https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #5 from Andreas Schwab ---
A cast is seldom a good solution, but even equality tests have the potential to
go wrong with C's composite type rules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785
Bug ID: 66785
Summary: internal compiler error in record_operand_use
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
--- Comment #5 from amker at gcc dot gnu.org ---
I can reproduce the problem on avr using its namespace with GCC trunk. The
example code is as below:
typedef __memx struct foo_s {
int a[20];
} foo_t;
int sum1(const foo_t *p)
{
int i, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66780
--- Comment #1 from Kazumoto Kojima ---
I can reproduce the issue with the trunk cross compiler.
It seems that openproc function in proc/readproc.c is miscompiled
with -fstack-protector-strong. Here is a reduced test case:
--
int t;
struct s {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66784
Bug ID: 66784
Summary: no symbol emitted for builtin with lto
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66783
Bug ID: 66783
Summary: No error-checking for creating structs containing
opaque structs
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #4 from Daniel Marjamäki ---
absolutely. there are often bugs in the boundaries.
well. I was hoping to get more optimistic response.
how about this.. imagine that we wrote a "possible division by zero" warning
for every integer divi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66237
Mikhail Maltsev changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #7 from Jeffrey A. Law ---
The other thing to keep in mind, sinking of this nature ought to be applicable
to other unary ops and cases where we have multiple PHI args that are
SSA_NAMEs.It shouldn't be structurally limited to just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726
--- Comment #6 from Jeffrey A. Law ---
WRT c#2. PRE will try to optimize away a runtime redundant expression. In the
cases I'm looking at, there is only a single runtime evaluation. But that
evaluation can be sunk from a set of predecessors i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66747
--- Comment #9 from Doug Gilmore ---
Our nightly builds are now clean with this patch.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66744
--- Comment #3 from Matt Grochowalski ---
The bootstrap succeeds after applying the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #7 from mikulas at artax dot karlin.mff.cuni.cz ---
#include
atomic_int a = ATOMIC_VAR_INIT(0);
atomic_int b = ATOMIC_VAR_INIT(0);
atomic_int p = ATOMIC_VAR_INIT(0);
int thread_1(void)
{
atomic_store_explicit(&b, 1, memory_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66782
Uroš Bizjak changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #3 from Andreas Schwab ---
It's always the boundary cases that matter most for security.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66782
--- Comment #1 from Uroš Bizjak ---
Adding clobbered registers explicitly is exactly the same as adding them to
call_fusage, so I don't see any problem here from the first sight.
Can you please provide a minimized testcase, following instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #6 from Andrew Macleod ---
The standard doesn't define what machines should generate what code. It defines
terms for observing effects that need to be adhered to. Their machine model was
created over a few years during the early stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66747
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #2 from Daniel Marjamäki ---
Thanks!
Hmm.. in my humble opinion, when I see the code:
int f(void) { return 0x == -1; }
.. I get the impression that the developer probably wants to test if the
bitpattern 0xfff.. matches -1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66782
Bug ID: 66782
Summary: Unable to run 64-bit wine after MS->SYSV register
changes
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66781
Bug ID: 66781
Summary: "confused by earlier errors, bailing out" with wrong
enum within class
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956
--- Comment #6 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Jul 6 17:37:50 2015
New Revision: 225470
URL: https://gcc.gnu.org/viewcvs?rev=225470&root=gcc&view=rev
Log:
Backport r225466: tests from 'Fix eipa_src AAPCS issue (PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956
--- Comment #5 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Jul 6 17:32:07 2015
New Revision: 225469
URL: https://gcc.gnu.org/viewcvs?rev=225469&root=gcc&view=rev
Log:
2015-07-06 Alan Lawrence
Backport from mainlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724
--- Comment #4 from Steve Kargl ---
On Mon, Jul 06, 2015 at 05:05:05PM +, kargl at gcc dot gnu.org wrote:
>
> I beat up you to the punch on most of these. Everything in
> comment #1 and #2 is caught except
>
> program p
>write (1, asyn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956
--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Jul 6 17:06:00 2015
New Revision: 225466
URL: https://gcc.gnu.org/viewcvs?rev=225466&root=gcc&view=rev
Log:
Fix eipa_src AAPCS issue (PR target/65956)
2015-05-05 Ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #5 from mikulas at artax dot karlin.mff.cuni.cz ---
So, please pinpoint specific parahraph(s) in the standard that specify that
this behavior is acceptable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65956
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Jul 6 16:58:16 2015
New Revision: 225465
URL: https://gcc.gnu.org/viewcvs?rev=225465&root=gcc&view=rev
Log:
[ARM] PR/65956 AAPCS update for alignment attribute
gcc/:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66724
--- Comment #1 from Gerhard Steinmetz
---
Longer scheme :
backspace (1, iomsg=#)
close (1, iomsg=#)
close (1, status=#)
endfile (1, iomsg=#)
flush (1, iomsg=#)
inquire (1, iomsg=#)
open (1, access=#)
open (1, action=#)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #4 from Andrew Macleod ---
I'm not sure where the problem is. We interacted quite a bit as the model was
being developed. As I recall, it started with the standard, but they
strengthened some of the problem spots for a complete testa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66779
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695
--- Comment #1 from Vladimir Fuka ---
Anyone can confirm this behaviour?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521
ctice at gcc dot gnu.org changed:
What|Removed |Added
CC||ctice at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66749
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66780
Bug ID: 66780
Summary: [4.9 Regression] Compiling with
-fstack-protector-strong causes binary to segfault
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #48 from John Paul Adrian Glaubitz ---
Alright, I found it, -fstack-protector-strong is the culprit. Will file a new
bug report now.
Adrian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
Ramana Radhakrishnan changed:
What|Removed |Added
Target Milestone|--- |5.2
--- Comment #16 from Ramana R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66749
--- Comment #6 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Mon Jul 6 15:17:44 2015
New Revision: 225460
URL: https://gcc.gnu.org/viewcvs?rev=225460&root=gcc&view=rev
Log:
Add -march=iamcu to optimize for IA MCU
IA MCU is based on Intel P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
The problem here is that we don't really know what does the standard specify.
People often suggest the Batty's paper Mathematizing C++ Concurrency (
http://www.cl.cam.ac.uk/~pes20/cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66739
--- Comment #7 from Richard Biener ---
I am testing
Index: gcc/match.pd
===
--- gcc/match.pd(revision 225453)
+++ gcc/match.pd(working copy)
@@ -1336,8 +1353,9 @@ (d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66772
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Mon Jul 6 14:41:22 2015
New Revision: 225459
URL: https://gcc.gnu.org/viewcvs?rev=225459&root=gcc&view=rev
Log:
2015-07-06 Richard Biener
PR tree-optimization/66772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66739
--- Comment #6 from Richard Biener ---
The ppc testcase,
int
f(int a, int b, int c)
{
a -= (short)b * (c >> 16);
if (!a)
return 10;
return a;
}
is probably artificially triggering the same issue. Here we do not
test for conditional p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66779
Bug ID: 66779
Summary: jit segfault
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66778
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66739
Andreas Schwab changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66778
Bug ID: 66778
Summary: [6.0 Regression] PPC 405 and 440 nmac failure
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Mon Jul 6 13:12:39 2015
New Revision: 225454
URL: https://gcc.gnu.org/viewcvs?rev=225454&root=gcc&view=rev
Log:
2015-07-06 Richard Biener
PR tree-optimization/66767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767
--- Comment #2 from Richard Biener ---
Indeed.
:
# PT = { D.2299 } (nonlocal)
# ALIGN = 16, MISALIGN = 0
vectp_p.4_16 = p_7(D) + 1;
addr2int0_4 = (signed long) vectp_p.4_16;
andmask_3 = addr2int0_4 & 15;
if (andmask_3 == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #13 from Bernd Schmidt ---
Author: bernds
Date: Mon Jul 6 12:49:26 2015
New Revision: 225453
URL: https://gcc.gnu.org/viewcvs?rev=225453&root=gcc&view=rev
Log:
Fix assert caused by bad cfg manipulation in bfin.
PR target/66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
--- Comment #8 from Manuel López-Ibáñez ---
> I'd vote for either removing this warning or fixing it.
You can use the corresponding -Wno-* option to remove it.
There's no much point in voting on this or other bugs: What is needed is
someone bra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61820
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard PALO ---
> I have this as well on SunOS 5.11 illumos with 4.9* (on pkgsrc)
Right, the bug is still present on the 4.9 branch (only). It was fixed
on mainl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636
Markus Trippelsdorf changed:
What|Removed |Added
CC||fiesh at zefix dot tv
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66777
--- Comment #1 from Richard Biener ---
-Waggressive-loop-optimizations, but it doesn't warn for me in this case. Of
course we warn about
t.c: In function ‘main’:
t.c:8:26: warning: ‘a[0]’ is used uninitialized in this function
[-Wuninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66769
--- Comment #3 from fiesh at zefix dot tv ---
Better, self contained problem case:
class A
{
void f(int a);
int g();
};
void A::f(int a) {}
int A::g()
{
auto r = [&] (auto x) { f(*x); };
int * p;
r(p);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #23 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Mon Jul 6 11:50:47 2015
New Revision: 225452
URL: https://gcc.gnu.org/viewcvs?rev=225452&root=gcc&view=rev
Log:
Allow -mincoming-stack-boundary=3 with -mno-sse
Similar to -mpref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #9 from Tobias Burnus ---
Jason, any news on this:
(In reply to Jan Hubicka from comment #8)
> Jaon, the issue here is that TYPE_CANONICAL is incomplete type:
[...]
> Shouldn't the canonical type be always the complete variant of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66733
--- Comment #3 from Richard Biener ---
Ok, it's actually slightly more twisted (but indeed related to CCP propagating
copies now).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66777
Bug ID: 66777
Summary: faggressive-loop-optimizations behavior.
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66774
--- Comment #2 from Jonathan Wakely ---
(In reply to contact from comment #0)
> As the bug does not
> occur with -O0 I assume the bug is part of gcc, and not of my own code, but
> I could obviously be wrong.
This is a completely invalid assumpti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731
--- Comment #1 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Mon Jul 6 11:00:03 2015
New Revision: 225450
URL: https://gcc.gnu.org/viewcvs?rev=225450&root=gcc&view=rev
Log:
[AArch64] PR target/66731 Fix fnmul insn with -frounding-math
gcc/C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Mon Jul 6 10:37:33 2015
New Revision: 225449
URL: https://gcc.gnu.org/viewcvs?rev=225449&root=gcc&view=rev
Log:
2015-07-06 Richard Biener
PR middle-end/66759
* mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66776
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64*
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #4)
> combine should not in general try multiple ways to write the same
> thing; this will not scale. In this case, I don't see that some
> backends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66776
Bug ID: 66776
Summary: [AArch64] zero-extend version of csel not matching
properly
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58586
--- Comment #8 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Jul 6 10:26:12 2015
New Revision: 225447
URL: https://gcc.gnu.org/viewcvs?rev=225447&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2015-07-06 Andre Vehreschild
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
--- Comment #18 from vries at gcc dot gnu.org ---
Created attachment 35919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35919&action=edit
combined testcase/trigger/tracing patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
--- Comment #17 from vries at gcc dot gnu.org ---
Created attachment 35918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35918&action=edit
update gzipped trace
latest trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66775
Bug ID: 66775
Summary: Allocatable function result type(t) produces segfault
when uninitialized
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66774
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
Daniel Marjamäki changed:
What|Removed |Added
CC||daniel.marjamaki at gmail dot
com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66774
Bug ID: 66774
Summary: Any optimization causes segfault on binary
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66757
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
Bug ID: 66773
Summary: sign-compare warning for == and != are pretty useless
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66757
--- Comment #3 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Jul 6 08:43:58 2015
New Revision: 225446
URL: https://gcc.gnu.org/viewcvs?rev=225446&root=gcc&view=rev
Log:
PR tree-optimization/66757
* match.pd: Add missing con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66749
--- Comment #5 from Yulia Koval ---
(In reply to H.J. Lu from comment #4)
> Created attachment 35904 [details]
> A patch
>
> Please try this.
It fixes the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40267
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40267
--- Comment #2 from Francois-Xavier Coudert ---
Author: fxcoudert
Date: Mon Jul 6 08:22:34 2015
New Revision: 225445
URL: https://gcc.gnu.org/viewcvs?rev=225445&root=gcc&view=rev
Log:
PR libfortran/40267
* Makefile.am: Remove li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771
--- Comment #7 from Jonathan Wakely ---
Oops sorry, I mean:
if (!m_input.getline(buf, sizeof(buf)))
return false;
The version comparing to 0 only works in C++03 (or non-conforming versions of
libstdc++ pre-gcc-5) because testing a strea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800
edanor1 at wp dot pl changed:
What|Removed |Added
CC||edanor1 at wp dot pl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66771
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
--- Comment #15 from vries at gcc dot gnu.org ---
My guess at this point is that the problem is that in
replace_block_vars_by_duplicates, we replace the old decls in the block with
new decls, but that the value-exprs that we copy from the old to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
--- Comment #14 from vries at gcc dot gnu.org ---
1.
In lower_omp_target for function fn3, we handle clause 'map(alloc:bD.1833
[pointer assign, bias: 0])' with variable-sized bD.1833.
The var bD.1833 has value-expr *b.0D.1844. For b.0D.1844, we s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974
Neil Bird changed:
What|Removed |Added
CC||neil at fnxweb dot com
--- Comment #1 from N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66770
--- Comment #2 from Richard Biener ---
This looks like a dup of PR66759 to me which has a reduced testcase and shows
a bug in folding of REAL_CST - x CMP REAL_CST.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66760
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66767
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768
Richard Biener changed:
What|Removed |Added
CC||amker.cheng at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66772
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 105 matches
Mail list logo
