https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #9 from Richard Biener ---
I have also always wondered about that glibc guard, esp. it being the
kitchen-sink fast-math guard rather than sth more specific (yep, we don't have
anything for -funsafe-math-optimizations). That is, I su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
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=118950
--- Comment #5 from Robin Dapp ---
Yeah, the original statement is recognized as a mask conversion pattern:
pr118950.c:9:21: note: vect_recog_mask_conversion_pattern: detected: _152 =
.MASK_LOAD (_230, 8B, _229, 0);
pr118950.c:9:21: note: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
--- Comment #9 from Andrew Pinski ---
I have a patch which builds on top of PR 14295 which improves the situtation
here. It has a few testcase regressions but those are testcase issues which I
will fix up later on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #4 from Thomas Koenig ---
Hm, maybe I am misunderstanding the standard here, or it says something
that was not intentional...
We accept
program memain
interface
subroutine lower () bind(c,name="foo")
end subroutine lowe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23782
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
--- Comment #4 from Andrew Pinski ---
(In reply to AK from comment #3)
> Seems like a duplicate of #59863 ?
No different issue . There we have an array which is all the way constant but
here we have a non-constant part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118860
Heiko Eißfeldt changed:
What|Removed |Added
CC||heiko at hexco dot de
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113715
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118931
--- Comment #2 from Li Pan ---
13 │ int main ()
14 │ {
15 │ vector(16) unsigned char vect__3.5;
16 │ unsigned char a_lsm.2;
17 │ long long int _5;
18 │ vector(16) unsigned char _13;
19 │ unsigned char _29;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114809
--- Comment #4 from Jeffrey A. Law ---
I fixed the missed peephole a while back. But the question about cpop vs other
strategies remains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115763
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
--- Comment #12 from Andrew Pinski ---
optimize_memcpy_to_memset does some simple copy prop but with zeroing. A
similar method could be done for non zeroing and i am going to try that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955
--- Comment #6 from Jeffrey A. Law ---
As I feared, this has just gone latent. If you revert:
bdbbe5d4b6d495ac06ee762540a1277498f2a7a0
7bef3482f27ce13ba7e6c4f43943f28a49e63a40
This can be triggered again on the trunk. Given the sensitivity t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117544
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #49 from LIU Hao ---
(In reply to Luke Dalessandro from comment #48)
> So my understanding is that 104688 basically determined that it's correct to
> implement atomic load with movdqa for aligned addresses on architectures
> with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118931
Li Pan changed:
What|Removed |Added
CC||pan2.li at intel dot com
--- Comment #1 from L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #48 from Luke Dalessandro ---
(In reply to LIU Hao from comment #47)
> (In reply to Luke Dalessandro from comment #46)
> > But if 104688 isn't related to this issue, and thus Jakub's comment was in
> > error, I definitely don't under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #5 from Li Pan ---
Thanks Vineet, update another case with explicit convert. It is unrelated to
the global_reg change.
1 │ #define T float
2 │
3 │ void func(const T * restrict a, const T * restrict b,
4 │
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #47 from LIU Hao ---
(In reply to Luke Dalessandro from comment #46)
> But if 104688 isn't related to this issue, and thus Jakub's comment was in
> error, I definitely don't understand the underlying problem and why clang is
> fine do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118963
Sam James changed:
What|Removed |Added
Target Milestone|--- |13.4
Summary|Miscompile at -O2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118922
--- Comment #9 from Andrew Pinski ---
*** Bug 118963 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118963
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118963
Bug ID: 118963
Summary: Miscompile at -O2/3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #22 from Hongtao Liu ---
(In reply to Sam James from comment #16)
> Bisected to r15-7400-gd3ff498c478ace (not CCing anyone yet as not enough
> useful information).
There's a new patch in [1] which will revert the commit and may fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #16 from Sam James ---
Created attachment 60552
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60552&action=edit
emacs.log.xz
So far, not got anywhere with attempting to copy our packaging into a script.
I've attached a build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-02-21
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118934
--- Comment #2 from Anton Blanchard ---
This reproduces the issue. Build without optimisation to avoid all the code
disappearing:
#define INSNS_1 x = x + 1;
#define INSNS_2 INSNS_1 INSNS_1
#define INSNS_4 INSNS_2 INSNS_2
#define INSNS_8 INSNS_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117544
--- Comment #4 from Jeffrey A. Law ---
Fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #10 from Vineet Gupta ---
(In reply to JuzheZhong from comment #9)
>
> I think we should consider many more different situation and consider it
> carefully. Like:
>
> vsetvli ... e8,mf8 ta ma (demand ratio)
> ...
> vservli zero zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
--- Comment #4 from Andrew Pinski ---
Created attachment 60551
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60551&action=edit
Fixes bbb's stack usage
This patch fixes the stack usage of bbb function in comment #0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Sam James changed:
What|Removed |Added
Summary|[15 regression] Miscompile |[15 regression] Miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117634
Andrew Pinski changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118057
--- Comment #8 from Jeffrey A. Law ---
This is really a costing issue.
Some designs (such as Ventana's) strided access can be very profitable,
particularly for a relatively small stride. On others it may be considerably
worse.
Point being som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118934
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-02-20
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
--- Comment #3 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118946
--- Comment #4 from Andrew Pinski ---
(In reply to Jeffrey A. Law from comment #2)
> Marking as a duplicate of one I happen to know about. I suspect there are
> others.
>
> *** This bug has been marked as a duplicate of bug 94713 ***
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118540
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #21 from Sam James ---
I understand, thanks. I'll keep whittling it down.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94173
Jeffrey A. Law changed:
What|Removed |Added
Summary|[RISCV] Superfluous |Superfluous stackpointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #9 from JuzheZhong ---
(In reply to Andrew Waterman from comment #8)
> > In fact, I'd be rather surprised to see anything preferring tail
> > undisturbed.
>
> Right. To be precise, microarchitectures without register renaming
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118946
--- Comment #3 from Sam James ---
*** This bug has been marked as a duplicate of bug 94173 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94173
Sam James changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713
Jeffrey A. Law changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118946
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #15 from Sam James ---
(In reply to David Malcolm from comment #14)
> FWIW I tried again building emacs (from git) with gcc trunk with
> --with-native-compilation=aot on x86_64 and, annoyingly, "make" completed
> successfully; I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #14 from David Malcolm ---
FWIW I tried again building emacs (from git) with gcc trunk with
--with-native-compilation=aot on x86_64 and, annoyingly, "make" completed
successfully; I see lots of
./native-lisp/31.0.50-677d9325/*.eln
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
H.J. Lu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #20 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #7 from Jeffrey A. Law ---
That's going to be a micro-architectual decision. Some designs aren't
sensitive to the number of vsetvls and I would expect that over time that's
where high performance designs will land over time.
Obviou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #6 from JuzheZhong ---
(In reply to Jeffrey A. Law from comment #5)
> This doesn't seem like an ABI issue (WRT c#2), it's just question of what
> uarchs prefer from a performance standpoint.
>
> With that in mind I'd tend to think t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.4
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923
--- Comment #5 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 60547 [details]
> gcc15-pr118923.patch
>
> Completely untested patch (can't test it right now).
> Not using get_internal_target_expr because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #18 from Vladimir Makarov ---
Created attachment 60549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60549&action=edit
Reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0c3061fe7367b378eb8adf4845fde914faca1f40
commit r13-9384-g0c3061fe7367b378eb8adf4845fde914faca1f40
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
--- Comment #9 from Andrew Pinski ---
(In reply to Sam James from comment #8)
> Sorry about that. It doesn't always hang because of uninit memory.
>
> With Valgrind, I got r15-1757-g4d24159a1fcb15. Does that sound more
> reasonable?
Maybe.
F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #16 from marcus at mc dot pp.se ---
Created attachment 60548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60548&action=edit
Result from check-gcc on stage1 of gcc 14.3 on aarch64_be
The tests finally completed.
So there were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Wilco from comment #6)
> > (In reply to Andrew Pinski from comment #5)
> >
> > > Or you could just do:
> > > #define TARGET_F951_OPTIONS
> > > "%{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #7 from Andrew Pinski ---
(In reply to Wilco from comment #6)
> (In reply to Andrew Pinski from comment #5)
>
> > Or you could just do:
> > #define TARGET_F951_OPTIONS "%{Ofast|ffast-math|funsafe-math-optimizations:
> > \
> > %{!no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #6 from Wilco ---
(In reply to Andrew Pinski from comment #5)
> Or you could just do:
> #define TARGET_F951_OPTIONS "%{Ofast|ffast-math|funsafe-math-optimizations: \
> %{!nostdinc: \
>%:fortran-preinclude-file(-fpre-include= mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923
--- Comment #4 from Jakub Jelinek ---
Created attachment 60547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60547&action=edit
gcc15-pr118923.patch
Completely untested patch (can't test it right now).
Not using get_internal_target_expr b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
--- Comment #3 from Andrew Pinski ---
__FILE__ is actually an string_cst rather than a pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
Attachment #60544|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118952
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
Andrew Pinski changed:
What|Removed |Added
Component|fortran |target
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #2)
> I think the relevant sentence from 19.2, paragraph 2, is
>
> "Furthermore, a binding label shall not be the same as the global identifier
> of any ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
Andrew Pinski changed:
What|Removed |Added
CC||rainer.bitschi at aon dot at
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #4 from Andrew Pinski ---
But it is the later fpre-include.
#define TARGET_F951_OPTIONS "%{!nostdinc:\
%:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"
I wonder if find_fortran_preinclude_file could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961
Bug ID: 118961
Summary: ICE g++ modules with LTO
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #3 from Andrew Pinski ---
I am trying to remember if math-vector-fortran.h is included via the
preprocessor or include Fortran directive.
If the former, then you could use preprocessor directives here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118962
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118962
--- Comment #1 from Andrew Pinski ---
IIRC there are some issues with realigning the stack and main ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Andrew Pinski changed:
What|Removed |Added
Keywords||ra
Component|tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118962
Bug ID: 118962
Summary: Segmentation fault on Windows
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-02-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #13 from Sam James ---
I've only seen this on amd64 so far (2 machines) but I didn't try to reproduce
it on arm64 or elsewhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
--- Comment #7 from Andrew Pinski ---
Valgrind might dectect the removal of the stores. I am not 100% sure though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961
--- Comment #1 from Andrew Pinski ---
Maybe related to:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586290.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
--- Comment #6 from Andrew Pinski ---
DSE4 shows:
```
Deleted dead store: g[1] = 8;
Deleted dead store: g[0] = 5;
```
But as I mentioned the problem is in pcom which is forming an invalid pointer
in the first place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #12 from David Malcolm ---
Sam: what architectures/configurations do you see this on? Comment #0 was
presumably aarch64, but I don't think comment #3 specified anything beyond it
being 64-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118860
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #17 from Sam James ---
Created attachment 60544
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60544&action=edit
gcc-bug.sh
I can reproduce with this script at least. I'll try cut it down next.
1 - 100 of 209 matches
Mail list logo
