[Bug c++/54560] New: g++ with --sysroot and -save-temps don't play nicely

[ianw at vmware dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54560

 Bug #: 54560
   Summary: g++ with --sysroot and -save-temps don't play nicely
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@vmware.com


We have a compiler built with a sysroot of "/dev/null", thus it always requires
a --sysroot argument.  A developer noticed that g++'s -save-temps option
doesn't work with this toolchain setup.

What happens is it gets to the stage of turning the .ii file in to the asm file
and cc1plus fails

---
/usr/bin/../libexec/gcc/x86_64-vmk-linux-gnu/4.6.3/cc1plus -fpreprocessed
foo.ii -quiet -dumpbase foo.cpp -m32 -march=i686 -auxbase-strip foo.o -g -O1
-Wall -Werror -Wno-unused-but-set-variable -Wno-conversion-null
-Wno-non-virtual-dtor -version -fwrapv -fno-working-directory -funwind-tables
-fasynchronous-unwind-tables -fstack-protector -fPIC -fno-strict-aliasing -o
foo.s
GNU C++ (GCC) version 4.6.3 (x86_64-vmk-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 5.0.4, MPFR version 2.4.2, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
cc1plus: error: /dev/null/usr/local/include: Not a directory
cc1plus: error: /dev/null/usr/include: Not a directory
GNU C++ (GCC) version 4.6.3 (x86_64-vmk-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 5.0.4, MPFR version 2.4.2, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
---

It's using the pre-processed source, so my feeling is that it doesn't require
the sysroot argument here.  Manually adding a -isysroot argument to *any* valid
directory (doesn't have to be a directory with the correct sysroot hierarchy in
it, e.g. /tmp) makes it work; so presumably the problem here is that
"/dev/null/usr/include" doesn't exist.

A quick search has not revealed to me where cc1plus is trying to access this
directory...

Another option might be to add a %I to the spec where this gets emitted [1] so
that a valid -isysroot value gets passed?

[1]
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/lang-specs.h;h=a73aba3cdc0dd970b068ce9172acdfeb20fbe7f5;hb=HEAD

[Bug c/25733] missed diagnostic about assignment used as truth value.

[ianw at vmware dot com]

--- Comment #6 from ianw at vmware dot com  2008-04-28 22:28 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Oh, just to be clear, my point was if (a=10) warns, but the extra 
> > parenthesis
> > hide the warning.
> 
> That is by design.

Ok, I did try looking but is that documented anywhere?

It would seem to have ramifications for people that do things like make an
ASSERT statement something like

#define ASSERT(v) {if (!(v))}

A quick search on google codesearch showed this was a very common idiom...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733

[Bug c/25733] missed diagnostic about assignment used as truth value.

[ianw at vmware dot com]

--- Comment #4 from ianw at vmware dot com  2008-04-28 22:16 ---
Oh, just to be clear, my point was if (a=10) warns, but the extra parenthesis
hide the warning.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733

[Bug c/25733] missed diagnostic about assignment used as truth value.

[ianw at vmware dot com]

--- Comment #3 from ianw at vmware dot com  2008-04-28 22:14 ---
As another data-point,

if ( (a=10) ) ;

also doesn't warn.  I'm not sure what the standard says on that, but other
contemporary compilers do give the an "assignment used as truth value" warning
for the example above.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733

[Bug c/36050] New: Ternary operator warning on assignment used as truth value

[ianw at vmware dot com]

Hi,

It would be great if ? warned when it got a (presumably accidental) assignment
like if statements do; e.g.

$ cat test.c
int main (void)
{
int i;
return (i = 20) ? 10 : 15;  
}
$ gcc-4.3 -Wall test.c 

It seems like this would be quite a common mistake?


-- 
   Summary: Ternary operator warning on assignment used as truth
value
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ianw at vmware dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36050