https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #1 from Brecht Sanders
---
Closer investigation shows the issue probably not (or not only) cause by the
.exe extension:
This is the error:
lto-wrapper.exe: fatal error: could not find accel/nvptx-none/mkoffload.exe in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98116
--- Comment #4 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:5a26d4a204c8a462a7e0a1a86bb2f25ecd470aad
commit r11-5745-g5a26d4a204c8a462a7e0a1a86bb2f25ecd470aad
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96226, which changed state.
Bug 96226 Summary: Failure to optimize shift+not to rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148
Bug ID: 98148
Summary: [AArch64] Wrong location expression for function entry
values
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #36 from abebeos at lazaridis dot com ---
Created attachment 49686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49686=edit
Patch by Senthil Kumar Selvaraj, non-cc0-avr-backend
this should(!) be the final patch, derived from:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #14 from Sergei Trofimovich ---
The gcc patch also fixes original liferea+webkit-gtk-2.28.4 crash. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ac2a6962b91128e700ee52db686dcdb2bab93790
commit r11-5747-gac2a6962b91128e700ee52db686dcdb2bab93790
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148
--- Comment #2 from Luis Machado ---
In my particular example, The DWARF information tells us the value is at the
following expression...
<11ac> DW_AT_GNU_call_site_value: 6 byte block: 8d ec 0 f6 4 2d
(DW_OP_breg29 (x29): 108;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148
--- Comment #1 from Luis Machado ---
You can find the sources for this testcase in binutils-gdb repo, at
gdb/testsuite/gdb.ada/O2_float_param.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #5 from Jeffrey A. Law ---
The best way to think about V_C_E is that it's the same bits, just viewed in a
different type whereas a cast can do things like sign/zero extension,
truncation of floating point values to integers, etc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98141
--- Comment #1 from David Neill Asanza ---
Here are even shorter examples:
$ cat short01.f90
program short01
class(*), allocatable :: a, b, c
character(len=0) :: s
allocate(a, source=s) !! No problem
allocate(character(len=0)::b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96232
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
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=94600
--- Comment #12 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:eb79f4db49c5f5a807555e9d374524664eb537bf
commit r11-5749-geb79f4db49c5f5a807555e9d374524664eb537bf
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #13 from Jakub Jelinek ---
wrong-code should be now fixed, keeping open if Richard or Honza don't want to
improve handling of non-replaceable delete operators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:78c4a9feceaccf487516aa1eff417e0741556e10
commit r11-5748-g78c4a9feceaccf487516aa1eff417e0741556e10
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:33be07be9e46f15b9556521050356c47460651ee
commit r11-5746-g33be07be9e46f15b9556521050356c47460651ee
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Christophe Lyon changed:
What|Removed |Added
Assignee|clyon at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #13 from CVS Commits ---
The releases/gcc-10 branch has been updated by Hans-Peter Nilsson
:
https://gcc.gnu.org/g:ac2347289d4d8000a078b540b6c9c2c74bb33471
commit r10-9121-gac2347289d4d8000a078b540b6c9c2c74bb33471
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:43e84ce7d62be121445e17cc0ee009a81fb285d7
commit r11-5755-g43e84ce7d62be121445e17cc0ee009a81fb285d7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:625e002396f7d0108f845bfba6a6f4f4fcadad05
commit r11-5756-g625e002396f7d0108f845bfba6a6f4f4fcadad05
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
--- Comment #2 from Brad Bell ---
That fixed my test result.
Sorry I missed that.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #7 from Jeffrey A. Law ---
If you're V_C_E-ing to a narrower type, you just ignore the bits outside the
target type, it's a lot like a narrowing subreg in the RTL world.
I don't know what the semantics are for the widening case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
Bug ID: 98151
Summary: integer output gives different results with -O2 and
-O3
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
Andrew Pinski changed:
What|Removed |Added
Host|Linux |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98101
scott snyder changed:
What|Removed |Added
CC||s...@li-snyder.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
Bug ID: 98150
Summary: Segfault from statement expression in lambda noexcept
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] |[10 Regression] Accessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
--- Comment #1 from Nick Krempel ---
The following slightly simpler code also repros the issue:
int main() {
[]()noexcept(({constexpr int&=1;}));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
--- Comment #2 from Nick Krempel ---
Realised it doesn't need C++20 and was able to repro back in gcc 6.1 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #6 from Andrew Macleod ---
and when the precision is different what? assume 0's for the missing bits?
If we allow and want that behaviour, we should change the documentation to
reflect that...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
--- Comment #7 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:34e72e050bf4e23689af7061f6381b95339eb7fa
commit r9-9099-g34e72e050bf4e23689af7061f6381b95339eb7fa
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 49687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49687=edit
Untested patch (proof of concept)
Here's a possible patch that retries after short reads.
Not regtested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98149
Bug ID: 98149
Summary: missing spelling hint for misspelled calls to member
functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #10 from Thomas Koenig ---
(In reply to anlauf from comment #9)
> The patch seems to regtest ok, but certainly needs some wider testing.
Actually, I think the bug is in io/unix.c:raw_read. That should take
care of repeating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a95753214b55d21e5b44eeb098cccf88d44c94dd
commit r11-5752-ga95753214b55d21e5b44eeb098cccf88d44c94dd
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:316a185ee29c9e6ec060762e76d25b64c60fd665
commit r10-9122-g316a185ee29c9e6ec060762e76d25b64c60fd665
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96675
--- Comment #6 from Marek Polacek ---
(In reply to Giorgio Audrito from comment #5)
> I add that a very similar problem happens with -Wtype-limits, I found this
> minimal example:
>
> template
> struct foo {
> bool bar(unsigned y) {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #2 from Brecht Sanders
---
Did a bit more digging...
Seems COMPILER_PATH uses ';' as separator on Windows, not ':'.
So besides the .exe issue parse_env_var() also needs to separate the list by a
different separator.
Something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #10)
> Seems like that, if nbyte <= MAX_CHUNK, we do not take account of the
> possibility of a short read.
Yes, that seems to be the better/right place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Eric Botcazou changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment #40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98134
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98134
Bug ID: 98134
Summary: [11 Regression] bootstrap error building gnat on
mips64el-linux-gnu
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98135
Bug ID: 98135
Summary: arm: Inconsistent automatic selection of FPU variant
from -mcpu= and -march= options
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121
--- Comment #12 from Wilhelm M ---
The following does not work:
# include
# include
# include
# include
# include
using to_t = std::array;
int main() {
constexpr std::byte from1[4]{};
constexpr auto v1 = std::bit_cast(from1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96675
Giorgio Audrito changed:
What|Removed |Added
CC||giorgio.audrito at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
Bug ID: 98138
Summary: BB vect fail to SLP one case
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|[aarch64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98137
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=96075
--- Comment #16 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:0f50805bb3b0924bab94bd85203370703af50f26
commit r10-9120-g0f50805bb3b0924bab94bd85203370703af50f26
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075
--- Comment #17 from CVS Commits ---
The releases/gcc-9 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:d910ca0493455ffa84d4d934957cda1cb1588a25
commit r9-9098-gd910ca0493455ffa84d4d934957cda1cb1588a25
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121
--- Comment #13 from Jakub Jelinek ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561119.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
Bug ID: 98136
Summary: [aarch64] Internal compiler error with large classes
and virtual methods
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98137
--- Comment #2 from Richard Biener ---
Created attachment 49677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49677=edit
patch
I am testing the attached simple patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123
--- Comment #5 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:485b40a5270cf50a7304a9e5cb8aff96bfa3d901
commit r11-5741-g485b40a5270cf50a7304a9e5cb8aff96bfa3d901
Author: Martin Liska
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98137
Bug ID: 98137
Summary: Could use SLP to vectorize if split_constant_offset
were smarter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #1 from Kewen Lin ---
Similar case is x264_pixel_satd_8x4 in x264
https://github.com/mirror/x264/blob/4121277b40a667665d4eea1726aefdc55d12d110/common/pixel.c#L288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96675
--- Comment #5 from Giorgio Audrito ---
I add that a very similar problem happens with -Wtype-limits, I found this
minimal example:
template
struct foo {
bool bar(unsigned y) {
return y < x;
}
};
int main() {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98100
--- Comment #7 from Jakub Jelinek ---
Fixed on the trunk (so far).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98100
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:704ccefb576dcf30b27a4b9bdacb6e15902f5307
commit r11-5743-g704ccefb576dcf30b27a4b9bdacb6e15902f5307
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
Bug ID: 98139
Summary: varasm.c fails to compile on AIX 7.2:
-Werror=unused-variable
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
--- Comment #1 from Rainer Orth ---
Created attachment 49678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49678=edit
Hacky patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #5 from Jan Hubicka ---
> So, shouldn't the code match what the comment says?
> /* If the call is to a replaceable operator delete and results
> from a delete expression as opposed to a direct call to
> such operator,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #6 from Richard Biener ---
(In reply to Jan Hubicka from comment #5)
> > So, shouldn't the code match what the comment says?
> > /* If the call is to a replaceable operator delete and results
> > from a delete expression as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98140
Bug ID: 98140
Summary: Reused register by xsmincdp leads to wrong NaN
propagation on Power9
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #10 from Jakub Jelinek ---
valid_new_delete_pair_p checks the extra constraints C++ has, like that if you
allocate with a particular replaceable operator new, you can free it only with
those and those replaceable operator delete and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
--- Comment #2 from David Edelsohn ---
I bootstrap GCC on AIX with, and the instructions in the CompileFarm wiki
recommend, --disable-werror.
If that currently is the only problem, we're lucky. I don't know that this
hack is better. Shrug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #7 from Alan Modra ---
(In reply to Alan Modra from comment #5)
> So the "o" flag symbol is one in the .opd section, rather than what would be
> correct here, .L._Z3foov.
Actually, that breakage happened recently with commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #2 from Richard Biener ---
So the expected vectorization builds vectors
{ tmp[0][0], tmp[1][0], tmp[2][0], tmp[3][0] }
that's not SLP, SLP tries to build the
{ tmp[i][0], tmp[i][1], tmp[i][2], tmp[i][3] }
vector and "succeeds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #9 from Martin Liška ---
(In reply to Jakub Jelinek from comment #8)
> Oops, yes, dunno why it didn't work for me before, confirmed now that it
> works with the patch and fails without.
>
> I think we want it even for the operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #2 from Thomas Koenig ---
The problem seems to be related to an early return from the read system call:
strace -e trace=open,read,close ./a.out
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\v\2\0\0\0\0\0"...,
832) = 832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #4 from Jakub Jelinek ---
That would mean:
--- gcc/testsuite/g++.dg/opt/pr98130.C.jj 2020-12-04 12:30:11.510988404
+0100
+++ gcc/testsuite/g++.dg/opt/pr98130.C 2020-12-04 12:33:05.663028984 +0100
@@ -0,0 +1,25 @@
+// PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98136
Martin Liška changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10/11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> That would mean:
>
> --- gcc/testsuite/g++.dg/opt/pr98130.C.jj 2020-12-04 12:30:11.510988404
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr98130.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #8 from Jakub Jelinek ---
Oops, yes, dunno why it didn't work for me before, confirmed now that it works
with the patch and fails without.
I think we want it even for the operator delete case, I believe the C++
standard only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #3 from Thomas Koenig ---
The problem seems to be that we assume that a short read is always
an EOF, in read_block_direct:
if (unlikely ((ssize_t) nbytes != have_read_record))
{
/* Short read, e.g. if we hit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98141
Bug ID: 98141
Summary: Segmentation fault with empty string sourced
allocation
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97270
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98146
Bug ID: 98146
Summary: [11 Regression] section type conflict when "used"
attribute is applied to decl with specific section
Product: gcc
Version: 11.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
Jozef Lawrynowicz changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
--- Comment #4 from Jonathan Wakely ---
(In reply to Barry Revzin from comment #2)
> I guess in general this is kind of a scary optimization, since it doesn't
> seem like it's really a global thing? Perhaps this calls for an attribute?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
--- Comment #5 from Jakub Jelinek ---
Perhaps spell it as gnu::exhaustive_enum then or something similar?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
--- Comment #6 from Jonathan Wakely ---
(In reply to Barry Revzin from comment #0)
> As desired. I am telling gcc to make an assumption about the range of
> values, and it is optimizing based on the fact that 5 is not a valid
> enumerator.
N.B.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
--- Comment #7 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #5)
> Perhaps spell it as gnu::exhaustive_enum then or something similar?
I like that.
It would be much stricter than -fstrict-enums as it would say that you won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130
--- Comment #11 from Richard Biener ---
(In reply to Jakub Jelinek from comment #8)
> Oops, yes, dunno why it didn't work for me before, confirmed now that it
> works with the patch and fails without.
>
> I think we want it even for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97981
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
1 - 100 of 126 matches
Mail list logo
