https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107323
Richard Biener changed:
What|Removed |Added
CC||hahnjo at hahnjo dot de
--- Comment #1
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=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 h
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
> n
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=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; the
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 m
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=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=69482
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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 co
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=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=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,
gsi
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
Component
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=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
Date
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
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108349
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
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=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=107608
--- Comment #16 from Aldy Hernandez ---
Created attachment 54224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54224&action=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=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 Tkachov
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=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 oper
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=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=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=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 n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
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
Pr
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=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=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=108351
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Summary|Dead Code Elim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Yann Girsberger changed:
What|Removed |Added
CC||yann at ywg dot ch
--- Comment #6 fro
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
Pr
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!
> wi
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 `GetFullPathNam
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
Pr
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 `GetFinalP
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
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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
Pr
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
Pr
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
Pr
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
Pr
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
Pr
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
Pr
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
> > `GetF
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=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=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=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 ???
/usr/src/debug/gl
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 M
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 Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #8 from niXman ---
> Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.
>
> - `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
> resolution.
>
> - `VOLUME_NAME_DOS` is needed to translate the in
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
Comp
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&action=edit
Assembly file containing _start
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&action=edit
Assembly output from compiler
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 J
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 opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #21 from Andrew Macleod ---
(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 very difficult here. Note that my comment referred to code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #22 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Aldy Hernandez from comment #16)
> > Created attachment 54224 [details]
> > untested patch
> >
> > Perhaps this would work. It solves the testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #2
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 very
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 #25 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #22)
> Note that we currently can't represent +-inf or +-max, as we only have two
> endpoints. So that would just be represented as VARYING.
By +-inf I meant eithe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |13.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108352
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108354
Martin Liška changed:
What|Removed |Added
Summary|Dead Code Elimination |[13 Regression] Dead Code
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=108356
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |13.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
Martin Liška changed:
What|Removed |Added
Summary|Dead Code Elimination |[13 Regression] Dead Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108358
Martin Liška changed:
What|Removed |Added
Summary|Dead Code Elimination |[13 Regression] Dead Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
Martin Liška changed:
What|Removed |Added
Summary|Dead Code Elimination |[13 Regression] Dead Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|Dead Code Elimina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #9 from Bill Zissimopoulos ---
Thank you.
Let me know if you need any help from me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108362
Bug ID: 108362
Summary: views::istream is SFINAE-unfriendly
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
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=106293
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108285
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=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=106003
--- Comment #7 from David Malcolm ---
For reference, this article (by one of my colleagues) talks about how valgrind
can detect file descriptor leaks *dynamically*:
https://developers.redhat.com/articles/2023/01/09/how-use-valgrind-track-file-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #1 from Andrew Macleod ---
>From ccp2 :
Simulating block 2
Visiting statement:
c.2_1 = c;
which is likely CONSTANT
Lattice value changed to VARYING. Adding SSA edges to worklist.
Whereas in GCC12 I see:
Simulating block 2
Visi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
--- Comment #1 from Richard Biener ---
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
[-Waggressive-loop-optimizations]
11 | for (; j; j
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 w
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=89204
Chinoune changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
Peter Bergner changed:
What|Removed |Added
CC||jskumari at gcc dot gnu.org
--- Comment
1 - 100 of 159 matches
Mail list logo
