https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975
--- Comment #5 from Andrew Pinski ---
Note C and C++ are differ here. C says only if the return value is used it
becomes undefined while in C++ it is undefined at the point of return.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98977
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96591
Jason Merrill changed:
What|Removed |Added
Component|c++ |lto
Assignee|jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
--- Comment #3 from Jim Wilson ---
I suppose cost model problems could explain why combine didn't do the
optimization. I didn't have a chance to look at that.
I still think there is a fundmental problem with how we represent SImode
operations,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
Bug ID: 98981
Summary: gcc-10.2 for RISC-V has extraneous register moves
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82952
Marek Polacek changed:
What|Removed |Added
CC||sshannin at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98980
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98980
Bug ID: 98980
Summary: Very slow compilation with -Wduplicated-branches and
ubsan
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98979
Bug ID: 98979
Summary: [11 regression] ICE in several tests cases after
r11-7112
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95888
--- Comment #5 from Marek Polacek ---
Simplified test:
template class A {
A(int, int);
template friend class A;
friend T;
};
template struct B {
template struct C {
A begin() { return {1, 0}; }
};
template
C fn();
};
int
ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #3 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #1)
> This would be an ABI break, and so not going to happen.
Is there no way to improve standard components implementation? I'd imagine you
could provide th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95682
--- Comment #2 from anlauf at gcc dot gnu.org ---
Adding some printout after initializing the t1%x(:),
do i = 1, size(t1%x)
print *, len_trim (t1%x(i)), t1%x(i)
end do
I get for gcc-8:
5 three
5 three
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #15 from Jakub Jelinek ---
The needed permutations for this boil down to
typedef int V __attribute__((vector_size (16)));
typedef int W __attribute__((vector_size (32)));
#ifdef __clang__
V f1 (V x) { return __builtin_shufflevector (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82235
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232
--- Comment #7 from Hussam Al-Tayeb ---
The patch in bug 95719 fixes the ICE. Can you please backport it to the gcc-9
branch?
Also we need some methodology for followup patches so they are marked as
candidates for stable branches as well.
In thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83997
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #2 from Jonathan Wakely ---
If we were going to do this, we could also make std::optional occupy a
single byte, using one bit for the value and one for the engaged flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #14 from Jakub Jelinek ---
WIP that implements that. Except that we need some permutation expansion
improvements, both for the SSE2 V4SImode permutation cases and for AVX2
V8SImode permutation cases.
--- gcc/config/i386/sse.md.jj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
Bug ID: 98978
Summary: Consider packing _M_Engaged in the tail padding of T
in optional<>
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93788
Marek Polacek changed:
What|Removed |Added
CC||zhan3299 at purdue dot edu
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972
--- Comment #3 from Zhuo Zhang ---
I reduced the test-case, and the simplest test-case should be:
--- crash1.cc starts ---
constexpr p([](register const signed struct s;
--- crash1.cc ends ---
The bug is also reproduced on the commit
8d0737d8f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #13 from Jakub Jelinek ---
Looking at what other compilers emit for this, ICC seems to be completely
broken, it emits logical right shifts instead of arithmetic right shift, and
LLVM trunk emits for >> 63 what this patch emits, for >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98947
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] |[10 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98947
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:7a18bc4ae62081021f4fd90d591a588cac931f77
commit r11-7126-g7a18bc4ae62081021f4fd90d591a588cac931f77
Author: Marek Polacek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96462
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96462
--- Comment #5 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1cbc10d894494c34987d1f42f955e7843457ee38
commit r11-7125-g1cbc10d894494c34987d1f42f955e7843457ee38
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931
--- Comment #12 from akrl at gcc dot gnu.org ---
Right LE is 4 bytes, good catch thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931
--- Comment #11 from Jakub Jelinek ---
Isn't the normal length of short le lr, 1b 4 bytes rather than 2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Known to work||9.3.1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
--- Comment #13 from ktkachov at gcc dot gnu.org ---
*** Bug 98949 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98949
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:97b668f9a8c6ec565c278a60e7d1492a6932e409
commit r9-9224-g97b668f9a8c6ec565c278a60e7d1492a6932e409
Author: Matthias Klose
Following suggestions I'm testing the attached emitting the following
for long branches where LE cannot cover:
subslr, #1
bmi .L2
>From 0cd38cb29829b48f96e8e060e7a875f49236b67b Mon Sep 17 00:00:00 2001
From: Andrea Corallo
Date: Wed, 3 Feb 2021 15:21:54 +0100
Subject: [PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931
--- Comment #10 from Andrea Corallo ---
Following suggestions I'm testing the attached emitting the following
for long branches where LE cannot cover:
subslr, #1
bmi .L2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719
Hussam Al-Tayeb changed:
What|Removed |Added
CC||ht990332 at gmx dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
--- Comment #10 from Jakub Jelinek ---
Ugh, that is quite misdesigned then...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #12 from Jakub Jelinek ---
V4DImode arithmetic right shifts would be (untested):
--- gcc/config/i386/sse.md.jj 2021-02-05 14:32:44.175463716 +0100
+++ gcc/config/i386/sse.md 2021-02-05 15:24:37.942026401 +0100
@@ -12458,7 +1245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232
--- Comment #6 from Martin Liška ---
(In reply to Hussam Al-Tayeb from comment #4)
> (In reply to Martin Liška from comment #3)
> > Run build system with in a verbose mode (V=1 or VERBOSE=1), or so.
> > And then for the problematic TU do -E, whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232
--- Comment #5 from Hussam Al-Tayeb ---
I also found this https://bugzilla.redhat.com/show_bug.cgi?id=1858036
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
--- Comment #9 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #8)
> Even if it does, exporting regexec@@GLIBC_2.3.4 from libsanitizer when glibc
> doesn't support that symbol looks wrong.
I think all the interceptors use unversi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232
--- Comment #4 from Hussam Al-Tayeb ---
(In reply to Martin Liška from comment #3)
> Run build system with in a verbose mode (V=1 or VERBOSE=1), or so.
> And then for the problematic TU do -E, which will save pre-processed source
> file instead o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98977
Bug ID: 98977
Summary: [x86] Failure to optimize consecutive sub flags usage
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
David Malcolm changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98943
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98943
--- Comment #9 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:6606b852bfa866c19375a7c5e9cb94776a28bd94
commit r11-7124-g6606b852bfa866c19375a7c5e9cb94776a28bd94
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
--- Comment #5 from Jakub Jelinek ---
Yeah, seems the analyzer looked through the cast, so either it shouldn't, or it
needs to readd the cast in there.
As for print_mem_ref, if we wanted to protect it from bogus MEM_REF creation
(not sure about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975
--- Comment #4 from Jakub Jelinek ---
The only thing that should be fixed is whatever code invokes the UB.
There is no bug on the compiler side, you essentially end up with
__builtin_unreachable (); in place of the loop.
You can use -fsanitize=un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975
--- Comment #3 from Emil Meissner ---
(In reply to Jakub Jelinek from comment #2)
> And the bug is? The code always invokes undefined behavior, so anything can
> happen.
Whilst that is true, shouldn't it still be fixed, given (possible) securit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98971
--- Comment #5 from Gabriel F. T. Gomes ---
(In reply to Martin Liška from comment #4)
>
> Well, the intermediate object contains just LTO bytecode, that's why you
> can't see the section. You can use -ffat-lto-objects in order to generate
> both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98976
Bug ID: 98976
Summary: [coroutines] co_return in a switch statement doesn't
make a generic lambda non-constexpr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975
--- Comment #1 from Emil Meissner ---
The code in the attachment, compiled with `g++ file.cpp -o bug -O3 -std=c++20`
produces no assembly for both the `main` and `bsort` function`. (I.e. not even
a `ret` instruction), ultimating in a segmentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98972
--- Comment #2 from Zhuo Zhang ---
(In reply to Martin Liška from comment #1)
> Thank you for the report. Actually, it's an invalid code and we do have a
> lot of error recovery ICEs.
> Or do you have an original test-case that is a valid C++ cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
--- Comment #8 from Jakub Jelinek ---
Even if it does, exporting regexec@@GLIBC_2.3.4 from libsanitizer when glibc
doesn't support that symbol looks wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98975
Bug ID: 98975
Summary: Infinite loop produces no assembly (including
returning) with -O3
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98971
--- Comment #4 from Martin Liška ---
> The only difference now is that the intermediate object doesn't have a
> __patchable_function_entries section, but that's OK as far as I can tell.
Well, the intermediate object contains just LTO bytecode, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98971
--- Comment #3 from Gabriel F. T. Gomes ---
(In reply to Martin Liška from comment #2)
>
> @Gabriel: Is it intended behavior?
That's what I expected, yes! Thank you.
The only difference now is that the intermediate object doesn't have a
__patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
--- Comment #6 from Jakub Jelinek ---
Well, it is not about what arches you care about, but what arches we support in
libsanitizer/configure.tgt (from *-linux*).
So, riscv64, aarch64, mips, arm, s390*, sparc*, powerpc*, x86.
So it is desirable to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98855
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98855
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:63538886d1f7fc7cbf066b4c2d6d7fd4da537259
commit r11-7123-g63538886d1f7fc7cbf066b4c2d6d7fd4da537259
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> For arithmetic >> (element_precision - 1) one can just use
> {,v}pxor + {,v}pcmpgtq, as in instead of return vec >> 63; do return vec < 0;
> (in C++-ish way), a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98920
--- Comment #5 from Martin Liška ---
(In reply to Jakub Jelinek from comment #3)
> I'm not sure if your patch is correct.
> glibc has the system of earliest symbol versions, and so on certain
> architectures
> GLIBC_2.3.4 symver will not appear a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> Btw, -fgcse-sm is nowhere enabled by default (same applies to -fgcse-las),
> we should consider removing these optimizations (though -fgcse-las at least
> sound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98656
Martin Liška changed:
What|Removed |Added
Known to work||11.0
Summary|[9/10/11 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98656
--- Comment #5 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:4ede02a5f2af1205434f0e05aaaeff762b24e329
commit r11-7122-g4ede02a5f2af1205434f0e05aaaeff762b24e329
Author: Tom de Vries
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98971
--- Comment #2 from Martin Liška ---
Created attachment 50133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50133&action=edit
Tentative patch
As seen the flag -fpatchable-function-entry is properly marked as Optimization.
However, it's th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
--- Comment #3 from Richard Biener ---
(In reply to avieira from comment #1)
> The testcase above issues a warning, around do j=jts,enddo
>
> To use it as a testcase in my patch I'd like to get rid of it so if someone
> proficient in Fortran kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
Tamar Christina changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #6 from Richard Biener ---
Btw, -fgcse-sm is nowhere enabled by default (same applies to -fgcse-las), we
should consider removing these optimizations (though -fgcse-las at least sounds
useful and I wonder why it is not enabled). GCSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98932
--- Comment #7 from Kristian ---
Thanks!
Yes, I agree. We are however bound to earlier versions due to CUDA-dependency
on the NVIDIA Jetson-platforms:
https://github.com/OE4T/meta-tegra/wiki/Compatibility-notes
Hopefully NVIDIA will update thei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98932
--- Comment #6 from Martin Liška ---
(In reply to Kristian from comment #5)
> Thanks for such a swift reponse! Looking forward to testing the patches for
> 8.x.
You're welcome. Just a note, please try to use the latest GCC release (version
10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98932
--- Comment #5 from Kristian ---
Thanks for such a swift reponse! Looking forward to testing the patches for
8.x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98325
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-02-05
Known to fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98949
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
--- Comment #1 from avieira at gcc dot gnu.org ---
The testcase above issues a warning, around do j=jts,enddo
To use it as a testcase in my patch I'd like to get rid of it so if someone
proficient in Fortran knows a way to get rid of it that'd be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98974
Bug ID: 98974
Summary: ICE in vectorizable_condition after
STMT_VINFO_VEC_STMTS
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #8 from Richard Biener ---
exploring more options I noticed there's no arithmetic vector V2DI right shift,
so vectorizing
uint64_t carry = (uint64_t)(((int64_t)W[1]) >> 63) & (uint64_t)135;
W[1] = (W[1] << 1) ^ ((uint64_t)(((int6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #28 from Jakub Jelinek ---
Actually tested version.
The above testcase with [2, INF] range doesn't make really much sense,
but adjusted testcase where n has [0, 2] range doesn't warn anymore like the
one with constant 2.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #5 from Andreas Krebbel ---
Created attachment 50132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50132&action=edit
RTL dump from store motion pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #4 from Andreas Krebbel ---
The update of global variable c is moved out of the loop. Due to that c stays
at 8 although it should be counted down to 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #3 from Andreas Krebbel ---
Created attachment 50131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50131&action=edit
RTL GCSE dump without -fgcse-sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #2 from Andreas Krebbel ---
Created attachment 50130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50130&action=edit
RTL GCSE dump with -fgcse-sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98656
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98957
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98967
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98957
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:37876976b0511ec96741f638f160874f2added0e
commit r11-7121-g37876976b0511ec96741f638f160874f2added0e
Author: Jakub Jelinek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60759
--- Comment #7 from Vincent Lefèvre ---
(In reply to Manuel López-Ibáñez from comment #6)
> I believe this is on purpose to avoid too much noise. The warning in GCC
> needs to be smarter about types and macros and avoid early folding.
Well, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97878
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97878
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b229baa75ce4627d1bd38f2d3dcd91af1a7071db
commit r11-7120-gb229baa75ce4627d1bd38f2d3dcd91af1a7071db
Author: Jakub Jelinek
Date: Fr
1 - 100 of 107 matches
Mail list logo
