https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
--- Comment #12 from Richard Biener ---
Just as data-point on znver2 Uros testcase shows
rguenther@ryzen:/tmp> gcc-11 t.c -Ofast -lm -march=znver2
rguenther@ryzen:/tmp> numactl --physcpubind=3 /usr/bin/time ./a.out
19.18user 0.00system 0:19.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497
--- Comment #2 from Andrew Pinski ---
: In function 'test':
:18:1: error: invalid RHS for gimple memory store: 'var_decl'
18 | }
| ^
iftmp.0
inv
# .MEM_12 = VDEF <.MEM_6>
iftmp.0 = inv;
:18:1: error: invalid RHS for gimple memory stor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104479
Hongtao.liu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497
--- Comment #1 from jbeulich at suse dot com ---
Actually, while trying to determine if there's any kind of workaround for the
actual code where the prior example was derived from, I found that this can be
further simplified:
typedef float __att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104456
Tom de Vries changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104479
--- Comment #4 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:165947fecf4d78c7effb0f1ee15e6942d8dce4ea
commit r12-7193-g165947fecf4d78c7effb0f1ee15e6942d8dce4ea
Author: liuhongt
Date: Thu Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104456
--- Comment #1 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:fd64b09217fbe8fa33b559e61564071e8aca71e5
commit r12-7190-gfd64b09217fbe8fa33b559e61564071e8aca71e5
Author: Tom de Vries
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104496
--- Comment #3 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #2)
> here is type V, a vector type with DImode and hit ICE in build
> build_vector_type_for_mode (type, mode) which take type as inner_type.
>
> type siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104496
--- Comment #2 from Hongtao.liu ---
here is type V, a vector type with DImode and hit ICE in build
build_vector_type_for_mode (type, mode) which take type as inner_type.
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104497
Bug ID: 104497
Summary: SEGV during GIMPLE pass: pre
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104487
--- Comment #3 from jim x ---
I think Clang is correct here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104487
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> ICC and MSVC accept this also.
I should say clang rejects it with recursiveness.
Also I thought I had seen this exact bug filed before but I can't find it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100010
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104496
--- Comment #1 from Hongtao.liu ---
w/ -mno-sse2 -mno-mmx, reproduce ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104487
--- Comment #1 from Andrew Pinski ---
ICC and MSVC accept this also.
d64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220210 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #22 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #20)
> On testing, this is not sufficient - one ends up with ICEs when we reject a
> valid (UNSPEC-wrapped) address here. So I think that the slightly more
> elaborat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #20 from Thomas Rodgers ---
(In reply to Jakub Jelinek from comment #17)
...
> I don't remember the std::bit_cast case right now, OpenMP atomics are about
Not sure if this is what you are talking about (frankly most of this is well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
--- Comment #3 from Martin Sebor ---
It might be possible to run the pass earlier to avoid this problem but I
haven't managed to find a spot that didn't regress some -Wdangling-pointer
tests (at least g++.dg/warn/Wdangling-pointer-2.C). Alterna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104274
--- Comment #4 from David Malcolm ---
This patch seems to fix it, but I'm not yet sure if it's the correct fix.
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index f8f19769258..9b42e9e983d 100644
--- a/gcc/analyzer/re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104274
--- Comment #3 from David Malcolm ---
In theory,
3978 gimplify_assign (local, parm, &stmts);
ought to be generating a "pl.0 = pl;" assignment, but we're hitting this case
in gimplify_modify_expr:
V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104274
--- Comment #2 from David Malcolm ---
In gimplify_parameters:
x86_64:
(gdb) p data.arg
$2 = {type = , mode = E_BLKmode, named = 1,
pass_by_reference = 0}
hppa64-hpux11.3:
(gdb) p data.arg
$29 = {type = , mode = E_DImode, named = 1,
pass_by_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524
Martin Sebor changed:
What|Removed |Added
Component|c |middle-end
--- Comment #8 from Martin Seb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #10 from Frank Heckenbach ---
If it was me, it wasn't intentional, sorry.
The select box on the web form defaults to "FIXED" for me even on reload (F5).
I had to click on the link to itself to get a clean form (set to "DUPLICATE").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #52 from Jonathan Wakely ---
*** Bug 104495 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #9 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:50243f4918c2ed7f1ddbf0e8df97a37aee73ebf2
commit r12-7188-g50243f4918c2ed7f1ddbf0e8df97a37aee73ebf2
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #8 from Jonathan Wakely ---
See PR 66146 comment 26, it affects all architectures, including x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Frank Heckenbach changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #7 from Frank Heck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #5 from Frank Heckenbach ---
As I replacement, I'll use the following code. It's a simple double-checked
lock, probably not as efficient as the original, but seems to work.
Posted here as RFC and for anyone else who encounters the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104274
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-02-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104107
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #4 from Frank Heckenbach ---
Indeed, it has 2.31.
2.34 is only just in Debian experimental, and apparently not available as a
backport.
Since I need my code to run on various systems and I can't realistically
compile a new glibc on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #2 from Frank Heckenbach ---
% g++ -print-multiarch
x86_64-linux-gnu
Debian 11.2, Linux 5.10.0-9-amd64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Bug ID: 104495
Summary: call_once hangs in call after exceptional call
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #19 from Jakub Jelinek ---
With the C7/C8 case, it is actually not just about clearing too much, but
clearing different bits:
struct C0 {};
struct C1 {};
struct C2 : C1, virtual C0 {};
struct C3 : virtual C2, C1 {};
struct C6 { char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #18 from Jakub Jelinek ---
But whether a type is trivially copyable is something only the FE knows, so
that checking should be done somewhere in the FE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885
Roger Sayle changed:
What|Removed |Added
Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104484
--- Comment #3 from Andrew Pinski ---
There is some heuristics going on here. If we mark the function very_heavy as
cold, then GCC does almost the right thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104420
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #16 from Jason Merrill ---
Created attachment 52410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52410&action=edit
sketch of vbase handling
This is roughly what I had in mind, though it's algorithmically poor because it
walk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
Bug 101603 depends on bug 104488, which changed state.
Bug 104488 Summary: Wrong access specification in method pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104488
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63532
Andrew Pinski changed:
What|Removed |Added
CC||me at elchris dot org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104488
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104494
Bug ID: 104494
Summary: -Wsuggest-attribute=noreturn catch 22
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
--- Comment #7 from qinzhao at gcc dot gnu.org ---
for the following IR:
struct sp x;
void (*) (void) _1;
...
[local count: 1073741824]:
_1 = MEM[(struct ptrmemfunc_U *)&x].ptr;
_7 = _1 != 8B;
***Before commit r11-6729-gadb520606ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104490
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524
--- Comment #7 from Fredrik Hederstierna
---
I tested GCC-12 and it now correctly warns for these test cases.
Great work, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
Pavel Sergeev changed:
What|Removed |Added
CC||dzhioev at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
--- Comment #11 from joseph at codesourcery dot com ---
An implementation using division like that definitely isn't valid without
-funsafe-math-optimizations (it gives nonsense results when the exponent
difference between the arguments is too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455
Jeffrey Walton changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Jeffrey Walt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493
Bug ID: 104493
Summary: OpenMP offload map cannot handle const
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104491
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
--- Comment #1 from Andrew Pinski ---
This is most likely the case where we have:
T = y != &z[0];
Z = {Clobber}
If(T)
And then forward prop the comparison after the clobber.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
Bug ID: 104492
Summary: Bogus dangling pointer warning (dangling pointer to
‘candidates’ may be used [-Werror=dangling-pointer=])
Product: gcc
Version: 12.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #15 from Jakub Jelinek ---
Created attachment 52408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52408&action=edit
gcc12-pr102586.patch
I can make it work with a langhook like this. But I can't figure out where in
BINFO to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98797
--- Comment #4 from Brian Sobulefsky
---
(In reply to David Malcolm from comment #3)
> The branch in comment #0 now gives a 404, but in any case I had to rewrite
> the store code in gcc 12 to support detection of uses of uninitialized
> values,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104491
Bug ID: 104491
Summary: gcc: internal compiler error: Segmentation fault
signal terminated program cc1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #14 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #13)
> So, perhaps if RECORD_TYPE type has TYPE_BINFO in clear_padding_type, we
> should be ignoring all the DECL_ARTIFICIAL unnamed fields in the structure
> and ins
Source: gcc-12
Version: 12_12-20220206-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
gcc-12-12-20220206 in experimental FTBFS on hurd-i386 due to missing
patches for gccgo, gnu.h and an yet unresolved bug in src/Makefile.in.
Attached are patches needed fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #13 from Jakub Jelinek ---
So, perhaps if RECORD_TYPE type has TYPE_BINFO in clear_padding_type, we should
be ignoring all the DECL_ARTIFICIAL unnamed fields in the structure and instead
walk the BINFO_BASE_BINFOS ?
Though, in the C8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
--- Comment #10 from Uroš Bizjak ---
FYI, the following testcase:
--cut here--
#include
float
__attribute__((noinline))
_fmodf (float x, float y)
{
return x - truncf (x/y) * y;
}
int
main ()
{
float a, b;
volatile float z;
for (a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102204
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98797
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102204
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:c22f3fb780775b91548e32937a3ce1095a7c72a3
commit r12-7185-gc22f3fb780775b91548e32937a3ce1095a7c72a3
Author: Tobias Burnus
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98797
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:2ac7b19f1e9219f46ccf55f25d8acb3e02e9a2d4
commit r12-7184-g2ac7b19f1e9219f46ccf55f25d8acb3e02e9a2d4
Author: David Malcolm
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
Thomas Rodgers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104488
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #8 from Segher Boessenkool ---
So I am wondering if this is something we want to do at all. It seems not
suitable for stage 4 at all.
The problem is that a "comparison" of a CC against 0 is not a comparison
at all, but the result o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #5 from qinzhao at gcc dot gnu.org ---
fixed in gcc12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #4 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:b32305b41dcafc5fb6974c0da3ce2f62251afdbf
commit r12-7183-gb32305b41dcafc5fb6974c0da3ce2f62251afdbf
Author: Qing Zhao
Date: Thu Feb 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:7ab70ed3aa88b7300b8027bc86268ce6bb808fef
commit r9-9946-g7ab70ed3aa88b7300b8027bc86268ce6bb808fef
Author: Uros Bizjak
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104458
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0cbdb6f7662e404a72f13a1e47609ca7d80ec4fb
commit r10-10447-g0cbdb6f7662e404a72f13a1e47609ca7d80ec4fb
Author: H.J. Lu
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104458
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:3c9a9ce0c1d5fe3d0ac93ff32d7a57e12a5fefb6
commit r11-9552-g3c9a9ce0c1d5fe3d0ac93ff32d7a57e12a5fefb6
Author: H.J. Lu
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:7fbd8c0d3362bcb724db18a0bb168ade4e30f53e
commit r10-10446-g7fbd8c0d3362bcb724db18a0bb168ade4e30f53e
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #3 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:3c1242592458b478d2c88aa8305918662ea16c1c
commit r11-9551-g3c1242592458b478d2c88aa8305918662ea16c1c
Author: Uros Bizjak
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104449
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #2 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:53fcc46339239c4958e2a15bb9e59274133bbcf7
commit r12-7182-g53fcc46339239c4958e2a15bb9e59274133bbcf7
Author: Uros Bizjak
Date: Thu F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104490
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104490
Bug ID: 104490
Summary: Cannot inherit consteval constructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #12 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #11)
> Trying clang++ it agrees with g++ that both c8 and c7 are 32-bytes, contain
> 2 vtable pointers at offsets 0 and 16 into the objects and that c8.c is at
> offs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104447
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #11 from Jakub Jelinek ---
Trying clang++ it agrees with g++ that both c8 and c7 are 32-bytes, contain 2
vtable pointers at offsets 0 and 16 into the objects and that c8.c is at offset
9 and c7.c is at offset 8. The big question is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #10 from Jakub Jelinek ---
So, on
struct C0 {};
struct C1 {};
struct C2 : C1, virtual C0 {};
struct C3 : virtual C2, C1 { virtual int foo () { return 1; } };
struct C6 { char c; };
struct C7 : virtual C6, virtual C3, C1 { virtual int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
--- Comment #3 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #2)
> NP on the timing. My biggest concern (as always) is whether or not this is
> a generic issue or a bug in the v850 target files. The former is obviously
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104489
--- Comment #1 from Tom de Vries ---
Created attachment 52407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52407&action=edit
reproducer
$ xgcc -B/home/vries/nvptx/trunk/build-gcc/./gcc/ -O2 -S mulhc3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #30 from Vladimir Makarov ---
(In reply to Richard Biener from comment #29)
> (In reply to Vladimir Makarov from comment #28)
> > Could somebody benchmark the following patch on zen2 470.lbm.
>
> Code generation changes quite a bit,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104489
Bug ID: 104489
Summary: nvptx, sm_53: internal compiler error: in
gen_rtx_SUBREG, at emit-rtl.cc:1022
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #7 from rdapp at linux dot ibm.com ---
Sorry for not getting back to this earlier, talked to Segher off-list about
this quickly.
>> The check
>>
>> if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode))
>
> With compare_
1 - 100 of 176 matches
Mail list logo
