error: unknown argument: '-ffoo' => reason ?

Hello,

I am working on the processing of the rebuild of Debian using clang 3.4.
I noticed that 159 packages are failing because on this simple call of
clang:
$ clang -fno-check-new -c foo.c
clang: error: unknown argument: '-fno-check-new'

I was wondering if there is a reason why this is an error and not a warning.

Thanks,
Sylvestre

Mostly tidiness. GCC (and every other command line tool really) errors
on unknown options.

We do try to ignore GCC options that are safe to ignore, so a patch
ignoring the ones that are causing you trouble is probably fine.

Cheers,
Rafael

Hello,

Is there a way to change this error to a warning, so that builds do not
fail?
Any flags to turn the message to a warning/error?

Thanks,
ali

OK. Thanks for the information.

There are quite some items with their occurrences:
      2 '-falign-jumps=2'
      2 '-fcheck-new'
     33 '-fexcess-precision=standard'
      2 '-fforce-addr'
      2 '-ffriend-injection'
      2 '-fgcse-after-reload'
      6 '-finline-limit='
      2 '-finput-charset=UTF-8'
      6 '-fno-check-new'
     40 '-fno-defer-pop'
      4 '-fno-delete-null-pointer-checks'
      1 '-fno-implement-inlines'
      1 '-fno-tree-ter'
     11 '-fno-tree-vrp'
      4 '-frename-registers'
      2 '-frerun-loop-opt'
      2 '-fsingle-precision-constant'
      2 '-fstack-check'
      2 '-fuse-linker-plugin'
      2 '-fvar-tracking'
      7 '-gnatea'
      2 '-gnatec=foo'
      2 '-malign-double'
      2 '-malign-jumps=1'
      4 '-print-multiarch'
      4 '-z'

Do you think I should ignore (all/most) them?

Thanks,
S

We do try to ignore GCC options that are safe to ignore, so a patch
ignoring the ones that are causing you trouble is probably fine.

OK. Thanks for the information.

There are quite some items with their occurrences:
      2 '-falign-jumps=2'
      2 '-fcheck-new'
     33 '-fexcess-precision=standard'
      2 '-fforce-addr'
      2 '-ffriend-injection'
      2 '-fgcse-after-reload'
      6 '-finline-limit='
      2 '-finput-charset=UTF-8'
      6 '-fno-check-new'
     40 '-fno-defer-pop'
      4 '-fno-delete-null-pointer-checks'
      1 '-fno-implement-inlines'
      1 '-fno-tree-ter'
     11 '-fno-tree-vrp'
      4 '-frename-registers'
      2 '-frerun-loop-opt'
      2 '-fsingle-precision-constant'
      2 '-fstack-check'
      2 '-fuse-linker-plugin'
      2 '-fvar-tracking'
      7 '-gnatea'
      2 '-gnatec=foo'
      2 '-malign-double'
      2 '-malign-jumps=1'
      4 '-print-multiarch'
      4 '-z'

Do you think I should ignore (all/most) them?

At least all the ones that just enable or disable a pass. Things like
-malign-double would probably turn a build error into a miscompilation
if ignored, so probably not.

Cheers,
Rafael

I disagree that we should be adding random "disable pass" options. It
just doesn't make sense and most of them shouldn't have been applied
unconditionally in first place as they are workarounds for optimizer
bugs in specific gcc versions. From the list:
- -fexcess-precision must not be dropped silently,
- -fno-check-new / -fcheck-new was discussed before, language lawyers
   can comment
- -finput-charset=UTF-8 would be safe to drop as it is the default
- -fsingle-precision-constant potentially changes behavior
- -fno-defer-pop was typically used without good reason, but custom asm
   parsers might depend on it, so no.
- -z should likely be fixed to be -Wl,-z

I would not change anything except maybe -finput-charset=UTF-8.

Joerg

At least all the ones that just enable or disable a pass. Things like
-malign-double would probably turn a build error into a miscompilation
if ignored, so probably not.

I disagree that we should be adding random "disable pass" options. It
just doesn't make sense and most of them shouldn't have been applied
unconditionally in first place as they are workarounds for optimizer
bugs in specific gcc versions. From the list:
- -fexcess-precision must not be dropped silently,
- -fno-check-new / -fcheck-new was discussed before, language lawyers
   can comment
- -finput-charset=UTF-8 would be safe to drop as it is the default
- -fsingle-precision-constant potentially changes behavior
- -fno-defer-pop was typically used without good reason, but custom asm
   parsers might depend on it, so no.
- -z should likely be fixed to be -Wl,-z

I would not change anything except maybe -finput-charset=UTF-8.

I think we are talking about different things. Yes, at some point it
would be nice to have a rationale for every option clang supports or
doesn't. My point is just that given that it warned on all of those
(including ABI breaking ones) no long ago, it seems reasonable to
going back to warning on an explicit list and then work our way over
that list.

Cheers,
Rafael

The list is unlikely to get shorter by just waiting. Most of the issues are in
software is between mature and dead. Warning now and error in half a
year only defers the pain.

Joerg

OK. I will give it a try with your list then.

Thanks for taking the time,
Sylvestre