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
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
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
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
Hi,
Require effective target non_strict_prototype in a few test-cases.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[testsuite] Require non_strict_prototype in a few tests
gcc/testsuite/ChangeLog:
2022-02-10 Tom de Vries
* gcc.c-torture/compile/pr100576.c: Require
Hi,
Require effective target alloca in a few test-cases.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[testsuite] Require alloca support in a few tests
gcc/testsuite/ChangeLog:
2022-02-10 Tom de Vries
* c-c++-common/Walloca-larger-than.c: Require effective target alloca.
Hi,
With GOMP_NVPTX_JIT=-00 and -mptx=3.1, I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-version-1.c \
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 \
execution test
...
The problem is that we're generating a diverging branch around
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:
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
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
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:
Hi!
On Thu, Feb 10, 2022 at 04:28:02PM -0600, Bill Schmidt wrote:
> On 2/10/22 4:11 PM, Segher Boessenkool wrote:
> >> No, trunk has this, for example:
> >>
> >> const signed int __builtin_altivec_vclzlsbb_v16qi (vsc);
> >> VCLZLSBB_V16QI vctzlsbb_v16qi {endian}
> > I see this on trunk:
> >
Hi!
On Thu, Feb 10, 2022 at 05:43:26PM -0500, David Edelsohn wrote:
> -mbig/-mlittle only applies to Linux, not AIX and not Darwin.
>
> I changed the BE testcases to add "-mbig" for little endian default
> targets because the compiler implicitly should be operating in big
> endian mode for other
On Fri, Feb 11, 2022 at 2:38 AM liuhongt wrote:
>
> >>> Confirmed. When uncond_op is expensive (there's *div amongst them) that's
> >>> definitely unwanted. OTOH when it is cheap then combining will reduce
> >>> latency.
> >>>
> >>> GIMPLE wise it's a neutral transform if uncond_op is not
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
On Thu, Feb 10, 2022 at 11:20 PM Thomas Schwinge
wrote:
>
> Hi!
>
> On 2022-02-10T16:36:51+, Michael Matz via Gcc-patches
> wrote:
> > On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
> >> On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge
> >> wrote:
> >> > OK to push (now, or in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104496
--- Comment #1 from Hongtao.liu ---
w/ -mno-sse2 -mno-mmx, reproduce ICE.
Martin Sebor via Gcc-patches writes:
> The -Warray-bounds description in the manual is out of date in
> a couple of ways. First it claims that the option is only active
> with optimization, which isn't entirely correct since at least one
> instance is issued even without it. Second, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104487
--- Comment #1 from Andrew Pinski ---
ICC and MSVC accept this also.
el: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220210 (experimental) (GCC)
On Fri, 11 Feb 2022 at 00:14, Jason Merrill wrote:
>
> On 2/9/22 21:18, Zhao Wei Liew via Gcc-patches wrote:
> > Hi!
> >
> > I wrote a patch for PR 25689, but I feel like it may not be the ideal
> > fix. Furthermore, there are some standing issues with the patch for
> > which I would like tips on
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
>
For what it is worth.
On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote:
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The
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
>>> Confirmed. When uncond_op is expensive (there's *div amongst them) that's
>>> definitely unwanted. OTOH when it is cheap then combining will reduce
>>> latency.
>>>
>>> GIMPLE wise it's a neutral transform if uncond_op is not single-use unless
>>> we need two v_c_es.
>>
>> We can leave it
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).
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
The -Warray-bounds description in the manual is out of date in
a couple of ways. First it claims that the option is only active
with optimization, which isn't entirely correct since at least one
instance is issued even without it. Second, the description of
its level 2 suggests it controls the
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104274
--- Comment #3 from David Malcolm ---
In theory,
3978 gimplify_assign (local, parm, );
ought to be generating a "pl.0 = pl;" assignment, but we're hitting this case
in gimplify_modify_expr:
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524
Martin Sebor changed:
What|Removed |Added
Component|c |middle-end
--- Comment #8 from Martin
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").
On Thu, Feb 10, 2022 at 05:43:26PM -0500, David Edelsohn via Gcc-patches wrote:
> For the LE testcases, I changed the target selector to
> "powrpc*-*-linux*" because that is the only PowerPC target that can
> operate as little endian. I could not find a generic "le" target
> selector.
On Thu, Feb 10, 2022 at 10:57:02AM +0100, Richard Biener via Gcc-patches wrote:
> > >>> * g++.dg/warn/Wuninitialized-32.C: New testcase.
The testcase FAILs whenever size_t is not unsigned long:
FAIL: g++.dg/warn/Wuninitialized-32.C -std=c++98 (test for excess errors)
Excess errors:
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
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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
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
On 2/8/22 15:37, Jason Merrill wrote:
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types can trigger -Wdangling-pointer when the argument is used
to store the address of a local variable. Since the stored value is
not
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
hello everyone,
i want to make the variable ompd_dll_locations global to openMP
runtime according to my understanding i should add it to OMP_5.1 {} in
libgomp.map and its definition should be done in initialize_env() function
in env.c is there anything else needed to be done.
another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
On Thu, Feb 10, 2022 at 4:17 PM Bill Schmidt wrote:
>
> Hi!
>
> On 2/10/22 2:50 PM, Segher Boessenkool wrote:
> > On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
> >> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
> >> These built-ins were misimplemented
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
Snapshot gcc-9-20220210 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20220210/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
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.
Hi!
On 2/10/22 4:11 PM, Segher Boessenkool wrote:
> On Thu, Feb 10, 2022 at 03:17:05PM -0600, Bill Schmidt wrote:
/* 1 argument vector functions added in ISA 3.0 (power9). */
-BU_P9V_AV_1 (VCLZLSBB_V16QI, "vclzlsbb_v16qi",CONST, vclzlsbb_v16qi)
-BU_P9V_AV_1 (VCLZLSBB_V8HI,
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
Hi!
On 2022-02-10T16:36:51+, Michael Matz via Gcc-patches
wrote:
> On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
>> On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge
>> wrote:
>> > OK to push (now, or in next development stage 1?) the attached
>> > "Consider 'TDF_UID',
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|---
Per Alan's comment in the bugzilla, fix attr-retain-* tescases for 32-bit
PowerPC.
Bootstrapped and regression tested on powerpc64(32/64) and powerpc64le.
Ok for master?
-Pat
2022-02-10 Pat Haugen
PR testsuite/100407
gcc/testsuite/
* gcc.c-torture/compile/attr-retain-1.c:
On Thu, Feb 10, 2022 at 03:17:05PM -0600, Bill Schmidt wrote:
> >> /* 1 argument vector functions added in ISA 3.0 (power9). */
> >> -BU_P9V_AV_1 (VCLZLSBB_V16QI, "vclzlsbb_v16qi",CONST, vclzlsbb_v16qi)
> >> -BU_P9V_AV_1 (VCLZLSBB_V8HI, "vclzlsbb_v8hi", CONST, vclzlsbb_v8hi)
> >>
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=edit
sketch of vbase handling
This is roughly what I had in mind, though it's algorithmically poor because it
walks all
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
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 *)].ptr;
_7 = _1 != 8B;
***Before commit
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!
Hi!
On 2/10/22 2:50 PM, Segher Boessenkool wrote:
> On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
>> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
>> These built-ins were misimplemented as always having big-endian semantics.
>>
>> Because the built-in
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
Some general observations:
* There are various toplevel GCC subdirectories that are built for the
host (possibly in addition to the target in some cases) but aren't changed
in this patch. Do they get a PIE or PIC build anyway by default? Such
directories include, I think: fixincludes (as a
On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
> These built-ins were misimplemented as always having big-endian semantics.
>
> Because the built-in infrastructure has changed, the modifications to the
>
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
On Feb 10, 2022, Jakub Jelinek wrote:
> PR rtl-optimization/104459
> * df-scan.cc (df_insn_change_bb): Don't call df_set_bb_dirty when
> moving DEBUG_INSNs between bbs.
Thanks, that looks quite reasonable to me. I suppose if we can
reconsider a variant that distinguishes
This test regressed after my PR103752 patch with -march=cascadelake. I
don't understand why that flag makes a difference, but this patch is correct
in any case.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_specializations): Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Dear Fortranners,
when referencing a bad array section after an erroneous previous
declaration we might hit an assert. The assert can be replaced
by a more gracious error recovery. Reported by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From
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++
Hi!
On 2/10/22 2:06 PM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
>> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
>> These built-ins were misimplemented as always having big-endian semantics.
> What is different
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 != [0];
Z = {Clobber}
If(T)
And then forward prop the comparison after the clobber.
Hi!
On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
> These built-ins were misimplemented as always having big-endian semantics.
What is different compared to the trunk version?
Segher
On Thu, Feb 10, 2022 at 06:23:58PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 10, 2022 at 10:42:03AM -0600, Segher Boessenkool wrote:
> > > Not on x86, that isn't a general auto-inc-dec target, but uses PRE_DEC
> > > etc. only for the sp hard register.
> >
> > Ugh. Does it have any benefit from
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of
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:
On Linux/x86_64,
0f58ba4dd6b25b16d25494ae18d15dfa681f9b65 is the first bad commit
commit 0f58ba4dd6b25b16d25494ae18d15dfa681f9b65
Author: Richard Biener
Date: Fri Feb 4 09:46:43 2022 +0100
tree-optimization/104373 - early diagnostic on unreachable code
caused
FAIL:
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=edit
gcc12-pr102586.patch
I can make it work with a langhook like this. But I can't figure out where in
BINFO to find
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,
1 - 100 of 259 matches
Mail list logo
