[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63886

--- Comment #12 from Eric Gallager  ---
I think someone added the -Wabsolute-value warning flag to GCC
recently; is it ok to close this bug now?

[Bug sanitizer/82595] bootstrap fails in libsanitizer on powerpc64-unknown-linux-gnu

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82595

--- Comment #6 from Eric Gallager  ---
On 10/19/17, jakub at gcc dot gnu.org  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82595
>
> --- Comment #5 from Jakub Jelinek  ---
> BTW, why --without-pic?  What you want to achieve by that?
>

I just copied it from my configure line from my home computer, which
runs i386-apple-darwin9.8.0, where I was trying --without-pic while
trying to fight with -mdynamic-no-pic when overriding BOOT_CFLAGS. I
guess I don't need it when compiling on the compile farm...

> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/67906] Missing warning about std::move without effect

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906

--- Comment #6 from Eric Gallager  ---
On 8/24/17, Mykola Orliuk  wrote:
> Hello
>
> Sure,
>
> struct Value {
> Value();
> Value(const Value&);
> Value(Value&&);
> };
>
> struct Frame {
> Value value; // previously mutable
> };
>
> Frame top;
> const Frame& x = top;
> Value y = std::move(x.value);
>
>
> https://godbolt.org/g/v24FfQ
>
> Thank you for looking into it. Yes, there should be better names than
> -Wno-effect. Maybe -Wignored-move and -Wmove-const are slightly better.
>
> Such warning will help to identify places which become ineffecient after
> changing constness of something.
>
> P.S. By some reason I were not able to leave comment in Bugzilla and got
> message "User account creation filtered due to spam." though I were logged
> in.
>

No, your comment still went through, 3 times in fact. The "User
account creation filtered due to spam" message is pinned to the top
for display to everyone; it doesn't actually mean that anything is
wrong with your account.

> Thank you,
> Mykola
>
> On Thu, Aug 24, 2017 at 7:40 AM egallager at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906
>>
>> Eric Gallager  changed:
>>
>>What|Removed |Added
>>
>> 
>>Keywords||diagnostic
>>  Status|UNCONFIRMED |WAITING
>>Last reconfirmed||2017-08-24
>>  CC||egallager at gcc dot
>> gnu.org
>>  Ever confirmed|0   |1
>>
>> --- Comment #1 from Eric Gallager  ---
>> Could you please provide a complete self-contained example? The snippet
>> you
>> posted looks like it's missing some declarations:
>>
>> $ /usr/local/bin/g++ -c 67906.cc
>> 67906.cc:1:7: error: ‘Frame’ does not name a type
>>  const Frame& x = stack.top();
>>^
>> 67906.cc:2:1: error: ‘Value’ does not name a type
>>  Value y = std::move(x.value); // x.value - non-mutable
>>  ^
>> $
>>
>> Anyways, bug 81159 is related, but that's about a different misuse of
>> std::move, so I'll keep the 2 separate.
>>
>> Oh, and also "-Wno-effect" would probably be a bad name for the option,
>> since
>> "-Wno-" is reserved for negative versions of warnings. i.e., is
>> "-Wno-effect"
>> the negative of "-Weffect"? That seems wrong. Or is it already in the
>> positive,
>> in which case the negative is "-Wno-no-effect"? That would seem
>> redundant.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>

[Bug c/80653] Enhancement: better location info for -Wunsafe-loop-optimizations

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80653

Eric Gallager  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing Bin Cheng since Bin is the most recent person to do stuff with
-Wunsafe-loop-optimizations

[Bug c/81453] relational expression involving null pointer not diagnosed with -Wall

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81453

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
Related: bug 7651

[Bug preprocessor/81419] New: GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419

Bug ID: 81419
   Summary: GCC wrongly suggests function-like macro as fixit hint
for undefined object-like macro
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
CC: dmalcolm at redhat dot com
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Testcase: 

$ cat macro_fixit.c
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))

int foo(unsigned int argument);

int bar(void)
{
return foo(PTR_SIZE);
}

Compiling gives:

$ /usr/local/bin/gcc -c macro_fixit.c
macro_fixit.c: In function ‘bar’:
macro_fixit.c:7:13: error: ‘PTR_SIZE’ undeclared (first use in this function);
did you mean ‘ARRAY_SIZE’?
  return foo(PTR_SIZE);
 ^~~~
 ARRAY_SIZE
macro_fixit.c:7:13: note: each undeclared identifier is reported only once for
each function it appears in

However, making the replacement that the fixit hint suggests is invalid, and
still leads to another error:

$ /usr/local/bin/gcc -c macro_fixit.c
macro_fixit.c: In function ‘bar’:
macro_fixit.c:7:13: error: ‘ARRAY_SIZE’ undeclared (first use in this function)
  return foo(ARRAY_SIZE);
 ^~
macro_fixit.c:7:13: note: each undeclared identifier is reported only once for
each function it appears in

IMO gcc should only suggest replacements as fixit hints when they actually fix
the problem being pointed out.

Version info:

$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170702 (experimental) (GCC)

[Bug preprocessor/49928] Only workaround for "-Wundef" is "defined(Macro) && Macro", but it is undefined behavior?

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49928

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
-Wexpansion-to-defined now exists and should warn about this

[Bug c/81417] New: -Wsign-compare should print types being compared

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81417

Bug ID: 81417
   Summary: -Wsign-compare should print types being compared
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Simple testcase:

$ cat Wsign_compare.c
/* { dg-do compile } */

int foo(signed int a, unsigned int b)
{
return (a < b);
}

When compiled with gcc, it says: 

$ /usr/local/bin/gcc -c -Wsign-compare Wsign_compare.c
Wsign_compare.c: In function ‘foo’:
Wsign_compare.c:5:12: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
  return (a < b);
^

However, when compiled with clang, it gives more information:

$ /sw/opt/llvm-3.1/bin/clang -c -Wsign-compare Wsign_compare.c
Wsign_compare.c:5:12: warning: comparison of integers of different signs: 'int'
and 'unsigned int' [-Wsign-compare]
return (a < b);
~ ^ ~
1 warning generated.

In such a small file like this it might not matter much, but in bigger files
where the variables being compared are very far away from their declarations,
it can be hard to remember what types they are. Having the compiler remind me
of the types being compared would be helpful when deciding how to silence
warnings like these.

Version info:

$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170702 (experimental) (GCC)

[Bug fortran/68649] [6/7/8 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #21 from Eric Gallager  ---
Bug 80379 is related

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

--- Comment #18 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #10)
> The last patch in comment 8 exposes another problem: buf[128] is too small.
> 
> The following patch which uses the trick proposed in IRC by Richi to split
> assemble_name_raw seems to work
> 
> --- ../_clean/gcc/config/darwin.c 2017-01-01 17:39:06.0 +0100
> +++ gcc/config/darwin.c   2017-07-03 14:21:19.0 +0200
> @@ -3683,11 +3683,9 @@ default_function_sections:
>  void
>  darwin_function_switched_text_sections (FILE *fp, tree decl, bool
> new_is_cold)
>  {
> -  char buf[128];
> -  snprintf (buf, 128, "%s%s",new_is_cold?"__cold_sect_of_":"__hot_sect_of_",
> - IDENTIFIER_POINTER (DECL_NAME (decl)));
>/* Make sure we pick up all the relevant quotes etc.  */
> -  assemble_name_raw (fp, (const char *) buf);
> +  assemble_name_raw (fp, new_is_cold?"__cold_sect_of_":"__hot_sect_of_");
> +  assemble_name_raw (fp, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
>fputs (":\n", fp);
>  }

I successfully bootstrapped with this patch; the test results produced by it
can be found here: https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg00365.html

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Mikael Pettersson from comment #0)
> 
> Side note, shouldn't there be a "diagnostic" component in bugzilla?  For now
> I chose "C frontend", which may or may not be appropriate.

You can put "diagnostic" under "keywords" instead

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81298

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #9 from Eric Gallager  ---
(In reply to tkoe...@netcologne.de from comment #8)
> 
> I understand that desire, but autoconf 2.69 has been around since 2012.
> It is hardly a fast-moving target.
> 
> I think it would be better to make a change towards 2.69.  The fewer
> versions of extra software we have to use to compile gcc, the better.

Seconded; I have local versions of override.m4 patched to say 2.69 instead of
2.64 for this reason

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

--- Comment #9 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #8)
> 
> 
> Looking into the error I suppose problem is:
> ___cold_sect_of_allocate:
> __ZN9__gnu_cxx16bitmap_allocatorIcE8allocateEmPKv.cold.42:
> 
> and bit later
> 
> ___cold_sect_of_allocate:
> __ZN9__gnu_cxx16bitmap_allocatorIwE8allocateEm.cold.47:
> 
> So perhaps the following fix it?
> Index: darwin.c
> ===
> --- darwin.c  (revision 249872)
> +++ darwin.c  (working copy)
> @@ -3685,7 +3665,7 @@
>  {
>char buf[128];
>snprintf (buf, 128, "%s%s",new_is_cold?"__cold_sect_of_":"__hot_sect_of_",
> - IDENTIFIER_POINTER (DECL_NAME (decl)));
> + IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
>/* Make sure we pick up all the relevant quotes etc.  */
>assemble_name_raw (fp, (const char *) buf);
>fputs (":\n", fp);

I tried this patch; bootstrap still fails for me, albeit on a different file
now. New error message is:

/private/var/root/gcc-git/my_oddly_named_builddir/./prev-gcc/xg++
-B/private/var/root/gcc-git/my_oddly_named_builddir/./prev-gcc/
-B/usr/local/i386-apple-darwin9.8.0/bin/ -nostdinc++
-B/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/src/.libs
-B/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs

-I/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/include/i386-apple-darwin9.8.0

-I/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/include
 -I/private/var/root/gcc-git/libstdc++-v3/libsupc++
-L/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/src/.libs
-L/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -mdynamic-no-pic  -gtoggle -DIN_GCC -fPIC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include
-I/private/var/root/gcc-git/my_oddly_named_builddir/./gmp
-I/private/var/root/gcc-git/gmp
-I/private/var/root/gcc-git/my_oddly_named_builddir/./mpfr/src
-I/private/var/root/gcc-git/mpfr/src -I/private/var/root/gcc-git/mpc/src 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/../libbacktrace
-I/private/var/root/gcc-git/my_oddly_named_builddir/./isl/include
-I/private/var/root/gcc-git/isl/include -I/usr/local/include -o
gimple-ssa-store-merging.o -MT gimple-ssa-store-merging.o -MMD -MP -MF
./.deps/gimple-ssa-store-merging.TPo ../../gcc/gimple-ssa-store-merging.c
cc1plus: warning: ‘-mdynamic-no-pic’ overrides ‘-fpic’, ‘-fPIC’, ‘-fpie’ or
‘-fPIE’
/var/tmp//cc2wwOg4.s:2529:FATAL:Symbol
___cold_sect_of__ZN10hash_tableIN8hash_mapI17tree_operand_hashPN12_GLOBAL__N_120imm_store_chain_infoE21simple_hashmap_traitsI19d
already defined.
make[3]: *** [gimple-ssa-store-merging.o] Error 1
make[3]: Leaving directory
`/private/var/root/gcc-git/my_oddly_named_builddir/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make: *** [all] Error 2

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

--- Comment #7 from Eric Gallager  ---
For me the error is:

/private/var/root/gcc-git/my_oddly_named_builddir/./prev-gcc/xg++
-B/private/var/root/gcc-git/my_oddly_named_builddir/./prev-gcc/
-B/usr/local/i386-apple-darwin9.8.0/bin/ -nostdinc++
-B/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/src/.libs
-B/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs

-I/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/include/i386-apple-darwin9.8.0

-I/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/include
 -I/private/var/root/gcc-git/libstdc++-v3/libsupc++
-L/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/src/.libs
-L/private/var/root/gcc-git/my_oddly_named_builddir/prev-i386-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -mdynamic-no-pic  -gtoggle -DIN_GCC -fPIC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc
-I../../gcc/build -I../../gcc/../include  -I../../gcc/../libcpp/include
-I/usr/local/include \
-o build/genmatch.o ../../gcc/genmatch.c
/var/tmp//cciuyI6t.s:4862:FATAL:Symbol ___cold_sect_of_gen_transform already
defined.
make[3]: *** [build/genmatch.o] Error 1
make[3]: Leaving directory
`/private/var/root/gcc-git/my_oddly_named_builddir/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/private/var/root/gcc-git/my_oddly_named_builddir'
make: *** [all] Error 2

...which I think is the same thing since it's an assembler error that mentions
a ___cold_sect_of_* symbol. I'm on i386-apple-darwin9.8.0 compiling trunk
checked out as of r249881.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #51 from Eric Gallager  ---
(In reply to Daniel Santos from comment #50)
> 
> It would be nice if the "naked" function attribute were available for the
> i386 back-end, then I wouldn't have to screw around with trying to hack-away
> the ABI. (maybe a worthwhile future venture)
> 

This is bug 25967

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80949

--- Comment #7 from Eric Gallager  ---
(In reply to Marek Polacek from comment #6)
> Would it be possible for you to try this patch?
> 
> --- a/gcc/c-family/c-warn.c
> +++ b/gcc/c-family/c-warn.c
> @@ -2354,8 +2354,8 @@ do_warn_duplicated_branches (tree expr)
>tree thenb = COND_EXPR_THEN (expr);
>tree elseb = COND_EXPR_ELSE (expr);
>  
> -  /* Don't bother if there's no else branch.  */
> -  if (elseb == NULL_TREE)
> +  /* Don't bother if any of the branches is missing.  */
> +  if (thenb == NULL_TREE || elseb == NULL_TREE)
>  return;
>  
>/* And don't warn for empty statements.  */

I tried it and it worked; compilation succeeded with no ICEs (or other errors
for that matter). Thank you!

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80949

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> 
> I'll leave the debug session open; let me know if you need any more info...

Never mind, I closed the debugger, but can reopen it if necessary. Here's an
even fuller backtrace I got before closing it:

(gdb) bt full
#0  0x00135430 in do_warn_duplicated_branches (expr=0x560ba10) at
../../gcc/c-family/c-warn.c:2362
thenb = (tree) 0x0
elseb = (tree) 0x55e7f80
hstate0 = {
  val = 1132540324, 
  bits = 509
}
h0 = 3221187736
hstate1 = {
  val = 233, 
  bits = 439
}
h1 = 342339
#1  0x001355ff in do_warn_duplicated_branches_r (tp=0x55fdaa0) at
../../gcc/c-family/c-warn.c:2401
No locals.
#2  0x01751efd in walk_tree_1 (tp=0x55fdaa0, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11838
code = 479
walk_subtrees = 1
result = (tree) 0x4381320c
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#3  0x017522a2 in walk_tree_1 (tp=0x56149a4, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
i = {
  ptr = 0x55fda98, 
  container = 0x5612a3c
}
code = STATEMENT_LIST
walk_subtrees = 1
result = (tree) 0x0
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#4  0x017522a2 in walk_tree_1 (tp=0x560b960, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
i = {
  ptr = 0x55fda5c, 
  container = 0x561226c
}
code = STATEMENT_LIST
walk_subtrees = 1
result = (tree) 0x0
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#5  0x017522a2 in walk_tree_1 (tp=0x560ba5c, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
i = {
  ptr = 0x55fdab0, 
  container = 0x560c190
}
code = STATEMENT_LIST
walk_subtrees = 1
result = (tree) 0x0
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#6  0x01751b3b in walk_tree_without_duplicates_1 (tp=0x53a7bec, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, lh=0) at
../../gcc/tree.c:12181
result = (tree) 0x437d2490
pset = {
  m_table = {
m_entries = 0x43812e00, 
m_size = 509, 
m_n_elements = 230, 
m_n_deleted = 0, 
m_searches = 361, 
m_collisions = 299, 
m_size_prime_index = 6, 
m_ggc = false, 
m_gather_mem_stats = false
  }
}
#7  0x001091ba in c_genericize (fndecl=0x53a7b80) at
../../gcc/c-family/c-gimplify.c:129
dump_orig = (FILE *) 0x53a7b80
local_dump_flags = 0
cgn = (cgraph_node *) 0x6
#8  0x0003f382 in finish_function () at ../../gcc/c/c-decl.c:9350
fndecl = (tree) 0x53a7b80
#9  0x00081370 in c_parser_declaration_or_fndef (parser=0x436a60a8,
fndef_ok=true, static_assert_ok=true, empty_ok=true, nested=false,
start_attr_ok=true, objc_foreach_object_declaration=0x0,
omp_declare_simd_clauses={m_vec = 0x0}, oacc_routine_data=0x0,
fallthru_attr_p=0x0) at ../../gcc/c/c-parser.c:2147
tv = TV_PARSE_FUNC
fnbody = (tree) 0x560ba48
fndecl = (tree) 0x53a7b80
declarator = (c_declarator *) 0x434b81a0
dummy = true
at = {
  m_timer = 0x0, 
  m_tv = TV_PARSE_FUNC
}
specs = (c_declspecs *) 0x434b8010
prefix_attrs = (tree) 0x0
all_prefix_attrs = (tree) 0x0
diagnosed_no_specs = false
here = 2147688185
auto_type_p = false
#10 0x000ab4fd in c_parser_external_declaration (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1469
ext = 1291845632
_ZZL29c_parser_external_declarationP8c_parserE12__FUNCTION__ =
"c_parser_external_declaration"
#11 0x000ab650 in c_parser_translation_unit (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1349
obstack_position = (void *) 0x434b8010
i = 3221189208
decl = (tree) 0xbfff794c
#12 0x000ab7ca in c_parse_file () at ../../gcc/c/c-parser.c:18112
tparser = {
  tokens = 0xbfff7274, 
  tokens_buf = {{
  type = CPP_KEYWORD, 
  id_kind = C_ID_NONE, 
  keyword = RID_TYPEDEF, 
  pragma_kind = PRAGMA_NONE, 
  location = 57329990, 
  value = 0x43618990, 
  flags = 64 '@'
}, {
  type = CPP_EQ, 
  id_kind = C_ID_ID, 
  keyword = RID_STATIC, 
  pragma_kind = PRAGMA_NONE, 
  location = 0, 
  value = 0x0, 
  flags = 0 '\0'
}, {
  type = 

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80949

--- Comment #4 from Eric Gallager  ---
(In reply to Marek Polacek from comment #3)
> This is x86_64-pc-linux-gnu.  I tried various combinations of the above
> options but I'm always seeing some errors.  Perhaps it would be possible to
> isolate the function where the crash occurs and thus get rid of
> target-dependent stuff?
> 
> I'd be interested in seeing a better backtrace, too.

I looked into creduce but apparently it doesn't work with objc yet:
https://github.com/csmith-project/creduce/issues/31

Anyways here's a better backtrace:


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00135430 in do_warn_duplicated_branches (expr=0x560ba10) at
../../gcc/c-family/c-warn.c:2362
2362  if (TREE_CODE (thenb) == NOP_EXPR
(gdb) bt
#0  0x00135430 in do_warn_duplicated_branches (expr=0x560ba10) at
../../gcc/c-family/c-warn.c:2362
#1  0x001355ff in do_warn_duplicated_branches_r (tp=0x55fdaa0) at
../../gcc/c-family/c-warn.c:2401
#2  0x01751efd in walk_tree_1 (tp=0x55fdaa0, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11838
#3  0x017522a2 in walk_tree_1 (tp=0x56149a4, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
#4  0x017522a2 in walk_tree_1 (tp=0x560b960, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
#5  0x017522a2 in walk_tree_1 (tp=0x560ba5c, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
#6  0x01751b3b in walk_tree_without_duplicates_1 (tp=0x53a7bec, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, lh=0) at
../../gcc/tree.c:12181
#7  0x001091ba in c_genericize (fndecl=0x53a7b80) at
../../gcc/c-family/c-gimplify.c:129
#8  0x0003f382 in finish_function () at ../../gcc/c/c-decl.c:9350
#9  0x00081370 in c_parser_declaration_or_fndef (parser=0x436a60a8,
fndef_ok=true, static_assert_ok=true, empty_ok=true, nested=false,
start_attr_ok=true, objc_foreach_object_declaration=0x0,
omp_declare_simd_clauses={m_vec = 0x0}, oacc_routine_data=0x0,
fallthru_attr_p=0x0) at ../../gcc/c/c-parser.c:2147
#10 0x000ab4fd in c_parser_external_declaration (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1469
#11 0x000ab650 in c_parser_translation_unit (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1349
#12 0x000ab7ca in c_parse_file () at ../../gcc/c/c-parser.c:18112
#13 0x0011349f in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1104
#14 0x01468198 in compile_file () at ../../gcc/toplev.c:468
#15 0x01469d18 in do_compile () at ../../gcc/toplev.c:2021
#16 0x01469fcf in toplev::main (this=0xbfff741e, argc=257, argv=0xbfff7450) at
../../gcc/toplev.c:2155
#17 0x018a42ab in main (argc=257, argv=0xbfff7450) at ../../gcc/main.c:39
Current language:  auto; currently c++


I'll leave the debug session open; let me know if you need any more info...

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80949

--- Comment #2 from Eric Gallager  ---
(In reply to Marek Polacek from comment #1)
> I can't reproduce; I get some errors:
> 
> $ ./cc1obj -quiet nsselect.mi  -fobjc-exceptions
> In file included from lisp.h:39:0,
>  from nsselect.m:32:
> ../lib/intprops.h:91:1: error: static assertion failed: "verify
> (TYPE_MINIMUM (long int) == LONG_MIN)"
> In file included from lisp.h:39:0,
>  from nsselect.m:32:
> ../lib/intprops.h:92:1: error: static assertion failed: "verify
> (TYPE_MAXIMUM (long int) == LONG_MAX)"
> In file included from nsselect.m:32:0:
> lisp.h:197:1: error: static assertion failed: "verify (BITS_WORD_MAX >>
> (BITS_PER_BITS_WORD - 1) == 1)"
> nsselect.m: In function ‘ns_string_from_pasteboard’:
> nsselect.m:274:7: error: cannot find interface declaration for
> ‘NXConstantString’

I'm guessing those are due to target differences; first 2 look like 32bit vs.
64bit issues, while the 3rd looks like a difference between -fgnu-runtime vs.
-fnext-runtime. What's the target for the compiler you're using? Also I'm
guessing that since the ICE was in do_warn_duplicated_branches_r that the
-Wduplicated-branches flag will be necessary to trigger it

[Bug objc/80949] New: ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80949

Bug ID: 80949
   Summary: ICE in do_warn_duplicated_branches_r
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Created attachment 41447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41447=edit
compressed preprocessed source

Compiling my fork of emacs led to a new ICE with my latest pull from trunk.
Full command line:

/usr/local/bin/gcc -c -DMAC_OSX=1   -DXASSERTS=1 -Demacs  -I.
-I/var/root/emacs/src -I../lib -I/var/root/emacs/src/../lib  -DMAC_OSX=1
-isystem /usr/X11/include  -fno-strict-aliasing  -isystem /sw/include/librsvg-2
-isystem /sw/include/glib-2.0 -isystem /sw/lib/glib-2.0/include -isystem
/sw/include/gtk-2.0 -isystem /sw/include/cairo -isystem /sw/include -isystem
/sw/include/freetype2 -isystem /usr/X11/include -isystem
/sw/include/ImageMagick-isystem /sw/include/libxml2 -isystem /sw/include
-isystem /sw/include/dbus-1.0 -isystem /sw/lib/dbus-1.0/include 
-isystem /sw/include-fno-common -Wabi -Waddress
-Waggressive-loop-optimizations -Wall -Wattributes -Wbool-compare
-Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wchkp -Wclobbered
-Wcomment -Wcoverage-mismatch -Wcpp -Wdate-time -Wdeprecated
-Wdeprecated-declarations -Wdesignated-init -Wdisabled-optimization
-Wdiscarded-array-qualifiers -Wdiscarded-qualifiers -Wdiv-by-zero
-Wdouble-promotion -Wduplicated-cond -Wempty-body -Wendif-labels -Wenum-compare
-Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-security
-Wformat-signedness -Wformat-y2k -Wformat-zero-length -Wframe-address
-Wfree-nonheap-object -Whsa -Wimplicit -Wimplicit-function-declaration
-Wimplicit-int -Wincompatible-pointer-types -Winit-self -Wint-conversion
-Wint-to-pointer-cast -Winvalid-memory-model -Winvalid-pch -Wjump-misses-init
-Wlogical-not-parentheses -Wmain -Wmaybe-uninitialized -Wmemset-transposed-args
-Wmisleading-indentation -Wmissing-braces -Wmissing-declarations
-Wmissing-include-dirs -Wmissing-parameter-type -Wmissing-prototypes
-Wmultichar -Wnarrowing -Wnonnull -Wnonnull-compare -Wnull-dereference
-Wold-style-declaration -Wold-style-definition -Woverflow -Woverlength-strings
-Woverride-init -Wpacked -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith
-Wpointer-sign -Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr
-Wreturn-type -Wscalar-storage-order -Wsequence-point -Wshift-count-negative
-Wshift-count-overflow -Wshift-negative-value -Wsizeof-array-argument
-Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes
-Wsuggest-attribute=const -Wsuggest-attribute=format
-Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types
-Wswitch-bool -Wswitch-default -Wtautological-compare -Wtrampolines -Wtrigraphs
-Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations -Wunused
-Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function
-Wunused-label -Wunused-local-typedefs -Wunused-macros -Wunused-result
-Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros
-Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings
-Warray-bounds=2 -Wnormalized=nfc -Wshift-overflow=2 -Wunused-const-variable=2
-Wno-missing-field-initializers -Wno-sign-compare -Wno-type-limits -Wno-switch
-Wno-unused-parameter -Wno-format-nonliteral -Wno-logical-op
-Wnonportable-cfstrings -Wstrict-overflow=1 -Wdeclaration-after-statement
-Wmissing-noreturn -Wunreachable-code -Woverride-init-side-effects
-Wshift-overflow=2 -Wdangling-else -Wduplicate-decl-specifier -Wmemset-elt-size
-Wswitch-unreachable -Wimplicit-fallthrough -Wformat-overflow=2
-Wformat-truncation=2 -Wstringop-overflow=2 -Wexpansion-to-defined -Wrestrict
-Wint-in-bool-context -Wpointer-compare -Wbool-operation -Wduplicated-branches
-Walloca-larger-than=16384 -Wvla-larger-than=16384
-Walloc-size-larger-than=32840 -Walloc-zero -Wpsabi
-Wbuiltin-declaration-mismatch -fno-eliminate-unused-debug-symbols
-fno-crossjumping -fno-delete-dead-exceptions -fno-delete-null-pointer-checks
-fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fno-optimize-strlen -fno-sched-spec-load-dangerous
-fno-split-wide-types -fbounds-check -fcheck-data-deps -fexceptions
-fstack-check -ftrapv -fvar-tracking -fvar-tracking-assignments -gpubnames
-gstrict-dwarf -falign-functions=4 -falign-labels=4 -falign-loops=4
-falign-jumps=4 -ggdb3 -Og -gdwarf-2 -gfull -mfix-and-continue 
-fobjc-exceptions   -Wassign-intercept -Wcast-align -Wproperty-assign-default
-Wprotocol -Wshadow-ivar -Wundeclared-selector -Wno-missing-noreturn
-Wno-overlength-stri

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #26 from Eric Gallager  ---
(In reply to Keith Thompson from comment #3)
> I see no "-Walign" option, either in the versions of gcc I'm using or in the
> online documentation.  Were you thinking of a different option?
>

Maybe -Wpacked?

[Bug objc/80912] enhancement: -Wundeclared-selector improvements

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80912

--- Comment #1 from Eric Gallager  ---
Created attachment 41437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41437=edit
compressed preprocessed source

Oops, the preprocessed source was too big to attach by itself, so I had to
compress it.

[Bug objc/80912] New: enhancement: -Wundeclared-selector improvements

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80912

Bug ID: 80912
   Summary: enhancement: -Wundeclared-selector improvements
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

1. -fdiagnostics-show-option does not actually cause the
'-Wundeclared-selector' option to be shown.

macappkit.m: In function ‘-[EmacsController
setConflictingKeyBindingsDisabled:]’:
macappkit.m:2010:4: warning: undeclared selector ‘sharedKeyBindingManager’
performSelector:@selector(sharedKeyBindingManager)];
^~~

should be

macappkit.m: In function ‘-[EmacsController
setConflictingKeyBindingsDisabled:]’:
macappkit.m:2010:4: warning: undeclared selector ‘sharedKeyBindingManager’
[-Wundeclared-selector]
performSelector:@selector(sharedKeyBindingManager)];
^~~

2. Better location info: the caret points to the beginning of the line instead
of the actual selector that is undeclared:

macappkit.m:2016:7: warning: undeclared selector ‘setQuoteBinding:’
   [keyBindingManager performSelector:@selector(setQuoteBinding:)
   ^

should point to 'setQuoteBinding:' instead.

3. '-Wundeclared-selector' ignores -ftrack-macro-expansion. Take for example:

macappkit.m: In function ‘-[EmacsController
handleQueuedNSEventsWithHoldingQuitIn:]’:
macappkit.m:1869:8: warning: undeclared selector ‘dummy’
MOUSE_TRACKING_RESET();
^~~~

MOUSE_TRACKING_RESET is a macro that expands to:

#define MOUSE_TRACKING_RESET()  \
  [self setTrackingObject:nil andResumeSelector:@selector(dummy)]

on line 1735 of this file. I would expect the warning to point inside the
definition of this macro, instead of pointing where it is used.

The file I am compiling, macappkit.m, is from YAMAMOTO Mitsuharu's Mac port of
Emacs. Full command line is:

$ /usr/local/bin/gcc -c -DMAC_OSX=1   -I/usr/local/include -DXASSERTS=1 -Demacs
 -I. -I/var/root/emacs/src -I../lib -I/var/root/emacs/src/../lib  -DMAC_OSX=1
-isystem /usr/X11/include   -isystem /sw/include/libxml2 -isystem
/sw/include -isystem /sw/include/dbus-1.0 -isystem /sw/lib/dbus-1.0/include
 -isystem /sw/include-Wno-deprecated-declarations -fno-common -Wabi
-Waddress -Waggressive-loop-optimizations -Wall -Wattributes -Wbool-compare
-Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wchkp -Wclobbered
-Wcomment -Wcoverage-mismatch -Wcpp -Wdate-time -Wdeprecated -Wdesignated-init
-Wdisabled-optimization -Wdiscarded-array-qualifiers -Wdiscarded-qualifiers
-Wdiv-by-zero -Wdouble-promotion -Wduplicated-cond -Wempty-body -Wendif-labels
-Wenum-compare -Wextra -Wformat-contains-nul -Wformat-extra-args
-Wformat-security -Wformat-signedness -Wformat-y2k -Wformat-zero-length
-Wframe-address -Wfree-nonheap-object -Whsa -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Winit-self -Wint-conversion -Wint-to-pointer-cast -Winvalid-memory-model
-Winvalid-pch -Wjump-misses-init -Wlogical-not-parentheses -Wmain
-Wmaybe-uninitialized -Wmemset-transposed-args -Wmisleading-indentation
-Wmissing-braces -Wmissing-declarations -Wmissing-include-dirs
-Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing -Wnonnull
-Wnonnull-compare -Wnull-dereference -Wold-style-declaration
-Wold-style-definition -Woverflow -Woverlength-strings -Woverride-init -Wpacked
-Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign
-Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type
-Wscalar-storage-order -Wsequence-point -Wshift-count-negative
-Wshift-count-overflow -Wshift-negative-value -Wsizeof-array-argument
-Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes
-Wsuggest-attribute=const -Wsuggest-attribute=format
-Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types
-Wswitch-bool -Wswitch-default -Wtautological-compare -Wtrampolines -Wtrigraphs
-Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations -Wunused
-Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function
-Wunused-label -Wunused-local-typedefs -Wunused-macros -Wunused-result
-Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros
-Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings
-Warray-bounds=2 -Wnormalized=nfc -Wshift-overflow=2 -Wunused-const-variable=2
-Wno-missing-field-initializers -Wno-sign-compare -Wno-type-limits -Wno-switch
-Wno-unused-parameter -Wno-format-nonliteral -Wno-logical-op
-Wnonportable-cfstrings -Wstrict-overflow=1 -Wdeclaration-after-statement
-Wmissing-noreturn -Wunreachable-code -Woverride-init

[Bug c/80892] New: [8 regression] -Wfloat-conversion now warns about non-floats

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80892

Bug ID: 80892
   Summary: [8 regression] -Wfloat-conversion now warns about
non-floats
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-apple-darwin10.8.0
Target: i386-apple-darwin10.8.0
 Build: i386-apple-darwin10.8.0

Previously, it was possible to request warnings about just conversions
involving floating point types by specifying -Wfloat-conversion. However, with
my latest build from trunk, -Wfloat-conversion seems to have become an alias
for -Wconversion, meaning that it now warns on things like:

/usr/local/bin/gcc -c -DHAVE_CONFIG_H -g -O2 -arch i386  -I. -I./../include
-D_DARWIN_UNLIMITED_STREAMS -mmacosx-version-min=10.5 -Wall -Wextra
-Wwrite-strings -Wc++-compat -Wodr -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-parameter-type -Wmissing-declarations -Wnested-externs -Wundef
-Wshadow -Wformat=2 -Wformat-overflow=2 -Wformat-truncation=2
-Wstringop-overflow=2 -Walloc-zero -Wrestrict -Wold-style-definition
-Wold-style-declaration -Wfloat-conversion -Wabi -Wc99-c11-compat
-Wmisleading-indentation -Wnull-dereference -Wpointer-compare -Wbool-operation
-pedantic  ./cp-demangle.c -o cp-demangle.o
./cp-demangle.c: In function 'd_print_java_identifier':
./cp-demangle.c:3473:27: warning: conversion from 'long unsigned int' to 'char'
may change value [-Wfloat-conversion]
d_append_char(dpi, c);
   ^

This means I now have a bunch of new warnings in my build where I previously
didn't, because I'm only using -Wfloat-conversion and not the full
-Wconversion. cc-ing Martin Sebor since he was the last one I remember seeing
posting patches touching the -Wconversion code.

gcc version info:
$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin10.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin10.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,objc,obj-c++,lto --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --without-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
--disable-nls --with-system-zlib --with-libiconv-prefix=/opt/local
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto
--enable-libstcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --enable-objc-gc --enable-libada --enable-libssp
CC='/usr/bin/gcc-4.2 -arch i386 -arch x86_64' CXX='/usr/bin/g++-4.2 -arch
x86_64' AR_FOR_TARGET=/opt/local/bin/ar AS_FOR_TARGET=/opt/local/bin/as
LD_FOR_TARGET=/opt/local/bin/ld NM_FOR_TARGET=/opt/local/bin/nm
RANLIB_FOR_TARGET=/opt/local/bin/ranlib STRIP_FOR_TARGET=/opt/local/bin/strip
OTOOL=/opt/local/bin/otool OTOOL64=/opt/local/bin/otool
AUTOCONF=/opt/local/bin/autoconf264 AUTOHEADER=/opt/local/bin/autoheader264
AUTOM4TE=/opt/local/bin/autom4te264 AUTORECONF=/opt/local/bin/autoreconf264
AUTOSCAN=/opt/local/bin/autoscan264 AUTOUPDATE=/opt/local/bin/autoupdate264
IFNAMES=/opt/local/bin/ifnames264 ACLOCAL=/sw/bin/aclocal-1.11
PERL=/opt/local/bin/perl CFLAGS='-pipe -g -Os' CXXFLAGS='-pipe -g -Os
-fcheck-new' CPP='/usr/bin/gcc-4.2 -E' CXXCPP='/usr/bin/g++-4.2 -E'
M4=/opt/local/bin/gm4
Thread model: posix
gcc version 8.0.0 20170525 (experimental) (GCC)

[Bug c/80653] New: Enhancement: better location info for -Wunsafe-loop-optimizations

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80653

Bug ID: 80653
   Summary: Enhancement: better location info for
-Wunsafe-loop-optimizations
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---

Currently, with a for-loop, -Wunsafe-loop-optimizations points to the "for":

reloc.c: In function 'bfd_generic_get_relocated_section_contents':
reloc.c:6000:7: warning: missed loop optimization, the loop counter may
overflow [-Wunsafe-loop-optimizations]
   for (parent = reloc_vector; (parent != NULL) && (*parent != NULL);
   ^~~

and with a while-loop, it points to the opening parenthesis:

pef.c: In function 'bfd_pef_parse_symbols':
pef.c:893:13: warning: missed loop optimization, the loop counter may overflow
[-Wunsafe-loop-optimizations]
   while (((codepos + 4UL) <= codelen) && (codepos < (size_t)UINT_MAX))
 ^
pef.c:723:13: warning: missed loop optimization, the loop counter may overflow
[-Wunsafe-loop-optimizations]
   while (((pos + 4UL) <= len) && (pos < (size_t)UINT_MAX))
 ^

It'd be more useful if the caret instead pointed to the variable being used as
the loop counter, and/or the point in the loop where it actually overflows

[Bug c/80529] Split "C++ style comments are not allowed in ISO C90" pedwarn into its own warning flag

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80529

--- Comment #2 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #1)
> IMHO warnings should not be enforcing in-house coding guidelines. Use
> clang-tidy for that.

GCC already has several warnings added for that purpose. -Wtemplates,
-Wmultiple-inheritance, -Wvirtual-inheritance, and -Wnamespaces are all
documented as existing because:
"Some coding rules disallow
[templates|[multiple|virtual]inheritance|namespaces], and this may be used to
enforce that rule."
And then -Weffc++ is also documented as being a set of style guidelines.
Also it seems odd that a GCC developer would recommend using a clang-based tool
instead of GCC when clang is a competing project designed specifically to
undermine GCC.

[Bug c/80529] New: Split "C++ style comments are not allowed in ISO C90" pedwarn into its own warning flag

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80529

Bug ID: 80529
   Summary: Split "C++ style comments are not allowed in ISO C90"
pedwarn into its own warning flag
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---

Given the following source:
$ cat gcctestcase01.c
// bad comment
int foo;

GCC errors on it with -std=c89 and -ansi, and warns on it with -std=gnu89
-pedantic, for example:

$ /usr/local/bin/gcc -std=gnu89 -pedantic -c gcctestcase01.c
gcctestcase01.c:1:1: warning: C++ style comments are not allowed in ISO C90
 // bad comment
 ^
gcctestcase01.c:1:1: warning: (this will be reported only once per input file)

However, many C projects disallow C++ style comments not for compatibility with
C90, but for style reasons. It'd be nice to be able to get this warning when
using newer language standards for such projects that disallow C++ style
comments anyways, especially now that GCC defaults to -std=gnu11 (meaning that
just adding -pedantic isn't enough). I suggest calling it -Wc++-style-comment.

[Bug tree-optimization/80519] if(p)free(p) with -Os

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80519

--- Comment #4 from Eric Gallager  ---
(In reply to Marc Glisse from comment #3)
> A warning would be quite a different thing. You would want it in the
> front-end, to detect when a user literally wrote if(p)free(p). What I am
> interested in is an optimization that detects when, possibly after inlining
> and other optimizations, a call to free ends up below a null check, which is
> normal and should not cause a warning.
> 
> Since the 2 are unlikely to share any code, I'd suggest filing a separate PR.

OK, I opened PR80528 for the warning.

[Bug c/80528] New: reimplement gnulib's "useless-if-before-free" script as a compiler warning

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80528

Bug ID: 80528
   Summary: reimplement gnulib's "useless-if-before-free" script
as a compiler warning
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---

Split off from Bug 80519

Gnulib has a script called "useless-if-before-free" that detects code like:
if (p) free(p);
and warns about it, since the "if" test is usually unneeded nowadays. It'd be
nice if GCC did this warning instead, so users wouldn't have to import a
separate script from gnulib just to check for this sort of thing.

Source for script:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free;h=4e3f3a2658b105e8949f14ef85d733192c29be2c;hb=HEAD

[Bug tree-optimization/80519] if(p)free(p) with -Os

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80519

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
It'd be nice if the compiler could emit a warning when removing such a check,
that way gnulib wouldn't need to keep around the "useless-if-before-free"
script any more if the compiler could just do it instead

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80354

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> The warning does just what it's designed to do: point out the potential
> unhandled truncation.  If the argument values are such that the truncation
> cannot occur then using snprintf is unnecessary and sprintf can be used
> instead.

There's other code checking tools (e.g. splint) that say to never use sprintf
and to always use snprintf instead; the manpage on my computer for sprintf also
says to always use snprintf instead. For this reason some projects do
#pragma GCC poison sprintf
in a header file, so sprintf can't actually be used instead in those cases.

[Bug c/54032] The C compiler does not warn about casts to more aligned types

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54032

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
This could probably also be marked as a duplicate of bug 41809 (like bug 79918
was) since that one is older and it looks like the same issue.

[Bug c/79918] Feature request: Warning about (may potential) misaligned address-reference

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79918

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
Is this the same as the issue in bug 41809?

[Bug middle-end/80023] missing diagnostic on aligned_alloc with invalid alignment

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80023

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
I would like to see this diagnostic please; "confirmed"

[Bug c/80116] Warn about macros expanding to multiple statements

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80116

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> Confirmed.  The CERT C Coding Standard outlines a number of common problems
> with macros that might be worth considering for inclusion in the proposed
> warning.   The following is the subject of this enhancement request:
> 
>   PRE10-C. Wrap multistatement macros in a do-while loop
>   https://www.securecoding.cert.org/confluence/x/jgL7
> 
> Some other checkers:
> 
>   PRE01-C. Use parentheses within macros around parameter names
>   https://www.securecoding.cert.org/confluence/x/CgU
> 
>   PRE02-C. Macro replacement lists should be parenthesized
>   https://www.securecoding.cert.org/confluence/x/HAs
> 
>   PRE11-C. Do not conclude macro definitions with a semicolon
>   https://www.securecoding.cert.org/confluence/x/wgBlAQ
> 
>   PRE12-C. Do not define unsafe macros
>   https://www.securecoding.cert.org/confluence/x/TIF3Ag
> 
>   PRE31-C. Avoid side effects in arguments to unsafe macros
>   https://www.securecoding.cert.org/confluence/x/agBi

Many of these are also in the CPP manual at:
https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html#Macro-Pitfalls
(even though no actual warning is output for any of them yet)

[Bug middle-end/80042] gcc thinks sin/cos don't set errno

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
Does toggling the flag -fmath-errno have any effect?

[Bug c/79936] ICE with -Walloc-size-larger-than=32767

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79936

--- Comment #3 from Eric Gallager  ---
Created attachment 40903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40903=edit
preprocessed source

(In reply to Andrew Pinski from comment #2)
> >Interestingly, the ICE seems to go away when I try to save the preprocessed
> >source to attach to this bug:
> 
> That usually might point to a GC issue.  still attach the preprocessed
> source and we can try to see what is going on.

OK, I did

[Bug c/79936] New: ICE with -Walloc-size-larger-than=32767

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79936

Bug ID: 79936
   Summary: ICE with -Walloc-size-larger-than=32767
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: diagnostic, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin10.8.0
Target: x86_64-apple-darwin10.8.0
 Build: x86_64-apple-darwin10.8.0

Created attachment 40902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40902=edit
system-generated crash report

Found when compiling my fork of emacs:

$ make sha256.o V=1
/usr/local/bin/gcc -DHAVE_CONFIG_H -D_IN_GNULIB -I. -I../src  -I.
-I/Users/ericgallager/emacs/lib -I../src -I/Users/ericgallager/emacs/src
-DMAC_OSX=1   -DXASSERTS=1  -fno-common -Wabi -Waddress
-Waggressive-loop-optimizations -Wall -Wattributes -Wbool-compare
-Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wchkp -Wclobbered
-Wcomment -Wcoverage-mismatch -Wcpp -Wdate-time -Wdeprecated
-Wdeprecated-declarations -Wdesignated-init -Wdisabled-optimization
-Wdiscarded-array-qualifiers -Wdiscarded-qualifiers -Wdiv-by-zero
-Wduplicated-cond -Wempty-body -Wendif-labels -Wenum-compare -Wextra
-Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-y2k
-Wformat-zero-length -Wframe-address -Wfree-nonheap-object -Whsa -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Winit-self -Wint-conversion -Wint-to-pointer-cast -Winvalid-memory-model
-Winvalid-pch -Wjump-misses-init -Wlogical-not-parentheses -Wmain
-Wmaybe-uninitialized -Wmemset-transposed-args -Wmisleading-indentation
-Wmissing-braces -Wmissing-declarations -Wmissing-include-dirs
-Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing -Wnonnull
-Wnonnull-compare -Wnull-dereference -Wold-style-declaration
-Wold-style-definition -Woverflow -Woverlength-strings -Woverride-init -Wpacked
-Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign
-Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type
-Wscalar-storage-order -Wsequence-point -Wshift-count-negative
-Wshift-count-overflow -Wshift-negative-value -Wsizeof-array-argument
-Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes
-Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-final-methods
-Wsuggest-final-types -Wswitch-bool -Wtautological-compare -Wtrampolines
-Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations
-Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function
-Wunused-label -Wunused-local-typedefs -Wunused-result -Wunused-value
-Wunused-variable -Wvarargs -Wvariadic-macros -Wvector-operation-performance
-Wvolatile-register-var -Wwrite-strings -Warray-bounds=2 -Wnormalized=nfc
-Wshift-overflow=2 -Wunused-const-variable=2 -Wno-missing-field-initializers
-Wno-sign-compare -Wno-type-limits -Wno-switch -Wno-unused-parameter
-Wno-format-nonliteral -Wno-logical-op -Wnonportable-cfstrings
-Wstrict-overflow=1 -Wdeclaration-after-statement -Wmissing-noreturn
-Wunreachable-code -Woverride-init-side-effects -Wshift-overflow=2
-Wdangling-else -Wduplicate-decl-specifier -Wmemset-elt-size
-Wswitch-unreachable -Wimplicit-fallthrough -Wformat-overflow=2
-Wformat-truncation=2 -Wstringop-overflow=2 -Wexpansion-to-defined -Wrestrict
-Wint-in-bool-context -Wpointer-compare -Wbool-operation -Wduplicated-branches
-Walloca-larger-than=16384 -Wvla-larger-than=16384
-Walloc-size-larger-than=32767 -Walloc-zero -Wpsabi
-Wbuiltin-declaration-mismatch   -ggdb3 -Og -gdwarf-2 -gfull -mfix-and-continue
-MT sha256.o -MD -MP -MF .deps/sha256.Tpo -c -o sha256.o sha256.c
sha256.c: In function 'sha256_stream':
sha256.c:181:9: warning: argument 1 value '32840' exceeds maximum object size
32767 [-Walloc-size-larger-than=]
   char *buffer = malloc (BLOCKSIZE + 72);
 ^~
In file included from ./stdlib.h:36:0,
 from ../src/conf_post.h:226,
 from ../src/config.h:3616,
 from sha256.c:23:
/usr/include/stdlib.h:169:7: note: in a call to allocation function 'malloc'
declared here
 void *malloc(size_t);
   ^~
sha256.c: In function 'sha224_stream':
sha256.c:252:9: internal compiler error: tree check: expected tree that
contains 'typed' structure, have 'block' in extended_tree, at tree.h:5286
   char *buffer = malloc (BLOCKSIZE + 72);
 ^~

sha256.c:252:9: internal compiler error: Abort trap
gcc: internal compiler error: Abort trap (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [sha256.o] Error 4


Interestingly, the ICE seems to go away when I try to save the preprocessed
source 

[Bug c++/79433] __has_include reports wrong result for std headers that #error on __cplusplus

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
(In reply to Marc Mutz from comment #5)
> Andrew, you're taking the easy way out. It might be that it works as
> implemented, but that behaviour is useless.
> 
> Please explain how one should detect, in a portable way, whether string_view
> and experimental::string_view is available, if not by headers check.

Do an autoconf test for it, AC_CHECK_HEADERS tests whether including the header
actually compiles.

[Bug debug/42065] DWARF .debug_macinfo contains unused macros

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #4 from Eric Gallager  ---
If -feliminate-unused-debug-symbols and/or -feliminate-unused-debug-types start
removing these, I'd want them to turn on -Wunused-macros automatically for me
as well so I can know about it

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #10 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Matt Clarkson from comment #2)
> > Because wehen I compile with clang against the libstdc++ the problem will
> > still occur and __GNUC__ will not be defined.
> 
> N.B. Clang does define __GNUC__ but it always defines it to 4 (and defines
> __GNUC_MINOR__ to 1 and __GNUC_PATCHLEVEL__ to 2, because it identifies as
> GCC 4.1.2, the last release Apple shipped for their OS).

__GNUC_MINOR__ and __GNUC_PATCHLEVEL__ values are swapped with each other
there; last release Apple shipped for their OS was 4.2.1, not 4.1.2

[Bug c++/79078] Warnings from deprecated attribute are too noisy

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79078

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #7 from Eric Gallager  ---
Another way to make deprecation warnings less noisy would be to split
-Wdeprecated-declarations into separate individually controllable flags, for
example, one that only warns about where the "deprecated" attribute is used
with the optional string following it. It could be called
-Wdeprecated-declarations-with-reasons or something, and then it'd make it
easier just to focus on the deprecated things for which there are replacements.
Another way to split it up would be by whether it's deprecated with the
C++-style attribute [-Wc++-deprecated-declarations] or a GNU-style attribute
[-Wgnu-deprecated-declarations]. Just focusing on one or the other might be
easier than trying to deal with warnings from each at the same time. Then
there's also splitting it by the kind of declaration, similar to how -Wunused
is an umbrella warning for several other more specific flags.

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jeffrey Walton from comment #0)
> > test.cxx:53:21: error: 'llrint' was not declared in this scope
> >llrint(0.0);
> >  ^
> > test.cxx:54:23: error: 'llrintf' was not declared in this scope
> >llrintf(0.0f);
> >^
> > test.cxx:55:23: error: 'llrintl' was not declared in this scope
> >llrintl(0.0l);
> >^
> > test.cxx:56:22: error: 'llround' was not declared in this scope
> >llround(0.0);
> >   ^
> > test.cxx:57:24: error: 'llroundf' was not declared in this scope
> >llroundf(0.0f);
> > ^
> > test.cxx:58:24: error: 'llroundl' was not declared in this scope
> >llroundl(0.0l);
> > ^
> 
> Because these six functions are missing we treat all C99 math functions as
> missing. We could split the checks into two pieces, so we check for these
> separately, which would allow the rest of the C99 math library to be
> imported into namespace std.
> 
> But OS X 10.5.8 is pretty old, and this might not be worth doing if it
> doesn't affect current versions of OS x.

10.5.8 is what I'm still on, too. Iain Sandoe has been committing patches
targeting 10.4 and 10.5 recently, as well. I'd say it's worth doing.

[Bug middle-end/71905] bogus -Wlarger-than=N and -Wframe-larger-than= -Wstack-usage= warnings on small objects with large N

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71905

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> To get around the INT_MAX limit the -Walloc-size-larger-than accepts numbers
> with suffixes like KB and MB.  Other options that accept sizes should
> probably accept the same suffixes for consistency.

[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767

--- Comment #11 from Eric Gallager  ---
Thank you for adding this!

[Bug driver/78772] -fstrict-aliasing should turn on Wstrict-aliasing automaticly

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78772

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
(In reply to Markus Trippelsdorf from comment #5)
> 
> These optimizations are not dangerous if you use standard conforming code.
> 

Many people don't though. Which is why this warning exists in the first place.

[Bug preprocessor/78680] [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78680

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #4 from Eric Gallager  ---
I'm running into this issue, too, with a different source file, but the line
number at input.c is 1388 instead of 1398. Should I open a separate bug?

[Bug c/61593] Support '#pragma mark - foo' (by simply ignoring it without warning)

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61593

--- Comment #1 from Eric Gallager  ---
The gcc documentation says pragma mark should be accepted:
https://gcc.gnu.org/onlinedocs/gcc/Darwin-Pragmas.html#Darwin-Pragmas

[Bug c++/62182] New warning wished: operator== and "equality comparison result unused [-Wunused-comparison]"/-Wunsed-value

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62182

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
I think this is a duplicate of bug 53598

[Bug other/65254] libiberty produces using extended field designator is an extension warnings in clang

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65254

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
(In reply to Jack Howarth from comment #0)
> The simple-object-xcoff.c file in libiberty produces a number of warnings of
> the form...
> 
> ./../../gcc-5-20150228/libiberty/simple-object-xcoff.c:330:12: warning:
> using extended field designator is an extension [-Wextended-offsetof]
>   + offsetof (struct external_filehdr,
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.
> xctoolchain/usr/bin/../lib/clang/6.0/include/stddef.h:87:24: note: expanded
> from macro
>   'offsetof'
> #define offsetof(t, d) __builtin_offsetof(t, d)
>^
> 
> under the clang compiler as "offsetof(T, field,subfield)" and "offsetof(T,
> arr[3])" are C/C++ extensions and only "offsetof(T, field)" is standard.
> Shouldn't these be recoded to use the standard form?

Furthermore, it'd be a good idea if gcc supported the -Wextended-offsetof flag,
too, like clang does.

[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64767

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #8 from Eric Gallager  ---
(In reply to Marek Polacek from comment #7)
> This code is now rejected in C++11.  See r240707.

What about in other standards? gcc built at the end of November still seems to
reject the -Wpointer-compare flag that I thought was going to be added for
this:

$ /usr/local/bin/gcc -Wpointer-compare randomer.c
gcc: error: unrecognized command line option ‘-Wpointer-compare’; did you mean
‘-Wnonnull-compare’?

[Bug libobjc/78698] [7 regression] Using static PIC libgc fails when it has dependencies

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78698

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Matthias Klose from comment #1)
> didn't check a configuration with --disable-shared :-/  What about checking
> for a $bdw_lib_dir/libgc.la and in that case setting BDW_GC_LIBS to
> $bdw_lib_dir/libgc.la and skipping the compile and link tests? I assume we
> could do a file check for the header file as well for this case.
> 
> --- configure.ac  (revision 243108)
> +++ configure.ac  (working copy)
> @@ -290,10 +293,19 @@
>AC_MSG_ERROR([no multilib path ($mldir) found in
> --with-target-bdw-gc-lib])
>  fi
>  BDW_GC_CFLAGS="-I$bdw_inc_dir"
> -BDW_GC_LIBS="-L$bdw_lib_dir -lgc"
> +if test -f $bdw_lib_dir/libgc.la; then
> +  BDW_GC_LIBS="$bdw_lib_dir/libgc.la"
> +else
> +  BDW_GC_LIBS="-L$bdw_lib_dir -lgc"
> +fi
>  AC_MSG_RESULT([found])
>fi
>  
> +  case "$BDW_GC_LIBS" in
> +  *libgc.la)
> +use_bdw_gc=yes
> +;;
> +  *)
>AC_MSG_CHECKING([for system boehm-gc])
>save_CFLAGS=$CFLAGS
>save_LIBS=$LIBS
> @@ -329,6 +341,7 @@
>  use_bdw_gc=yes
>  AC_MSG_RESULT([found])
>fi
> +  esac
>  esac
>  
>  if test "$use_bdw_gc" = no; then

Note that some package managers automatically delete .la files as part of the
installation process. I suppose it'd just fall through to the compile-and-link
tests in that case, though, which might still work...

[Bug bootstrap/78616] [7 regression] bootstrap fails for x86_64-darwin at stage1 after 243030 when the bootstrap compiler doesn't have strndup

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78616

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #11 from Eric Gallager  ---
(In reply to David Malcolm from comment #10)
> Build breakage should have been fixed as of r243207 (sorry again).
> 
> Should we poision strndup in system.h?

I think so, I meant to ask that last time this happened in bug 67363 but never
got around to it.

[Bug c/78380] GCC crash with internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78380

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
(In reply to Elmar from comment #0)
> Created attachment 40057 [details]
> Preprocessed source file
> 
> Dear GCC team,
> 
> I encountered this crash when compiling for MacOSX, either directly in
> MacOSX (precompiled GCC 6.2.0 downloaded from hpc.sourceforge.net) or when
> cross-compiling from Linux (GCC 6.2.0 compiled using
> https://github.com/tpoechtrager/osxcross scripts)
> 
> The bug database found three possibly related bugs, but in emit-rtl.c line
> 1027, not line 1025 like mine:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70420
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68538
> 

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009 might also be related

[Bug target/68538] ICE in gen_reg_rtx, at emit-rtl.c:1027 when cross-compiling for cris-linux-gnu target

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68538

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #4 from Eric Gallager  ---
After seeing this report, I'm realizing that Bug 71009 which I filed might be a
duplicate of this one; it's also an ICE at the same place in emit-rtl.c for the
same reason of can_create_pseudo_p having an issue. It's just for a different
target though.

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
I can confirm it only happens with the -Og optimization level; I also tested
-Ofast and -Os, and neither of those triggered it either.

gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Og maybe_uninit_00.cpp
maybe_uninit_00.cpp: In function ‘float foo()’:
maybe_uninit_00.cpp:19:17: warning: ‘vy’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 return vx + vy;
 ^~
maybe_uninit_00.cpp:19:17: warning: ‘vx’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O1 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O2 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O3 maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os maybe_uninit_00.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -O0 -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Og maybe_uninit_01.cpp
maybe_uninit_01.cpp: In function ‘float foo()’:
maybe_uninit_01.cpp:19:17: warning: ‘vy’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 return vx + vy;
 ^~
maybe_uninit_01.cpp:19:17: warning: ‘vx’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Ofast -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -Wall -Wextra -pedantic -Wmaybe-uninitialized
-Weffc++ -Winline -Wfloat-conversion -c -Os -g maybe_uninit_01.cpp
gcc_bugs root$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --enable-objc-gc --disable-host-shared
--enable-maintainer-mode --disable-default-pie --with-ld64 --without-pic
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 7.0.0 20161027 (experimental) (GCC)

[Bug c/78359] Redeclaration of global variables is not reported

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78359

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to hugo74 from comment #2)
> > It should not work that way. I checked it in other C compilers and each of
> > them reports an redefinition error in such case.
> 
> Are you sure they were C compilers and not C++ compilers?
> 
> C and C++ differ here.

Hence -Wc++-compat gets the warning desired:

$ /usr/local/bin/gcc -Wall -Wextra -pedantic -Wredundant-decls -Wc++-compat
-fno-common -c pr78359.c
pr78359.c:1:14: warning: duplicate declaration of ‘Counter’ is invalid in C++
[-Wc++-compat]
 int Counter, Counter, Counter;
  ^~~
pr78359.c:1:5: note: previous declaration of ‘Counter’ was here
 int Counter, Counter, Counter;
 ^~~
pr78359.c:1:23: warning: duplicate declaration of ‘Counter’ is invalid in C++
[-Wc++-compat]
 int Counter, Counter, Counter;
   ^~~
pr78359.c:1:14: note: previous declaration of ‘Counter’ was here
 int Counter, Counter, Counter;
  ^~~

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267

--- Comment #34 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #23)
> (In reply to Eric Gallager from comment #22)
> > 
> > To be specific, they're not supported by the FSF release of GCC. Apple's
> > fork of GCC supported blocks back before they ditched it for clang, so this
> > isn't just a clang extension.
> 
> Apple's blocks implementation was never submitted "upstream" is my
> understanding, it's not present in any branch on an FSF server (and thus we
> can't use it, even if it were usable 4.2 => 7.0, which it isn't without
> significant re-work).
> 
> (Let's not side-track this PR - perhaps we should just file one to cover
> missing blocks support, 63651 already discusses two different problems).

I opened bug 78352 for missing blocks support.

[Bug c/78352] New: GCC lacks support for the Apple "blocks" extension to the C family of languages

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352

Bug ID: 78352
   Summary: GCC lacks support for the Apple "blocks" extension to
the C family of languages
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---

In bug 78267 Iain suggested to open a separate bug for the issue of missing
Apple-blocks support in FSF GCC, so that's what this bug is. Here is an example
of code that is currently rejected due to lack of support for this feature:

typedef void (^os_trace_payload_t)(xpc_object_t xdict);

In Apple's gcc and clang, support for blocks can be enabled with the -fblocks
flag, and can be detected by the presence of the __BLOCKS__ preprocessor macro.
This extension applies to all members of the C family: C, C++, Objective C, and
Objective C++. 

Further information:
https://gcc.gnu.org/ml/gcc/2009-09/msg00277.html (and the rest of the thread)
https://gcc.gnu.org/ml/gcc/2013-11/msg00039.html (likewise, & rest of thread)
Bug 63651
http://clang.llvm.org/docs/BlockLanguageSpec.html
http://clang.llvm.org/docs/Block-ABI-Apple.html
http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1370.pdf
https://en.wikipedia.org/wiki/Blocks_%28C_language_extension%29

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #22 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Maxim Ostapenko from comment #1)
> > Eh, mine.
> > 
> > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange,
> > it seems that it's an Objective-C declaration, right?
> 
> It's declaring os_trace_payload_t to of type "Apple block" (like a lambda
> that can be used over the whole of c-family);  Apple blocks are currently
> not supported by GCC.  There is no realistic work-around, any interface
> using blocks will fail, and thus either those interfaces need to be excluded
> from tests, or the tests skipped/xfailed.
>

To be specific, they're not supported by the FSF release of GCC. Apple's fork
of GCC supported blocks back before they ditched it for clang, so this isn't
just a clang extension. Bug 63651 has more stuff about support for blocks in
FSF GCC.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097

--- Comment #12 from Eric Gallager  ---
GCJ has been removed from GCC 7. But on the other hand this isn't really so
much a java bug itself as it is an unwinding bug that java just happened to be
the one to tickle. So is it worth keeping this bug open?

[Bug classpath/29304] autoconf should be used in libjava to check for fabs, fabsf and scalbn

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29304

--- Comment #2 from Eric Gallager  ---
GCJ has been removed from GCC 7. So "wontfix"?

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #38 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #34)
> (In reply to Eric Gallager from comment #33)
> > I'm not sure if this is due to the patches from this bug report, or if it's
> > due to some other change made to GCC recently, but my fork of Emacs now
> > fails to build with LTO due to a bunch of undefined local symbols:
> 
> honestly, rather hard to tell from the info given, please can you identify
> what you've built (and what version) and on what Darwin etc.

$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --enable-objc-gc --enable-host-shared
--enable-maintainer-mode --with-ld64 CC=/usr/local/bin/gcc
CXX=/usr/local/bin/g++ : (reconfigured) ../configure --disable-werror
--disable-werror-always --enable-languages=c,c++,lto,objc,obj-c++
--enable-stage1-checking=release -C --with-system-libunwind --enable-secureplt
--enable-frame-pointer --enable-debug --with-isl --enable-objc-gc
--enable-host-shared --enable-maintainer-mode --with-ld64 CC=/usr/local/bin/gcc
CXX=/usr/local/bin/g++
Thread model: posix
gcc version 7.0.0 20161005 (experimental) (GCC) 

$ uname -a
Darwin ian-gallagers-macbook.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul
15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

There were also a bunch of -Wlto-type-mismatch warnings when linking, but they
were there before, so I trimmed them off.

> 
> > I was figuring it might have something to do with this patch because this
> > patch messed with the "L_" prefixing of symbols. GCC's LTO worked with my
> > fork of Emacs a few months ago.
> 
> yeah, it's possible - although if you look at the logic that adds the "L"
> onto objc local syms it wasn't touched (and they shouldn't pass equality
> test with "LC" either).
> 
> Can you find any reproducer smaller than "emacs" ? 
> 
> I have a current build of 241437 under test with rebased patches and it
> doesn't show this in the LTO tests in the test-suite.  However it might be
> being hidden by some other error.  [I'll re-test with my work-around for
> instancetype applied].

(In reply to Jack Howarth from comment #35)
> (In reply to Eric Gallager from comment #33)
> > I'm not sure if this is due to the patches from this bug report, or if it's
> > due to some other change made to GCC recently, but my fork of Emacs now
> > fails to build with LTO due to a bunch of undefined local symbols:
> 
> Did you actually add the patches for this bug report to your local gcc
> build? The patches haven't been posted to gcc-patches yet or committed into
> trunk.

Yes, I did, I posted test results with them above in this bug, too. I had also
applied a few other patches from gcc-patches that hadn't been committed to
trunk yet. This actually caused a conflict with the patch from this bug that
touched the gcc subdirectory's configure script, so I had to regenerate that
manually.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #33 from Eric Gallager  ---
I'm not sure if this is due to the patches from this bug report, or if it's due
to some other change made to GCC recently, but my fork of Emacs now fails to
build with LTO due to a bunch of undefined local symbols:

/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_toggleFullScreen$.lto_priv.1027
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_window.lto_priv.394
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_setFSValue$.lto_priv.1033
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_fsIsNative.lto_priv.1034
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_windowDidBecomeKey$.lto_priv.1035
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_ClassRefs_4.lto_priv.333
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_deleteWorkingText.lto_priv.1043
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_frame.lto_priv.350
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_windowWillResize$toSize$.lto_priv.1039
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_screens.lto_priv.474
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_ClassRefs_8.lto_priv.431
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_objectAtIndex$.lto_priv.358
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_mouseMoved$.lto_priv.1048
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_mouseDown$.lto_priv.1051
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_isFullscreen.lto_priv.1046
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_toolbar.lto_priv.434
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_retain.lto_priv.405
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_release.lto_priv.312
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_subviews.lto_priv.1056
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_count.lto_priv.355
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_class.lto_priv.440
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_ClassRefs_15.lto_priv.391
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_isKindOfClass$.lto_priv.442
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_condemn.lto_priv.1059
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_judge.lto_priv.1057
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_updateFrameSize$.lto_priv.1032
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_display.lto_priv.399
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_Class_EmacsView.lto_priv.1044
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_viewDidEndLiveResize.lto_priv.1045
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_stringWithUTF8String$.lto_priv.323
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_ClassRefs_3.lto_priv.285
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_dealloc.lto_priv.367
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_modifierFlags.lto_priv.472
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_keyDown$.lto_priv.464
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_visibleRect.lto_priv.1053
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_setOnMouseEntered$.lto_priv.1055
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_arrowCursor.lto_priv.480
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_ClassRefs_27.lto_priv.1052
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_addCursorRect$cursor$.lto_priv.1054
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_UTF8String.lto_priv.294
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_objectEnumerator.lto_priv.304
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_nextObject.lto_priv.308
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_isEqualToString$.lto_priv.316
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_invalidate.lto_priv.331
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_ClassRefs_17.lto_priv.374
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_context.lto_priv.336
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_windowNumber.lto_priv.341
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_contentView.lto_priv.353
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_windowWillExitFullScreen$.lto_priv.1030
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_windowDidExitFullScreen$.lto_priv.1031
/var/tmp//ccaoPXbR.s:unknown:Undefined local symbol
L_OBJC_SelRef_windowWillEnterFullScreen$.lto_priv.1028

[Bug c/77965] -Wduplicated-cond should find duplicated condition / identical expressions of form "a || a" or "a && a"

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77965

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
Use -Wlogical-op:

$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic -Wlogical-op -Wduplicated-cond
-Wtautological-compare logical_op.c 
logical_op.c: In function ‘foo’:
logical_op.c:5:17: warning: logical ‘or’ of equal expressions [-Wlogical-op]
  return (x == 5 || x == 5) ? 1 : 0;
 ^~

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #29 from Eric Gallager  ---
I tried testing this patchset on i386-apple-darwin9.8.0, but I think something
went wrong with the parallelism in the testsuite (I did `make -j2 check-gcc
RUNTESTFLAGS="-v -v"`), and I ended up having to restart my computer... but
anyways, the results are here:
https://gcc.gnu.org/ml/gcc-testresults/2016-10/msg00537.html
I think the failures are mostly unrelated...

[Bug go/77861] GO and Mac OS X : configure impossible

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77861

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
Duplicate of Bug 46986

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #8 from Eric Gallager  ---
I reduced the command line required to trigger the ICE. It depends on whether
-fmath-errno is set or not. With:

$ /usr/local/bin/gcc -c -Ofast -I. -I../include -DHAVE_CONFIG_H -I../bfd
-Imacosx -Iconfig -Wno-deprecated-declarations -fno-math-errno valarith.c

...it ICEs as it did previously, but with:

$ /usr/local/bin/gcc -c -Ofast -I. -I../include -DHAVE_CONFIG_H -I../bfd
-Imacosx -Iconfig -Wno-deprecated-declarations -fmath-errno valarith.c

...it compiles successfully. That could explain why it wouldn't reproduce on
x86_64-linux-gnu, as I believe the default for -fmath-errno is different
between Darwin and GNU/Linux.

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #15 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Eric Gallager from comment #6)
> > This should probably depend on the -fstrict-enums flag, as that controls
> > whether enums can have any value or just those values that are enumerated.
> 
> No, that's not what it does.
> 
> It tells the compiler the enum will only be one of the values of the
> enumeration, which is not the same as the values corresponding to
> enumerators.
>


That's a confusing distinction; they sound like the same thing at first to
someone like me who doesn't speak standards-ese...


> 
> As I said in comment 3, the OP's type has the values of int, because it has
> an underlying type of int.
> 
> Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> -fstrict-enums tells the compiler it will never have a value outside that
> range. It does **not** tell it that the type will never have the value 0 or
> 2.


Thanks, that example helps clear things up. Could it be added to the
documentation for -fstrict-enums?

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

--- Comment #14 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #9)
> In summary, neither adding 'default' or 'return' are recommended to silence
> this warning if you think the warning is wrong. If you think the warning
> will always be wrong, use __builtin_unreachable(). If you think it is wrong
> now, but you would like to notice if it stops being wrong, then use
> assert(false).


This is probably an issue for a separate bug, but speaking of
__builtin_unreachable(), now that GCC is going to start recognizing the
lint-style comment of:
/* FALLTHROUGH */
for the benefit of -Wimplicit-fallthrough, could it also start recognizing the
lint-style comment of:
/* NOTREACHED */
as a synonym for __builtin_unreachable()? I've seen comments like that in a lot
of code, actually, and it'd be a more portable solution than
__builtin_unreachable().

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
This should probably depend on the -fstrict-enums flag, as that controls
whether enums can have any value or just those values that are enumerated.

[Bug c++/77431] warn for having the same code in if-else branches

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77431

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Marek Polacek from comment #1)
> Mine.  Any ideas for the name?

-Wduplicated-cond-body? Enabled by -Wduplicated-cond.
-Wduplicated-branches?
-Wredundant-branch?

[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #8 from Eric Gallager  ---
As a user, I'd prefer warning about the missing parentheses instead of the
boolean context thing, the missing parentheses make a lot more sense to me and
it'd be easier for me to understand how to fix it, whereas the boolean context
one is a bit more confusing.

[Bug c++/77449] False ambiguity for variadic function with non-deduced template parameter

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77449

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
The full error message is:

$ /usr/local/bin/g++ -c -Wall -Wextra pr77449.cc
pr77449.cc: In function ‘int main()’:
pr77449.cc:11:17: error: call of overloaded ‘bar(int, const char [1])’ is
ambiguous
  bar(7, ""); // ambiguous according to gcc
 ^
pr77449.cc:4:6: note: candidate: void bar(Check, T ...) [with X = void; Check =
int; T = {const char*}]
 auto bar(Check, T...) -> void;
  ^~~
pr77449.cc:7:6: note: candidate: void bar(int, T ...) [with X = void; T =
{const char*}]
 auto bar(int, T...) -> void;
  ^~~

As a human reader who doesn't know C++ very well I'd consider it to be
ambiguous, too... maybe as a compromise the error could be downgraded to a
warning?

[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #8 from Eric Gallager  ---
Turns out there's actually an entire Wikipedia article on this issue:
https://en.wikipedia.org/wiki/Most_vexing_parse
It mentions that Scott Meyers talks about it in his "Effective STL" book, so
maybe if GCC adds a -Wvexing-parse option, it could have it be automatically
enabled by the -Weffc++ option.

[Bug web/69601] current/ redirect is off by at least a day

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601

--- Comment #6 from Eric Gallager  ---
Seems to be fixed for September.

[Bug objc/77404] Add Wobjc-root-class

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
(In reply to Tom de Vries from comment #0)
> clang supports:
> - the objc_root_class attribute, and 
> - a warning Wobjc-root-class that warns if a class both:
>   - does not have a superclass, and
>   - does not have the objc_root_class attribute
> 
> gcc:
> - does not support the -Wobjc-root-class warning, and 
> - when encountering the objc_root_class attribute, gives an unsupported
>   attribute warning.
> 
> Is the -Wobjc-root-class warning something we want to have in gcc objc as
> well?


What's the reasoning behind clang having it? Do you have any links to
documentation of the warning?

[Bug c++/69818] warn for C++ functional cast expression on pointer or reference

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69818

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #5 from Eric Gallager  ---
Personally I'd prefer a separate option, -Wfunctional-cast or something, as
functional casts and "old-style" casts are different things. I generally avoid
-Wold-style-cast currently, as it is often pretty noisy in code that started
off written as C and was then converted to C++, but I'd consider using a
separate -Wfunctional-cast, as that would catch just things added
post-C++-conversion, which means it would probably be significantly less noisy,
and easier to fix.

[Bug c/53129] Wself-assign

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53129

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
I'd like to see this warning added, too... can I mark this as confirmed?

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #7 from Eric Gallager  ---
Created attachment 39089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39089=edit
some compressed compiler output

Still happens with trunk from the end of July. I tried playing around with some
of the developer options to generate some dumpfiles, but there's too many of
them, and when I group them into folders, the archives are too big to upload
even after compressing them, so I'm not really sure what to upload, besides the
attached tempfiles.

Current version info:
$ /usr/local/bin/g++ -march=native -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --enable-objc-gc --enable-host-shared
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
Thread model: posix
gcc version 7.0.0 20160730 (experimental) (GCC)

[Bug web/69601] current/ redirect is off by at least a day

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #5 from Eric Gallager  ---
(In reply to Joost VandeVondele from comment #4)
> and also in July...

...and in August...

[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63886

--- Comment #11 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to Eric Gallager from comment #8)
> > (In reply to Andreas Schwab from comment #4)
> > > float f = 3.1f;
> > 
> > Isn't there already -Wunsuffixed-float-constants for warnings with that kind
> > of fix?
> 
> -Wfloat-conversion is not warning about the lack of suffix, but about the
> fact that 3.1 does not fit into a double (3.5 does, so there is no warning).
> 
> float f;
> double d;
> 
> f = 3.100088817841970012523233890533447265625; // 
> -Wfloat-conversion -Wunsuffixed-float-constants
> d = 3.100088817841970012523233890533447265625; //
> -Wunsuffixed-float-constants (not sure why!)
> f = 3.5; // -Wunsuffixed-float-constants 
> d = 3.5; // -Wunsuffixed-float-constants (not sure why!)
> f = 3.1f; // no warning
> d = 3.1f; // no warning

About the ones where you wrote "(not sure why!)", it's asking the programmer to
add the nonstandard "d" suffix, which is a GNU extension. This has led projects
to ignore the warning:
https://lists.gnu.org/archive/html/bug-gzip/2011-11/msg00017.html
But I suppose that's an issue for a separate bug.

[Bug other/31233] obstack.h typo

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31233

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #3 from Eric Gallager  ---
(In reply to Jim Wilson from comment #2)
> In theory, obstack.h is imported from the FSF gnulib package, though
> unfortunately that isn't documented in our codingconventions.html web page,
> and it looks like people have just been modifying it in place.  The parent
> package is here
> http://savannah.gnu.org/projects/gnulib#options
> 
> Looking at the cvs history, it looks like this was broken in revision 1.24
> and fixed in revision 1.32, so we should be able to import a fixed version
> of this file to fix this bug report.
> 
> Except that we will have to deal with local changes somehow.  They really
> should be pushed to the FSF is they aren't already there.

Has it been resynced as part of the "Replace libiberty with gnulib" GSoC
project yet?

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #6 from Eric Gallager  ---
I investigated more. What's happening at ../../gcc/emit-rtl.c:1025 is that the
following assert is failing:

  gcc_assert (can_create_pseudo_p ());

This fails if and only if gen_reg_rtx is passed V2DImode as its mode parameter.
I tried editing emit-rtl.c to make the assert conditional, like this:

  if (mode != V2DImode)
gcc_assert (can_create_pseudo_p ());

...but that only resulted in a different error:

valarith.c: In function ‘value* value_binop(value*, value*, exp_opcode)’:
valarith.c:1408:1: error: insn does not satisfy its constraints:
(insn 3157 1585 3158 192 (set (reg:V2DI 1029)
(vec_concat:V2DI (mem/c:DI (reg/f:SI 7 sp) [50 %sfp+-64 S8 A128])
(const_int 0 [0]))) valarith.c:1180 3653 {vec_concatv2di}
 (nil))

Breakpoint 1, internal_error (gmsgid=0x15ee807 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1337
1337  va_start (ap, gmsgid);

Any ideas what's going on?

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #5 from Eric Gallager  ---
I rebuilt with debugging info and got a better backtrace:

Breakpoint 1, internal_error (gmsgid=0x15ee807 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1337
1337  va_start (ap, gmsgid);
(gdb) bt
#0  internal_error (gmsgid=0x15ee807 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1337
#1  0x01266866 in fancy_abort (file=0x157ccd5 "../../gcc/emit-rtl.c",
line=1025, function=0x190cd98 "gen_reg_rtx") at ../../gcc/diagnostic.c:1405
#2  0x00945479 in gen_reg_rtx (mode=V2DImode) at ../../gcc/emit-rtl.c:1025
#3  0x00579f86 in gen_split_349 (curr_insn=0x325acf0, operands=0x1ff95c0) at
../../gcc/config/i386/sse.md:1129
#4  0x0076bb58 in split_8 (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:1115
#5  0x00778c75 in split_insns (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:13387
#6  0x0094b3e4 in try_split (pat=0x3255ce4, trial=0x325acf0, last=1) at
../../gcc/emit-rtl.c:3658
#7  0x00d4a502 in split_insn (insn=0x325acf0) at ../../gcc/recog.c:2887
#8  0x00d4a7c5 in split_all_insns () at ../../gcc/recog.c:2977
#9  0x00d4c34b in rest_of_handle_split_after_reload () at
../../gcc/recog.c:3913
#10 0x00d4c389 in (anonymous namespace)::pass_split_after_reload::execute
(this=0x50d0e190) at ../../gcc/recog.c:3942
#11 0x00d12144 in execute_one_pass (pass=0x50d0e190) at ../../gcc/passes.c:2344
#12 0x00d12495 in execute_pass_list_1 (pass=0x50d0e190) at
../../gcc/passes.c:2428
#13 0x00d124c5 in execute_pass_list_1 (pass=0x50d0e0d0) at
../../gcc/passes.c:2429
#14 0x00d124c5 in execute_pass_list_1 (pass=0x50d0d590) at
../../gcc/passes.c:2429
#15 0x00d12515 in execute_pass_list (fn=0x2b35bb8, pass=0x50d0b190) at
../../gcc/passes.c:2439
#16 0x008539ee in cgraph_node::expand (this=0x2d4b424) at
../../gcc/cgraphunit.c:1983
#17 0x00853fff in expand_all_functions () at ../../gcc/cgraphunit.c:2119
#18 0x00854c8b in symbol_table::compile (this=0x50e0b000) at
../../gcc/cgraphunit.c:2475
#19 0x00854ed1 in symbol_table::finalize_compilation_unit (this=0x50e0b000) at
../../gcc/cgraphunit.c:2565
#20 0x00e246cd in compile_file () at ../../gcc/toplev.c:490
#21 0x00e26f70 in do_compile () at ../../gcc/toplev.c:1998
#22 0x00e27332 in toplev::main (this=0xbfff94de, argc=140, argv=0xbfff9510) at
../../gcc/toplev.c:2132
#23 0x0124f80f in main (argc=140, argv=0xbfff9510) at ../../gcc/main.c:39
Current language:  auto; currently c++
(gdb) bt full
#0  internal_error (gmsgid=0x15ee807 "in %s, at %s:%d") at
../../gcc/diagnostic.c:1337
ap = 0x0
richloc = {
  static MAX_RANGES = , 
  static MAX_FIXIT_HINTS = , 
  m_num_ranges = 0, 
  m_ranges = {{
  m_loc = 33527040, 
  m_show_caret_p = 204
}, {
  m_loc = 0, 
  m_show_caret_p = false
}, {
  m_loc = 0, 
  m_show_caret_p = true
}}, 
  m_column_override = 0, 
  m_have_expanded_location = 104, 
  m_expanded_location = {
file = 0xd47953 "??\020\017U???\030?x?\001\002??u2?E\b\017?", 
line = 18, 
column = 1356874188, 
data = 0x0, 
sysp = false
  }, 
  m_num_fixit_hints = 18, 
  m_fixit_hints = {0x50e041cc, 0x0}
}
__FUNCTION__ = "internal_error"
#1  0x01266866 in fancy_abort (file=0x157ccd5 "../../gcc/emit-rtl.c",
line=1025, function=0x190cd98 "gen_reg_rtx") at ../../gcc/diagnostic.c:1405
No locals.
#2  0x00945479 in gen_reg_rtx (mode=V2DImode) at ../../gcc/emit-rtl.c:1025
val = (rtx) 0xd479ef
align = 128
__FUNCTION__ = "gen_reg_rtx"
#3  0x00579f86 in gen_split_349 (curr_insn=0x325acf0, operands=0x1ff95c0) at
../../gcc/config/i386/sse.md:1129
tmp = (rtx) 0x50e0e430
_val = (rtx_insn *) 0x0
__FUNCTION__ = "gen_split_349"
#4  0x0076bb58 in split_8 (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:1115
operands = (rtx * const) 0x1ff95c0
x2 = (rtx) 0x3259dd0
x3 = (rtx) 0x3259dc0
x4 = (rtx) 0x32c22f0
x5 = (rtx) 0x27c6018
x6 = (rtx) 0x0
x7 = (rtx) 0x3255ccc
x8 = (rtx) 0x3254eb0
x9 = (rtx) 0x32797e0
x10 = (rtx) 0x0
#5  0x00778c75 in split_insns (x1=0x3255ce4, insn=0x325acf0) at
../../gcc/config/i386/sse.md:13387
operands = (rtx * const) 0x1ff95c0
x2 = (rtx) 0xbfff91d8
x3 = (rtx) 0xbfff922b
x4 = (rtx) 0x2d4b424
x5 = (rtx) 0x3251a28
x6 = (rtx) 0xbfff91c8
x7 = (rtx) 0x27c0cdc
x8 = (rtx) 0x325acf0
x9 = (rtx) 0xc07a4e
x10 = (rtx) 0xbfff91c8
x11 = (rtx) 0x0
x12 = (rtx) 0x3251a28
x13 = (rtx) 0x95215c
x14 = (rtx) 0xbfff91b8
x15 = (rtx) 0x27c0cdc
x16 = (rtx) 0x325ad14
x17 = (rtx) 0x9521eb
#6  0x0094b3e4 in try_split (pat=0x3255ce4, trial=0x325acf0, last=1) at
../../gcc/emit-rtl.c:3658
before = (rtx_insn *) 0x325aca8
after = (rtx_insn *) 0x325ad14
note = (rtx) 0x325aca8
seq = (rtx_insn *) 0x0
tem = (rtx_insn *) 0xbfff9248

[Bug testsuite/67905] running the libstdc++ testsuite as root removed /dev/null from my system

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67905

--- Comment #2 from Eric Gallager  ---
Created attachment 38786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38786=edit
bzipped testsuite log

It happened again with yesterday's trunk. I'm attaching the logfile this time.

[Bug c++/71456] missing -Wunused-variable on a static global initialized with another

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71456

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> (In reply to Eric Gallager from comment #2)
> > Speaking of -Wglobal-constructors, FSF GCC doesn't support this option. Is
> > there a bug open for adding it? I couldn't find one when searching.
> 
> I couldn't find it either.  It might be a useful feature to request, either
> independent of this bug, or as part of it.

Okay, I opened bug 71482 for it.

[Bug c++/71482] New: Add -Wglobal-constructors warning option

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482

Bug ID: 71482
   Summary: Add -Wglobal-constructors warning option
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---

Apple's gcc 4.2 has a warning flag called -Wglobal-constructors that they
describe in their invoke.texi like this:

@c APPLE LOCAL begin Wglobal-constructors 6324584
@item -Wglobal-constructors
@opindex Wglobal-constructors
Warn about namespace scope data that requires construction or
destruction, or functions that use the constructor attribute or the
destructor attribute.  Additionally warn if the Objective-C GNU
runtime is used to initialize various metadata.
@c APPLE LOCAL end Wglobal-constructors 6324584

In their c.opt it says:

; APPLE LOCAL begin Wglobal-constructors 6324584
Wglobal-constructors
C ObjC C++ ObjC++ Var(warn_global_constructors)
Warn when global (namespace scope) objects require runtime
construction or destruction or when functions that use attribute
constructor or destructor are used.  This is useful to help maintain
fast program startup and end times.
; APPLE LOCAL end Wglobal-constructors 6324584

Apparently this option has been carried forward to clang, as pointed out in bug
71456. It would be useful for FSF GCC to have this warning option, too.

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #3 from Eric Gallager  ---
Still happens with:

$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --without-isl --enable-objc-gc --enable-host-shared
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
Thread model: posix
gcc version 7.0.0 20160526 (experimental) (GCC) 


This time I attached gdb and got a backtrace:

(gdb) bt
#0  0x00ed6004 in internal_error ()
#1  0x00ed5040 in fancy_abort ()
#2  0x00719077 in gen_reg_rtx ()
#3  0x0048fc28 in gen_split_343 ()
#4  0x00569b62 in split_8 ()
#5  0x00720956 in try_split ()
#6  0x00a6a7be in split_insn ()
#7  0x00a6ec9a in split_all_insns ()
#8  0x00a6ecfb in (anonymous namespace)::pass_split_after_reload::execute ()
#9  0x00a3c567 in execute_one_pass ()
#10 0x00a3cb59 in execute_pass_list_1 ()
#11 0x00a3cb6c in execute_pass_list_1 ()
#12 0x00a3cb6c in execute_pass_list_1 ()
#13 0x00a3cbba in execute_pass_list ()
#14 0x0063b7d9 in cgraph_node::expand ()
#15 0x0063d244 in symbol_table::compile ()
#16 0x0063f74d in symbol_table::finalize_compilation_unit ()
#17 0x00b19b51 in compile_file ()
#18 0x0177f168 in toplev::main ()
#19 0x01780a24 in main ()

I'll have to rebuild gcc for debugging to get further info.

[Bug c++/71456] missing -Wunused-variable on a static global initialized with another

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71456

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> (Clang only diagnoses the dynamic initialization with potential side-effects
> with -Wglobal-constructors, and regardless of whether the static variable is
> used or not.)

Speaking of -Wglobal-constructors, FSF GCC doesn't support this option. Is
there a bug open for adding it? I couldn't find one when searching.

[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #12 from Eric Gallager  ---
This seems to be fixed on trunk.

[Bug c++/71283] -Wterminate is not described in "Options to Request or Suppress Warnings"

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #3 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #2)
> That is because this is C++ only option.  It is listed under
> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/C_002b_002b-Dialect-Options.
> html#C_002b_002b-Dialect-Options :
> 
> -Wno-terminate (C++ and Objective-C++ only)
> Disable the warning about a throw-expression that will immediately result in
> a call to terminate.
> 
> This is exact location for all other C++ only options are located.
> 
> So not a bug.

There are other C++-only options under "Options to Request or Suppress
Warnings".
For example:
* -Wc++11-compat
* -Wc++14-compat
* -Wconditionally-supported
* -Wno-conversion-null
* -Wzero-as-null-pointer-constant
* -Wsubobject-linkage
* -Wdelete-incomplete
* -Wuseless-cast
* -Wsized-deallocation
* -Wno-invalid-offsetof

It's kind of inconsistent whether C++-only warnings are listed here or there.

[Bug c++/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

--- Comment #1 from Eric Gallager  ---
Created attachment 38442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38442=edit
bzipped preprocessed source

[Bug c++/71009] New: g++: ICE on modified gdb/valarith.c with -Ofast

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

Bug ID: 71009
   Summary: g++: ICE on modified gdb/valarith.c with -Ofast
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Full command line and output:

$ make CFLAGS="-g3 -Ofast -force_cpusubtype_ALL -gstrict-dwarf -gdwarf-2 -gfull
-save-temps" V=1
this target, 'config.h' just makes its dep, 'stamp-h'
/usr/local/bin/g++ -g3 -Ofast -force_cpusubtype_ALL -gstrict-dwarf -gdwarf-2
-gfull -save-temps -arch i386 -DTARGET_I386 -I./macosx -I./macosx -DWITH_CFM=0
-DUSE_PTHREADS=1 -D_DARWIN_UNLIMITED_STREAMS -mmacosx-version-min=10.5  -I. -I.
-I./config -DHAVE_CONFIG_H -DHAVE_SYS_TYPES_H
-DLOCALEDIR="\"/usr/local/share/locale\""   -I./../include/opcode
-I./../readline/.. -I./../zlib -I../bfd -I./../bfd -I./../include
-I./../mmalloc -I../mmalloc -I../intl -I./../intl  -DMI_OUT=1
-I/sw/include/libxml2 -I/sw/include -D__MigTypeCheck=1 -D__DARWIN_UNIX03=1
-Wreturn-type -Wcomment -Wtrigraphs -Wparentheses -Wpointer-arith
-Wchar-subscripts -Wno-unused -Wunused-value -Wunused-label -Wunused-result
-Wunused-variable -Wunused-but-set-variable -Wunused-function -Wempty-body
-Wmissing-declarations -Wignored-qualifiers -Wmissing-format-attribute
-Waddress -Wattributes -Wswitch -Wclobbered -Wcoverage-mismatch -Wdiv-by-zero
-Wdouble-promotion -Wfree-nonheap-object -Wsign-compare -Wtype-limits
-Winvalid-memory-model -Winvalid-pch -Wmain -Wmissing-braces
-Wmissing-include-dirs -Woverflow -Woverlength-strings -Wpragmas
-Wreturn-local-addr -Wsequence-point -Wsizeof-pointer-memaccess -Wtrampolines
-Wunknown-pragmas -Wnormalized=nfkc -Wlogical-op -Wfloat-conversion
-Wmissing-field-initializers -Wno-deprecated-declarations -Wbool-compare
-Wlogical-not-parentheses -Wsizeof-array-argument -Wswitch-bool
-Wshift-count-negative -Wshift-count-overflow -Wshift-negative-value
-Wshift-overflow=2 -Wmisleading-indentation -Wlto-type-mismatch
-Wtautological-compare -Wduplicated-cond -Wwrite-strings -Wenum-compare
-Wnonnull-compare -Wabi -Wabi-tag -Woverloaded-virtual -Wsign-promo -Wodr
-Wsubobject-linkage -Wctor-dtor-privacy -Wterminate -Wc++11-compat
-Wdelete-incomplete -Wdelete-non-virtual-dtor -Winherited-variadic-ctor
-Winvalid-offsetof -Wliteral-suffix -Wnoexcept -Wnon-template-friend
-Wnon-virtual-dtor -Wreorder -Wstrict-null-sentinel -Wmultiple-inheritance
-Wvirtual-inheritance -Wpmf-conversions -Wtemplates -Wvirtual-move-assign
-Wconversion-null -Weffc++ -Wsized-deallocation -Wplacement-new=2 -fpermissive
-Wendif-labels -Wformat -Wformat-y2k -Wformat-security -Wnonnull
-Wnonportable-cfstrings -Wno-unused-const-variable -std=gnu++03 -pedantic
-Wno-long-long -Wcast-align -Wuninitialized -Winit-self -Wmissing-noreturn
-Wvolatile-register-var -Wdisabled-optimization -Winline
-Waggressive-loop-optimizations -Wvector-operation-performance
-Wmaybe-uninitialized -Wstrict-overflow=1 -fno-strict-aliasing
-Wnull-dereference -Wframe-address -Wframe-larger-than=262144
-Wlarger-than=262144 -Wsuggest-attribute=const -Warray-bounds  -Wall -Wextra
-Wno-unused-parameter  -c -o valarith.o valarith.c
valarith.c: In function ‘value* value_binop(value*, value*, exp_opcode)’:
valarith.c:1408:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [valarith.o] Error 1

The file compiles fine with all the other optimization levels I've tested
recently (-O3, -O2, -O1, -Os, -Og, -O0).

g++ version info:

$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-version-specific-runtime-libs --enable-assert --enable-fat
--enable-portable-binary --enable-browser-plugin --enable-gconf-peer
--enable-libgcj-debug --enable-gc-debug --enable-interpreter
--enable-aot-compile-rpm --enable-java-home --with-x --enable-collections
--enable-gstreamer-peer --enable-xmlj --enable-qt-peer --enable-debug
--enable-local-sockets --without-isl --enable-objc-gc --enable-maintainer-mode
--enable-host-shared CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader
AUTOM4TE=/usr/local/bin/autom4te AUTORECONF=/us

[Bug c++/71003] New: __extension__ silences pedwarn for "\e" in C but not in C++

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71003

Bug ID: 71003
   Summary: __extension__ silences pedwarn for "\e" in C but not
in C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Say I have the following file:

$ cat __extension__.c
const char *str0 = "\e";
const char *str1 = __extension__ "\e";

When I try to compile it with gcc, everything works as expected:

$ /usr/local/bin/gcc -pedantic -c __extension__.c
__extension__.c:1:20: warning: non-ISO-standard escape sequence, '\e'
 const char *str0 = "\e";
^~~~

i.e., it only warns on the string where I left off the __extension__.
However, when I try to compile it with g++, it warns on both strings:

$ /usr/local/bin/g++ -pedantic -c __extension__.c
__extension__.c:1:20: warning: non-ISO-standard escape sequence, '\e'
 const char *str0 = "\e";
^~~~
__extension__.c:2:34: warning: non-ISO-standard escape sequence, '\e'
 const char *str1 = __extension__ "\e";
  ^~~~

This behavior is inconsistent. I would expect the warning for the string with
__extension__ to be silenced in both cases, not just in C.

g++ version info:

$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-version-specific-runtime-libs --enable-assert --enable-fat
--enable-portable-binary --enable-browser-plugin --enable-gconf-peer
--enable-libgcj-debug --enable-gc-debug --enable-interpreter
--enable-aot-compile-rpm --enable-java-home --with-x --enable-collections
--enable-gstreamer-peer --enable-xmlj --enable-qt-peer --enable-debug
--enable-local-sockets --without-isl --enable-objc-gc --enable-maintainer-mode
--enable-host-shared CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader
AUTOM4TE=/usr/local/bin/autom4te AUTORECONF=/usr/local/bin/autoreconf
AUTOSCAN=/usr/local/bin/autoscan AUTOUPDATE=/usr/local/bin/autoupdate
IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 7.0.0 20160426 (experimental) (GCC)

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #15 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #6)
> Fixing this is even more unlikely than fixing PR 23608, since the latter
> only asks for constant propagation, but this one requires value range
> propagation.

That has since been closed as fixed. So are the chances of this one being fixed
next somewhat better now?

[Bug c/66773] sign-compare warning for == and != are pretty useless

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
(In reply to Andreas Schwab from comment #5)
> A cast is seldom a good solution

Well, that's the sort of solution this warning causes inexperienced programmers
who don't know any better (such as myself) to use... Maybe now that GCC has
fixits, it could suggest something better?

[Bug c/70791] -Wnested-externs prints inconsistent column number

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70791

--- Comment #4 from Eric Gallager  ---
(In reply to Marek Polacek from comment #3)
> Fixed.

Thanks for the speedy response and fix!

[Bug c/70791] New: -Wnested-externs prints inconsistent column number

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70791

Bug ID: 70791
   Summary: -Wnested-externs prints inconsistent column number
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Say I have the following file:

$ cat undeclared.c
char *foo(char *);

int bar(void) {
char *baz = foo(UNDECLARED_MACRO(""));
}

When I compile it like this, gcc says:

$ /usr/local/bin/gcc -c -Wimplicit -Wnested-externs -Wint-conversion
undeclared.c
undeclared.c: In function ‘bar’:
undeclared.c:4:18: warning: implicit declaration of function ‘UNDECLARED_MACRO’
[-Wimplicit-function-declaration]
  char *baz = foo(UNDECLARED_MACRO(""));
  ^
undeclared.c:4:2: warning: nested extern declaration of ‘UNDECLARED_MACRO’
[-Wnested-externs]
  char *baz = foo(UNDECLARED_MACRO(""));
  ^
undeclared.c:4:18: warning: passing argument 1 of ‘foo’ makes pointer from
integer without a cast [-Wint-conversion]
  char *baz = foo(UNDECLARED_MACRO(""));
  ^
undeclared.c:1:7: note: expected ‘char *’ but argument is of type ‘int’
 char *foo(char *);
   ^

I would expect the warning from -Wnested-externs to point to the same column as
the other 2 warnings. 
(Of course, ideally the 3 would be combined into a single warning, but that's a
separate issue)

My gcc version info:

$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/6.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C
--with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-version-specific-runtime-libs --enable-assert --enable-fat
--enable-portable-binary --enable-browser-plugin --enable-gconf-peer
--enable-libgcj-debug --enable-gc-debug --enable-interpreter
--enable-aot-compile-rpm --enable-java-home --with-x --enable-collections
--enable-gstreamer-peer --enable-xmlj --enable-qt-peer --enable-debug
--enable-local-sockets --without-isl --enable-objc-gc --enable-maintainer-mode
--enable-host-shared CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader
AUTOM4TE=/usr/local/bin/autom4te AUTORECONF=/usr/local/bin/autoreconf
AUTOSCAN=/usr/local/bin/autoscan AUTOUPDATE=/usr/local/bin/autoupdate
IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 6.0.0 20151007 (experimental) (GCC)

[Bug bootstrap/25470] [4.9/5/6 Regression] fixincludes/ subdirectory not cleaned by "make distclean"

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25470

--- Comment #23 from Eric Gallager  ---
(In reply to Eric Gallager from comment #22)
> This seems to be fixed; the only subdir that fails to distclean properly for
> me currently is libcc1...

...which is Bug 70173