[Bug c++/79008] missing detail in -Wbuiltin-declaration-mismatch

2019-05-23 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79008

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> 
> One example of an incompatibility is the following declaration:
> 
>   int __attribute__ ((pure)) abs (int);
> 
> where abs() the built-in is actually declared const.  GCC doesn't currently
> diagnose this except with my patch for bug 81544 (yet to be reviewed).
> 

That's fixed now.

[Bug tree-optimization/89479] __restrict on a pointer ignored when a function is passed alongside it

2019-05-22 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81009

--- Comment #8 from Eric Gallager  ---
(In reply to Eyal Rozenberg from comment #2)
> (In reply to Marc Glisse from comment #1)
> > Seems similar enough.
> 
> With respect  - this is not about x being a const __restrict pointer; what I
> said (including the clang behavior) applies exactly the same when we remove
> the const. See: https://godbolt.org/z/hH643a (where the const is gone).

OK, but even if it's not a dup, I still think it's related enough to go under
"See Also"

[Bug c/88144] remove long-obsolete syntax for designated initializers

2019-05-22 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88144

--- Comment #6 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #3)
> Maybe -Wdeprecated or -Wdeprecated-declarations

I think clang puts this under -Wgnu-designator: 
https://clang.llvm.org/docs/DiagnosticsReference.html#wgnu-designator

Just brainstorming an options entry:
Wgnu-designator
C ObjC C++ ObjC++ Warning Var(warn_gnu_designator) LangEnabledBy(C ObjC C++
ObjC++,Wall || Wextra || Wpedantic || Wdeprecated || Wdeprecated-declarations
|| Wdesignated-init)
Warn on use of obsolete GNU syntax for designated initializers.

[Bug c++/78388] Bogus "declaration shadows template parameter" error with parenthesized function-style casts

2019-05-22 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78388

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing C++ FE maintainers

[Bug other/84889] Ideas on revamping how we format diagnostics

2019-05-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889

--- Comment #17 from Eric Gallager  ---
(In reply to David Malcolm from comment #16)
> (In reply to Martin Liška from comment #14)
> > David: Can the bug be marked as resolved?
> 
> Much of this is implemented for gcc 9.
> 
> I want to keep this open, to revisit it in gcc 10.

It's gcc 10 now.

> I think the main pending items are:
> 
> (In reply to David Malcolm from comment #0)
> [...]
> > * the diagnostic and the followup notes are grouped, so it's easier to pick
> > out what messages relate to what
> [...]
> > IIRC, clang does something where the left-hand column is only non-empty for
> > the start of a diagnostic; followup lines (e.g. due to line wrapping) are
> > indented by 1 char, so that the "wall of text" is broken up somewhat
> [...]

[Bug c/53063] encode group options in the .opt files

2019-05-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Eric Gallager  ---
(In reply to Eric Gallager from comment #12)
> (In reply to Martin Liška from comment #11)
> > Can the bug be marked as resolved?
> 
> WAITING on a reply

no reply; assuming this was fixed

[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags

2019-05-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40989
Bug 40989 depends on bug 53063, which changed state.

Bug 53063 Summary: encode group options in the .opt files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug c++/48562] [C++0x] warn about uses of initializer_list that will lead to dangling pointers

2019-05-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Eric Gallager  ---
(In reply to Eric Gallager from comment #13)
> (In reply to Martin Liška from comment #12)
> > Can the bug be marked as resolved?
> 
> WAITING on a reply

no reply; assuming this was fixed

[Bug middle-end/90549] missing -Wreturn-local-addr maybe returning an address of a local array plus offset

2019-05-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90549

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> Agreed.  Please go ahead abd create one.
> 
> I'm working on a combined patch for this and PR 71924.

OK, I created bug 90556

[Bug other/90556] New: [meta-bug] bogus/missing -Wreturn-local-addr

2019-05-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556

Bug ID: 90556
   Summary: [meta-bug] bogus/missing -Wreturn-local-addr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic, meta-bug
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Depends on: 19972, 49974, 69433, 71924, 81811, 90549
  Target Milestone: ---

-Wreturn-local-addr bugs are spread out between so many different components
that I couldn't pick a decent one for this one and ended up just going with
"other"


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19972
[Bug 19972] -Wreturn-local-addr misses return of local (nested) function
pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
[Bug 49974] missing -Wreturn-local-addr for indirectly returning reference to
local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69433
[Bug 69433] missing -Wreturn-local-addr assigning address of a local to a
static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71924
[Bug 71924] missing -Wreturn-local-addr returning alloca result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81811
[Bug 81811] missing -Wreturn-local-addr returning strcpy result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90549
[Bug 90549] missing -Wreturn-local-addr maybe returning an address of a local
array plus offset

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
How many of these have been fixed by Martin's recent -Wformat-diag addition?

[Bug middle-end/90549] missing -Wreturn-local-addr maybe returning an address of a local array plus offset

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90549

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think there's enough bugs with -Wreturn-local-addr for it to have its own
meta-bug now...

[Bug c/90552] attribute((optimize(3))) not overriding -Os

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90552

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86840

--- Comment #1 from Eric Gallager  ---
Another bug with __attribute__((optimize)) being ignored is bug 86840

[Bug target/63545] ICE when building GCC for ia64-hp-hpux11.23 in hash_table::find_slot_with_hash

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63545

Eric Gallager  changed:

   What|Removed |Added

 CC||dave.anglin at bell dot net

--- Comment #8 from Eric Gallager  ---
cc-ing HPUX maintainer

[Bug c/80502] Provide macro to indicate OpenMP SIMD support

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80502

--- Comment #4 from Eric Gallager  ---
(In reply to Evan Nemerson from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > _OPENMP_SIMD is a bad idea, that namespace is reserved for OpenMP, so unless
> > it shows up in the OpenMP standard, it shouldn't be added.
> 
> Fair enough, I'll propose it to the OpenMP people:
> http://forum.openmp.org/forum/viewtopic.php?f=23=2031
> 
> > Why do you need a macro?  Just use #pragma omp simd etc. unconditionally,
> > compilers that don't have support for such pragmas will just ignore those.
> 
> Not necessarily; often they'll emit warnings (for GCC, -Wall even includes
> -Wunknown-pragmas). I'd much rather use the preprocessor in my code than
> teach people to disable warnings.
> 

Does Michael Klemm from that discussion have an account here on this bugzilla?

> I need to support alternatives in my code. For example, for SIMDe
> (), I try to support OpenMP SIMD and Cilk
> Plus, as well as compiler-specific pragmas for GCC (GCC ivdep), ICC (simd),
> and clang (clang loop ...), and I'd be happy to add more as necessary. I'd
> rather not end up with something like
> 
>   #pragma omp simd
>   #pragma simd
>   #pragma GCC ivdep
>   #pragma clang loop vectorize(enable)
>   for (...) { ... }
> 
> I'd much rather just have a few macros which will expand to the right pragma
> based on preprocessor macros. Right now I'm stuck using the much less
> expressive ivdep syntax for GCC unless *full* OpenMP support is enabled (or
> someone defines a macro manually to indicate OpenMP SIMD support).

[Bug c/59753] -Woverflow warning inconsistency with signed constant conversion between T_MAX+1 and UT_MAX vs larger than UT_MAX

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug c/80592] gcc fails to detect overflow in shift statement

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80592

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug c/70378] wrong warning with -Wconversion with explicit cast

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742

--- Comment #11 from Eric Gallager  ---
Are you still working on this, Jonathan?

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314

--- Comment #3 from Eric Gallager  ---
is this an ice-on-valid or an ice-on-invalid?

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

2019-05-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58321

Eric Gallager  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #3)
> Still present at r220301 (see
> https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html). Does the
> patch in comment 2 makes sense or is there a better fix?

cc-ing FX from that

[Bug tree-optimization/37239] peeling last iteration of a <= loop

2019-05-15 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239

Eric Gallager  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00253.html
> 
> This was approved with a minor nit fixed

cc-ing Jeff from that thread

[Bug c++/90428] -Wredundant-move could warn for more cases

2019-05-15 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90428

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81159,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67906

--- Comment #1 from Eric Gallager  ---
kinda related to other requests for improvements to warnings regarding
std::move, such as bug 81159 and bug 67906

[Bug c++/84916] Tweaks to template type elision

2019-05-15 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84916

--- Comment #5 from Eric Gallager  ---
(In reply to David Malcolm from comment #4)
> I have a patch for this, queuing for gcc 10 stage 1.

It's gcc 10 stage 1

[Bug c/90476] prepossessor should error if #line 0

2019-05-14 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476

--- Comment #4 from Eric Gallager  ---
(In reply to Segher Boessenkool from comment #3)
> Where is it documented (in GCC). then?  I can't find it.

¯\_(ツ)_/¯

I dunno where they got that idea; just reporting it because I thought it seemed
like it might be relevant

[Bug c/90476] prepossessor should error if #line 0

2019-05-14 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90476

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
For reference, clang considers this a GNU extension and even has a specific
named flag to warn about it, -Wgnu-zero-line-directive:
https://clang.llvm.org/docs/DiagnosticsReference.html#wgnu-zero-line-directive

[Bug c++/90466] Documentation: -Wconversion-extra not documented

2019-05-14 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90466

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
That's a fortran option; it's documented in the gfortran manual:
https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

2019-05-14 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817

Eric Gallager  changed:

   What|Removed |Added

 CC||gcc-bugs at engestrom dot ch

--- Comment #19 from Eric Gallager  ---
*** Bug 90457 has been marked as a duplicate of this bug. ***

[Bug c/90457] -Wimplicit-fallthrough seems confused by #ifdef

2019-05-14 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90457

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Gallager  ---
dup of bug 77817

*** This bug has been marked as a duplicate of bug 77817 ***

[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'

2019-05-13 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329

Eric Gallager  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> (In reply to David Malcolm from comment #4)
> > Fixed on trunk by r262199; still affects gcc-8 and gcc-7 branches.
> 
> so what should be the target milestone then?

(In reply to David Malcolm from comment #6)
> Author: dmalcolm
> Date: Thu Feb 14 23:02:45 2019
> New Revision: 268909
> 
> URL: https://gcc.gnu.org/viewcvs?rev=268909=gcc=rev
> Log:
> C++: don't offer bogus "._0" suggestions (PR c++/86329)
> 
> PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
> 
>   #include 
> 
>   int compare()
>   {
> return __n1 - __n2;
>   }
> 
> suggested.cc: In function 'int compare()':
> suggested.cc:5:10: error: '__n1' was not declared in this scope
>return __n1 - __n2;
>   ^~~~
> suggested.cc:5:10: note: suggested alternative: '._61'
>return __n1 - __n2;
>   ^~~~
>   ._61
> suggested.cc:5:17: error: '__n2' was not declared in this scope
>return __n1 - __n2;
>  ^~~~
> suggested.cc:5:17: note: suggested alternative: '._72'
>return __n1 - __n2;
>  ^~~~
>  ._72
> 
> The dot-prefixed names are an implementation detail of how we implement
> anonymous enums found in the header files, generated via
> anon_aggrname_format in make_anon_name.
> 
> This patch uses anon_aggrname_p to filter them out when considering
> which names to suggest.
> 
> gcc/cp/ChangeLog:
>   Backport of r262199 from trunk.
>   2018-06-27  David Malcolm  
> 
>   PR c++/86329
>   * name-lookup.c (consider_binding_level): Filter out names that
>   match anon_aggrname_p.
> 
> gcc/testsuite/ChangeLog:
>   Backport of r262199 from trunk.
>   2018-06-27  David Malcolm  
> 
>   PR c++/86329
>   * g++.dg/lookup/pr86329.C: New test.
> 
> 
> Added:
> branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/pr86329.C
> Modified:
> branches/gcc-8-branch/gcc/cp/ChangeLog
> branches/gcc-8-branch/gcc/cp/name-lookup.c
> branches/gcc-8-branch/gcc/testsuite/ChangeLog

So, since this fixed it for 8, just 7 is left, so changing the target milestone
to 7.4

[Bug c++/67960] [8/9/10 Regression] Prefixing a function with [[deprecated]] produces multiple warnings

2019-05-13 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79078

--- Comment #4 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> This is not a dup of PR 79078, because that's about issuing warnings in too
> many places, this is just about issuing the same one too many times.
> 
> This seems to have been fixed for GCC 7, as only one warning is given, but
> then regressed for GCC 8, which gives two warnings.

OK, so maybe not a dup, but it still seems related enough to go under "See
Also"

[Bug c++/90449] No way to turn off warning about inaccessible base

2019-05-13 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90449

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Blocks||44209

--- Comment #2 from Eric Gallager  ---
falls under the meta-bug of bug 44209


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
[Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options

[Bug c++/90451] [7/8/9/10 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)

2019-05-13 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79078

--- Comment #4 from Eric Gallager  ---
I think bug 79078 is related, too

[Bug middle-end/89230] Bogus uninited usage warning

2019-05-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230

--- Comment #7 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to lavr from comment #2)
> > Okay, but "d" points to a clearly separate storage on stack within a local
> > frame.  None of the pointers passed to (s)printf() relate to that area
> > (either they are also clearly separate within the current stack frame,
> > automatic ("name", "type", "temp"); or the argument values, that function
> > was called with ("pfx")), so how "d->D_fid[2]" can be changed, in GCC's
> > point of view?  I mean, within the semantics of the language, that's
> > impossible; and the warning should only be issued for that kind of a
> > (mis)use.
> 
> It is not obvious from your small code snippet that d does not point to a
> local struct or if that local struct does not escape.
> 
> Without a full testcase (preprocessed source), it is hard to debug this any
> further.

Reporter has since provided a full testcase (I haven't made any further attempt
to debug it myself though)

[Bug target/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

2019-05-11 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

Eric Gallager  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #21 from Eric Gallager  ---
(In reply to Eric Gallager from comment #20)
> Should this really have the middle-end for its component? It seems like this
> is more of a target issue...

changing component to target

[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used

2019-05-11 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048

Eric Gallager  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||dvyukov at google dot com,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
cc-ing sanitizer maintainers

[Bug tree-optimization/42970] Missed unused function return value elimination

2019-05-11 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-05/msg00472.ht
   ||ml

--- Comment #8 from Eric Gallager  ---
(In reply to Martin Jambor from comment #7)
> (In reply to Eric Gallager from comment #6)
> > 
> > Stage 1 has opened again.
> 
> And therefore I have submitted a cleaned-up version for review:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00472.html

Cool, thanks! Adding "patch" keyword then.

[Bug tree-optimization/42970] Missed unused function return value elimination

2019-05-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Jambor from comment #5)
> I have posted a WIP patch as:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01765.html
> 
> I am in the process of cleaning it up for final submission once stage 1
> opens again.

Stage 1 has opened again.

[Bug c/66970] Add __has_builtin() macro

2019-05-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970

--- Comment #14 from Eric Gallager  ---
(In reply to Martin Sebor from comment #13)
> Let me look into this request for GCC 10.

It's GCC 10 now.

[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull

2019-05-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80936

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Sebor from comment #4)
> POSIX says this about bcopy:
> 
>   For maximum portability, it is recommended to replace the function call to
> bcopy() as follows:
> 
>   #define bcopy(b1,b2,len) (memmove((b2), (b1), (len)), (void) 0)
> 
> GCC lowers bcopy calls to memmove (and similarly for other bxxx calls),
> which I think makes it even more important that the non-null attribute be
> applied to their declarations, to detect bugs due to legacy code making the
> assumption that   bcopy et al are null-safe (e.g., on a target where they
> really are).
> 
> $ cat t.c && gcc -O0 -S -Wall -fdump-tree-lower=/dev/stdout t.c
> void f (void *d, const void *s, __SIZE_TYPE__ n)
> {
>   __builtin_bcopy (s, 0, n);
> }
> 
> ;; Function f (f, funcdef_no=0, decl_uid=1908, cgraph_uid=1, symbol_order=0)
> 
> f (void * d, const void * s, long unsigned int n)
> {
>   __builtin_memmove (0B, s, n);
>   return;
> }

ok, be sure to update the comment, then, once you add the attribute

[Bug other/49194] Trivially stupid inlining decisions

2019-05-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194

--- Comment #12 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #11)
> Well, I am working on gradual improvements in the inlining decisions,
> but since the PR is not very specific, we never will be perfect :)

So should we leave it open then, or close it?

[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions

2019-05-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759

--- Comment #10 from Eric Gallager  ---
(In reply to Arseny Solokha from comment #9)
> Yes, but AFAIK none of the PRs specific to powerpcspe have been closed so
> far. And, personally, I'd like them to stay open for another release cycle
> in the hope Andrew would actually revive the target this year. But it's up
> to gcc maintainers to decide, of course.

OK, leaving this open then...

[Bug middle-end/78917] missing -Wnonnull passing null to a nonnull function

2019-05-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78917

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> Another test case:
> 
> $ cat f.c && gcc -O2 -S -Wall -Wextra f.c
> int f (int i)
> {
>   const char * p = __builtin_strchr (i ? "123" : "456", '2');
>   return __builtin_strlen (p);
> }
> 
> The strlen argument is a phi with a null operand so that should make it easy
> to detect:
> 
>   # prephitmp_11 = PHI <_10(3), 0B(2)>
>   _1 = __builtin_strlen (prephitmp_11);

OK, this second testcase is different enough, so I guess this bug can stay
separate

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

2019-05-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1

Eric Gallager  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com,
   ||pinskia at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #13 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #10)
> On Thu, 25 Jun 2015, P at draigBrady dot com wrote:
> 
> > I'm not understanding completely TBH. Are flexible array members not 
> > special?
> > Should the optimizations be restricted on access through the flexible array,
> > because I presume most/all existing allocation code is not considering this
> > alignment/padding issue. I certainly didn't notice any examples when looking
> > into a workaround which I came up with independently. For my reference there
> > are some notes RE GCC's divergence from C99 re padding and flexi arrays at:
> > https://sites.google.com/site/embeddedmonologue/home/c-programming/data-alig
> 
> That page doesn't exist - I assume you mean: 
> https://sites.google.com/site/embeddedmonologue/home/c-programming/data-
> alignment-structure-padding-and-flexible-array-member
> 
> That page is over ten years out of date - it's quoting the wording in C99 
> as it was before it was corrected by TC2 (published 2004-11-15).  You 
> should look at the post-TC2 wording rather than the old wording with 
> various defects in it.

Could you quote the post-TC2 wording here for us so we don't have to go
looking?

[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros

2019-05-08 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think there's another bug like this; forget its number right now though...

[Bug middle-end/78998] missing -Wnonnull for an unconditional call to strlen with a null argument

2019-05-08 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78998

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug c++/80684] poor error message and fix-it hint for a function with an argument of undeclared type

2019-05-08 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80684

Eric Gallager  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing other diagnostics maintainer

[Bug other/90375] Environment variables not listed in ENVIRONMENT section of man page

2019-05-07 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90375

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #0)
> The following env vars are documented as affecting GCC's behaviour, but are
> not listed in the ENVIRONMENT section of the gcc(1) man page:
> 
> GCC_COLORS (for -fdiagnostics-color)
> COLUMNS (for -fno-diagnostics-show-caret)
> MAKE (for -flto=n)
> ASAN_OPTIONS
> TSAN_OPTIONS
> LSAN_OPTIONS
> VTV_LOGS_DIR (for -fvtv-debug)
> PATH (for finding subprograms when -Bprefix and the standard locations don't
> have them)

Bug 80271 would have CLICOLOR_FORCE added to that list as well.

> 
> -M mentions "or use an environment variable like DEPENDENCIES_OUTPUT" which
> isn't very clear if that actually gets used by GCC or is just an example. I
> suggest saying "or use one of the environment variables DEPENDENCIES_OUTPUT
> or SUNPRO_DEPENDENCIES" instead.
> 
> There's also "The runtime library  behavior can be influenced using various
> CHKP_RT_* environment variables.  See
> <https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler>
> for more details."

I thought the CHKP/MPX stuff had been removed...

[Bug c++/84177] Attributes on C++17 nested namespaces

2019-05-07 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84177

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
Martin Sebor has been doing stuff with diagnostics for attributes lately;
cc-ing him

[Bug c++/79817] GCC does not recognize [[deprecated]] attribute for namespace

2019-05-07 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79817

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing C++ FE maintainers

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2019-05-07 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #22 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #21)
> (In reply to Eric Gallager from comment #20)
> > (In reply to Dominique d'Humieres from comment #18)
> > > For the record with darwin15 I had to add
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/
> > > NSEnumerator.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h
> > > 
> > > from the 10.9 SDK to
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
> > > /usr/include/objc/NSObject.h
> > 
> > that seems dangerous
> 
> Not so dangerous as it seems.
> 
> Many (most, in fact) of the failures seen from GCC Objective-C are caused by
> missing support for new features that have been introduced into the vendor's
> headers.  Short list: Apple Blocks, Lightweight Generics, Nullability,
> Syntactic sugar on ID.

Blocks support at least is bug 78352; are there bugs open for the other 3? 

> I'm working on a set of replacement test-suite headers that allow us to
> test the things that _do_ work on GCC Objective-C, and expose any real
> regressions.
> 
> Tests on Darwin13 and earlier show that we are not in such bad shape as the
> header fails make it appear.
> 
> I hope to get these test fixes (there's a set of three PRs related to excess
> fails on Yosemite+) in place soon - and to back port them to the open
> branches.

[Bug c/82200] Unhelpful diagnostic for incorrectly ordered attribute and asm on function declaration in system header

2019-05-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82200

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
I know Martin Sebor has done work on attribute diagnostics; cc-ing him

[Bug c/45358] Diagnostic could be issued for old C style a =+ b and similar cases

2019-05-01 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358

Eric Gallager  changed:

   What|Removed |Added

 Blocks||87403

--- Comment #6 from Eric Gallager  ---
making this block the "new-warning" meta-bug


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c/80130] Wrong diagnostic: dereferencing type-punned pointer

2019-05-01 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80130

Eric Gallager  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Richard Biener from comment #3)
> (In reply to Eric Gallager from comment #2)
> > I only get 1 warning on (1) and only with -Wstrict-aliasing=1.
> > -Wstrict-aliasing=2 and -Wstrict-aliasing=3 are both silent.
> > 
> > (In reply to Richard Biener from comment #1)
> > > The warning implementation is incredibly stupid, don't use it.  It doesn't
> > > have any context (so the two stmt variant is different from the single 
> > > stmt
> > > one).
> > 
> > It'd still be nice if it could be improved though. Although, maybe it
> > already has been?
> 
> I don't see how it can be improved.  Iff the compiler can detect an
> aliasing violation it may as well try to be conservative (which in
> fact we do later during optimization).
> 
> Jakub has attempted to do a TBAA sanitizer, not sure how far that went though,
> it is quite meta-data heavy to do "correctly".  Still tracking the dynamic
> type of storage at runtime and then instrumenting each access is the only
> way to reliably detect TBAA violations (without false positives).

cc-ing Jakub then to see how far he got with it

[Bug c/77331] incorrect range location in -Wformat with a concatenated format literal

2019-05-01 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77331

Eric Gallager  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
cc-ing other diagnostics maintainer

[Bug translation/90118] Missing space between words

2019-05-01 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Eric Gallager  ---
(In reply to Roland Illig from comment #9)
> The particular issue has been fixed, the linter has been updated in bug
> 90176, therefore I think this bug can be closed.

OK.

[Bug web/89770] move java-related mailing lists on lists.html to the "Historical lists" section

2019-04-30 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89770

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Liška from comment #1)
> Fixed.

So it is. Thanks!

[Bug c/79084] Missed -Wpedantic for implicit double with complex specifier due to "complex" being a macro defined in a system header

2019-04-30 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79084

Eric Gallager  changed:

   What|Removed |Added

Summary|No warning for implicit |Missed -Wpedantic for
   |double with complex |implicit double with
   |specifier   |complex specifier due to
   ||"complex" being a macro
   ||defined in a system header

--- Comment #2 from Eric Gallager  ---
retitling to clarify that this warning isn't actually new (and thus doesn't
need to block the new-warning meta-bug)

[Bug c/71870] wrong location of "%n$" directive in -Wformat

2019-04-30 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71870

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

2019-04-29 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #33 from Eric Gallager  ---
This came up on the mailing lists again here:
https://gcc.gnu.org/ml/gcc/2019-04/msg00276.html

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

2019-04-29 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2

Eric Gallager  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e, jrtc27 at jrtc27 dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87338

--- Comment #16 from Eric Gallager  ---
(In reply to Jim Wilson from comment #14)
> https://wiki.debian.org/Ports/ia64
> 
> James Clarke has been active recently on the binutils and/or gcc mailing
> lists.  My IA-64 work has dwindled down to nothing, as RISC-V work has kept
> me too busy to do anything else.  With the architecture already set to
> end-of-life next year, I'm not planning to do anymore IA-64 work.

(In reply to Jim Wilson from comment #15)
> See also PR 87338 which has a response earlier today from John Paul Adrian
> Glaubitz.

ok, thanks

[Bug c/71188] missing warning converting constant integer expression zero to pointer

2019-04-29 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71188

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44263

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> Possibly related to bug 44263?

That was closed as fixed, and Martin said that was just for C++, so I guess
this is the plain-C equivalent. Still putting it under "See Also" anyways

[Bug fortran/30123] Document INQUIRE, especially UNFORMATTED and FORMATTED

2019-04-28 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123

--- Comment #5 from Eric Gallager  ---
(In reply to Jürgen Reuter from comment #4)
> This seems like one of these documentation tasks which is in principle very
> easy to do but nobody is motivated to do.^^

Indeed.

[Bug c/43728] Add warning for redundant static function prototypes

2019-04-28 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #10 from Eric Gallager  ---
(In reply to Eric Gallager from comment #9)
> (In reply to Eric Gallager from comment #8)
> > Confirmed, although I probably wouldn't use such a warning myself if it were
> > added. (I like redundancy)
> 
> Do people still want this? Putting in WAITING for someone to re-confirm.

No reply, I guess no one really wants this after all.

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

2019-04-28 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 43728, which changed state.

Bug 43728 Summary: Add warning for redundant static function prototypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

2019-04-28 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2

--- Comment #13 from Eric Gallager  ---
(In reply to Jim Wilson from comment #12)
> I no longer have access to IA-64 hardware.  I was leaving myself as
> maintainer just so that there was someone responsible for answering
> questions.  I don't care if the port survives or not.  I can resign if that
> makes things easier.
> 
> There is an ia64 debian group that has hardware, and is still doing debian
> work.  They would be disappointed if the ia64 port was deprecated.  I get
> the occasional binutils and gcc bug reports from them, and am occasionally
> able to fix them even though I don't have hardware.

Do they have a bugzilla account here that could be cc-ed?

> 
> I think that solving this bug requires that all locals get initialized to 0
> when defined.  Otherwise, you may accidentally read a register with the nat
> bit set when doing bit-field operations on a register.  I don't care enough
> about ia64 to try to fix this.

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

2019-04-28 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build, memory-hog
 CC||egallager at gcc dot gnu.org
 Blocks||45375

--- Comment #1 from Eric Gallager  ---
I see -flto in there, so making this block the mozillametabug


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug 45375] [meta-bug] Issues with building Mozilla (i.e. Firefox) with LTO

[Bug objc++/49070] [7/8/9/10 regression] ObjC++ compiler fails to compile ObjC method invocations without keyword arguments

2019-04-27 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070

Eric Gallager  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net

--- Comment #4 from Eric Gallager  ---
cc-ing objc[++] maintainers

[Bug c/50422] -Wswitch warns about unhandled cases in nested switches

2019-04-27 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50422

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug c/55096] Wconversion-nul does not work in C

2019-04-27 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55096

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS (can lead to build failures when libunwind-headers from MacPorts is active)

2019-04-26 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251

Eric Gallager  changed:

   What|Removed |Added

Summary|config/gettext.m4 and   |config/gettext.m4 and
   |config/iconv.m4 contaminate |config/iconv.m4 contaminate
   |CPPFLAGS|CPPFLAGS (can lead to build
   ||failures when
   ||libunwind-headers from
   ||MacPorts is active)

--- Comment #10 from Eric Gallager  ---
(In reply to Eric Gallager from comment #9)
> (In reply to Eric Gallager from comment #8)
> > r265896 might have affected this
> 
> Update: apparently not; I still had to deactivate libunwind-headers again on
> my latest build of gcc

Since I keep running into this, I'm adding that part to the title for easier
findability

[Bug c/90253] no warning for cv-qualified selectors in _Generic

2019-04-26 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90253

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think there was another bug about this w.r.t. -Wignored-qualifiers and/or
whether or not typeof should strip qualifiers; can't find it right now
though...

[Bug tree-optimization/89043] strcat (strcpy (d, a), b) not folded to stpcpy (strcpy (d, a), b)

2019-04-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89043

--- Comment #7 from Eric Gallager  ---
Anyways my point about bringing up which standards stpcpy() is in is to remind
people to keep portability concerns in mind when doing this change. Please
check the gnulib docs on stpcpy() for specifics:
https://www.gnu.org/software/gnulib/manual/html_node/stpcpy.html

[Bug c/37874] gcc sometimes accepts attribute in identifier list

2019-04-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> (In reply to Chris Lattner from comment #0)
> > GCC rejects the former, but not the later.
> > 
> > void f2(y, __attribute__(()) x);
> > void f3(__attribute__(()) x, y);
> 
> GCC can be made to reject f3() with -Werror:
> 
> $ /usr/local/bin/gcc -c -Wall -Wextra -pedantic -Werror 37874.c
> 37874.c:1:12: error: expected ‘)’ before ‘__attribute__’
>  void f2(y, __attribute__(()) x);
> ^
> 37874.c:2:1: error: parameter names (without types) in function declaration
> [-Werror]
>  void f3(__attribute__(()) x, y);
>  ^~~~
> cc1: all warnings being treated as errors
> 
> I see you fixed this for f4() at least for clang:
> 
> $ /sw/opt/llvm-3.1/bin/clang-3.1 -c 37874.c
> 37874.c:1:12: error: expected identifier
> void f2(y, __attribute__(()) x);
>^
> 37874.c:2:27: warning: type specifier missing, defaults to 'int'
> [-Wimplicit-int]
> void f3(__attribute__(()) x, y);
> ~ ^
> 37874.c:2:30: warning: type specifier missing, defaults to 'int'
> [-Wimplicit-int]
> void f3(__attribute__(()) x, y);
>  ^
> 37874.c:3:9: error: expected parameter declarator
> void f4(__attribute__(()));
> ^
> 2 warnings and 2 errors generated.

Since clang rejects this, I'm making this an accepts-invalid

[Bug c/26613] Corner case causes garbage to be output by -aux-info switch.

2019-04-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613

--- Comment #9 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Eric Gallager from comment #7)
> > (In reply to Mark F. Haigh from comment #5)
> > > Created attachment 11005 [details]
> > > Fix for trunk (against 2006-03-03 CVS)
> > 
> > Could you submit a newer version of this patch to the gcc-patches mailing
> > list please?
> 
> I doubt c-aux-info.c has changed in the last 10 years ...

I tried applying it and the second hunk was rejected...

[Bug other/63613] dejagnu.h needs to be fix included

2019-04-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63613

Eric Gallager  changed:

   What|Removed |Added

 CC||bkorb at gnu dot org

--- Comment #13 from Eric Gallager  ---
(In reply to Eric Gallager from comment #12)
> (In reply to David Malcolm from comment #11)
> > Patch posted as https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00468.html
> 
> Does this still apply?

So after reviewing this thread, it looks like Jeff Law approved the patch, but
Bruce Korb requested a minor tweak. It should be pretty easy to make Bruce's
requested change; can you do that and resubmit, David? Or are we assuming that
dejagnu 1.6 has been out long enough now that this bug doesn't really matter
any longer?

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

2019-04-23 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435

Eric Gallager  changed:

   What|Removed |Added

 CC||dj at redhat dot com,
   ||joseph at codesourcery dot com

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to jos...@codesourcery.com from comment #5)
> > Subject: Re:  gengtype: don't test undefined value after
> >  vasprintf failure
> > 
> > On Mon, 7 Jun 2010, dj at redhat dot com wrote:
> > 
> > > > If the libiberty maintainers won't review the xvasprintf patch,
> > > 
> > > I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html
> > 
> > That's a review of an older version.  The URLs I gave were of a version a 
> > different person updated to take account of your original review comments.
> 
> Has the updated version been reviewed yet?

Joseph, do you remember what happened with this, if anything?

[Bug c++/90205] Wformat-signedness detects %d and suggests %d fixit hint

2019-04-23 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90205

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Jonny Grant from comment #6)
> Wondering if it is also worth the message making clear the type was promoted?
> 
> eg:
> 
> :5:14: warning: format '%d' expects argument of type 'int', but
> argument 2 has type 'float' automatically promoted to 'double', for which
> '%f' is required [-Wformat=]
> 
> 5 | printf("%d", i);
>   | ~^   ~
>   |  |   |
>   |  int float
>   | %f

Maybe, but the message would be getting pretty long by that point...

[Bug c++/18635] [DR 504] use of uninitialised reference accepted (without -Wuninitialized) in C++ front end

2019-04-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635

Eric Gallager  changed:

   What|Removed |Added

   Keywords|accepts-invalid |diagnostic
 Blocks||24639
Summary|[DR 504] use of |[DR 504] use of
   |uninitialised reference |uninitialised reference
   |accepted in C++ front end   |accepted (without
   ||-Wuninitialized) in C++
   ||front end
   Severity|normal  |enhancement

--- Comment #17 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #16)
> This is
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3293.html#504 which
> is Open, so I'm suspending this. If/when that gets resolved we can revisit
> this PR.
> 
> I think SUSPENDED rather than INVALID is being generous, as G++ is
> completely correct to accept the code, and follows the committee's
> intentions:
> "Implementations can warn about such constructs, and the resolution for
> issue 453 makes executing such code undefined behavior; that seemed to
> address the situation adequately."

Changing from an accepts-invalid to an enhancement request for an optional
-Wuninitialized diagnostic then


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

2019-04-21 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #20)
> r261797 removed all references to _ANSI_H_ from stddef.h, so this issue 
> can't be relevant after then.

...so that sounds like it can be closed, then.

[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment

2019-04-20 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #20 from Eric Gallager  ---
came up on the mailing lists here:
https://gcc.gnu.org/ml/gcc/2019-04/msg00202.html

[Bug translation/90163] untranslated placeholder in warn_once_call_ms2sysv_xlogues

2019-04-19 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90163

Eric Gallager  changed:

   What|Removed |Added

 CC||daniel.santos at pobox dot com,
   ||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
pretty sure Daniel Santos did this code

[Bug c++/52961] Make -Wempty-body less noisy and enable it with -Wall

2019-04-19 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52961

--- Comment #12 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #10)
> Clang... suggests placing the ";" on a different line to silence
> the warning:
> 
> 
> warning: if statement has empty body [-Wempty-body]
>   if(a);
>^
> note: put the semicolon on a separate line to silence this warning
> 
> which seems a nicer way to silence the warning instead of ugly { ; }

That's a debatable opinion; I think the braces do a better job expressing
grouping

[Bug inline-asm/52813] %rsp in clobber list is silently ignored

2019-04-18 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Eric Gallager  ---
(In reply to Christophe Lyon from comment #11)
> (In reply to Eric Gallager from comment #10)
> > So after these 2, has this been fixed now?
> OK for me.

OK.

[Bug inline-asm/52813] %rsp in clobber list is silently ignored

2019-04-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813

--- Comment #10 from Eric Gallager  ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> Author: rsandifo
> Date: Tue Jan 15 16:46:54 2019
> New Revision: 267941
> 
> URL: https://gcc.gnu.org/viewcvs?rev=267941=gcc=rev
> Log:
> PR inline-asm/52813 revisited
> 
> The original patch for this PR made it an error to list the stack
> pointer in the clobber list of an inline asm.  However, the general
> feeling seemed to be that going straight to a hard error was too harsh,
> since there's quite a bit of existing code that has the clobber.
> 
> This patch implements the compromise discussed on IRC of making it
> a -Wdeprecated warning instead.
> 
> 2019-01-15  Richard Sandiford  
> 
> gcc/
>   PR inline-asm/52813
>   * doc/extend.texi: Document that listing the stack pointer in the
>   clobber list of an asm is a deprecated feature.
>   * common.opt (Wdeprecated): Moved from c-family/c.opt.
>   * cfgexpand.c (asm_clobber_reg_is_valid): Issue a -Wdeprecated
>   warning instead of an error for clobbers of the stack pointer.
>   Add a note explaining why.
> 
> gcc/c-family/
>   PR inline-asm/52813
>   * c.opt (Wdeprecated): Move documentation and variable to common.opt.
> 
> gcc/d/
>   PR inline-asm/52813
>   * lang.opt (Wdeprecated): Reference common.opt instead of c.opt.
> 
> gcc/testsuite/
>   PR inline-asm/52813
>   * gcc.target/i386/pr52813.c (test1): Turn the diagnostic into a
>   -Wdeprecated warning and expect a following note:.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/c-family/ChangeLog
> trunk/gcc/c-family/c.opt
> trunk/gcc/cfgexpand.c
> trunk/gcc/common.opt
> trunk/gcc/d/ChangeLog
> trunk/gcc/d/lang.opt
> trunk/gcc/doc/extend.texi
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gcc.target/i386/pr52813.c

(In reply to Christophe Lyon from comment #9)
> Author: clyon
> Date: Fri Jan 18 09:57:41 2019
> New Revision: 268066
> 
> URL: https://gcc.gnu.org/viewcvs?rev=268066=gcc=rev
> Log:
> [ARM][testsuite] follow-up to PR target/52813 and target/11807 fix.
> 
> 2019-01-18  Christophe Lyon  
> 
>   * gcc.target/arm/pr77904.c: Add dg-warning for sp clobber.
> 
> 
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gcc.target/arm/pr77904.c

So after these 2, has this been fixed now?

[Bug c++/81159] New warning idea: -Wself-move

2019-04-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159

Eric Gallager  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing Marek since he wrote a blog post that seems relevant here:
https://developers.redhat.com/blog/2019/04/12/understanding-when-not-to-stdmove-in-c/

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

2019-04-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906

Eric Gallager  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #8)
> Kinda related: PR 86981

cc-ing Marek since he fixed that

[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags

2019-04-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #35 from Eric Gallager  ---
cc-ing Martin Sebor since this bug is relevant to this blog post he wrote:
https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings/

(In reply to Manuel López-Ibáñez from comment #16)
> Subject: Bug 7651
> 
> Author: manu
> Date: Tue Jan  2 17:33:25 2007
> New Revision: 120347
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=120347
> Log:
> 2007-01-02  Manuel Lopez-Ibanez  
> 
>   PR middle-end/7651
>   * c.opt (Wold-style-declaration): New.
>   * doc/invoke.texi (C-only Warning Options): New.
>   (Wold-style-declaration): Document it.
>   (Wextra): Enabled by -Wextra.
>   * c-opts.c (c_common_post_options): Enabled by -Wextra.
>   * c-decl.c (declspecs_add_scspec): Replace -Wextra with
>   -Wold-style-declaration.
> 
> testsuite/
>   * gcc.dg/declspec-3.c: Replace -W with -Wold-style-declaration.
>   * gcc.dg/declspec-3-Wextra.c: New.
>   * gcc.dg/declspec-3-no.c: New
> 
> Added:
> trunk/gcc/testsuite/gcc.dg/declspec-3-Wextra.c
> trunk/gcc/testsuite/gcc.dg/declspec-3-no.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/c-decl.c
> trunk/gcc/c-opts.c
> trunk/gcc/c.opt
> trunk/gcc/doc/invoke.texi
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gcc.dg/declspec-3.c

Would have been nice to have a testcase explicitly named
gcc.dg/Wold-style-declaration.c, too, for easier findability

[Bug web/90127] Disable bugzilla [[wiki_links]] and don't confuse r12 register names with r12345 svn revisions

2019-04-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
oh yeah this has been bothering me for a while now; good to see an effort to
finally do something about it!

[Bug translation/90119] Merge translation msgids that only differ in placeholders

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
since this requests modifying the linter, I'm going to say this is more
difficult than just "trivial" and thus leave the importance as "normal"
(likewise with other translation bugs that request modifying the linter)

[Bug target/79869] i18n: document placeholders for translators

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation
 CC||amylaar at gcc dot gnu.org,
   ||andrew.burgess at embecosm dot 
com
   ||, claziss at gmail dot com,
   ||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Roland Illig from comment #1)
> ping? Two years later, and I still don't know how to translate this string
> into proper German.

cc-ing arc maintainers/reviewers

[Bug translation/90120] inconsistent punctuation in translation messages

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||egallager at gcc dot gnu.org
 Blocks||40883
   Severity|normal  |trivial


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug translation/90121] extra space in error message

2019-04-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||egallager at gcc dot gnu.org
 Blocks||40883
   Severity|normal  |trivial


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug 40883] [meta-bug] Translation breakage with trivial fixes

[Bug other/88790] No warning for misleading indentation

2019-04-15 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790

--- Comment #2 from Eric Gallager  ---
(In reply to Segher Boessenkool from comment #1)
> (I couldn't add that cc:, Daniel doesn't have a bugzilla account yet).

What about now?

[Bug tree-optimization/81437] missing -Wstringop-overflow reading past the end of a string

2019-04-14 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81437

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> GCC 9 prints the two warnings below with -m64 as well as -m32.  GCC 8.2.0
> prints them too but only in LP64 mode.  With -m32, it only warns about g.
> 
> $ gcc -O2 -S -Wall -m32 a.c
> a.c: In function ‘g’:
> a.c:12:3: warning: ‘__builtin_memcpy’ forming offset 5 is out of the bounds
> [0, 4] of object ‘a’ with type ‘const char[4]’ [-Warray-bounds]
>12 |   __builtin_memcpy (d, a + 4, n);   // missing warning
>   |   ^~
> a.c:10:14: note: ‘a’ declared here
>10 |   const char a[] = "123";
>   |  ^
> a.c: In function ‘f’:
> a.c:5:3: warning: ‘__builtin_memcpy’ forming offset [5, 2147483651] is out
> of the bounds [0, 4] of object ‘a’ with type ‘const char[4]’ [-Warray-bounds]
> 5 |   __builtin_memcpy (d, a + 4, n);   // warning (ok)
>   |   ^~
> a.c:3:14: note: ‘a’ declared here
> 3 |   const char a[] = "123";
>   |  ^

So we're down to just 1 missing warning now then?

[Bug c++/83820] No diagnostic issued for noreturn attribute specifier with an argument list

2019-04-14 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83820

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> Confirmed, thanks.  GCC 8 does a better job diagnosing these issues (e.g.,
> it complains about attribute malloc on a void function) but this case was
> missed in r255469.  There probably are other meaningless declarations that
> would be helpful to warn about so please open a new bug for each.

I think the reporter is asking for a hard error and not just a warning? Reads
like an accepts-invalid to me (on this reading at least)

[Bug c++/90052] Warning for (x == 1 && x == 2) should be in -Wall

2019-04-11 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90052

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Blocks||87656

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> Reopening, as these warnings seem appropriate for -Wall

-Wlogical-op is not in -Wall or -Wextra due to bug 61534, bug 69602, and I
guess also bug 82240. At least those are those are the -Wlogical-op related
bugs blocking bug 87656...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
[Bug 87656] Useful flags to enable with -Wall or -Wextra

[Bug middle-end/64101] GCC considers that the erf math function does not set errno

2019-04-11 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88576,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=37073

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> possibly related to some of the other -fmath-errno bugs that have been under
> discussion lately?

i.e., bug 88576 and bug 37073

[Bug target/37073] -fno-math-errno should be the default on FreeBSD

2019-04-11 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37073

Eric Gallager  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |gerald at pfeifer dot 
com

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Gerald Pfeifer from comment #2)
> > I'll see what I can do about this.
> 
> Did you mean to put yourself as the assignee for this, instead of just on
> cc? I mean, since you changed the status to ASSIGNED...

Assuming yes and making Gerald the assignee

[Bug tree-optimization/81343] missing strlen optimization with intervening strcat of unknown strings

2019-04-11 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81343

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> See also pr81330 for another strlen optimization opportunity.

Well, and all other bugs blocking bug 83819 as well, that is

  1   2   3   4   5   6   7   8   9   10   >