[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
maybe try putting #pragma GCC system_header in your headers? idk

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

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

--- Comment #2 from Eric Gallager  ---
The name -Wordered-pointer-comparison was suggested for this warning here: 
https://gcc.gnu.org/ml/gcc-patches/2007-01/msg00608.html

[Bug c++/68897] No option to disable just "warning: enumeral and non-enumeral type in conditional expression"

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #1)
> You just need to come up with a good name and implement a patch like the
> ones shown in PR7651. Finding a good name is probably the hardest part. :)
> 
> 
> See also https://gcc.gnu.org/ml/gcc/2007-01/msg00391.html

>From that thread, it seems like the agreement was to put it under -Wconversion:
https://gcc.gnu.org/ml/gcc/2007-01/msg00437.html

[Bug debug/49348] DW_TAG_template_* DIEs missing from template specializations

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|WAITING
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg00873.htm
   ||l
 CC||egallager at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=41736

--- Comment #5 from Eric Gallager  ---
(In reply to Alexandre Oliva from comment #4)
> From Jason's feedback in response to the proposed patch, it looks like this
> is not a bug, after all, and GCC is working as intended.  Is there any
> reason for this bug to remain open?

WAITING on a reply to this

[Bug c++/57255] [meta-bug] ref-qualifiers

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
all the bugs that this one depends upon have been closed; can this one be
closed as well?

[Bug rtl-optimization/58036] [meta-bug] alias.c:base_alias_check says stack accesses with different base registers don't alias

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think the "Blocks" field might need to be swapped into the "Depends on"
field; normally meta-bugs depend on more bugs than they block.

[Bug target/69142] missing documentation for s/390 zvector builtin features

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Andreas, you put yourself as the assignee but didn't change the status to
ASSIGNED; was that intentional?

[Bug tree-optimization/81435] missing strlen optimization for strcat past the beginning of clear array

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

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> I think it means that Andrew is a maintainer of the overall tree-ssa
> infrastructure.  AFAIK, he has not done any work on the strlen optimizations
> in the file.  Jakub is the author of the pass so he knows the most about it.
> But he's also aware of most bugs that come in so I don't think he needs to
> be CC'd.
> 
> Most of the bugs I raised for the strlen pass are enhancements.  I noticed
> them while testing various warnings (-Wstringop-overflow, -Wrestrict, etc.)
> where they imply false negatives.  The optimizations themselves aren't
> necessarily critical to performance but the better the strlen pass is at
> optimizing stuff the better the warnings are at finding bugs.
> 
> I expect to be doing some work on the strlen pass for GCC 10 so I might pick
> up some of these bugs in the process.

It's GCC 10 now.

[Bug tree-optimization/81330] missing strlen optimization with intervening memcpy

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

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> You're right, I didn't consider this case.  When copying (strlen(s) + 1) or
> more bytes, d cannot point at the terminating NUL at (s + strlen(s)) because
> the copy would then overlap, so the transformation is only valid for such
> copies.  When copying fewer bytes than that (or when the number is unknown),
> it would not be valid.  Thanks for clarifying that!
> 
> So the missed optimization opportunity is in the "or more bytes" case, when
> GCC can also assume the NUL isn't overwritten.  I.e., a test case for it
> would be the same as the original in comment #0 except with a call to
> __builtin_memcpy (d, s, n0 + 2) in g() (or any constant or known N greater
> than 1).
> 
> Btw., the comment above handle_builtin_memcpy() in tree-ssa-strlen.c copied
> below hints that the constraint is deliberate but it doesn't explain why. 
> I'll see about adding some detail to it since I happen to be working in this
> area.

You still working in this area nowadays?

> 
> /* Handle a memcpy-like ({mem{,p}cpy,__mem{,p}cpy_chk}) call.
>If strlen of the second argument is known and length of the third argument
>is that plus one, strlen of the first argument is the same after this
>call.  */

[Bug c++/77796] tautological compare warning emitted for inherited static method comparisons

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

--- Comment #4 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Eric Gallager from comment #2)
> > (In reply to Eric Gallager from comment #1)
> > > Confirmed. Also, it seems weird that the warning underlines all of
> > > B::destroy, but only the "A" in A::destroy:
> > > 
> > > $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77796.cc
> > > 77796.cc:11:12: warning: self-comparison always evaluates to true
> > > [-Wtautological-compare]
> > >  B::destroy == A::destroy ? 0 : 1
> > >  ~~~^~~~
> > > $
> > 
> > Diagnostics maintainers, do you know what's up with that?
> 
> That was PR 87386, fixed on trunk.

Ah, so it is; output is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77796.cc
77796.cc:11:12: warning: self-comparison always evaluates to true
[-Wtautological-compare]
   11 | B::destroy == A::destroy ? 0 : 1
  | ~~ ^~ ~~
$

[Bug c++/64867] split warning for passing non-POD to varargs function from -Wconditionally-supported into new warning flag, -Wnon-pod-varargs

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #26 from Eric Gallager  ---
Martin Sebor has been doing stuff related to warnings about POD-ness lately;
cc-ing him

[Bug c++/80518] -Wsuggest-override does not warn about missing override on destructor

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

--- Comment #6 from Eric Gallager  ---
(In reply to Arnaud Desitter from comment #2)
> Interesting. Shame that there is no rationale.
> 
> I suppose that "-Wsuggest-override=2" could warn about "override" missing
> for destructor.

I'd just like to repeat my preference for named options over numeric warning
levels here; named options are separately controllable and thus more useful.
Maybe call it -Wsuggest-override-destructor instead?

[Bug c++/87274] -std=c++11 breaks quadmath macros

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

--- Comment #5 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Jonathan Wakely from comment #2)
> > (In reply to Patrick J. LoPresti from comment #0)
> > > Note that my code does not use any quad-precision literals; just the
> > > documented `FLT128_MAX` macro.
> > 
> > Which is a quad-precision literal, of course.
> > 
> > > I realize quadmath is more a C thing than a C++ thing... But it would
> > > still be nice if this worked, IMO.
> > 
> > It does work if you use the right options to allow the necessary extensions.
> > 
> > > On a possibly related note, writing "__extension__" before a
> > > quad-precision literal does not silence this error. Perhaps it should (?)
> > 
> > Yes, maybe. Confirming for that feature request.
> 
> 
> This is an error, not a warning nor a warning converted to an error.
> __extension__ silences warnings, it does not make something that should not
> compile into something that should compile.
> 
> However, the following should work and it doesn't:
> 
> // with -Wpedantic -std=gnu++11
> #include 
> __float128 x0 = FLT128_MAX; /* warn */
> __float128 x1 = __extension__ FLT128_MAX; /* no warn */

That sounds like bug 71003 (which apparently was already added as related from
the other end, but just making sure to mention it on this end as well, since I
filed it and would like to see it fixed)

[Bug bootstrap/77510] genautomata memory footprint for MIPS

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

Eric Gallager  changed:

   What|Removed |Added

 CC||mfortune at gmail dot com

--- Comment #2 from Eric Gallager  ---
cc-ing MIPS maintainer

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

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

Eric Gallager  changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu.org,
   ||mark at codesourcery dot com,
   ||steven at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
(In reply to Jorn Wolfgang Rennecke from comment #7)
> The patches have been tested & posted to gcc-patches:
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02492.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02452.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02495.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02618.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02645.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02649.html

cc-ing some people from these threads

[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
(In reply to qinzhao from comment #4)
> the patch has been committed into upstream as today.

So... FIXED then.

[Bug c/82922] Request: add -Wstrict-prototypes to -Wextra as K style is obsolescent

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

--- Comment #8 from Eric Gallager  ---
(In reply to Martin Sebor from comment #7)
> I posted a GCC 9 patch here:
>   https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00675.html
> 
> It adds -Wstrict-prototypes to -Wall.  Unfortunately, it got derailed by
> (IMO unsubstantiated) concerns about the impact on some poorly written
> configure tests.  I'll see if I can find the time to adjust the patch to
> enable the option only with -Wextra and convince the powers that be to
> accept it into GCC 9.

OK, timeframe for GCC 9 has passed; what about for GCC 10?

[Bug c/86418] warn about mismatch in type between argument and parameter type for declaration without prototype

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

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Sebor from comment #4)
> Confirmed.  My preference would be to resolve pr82922 and diagnose all calls
> to functions without a prototype.

Agreed.

> Short of that, this could be handled by saving the type of the first call to a
> function without a prototype in a translation unit, comparing it to the type 
> of
> each subsequent call, and warning if they don't match.

What about with LTO?

[Bug other/44032] internals documentation is not legally safe to use

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

--- Comment #7 from Eric Gallager  ---
Richard says the FSF doesn't object to combinations of GFDL code from the
manual with GPL code from the source and that we can put a statement to this
effect in the internals manual.

[Bug c/91092] Error on implicit function declarations by default

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
autoconf should generate #line markers in its conftests so gcc can generate
fix-its that point to the corresponding snippets in the configure.ac file (or
included m4 macro files). Of course, that would require making a new autoconf
release, which hasn't been done in years, so...

[Bug c++/89976] missing uninitialized warning: laundering via passing object through a function

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

--- Comment #1 from Eric Gallager  ---
could you be a bit more specific about which lines exactly you're expecting the
warnings to go on?

[Bug debug/78685] -Og generates too many ""s

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #17 from Eric Gallager  ---
Richard Sandiford had a series of patches radically overhauling how -Og works
in general that might affect this bug:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html
cc-ing him so he can comment on if it does in fact affect this bug.

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Gallager  ---
(In reply to Richard Biener from comment #6)
> Confirmed.  It was the original intent to allow this, esp. for libgfortran
> for example.

That's bug 77278

[Bug target/38629] target-specific parameters for inline heuristics not defined for AVR

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

--- Comment #11 from Eric Gallager  ---
(In reply to Federico Fissore from comment #8)
> I forgot to say: this result came out of avr-gcc 4.8.1 (packaged by Arduino:
> it's a 4.8.1 with two small patches applied [1]). It uses -Os optimization
> flag
> 
> [1] https://github.com/arduino/toolchain-avr/tree/master/gcc-patches

This link no longer works

[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jg at jguk dot org

--- Comment #9 from Eric Gallager  ---
This came up again on gcc-help here:
https://gcc.gnu.org/ml/gcc-help/2019-07/msg00014.html

[Bug c/79632] params.def should not contain redundant comments

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
What exactly is the harm of the redundancy? I don't think this is too big of an
issue...

[Bug fortran/79596] translation: argument to gfc_internal_error should not be translated

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2017-02-22 00:00:00 |2019-7-2
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Confirmed.

[Bug web/90334] documentation for getting read-write SVN access is misleading

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #5)
> Maybe just saying "sourceware.org / gcc.gnu.org" would be good enough to
> avoid confusion. That's obviously not a URL that you're supposed to copy &
> paste.

Yes, that would be an improvement.

[Bug c/91046] missing warning about empty translation unit

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
gcc warns for me:

$ echo "" >> empty.c
$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic empty.c
empty.c:1: warning: ISO C forbids an empty translation unit [-Wpedantic]
1 | 
  | 
$

For comparison, clang puts this under its own separate flag: 

$ clang -c -Wall -Wextra -pedantic empty.c
empty.c:1:1: warning: ISO C requires a translation unit to contain at least one
declaration [-Wempty-translation-unit]
^
1 warning generated.
$

So maybe it's worth splitting -Wempty-translation-unit off from -Wpedantic in
gcc too, so it's separately controllable?

[Bug target/90835] Incompatibilities with macOS 10.15 headers

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
(In reply to Jack Howarth from comment #8)
> Jeremy's comment on this issue was...
> 
> "Although frankly, it is well past time that GCC add support for these
> macros and attributes if they want to actually consider darwin a supported
> platform."
> 
> so I suspect upstream may expect FSF gcc to finally support these macros at
> this late date.

This would be a lot easier if Apple would let their employees contribute to
GPL3+-licensed projects. It's kind of unfair of them to keep introducing new
non-standard language features while expecting everyone else to add support for
them without actually putting in the work to see that support added.

[Bug target/80782] Configure options to use llvm/clang assembler on Mac

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

--- Comment #14 from Eric Gallager  ---
(In reply to Eric Gallager from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > AFAIK the use of the clang assembler (i.e. calling cctools as which then
> > spawns clang -cc1as) is working on all open branches (and on the closed 
> > 6.5).
> > 
> > please could you be more specific about exactly what's not working?
> >  - i.e if you're on an older version of the OS.
> >  - version of Xcode.
> > 
> > Note that the default for which assembler backend is called does depend on
> > the Xcode version.
> 
> This is probably material for a separate bug, but the MacPorts package for
> GCC 8 uses the clang assembler from the clang-3.4 port on my system, and
> apparently all includes flags get passed to it, so it prints out all sorts
> of messages like:
> 
> clang: warning: argument unused during compilation: '-I .'
> 
> when compiling with it. The driver specs might need to be hacked to stop
> passing '-I' flags to the assembler that it won't use. Currently I'm working
> around it by prefixing all '-I' flags with '-Wp,' so that only the
> preprocessor sees them, but that doesn't work for other tools (e.g. splint)
> that accept '-I' flags but not '-Wp,' flags. It also breaks fortran-style
> includes in gfortran since apparently they're different from the kind seen
> in the C preprocessor.

Note that these excess warnings cause so many testsuite fails that the
resulting log becomes too big to mail to the gcc-testresults mailing list.
(3.4MB!)

[Bug jit/64196] No automated test coverage for debugging of JIT-generated code

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

Eric Gallager  changed:

   What|Removed |Added

   Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Eric Gallager from comment #2)
> > (In reply to David Malcolm from comment #0)
> > > gcc/jit/docs/intro/tutorial04.rst shows an example of debugging,
> > > single-stepping through JIT-generated code in gdb [1].
> > > 
> > > This was all tested by hand.  We don't yet have any automated test 
> > > coverage
> > > to verify that this works.
> > > 
> > > [1]: built HTML version of this currently here:
> > > https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/intro/tutorial04.
> > > html#single-stepping-through-the-generated-code
> > 
> > Are you still working on this?
> 
> Guess not; unassigning

Er, doing it right this time...

[Bug jit/66074] gcc_jit_result_get_code returns a void*

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> David, are you the assignee on this because you're actually working on it,
> or just because that's the default for bugs filed under the "jit" component?

guess it's the latter; moving from assignee to cc

[Bug bootstrap/11799] The toplevel should handle multi-libs.

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

--- Comment #6 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Nathanael Nerode already said that he is working on it
>  07/msg01872.html> so reassign this bug to him.

repasting the link so it's clickable:
http://gcc.gnu.org/ml/gcc/2003-07/msg01872.html

[Bug c++/61339] add mismatch between struct and class [-Wmismatched-tags] to non-bugs

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> Regardless of compatibility with MS, writing code consistently makes things
> easier for human readers to follow, and should be encouraged. At least IMO.

Apparently Martin Sebor agrees and has started work on a similar warning:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01853.html

[Bug fortran/35276] Doc should described how to compile mixed-language programs

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

--- Comment #7 from Eric Gallager  ---
(In reply to Thomas Koenig from comment #6)
> (In reply to Eric Gallager from comment #5)
> > (In reply to Jürgen Reuter from comment #4)
> > > It seems that at least Thomas and Dominique believe that this can be 
> > > closed.
> > 
> > with which status?
> 
> We need to extend that chapter with the new status for gcc 9 after
> Paul's fixes have all gone in.
> 
> After that, I we should close this as FIXED.

Have Paul's fixes all gone in yet?

[Bug c++/71637] -Wmisleading-indentation only triggered when using integrated cpp

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing other diagnostics maintainer (i.e. besides David, since he's already on
this)

[Bug middle-end/47307] Uninitialized in this function: warning for initialized, no warning for uninitialized

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

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 target/52154] va_arg with empty aligned structure fails for MIPS EABI32

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||xfail

--- Comment #4 from Eric Gallager  ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> (In reply to Eric Gallager from comment #2)
> > Did this fix it?
> 
> No, I had to XFAIL the test for EAB32, and this PR was to keep track of that.
> At this stage I'm not sure whether anyone's ever likely to fix it though. :-)

ah ok, adding the xfail keyword then

[Bug other/60548] [libvtv/scripts/sum-vtv-counts.c:108]: (warning) scanf without field width limit s can crash with huge input data.

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

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> This file is never compiled so it is very minor.

Why does it even exist then?

[Bug libstdc++/81670] include/ext/pb_ds/detail/splay_tree_/splay_fn_imps.hpp:253: suspicious assignment ?

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

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> What's broken? Is there an actual bug or just a redundant assignment?
> 
> (I'm unaware of anybody anywhere ever using these containers so it's hardly
> a priority)

You said you were thinking about removing them, right?

[Bug rtl-optimization/82338] valgrind error in inherit_in_ebb

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Vladimir Makarov from comment #3)
> > Author: vmakarov
> > Date: Fri Sep 29 17:15:24 2017
> > New Revision: 253299
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=253299=gcc=rev
> > Log:
> > 2017-09-29  Vladimir Makarov  
> > 
> > PR rtl-optimization/82338
> > * lra-constraints.c (inherit_in_ebb): Check usage_insns check.
> > 
> > 
> > Modified:
> > trunk/gcc/ChangeLog
> > trunk/gcc/lra-constraints.c
> 
> Did this fix it?

WAITING on a reply

[Bug target/52154] va_arg with empty aligned structure fails for MIPS EABI32

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to rsand...@gcc.gnu.org from comment #1)
> Author: rsandifo
> Date: Tue Feb  7 19:15:10 2012
> New Revision: 183977
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=183977
> Log:
> gcc/
>   PR middle-end/24306
>   * config/mips/mips.c (mips_std_gimplify_va_arg_expr): New function.
>   (mips_gimplify_va_arg_expr): Call it instead of
>   std_gimplify_va_arg_expr.
> 
> gcc/testsuite/
>   PR middle-end/24306
>   PR target/52154
>   * lib/target-supports.exp (check_effective_target_mips_eabi): New.
>   * gcc.target/mips/va-arg-1.c: New test.
> 
> Added:
> trunk/gcc/testsuite/gcc.target/mips/va-arg-1.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/mips/mips.c
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/lib/target-supports.exp

Did this fix it?

[Bug c/72783] Fortify scanf %s, %[ conversion specifiers

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
ASSIGNED since there's an assignee

[Bug preprocessor/79346] -Wundef should not warn for standard macros

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> Confirmed, although it's pretty easy to work around, just write:
> 
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ < 199901L
> #endif
> 
> instead.

Ah, upon revisiting, I see this was already addressed in the gcc-help thread
linked, so never mind then.

[Bug c++/59552] Warning when non-trivial type parameter is passed by value but not changed in function

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

Eric Gallager  changed:

   What|Removed |Added

 Blocks||87403

--- Comment #4 from Eric Gallager  ---
Presumably this warning would go under a new flag, so making it 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++/47342] misleading diagnostic for member of undeclared class template partial specialization

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

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 debug/82738] [meta-bug] issues with the -Og optimization level

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Richard Sandiford has a series of patches radically overhauling how -Og works:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html
cc-ing him so he can comment on how it affects some of the bugs listed as
dependencies here.

[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses

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

--- Comment #1 from Eric Gallager  ---
I see Martin Liska added a bunch of bugs found by the clang static analyzer as
blocking this... Martin, did you verify that cppcheck catches them, too, or are
we using this bug for static analyzers in general now? It's ok if it's the
latter, we'll just need to update the title...

[Bug target/545] -std=c89 defines macros it shouldn't

2019-06-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=545

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #17 from Eric Gallager  ---
(In reply to Ben Elliston from comment #16)
> Not much has changed.  For r131688:
> 
> ./ptx4.h
> ./svr4.h
> ./cris/aout.h
> ./rs6000/aix53.h
> ./rs6000/aix51.h
> ./rs6000/aix52.h
> ./rs6000/aix43.h
> ./rs6000/aix41.h
> ./i386/sco5.h

This first batch of headers no longer exists.

> ./sol2.h

In this header, the check for "ansi" also checks for "std=c" and "std=i" so I
think that means it should be considered fixed.

> ./rs6000/sysv4.h

This header no longer references "ansi" so it can be ignored.

> ./rs6000/aix.h
> ./i386/cygwin.h

These last 2 headers still need to be fixed.

[Bug c++/58999] sizeof ...(T) is very slow than clang

2019-06-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58999

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #5)
> Probably a meta-bug about this sort of issue would also make sense. We have
> got a few bugs already.

Which ones do you mean?

[Bug fortran/52274] [Meta-bug] Fortran translation related issues: Typos and more

2019-06-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52274

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Are the "Depends on" and "Blocks" fields swapped here? Normally meta-bugs
depend on more bugs than they block

[Bug tree-optimization/18374] [meta-bug] Argument and return value marshalling at tree level

2019-06-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18374

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=15484
 Blocks|16797, 16802|
 Depends on||16797, 16802

--- Comment #3 from Eric Gallager  ---
I think this is another one of those meta-bugs that falls victim to the change
in the way meta-bugs are done; swapping the "blocks" and "depends on" fields


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16797
[Bug 16797] Opportunity to remove unnecessary load instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16802
[Bug 16802] PowerPC - Unnecessary extsw

[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"

2019-06-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808

--- Comment #9 from Eric Gallager  ---
(In reply to sduguay from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > In any case, I agree with confirming this as a bug: all warnings should be
> > controllable by a -Wxxx option.
> > 
> > Adding such an option is quite easy, and a good first contribution to GCC.
> > For an example of adding a new option see https://gcc.gnu.org/r192968
> 
> I was going to propose looking into it. I'll try to find some time.

Have you found some time yet?

[Bug debug/47819] [meta-bug] LTO debug information issues

2019-06-25 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Gallager  ---
(In reply to rguent...@suse.de from comment #2)
> On Tue, 25 Jun 2019, egallager at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819
> > 
> > Eric Gallager  changed:
> > 
> >What|Removed |Added
> > 
> >  Status|NEW |WAITING
> >          CC|    |egallager at gcc dot 
> > gnu.org
> > 
> > --- Comment #1 from Eric Gallager  ---
> > All the bugs that this one depends upon have been closed, ok to close this 
> > too?
> 
> Please leave it open.

OK.

[Bug debug/47819] [meta-bug] LTO debug information issues

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
All the bugs that this one depends upon have been closed, ok to close this too?

[Bug middle-end/23409] [meta-bug] data dependence analyzer (BAD vs. BOP)

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
None of the bugs that this one depends upon are still open. Is it ok to close
this?

[Bug rtl-optimization/66204] [MIPS] LRA: Non-optimal code / regression

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||ra
 CC||kyukhin at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Robert Suchanek from comment #0)
> 
> LRA is now inserting unnecessary reloads and I tracked it down to r216154

cc-ing author of that commit

[Bug tree-optimization/19347] Invariant load not moved out of loop

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

--- Comment #7 from Eric Gallager  ---
(In reply to Richard Biener from comment #6)
> Reconfirmed.  Note we do vectorize the loop now but we add a runtime check
> for the aliasing (and not move the invariant out either).

So wait if the vectorization part is done now, then why did you make this block
the vectorizer meta-bug? I mean, if that's the part that works and it's only
the other stuff that's still in need of fixing...

[Bug tree-optimization/90906] diagnose returning pointers to freed memory

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-18
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80532
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed. Related to bug 80532

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

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

--- Comment #16 from Eric Gallager  ---
I think David's original suggestion of -Wexclusive-or is the best name so far.

[Bug middle-end/88518] Function call defeats -Wuninitialized

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

--- Comment #4 from Eric Gallager  ---
Note that if h() has __attribute__((pure)) or __attribute__((const)) on it, you
then get the -Wuninitialized warning as expected. Of course, then you also get
a warning from -Wattributes about pure or const being used on a function
returning void, too...

[Bug c/81665] Please introduce flags attribute for enums which will mimic one from C#

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

--- Comment #6 from Eric Gallager  ---
Note that clang has __attribute__((flag_enum)):
https://clang.llvm.org/docs/AttributeReference.html#flag-enum

[Bug libquadmath/58327] Problem of quadmath in connection with SDL2

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-06-16
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=51007
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
(In reply to Kai Tietz from comment #5)
> This sounds a bit like an issue with OP-specific invocation of ld. How are
> you invoke the linker?

WAITING on a reply to this

[Bug objc++/85335] Possible misuse of 'lang_GNU_OBJC' in 'default_floatn_builtin_p'

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to avshash from comment #0)
> In function 'default_floatn_builtin_p' at 'gcc/targhooks.c'.
> Using the lang_GNU_OBJC query that returns TRUE when the language is either
> Objective C, or Objective C++ (documentation in 'langhooks.c' implementation
> is wrong).
> According to documentation, the test is for Objective C only.
> Need to either clariffy the documentation, or replacte the function call with
> "(strcmp ("GNU Objective-C", lang_hooks.name) == 0)"

Could you give a bit more context? Why is this an issue?

[Bug other/43748] build machinery insufficient for installing target specific .def files as plugin headers

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

Eric Gallager  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
since this is at least somewhat Darwin-related, cc-ing Iain...

[Bug tree-optimization/46029] -ftree-loop-if-convert-stores causes FAIL: libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc

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

--- Comment #7 from Eric Gallager  ---
the pb_ds directory might be removed in the future; might want to retitle this
to clarify that the underlying issue is actually in the compiler and the pb_ds
testcase only happens to expose it, so that this bug doesn't get closed when
the removal happens...
(assuming my read of the issue is right)

[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable

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

--- Comment #7 from Eric Gallager  ---
(In reply to Uroš Bizjak from comment #0)
> > >> It can be done ultimately, but as a prerequisite, we should have
> > >> warnings in -Wextra for all of
> > >>
> > >> ? boolvar++; ++boolvar;
> > >> ? boolvar--; --boolvar;
> > >> ? boolvar = nonbool;
> > >> ? boolvar & nonbool; boolvar &= nonbool;
> > >> ? boolvar | nonbool; boolvar |= nonbool;
> > >> ? boolvar ^ nonbool; boolvar ^= nonbool;
> > >
> > > Fair enough. I have CCed Manuel, perhaps he is interested in this warning.
> > 
> > I am not sure it fits in -Wconversion. -Wbool-arith perhaps?
> 

I made a testcase that includes all of those:

$ cat 45780.c
#include 
#include 

static bool f1(int i)
{
  return i;
}

static bool f2(int i)
{
  i = !!i;
  return i;
}

int main(int argc, char **argv)
{
  bool a = true;
  bool b = a++;
  bool c = ++b;
  bool d = argc;
  bool e = a & argc;
  bool f = b | argc;
  bool g = c ^ argc;
  f &= argc;
  g |= argc;
  e ^= argc;
  if (f1(argc))
e--;
  else
--e;
  if (!!argc)
return ((argv != NULL) ? d : ((f > g) ? e : (f << g)));
  else
return f2(argc);
}
$

gcc's -Wbool-operation currently catches the increments and decrements, but
none of the rest of the operations:

$ /usr/local/bin/gcc -c -Wall -Wextra -Wbool-compare -Wint-in-bool-context
-Wparentheses -pedantic -Wconversion 45780.c
45780.c: In function 'main':
45780.c:18:13: warning: increment of a boolean expression [-Wbool-operation]
   18 |   bool b = a++;
  | ^~
45780.c:19:12: warning: increment of a boolean expression [-Wbool-operation]
   19 |   bool c = ++b;
  |^~
45780.c:28:6: warning: decrement of a boolean expression [-Wbool-operation]
   28 | e--;
  |  ^~
45780.c:30:5: warning: decrement of a boolean expression [-Wbool-operation]
   30 | --e;
  | ^~
$

[Bug target/34484] libgcc should check if feclearexcept (and others) available for BID support on uclibc

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

--- Comment #15 from Eric Gallager  ---
(In reply to Bernhard Reutner-Fischer from comment #8)
> From FSFChangelog.10:
> Mon Feb 12 20:42:11 1996  Randy Smith  
>

Does Randy have a Bugzilla account that could be cc-ed here?

[Bug c/86157] Wmisleading-indentation disabled after a #line directive

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing author of -Wmisleading-indentation

[Bug c/88000] Warn when different local vars regs order may produce different and so unsupported code [-Wasm-register-var]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Keywords||diagnostic
   Last reconfirmed||2019-06-15
 CC||egallager at gcc dot gnu.org
 Resolution|INVALID |---
 Blocks||87403
 Ever confirmed|0   |1
Summary|Different local vars regs   |Warn when different local
   |order may produce different |vars regs order may produce
   |and so wrong code   |different and so
   ||unsupported code
   ||[-Wasm-register-var]

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Sebor from comment #4)
> GCC could help by issuing a warning for unsupported uses, like in the
> prototype patch below:
> 
> Index: gcc/c/c-typeck.c
> ===
> --- gcc/c/c-typeck.c  (revision 266033)
> +++ gcc/c/c-typeck.c  (working copy)
> @@ -6505,6 +6505,14 @@ convert_for_assignment (location_t location, locat
>objc_ok = objc_compare_types (type, rhstype, parmno, rname);
>  }
>  
> +  if (VAR_P (rhs) && DECL_HARD_REGISTER (rhs)
> +  && warning_at (expr_loc, OPT_Wasm_register_var,
> +  "unsupported use of a hard register %qD as "
> +  "argument %d of %qE",
> +  rhs, parmnum, rname))
> +inform (DECL_SOURCE_LOCATION (rhs),
> + "%qD declared here", rhs);
> +
>if (warn_cxx_compat)
>  {
>tree checktype = origtype != NULL_TREE ? origtype : rhstype;
> Index: gcc/c-family/c.opt
> ===
> --- gcc/c-family/c.opt(revision 266033)
> +++ gcc/c-family/c.opt(working copy)
> @@ -338,6 +338,10 @@ Warray-bounds=
>  LangEnabledBy(C ObjC C++ LTO ObjC++,Wall,1,0)
>  ; in common.opt
>  
> +Wasm-register-var
> +ObjC ObjC++ Var(warn_asm_register_var) Warning LangEnabledBy(C ObjC C++
> ObjC++, Wall)
> +Warn for unsupported uses of variables declared asm register.
> +
>  Wassign-intercept
>  ObjC ObjC++ Var(warn_assign_intercept) Warning
>  Warn whenever an Objective-C assignment is being intercepted by the garbage
> collector.

Reopening to confirm the part about this warning request at least


Referenced Bugs:

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

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

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

Bug 88000 Summary: Warn when different local vars regs order may produce 
different and so unsupported code [-Wasm-register-var]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88000

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'

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

Eric Gallager  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-06-14
 CC||egallager at gcc dot gnu.org
 Resolution|WORKSFORME  |---
 Ever confirmed|0   |1

--- Comment #5 from Eric Gallager  ---
(In reply to Rich Felker from comment #2)
> This does seem to be real, so please reopen it. 

(In reply to Dima Krasner from comment #3)
> Please re-open this bug. 

OK.

[Bug libgomp/57298] GOMP_CPU_AFFINITY will not work when system has >1024 cores

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #2)
> Author: jakub
> Date: Tue Oct  1 14:49:36 2013
> New Revision: 203064
> 
> URL: http://gcc.gnu.org/viewcvs?rev=203064=gcc=rev
> Log:
>   PR libgomp/57298
>   * config/linux/proc.c (gomp_cpuset_size, gomp_cpusetp): New variables.
>   (gomp_cpuset_popcount): Use CPU_COUNT_S if available, or CPU_COUNT if
>   gomp_cpuset_size is sizeof (cpu_set_t).  Use gomp_cpuset_size instead
>   of sizeof (cpu_set_t) to determine number of iterations.
>   (gomp_init_num_threads): Initialize gomp_cpuset_size and gomp_cpusetp
>   here, use gomp_cpusetp instead of  and pass gomp_cpuset_size
>   instead of sizeof (cpu_set_t) to pthread_getaffinity_np.
>   (get_num_procs): Don't call pthread_getaffinity_np if gomp_cpusetp
>   is NULL.  Use gomp_cpusetp instead of  and pass gomp_cpuset_size
>   instead of sizeof (cpu_set_t) to pthread_getaffinity_np.
>   * config/linux/proc.h (gomp_cpuset_popcount): Add attribute_hidden.
>   (gomp_cpuset_size, gomp_cpusetp): Declare.
>   * config/linux/affinity.c (CPU_ISSET_S, CPU_ZERO_S, CPU_SET_S): Define
>   if CPU_ALLOC_SIZE isn't defined.
>   (gomp_init_affinity): Don't call pthread_getaffinity_np here, instead
>   use gomp_cpusetp computed by gomp_init_num_threads.  Use CPU_*_S
>   variants of macros with gomp_cpuset_size as set size, for cpusetnew
>   use alloca for it if CPU_ALLOC_SIZE is defined, otherwise local
>   fixed size variable.
>   (gomp_init_thread_affinity): Use CPU_*_S variants of macros with
>   gomp_cpuset_size as set size, for cpuset use alloca for it if
>   CPU_ALLOC_SIZE is defined, otherwise local fixed size variable.
> 
> Modified:
> branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
> branches/gomp-4_0-branch/libgomp/config/linux/affinity.c
> branches/gomp-4_0-branch/libgomp/config/linux/proc.c
> branches/gomp-4_0-branch/libgomp/config/linux/proc.h

Did this fix it?

(also I'm kind of jealous of anyone with a computer with that many cores...)

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #39 from Eric Gallager  ---
(In reply to Richard Biener from comment #35)
> Let's try "fixing" this finally for GCC 6.

Uh... for GCC 10 now?

[Bug rtl-optimization/25609] too agressive printf optimization

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

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=15574,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=15685,
   ||http://sourceware.org/bugzi
   ||lla/show_bug.cgi?id=5618

--- Comment #23 from Eric Gallager  ---
(In reply to Ulrich Drepper from comment #6)
> This is NOT a dup of 15574.

ok, but related enough to go under "See Also" though

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-14
 CC||egallager at gcc dot gnu.org
 Blocks||87403
 Ever confirmed|0   |1

--- Comment #9 from Eric Gallager  ---
Confirmed. More discussion from that thread about possible heuristics for the
warning: https://twitter.com/elwoz/status/1139522678396784642
* restricting it to just decimal literals probably makes sense, if someone is
using the 0x or 0b prefix, they probably are in fact intending to do
bit-twiddling with xor
* the "not from the expansion of ’s xor macro" criterion I can see
possibly being a difficulty, due to how many other bugs there are about gcc's
handling of macros from system headers...


Referenced Bugs:

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

[Bug c/61939] warn when __attribute__((aligned(x))) is ignored

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

--- Comment #4 from Eric Gallager  ---
(In reply to Daniel Santos from comment #2)
> (In reply to Vedran Miletic from comment #1)
> > #include 
> > #include 
> > float f(std::vector& A, std::vector& B)
> > {
> >   __builtin_assume_aligned(A.data(), 64);
> >   __builtin_assume_aligned(B.data(), 64);
> >   return std::inner_product(A.begin(), A.end(), B.begin(), 0.f);
> > }
> 
> You are doing it wrong. __builtin_assume_aligned() returns void* and you
> must use it's return value for it to be effective. 

Sounds like __builtin_assume_aligned() should be marked up with
__attribute__((warn_unused_result))

[Bug ipa/90874] trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ?

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
This is cppcheck, right? Assuming so...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
[Bug 89863] [meta-bug] Issues that cppcheck finds that gcc misses

[Bug bootstrap/46981] multilib LD_LIBRARY_PATH prevents configuration of target libraries

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

Eric Gallager  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Edelsohn from comment #0)
> config-ml.in adjusts LD_LIBRARY_PATH for multilib target libraries.  This
> apparently was introduced to ensure that applications created by configure
> in multilib directories find the correct libraries:
> 
> http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00666.html
> 

cc-ing Alex and Jeff from that thread

[Bug target/90834] Header and startup objects not found on macOS 10.15

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
possible dup of bug 90808?

[Bug c++/60972] Mixing #pragma pack and __attribute__((packed)) leads to spurious warnings.

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

Eric Gallager  changed:

   What|Removed |Added

 Blocks||44209

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> Confirmed. Another problem with the warnings is that there's no flag
> controlling them. I'd expect one of -Wno-packed, -Wno-attributes, or
> -Wno-ignored-attributes to disable the warning, but none of them do so.

That part makes this fall under 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 sanitizer/85777] [7/8/9/10 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

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

--- Comment #11 from Eric Gallager  ---
(In reply to Vincent Lefèvre from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > That is not true, automake is highly customizable, you can e.g. override
> > COMPILE/LTCOMPILE variables in Makefile.am or something similar.
> 
> The issue is that what COMPILE/LTCOMPILE should contain is not specified, so
> that it is impossible to write a replacement that will be guaranteed to work
> in a portable way.
> 
> For instance, the following is generated:
> 
> LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> $(AM_CFLAGS) $(CFLAGS)
> 
> but the AM_V_lt variable is nowhere documented. Thus replacing
> COMPILE/LTCOMPILE would require the developer to use obscure internals. I
> will never do that!
> 
> Anyway, this would not be these variables that one would need to change, but
> the Make rules that invoke the compiler, like:
> 
> .c.o:
> $(AM_V_CC)depbase=`echo $@ | sed
> 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
> $(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
> $(am__mv) $$depbase.Tpo $$depbase.Po
> #   $(AM_V_CC)source='$<' object='$@' libtool=no \
> #   DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
> #   $(AM_V_CC_no)$(COMPILE) -c -o $@ $<
> 
> But this is even worse: more internals, more code that is
> platform-dependent...

The lack of specification/documentation sounds more like a bug with
automake/libtool than with anything under GCC's control. I'd suggest reporting
the issue to automake/libtool instead, but they're not exactly very actively
maintained these days, so... YMMV.

[Bug tree-optimization/47770] wrong code -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc

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

Eric Gallager  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Zdenek Sojka from comment #1)
> "-ftree-loop-if-convert -fno-tree-reassoc -fno-tree-vectorize" gives about
> 316 exec failures on current trunk. I should try the fix for PR46029 from
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01613.html

cc-ing Richard from that thread

(In reply to Sebastian Pop from comment #2)
> I do not think that 0001-Fix-PR46029-reimplement-if-convert-stores.patch
> is the right way to fix this: I discussed with Ira Rosen

cc-ing Ira

[Bug bootstrap/90808] gcc fails to build/bootstrap with XCode 10.2.1

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
I think the -Wunused-parameter is a red herring; the real error looks to me to
be:

ld: library not found for -ldylib1.10.5.o
collect2: error: ld returned 1 exit status

[Bug c++/52281] No warnings generated for unused captures

2019-06-09 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52281

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Blocks||89180, 87403

--- Comment #2 from Eric Gallager  ---
clang puts this under -Wunused-lambda-capture:

$ clang++ -c -Wall -Wextra 52281.cc
52281.cc:9:14: warning: lambda capture 'i' is not used
[-Wunused-lambda-capture]
  auto x = []() {return 25;};
~^
1 warning generated.
$


Referenced Bugs:

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

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

2019-06-09 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #35 from Eric Gallager  ---
(In reply to Matthias Klose from comment #34)
> Author: doko
> Date: Sun Mar 10 07:25:13 2019
> New Revision: 269546
> 
> URL: https://gcc.gnu.org/viewcvs?rev=269546=gcc=rev
> Log:
> gcc/cp/
> 
> 2019-04-10  Matthias Klose  
> 
>   Backport from the gcc-8 branch
>   2019-03-07  Jakub Jelinek  
> 
>   PR c++/89585
>   * parser.c (cp_parser_asm_definition): Parse asm qualifiers even
>   at toplevel, but diagnose them.
> 
> gcc/testsuite/
> 
> 2019-04-10  Matthias Klose  
> 
>   Backport from the gcc-8 branch
>   2019-03-07  Jakub Jelinek  
> 
>   PR c++/89585
>   * g++.dg/asm-qual-3.C: Adjust expected diagnostics.
> 
> Modified:
> branches/gcc-7-branch/gcc/cp/ChangeLog
> branches/gcc-7-branch/gcc/cp/parser.c
> branches/gcc-7-branch/gcc/testsuite/ChangeLog
> branches/gcc-7-branch/gcc/testsuite/g++.dg/asm-qual-3.C

Is this fixed now?

[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'

2019-06-09 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794

--- Comment #5 from Eric Gallager  ---
(In reply to coypu from comment #4)
> Hi,
> 
> It's probably a setup/configuration issue for everyone reporting this issue.
> It's hard to debug, my patch helps with figuring out the problem - but
> doesn't fix it.
> 
> I didn't ping this bug report because I don't understand what the other
> patch described here does.

The patch described here appears to simply add a rule to create auto-build.h
from the Makefile; as Marcin said, though, it might not be correct... probably
worth continuing to pursue your own patch separately...

[Bug tree-optimization/41647] Early Loop Unrolling control

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

Eric Gallager  changed:

   What|Removed |Added

 CC||grosser at gcc dot gnu.org,
   ||spop at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
cc-ing graphite maintainers

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-06/msg00471.ht
   ||ml
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90764

--- Comment #5 from Eric Gallager  ---
thread for a patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00471.html

[Bug target/30829] extra register zero extends on x86_64

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Rask Ingemann Lambertsen from comment #2)
> It's not unusual to need more than one instruction pattern for the same
> machine instruction. See
> http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01318.html> and the
> followup for a recent example and what you can do about it.

message mentions bug 31985; assuming that's related here, too

[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch

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

--- Comment #5 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #3)
> Marek, would you like to implement this for GCC 10?

(In reply to Marek Polacek from comment #4)
> I can try, sure.

It's GCC 10 now.

[Bug other/46489] tree optimizer and frontend files use target macros

2019-06-06 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #10 from Eric Gallager  ---
(In reply to Eric Gallager from comment #9)
> (In reply to Joseph S. Myers from comment #7)
> > FWIW, the following files include tm.h and appear not to have any direct
> > uses of target macros, or uses of the most common headers (such as rtl.h or
> > cp-tree.h) that depend on tm.h.  They require more careful checks of what
> > headers they are using for any hidden tm.h dependencies, but may be good
> > candidates for the removal of tm.h includes.
> > 
> > gcc/java/except.c
> > gcc/java/jvgenmain.c
> > gcc/java/jvspec.c
> > gcc/java/mangle.c
> > gcc/java/zextract.c
> 
> I don't know about the rest of them, but these at least are gone.

I checked for other removals:

(In reply to Joseph S. Myers from comment #7)
> gcc/c-aux-info.c
> gcc/c-convert.c
> gcc/c-errors.c
> gcc/c-lang.c
> gcc/c-parser.c

These have all been moved to gcc/c/

> gcc/cppspec.c

This has been moved to gcc/c-family/

> gcc/tree-nomudflap.c
> gcc/tree-optimize.c
> gcc/tree-ssa-copyrename.c

These 3 appear to have been removed.

[Bug debug/24551] [meta-bug] -feliminate-unused-debug-types issues

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

--- Comment #3 from Eric Gallager  ---
(In reply to Richard Biener from comment #2)
> But this meta-bug is about -feliminate-unused-debug-types, not -decls.

oh sorry, I misread, nvm then...

[Bug rtl-optimization/22568] Should use cmov in some stituations

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

--- Comment #14 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #12)
> I have a patch to tree-ssa-phiopt.c to fix comment #1 though it needs
> another patch to expr.c to produce the cmov directly from COND_EXPR.  I hope
> to post both patches for 4.8.0.

Did you ever post them?

[Bug debug/24551] [meta-bug] -feliminate-unused-debug-types issues

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

Eric Gallager  changed:

   What|Removed |Added

 CC||patrickdepinguin at gmail dot 
com,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
-feliminate-unused-debug-symbols recently became the default, so these issues
are a little more important now:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02089.html

[Bug preprocessor/66505] -Wno-error=pedantic does not reverse -Werror -Wpedantic

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords|easyhack|

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Liška from comment #4)
> (In reply to Martin Liška from comment #3)
> > I believe I'll fix it once patch for PR89051 will be merged.
> 
> Apparently it's more comlicated.

Darn. Removing the "easyhack" keyword then...

[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.

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

--- Comment #12 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #10)
> (In reply to Eric Gallager from comment #9)
> 
> Not much has changed. There's LRA now, so for targets using LRA
> things may now work. 

That's most targets...

[Bug c/65403] -Wno-error= is an error

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

--- Comment #12 from Eric Gallager  ---
(In reply to Alex Henrie from comment #11)
> Created attachment 45889 [details]
> Proposed patches
> 
> I fixed up the patch from comment 4 and added a second patch with tests. Now
> I'm just waiting to receive a copyright assignment form.

It's been a bit... have you received your copyright assignment form yet?

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

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

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=89260,
   ||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=24567

--- Comment #7 from Eric Gallager  ---
(In reply to ohaiziejohwahkeezuoz from comment #5)
> Since the assertion is in `ld`, I've also reported the issue with some new
> details here https://sourceware.org/bugzilla/show_bug.cgi?id=24567

This was fixed.

  1   2   3   4   5   6   7   8   9   10   >