||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-07-19
Keywords||ice-on-valid-code
Summary|incorrectly specified array |incorrectly specified array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121157
--- Comment #8 from Eric Botcazou ---
*** Bug 121163 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121157
--- Comment #9 from Eric Botcazou ---
*** Bug 121162 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121162
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
|UNCONFIRMED |RESOLVED
CC||ebotcazou at gcc dot gnu.org
--- Comment #1 from Eric Botcazou ---
.
*** This bug has been marked as a duplicate of bug 121157 ***
||ebotcazou at gcc dot gnu.org
Summary|GNAT internal error when|internal error on Ada's
|using -gcodeview|unconstrained array types
||with -gcodeview
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
--- Comment #11 from Eric Botcazou ---
> If the CC'd target maintainers could confirm my understanding of their area
> above, I would be very grateful. I don't think I need any of you to change
> the code, just let me know if the assembly is fre
||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-07-15
--- Comment #1 from Eric Botcazou ---
Yes, the interface with back-ends would need to be reworked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058
Eric Botcazou changed:
What|Removed |Added
Target Milestone|16.0|---
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058
Eric Botcazou changed:
What|Removed |Added
Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
Ever confirmed|0 |1
CC||ebotcazou at gcc dot gnu.org
Target Milestone|--- |16.0
--- Comment #2 from Eric Botcazou ---
You should be using 15.x at this point, 16.0 is too experimental.
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: dennis at przytarski dot com
CC: dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org
Target Milestone: ---
Status: RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056
Bug ID: 121056
Summary: Assertion failure triggered by access-type dispatch in
Implementation Extension mode
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #14 from Eric Botcazou ---
FWIW the "force functions and their inner functions to remain in a single unit"
approach for LTO was already discussed a few times in the past because of very
similar issues pertaining to the static chain,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #16 from Eric Botcazou ---
> I'll try to recompile GCC 6.5 with GCC 5.5 again, but this time not with
> just '--with-gnu-as', buth with also '--with-as=/usr/local/bin/as'. Perhaps
> that will fix this.
Yes, that's the right thing to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120705
Eric Botcazou changed:
What|Removed |Added
Target Milestone|16.0|15.2
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120854
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120854
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
||concatenation with illegal
||character constant hangs
CC||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2025-06-26 00:00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120705
--- Comment #1 from Eric Botcazou ---
Probably just:
diff --git a/gcc/ada/exp_ch3.adb b/gcc/ada/exp_ch3.adb
index cf2238e9ee1..651e55c5242 100644
--- a/gcc/ada/exp_ch3.adb
+++ b/gcc/ada/exp_ch3.adb
@@ -6902,7 +6902,9 @@ package body Exp_Ch3 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120705
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Ever
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120106
Eric Botcazou changed:
What|Removed |Added
CC||emr-gnu at hev dot psu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Target Milestone|13.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120106
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |16.0
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120106
--- Comment #4 from Eric Botcazou ---
> v02 passes GNATMAKE_FOR_BUILD via BASE_TARGET_EXPORT instead of
> EXTRA_TARGET_FLAGS. Is this less ugly?
Yes, thanks, I'm going to apply it.
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target Milestone: ---
The toplevel Makefile contains these lines:
GFORTRAN_FOR_BUILD = $(GFORTRAN)
GOC_FOR_BUILD = $(GOC)
GDC_FOR_BUILD = $(GDC)
GM2_FOR_BUILD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120665
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|ASSIGNED
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
CC|ebotcazou at gcc dot gnu.org |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120658
--- Comment #5 from Eric Botcazou ---
> One additional question: can you propose how to do better, how to avoid such
> fails? Were programming rules violated here?
Declare a character buffer with the right size (TO_BASE_N) and pass it to
my_to_
||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Eric Botcazou ---
Compiling with -fsanitize=address -g yields:
TO_BASE( (uint)x1i, 10 ): 4287654321
||2025-06-16
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou ---
This has apparently never worked.
||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-06-16
--- Comment #1 from Eric Botcazou ---
The code is simply nonsensical:
p.adb:4:31: warning: empty aggregate returned by the empty function of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
--- Comment #13 from Eric Botcazou ---
Patches are always welcome!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Last
||2025-06-10
Ever confirmed|0 |1
CC||ebotcazou at gcc dot gnu.org
|RESOLVED
CC||ebotcazou at gcc dot gnu.org
--- Comment #1 from Eric Botcazou ---
.
|GNAT.Registry doesn't |GNAT.Registry doesn't
|read/write with |read/write with
|HKEY_LOCAL_MACHINE. |HKEY_LOCAL_MACHINE
Resolution|--- |WONTFIX
CC| |ebotcazou
confirmed|0 |1
CC||ebotcazou at gcc dot gnu.org
||ebotcazou at gcc dot gnu.org
--- Comment #2 from Eric Botcazou ---
> After clicking back to my Compiler Explorer tab I noticed that I failed to
> switch to trunk when testing. This seems to have been fixed already.
Yes, this is fixed in GCC 15 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118712
Eric Botcazou changed:
What|Removed |Added
CC||zzbard at wanadoo dot fr
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120463
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120463
--- Comment #6 from Eric Botcazou ---
> do you need more information or is it OK now for you to investigate
> the bug, please?
Yes, see the end of my last message, we need the command line passed to the
compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #5 from Eric Botcazou ---
> Importance isn't actually a field, it's the combination of Priority and
> Severity. And severity is pretty much ignored, and priority is set according
> to clear rules, so I see no harm in assuming that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120463
--- Comment #4 from Eric Botcazou ---
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
> OFFLOAD_TARGET_DEFAULT=1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
CC| |ebotcazou at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #5 from Eric Botcazou ---
As shown in the log, that's not the compiler build itself but the library
build, so it very likely needs to be ported to th
|1
Status|UNCONFIRMED |WAITING
CC||ebotcazou at gcc dot gnu.org
--- Comment #2 from Eric Botcazou ---
> No more comment.. You've [Gnat, GCC] version & original files.., you should
> be ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #12 from Eric Botcazou ---
> Later in the compilation pipeline, DCE removes insns 6 and 8 as dead code,
> leaving:
>
> _.c.331r.cmpelim:
>
>10: {x1:SI=asm_operands;clobber [scratch];}
>12: {x3:SI=asm_operands;clobber [scrat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #10 from Eric Botcazou ---
Is it really invalid to perform CSE on val though?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120440
--- Comment #6 from Eric Botcazou ---
> It bisects to r15-8901-g7bec4570301c43 which I find very surprising. Double
> checked with a build of r15-8900-g525d4a10302113 (which works) and
> r15-8901-g7bec4570301c43 (which doesn't).
This patch does
||ebotcazou at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #2 from Eric Botcazou ---
__gnat_decode is only used for exception backtraces, which are already slow, so
we do not really care about its run-time performance; readability and easy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120430
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||ebotcazou at gcc dot gnu.org
--- Comment #2 from Eric Botcazou ---
This part of the compiler is not supposed to have changed much, so bisecting
might be helpful indeed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
--- Comment #24 from Eric Botcazou ---
*** Bug 120424 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424
--- Comment #5 from Eric Botcazou ---
*** This bug has been marked as a duplicate of bug 118939 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118989
Eric Botcazou changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87778
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
|--- |FIXED
Target Milestone|--- |15.0
CC||ebotcazou at gcc dot gnu.org
--- Comment #2 from Eric Botcazou ---
Fixed in GCC 15 and later. I'd suggest reporting Ada 2022 issues against GCC
15 only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698
--- Comment #18 from Eric Botcazou ---
> I believe this bug is fixed by the following commit:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=8b26ee407613cdbfc3fb2095c09ae28b4642fd63
>
> This change enables generation of GNU stack notes in g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120104
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120104
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120104
--- Comment #5 from Eric Botcazou ---
The Finalizable aspect is new in GCC 15 and later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120104
Eric Botcazou changed:
What|Removed |Added
Summary|[15/16 regression] |assertion failure on
||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Summary|Assertion failure on use of |assertion failure on
|finalizable aspect |Finalizable aspect with
||abstract
|NEW
CC||ebotcazou at gcc dot gnu.org
Last reconfirmed||2025-05-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120106
--- Comment #1 from Eric Botcazou ---
The build and host changes should be separated. I'm not sure that we want to
change the host side (gnattools) given that they mimic Make-lang.in. The build
changes are more desirable, but the EXTRA_TARGET_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87778
--- Comment #5 from Eric Botcazou ---
The ChangeLog must be relative to the ChangeLog file present gcc/ada:
gcc/ada/
* Make-generated.in: Remove -q gnatmake option.
* gcc-interface/Makefile.in: Likewise.
But the change does more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #44 from Eric Botcazou ---
> Right, sorry, I should clarify—I can see what the *actual* effect of
> -mstackrealign / __force_align_arg_pointer__ is. I'm confused at what its
> *intended* effect is. "Align to 16 bytes, but only if we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #41 from Eric Botcazou ---
> This reads to me like `-mstackrealign` usually decreases
> `incoming_stack_boundary` from 128 to 32; realignment is actually a result
> of that, right?
Yes, both -mstackrealign and force_align_arg_pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2025-05-01
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #39 from Eric Botcazou ---
> What's the difference between the `-mstackrealign` option and the
> `force_align_arg_pointer` attribute?
-mstackrealign (ix86_force_align_arg_pointer) is only used here:
/* In 32bit, use MIN_STACK_BOU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #37 from Eric Botcazou ---
You may want to revert the previous change though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698
--- Comment #10 from Eric Botcazou ---
FIWI I cannot reproduce with GCC 12 on x86-64/Linux and Valgrind is silent (it
is usually very good at catching finalization issues), so this may be more a
code generation issue on the PA than an Ada issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698
--- Comment #9 from Eric Botcazou ---
> also seen with gcc-13
What do you mean exactly here? That it cannot compile GCC 12, or itself, or
GCC 15 or...?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698
Eric Botcazou changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #5 from Eric Botcazou ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958
Eric Botcazou changed:
What|Removed |Added
Target Milestone|14.3|12.5
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958
--- Comment #14 from Eric Botcazou ---
Created attachment 61250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61250&action=edit
Tentative fix
Please give it a try on FreeBSD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #20 from Eric Botcazou ---
> So it looks like enabling SSE somehow forces realigning ESP.
Yes, see comment #5 the audit trail.
|WAITING
Last reconfirmed||2025-04-25
CC||ebotcazou at gcc dot gnu.org
--- Comment #2 from Eric Botcazou ---
The configure line is missing as per https://gcc.gnu.org/bugs/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
--- Comment #18 from Eric Botcazou ---
> So WITH_SIZE_EXPR isn't applicable here? OK, that's a thing
> only introduced by gimplification at the moment, IIRC. So in case
> the VIEW_CONVERT_EXPR is "just" to make the gimplifier emit the
> approp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
--- Comment #16 from Eric Botcazou ---
> Eric, can you try to read through
> https://gcc.gnu.org/wiki/document-middle-end-type-system and amend
> it with comments about Ada?
I added a minimal comment about TYPE_CANONICAL a couple of days ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
--- Comment #14 from Eric Botcazou ---
> FWIW, when I restore my patch on GCC-14 and add the size check to
> useless_type_conversion_p, this then fixes the Ada test case.
>
> diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
> index 0477c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #34 from Eric Botcazou ---
> Those aliasing bugs are very annoying though and I think one reason people
> who care about correctness / reliability tend to use -fno-strict-alasing. It
> would be nice to get this sorted out instead of
|UNCONFIRMED |RESOLVED
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Eric Botcazou ---
That's expected because -fstack-clash-protection is a no-op on Windows (the ABI
already mandates stack checking there).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #30 from Eric Botcazou ---
> Note that this is not directly related to C23 changes. C23 changes reuse the
> across TU rules also inside TU. But here the problem is that the across TU
> aliasing was already broken in some corner case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
Eric Botcazou changed:
What|Removed |Added
Known to work|14.2.0, 15.0|
--- Comment #5 from Eric Botcazou ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119673
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119673
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2025-04-14
Status|UNCONFIRM
1 - 100 of 2508 matches
Mail list logo
