https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
Torbjorn SVENSSON changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
Bug ID: 116444
Summary: gcc.target/arm/thumb-ifcvt-2.c fails on Cortex-M55 and
misses possible Cortex-M optimization
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445
Bug ID: 116445
Summary: gcc.target/arm/unsigned-extend-2.c on Cortex-M55 and
misses possible Cortex-M optimization
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
Bug ID: 116447
Summary: g++.dg/cpp23/ext-floating13.C fails on Cortex-M55 due
to undefined reference
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
Bug ID: 116448
Summary: gcc.target/arm/vfp-1.c uses the wrong instructions on
Cortex-M55
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115253
Torbjorn SVENSSON changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |azoff at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115253
Torbjorn SVENSSON changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115826
Bug ID: 115826
Summary: vect-tsvc-s1281.c fails with with -ffast-math on
arm-none-eabi
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
Bug ID: 115827
Summary: uninit-17.c no longer emits expected warning on
arm-none-eabi
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
--- Comment #10 from Torbjorn SVENSSON ---
I've sent a patch that drops the lsr check:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656871.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115826
--- Comment #2 from Torbjorn SVENSSON ---
Adding /* { dg-add-options ieee } */ to
gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s1281.c did not change any of the
flags that gcc was invoked with.
I experimented a bit more and found that adding -fno-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
Bug ID: 116032
Summary: [12/13/14/15 Regression] gcc.target/arm/pr40457-2.c
produces larger code for armv7ve+neon
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
Torbjorn SVENSSON changed:
What|Removed |Added
CC||richard.earnshaw at arm dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115826
Torbjorn SVENSSON changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116060
Bug ID: 116060
Summary: -fanalyzer -fdiagnostics-text-art-charset=unicode
replaces typedef'ed type with "int" in some cases
Product: gcc
Version: 14.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
--- Comment #3 from Torbjorn SVENSSON ---
@Andre, did you see the email I sent you yesterday about the regression that
this change introduced?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117408
Bug ID: 117408
Summary: ICE on `#pragma arm "arm_mve.h" false`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117408
Torbjorn SVENSSON changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |azoff at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116444
--- Comment #8 from Torbjorn SVENSSON ---
(In reply to avieira from comment #7)
> @Torbjorn: OK to close?
Yes, this is ok on trunk, but should it also be backported to releases/gcc-14?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117408
Torbjorn SVENSSON changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94531
Torbjorn SVENSSON changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #4 from Torbjorn SVENSSON ---
(In reply to Jakub Jelinek from comment #3)
> libsupc++.a (fundamental_type_info.o) (also included in libstdc++.a and
> libstdc++.so.6)
> should provide those symbols since r13-4722 if the target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #2 from Torbjorn SVENSSON ---
(In reply to Richard Earnshaw from comment #1)
> How was the compiler configured and what's the full command line used when
> building the test?
The toolchain was built using the scripts here:
https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116060
--- Comment #2 from Torbjorn SVENSSON ---
I posted a patch that appears to fix this issue, but I'm not sure if it's the
only thing needed for C++.
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671724.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #9 from Torbjorn SVENSSON ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Torbjorn SVENSSON from comment #7)
> > So, if I understand you correctly Andrew, it's impossible to write the start
> > code in C for a free-sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #7 from Torbjorn SVENSSON ---
So, if I understand you correctly Andrew, it's impossible to write the start
code in C for a free-standing application and build it with -flto into a
library and then reuse that?
I.e. think of the case w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #1 from Torbjorn SVENSSON ---
Created attachment 59928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59928&action=edit
Test case to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
Bug ID: 118136
Summary: Linking start code built with -flto with application
where main signature does not match causes warning
Product: gcc
Version: 15.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116060
Torbjorn SVENSSON changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103298
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #7 from Torbjorn SVENSSON ---
Indeed, it looks like this could be related.
@Christophe, did you take a look at issue in ticket 117814 or is that still on
your todo list? If you did, do you think these tickets are related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118437
Bug ID: 118437
Summary: Unable to include arm_fp16.h on a MVE capable Cortex-M
target
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018
Torbjorn SVENSSON changed:
What|Removed |Added
CC||azoff at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
--- Comment #2 from Torbjorn SVENSSON ---
Thanks Richard. I'll give it a try with -Os and create a patch with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
--- Comment #6 from Torbjorn SVENSSON ---
It worked.
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674476.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018
--- Comment #5 from Torbjorn SVENSSON ---
(In reply to Christophe Lyon from comment #4)
> Rather than a cost issue, it's probably because you use +fp.dp (which
> -mcpu=cortex-m7 does too), which enables the double-precision FPU. cortex-m4
> does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
Torbjorn SVENSSON changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116448
--- Comment #3 from Torbjorn SVENSSON ---
Compiling the test case with -Os resolves the failed checks, but it also starts
failing on the sqrt() and sqrtf() calls. These are no longer expanded to
vsqrt.f32 and vsqrt.f64 but instead a branch to sq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116445
--- Comment #6 from Torbjorn SVENSSON ---
(In reply to Christophe Lyon from comment #5)
> The test has:
> /* { dg-require-effective-target arm_thumb2_ok_no_arm_v8_1_lob } */
> since commit g:d2ed233cb940aa3eecc163d98b47979dd81dbc0a
> with this c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460
Bug ID: 118460
Summary: [14/15 Regression] ICE on armv8.1-m.main with
-mfloat-abi=hard
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118446
Bug ID: 118446
Summary: __builtin_iseqsig does not raise exception when
supplied with NaN on Cortex-M at -O1 or higher
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118446
--- Comment #2 from Torbjorn SVENSSON ---
No, I don't think it's related as armv8-a produces:
$ arm-none-eabi-gcc -march=armv8-a -mfloat-abi=hard -mfpu=neon-fp-armv8 -Os -S
-o - foo.c -dp
...
ffalse:
@ args = 0, pretend = 0, frame = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460
--- Comment #2 from Torbjorn SVENSSON ---
std::hypot() is actually expanded to a min/max like expression.
Anyhow, I've reduced it further down to the following C snippet:
$ cat pr118460.c
_Float16
bar(_Float16 x, _Float16 y)
{
return x < y ?
49 matches
Mail list logo
