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. IST
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=98101
scott snyder changed:
What|Removed |Added
CC||s...@li-snyder.org
--- Comment #3 from sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98151
Andrew Pinski changed:
What|Removed |Added
Host|Linux |
|5.8.15-301.fc33.x86_
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
Prior
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=98150
--- Comment #1 from Nick Krempel ---
The following slightly simpler code also repros the issue:
int main() {
[]()noexcept(({constexpr int&&x=1;}));
}
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=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: Sa
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: Sa
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
Compo
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: We
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=95342
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
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
Dat
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 t
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 reads
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
D
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 anlau
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 #8 from anlauf at gcc dot gnu.org ---
Created attachment 49687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49687&action=edit
Untested patch (proof of concept)
Here's a possible patch that retries after short reads.
Not regte
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=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=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=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: Hans-Peter
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&action=edit
Patch by Senthil Kumar Selvaraj, non-cc0-avr-backend
this should(!) be the final patch, derived
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=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=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; DW_OP_GNU_der
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=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=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=98129
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
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: F
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=96226
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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: Fr
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: F
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=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=96232
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned a
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
d:/prog/winlib
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)
all
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=98140
--- Comment #1 from Alexander Grund ---
It looks like this was fixed in 10.1 by this commit
https://github.com/gcc-mirror/gcc/commit/37e0df8a9be5a8232f4ccb73cdadb02121ba523f
However the codegen looks worse:
390: 20 00 9e c3 lfs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97981
--- Comment #4 from Martin Uecker ---
I think the code to drop qualifiers needs to be moved below the check for
atomic. I will look into it. (I wonder why this passed checks for me).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98116
Nathan Sidwell changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98147
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98147
Bug ID: 98147
Summary: [11 Regression] ICE in emit_library_call_value_1, at
calls.c:5296 since
r11-5725-g442b6fb7c09a39577261de90413cc4db366f1c5f
Product: gcc
Ver
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=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 #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 #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?
>
> [[gnu
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=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=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: UNCONFIRMED
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=98145
Bug ID: 98145
Summary: On Windows .exe extension is missing when
searching/calling mkoffload
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
--- Comment #1 from Richard Biener ---
Created attachment 49682
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49682&action=edit
preprocessed insn-extract
This is x86_64 insn-extract when configured with --enable-checking=yes,rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
Bug ID: 98144
Summary: REE needs 6GB DF memory when compiling insn-extract.c
with RTL checking enabled
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98143
Bug ID: 98143
Summary: arm: missed vectorization with MVE compared to Neon
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192
--- Comment #4 from Jakub Jelinek ---
No, because it isn't sufficient, I believe we need to reject it rather than
accept it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749
Max Kellermann changed:
What|Removed |Added
CC||max at duempel dot org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97540
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
--- Comment #2 from Barry Revzin ---
That is a great point.
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?
[[gnu::i_promise_on_penalty_of_ub_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97868
--- Comment #2 from Martin Liška ---
Created upstream issue: https://github.com/google/sanitizers/issues/1352.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97981
--- Comment #3 from Martin Liška ---
The revision causes the following diff in GENERIC:
@@ -10,8 +10,8 @@
static atomic volatile double a;
static atomic volatile double b = 0.0;
# DEBUG BEGIN STMT;
- if (TARGET_EXPR (__atomic_load_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97981
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
Bug ID: 98142
Summary: fstrict-enums optimization applied only for unscoped
enums with unfixed underlying type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
--- Comment #5 from David Edelsohn ---
It has nothing to do with the proper way to install GCC on AIX.
It was not the only -Werror failure on AIX. That is why I said, if that's the
only problem, we're lucky. The -Werror failures change.
The p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98139
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from David Edelsohn ---
> I bootstrap GCC on AIX with, and the instructions in the CompileFarm wiki
> recommend, --disable-werror.
Ah, I missed that. It's the only ins
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=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 operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98069
--- Comment #5 from Richard Biener ---
The proposed fix for PR98137 might also expose more cases like this (which
maybe is a good thing for coverage).
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=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
Priori
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 n
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=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
c
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 de
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 constrai
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.C2020-1
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 opp
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=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=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 694d4a6d
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, then
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&action=edit
Hacky patch.
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
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
P
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]
1 - 100 of 126 matches
Mail list logo
