https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121387
--- Comment #5 from Eric Botcazou ---
> So, the question: to avoid unrelated issues do you think it is wise idea to
> "harves" patches from OpenBSD ports to upstream?
Generally speaking, yes, configuration bits for the Ada compiler are welcome
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121387
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120440
--- Comment #25 from Eric Botcazou ---
Thanks for confirming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121159
--- Comment #25 from Eric Botcazou ---
> At least from a user's perspective, that error is not Ok. It does not say
> "-fdelayed-branch is needed," it says "target is not able..."
Admittedly.
> Also, it is important for debugging that code comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121159
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #58 from Eric Botcazou ---
The above commit (r16-2688) was unintentional and has been reverted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120440
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120440
--- Comment #20 from Eric Botcazou ---
> Looking at the dumps:
>
> --- a/a-except.adb.006t.original
> +++ b/a-except.adb.006t.original
> @@ -782,7 +782,7 @@ void
> ada.exceptions.exception_propagation.gnat_gcc_exception_cleanup (system__ex
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120440
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=114065
--- Comment #56 from Eric Botcazou ---
Created attachment 61964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61964&action=edit
v19 more conservative proposal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #55 from Eric Botcazou ---
Following Olivier's message, we decided to go one step farther and to propose
further changes:
- The record types in System.C_Time are declared with both Convention C and
ranges for their components, whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121184
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |15.2
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121184
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
||ebotcazou at gcc dot gnu.org
Last reconfirmed||2025-07-21
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Eric Botcazou ---
Thanks for your attention to details. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121157
Eric Botcazou changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #15 from Eric B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121157
--- Comment #13 from Eric Botcazou ---
Making -gcodeview works for Ada in the general case looks hopeless given the
sophistication of the DWARF required to describe Ada's dynamic types, so the
only way out is probably to force -fgnat-encodings=a
||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...?
1 - 100 of 2524 matches
Mail list logo
