https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108939
--- Comment #2 from Anton Nikolaevsky ---
Indeed, with the sample code that I've originally reported the presence of the
flag -std=xxx does not matter. The fact is I started from the following a bit
more complex code:
#include
#include
#d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108927
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #15 from Alexander Monakov ---
That is the fancy-error-handling path that is reached under _LIB_VERSION !=
_IEEE_. Before glibc-2.27, linking with -lieee would set _LIB_VERSION = _IEEE_,
and then glibc would use the fprem[1] instruct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #16 from Jakub Jelinek ---
Doesn't the SDM guarantee the right behavior though?
It is true that the FPREM results table says * and ** in certain spots (Table
3-31 in my copy), but then in the Invalid Arithmetic Operand Exception (#IA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108926
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
--- Comment #2 from Hongtao.liu ---
> patterns it groks, so this would add for 32-bit only 0x03040102 (or, does it
> make sense
It can be even more flexible, .i.e 0x04010203, 0x02030401, rotate count can be
any multiple of 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108940
Bug ID: 108940
Summary: Offset of pointer to global variable not set correctly
for position independent executable
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
--- Comment #3 from Jakub Jelinek ---
You're right. Then we should handle it more generically, basically check if
either the
CMPNOP or CMPXCHG patterns (well, their narrowed counterparts based on size)
would match if rotated by a multiple of 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #17 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #16)
> Doesn't the SDM guarantee the right behavior though?
Indeed, this is what is missing from Table 3-31.
> It is true that the FPREM results table says * and ** i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Richard Biener changed:
What|Removed |Added
Target Milestone|13.0|---
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #18 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #17)
> So, based on the above finding, should insn condition be changed to
> !flag_errno_math?
I'd say that it shouldn't be the business of backends to check flag_errn
et any abort, just the same
> SEGV
> https://godbolt.org/z/rjYG8Yrnh
If you want a PEDASSERT to fire you need to actually request pedantic
assertions.
https://godbolt.org/z/874x18G1G
/opt/compiler-explorer/gcc-trunk-20230227/include/c++/13.0.1/bits/basic_string.h:1645:
constexpr std::__cxx11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #19 from Alexander Monakov ---
I get the feeling that you're ignoring me, but gcc-4.8.3 was already emitting a
helper fmod call for setting errno without any flag_errno_math checks in
i386.md, i.e. it was already in the middle-end. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #20 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #16)
> More questionable is the #Z case, where Table 8-11 just talks about
> Divide or reverse divide operation Returns an ∞ signed with the exclusive
> OR of the
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
Bug ID: 108941
Summary: Error: operand type mismatch for `shr' with binutils
master
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942
Bug ID: 108942
Summary: ICE in build2, at tree.c: 5096 for
gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
--- Comment #4 from Jakub Jelinek ---
And perhaps next to rotate it could try some left or right (logical) shift too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #21 from Uroš Bizjak ---
(In reply to Alexander Monakov from comment #19)
> I get the feeling that you're ignoring me, but gcc-4.8.3 was already
> emitting a helper fmod call for setting errno without any flag_errno_math
> checks in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
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=106594
Tamar Christina changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #2 from Martin Liška ---
Well, I just noticed clang transforms it into:
$ clang libavformat.i -w -S -O2 -o /dev/stdout | grep shr
shrl$255, %eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #22 from Alexander Monakov ---
Strange, comment #8 claims the opposite (unless Jan tested the revert not on
trunk, but on some branch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
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=108941
--- Comment #3 from Jakub Jelinek ---
(In reply to Martin Liška from comment #2)
> Well, I just noticed clang transforms it into:
> $ clang libavformat.i -w -S -O2 -o /dev/stdout | grep shr
> shrl$255, %eax
Well, GNU inline assembly i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #23 from Jan Kratochvil ---
Created attachment 54542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54542&action=edit
fmoderrno.cpp
(In reply to Uroš Bizjak from comment #21)
> When g:93ba85fdd253b4b9cf2b9e54e8e5969b1a3db098 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #24 from Jan Kratochvil ---
(In reply to Alexander Monakov from comment #22)
> Strange, comment #8 claims the opposite (unless Jan tested the revert not on
> trunk, but on some branch).
The testsuite ran on 4341106354c6a463ce3628a4e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2022-12-21 00:00:00 |2023-2-27
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #25 from Jakub Jelinek ---
Note, the 215740 change has been backported to 4.8 branch in r215773 (I've been
wondering why I can't reproduce it on 4.8; and also to 4.9 branch).
Anyway, in 4.7 I see fmodl being called in *.optimized dum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #4 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #1)
> GCC inline asm has always worked like that, the operand is 8-bit and in GCC
> constants are always sign-extended.
But then ...
> If you try just
> st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #26 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #23)
> Created attachment 54542 [details]
> fmoderrno.cpp
>
> (In reply to Uroš Bizjak from comment #21)
> > When g:93ba85fdd253b4b9cf2b9e54e8e5969b1a3db098 is revert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #5 from Jakub Jelinek ---
(In reply to jbeulich from comment #4)
> > In the assembly, if you have a spot which accepts 8-bit quantity, one
> > shouldn't care if it is signed or unsigned.
>
> I firmly disagree: I assume you did look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
--- Comment #12 from Richard Biener ---
The variable is built from
#0 build_local_temp (type=)
at /space/rguenther/src/gcc/gcc/cp/tree.cc:559
#1 0x0110fdc1 in force_target_expr (
type=,
init=, complain=3)
at /space/rg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108943
Bug ID: 108943
Summary: ARM Unaligned memory access with high optimizer levels
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #29 from Jakub Jelinek ---
Note, fmod_optab is only used on i?86 (where because of the commit mentioned
here it was limited to finite math only) and rs6000 (which guards it on unsafe
math optimizations), so both in the fast-math rela
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #6 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #5)
> GCC doesn't even have that information at all, at the RTL level it doesn't
> know
> if it was signed or unsigned.
> All it has is the constraint and op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #30 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #29)
> Note, fmod_optab is only used on i?86 (where because of the commit mentioned
> here it was limited to finite math only) and rs6000 (which guards it on
> unsafe m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #7 from jbeulich at suse dot com ---
Maybe what would help is a discussion in the context of the binutils patch,
despite it already having been committed. As said there and earlier here, there
may be reasons to adjust (back) some of w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #8 from Jakub Jelinek ---
(In reply to jbeulich from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > GCC doesn't even have that information at all, at the RTL level it doesn't
> > know
> > if it was signed or unsigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #9 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #1)
> How does that look like a gcc bug? It is either a binutils bug for not
> accepting it anymore, or ffmpeg-4 bug for relying on the negative shifts.
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #11 from Jakub Jelinek ---
(In reply to jbeulich from comment #9)
> (In reply to Jakub Jelinek from comment #1)
> > How does that look like a gcc bug? It is either a binutils bug for not
> > accepting it anymore, or ffmpeg-4 bug for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #12 from Martin Liška ---
(In reply to jbeulich from comment #9)
> (In reply to Jakub Jelinek from comment #1)
> > How does that look like a gcc bug? It is either a binutils bug for not
> > accepting it anymore, or ffmpeg-4 bug for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #10 from Richard Biener ---
(In reply to Richard Biener from comment #9)
> Note I think there's still a bug in value_range (irange) here.
> get_size_range
> does
>
> if (integral)
> {
> value_range vr;
>
> query-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108944
Bug ID: 108944
Summary: libgm2/libm2pim/sckt.cc:254:3: warning: memset()
called to fill 0 bytes. [memsetZeroBytes]
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #13 from Jakub Jelinek ---
We could file an x86 backend enhancement request based on those comments,
int
foo (int x, int y)
{
return x << (y & 31);
}
int
bar (int x, int y)
{
return x << (32 + y);
}
int
baz (int x, int y)
{
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945
Bug ID: 108945
Summary: [13.0] d: vector float comparison doesn't result in 0
or -1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946
Bug ID: 108946
Summary: [13.0] d: Identity comparison of vectors not supported
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
03b9882-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230227 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108948
Bug ID: 108948
Summary: for function
template with auto return and parameter pack
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200
Jakub Jelinek changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #9 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108948
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108948
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108949
Bug ID: 108949
Summary: Optimize shift counts
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
--- Comment #2 from Eugen Wissner ---
Not sure about class and enum, but „const struct“ results in a similar error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108950
Bug ID: 108950
Summary: [11/12/13 Regression] ICE: verify_gimple failed
(error: conversion of register to a different size in
'view_convert_expr'; error: type mismatch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Richard Biener changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #5 from Jakub Jelinek ---
Created attachment 54544
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54544&action=edit
gcc13-pr108910-lto.patch
Untested fix for the lto side of this bug. No testcase included, as when
the target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108940
--- Comment #1 from Andrew Pinski ---
There should be a .reloc section in the executable which does the fix up ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108943
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108940
--- Comment #2 from Rob Meades ---
Created attachment 54545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54545&action=edit
Disassembly of executable file
Here is the complete disassembly of the executable output file: we do indeed
seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
Gaius Mulley changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
I send this to gcc-help but it would probably be more appropriate.
While compiling a source file with the -fanalyzer option I got a compiler
-Wanalyser-malloc-leak warning. I followed the diagnostic message but
didn't see the problem so I decided to go look at the assembly code.
Compiling the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108944
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #12 from Aldy Hernandez ---
(In reply to Richard Biener from comment #10)
> (In reply to Richard Biener from comment #9)
> > Note I think there's still a bug in value_range (irange) here.
> > get_size_range
> > does
> >
> > if (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #13 from Jonathan Wakely ---
(In reply to Richard Biener from comment #11)
> We can again work around this in libstdc++ by CSEing ->_M_size ourselves.
> The following helps:
>
> diff --git a/libstdc++-v3/include/std/valarray
> b/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108951
Bug ID: 108951
Summary: std::valarray doesn't support extended alignment
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108936
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-02-27
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108944
--- Comment #2 from David Binderman ---
(In reply to Gaius Mulley from comment #1)
> Thank you very much for reporting this bug - very useful regarding PR108835
> (or at least it is related and timely).
You are welcome. gcc flags -Wall and -Wm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108950
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-02-27
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
Bug ID: 108952
Summary: Regression in uses_allocator_construction_args for
pair of rvalue references
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
--- Comment #1 from Andrew Pinski ---
Created attachment 54546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54546&action=edit
testcase
Please next time also attach or put inline the testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #14 from Aldy Hernandez ---
(In reply to Richard Biener from comment #11)
> So I've missed the VR_ANTI_RANGE handling in get_size_range where we run into
>
> wide_int maxsize = wi::to_wide (max_object_size ());
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108940
--- Comment #3 from Andrew Pinski ---
Can you instead attach the output of `readelf -a`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108940
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108949
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953
Bug ID: 108953
Summary: inefficient codegen for trivial equality
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108944
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:e5fcf084e381aefe170dcd418dc97e469dacfa91
commit r13-6359-ge5fcf084e381aefe170dcd418dc97e469dacfa91
Author: Gaius Mulley
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108944
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #12 from Jakub Jelinek ---
Created attachment 54547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54547&action=edit
gcc13-pr108894.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953
Jakub Jelinek changed:
What|Removed |Added
Component|c++ |tree-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #3 from TC --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
--- Comment #5 from Jonathan Wakely ---
(In reply to Peter Dimov from comment #4)
> An easy fix is to use `std::get<0>` instead of `.first`.
Yeah I tried that, but I think there's an additional change needed (or I messed
something up).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108954
Bug ID: 108954
Summary: ICE with invalid gimple source
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #4 from Jens Seifert ---
PPCLE with no special option means -mcpu=power8 -maltivec (altivecle to be mor
precise).
vec_promote(, 1) should be a noop on ppcle. But value gets
splatted to both left and right part of vector register. =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108936
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
1 - 100 of 151 matches
Mail list logo
