https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981
--- Comment #7 from mauro russo ---
ok.
Maybe the comment in PR 32071 about this as duplicated may also be removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
philippe.waroquiers at skynet dot be changed:
What|Removed |Added
CC||philippe.waroquier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116990
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116994
Bug ID: 116994
Summary: [15 regression] GCC trunk generates larger code than
GCC 14 at -Os
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #29 from Sam James ---
Honza, can you try with --enable-checking=yes,extra,rtl? I couldn't reproduce
with release checking (and maybe even default too).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #30 from Andrew Pinski ---
What I found is that the testcases are very much violatile on producing or not.
Even different slightly different whitespaces and/or line #s sometimes cause no
longer to reproduce the issue. Even using sli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116994
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #378 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #375)
> (In reply to Kazumoto Kojima from comment #374)
> > Created attachment 59286 [details]
> > a patch for c#367
> >
> > We use movsf_ie as a fall-back f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #5 from Feng Xue ---
(In reply to Tamar Christina from comment #4)
> (In reply to Richard Biener from comment #3)
> > I would suggest to add a STMT_VINFO_ENSURE_NOTRAP or so and delay actual
> > verification to vectorizable_load when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #5 from Andrew Pinski ---
> but it is already in reliable real-world use.
Then that real world use is broken.
>It's a pretty isolated change and doesn't impact any later stages of
>compilation.
It is not exactly isolated, that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #6 from Tamar Christina ---
> Actually, what I wish is that we could allow vectorization on early break
> case for arbitrary address pointer (knowing nothing about alignment and
> bound) based on some sort of assumption specified via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116985
--- Comment #1 from Andrew Pinski ---
Created attachment 59287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59287&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112358
--- Comment #11 from John David Anglin ---
glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=32245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116985
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116991
Bug ID: 116991
Summary: FAIL: 26_numerics/complex/ext_c++23.cc -std=gnu++23
(test for excess errors)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116992
Bug ID: 116992
Summary: FAIL: 30_threads/semaphore/platform_try_acquire_for.cc
-std=gnu++20 (test for excess errors)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
lib
gcc version 15.0.0 20241006 (experimental) (GCC)
[527] %
[527] % gcctk -O3 -fno-tree-ccp -fno-tree-loop-im -fno-tree-dse -c small.c
during GIMPLE pass: vect
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in single_pred_edge, at basic-block.h:342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #379 from Oleg Endo ---
(In reply to Oleg Endo from comment #375)
>
> I've updated my branch https://github.com/olegendo/gcc/commits/devel/sh-lra/
>
> Testsuite results pending.
Comparing latest commit 90d5d797 (LRA enabled) vs. "S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #26 from Jan Hubicka ---
GGC should not release blocks that are still in use. They are linked by
function's block tree and only if dead they are removed by tree-ssa-live.cc
So the question is why that expr has dangliing pointer to d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #27 from Jan Hubicka ---
Hmm, I can not seem to reproduce it. Basically we need to work out why that
expression is streamed. If it is part of function body or part of summary. For
summary it may be missing call to unshare_expr_witho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116993
Bug ID: 116993
Summary: FAIL: g++.dg/tm/pr46270.C -std=gnu++17 (test for
excess errors)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #28 from Eric Botcazou ---
> We also stream out blocks by:
> stream_write_tree_ref (ob, TREE_BLOCK (expr))
> in tree-streamer-out.C, so removing that call will just postpone the problem
> to later ICE.
Of course we'd remove all th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #8 from Arsen Arsenović ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Arsen Arsenović from comment #6)
> > (In reply to Andrew Pinski from comment #5)
> > > > but it is already in reliable real-world use.
> > >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #381 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #378)
> I just tried a full bootstrap using that tree with all languages but Rust
> and Go enabled and it fails with:
>
> during RTL pass: subreg3
> ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #9 from Andrew Pinski ---
(In reply to Arsen Arsenović from comment #8)
> > what happens if you have 2 structs marked as randomize_layout but the order
> > of the definition is different between 2 TUs? Then this breaks unless you
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #11 from Arsen Arsenović ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Arsen Arsenović from comment #8)
> > > what happens if you have 2 structs marked as randomize_layout but the
> > > order
> > > of the definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #382 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #381)
> (In reply to John Paul Adrian Glaubitz from comment #378)
> > I just tried a full bootstrap using that tree with all languages but Rust
> > and Go enabled and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #9 from John David Anglin ---
Noticed in LRA testing - the label operand in the indirect_goto pattern
is an input, not an output.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f6539107b8804bcc3532e748f3f596c5a8b29b44
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #380 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #378)
> Will test Kaz's patch seprately applied to sh-lra-take3.
This bootstraps fine (tested without Go and Rust). So, it's an issue with
Ol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #10 from John David Anglin ---
This commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=29f47b0929e00ef9b880e9157f156c78ff924f5b
fixes an ICE in add_stores. The clobbers of the frame_pointer_rtx
in the nonlocal_goto and builtin_set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #7 from Andrew Pinski ---
(In reply to Arsen Arsenović from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > > but it is already in reliable real-world use.
> >
> > Then that real world use is broken.
> >
> > >It's a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #6 from Arsen Arsenović ---
(In reply to Andrew Pinski from comment #5)
> > but it is already in reliable real-world use.
>
> Then that real world use is broken.
>
> >It's a pretty isolated change and doesn't impact any later stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116920
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #12 from Andrew Pinski ---
(In reply to Kees Cook from comment #4)
> This feature is designed as a "security through obscurity" feature that has
> real-world benefits to specialized high-security deployments where
> performance is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #383 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #382)
> Instead of ...
>
> && REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
>
> ... could we also write it as...
>
> (define_predicate "hard_reg_r0"
> (an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #4 from Kees Cook ---
This feature is designed as a "security through obscurity" feature that has
real-world benefits to specialized high-security deployments where performance
is not a concern.
It is never expected to be compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116990
--- Comment #2 from Andrew Pinski ---
Looks like we assume if the latch is empty it has one predecessor which is not
true here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #11 from John David Anglin ---
This commit fixes the secondary memory needed issue mentioned comment 7.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=220402bfc03cf6a6c5bff11da8497b5374dccfe0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
John David Anglin changed:
What|Removed |Added
Attachment #59178|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981
--- Comment #5 from mauro russo ---
yes, `B` needs to be changed to `B`.
Please, may you remove the dup-relation with PR 32071 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981
--- Comment #6 from Andrew Pinski ---
(In reply to mauro russo from comment #5)
> Please, may you remove the dup-relation with PR 32071 ?
I did right away; now it is just a related (see also) relationship; I was too
fast as marking as a dup sor
42 matches
Mail list logo
