https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108353
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=106293
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8d96a7fc27f3561f984e50feb316d3e472ed9d14
commit r13-5099-g8d96a7fc27f3561f984e50feb316d3e472ed9d14
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
cqwrteur changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
cqwrteur changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|MOVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #22 from cqwrteur ---
(In reply to cqwrteur from comment #19)
> (In reply to cqwrteur from comment #18)
> > (In reply to cqwrteur from comment #17)
> > > (In reply to Eric Botcazou from comment #16)
> > > > > #if _WIN32_WINNT >=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #6 from Kewen Lin ---
(In reply to Peter Bergner from comment #5)
> (In reply to Kewen Lin from comment #1)
> > diff --git a/gcc/config/rs6000/rs6000-call.cc
> > b/gcc/config/rs6000/rs6000-call.cc
> > index 59c51fa3579..6767a1f541c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #11 from Gaius Mulley ---
> when a module has the same name but a different interface are the
symbols distinct (i.e. mangled differently)?
no. So, as you say, the ordering of the static link works fine. I
had assumed that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108366
--- Comment #2 from Ben Wiederhake ---
Created attachment 54242
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54242=edit
precompiled file as generated by -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108366
--- Comment #1 from Ben Wiederhake ---
Preprocessed file see attachments, and output as generated by -v -save-temps
here:
$ g++ -v -o foo -O2 -std=c++20 -save-temps repro.cpp
Using built-in specs.
COLLECT_GCC=g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108366
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
--- Comment #22 from Jakub Jelinek ---
(In reply to Sergey Fedorov from comment #21)
> On ppc64 (970) it probably is supported.
No, it is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108366
Bug ID: 108366
Summary: [12/13 Regression] Spurious stringop overflow,
possibly alias-related
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85440
Sergey Fedorov changed:
What|Removed |Added
CC||vital.had at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108334
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
--- Comment #5 from Jakub Jelinek ---
I think the bug is in the C++ FE:
/* When dividing two signed integers, we have to promote to int.
unless we divide by a constant != -1. Note that default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
--- Comment #4 from Jakub Jelinek ---
With r9-1730 or later, I think the problem is that something decides to narrow
the division from long long to int. In long long it is well defined if b is
non-zero
as -2147483648LL / -1LL is 2147483648LL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
Andrew Pinski changed:
What|Removed |Added
Known to work|6.1.0, 6.4.0|
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-10
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
--- Comment #2 from Andrew Pinski ---
I noticed that with the C++ front-end early inline inlines f into main but with
the C front-end it does not ...
)(-2147483647 - 1)) / long(b[0] ? -1 :
0)););
}
Error:
>$ g++ -O0 repr.cpp && ./a.out
Floating point exception (core dumped)
gcc version 13.0.0 20230110 (e9a39ad7936815980013605b052b12425d56ead8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
--- Comment #6 from Steve Kargl ---
On Tue, Jan 10, 2023 at 09:50:08PM +, cvs-commit at gcc dot gnu.org wrote:
>
> --- Comment #5 from CVS Commits ---
> The master branch has been updated by Harald Anlauf :
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:fec9fc1a17ec44461cee841513f1b6b8ad680fe4
commit r13-5095-gfec9fc1a17ec44461cee841513f1b6b8ad680fe4
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> (In reply to anlauf from comment #2)
> > +
> > + mpz_clear (do_start);
> > + mpz_clear (do_end);
> > + mpz_clear (do_step);
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> +
> + mpz_clear (do_start);
> + mpz_clear (do_end);
> + mpz_clear (do_step);
> }
Harald, when I was looking at this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108364
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995
Andrew Pinski changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #12 from Bill Zissimopoulos ---
(In reply to niXman from comment #10)
> it is strange, but for some reason I can't build master nor 12.2.0 because
> of error:
Unfortunately I am not really familiar with the gcc build process to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108364
Bug ID: 108364
Summary: Construction from prvalue erroneously uses
move-constructor
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
--- Comment #5 from Andrew Macleod ---
Created attachment 54240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54240=edit
sample implementation
In fact that appears to work... The attached (untested) patch simply does
that at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
--- Comment #4 from Andrew Macleod ---
Well, range does know there is a relationship.. or at least could know:
Partial equiv (i_23 pe8 _35)
Partial equiv (k_24 pe8 _35)
It knows they are both 8 bit equivalences of _35. I don't remember if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #11 from niXman ---
even with a downgraded host toolchain to that which uses mingw-w64 rt-v9 I get
the same error...
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=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=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=108359
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
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=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=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=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=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=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=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=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=99373
Andrew Pinski changed:
What|Removed |Added
CC||eric-bugs at omnifarious dot
org
---
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=31756
Thomas Koenig changed:
What|Removed |Added
CC||mehdi.chinoune at hotmail dot
com
---
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=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=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=108348
--- Comment #5 from Peter Bergner ---
(In reply to Kewen Lin from comment #1)
> diff --git a/gcc/config/rs6000/rs6000-call.cc
> b/gcc/config/rs6000/rs6000-call.cc
> index 59c51fa3579..6767a1f541c 100644
> --- a/gcc/config/rs6000/rs6000-call.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108360
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #3 from Andrew Macleod ---
Hmm. It is not eliminated until VRP1 now. Looks like something in EVRP. lets
see...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
Peter Bergner changed:
What|Removed |Added
CC||jskumari 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=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=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=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=108355
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
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
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://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=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=106293
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc
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=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=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=108218
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
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=108360
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|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=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=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=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=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=108352
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
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=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
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=107608
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment
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
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 #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
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=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=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
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=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=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=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
1 - 100 of 159 matches
Mail list logo
