https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #14 from Richard Biener ---
Author: rguenth
Date: Fri Feb 1 08:07:35 2019
New Revision: 268442
URL: https://gcc.gnu.org/viewcvs?rev=268442&root=gcc&view=rev
Log:
2019-02-01 Richard Biener
PR rtl-optimization/88593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88932
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451
Richard Biener changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
--- Comment #8 from Richard Biener ---
(In reply to Jan Hubicka from comment #7)
> It seems that this breaks debug-types-sections w/o LTO as well now.
> ./xgcc -B ./ -O2 -g ~/tramp3d-v44.ii -fdebug-types-section
> /aux/hubicka/tramp3d-v4b.cpp:560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
--- Comment #9 from Jan Hubicka ---
Note that Mark also got an crash in the wrapper
#0 0x0046527f in simple_object_elf_copy_lto_debug_sections
(sobj=, dobj=, pfn=,
err=) at
+/home/engshare/third-party2/gcc/7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87175
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 1 08:42:01 2019
New Revision: 268443
URL: https://gcc.gnu.org/viewcvs?rev=268443&root=gcc&view=rev
Log:
PR c++/87175
* parser.c (cp_parser_gnu_attributes_opt): Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88107
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 1 08:43:02 2019
New Revision: 268444
URL: https://gcc.gnu.org/viewcvs?rev=268444&root=gcc&view=rev
Log:
PR tree-optimization/88107
* tree-cfg.c (find_outermost_re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89143
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 1 08:44:23 2019
New Revision: 268445
URL: https://gcc.gnu.org/viewcvs?rev=268445&root=gcc&view=rev
Log:
PR tree-optimization/89143
* wide-int-range.h (wide_int_ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89143
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071
--- Comment #13 from Uroš Bizjak ---
I assume that memory inputs are not problematic for SSE/AVX {R,}SQRT, RCP and
ROUND instructions. Contrary to CVTSI2S{S,D}, CVTSS2SD and CVTSD2SS, we
currently don't emit XOR clear in front of these instrucito
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88107
Jakub Jelinek changed:
What|Removed |Added
Known to work||9.0
Summary|[7/8/9 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
Richard Biener changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #10 from Ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87175
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89147
Richard Biener changed:
What|Removed |Added
Keywords||lto
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89145
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
Richard Biener changed:
What|Removed |Added
CC||m...@nieper-wisskirchen.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #23 from Jakub Jelinek ---
Created attachment 45580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45580&action=edit
gcc9-pr89093.patch
This is what we are successfully using in Fedora for now (passed
bootstrap/regtest and fixe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87863
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451
--- Comment #13 from Richard Biener ---
Author: rguenth
Date: Fri Feb 1 09:08:55 2019
New Revision: 268446
URL: https://gcc.gnu.org/viewcvs?rev=268446&root=gcc&view=rev
Log:
2019-02-01 Richard Biener
PR testsuite/87451
* gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Fri Feb 1 09:17:14 2019
New Revision: 268447
URL: https://gcc.gnu.org/viewcvs?rev=268447&root=gcc&view=rev
Log:
2019-02-01 Richard Biener
PR tree-optimization/85497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497
Richard Biener changed:
What|Removed |Added
Keywords|deferred|
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497
Richard Biener changed:
What|Removed |Added
Summary|[8/9 Regression] [graphite] |[8 Regression] [graphite]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497
--- Comment #6 from Arseny Solokha ---
Sorry, but it would be a mistake to think that I'm short of testcases… Usually
I get one every few minutes.
1.
% gcc-9.0.0-alpha20190127 -O3 -floop-parallelize-all -fopenacc -fopenmp
-fno-guess-branch-prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89144
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88494
--- Comment #4 from Peter Cordes ---
I suspect dep-chains are the problem, and branching to skip work is a Good
Thing when it's predictable.
(In reply to Richard Biener from comment #2)
> On Skylake it's better (1uop, 1 cycle latency) while on R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #17 from Uroš Bizjak ---
(In reply to Christophe Lyon from comment #16)
> I've noticed this problem on arm and aarch64 native builds too.
> But my cross-compilers (using QEMU as simulator) still pass this test. Does
> this mean there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #18 from nsz at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #16)
> I've noticed this problem on arm and aarch64 native builds too.
> But my cross-compilers (using QEMU as simulator) still pass this test. Does
> this m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #19 from Christophe Lyon ---
(In reply to nsz from comment #18)
> it's not a bug in the sense that the arm architecture
> allows trap support (it's just not required), but it's
> buggy that it would not report the support correctly
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
--- Comment #11 from Richard Biener ---
Created attachment 45581
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45581&action=edit
sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88494
--- Comment #5 from Peter Cordes ---
IF ( xij.GT.+HALf ) xij = xij - PBCx
IF ( xij.LT.-HALf ) xij = xij + PBCx
For code like this, *if we can prove only one of the IF() conditions will be
true*, we can implement it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
Bug ID: 89149
Summary: Out of bounds array access not detected as ill-formed
in a constant expression context in some cases
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87022
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88494
--- Comment #6 from Peter Cordes ---
Oops, these were SD not SS. Getting sleepy >.<. Still, my optimization
suggestion for doing both compares in one masked SUB of +-PBCx applies equally.
And I think my testing with VBLENDVPS should apply equa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88494
--- Comment #7 from rguenther at suse dot de ---
On Fri, 1 Feb 2019, peter at cordes dot ca wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88494
>
> --- Comment #5 from Peter Cordes ---
>IF ( xij.GT.+HALf ) xij = xij - P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497
--- Comment #7 from rguenther at suse dot de ---
On Fri, 1 Feb 2019, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497
>
> --- Comment #6 from Arseny Solokha ---
> Sorry, but it would be a mistake to think tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497
Richard Biener changed:
What|Removed |Added
Keywords||deferred
Known to work|8.1.0, 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
--- Comment #2 from Richard Biener ---
If you ask the middle-end about such expressions you get its view. So if you
want to apply language semantics you need to avoid folding it with those
routines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
--- Comment #3 from Jakub Jelinek ---
That fold_build_pointer_plus_loc looks premature to me in any case given the
desire to delay folding. We have tons of those through the C as well as C++
FEs though.
E.g. pointer_int_sum calls:
fold_build2_lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88986
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89146
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
--- Comment #4 from rguenther at suse dot de ---
On Fri, 1 Feb 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
>
> --- Comment #3 from Jakub Jelinek ---
> That fold_build_pointer_plus_loc looks premat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
--- Comment #12 from Jakub Jelinek ---
Reduced testcase for -O2 -g -fdebug-types-section:
struct A {};
namespace N {
struct B {
using C = struct H {};
using D = A;
};
}
struct E : N::B {
typedef C C;
};
namespace N {
struct F {
E::C d;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89009
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 87742, which changed state.
Bug 87742 Summary: [7/8/9 Regression] false warning: array subscript 3 is above
array bounds of 'const std::type_info* const [3]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87685
--- Comment #2 from Jakub Jelinek ---
This happens in:
943 for (lkp_iterator iter (fns); iter; ++iter)
944 if ((!id_expr || TREE_CODE (*iter) == TEMPLATE_DECL)
945 && DECL_NONSTATIC_MEMBER_FUNCTION_P (*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669
--- Comment #8 from Thomas Koenig ---
(In reply to Christophe Lyon from comment #7)
> I've noticed a new ICE on arm likely caused by this fix. It appeared between
> r268426 and r268434 hence my suspicion.
Can you open a new PR (9 Regression] and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
--- Comment #13 from Richard Biener ---
OK, so we're cloning from two different type units ultimatively refering to the
same DIE. This means that copy_ancestor_tree doesn't set up decl_table
appropriately since it doesn't have the same logic as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663
--- Comment #6 from Jakub Jelinek ---
Hans-Peter, any comments on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150
Bug ID: 89150
Summary: [9 regression] Tree form bitmaps break GC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020
--- Comment #8 from Bill Schmidt ---
Honza, sorry for being so late to respond! I had to poke the performance team
once more on this. Reverting this patch did indeed solve the problem for us on
trunk, and we are seeing far better performance th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Johannes Pfau ---
>> The Minfo_Bracketing assert in sections_elf_shared.d fails now, of
>> course, but the file is usable even without linker-provided
>> bracketing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #5 from Marc Glisse ---
IIUC, EVRP sees if(x!=3)__builtin_unreachable() and adds a range [3,3] on x.
The condition thus gets cleaned up and __builtin_unreachable disappears. This
could be fine, except that x has a single use, the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88597
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Fri Feb 1 13:41:43 2019
New Revision: 268449
URL: https://gcc.gnu.org/viewcvs?rev=268449&root=gcc&view=rev
Log:
2019-02-01 Richard Biener
PR middle-end/88597
* tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88597
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #5 from rdapp at linux dot ibm.com ---
I performed a bisect using const-1.go as check and got the following likely
culprit:
b0751b120f1b83d8e48a7c2cac831aabbb0bc048 is the first bad commit
commit b0751b120f1b83d8e48a7c2cac831aabbb0bc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #6 from Jakub Jelinek ---
Reduced testcase:
typedef void *Lisp_Word;
typedef Lisp_Word Lisp_Object;
struct Lisp_Cons
{
union
{
struct { Lisp_Object car; union { Lisp_Object cdr; struct Lisp_Cons *chain;
} u; } s;
char _Ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #6 from Ian Lance Taylor ---
Thanks. I could have predicted that that would be the change. Unfortunately
that isn't useful as that is a huge change, bringing in a large number of
upstream changes from the master Go library.
While a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150
--- Comment #3 from Nathan Sidwell ---
I didn't know there were no tree-form bitmaps yet.
Contrary to my original assertion, I think just dropping the chain_prev
("%h.prev") marker will suffice. Normal use of a list-form bitmap starts at
the he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #7 from Jakub Jelinek ---
Before doing manual reduction, I've tried:
struct S { void *a, *b; int c; };
static inline int foo (void *p)
{
return ((unsigned) ((__INTPTR_TYPE__) p) & 7) == 3;
}
static inline void *bar (void *p)
{
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.0 |10.0
--- Comment #8 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89084
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
--- Comment #6 from Arseny Solokha ---
Testcase #3
% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20190127 -maccumulate-outgoing-args
-O1 -fschedule-insns -fselective-scheduling -fno-tree-ter -c
gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c
durin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #20 from Jakub Jelinek ---
Created attachment 45583
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45583&action=edit
gcc9-pr87485.patch
So like this (untested so far except for the testcase)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #7 from rdapp at linux dot ibm.com ---
I did a full debug build of libgo and noticed that this changes the behavior of
the executable. When it would segfault with default -O2 before, it now seems
to rapidly allocate gigabytes of memor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.0 |10.0
Summary|[7/8/9 Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #5 from Marc Nieper-Wißkirchen ---
If that was possible (that symbols are aliased in the TU in which they are
defined, but not (explicitly) in a TU where they are declared), there would be
the need of a "no_alias" (or "never_alias") a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.0 |10.0
Summary|[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #6 from Jakub Jelinek ---
That optimization is of course possible if the compiler can prove the addresses
are different. So, e.g. if one of the two vars is defined locally, or both
locally, or one is automatic and another namespace/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> happens when we're already running cgraph_node::expand on "h"
~~
"when we've already run", I meant to say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89084
--- Comment #4 from Jakub Jelinek ---
integer function foo ( )
write (*,*) 'foo'
block
integer, parameter :: idxs(3) = (/ 1, 2, 3 /)
integer :: i
foo = 0
do i = 1, size(idxs)
foo = foo + idxs(i)
enddo
end block
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87863
--- Comment #5 from Martin Jambor ---
Author: jamborm
Date: Fri Feb 1 16:22:13 2019
New Revision: 268452
URL: https://gcc.gnu.org/viewcvs?rev=268452&root=gcc&view=rev
Log:
[PR hsa/87863] Set assembler name of group and global variables early
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89084
Jakub Jelinek changed:
What|Removed |Added
Component|lto |fortran
--- Comment #5 from Jakub Jeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #32 from Matthew Malcomson ---
Created attachment 45584
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45584&action=edit
Single define_insn version of above patch
FWIW I've attached the patch I'd made.
The only interesting dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #7 from Marc Nieper-Wißkirchen ---
I'm sorry, I wasn't precise what I meant. When I wrote that the optimization
wouldn't be possible I meant the case of two externally defined variables, e.g.
extern int p;
extern int q;
One can forc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89151
Bug ID: 89151
Summary: SFINAE-disabled member hides another
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89151
--- Comment #1 from Csaba Ráduly ---
Created attachment 45585
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45585&action=edit
preprocessor output from -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89152
Bug ID: 89152
Summary: Wrapping values in structures can make the optimizer
blind
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #33 from Jakub Jelinek ---
How could you avoid the arm.c changes from my patch if you are using rtx_equal
on the MEM's addr and first operand of PLUS? I believe either that arm.c
change is needed, or the predicate used on the new def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #5 from Andreas Krebbel ---
Created attachment 45586
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45586&action=edit
qrsolv-reduc.f the miscompiled fortran file autoreduced from scipy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #6 from Andreas Krebbel ---
Created attachment 45587
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45587&action=edit
A C wrapper to call the qrsolv function in the fortran snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87863
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #34 from Matthew Malcomson ---
Yes, I needed to redo that check for an offset of 4 -- I compared the
expression of the first MEM with the result of `plus_constant` with 4 on the
expression of the second MEM in the condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89151
--- Comment #2 from Csaba Ráduly ---
Commenting out the non-optional operator GetWhat makes GCC 8.2.0 compile the
example as written. However, that operator is needed if struct R is changed to
struct R {
boost::optional password;
1 - 100 of 188 matches
Mail list logo
