https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82646
Bug ID: 82646
Summary: bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on
strncpy with range to a member array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61593
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82645
Bug ID: 82645
Summary: missing -Wstringop-overflow on strcpy overflowing a
member array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839
--- Comment #7 from Eric Gallager ---
(In reply to Paolo Carlini from comment #6)
> Maybe time to actually send something to gcc-patches for discussion?
Please do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #10 from Hannes Hauswedell ---
> Could you please tell us the FreeBSD version and arch you run on?
uname -ra
FreeBSD celegans.imp.fu-berlin.de 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309:
Fri Jul 21 02:08:28 UTC 2017
r...@releng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644
--- Comment #1 from Jonathan Wakely ---
While I'm on the subject, we fail to import the special functions into the
global namespace in (because the wrong macro is checked):
#include
namespace test {
using std::beta; // OK
using ::beta;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644
Bug ID: 82644
Summary: Non-standard hypergeometric special functions defined
in strict modes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: rejects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82644
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59276
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82633
--- Comment #8 from Andrew Pinski ---
You might need -fkeep-static-functions also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82633
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096
--- Comment #6 from Dominique d'Humieres ---
I get
gA%next(): 2
gA%next(): 4
gA%next(): 6
gAp%next(): 2
gAp%next(): 4
gAp%next(): 6
for 4.8 up to trunk (8.0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478
--- Comment #8 from Dominique d'Humieres ---
> The test case in comment 0 and comment 3 are invalid in Fortran 2003;
> I think they are valid in Fortran 2008 (cf. PR 48858 comment 9). However,
> I need a quiet moment to disentangle the standard s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82622
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81924
--- Comment #9 from Bill Schmidt ---
Er, HERE is the simple patch:
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 253957)
+++ gcc/config/rs6000/vsx.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81924
--- Comment #8 from Bill Schmidt ---
Matthias, the following appears to fix this problem for gcc-5-branch.
Obviously the branch is closed to further development, but if you want to
consider carrying this patch, let me know and I will give it a f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81924
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82643
--- Comment #3 from bastien penavayre ---
Created attachment 42427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42427&action=edit
source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82643
--- Comment #2 from bastien penavayre ---
wrong file attached, see second comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82643
--- Comment #1 from bastien penavayre ---
Comment on attachment 42426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42426
source code
int main()
{
struct A
{
constexpr int operator()() const { return 42; }
};
auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82643
Bug ID: 82643
Summary: lambda capture breaks constexpr-ness of non-static
const constexpr member call on non-constexpr
value/variable
Product: gcc
Version: 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #9 from Andreas Tobler ---
Could you please tell us the FreeBSD version and arch you run on?
uname -ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82268
Daniel Santos changed:
What|Removed |Added
CC||daniel.santos at pobox dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80985
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82640
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
--- Comment #10 from Jakub Jelinek ---
Testcase for determining the sbbb and adcb behavior for all operands:
int
main (void)
{
int cf, x, y;
for (cf = 0; cf < 2; cf++)
for (x = 0; x <= 255; x++)
for (y = 0; y <= 255; y++)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81924
--- Comment #6 from Bill Schmidt ---
The patch applies cleanly to gcc-6-branch, and I can certainly commit that
(although I can't show a case where it can happen with present behavior, it
should be cleaned up).
For gcc-5-branch, the patch doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82642
Bug ID: 82642
Summary: Dynamic predicate for a record should give a warning
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79795
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79795
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Fri Oct 20 19:26:35 2017
New Revision: 253956
URL: https://gcc.gnu.org/viewcvs?rev=253956&root=gcc&view=rev
Log:
2017-10-20 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
--- Comment #9 from Jakub Jelinek ---
So, for the -1UL <= 1UL comparison, the cmpl instruction sets the CF, and then
sbbl subtracts -1U (2nd operand) + 1U (CF) from 0U (1st operand/destination)
and sets CF flag, but the RTL representation of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636
--- Comment #5 from Michael Meissner ---
Created attachment 42425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42425&action=edit
Post reload dump file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636
--- Comment #4 from Michael Meissner ---
Created attachment 42424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42424&action=edit
Reload dump file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636
--- Comment #3 from Michael Meissner ---
Created attachment 42423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42423&action=edit
LRA dump file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636
--- Comment #2 from Michael Meissner ---
Created attachment 42422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42422&action=edit
Simpler test case that does not use asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636
--- Comment #1 from Michael Meissner ---
This looks like a reload bug. I see the same thing with automatically
generated fmas:
--> cat foo06c.c
__ieee128
__fmaf128_power9 (__ieee128 x, __ieee128 y, __ieee128 z)
{
return (x * y) + z;
}
After
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #1 from Yichao Yu ---
I've found a workaround in
https://sourceware.org/ml/binutils/2017-04/msg00171.html but it's extremely
ugly (albeit also very clever...).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82639
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
adb
+===GNAT BUG DETECTED==+
| 8.0.0 20171020 (experimental) [trunk revision 253921] (x86_64-suse-linux) |
| Assert_Failure atree.adb:979 |
| Error detected at uri.ads:3:1
uri.adb
+===GNAT BUG DETECTED==+
| 8.0.0 20171020 (experimental) [trunk revision 253921] (x86_64-suse-linux) |
| Assert_Failure atree.adb:979 |
| Error detected at uri.ads:4:1|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82639
--- Comment #1 from Victor Porton ---
This was an example of a legal Ada program which does not compile with GNAT.
Workaround: Don't use a private type here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79795
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Fri Oct 20 18:01:36 2017
New Revision: 253951
URL: https://gcc.gnu.org/viewcvs?rev=253951&root=gcc&view=rev
Log:
2017-10-20 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
Bug ID: 82641
Summary: Unable to enable crc32 for a certain function with
target attribute on ARM
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
--- Comment #8 from Jakub Jelinek ---
Ah, and nonzero_bits ((reg:SI 93), SImode) == 1. So (plus:SI (ltu:SI (reg:SI
93) (const_int -1)) (const_int -1)) is also (const_int 0).
reg:SI 93 is even constant 1. So in:
(insn 19 18 20 4 (set (reg:CC 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82640
Bug ID: 82640
Summary: gcc doesn't show errors on anonymous local variables
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82639
Bug ID: 82639
Summary: Legal program rejected
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
Andrew Pinski changed:
What|Removed |Added
Component|c++ |libgcc
--- Comment #7 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
--- Comment #7 from Jakub Jelinek ---
There is another important detail, num_sign_bit_copies ((reg/v:DI 89 [ d ]),
DImode) == 64.
So, in the end, if the whole DI 89 pseudo is non-zero, then
(plus:SI (ltu:SI (reg:SI 93)
(subreg:SI (reg/v:D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
--- Comment #6 from Jakub Jelinek ---
The problem seems to be in if_then_else_cond, which is called on
(plus:SI (ltu:SI (reg:SI 93)
(subreg:SI (reg/v:DI 89 [ d ]) 0))
(subreg:SI (reg/v:DI 89 [ d ]) 4))
and returns a bogus thing - retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #20 from Thomas Koenig ---
(In reply to Jerry DeLisle from comment #19)
> (In reply to Christophe Lyon from comment #17)
> > Thanks for your effort; I'm still seeing noise though.
> >
> > Sorry, I'm not fluent in fortran: is there a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #13 from joseph at codesourcery dot com ---
Strictly, all x86 excess precision cases are indeterminable (semantics of
-1) except for the case where -fexcess-precision=standard is used
(requires front-end support, present for C only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #12 from Keith Marshall ---
(In reply to Jakub Jelinek from comment #10)
> While defining float_t to float and double_t to long double for -msse
> -mfpmath=sse is a reasoanble choice,
Actually, it is the correct choice, but...
> you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #11 from Keith Marshall ---
(In reply to Jakub Jelinek from comment #8)
> Indeed, this really is a mingw bug.
Wrong! It is *both* a MinGW bug, *and* a GCC bug. The difference is that I am
fully committed to fixing the MinGW bug, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82629
--- Comment #3 from Thorsten Kurth ---
One more thing,
In the test case I send, please change the $(XPPFLAGS) in the main.x target
compilation to $(CXXFLAGS), so that -fopenmp is used at link time also.
However, that does not solve the problem b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82629
--- Comment #2 from Thorsten Kurth ---
Created attachment 42420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42420&action=edit
This is the test case demonstrating the problem.
Linking this code will produce:
-bash-4.2$ make main.x
g++ -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81896
--- Comment #2 from Thorsten Kurth ---
Hello,
another data point:
when I create a dummy variable, it works: for example alias data to tmp and
then use tmp. I think this is not working for the same reason one cannot
arbitrarily put class member v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #6 from Hannes Hauswedell ---
Sorry, I forgot the stack trace. It wasn't helpful to me:
(gdb) bt
#0 uw_frame_state_for (context=context@entry=0x801c00e20,
fs=fs@entry=0x801c00b70) at
/wrkdirs/usr/ports/lang/gcc7-devel/work/gcc-7-2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859
--- Comment #28 from Thorsten Kurth ---
Hello,
can someone please give me an update on this bug?
Best Regards
Thorsten Kurth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #10 from Jakub Jelinek ---
The footnote says:
The types float_t and double_t are intended to be the implementation’s most
efficient types at least as wide as float and double, respectively. For
FLT_EVAL_METHOD equal 0, 1, or 2, the ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81896
--- Comment #1 from Thorsten Kurth ---
Hello,
is this report actually being worked on? It is in unconfirmed state for quite a
while now.
Best Regards
Thorsten Kurth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #9 from Jonathan Wakely ---
I doubt many people use those types at all in C++, so not defining them
probably won't upset anybody. On the other hand, what we do today results in an
unavoidable error.
This is probably a better way to d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82595
--- Comment #11 from Eric Gallager ---
My testresults are here:
https://gcc.gnu.org/ml/gcc-testresults/2017-10/msg01751.html
Lots of sanitizer-related FAILs, but they're probably my fault due to the bogus
--without-pic I added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630
--- Comment #6 from Rafael Avila de Espindola ---
(In reply to H.J. Lu from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > The problem is the assembler's special treatment of _GLOBAL_OFFSET_TABLE_,
> > that
> > .long _GLOBAL_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
Steven Noonan changed:
What|Removed |Added
Attachment #42417|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #8 from Jakub Jelinek ---
Indeed, this really is a mingw bug.
"and for other values of FLT_EVAL_METHOD, they are
otherwise implementation-defined."
Being implementation-defined doesn't mean they aren't defined at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #12 from Steven Noonan ---
Created attachment 42418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42418&action=edit
nbody_CPU_AOS compile error testcase preprocessed source
Compile error case, preprocessed source.
Compile wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #7 from Jonathan Wakely ---
I don't see any leeway in the C standard for an implementation to not define
those types at all, but we can certainly make this change, if that's the right
thing to do:
--- a/libstdc++-v3/include/c_global/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
Steven Noonan changed:
What|Removed |Added
Attachment #40333|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|8.0 |7.3
--- Comment #10 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #5 from Jonathan Wakely ---
(In reply to Hannes Hauswedell from comment #4)
> The crash happens when calling .joinable(). If we skip the joinable check it
> crashes on .join().
That's not very precise. Calling it where? From the dest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #6 from Keith Marshall ---
(In reply to Jakub Jelinek from comment #5)
> __FLT_EVAL_METHOD__ 0 can't be correct in that case, "all operations and
> constants evaluate in the range and precision of the type used." does not
> hold,
__F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481
--- Comment #9 from Jonathan Wakely ---
Author: redi
Date: Fri Oct 20 15:14:33 2017
New Revision: 253944
URL: https://gcc.gnu.org/viewcvs?rev=253944&root=gcc&view=rev
Log:
PR libstdc++/82481 Suppress clang-tidy warnings
Backport from mainline
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #27 from Jonathan Wakely ---
Author: redi
Date: Fri Oct 20 15:14:29 2017
New Revision: 253943
URL: https://gcc.gnu.org/viewcvs?rev=253943&root=gcc&view=rev
Log:
PR libstdc++/79433 no #error for including headers with wrong -std
Back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82627
--- Comment #4 from Bill Seurer ---
I attached the dumps from before and after. Wow, they are radically different
in size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82627
--- Comment #3 from Bill Seurer ---
Created attachment 42416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42416&action=edit
Before revisvion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82627
Bill Seurer changed:
What|Removed |Added
CC||seurer at linux dot
vnet.ibm.com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #4 from Hannes Hauswedell ---
> the complete command line that triggers the bug;
/usr/local/bin/g++7 -Wl,-rpath -Wl,/usr/local/lib/gcc7/ -std=c++11 -pthread
test_thread.cpp
(g++7 could be g++6 g++6 or g++8)
> Are you linking to libp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #10 from Jakub Jelinek ---
Can you please attach preprocessed sources for both issues (the error and the
undefined external ref to *.omp_fn* function) + full g++ command line options?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82637
--- Comment #1 from Victor Porton ---
Possibly related bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82614
--- Comment #7 from Marco Castelluccio ---
(In reply to Martin Liška from comment #6)
> (In reply to Marco Castelluccio from comment #5)
> > (In reply to Martin Liška from comment #4)
> > > (In reply to Marco Castelluccio from comment #3)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82638
Bug ID: 82638
Summary: Legal program rejected with a weird error message
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82617
--- Comment #3 from Ögmundur Petersson ---
I fear that it doesn't add any new information but here is my full backtrace:
test.f90:22:0:
FUNCTION str_words(str,white) RESULT(items)
Error: Local declaration from a different function
..__resul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82637
Bug ID: 82637
Summary: Compiler crash
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635
--- Comment #2 from Jonathan Wakely ---
*** Bug 82634 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82634
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #5 from Jakub Jelinek ---
__FLT_EVAL_METHOD__ 0 can't be correct in that case, "all operations and
constants evaluate in the range and precision of the type used." does not hold,
but "all operations and constants evaluate in the range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82595
--- Comment #10 from Jakub Jelinek ---
Still, it was clearly caused by the bogus --without-pic, as lsan_preinit.cc is
guarded with a macro that was not enabled if PIC was defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82595
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
Keith Marshall changed:
What|Removed |Added
CC||keith.marshall at mailinator
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636
Segher Boessenkool changed:
What|Removed |Added
Keywords||ra
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636
Bug ID: 82636
Summary: powerpc: Unnecessary copy of __ieee128 parameter
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49526
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rearnsha at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82473
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82473
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Fri Oct 20 13:43:47 2017
New Revision: 253937
URL: https://gcc.gnu.org/viewcvs?rev=253937&root=gcc&view=rev
Log:
2017-10-20 Richard Biener
PR tree-optimization/82473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82129
--- Comment #4 from Richard Biener ---
So we oscillate in the expression set because we "randomly" take expressions
when intersecting ANTIC_OUT. Both keeping all and canonicalizing to lowest
expression ID fixes this.
Testing patch.
1 - 100 of 160 matches
Mail list logo
