https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #3 from Kewen Lin ---
There seem to be two alternatives to fix this, one is to raise error in
rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
something like mma_return_type_error to avoid re-erroring;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
--- Comment #5 from Alexander Monakov ---
(In reply to Richard Biener from comment #4)
>
> For the case at hand loading two vectors from the destination and then
> punpck{h,l}bw and storing them again might be the most efficient thing
> to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341
--- Comment #7 from LIU Hao ---
(In reply to Jakub Jelinek from comment #4)
> I think 0 argument for __builtin_c[lt]z{,l,ll,imax} is always undefined, 0
> argument
> to .C[LT]Z (internal calls) is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107323
Richard Biener changed:
What|Removed |Added
CC||hahnjo at hahnjo dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108314
--- Comment #3 from Richard Biener ---
(gdb) p debug_gimple_stmt (stmt)
t_5 = .FOLD_EXTRACT_LAST (t_14, _41, );
there's a missing call argument, the call is built here:
#0 vectorizable_condition (vinfo=0x3b67200, stmt_info=0x3c3d160,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
Bug ID: 108350
Summary: Windows: invoking gcc via symlink does not work
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #1 from niXman ---
> FIX
>
> The most straightforward fix is to change `lrealpath` to use
> `GetFinalPathNameByHandle` instead of `GetFullPathName`.
thanks for the investigation!
will do it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108314
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #4 from niXman ---
> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
Bug ID: 108360
Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #14 from Richard Biener ---
const_binop has
/* Don't constant fold this floating point operation if
the result has overflowed and flag_trapping_math. */
if (flag_trapping_math
&& MODE_HAS_INFINITIES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
--- Comment #6 from rguenther at suse dot de ---
On Tue, 10 Jan 2023, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
>
> --- Comment #5 from Alexander Monakov ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
--- Comment #3 from Jakub Jelinek ---
Seems e.g. sincos* have wrong prototypes since that revision too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
Bug ID: 108351
Summary: Dead Code Elimination Regression at -O3 (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Yann Girsberger changed:
What|Removed |Added
CC||yann at ywg dot ch
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #3 from niXman ---
(In reply to Bill Zissimopoulos from comment #2)
> (In reply to niXman from comment #1)
> > > The most straightforward fix is to change `lrealpath` to use
> > > `GetFinalPathNameByHandle` instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355
Bug ID: 108355
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #18 from Jakub Jelinek ---
See #c10, I think even with comparisons we need to be careful. One thing is
whether we can prove one of the branches will be unreachable, we can do that
and replace that branch with __builtin_unreachable,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #17 from Jonathan Wakely ---
Please try current master, I think the errors for h8300-elf and msp430-elf
should be fixed (but I still get the assembler errors for h8300-elf using
latest binutils).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108314
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106476
Richard Biener changed:
What|Removed |Added
Known to work||13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
Bug ID: 108356
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #7 from Bill Zissimopoulos ---
(In reply to niXman from comment #6)
> > I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
>
> together? OR'ed?
>
> or should I try for the first, and for the second one? or...?
Yes, or them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108314
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106476
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #17 from Richard Biener ---
(In reply to Aldy Hernandez from comment #16)
> Created attachment 54224 [details]
> untested patch
>
> Perhaps this would work. It solves the testcase, though I think we should
> probably audit the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #12 from Iain Sandoe ---
unfortunately, neither this nor the v4.1 (WIP) is still quite right.
Using LIBDIR in the computation of the include paths means that the compiler
does not work when it is relocated .. the directory prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
Bug ID: 108353
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108354
Bug ID: 108354
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
Bug ID: 108357
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
Bug ID: 108359
Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Stam Markianos-Wright
:
https://gcc.gnu.org/g:08842ad274f5e2630994f7c6e70b2d31768107ea
commit r11-10461-g08842ad274f5e2630994f7c6e70b2d31768107ea
Author: Stam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #4 from Kewen Lin ---
(In reply to Kewen Lin from comment #3)
> There seem to be two alternatives to fix this, one is to raise error in
> rs6000_pass_by_reference like what we do in rs6000_function_arg, but we need
> something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #13 from Richard Biener ---
(In reply to Aldy Hernandez from comment #12)
> (In reply to Richard Biener from comment #6)
> > (In reply to Jakub Jelinek from comment #0)
> > > ... but then
> > > comes dom2 and happily replaces
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
Bug ID: 108349
Summary: LTO mismatch for __builtin_realloc between glibc and
gfortran frontend
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b39f4333d18cc58b1a655c537a78fefe95b82609
commit r13-5079-gb39f4333d18cc58b1a655c537a78fefe95b82609
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #12 from Eric Botcazou ---
> How are the bits numbered in there, IOW is bit 0 always the LSB or not?
Answering to myself: no, they are numbered in memory order, which is
problematic because, in the implementation model, stand-alone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #19 from rguenther at suse dot de ---
On Tue, 10 Jan 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
>
> --- Comment #18 from Jakub Jelinek ---
> See #c10, I think even with comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108314
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:554bb9b61e2b76d4ace16a3f766b98ea887b17f4
commit r13-5089-g554bb9b61e2b76d4ace16a3f766b98ea887b17f4
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107843
Jose E. Marchesi changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:769fae76dfd71045fe062e7b1edef0f59e50371d
commit r13-5080-g769fae76dfd71045fe062e7b1edef0f59e50371d
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108140
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:849c3cf7b4189342b4a0df941afddf8327585570
commit r12-9037-g849c3cf7b4189342b4a0df941afddf8327585570
Author: Kyrylo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #16 from Aldy Hernandez ---
Created attachment 54224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54224=edit
untested patch
Perhaps this would work. It solves the testcase, though I think we should
probably audit the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Summary|Dead Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108352
Bug ID: 108352
Summary: Dead Code Elimination Regression at -O2 (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108358
Bug ID: 108358
Summary: Dead Code Elimination Regression at -Os (trunk vs.
12.2.0)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #18 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:c389991432da2bcc335a2b4fb7e502d28a6b3346
commit r13-5090-gc389991432da2bcc335a2b4fb7e502d28a6b3346
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #5 from Bill Zissimopoulos ---
(In reply to niXman from comment #4)
> > FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> > via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106133
--- Comment #4 from Martin Liška ---
Btw. it crashes also for:
gcc empty.c -fdiagnostics-format=sarif-file --save-temps -c
0xf02ebf crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:314
0x778b78df ???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #15 from Aldy Hernandez ---
(In reply to Richard Biener from comment #13)
> Note that the constant folding routines generally refrain from folding
> when that loses exceptions, it's just ranger when producing singleton
> ranges and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #2 from Bill Zissimopoulos ---
(In reply to niXman from comment #1)
> > The most straightforward fix is to change `lrealpath` to use
> > `GetFinalPathNameByHandle` instead of `GetFullPathName`.
>
> thanks for the investigation!
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #6 from niXman ---
> I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
together? OR'ed?
or should I try for the first, and for the second one? or...?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106421
--- Comment #4 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:851e1ba03f9de699a754dd8648fc151c3e26d697
commit r13-5091-g851e1ba03f9de699a754dd8648fc151c3e26d697
Author: Roger Sayle
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #2 from eric-bugs at omnifarious dot org ---
Created attachment 54238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54238=edit
Assembly output from compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
Martin Liška changed:
What|Removed |Added
Summary|[13 Regression] Dead Code |[13 Regression] Dead Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #24 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #21)
> (In reply to Richard Biener from comment #13)
>
> > Yes, the fact that ranger doesn't operate as a usual propagator with a
> > lattice
> > makes things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|Dead Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108137
--- Comment #9 from ucko at ncbi dot nlm.nih.gov ---
Thanks! I'm happy to confirm that the patch works for me too, even in the more
severely affected file I mentioned earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4e0b504f26f78ff02e80ad98ebbf8ded3aa6ffa1
commit r13-5092-g4e0b504f26f78ff02e80ad98ebbf8ded3aa6ffa1
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #2 from Richard Biener ---
(In reply to Andrew Macleod from comment #1)
> From ccp2 :
>
> Simulating block 2
>
> Visiting statement:
> c.2_1 = c;
> which is likely CONSTANT
> Lattice value changed to VARYING. Adding SSA edges to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108352
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #3 from Jakub Jelinek ---
The first difference with r13-2048 is during fre3:
@@ -210,7 +210,7 @@ marking outgoing edge 6 -> 1 executable
RPO iteration over 5 blocks visited 5 blocks in total discovering 5 executable
blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #10 from Andrew Pinski ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2392
"potentially-evaluated".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31756
Thomas Koenig changed:
What|Removed |Added
CC||mehdi.chinoune at hotmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Thomas Koenig changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #8 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #10 from niXman ---
it is strange, but for some reason I can't build master nor 12.2.0 because of
error:
```
{
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/nm
-pg _chkstk_s.o _chkstk_ms_s.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108363
Bug ID: 108363
Summary: Narrowing conversion errors are suppressed with the -w
flag
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #2 from Jakub Jelinek ---
Seems it happens even with
short b;
static short c;
unsigned char e;
char f;
void foo();
short(a)(short h, short i) { return h + i; }
static short(d)(short h, int i) { return (h >= 32 || h > (7 >> i)) ? h :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99373
Andrew Pinski changed:
What|Removed |Added
CC||eric-bugs at omnifarious dot
org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #5 from Andrew Pinski ---
Sorry PR 89139.
*** This bug has been marked as a duplicate of bug 89139 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139
Andrew Pinski changed:
What|Removed |Added
CC||eric-bugs at omnifarious dot
org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #5 from Andrew Macleod ---
The key change is that condition:
_6 = f.5_5 << 4;
e = _6;
h_23 = (short int) _6;
if (_21 == -1)
goto ; [50.00%]
else
goto ; [50.00%]
On the false edge, we lose the ability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
--- Comment #2 from Jakub Jelinek ---
Note, i and k are [0,0] U [5,5], so e is 0>>0 or 5>>5 and so always 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Stam Markianos-Wright
:
https://gcc.gnu.org/g:25edc76f2afba0b4eaf22174d42de042a6969dbe
commit r12-9038-g25edc76f2afba0b4eaf22174d42de042a6969dbe
Author: Stam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |13.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355
Martin Liška changed:
What|Removed |Added
Summary|Dead Code Elimination |[13 Regression] Dead Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #1 from Richard Biener ---
The CCP hunk causes a condition to be optimized away which then results in
different jump threading and different VRP. I didn't analyze further, but the
first difference is good:
@@ -253,31 +256,25 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> But the linker errors is a bug in your code really.
Because the original code has references to both std::string and
std::system_error .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #6 from eric-bugs at omnifarious dot org ---
Technically, I suppose it is. I do reference those things in the original code.
:-)
But it is sort of annoying to get the error when I can just edit the assembly
and clip out the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #4 from Andrew Macleod ---
The IL is different in VRP2 between GCC12 and GCC13. IN GCC 12 I see:
[local count: 1073741824]:
b.2_1 = b;
_2 = b.2_1 <= 0;
h.0_20 = (unsigned short) _2;
_21 = h.0_20 + 65535;
_22 = (short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
--- Comment #6 from Andrew Macleod ---
and VRP1 turned that
if (_21 < 0)
into
if (_21 == -1)
So yes, that was a correct transformation in FRE3, but the side effect is we
lose the ability to look back and determine better ranges for _6 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> The for (; j; j = j + 9) loop invokes undefined behavior:
>
> t.c: In function 'g':
> t.c:11:17: warning: iteration 396462472 invokes undefined behavior
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #1 from eric-bugs at omnifarious dot org ---
Created attachment 54237
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54237=edit
Assembly file containing _start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
Bug ID: 108361
Summary: Assembly code that is never called emitted on x86_64
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #20 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #16)
> Created attachment 54224 [details]
> untested patch
>
> Perhaps this would work. It solves the testcase, though I think we should
> probably audit the
1 - 100 of 159 matches
Mail list logo
