https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #6 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #5)
> static void
> sparc_asm_function_epilogue (FILE *file)
> {
> /* If the last two instructions of a function are "call foo; dslot;"
> the return address mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #8 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #7)
> > I still think that the profiling counter increment in the
> > __builtin_unreachable() path is a bug.
>
> How so? I only see a missed optimization, but with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98135
Bug ID: 98135
Summary: arm: Inconsistent automatic selection of FPU variant
from -mcpu= and -march= options
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98595
Bug ID: 98595
Summary: [RISC-V, Ada] a-nallfl.ads:48:13: warning: profile of
"Sin" doesn't match the builtin it binds
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98595
Sebastian Huber changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98878
--- Comment #1 from Sebastian Huber ---
It may have something to do with TARGET_RISCV_DEFAULT_ABI == ilp32d. The
gcc/tm.h in the build tree contains this:
gcc/tm.h:#ifndef TARGET_RISCV_DEFAULT_ARCH
gcc/tm.h:# define TARGET_RISCV_DEFAULT_ARCH rv3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Bug ID: 99151
Summary: Missed optimization: Superfluous stack frame and code
with noreturn or __builtin_unreachable()
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #2 from Sebastian Huber ---
(In reply to Jakub Jelinek from comment #1)
> This is done intentionally, so that one gets e.g. usable backtraces from
> abort.
Ok, the stack frame could be a feature.
The extra nop on SPARC hurts a bit i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #4 from Sebastian Huber ---
(In reply to Andrew Pinski from comment #3)
> Is the nop due to alignment?
With -g and -coverage I get this code:
sparc-rtems7-gcc -O2 -o - -S unreachable.c -fverbose-asm -g -coverage
.file "unr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100357
Bug ID: 100357
Summary: attribute noinit with -fdata-sections unexpected
behaviour
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100357
Sebastian Huber changed:
What|Removed |Added
Summary|attribute noinit with |unexpected behaviour of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Bug ID: 108658
Summary: [GCOV] Function entry is not recorded in a function
containing an infinite loop depending on the
optimization level
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
--- Comment #3 from Sebastian Huber ---
Thanks for the hint, however, adding -pthread or -fprofile-update=atomic
doesn't change anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Sebastian Huber changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104090
Bug ID: 104090
Summary: [10/11/12 Regression] powerpc: asm machine directive
wrong for FSL processors
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104090
--- Comment #1 from Sebastian Huber ---
I work on a patch, see:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588641.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
Bug ID: 104121
Summary: [12 Regression] v850: Infinite loop in
find_reload_regno_insns()
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
--- Comment #2 from Sebastian Huber ---
Created attachment 52235
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52235&action=edit
Pre-processed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104090
Sebastian Huber changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #18 from Sebastian Huber ---
clang 11 produces this code for the attached test case:
clang -O2 -S -o - pr50883.c -target arm
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
clang-11.0: warning: unknown platform, ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
--- Comment #8 from Sebastian Huber ---
I can't reproduce the issue with the reduced test case, however, compiling the
preprocessed file still results in an infinite loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103150
Bug ID: 103150
Summary: Structure return is not optimized on 32-bit targets
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031
Bug ID: 108031
Summary: riscv: Access of members of a global structure is not
optimized in atomic operations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106282
Bug ID: 106282
Summary: m68k: Problem with thread-local storage and -mcpu=5206
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
Bug ID: 109566
Summary: powerpc: unrecognizable insn for -mcpu=e6500
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
Sebastian Huber changed:
What|Removed |Added
Known to work||12.1.0, 12.2.0
--- Comment #1 from Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
--- Comment #2 from Sebastian Huber ---
Sorry for the confusion, the actual bad commit was the follow up commit (NOT
d75be7e4343f049176546aa9517d570e5eb67954):
commit 6cc3394507a2303a18891d34222c53f679256c37
Author: Andrew MacLeod
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
Sebastian Huber changed:
What|Removed |Added
Summary|powerpc: unrecognizable |powerpc: unrecognizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
--- Comment #4 from Sebastian Huber ---
(In reply to Sebastian Huber from comment #3)
> I get this error also for -mcpu=power3, ..., -mcpu=power10.
I get the ICE only in 32-bit mode, the 64-bit mode works:
powerpc-rtems6-gcc -O2 -mcpu=power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
--- Comment #7 from Sebastian Huber ---
(In reply to Jakub Jelinek from comment #6)
> How have you configured gcc? I certainly can't reproduce this with
> --enable-targets=powerpc64-linux,powerpc-linux --with-cpu-32=power7
> --with-cpu-64=power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
--- Comment #15 from Sebastian Huber ---
Thanks for digging into this. With the change I am able to build the
powerpc-rtems target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112777
--- Comment #3 from Sebastian Huber ---
I think the issue is in c-cppbuiltin.cc:
builtin_define_with_int_value ("__LIBGCC_HAVE_LIBATOMIC",
targetm.have_libatomic);
Which is used in libgcov.h like this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #6 from Sebastian Huber ---
It seems that the change
commit acc727cf02a1446dc00f8772f3f479fa3a508f8e
Author: Kewen Lin
Date: Tue Dec 27 04:13:07 2022 -0600
rs6000: Rework option -mpowerpc64 handling [PR106680]
causes a regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #8 from Sebastian Huber ---
Yes, it seems that -mcpu=e6500 -mno-powerpc64 yields the right code for the
attached test case (with or without the -m32).
I am now a bit confused what the purpose of the -m32 and -m64 options is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #10 from Sebastian Huber ---
(In reply to Kewen Lin from comment #9)
> Note that now we only disable implicit powerpc64 for -m32 when the
> OS_MISSING_POWERPC64 is set.
>
> /* Don't expect powerpc64 enabled on those OSes with OS_M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #13 from Sebastian Huber ---
(In reply to Kewen Lin from comment #12)
> (In reply to Sebastian Huber from comment #10)
> > (In reply to Kewen Lin from comment #9)
> > > Note that now we only disable implicit powerpc64 for -m32 when t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
--- Comment #14 from Sebastian Huber ---
Thanks for your help, it seems that this patch fixes the issue for RTEMS:
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 57a2325991b..b36e64fec77 100644
--- a/gcc/config/rs6000/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117475
Bug ID: 117475
Summary: C++20: Union object with atomic integer cannot be
statically initialized
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117475
--- Comment #7 from Sebastian Huber ---
This is not really great for C/C++ compatibility. Is there a way to get
statically initialized atomic integers using the standard C++20 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117475
Sebastian Huber changed:
What|Removed |Added
Version|12.4.0 |13.0
--- Comment #5 from Sebastian Hu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117475
--- Comment #6 from Sebastian Huber ---
(In reply to Andrew Pinski from comment #1)
> >It works with clang 17.0.6:
>
> It is rejected for me with both libstdc++ and libc++ with clang with
> -std=c++20:
>
> :14:3: error: call to implicitly-dele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117475
--- Comment #12 from Sebastian Huber ---
(In reply to Andrew Pinski from comment #11)
> Note again the only reason clang 17 from opensuse works is because it is
> using GCC's libstdc++ from GCC 7 which is pre the fix for PR 58605 (which
> was do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117475
--- Comment #17 from Sebastian Huber ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Andreas Schwab from comment #13)
> > > Note again the only reason clang 17 from opensuse works is because it is
> > > using GCC's libstdc++ fr
48 matches
Mail list logo
