https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108461
--- Comment #1 from Arseny Solokha ---
Created attachment 54304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54304&action=edit
gkd diff w/ -m64
Compiling w/ -m64 instead of -m32 yields the attached gkd diff.
This PR can be actually a d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108461
Bug ID: 108461
Summary: '-fcompare-debug' failure (length) w/ -mcpu=e500mc -O2
-ftrapv -fno-expensive-optimizations
-fno-guess-branch-probability -fno-tree-dce
-fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449
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=108449
--- Comment #2 from Richard Biener ---
OK, so early we still have vfork() 'static' and maybe_special_function_p
returns false. But then check_global_declaration () comes along and does
/* Warn about any function declared static but not defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #43 from rguenther at suse dot de ---
On Thu, 19 Jan 2023, xry111 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
>
> --- Comment #42 from Xi Ruoyao ---
> (In reply to Richard Biener from comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96887
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96419
Andrew Pinski changed:
What|Removed |Added
URL|https://gcc.godbolt.org/z/c |
|7E3P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95871
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95010
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-19
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #7 from Andrew Pinski ---
I do notice some aliasing violations with y_map_index and
y_strucon_handleErrorHelper
y_vec* stack;
...
y_map_existsStringKey_v(d->contexts, ("com.yzena.yc.error_handler"),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #6 from Gavin Howard ---
Created attachment 54302
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54302&action=edit
An Amalgamation to Reproduce
I have managed to make an amalgamation that reproduces the bug. When you unzip
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108460
--- Comment #1 from tim blechmann ---
possibly related to 95330?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108460
Bug ID: 108460
Summary: -Wmissing-braces with ctad
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55768
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83932
--- Comment #2 from Andrew Pinski ---
We do handle the default argument in other places correctly that is we reject:
struct g
{
int operator()(int i = 1, int j){return 0;}
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84373
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html
>
>
> Confirmed.
I should note that paper clearifies this to the tea now:
A parameter sha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84373
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-19
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82325
Andrew Pinski changed:
What|Removed |Added
Component|c++ |middle-end
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #20 from Alexandre Oliva ---
The bug is now either fixed or latent in the trunk, I'm not sure which, because
I have not got as far as figuring out why removing unnecessary address cselib
lookups in debug insns made a difference to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040
Andrew Pinski changed:
What|Removed |Added
Target Milestone|8.0 |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #19 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:3c99493bf39a7fef9213e6f5af94b78bb15fcfdc
commit r13-5252-g3c99493bf39a7fef9213e6f5af94b78bb15fcfdc
Author: Alexandre Oliva
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
--- Comment #3 from Andrew Pinski -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102213
Andrew Pinski changed:
What|Removed |Added
Summary|Incorrect executable|virtual consteval is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106485
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106485
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 104512, which changed state.
Bug 104512 Summary: [c++20] consteval constructor does not need to initialize
all data members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #11 from niXman ---
Created attachment 54301
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54301&action=edit
patch
(In reply to niXman from comment #9)
> although I think these two bugs have the same cause...
right, it was th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95968
Andrew Pinski changed:
What|Removed |Added
Keywords|rejects-valid |
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #42 from Xi Ruoyao ---
(In reply to Richard Biener from comment #41)
> We could fix the testcase with
>
> diff --git a/gcc/testsuite/gcc.dg/pr95115.c b/gcc/testsuite/gcc.dg/pr95115.c
> index 69c4f83250c..09273e445d2 100644
> --- a/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #15 from Jerry DeLisle ---
Do we close this bug as invalid or do we need to adjustsomething?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458
--- Comment #2 from Andrew Pinski ---
Note GCC does implement consteval which allows for:
static_assert([]() { if consteval { return std::vector{1, 2} ==
get_val(std::vector>{
{1, 2}, {3, 4}}); } }()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458
--- Comment #1 from Andrew Pinski ---
These all work too:
static_assert([]()consteval {return std::vector{1, 2} ==
get_val(std::vector>{
{1, 2}, {3, 4}}); }());
static_assert([]()consteval {return std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> static_assert is an immediate function context
static_assert is NOT an immediate function context sorry for the typo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104512
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #23 from Michael_S ---
(In reply to Jakub Jelinek from comment #19)
> So, if stmxcsr/vstmxcsr is too slow, perhaps we should change x86
> sfp-machine.h
> #define FP_INIT_ROUNDMODE \
> do {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #37 from H.J. Lu ---
It is
if ((__atomic_fetch_xor_4 ((volatile void *) a, (unsigned int) (1 << bit), 0)
& (unsigned int) (1 << bit)) != 0)
vs
if ((__atomic_fetch_xor_4 ((volatile void *) a, 1 << bit, 0) >> bit & 1) != 0)
Why do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #22 from Michael_S ---
(In reply to Michael_S from comment #8)
> (In reply to Thomas Koenig from comment #6)
> > And there will have to be a decision about 32-bit targets.
> >
>
> IMHO, 32-bit targets should be left in their current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #7 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> I'm surprised by rr_union_table content.
> // VREL_VARYING
> { VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
> VREL_VARYING, VREL_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
Tobias Burnus changed:
What|Removed |Added
Attachment #54265|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> I see fold_using_range::relation_fold_and_or
> which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because
> of
> relation_union (relation1, rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459
Bug ID: 108459
Summary: [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in
expand_omp_for_init_counts
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108424
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:0f85ae6591c92b161693073c0931c7ca1d5d0c5a
commit r13-5249-g0f85ae6591c92b161693073c0931c7ca1d5d0c5a
Author: Marek Polacek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-01-18
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469
--- Comment #18 from Jan Hubicka ---
It should just make any bug to go latent. It surprises me it makes any
difference given that things not cloned by ipa-cp should be all handled by
ipa-sra.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108458
Bug ID: 108458
Summary: Incorrect detection of constexpr heap usage in
non-constexpr context
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457
--- Comment #2 from dave.anglin at bell dot net ---
On 2023-01-18 4:07 p.m., pinskia at gcc dot gnu.org wrote:
> Basically C[TL]Z_DEFINED_VALUE_AT_ZERO macro does not always use its arguments
> so they don't get marked as used ...
Yes. PA uses t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
--- Comment #5 from David Faust ---
(In reply to Andrew Pinski from comment #4)
> (In reply to David Faust from comment #3)
> > Thanks for the info Andrew. I'll look at __builtin_offsetof.
> >
> > As for the implementation in clang, I can point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457
Andrew Pinski changed:
What|Removed |Added
Summary|tree-ssa-loop-niter.cc:2255 |[13 Regression]
|:23:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457
Bug ID: 108457
Summary: tree-ssa-loop-niter.cc:2255:23: warning: variable
'mode' set but not used
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108454
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-01-18
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #32 from niXman ---
> Thanks. Your Windows related changes look good to me.
great, thanks!
> FYI, I am unsure about the need to change all backslashes to slashes and
> wonder if this is a backwards incompatible change for users of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #12 from Brecht Sanders ---
I couldn't apply that patch. Is that for 12.2.0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #5 from Jakub Jelinek ---
I'm surprised by rr_union_table content.
// VREL_VARYING
{ VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
VREL_VARYING, VREL_VARYING, VREL_VARYING },
is obviously correct, sure,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #21 from Wilco ---
(In reply to Jakub Jelinek from comment #20)
> __attribute__((noinline, optimize ("rounding-math"))) static int
> round_to_nearest (void) { return 1.0f - __FLT_MIN__ == 1.0f + __FLT_MIN__; }
Wouldn't that always s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #31 from Bill Zissimopoulos ---
(In reply to niXman from comment #29)
> Created attachment 54285 [details]
> patch
>
> another version of the patch.
Thanks. Your Windows related changes look good to me.
FYI, I am unsure about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #30 from Bill Zissimopoulos ---
(In reply to niXman from comment #29)
> Created attachment 54285 [details]
> patch
>
> another version of the patch.
Sorry for the delay. Will look at it now.
(In reply to niXman from comment #28)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #4 from Jakub Jelinek ---
I see fold_using_range::relation_fold_and_or
which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because of
relation_union (relation1, relation2) == VREL_VARYING fold it to 1.
But for floatin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
--- Comment #3 from David Faust ---
Thanks for the info Andrew. I'll look at __builtin_offsetof.
As for the implementation in clang, I can point to some bits relevant to
the builtin itself:
llvm-project/clang/lib/CodeGen/CGBuiltin.cpp
CodeGen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #20 from Jakub Jelinek ---
__attribute__((noinline, optimize ("rounding-math"))) static int
round_to_nearest (void) { return 1.0f - __FLT_MIN__ == 1.0f + __FLT_MIN__; }
and
if (round_to_nearest ()) \
_fcw = FP_RND_NEAREST; \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #19 from Jakub Jelinek ---
So, if stmxcsr/vstmxcsr is too slow, perhaps we should change x86 sfp-machine.h
#define FP_INIT_ROUNDMODE \
do {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #10 from niXman ---
(In reply to Jakub Jelinek from comment #8)
> As Joseph wrote, there were lots of strtod_l.c fixes since 2011 and most of
> them weren't incorporated into libquadmath (unlike most of the math/
> functions which wer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #9 from niXman ---
although I think these two bugs have the same cause...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #18 from W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
--- Comment #2 from Andrew Pinski ---
The reason why is folded is because some folks use the null pointer for
offsetof (previously before GCC added __builtin_offsetof).
I wonder if you could use __builtin_offsetof here.
I also curious how this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #3 from Andrew Macleod ---
Those specialized relations are handled within the floating point range-ops
code iirc. We established that none of the other floating point relations
needed to be exposed to non-floating point code.
The f
.cfi_endproc
.LFE1:
.size f2, .-f2
.ident "GCC: (GNU) 13.0.1 20230118 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #7 from niXman ---
(In reply to niXman from comment #5)
> because it's MinGW specific:
I will paraphrase:
this report is for MinGW.
but another one - 87204, looks like NOT. but im unsure... will work on it too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
--- Comment #1 from David Faust ---
Looks like this is a result of the combination of how the bpf_core_field_exists
macro is defined and some sort of optimization(?) happening in the C frontend.
Consider:
struct S {
unsigned short x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108456
Bug ID: 108456
Summary: attribute deprecated on enum doesn't warn
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #6 from niXman ---
(In reply to niXman from comment #3)
> BTW, I have fixed it for x86_64-mingw32. trying to rebuild for i686-mingw32
> for check.
yeah, it's fixed.
works on x86_64 and i686 MinGW.
will check it on Linux host too for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455
--- Comment #1 from David Malcolm ---
Perhaps should only complain if the deref site dominates the check site in the
supergraph (and both are in the same function?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #5 from Gavin Howard ---
As mentioned, it works at -O0, and UBSan reports nothing until the segfault.
ASan also reports nothing. Valgrind also reports nothing. They all report
nothing at -O0 and -O2.
I keep my code clean of such thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #5 from niXman ---
because it's MinGW specific:
> Demo strtoflt128 error with some subnormals on Windows
but another one - 87204, looks like NOT. but im unsure... will work on it too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455
Bug ID: 108455
Summary: -Wanalyzer-deref-before-check false positive seen in
git pack-revindex.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #4 from Jakub Jelinek ---
I can reproduce it on x86_64-linux with -m32 too:
f1: 0x0.00014707e947d757fbf6f7p-16382
f2: 0x0.00014707e946d257f2f674b9p-16382
but can't with -m64 nor when using glibc 2.35 strtof128 (in that case it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #4 from Andrew Pinski ---
Does it work at -O0?
Does -fsanitizer=address -fsanitizer=undefined report anything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108454
Bug ID: 108454
Summary: ICE in gfc_trans_common, at
fortran/trans-common.cc:1385
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453
Bug ID: 108453
Summary: [10/11/12/13 Regression] ICE in gfc_trans_use_stmts,
at fortran/trans-decl.cc:5361
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108452
Bug ID: 108452
Summary: ICE in gfc_trans_use_stmts, at
fortran/trans-decl.cc:5347
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
G. Steinmetz changed:
What|Removed |Added
Keywords||accepts-invalid,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Bug ID: 108451
Summary: [13 Regression] ICE in check_complete_insertion, at
hash-table.h:578
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450
Bug ID: 108450
Summary: [12/13 Regression] ICE in sort_actual, at
fortran/intrinsic.cc:4380
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #3 from Gavin Howard ---
> Have you tried -fno-strict-aliasing ? I have a feeling like you have some
> aliasing issues in this code ...
Just tried it, same thing happens.
I'll try to make a better test case, but in this case, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449
Bug ID: 108449
Summary: [13 Regression] ICE in eliminate_unnecessary_stmts, at
tree-ssa-dce.cc:1512
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #2 from Andrew Pinski ---
Have you tried -fno-strict-aliasing ? I have a feeling like you have some
aliasing issues in this code ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Bug ID: 108448
Summary: GCC Elides Assignment to Pointer and memcpy
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
1 - 100 of 190 matches
Mail list logo
