https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92553
--- Comment #2 from Ye Luo ---
PR92357 mentioned that you backported a fix to the gcc 9 branch and how I'm
getting the following error
/home/yeluo/opt/gcc-9-branch/bin/g++ -fopenmp -foffload=nvptx-none
-foffload=-lm -fomit-frame-pointer -finli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769
--- Comment #4 from Andrew Pinski ---
>Linux system calls and Linux VDSO calls
System calls, I can understand But why is it required by VDSO calls too? That
seems backwards and also means VDSO functions are not the same ABI as normal
function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92941
--- Comment #1 from Andrew Pinski ---
The reason why this has not been seen as much as building without the C++
front-end is not something 99% people do, even cross compiler folks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|ICE in verify_gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93135
Andrew Pinski changed:
What|Removed |Added
Depends on||93221
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
--- Comment #3 from Andrew Pinski ---
aarch64 is one of the few targets that has a floating point type which is less
than SImode :).
A simple workaround for this bug is to change the code slightly:
struct sfp16 {
__fp16 f;
};
struct sfp16 get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
--- Comment #1 from Andrew Pinski ---
*** Bug 93236 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236
--- Comment #1 from Jim Rees ---
Created attachment 47639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47639&action=edit
sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236
Bug ID: 93236
Summary: [AArch64] ICE
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235
Bug ID: 93235
Summary: [AArch64] ICE
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
--- Comment #4 from Andrew Pinski ---
Note the patch also does not handle the following (or something a little more
complex):
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
#define vector __attribute__((__vector_size__(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Richard Biener from comment #2)
> > OK for trunk.
>
> Except it is wrong if the size(@1) != size(@3). I Noticed that after I
> created this bug rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> It's a bugfix so applicable for stage3... pre-approved with a testcase.
Except it causes a regression on x86_64:
FAIL: gcc.target/i386/pr54855-8.c scan-assembl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93044
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> Indeed that seems to disallow this case. The condition is complicated
> enough to warrant extra care fiddling with it though ;)
The main reason why I filed thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93081
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> OK for trunk.
Except it is wrong if the size(@1) != size(@3). I Noticed that after I created
this bug report. I have a better fix; though I combined it with s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93196
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232
--- Comment #3 from Andrew Pinski ---
(In reply to fdlbxtqi from comment #2)
> Is that a method to dump the entire processed source?
Please read https://gcc.gnu.org/bugs/ under the "Detailed bug reporting
instructions" section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318
--- Comment #5 from Piotr Henryk Dabrowski ---
Ping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234
Bug ID: 93234
Summary: INQUIRE on pre-assigned files of ROUND and SIGN
properties fails
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> Can you attach the preprocessed source?
>
> This might be a dup of bug 92955.
The source is here:
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/examples/0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233
--- Comment #1 from Chris Sykes ---
I noticed that g++ also fails to warn about this with a similar test
case written in c++, and found this old bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Perhaps this is easier to fix (witho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93233
Bug ID: 93233
Summary: No warning for possibly uninitialised return
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #7 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #5)
> >the cntlz ones are not, for example
>
> :) It has been a long time since I touched this but I would not doubt I
> messed up this too.
It's nastiness in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #6 from Segher Boessenkool ---
(In reply to Matt Emmerton from comment #4)
> The intrinsics that we would find useful, having used them as provided by
> the IBM XL C/C++ compiler, are the following:
>
> __sync()
> __isync()
> __lwsyn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219
--- Comment #6 from Andrew Pinski ---
(In reply to Roland Illig from comment #5)
> This is worse than before.
Not exactly because if write fails to stderr, there is not much to be done
except abort :). You can print something out because the w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219
--- Comment #5 from Roland Illig ---
(In reply to Jakub Jelinek from comment #4)
> Change return type from void to int.
Not quite. The return type is now bool, not int.
> Return true if not all characters have been written.
This feels wrong to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192
--- Comment #5 from Mikael Pettersson ---
Confirmed, needs -msoft-float or selecting a CPU model which implies that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #19 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #17)
> Dunno about others, but this particular optimization could be done in a new
> function called next to optimize_range_tests_cmp_bitwise and
> optimize_range_test
34 matches
Mail list logo
