[Bug ada/114640] ICE on 'elsif' with complex function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640 --- Comment #1 from simon at pushface dot org --- It turns out that the error does not occur if I change if First_Term = Invalid_Node_Access then -- Empty or all virtual return Invalid_Line_Number; elsif not Contains ((First => to if First_Term = Invalid_Node_Access then -- Empty or all virtual return Invalid_Line_Number; end if; if not Contains ((First =>
[Bug ada/114640] New: ICE on 'elsif' with complex function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640 Bug ID: 114640 Summary: ICE on 'elsif' with complex function call Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57902=edit Code as requested With GCC 12.2.0, get a CE, also at wisitoken-syntax_trees.adb:6183:19 With GCC 13.2.0, get stack overflow With GCC 14.0.1, see below. gcc -c -gnat2022 wisitoken-syntax_trees.adb +===GNAT BUG DETECTED==+ | 14.0.1 20240405 (experimental) (x86_64-apple-darwin21) Assert_Failure failed precondition from sinfo-nodes.ads:3686| | Error detected at wisitoken-syntax_trees.adb:6183:19 | | Compiling wisitoken-syntax_trees.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). wisitoken-syntax_trees.adb wisitoken-syntax_trees.ads wisitoken.ads gnatcoll.ads gnatcoll-memory.ads wisitoken_utils.ads wisitoken-lexer.ads gnatcoll-mmap.ads gnatcoll-strings.ads gnatcoll-strings_impl.ads gnatcoll-atomic.ads a-cdllal.ads a-idllal.ads compilation abandoned
[Bug ada/114636] New: Actual does not match formal in generic instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114636 Bug ID: 114636 Summary: Actual does not match formal in generic instantiation Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57899 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57899=edit example.adb Compiler can’t match an actual type with a formal. This appears to have been present from GCC 8.2, and is still present. Could it be related to PR24480? $ gnatmake -gnatl example.adb gcc -c -gnatl example.adb GNAT 13.2.1 Copyright 1992-2023, Free Software Foundation, Inc. Compiling: example.adb Source file time stamp: 2024-04-08 09:57:34 Compiled at: 2024-04-08 11:09:37 1. procedure Example is 2.generic 3. type Terminals is (<>); 4. type Nonterminals is (<>); 5.package Types is 6. type Action is record 7. data : Integer; 8. end record; 9.end Types; 10. 11.generic 12. type States is (<>); 13. type Input_T is (<>); 14. type Action_T is private; 15.package FSM is 16.end FSM; 17. 18.generic 19. with package Typs is new Types (<>); 20. with package SMs is new FSM 21. (States => <>, Input_T => Typs.Terminals, Action_T => Typs.Action); 22.package Gen is 23.end Gen; 24. 25.package Typs is new Types (Natural, Integer); 26.package SMs is new FSM (Integer, Natural, Typs.Action); 27.package Generator is new Gen (Typs, SMs); | >>> error: actual for "Action_T" in actual instance does not match formal 28. begin 29.null; 30. end Example; 30 lines: 1 error
[Bug ada/106037] ICE with Aggregate aspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #4 from simon at pushface dot org --- This is illegal code: 'aspect "Aggregate" can only be applied to non-array type'. See https://groups.google.com/g/comp.lang.ada/c/FHWcqk1SWRM/m/sYTWUHQxAgAJ, and the (slightly unemphatically worded) ARM 4.3.5(2), "For a type other than an array type, the following type-related operational aspect may be specified" GNAT 14.0.1 20240223 (experimental) Copyright 1992-2024, Free Software Foundation, Inc. Compiling: container_aggregates.adb Source file time stamp: 2024-03-13 15:04:00 Compiled at: 2024-03-13 15:04:53 1. procedure Container_Aggregates is 2. 3.type Array_Type is 4. array (1 .. 10) of Integer 5.with Aggregate => (Empty => Empty_Array); 12 3 >>> error: aspect "Aggregate" can only be applied to non-array type >>> error: incomplete specification for aggregate >>> error: object "Empty_Array" cannot be used before end of its declaration >>> error: improper aggregate operation for "Array_Type" 6. 7.Empty_Array : constant Array_Type := [1..10 => 123]; 8. 9. begin 10.null; 11. end Container_Aggregates; 12. 12 lines: 4 errors
[Bug ada/111909] Filename case sensitivity defaulted wrongly on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 simon at pushface dot org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from simon at pushface dot org --- Fixed on mainline.
[Bug ada/114127] New: [14 regression] Assert_Failure in nlists.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114127 Bug ID: 114127 Summary: [14 regression] Assert_Failure in nlists.adb Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57550=edit Reproducer This was originally found in the equivalent arm-eabi cross compiler. Sources in attached zip file. $ gcc -c framebuffer_ili9341.ads +===GNAT BUG DETECTED==+ | 14.0.1 20240218 (experimental) (x86_64-apple-darwin21) Assert_Failure nlists.adb:952| | Error detected at ili9341-device.adb:44:53 [framebuffer_ili9341.ads:59:4]| | Compiling framebuffer_ili9341.ads| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). framebuffer_ili9341.ads hal.ads hal-framebuffer.ads hal-bitmap.ads framebuffer_ltdc.ads stm32.ads stm32-dma2d_bitmap.ads stm32-dma2d.ads memory_mapped_bitmap.ads soft_drawing_bitmap.ads stm32-ltdc.ads stm32-device.ads stm32_svd.ads stm32_svd-sdio.ads stm32-dma.ads stm32_svd-dma.ads stm32-gpio.ads stm32_svd-gpio.ads stm32-exti.ads hal-gpio.ads stm32-adc.ads stm32_svd-adc.ads stm32-usarts.ads hal-uart.ads stm32_svd-usart.ads stm32-spi.ads stm32_svd-spi.ads hal-spi.ads stm32-spi-dma.ads stm32-dma-interrupts.ads stm32-i2s.ads hal-audio.ads stm32-i2c.ads stm32_svd-i2c.ads hal-i2c.ads stm32-i2c-dma.ads stm32-timers.ads stm32-dac.ads stm32_svd-dac.ads stm32-rtc.ads hal-real_time_clock.ads stm32-crc.ads stm32_svd-crc.ads stm32-sdmmc.ads sdmmc_svd_periph.ads hal-sdmmc.ads hal-block_drivers.ads stm32-sdmmc_interrupt.ads ili9341.ads ili9341-device.ads hal-time.ads ili9341-spi_connector.ads ili9341-device.adb ili9341-regs.ads
[Bug ada/104342] ICE with -gnata -fcallgraph-info=su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104342 --- Comment #5 from simon at pushface dot org --- That thought occurred to me, but does that mean that if this code is compiled with a release branch Bad Things will happen? (I guess the code would probably have to get executed for that to occur)
[Bug ada/104342] [14 regression] ICE with -gnata -fcallgraph-info=su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104342 simon at pushface dot org changed: What|Removed |Added Attachment #52327|0 |1 is obsolete|| --- Comment #3 from simon at pushface dot org --- Created attachment 57530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57530=edit Reproducer (14.0.1)
[Bug ada/104342] [14 regression] ICE with -gnata -fcallgraph-info=su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104342 simon at pushface dot org changed: What|Removed |Added Summary|ICE with -gnata |[14 regression] ICE with |-fcallgraph-info=su |-gnata -fcallgraph-info=su --- Comment #2 from simon at pushface dot org --- This doesn’t occur in 12.2.0 or 13.1.0, but has reappeared in gcc version 14.0.1 20240218 (experimental) (GCC). New reproducer uploaded (same files, new content). gcc -c -gnata -fcallgraph-info=su stm32-spi-dma.adb targetname: "+===GNAT BUG DETECTED==+ | 14.0.1 20240218 (experimental) (x86_64-apple-darwin21) Assert_Failure exp_cg.adb:484| | No source file position information available| | Compiling stm32-spi-dma.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). stm32-spi-dma.adb stm32-spi-dma.ads stm32-spi.ads stm32.ads hal.ads stm32_svd.ads stm32_svd-spi.ads hal-spi.ads stm32-dma.ads stm32_svd-dma.ads stm32-dma-interrupts.ads compilation abandoned gnatmake: "stm32-spi-dma.adb" compilation error
[Bug ada/113979] New: Allocation of 2D array fails when Dynamic Predicate applied to type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113979 Bug ID: 113979 Summary: Allocation of 2D array fails when Dynamic Predicate applied to type Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57455=edit Reproducer This error is present in GCC 11/12/13/14 -- can’t tell about GCC 10. The error doesn’t occur without -gnata. -- $ /opt/gcc-14.0.1-20240114-x86_64/bin/gnatmake alloc2.adb -gnatwa -gnatl -f -gnata gcc -c -gnatwa -gnatl -gnata alloc2.adb GNAT 14.0.1 20240114 (experimental) Copyright 1992-2023, Free Software Foundation, Inc. Compiling: alloc2.adb Source file time stamp: 2024-02-18 14:27:29 Compiled at: 2024-02-18 14:28:05 1. procedure Alloc2 is 2.type Grid is array (Positive range <>, Positive range <>) of Integer with 3. Dynamic_Predicate => Grid'First (1) = 1 and then Grid'First (2) = 1; 4. 5.type Grid_Ptr is access Grid; 6. 7.Data : Grid_Ptr := new Grid (1 .. 10, 1 .. 20); | >>> error: invalid use of subtype mark in expression or call 8. begin -- Alloc2 9.null; 10. end Alloc2; 10 lines: 1 error gnatmake: "alloc2.adb" compilation error
[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877 --- Comment #3 from simon at pushface dot org --- I’ve now found the related documentation[1]. I think the conclusion is that gnatchop is working-as-designed, and that this PR should be marked WONTFIX (or INVALID), as seems best. Sorry for the noise. [1] https://docs.adacore.com/live/wave/gnat_ugn/html/gnat_ugn/gnat_ugn/the_gnat_compilation_model.html#operating-gnatchop-in-compilation-mode
[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877 --- Comment #2 from simon at pushface dot org --- I came across -c in ACATS[1]. I do agree it’s an uncommon usage, and indeed I can’t think of other reasons to do it; perhaps it’s to support porting from other compilers? (if that’s something we should be concerned about still). At the moment, if I gnatchop -c foo.a -w foo_src gnatchop -c bar.a -w bar_src and both foo.a and bar.a contain a configuration-pragma-only section, then bar.a’s configuration pragmas are appended to foo.a’s in gnat.adc in the current working directory. If all configuration pragmas need to be partition-wide, that would justify the current design, but I don’t think that’s the case. I just don’t know what the original use case was, or whether there are users whose workflows would be disrupted by a change (one of those would _not_ be ACATS: it deletes gnatchopped files, including gnat.adc, after each test). [1] https://github.com/gcc-mirror/gcc/blob/2c2f57e4158924467afbf4c2fd3938e507287dab/gcc/testsuite/ada/acats/run_all.sh#L332
[Bug ada/113877] New: gnatchop -c puts gnat.adc in the current working directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877 Bug ID: 113877 Summary: gnatchop -c puts gnat.adc in the current working directory Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57387 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57387=edit Demonstrator In the attached demo, where demo-00.a contains only a configuration pragma, you’d have expected "gnatchop -c *.a tmp" to put the configuration file "gnat.adc" into the same directory "tmp/" as the chopped code. Instead, it’s output into the current directory. $ gnatchop -c *.a tmp writing configuration pragmas from demo-00.a to gnat.adc splitting demo-00.a into: splitting demo-01.a into: tmp/demo.ads $ ls -R demo-00.a demo-01.a gnat.adctmp ./tmp: demo.ads
[Bug ada/104354] ICE with Partition_Elaboration_Policy (Sequential)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104354 --- Comment #3 from simon at pushface dot org --- It happens in 12.2.0, doesn’t happen in 13.1.0 or 13.2.0.
[Bug ada/112781] New: [13?/14 regression] ICE in generic instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112781 Bug ID: 112781 Summary: [13?/14 regression] ICE in generic instantiation Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 56727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56727=edit Reproducer: to be gnatchopped I'm not sure this is in fact a regression in 13; with 13.1.0, the program builds, but when run reports $ ./test Hello World raised PROGRAM_ERROR : test.adb:4 finalize/adjust raised exception With 14.0.0, built from LATEST, we get a bug box: $ gnatmake test.adb gcc -c test.adb +===GNAT BUG DETECTED==+ | 14.0.0 20231126 (experimental) (x86_64-apple-darwin21) Assert_Failure sem_ch3.adb:16970| | Error detected at example.ads:3:9 [test.adb:16:4]| | Compiling test.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). test.adb example.ads compilation abandoned gnatmake: "test.adb" compilation error Reproducer (to be gnat chopped) attached.
[Bug testsuite/112529] New: ACATS test c250002 uses illegal filename on APFS filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112529 Bug ID: 112529 Summary: ACATS test c250002 uses illegal filename on APFS filesystem Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- This test checks that characters in Latin-1 above ASCII.Del can be used in identifiers, character literals and strings. Some of the identifiers are package names, so when the source is "gnatchopped' they become filenames. In Apple's HFS+, although filesystem naming is UTF-8 (well, Apple's version), attempts to create files with Latin-1 names are allowed by silent name conversion: for example, given the filename c250002_á.ads, what is stored is c250002_%E1.ads. In Apple's current APFS, however, this attempt results in failure: $ gnatchop c250002.aw splitting c250002.aw into: c250002_0.ads cannot create c250002_?.ads cannot create c250002_?.adb c250002.adb It would perhaps be ideal to report this test as 'unsupported' if run on macOS, but this could be challenging given the rather ad-hoc nature of the scripts involved. Just not running the test at all wouldn't be right, since it runs OK on other operating systems.
[Bug ada/112461] New: [14 regression] Simple return inside extended return loses updates to return object value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112461 Bug ID: 112461 Summary: [14 regression] Simple return inside extended return loses updates to return object value Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- In a complicated extended return[1] with this structure -- Calculate the sum of the natural numbers up to & including the -- given limit. function Add (Up_To : Natural) return Natural is Round : Natural := 0; begin return Result : Natural := 0 do loop Result := Result + Round; if Round = Up_To then return; end if; Round := Round + 1; end loop; end return; end Add; what was returned was the equivalent of the initial value (here, 0) rather than the value as updated in the loop (NB! this simple loop doesn’t fail, I only include it as an example, since I don’t have a simple reproducer). The problem was introduced after 20231008. [1] https://github.com/alire-project/alire/blob/a69ac7c7a24590bdfe1ca77bcb60386551989696/src/alire/alire-properties-from_toml.adb#L14
[Bug ada/112446] New: Switch -gnatyz included in -gnatyg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112446 Bug ID: 112446 Summary: Switch -gnatyz included in -gnatyg Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 56538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56538=edit Demonstrator "gnatmake --help" states that -gnatyg is equivalent to -gnatydISux, but in fact the new switch -gnatyz (check parentheses not required by operator precedence rules) is included. If this is deliberate, the help information should say so. (Personally, I think that clarifying parens are a valuable help to the reader! Are the GNAT Style Rules published?) Given this (see the attachment), procedure P (P1, P2 : Boolean) is Dummy : Boolean; begin Dummy := (P1) or P2; end P; this happens: $ /opt/gcc-14.0.0-20231105/bin/gnatmake -gnatyg p.adb gcc -c -gnatyg p.adb p.adb:4:13: (style) redundant parentheses [-gnatyz]
[Bug ada/111909] New: Filename case sensitivity defaulted wrongly on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111909 Bug ID: 111909 Summary: Filename case sensitivity defaulted wrongly on macOS Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 56167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56167=edit Demo of code to determine case sensitivity In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the assumption for __APPLE__ is that file names are case-insensitive unless __arm__ or __arm64__ are defined, in which case file names are declared case-sensitive. The associated comment is "By default, we suppose filesystems aren't case sensitive on Windows and Darwin (but they are on arm-darwin)." This change was made in commit b54d1d39d30c (in github gcc-mirror). This means that on aarch64-apple-darwin, file names are declared case-sensitive. I understand that GCC does not currently support iOS/tvOS/watchOS, so we could assume macOS. On macOS, the default filesystem is case-insensitive; changing this function to reflect that would be an improvement. However, it's possible to create case-sensitive filesystems, and some users do when dealing with OSS code. It would be good to check the actual filesystem in use.
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 --- Comment #9 from simon at pushface dot org --- Created attachment 56140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56140=edit C demonstrator As noted in comment 8, the C compiler doesn’t have a problem with finding a file with a combining filename when the #include directice uses a composed filename.
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 --- Comment #8 from simon at pushface dot org --- I think I’d forgotten that compiling páck3.ads on its own, rather than as part of the closure, was the way to demonstrate this problem. It was NOT fixed in darwin19 (it’s still present in darwin23). For interest, I made a C file which #includes a header with an a-acute in its name; the C file uses the composed a-acute, but the header’s file name (as shown by ls) uses the combining a-acute. Compiles without complaint. Attachment c-demo.zip. On third thoughts, this should probably go back to SUSPENDED. When I looked into it, it seemed to involve quite deep parts of the compiler, which probably means that the Ada maintainers would be resistant (especially since AdaCore don’t support macOS).
[Bug ada/55119] Ada.Directories only handles files under 2GB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55119 --- Comment #2 from simon at pushface dot org --- I think this is OBE: fixed 2014-08-01, r213412, by making attr->file_length __int64. The comment in adaint.c is still wrong! Just tested on macOS with a 5GB download.
[Bug ada/50502] GNAT fails to compile a modification of B37101A ACATS test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50502 --- Comment #3 from simon at pushface dot org --- The sample compiles without error with GCC 13.1.0 and 14.0.0 20231008. Close as fixed?
[Bug ada/111813] New: Inconsistent limit in Ada.Calendar.Formatting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111813 Bug ID: 111813 Summary: Inconsistent limit in Ada.Calendar.Formatting Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 56107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56107=edit Demonstrator The Value function's description (ARM 9.6.1(87)[1] doesn't place any limitation on the Elapsed_Time parameter's value, beyond "Constraint_Error is raised if the string is not formatted as described for Image, or the function cannot interpret the given string as a Duration value". It would seem reasonable that Value and Image should be consistent, in that any string produced by Image should be accepted by Value. Since Image must produce a two-digit representation of the Hours, there's an implication that its Elapsed_Time parameter should be less than 100 hours (the ARM merely says that in that case the result is implementation-defined). The current implementation of Value raises Constraint_Error if the Elapsed_Time parameter is greater than or equal to 24 hours. The attached demonstrator (calendar_format_value.adb) shows Image accepting an Elapsed_Time of 24h00m00s, converting it to "24:00:00"; given this string, Value raises Constraint_Error. This issue is present in GCC 10, 11, 12 and 13, but probably not worth backfitting. [1] http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-9-6-1.html#p87
[Bug target/111481] MacOS, linker issues with Xcode 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111481 --- Comment #2 from simon at pushface dot org --- A fix for the Ada issue is to link with the classic linker: $ gnatmake hello -largs -Wl,-ld_classic gcc -c hello.adb gnatbind -x hello.ali gnatlink hello.ali -Wl,-ld_classic $
[Bug target/111481] MacOS, linker issues with Xcode 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111481 --- Comment #1 from simon at pushface dot org --- The -macosx_version_min issue appears to have been resolved in GCC 14.0.0 20230820. The Ada linking issue remains.
[Bug target/111481] New: MacOS, linker issues with Xcode 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111481 Bug ID: 111481 Summary: MacOS, linker issues with Xcode 15 Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Running on a Mac mini with Apple silicon (M1), with Darwin 22.6.0 (macOS 13.5.2) and Command Line Tools version 15.0.0.0.1.1694021235. The compiler is GCC 13.1.0, for x86_64-apple-darwin21 (so, running under Rosetta). Compiling hello.c gives the following result: $ gcc hello.c -macosx_version_min has been renamed to -macos_version_min Running otool -l hello.o reports minos 13.0, so we may not have needed to specify the old version of the switch anyway. The executable runs as expected. Compiling hello.adb fails: $ gnatmake hello.adb gcc -c hello.adb gnatbind -x hello.ali gnatlink hello.ali -macosx_version_min has been renamed to -macos_version_min 0 0x100837f43 __assert_rtn + 64 1 0x100739f43 ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411 2 0x100756431 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 19745 3 0x100766e44 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 1380 4 0x7ff8128ae066 _dispatch_client_callout2 + 8 5 0x7ff8128bfe09 _dispatch_apply_invoke + 213 6 0x7ff8128ae033 _dispatch_client_callout + 8 7 0x7ff8128be0f6 _dispatch_root_queue_drain + 683 8 0x7ff8128be768 _dispatch_worker_thread2 + 170 9 0x7ff812a4bc0f _pthread_wqthread + 257 ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. collect2: error: ld returned 1 exit status gnatlink: error when calling /opt/gcc-13.1.0/bin/gcc gnatmake: *** link failed.
[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114 --- Comment #6 from simon at pushface dot org --- (In reply to simon from comment #1) > Further: > > $ GNAT_FILE_NAME_CASE_SENSITIVE=1 gnatmake -c p*.ads > gcc -c páck3.ads > páck3.ads:1:10: warning: file name does not match unit name, should be > "páck3.ads" > > The reason for this apparently-bizarre message is[1] that macOS takes > the composed form (lowercase a acute) and converts it under the hood > to what HFS+ insists on, the fully decomposed form (lowercase a, combining > acute); thus the names are actually different even though they _look_ > the same. This behaviour (I think it was an error) was fixed by darwin 19. Opening by a name with the composed form now correctly finds the file named with the fully decomposed form.
[Bug ada/88610] ICE with new ACATS test c452003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88610 --- Comment #4 from simon at pushface dot org --- This problem has been fixed for some time now - I think in GCC 11.
[Bug target/107860] Compilation failure, ambiguous fisttp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860 --- Comment #9 from simon at pushface dot org --- (In reply to Andrew Pinski from comment #8) > You need to do "arch -x86_64 bash" to this build really. > Otherwise you end up with the arm64 assembler. > So if you start with that, it should work. Exactly so. I don't think I completely understood your point at the time, sorry about that, but today I verified it!
[Bug bootstrap/110467] Bootstrap with Ada enabled fails with --enable-host-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110467 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #6 from simon at pushface dot org --- I hadn't spotted this, so attempted an Ada build with gcc-14-20230702 and got this: make[3]: *** No rule to make target `../libiberty/pic/libiberty.a', needed by `cc1-checksum.cc'. Stop. make[3]: Leaving directory `/Volumes/Miscellaneous3/x86_64/gcc-14-20230702/gcc/gcc' gcc-14-20230702/gcc/ is automatically configured with --enable-host-pie, should libliberty/ be also?
[Bug ada/109798] Gnat Bug Detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798 --- Comment #7 from simon at pushface dot org --- I *can* reproduce with /opt/gcc-13.1.0-aarch64/bin/gcc -c -x ada -gnatA -Og -ffunction-sections -fdata-sections -g -gnatwa -gnatw.X -gnatVa -gnaty3 -gnatya -gnatyA -gnatyB -gnatyb -gnatyc -gnaty-d -gnatye -gnatyf -gnatyh -gnatyi -gnatyI -gnatyk -gnatyl -gnatym -gnatyn -gnatyO -gnatyp -gnatyr -gnatyS -gnatyt -gnatyu -gnatyx -gnatW8 -gnatec=/private/var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T/GNAT-TEMP-03.TMP -gnatem=/private/var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T/GNAT-TEMP-04.TMP /Users/simon/Developer/bugs/gcc/109798/alire/testing/src/testing.adb where the -gnatec file contains pragma Source_File_Name_Project (Spec_File_Name => "*.ads", Casing => lowercase, Dot_Replacement => "-"); pragma Source_File_Name_Project (Body_File_Name => "*.adb", Casing => lowercase, Dot_Replacement => "-"); and the -gnatem file contains testing_config%s testing_config.ads /Users/simon/Developer/bugs/gcc/109798/alire/testing/config/testing_config.ads testing%b testing.adb /Users/simon/Developer/bugs/gcc/109798/alire/testing/src/testing.adb I think it’s the -gnatVa (I took out the -f*sections and all the style options except a simple -gnaty).
[Bug ada/109798] Gnat Bug Detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #1 from simon at pushface dot org --- Can’t reproduce (Darwin 22.4.0, GCC 12.1, 12.2, 13.1). I _do_ get the annoying warning that array aggregates using () is an obsolescent syntax - see PR104751.
[Bug ada/108157] [12/13/14 regression] object subtype doesn't statically match designated subtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108157 --- Comment #2 from simon at pushface dot org --- Still present in 13.1.0.
[Bug ada/108801] ICE, task’s secondary_stack_size from parent discriminant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108801 --- Comment #3 from simon at pushface dot org --- Fixed in GCC 13.1.0.
[Bug ada/109472] New: [13 regression] False unread/unassigned warning for variable in local package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109472 Bug ID: 109472 Summary: [13 regression] False unread/unassigned warning for variable in local package Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 54830 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54830=edit Demonstrator The compiler warns that a variable in a local package is not assigned and not read, even though it is assigned and read in code outside the package. GNAT 13.0.1 20230409 (experimental) Copyright 1992-2023, Free Software Foundation, Inc. Compiling: test_wu.adb Source file time stamp: 2023-04-11 14:20:32 Compiled at: 2023-04-11 15:30:49 1. procedure Test_Wu is 2. 3. package P is 4. X : Integer; | >>> warning: variable "X" is never read and never assigned [-gnatwu] 5. end; 6. 7. Y : Integer; 8. 9. begin 10. P.X := 5; 11. Y := P.X; 12. end; 12 lines: No errors, 1 warning
[Bug tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 --- Comment #19 from simon at pushface dot org --- (In reply to avieira from comment #15) > Simon, I can't compile your minimal reproducer, first it complains about > missing the body keyword, so I added that, but then it complains about > missing a ifcvt_demo.ads, tried adding an empty one but that didn't work. Sorry about that, next time I’ll post a zip archive so there’s no mistaking the expected file name/type (it should have been .ads).
[Bug tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 --- Comment #13 from simon at pushface dot org --- Not sure that it’ll make any difference, but I managed to slim the reproducer down to a pure set of data declarations, no user code at all. It’s the very last declaration (TIMx_CCMRx_Lower_Half) that triggers the problem. I think it’s initialization code.
[Bug tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 --- Comment #12 from simon at pushface dot org --- Not sure that it’ll make any difference, but I managed to slim the reproducer down to a pure set of data declarations, no user code at all. It’s the very last declaration (TIMx_CCMRx_Lower_Half) that triggers the problem. I think it’s initialization code.
[Bug tree-optimization/109005] [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 --- Comment #11 from simon at pushface dot org --- Created attachment 54597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54597=edit Minimal reproducer
[Bug ada/109005] [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 --- Comment #4 from simon at pushface dot org --- (In reply to Richard Biener from comment #3) > Eh, I'm hoping for a C testcase ... what's the actual ICE? This is an LLDB session -- hope that helps $ lldb /opt/gcc-13-20230226/libexec/gcc/x86_64-apple-darwin15/13.0.1/gnat1 (lldb) target create "/opt/gcc-13-20230226/libexec/gcc/x86_64-apple-darwin15/13.0.1/gnat1" Current executable set to '/opt/gcc-13-20230226/libexec/gcc/x86_64-apple-darwin15/13.0.1/gnat1' (x86_64). (lldb) run -quiet -O2 -dumpbase stm32-timers.adb -dumpbase-ext .adb -gnatez -gnatea -gnatez -mmacosx-version-min=12.0.0 -mtune=core2 -fPIC stm32-timers.adb -o /var/folders/_q/fvnxz46903z9hjh38fz0lyhmgs/T//cc4fhSaX.s Process 55466 launched: '/opt/gcc-13-20230226/libexec/gcc/x86_64-apple-darwin15/13.0.1/gnat1' (x86_64) during GIMPLE pass: ifcvt Process 55466 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x7ff80dd106b2 libsystem_platform.dylib`_platform_strlen + 18 libsystem_platform.dylib`: -> 0x7ff80dd106b2 <+18>: pcmpeqb (%rdi), %xmm0 0x7ff80dd106b6 <+22>: pmovmskb %xmm0, %esi 0x7ff80dd106ba <+26>: andq $0xf, %rcx 0x7ff80dd106be <+30>: orq$-0x1, %rax Target 0: (gnat1) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x7ff80dd106b2 libsystem_platform.dylib`_platform_strlen + 18 frame #1: 0x000102a43f24 gnat1`libiberty_vprintf_buffer_size + 779 frame #2: 0x000102a483f1 gnat1`xvasprintf + 35 frame #3: 0x000102a48082 gnat1`xasprintf + 159 frame #4: 0x00010003e629 gnat1`internal_error_function(diagnostic_context*, char const*, __va_list_tag (*) [1]) + 415 frame #5: 0x00010296caf1 gnat1`diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) + 635 frame #6: 0x00010296d2c1 gnat1`diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t) + 272 frame #7: 0x00010296ed3f gnat1`internal_error(char const*, ...) + 239 frame #8: 0x00010296f099 gnat1`fancy_abort(char const*, int, char const*) + 293 frame #9: 0x0001024a1dae gnat1`make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int) + 141 frame #10: 0x0001024b2955 gnat1`make_temp_ssa_name(tree_node*, gimple*, char const*) + 109 frame #11: 0x00010221a144 gnat1`ifc_temp_var(tree_node*, tree_node*, gimple_stmt_iterator*) + 44 frame #12: 0x0001022238ea gnat1`lower_bitfield(gassign*, bool) + 415 frame #13: 0x000102224670 gnat1`tree_if_conversion(loop*, vec*) + 1337 frame #14: 0x000102224b47 gnat1`(anonymous namespace)::pass_if_conversion::execute(function*) + 275 frame #15: 0x000101f7aac8 gnat1`execute_one_pass(opt_pass*) + 800 frame #16: 0x000101f7af07 gnat1`execute_pass_list_1(opt_pass*) + 92 frame #17: 0x000101f7af38 gnat1`execute_pass_list_1(opt_pass*) + 141 frame #18: 0x000101f7af38 gnat1`execute_pass_list_1(opt_pass*) + 141 frame #19: 0x000101f7af9e gnat1`execute_pass_list(function*, opt_pass*) + 74 frame #20: 0x0001017c53c0 gnat1`cgraph_node::expand() + 590 frame #21: 0x0001017c5c61 gnat1`expand_all_functions() + 778 frame #22: 0x0001017c6b0c gnat1`symbol_table::compile() + 962 frame #23: 0x0001017c700e gnat1`symbol_table::finalize_compilation_unit() + 318 frame #24: 0x00010214fcf1 gnat1`compile_file() + 233 frame #25: 0x0001021535d0 gnat1`do_compile(bool) + 802 frame #26: 0x000102153b0f gnat1`toplev::main(int, char**) + 721 frame #27: 0x00010293ad78 gnat1`main + 59 frame #28: 0x00010536052e dyld`start + 462 (lldb) q
[Bug ada/109005] [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 simon at pushface dot org changed: What|Removed |Added Target||x86_64-apple-darwin Known to work||12.2.0 --- Comment #2 from simon at pushface dot org --- [So sorry not to have commented here before posting! The list of suggested PRs covered the screen] This occurs at -O2, not at -O1 or -O0. $ gnatmake -c -u -f stm32-timers.adb -O2 -v GNATMAKE 13.0.1 20230226 (experimental) Copyright (C) 1992-2023, Free Software Foundation, Inc. gcc -c -O2 stm32-timers.adb during GIMPLE pass: ifcvt raised CONSTRAINT_ERROR : erroneous memory access End of compilation gnatmake: "stm32-timers.adb" compilation error I first found this exact problem when using an x86_64 x arm-eabi cross compiler.
[Bug ada/109005] [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 --- Comment #1 from simon at pushface dot org --- Created attachment 54576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54576=edit Reproducer
[Bug ada/109005] New: [13 Regression] ICE during GIMPLE pass: ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005 Bug ID: 109005 Summary: [13 Regression] ICE during GIMPLE pass: ifcvt Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: ---
[Bug ada/108801] New: ICE, task’s secondary_stack_size from parent discriminant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108801 Bug ID: 108801 Summary: ICE, task’s secondary_stack_size from parent discriminant Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 54464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54464=edit Reproducer An instance of a task type is declared in a record with a discriminant Secondary_Storage_Size. The task’s Secondary_Storage_Size is specified using the record’s corresponding discriminant, like so: package Demo is type Event_Queue_Base (Secondary_Stack_Size : Natural) is tagged limited private; private task type Dispatcher (The_Queue: access Event_Queue_Base'Class; Secondary_Stack_Size : Natural) with Secondary_Stack_Size => Secondary_Stack_Size; type Event_Queue_Base (Secondary_Stack_Size : Natural) is tagged limited record The_Dispatcher : Dispatcher (Event_Queue_Base'Access, Secondary_Stack_Size => Secondary_Stack_Size); end record; end Demo; All is fine in a normal compilation, but under the Ravenscar profile (or, indeed, just pragma Restrictions (No_Implicit_Heap_Allocations)) this happens: $ gnatmake -c -u -f demo.ads gcc -c demo.ads +===GNAT BUG DETECTED==+ | 12.2.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access | | Error detected at demo.ads:14:9 | | Compiling demo.ads | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). demo.ads compilation abandoned gnatmake: "demo.ads" compilation error This also happens with 10.1, 11.2, but not with 9.1.
[Bug ada/108157] New: [12/13 regression] object subtype doesn't statically match designated subtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108157 Bug ID: 108157 Summary: [12/13 regression] object subtype doesn't statically match designated subtype Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 54118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54118=edit Demonstrator The attached code fails with $ /opt/gcc-12.2.0/bin/gcc -c g-socser.adb g-socser.adb:13:22: error: object subtype must statically match designated subtype The relevant part of g-socser.adb: 9. Connect_Socket 10. (Socket => Client.Socket, 11. Server => Client.Client_Address, 12. Timeout => 0.0, 13. Selector => Listener.Selector'Unchecked_Access, | >>> error: object subtype must statically match designated subtype The relevant part of g-socser.ads: 20.type Connections_Server is tagged limited record 21. -- limited because Selector_Type is limited 22. Selector : aliased Selector_Type; 23.end record; The relevant part of the GNAT standard library GNAT.Sockets is procedure Connect_Socket (Socket : Socket_Type; Server : Sock_Addr_Type; Timeout : Selector_Duration; Selector : access Selector_Type := null; Status : out Selector_Status); and it’s the same Selector_Type all the way. I’ve looked at Annotated Ada Reference Manual (Ada 2022 Draft 34) 4.9.1[1] and I can’t see what the problem is. Note, I don’t know why the code uses 'Unchecked_Access; 'Access gives the same error, 'Unrestricted_Access compiles OK. [1] http://www.ada-auth.org/standards/22aarm/html/AA-4-9-1.html
[Bug ada/68849] Bug box when using a type with static predicate as formal parameter of generic procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68849 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #2 from simon at pushface dot org --- Not triggered with 12.2.0 (or 7.1.0, or 13-20221120)
[Bug target/107860] Compilation failure, ambiguous fisttp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860 --- Comment #6 from simon at pushface dot org --- The situation with aarch64-apple-darwin vs x86_64-apple-darwin isn't I think quite like the standard cross-compilation scenario, because of Apple's Rosetta x86_64 emulation and the fact that all the low-level tools (as, ld, ...) support both architectures. If I take an x86_64-apple-darwin compiler and run it on aarch64-apple-darwin it will generate x86_64 assembler and invoke as, ld with the right switches to create x86_84 binaries and executables; the executables will run on aarch64 under Rosetta or on x86_64 natively. So I'm not sure what --build, --host should have been set to (given I don't want a cross-compiler; the cross- facilities are provided by macOS under the hood). In what I was trying to do, the host machine was aarch64-apple-darwin22, but notably aarch64 running Rosetta. The boot compiler was x86_64-apple-darwin21. Anyway, the issue here was the way that configure invoked the assembler; /usr/bin/as will assume it's targeting aarch64 (aka arm64) unless told different. These are the results of compiling the test case: $ cat conftest-filds-fists.s // $gcc_cv_as $gcc_cv_as_flags -o conftest.o conftest.s filds (%ebp) fists (%ebp) with /usr/bin/as -c -b conftest-filds-fists.s -o conftest-filds-fists.o (a) on x86_64 Apple clang version 14.0.0 (clang-1400.0.29.201) Target: x86_64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple x86_64-apple-macosx12.0.0 -filetype obj -main-file-name conftest-filds-fists.s -target-cpu penryn -fdebug-compilation-dir=/Users/simon/tmp -dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.201)" -dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm -disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o conftest-filds-fists.s (b) on aarch64 $ /usr/bin/as -c -v conftest-filds-fists.s -o conftest-filds-fists.o Apple clang version 14.0.0 (clang-1400.0.29.202) Target: arm64-apple-darwin22.1.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple arm64-apple-macosx13.0.0 -filetype obj -main-file-name conftest-filds-fists.s -target-cpu apple-m1 -target-feature +v8.5a -target-feature +fp-armv8 -target-feature +neon -target-feature +crc -target-feature +crypto -target-feature +dotprod -target-feature +fp16fml -target-feature +ras -target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-feature +sm4 -target-feature +sha3 -target-feature +sha2 -target-feature +aes -fdebug-compilation-dir=/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc -dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.202)" -dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm -disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o conftest-filds-fists.s conftest-filds-fists.s:2:16: error: unknown token in expression filds (%ebp) ^ conftest-filds-fists.s:2:15: error: invalid operand filds (%ebp) ^ conftest-filds-fists.s:3:16: error: unknown token in expression fists (%ebp) ^ conftest-filds-fists.s:3:15: error: invalid operand fists (%ebp) ^ (c) on aarch64, with -arch x86_64 $ /usr/bin/as -c -v conftest-filds-fists.s -o conftest-filds-fists.o -arch x86_64 Apple clang version 14.0.0 (clang-1400.0.29.202) Target: x86_64-apple-darwin22.1.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple x86_64-apple-macosx13.0.0 -filetype obj -main-file-name conftest-filds-fists.s -target-cpu penryn -fdebug-compilation-dir=/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc -dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.202)" -dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm -disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o conftest-filds-fists.s I think the solution to this PR might be to set it as INVALID or WONTFIX? up to you.
[Bug target/107860] Compilation failure, ambiguous fisttp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860 --- Comment #3 from simon at pushface dot org --- Created attachment 53961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53961=edit gcc/config.log As requested (this time, sorry about previous attempt)
[Bug target/107860] Compilation failure, ambiguous fisttp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860 --- Comment #2 from simon at pushface dot org --- Created attachment 53960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53960=edit gcc/config.log As requested
[Bug bootstrap/107860] New: Compilation failure, ambiguous fisttp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Bug ID: 107860
Summary: Compilation failure, ambiguous fisttp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: simon at pushface dot org
Target Milestone: ---
Building the snapshot gcc-13-20221120 on macOS 13 (actually an aarch64 machine,
but using x86_64-apple-darwin21 compiler under Rosetta) with Command Line Tools
14.1.
Source patched as commit ac50541 for PR107781.
Phase 1 (actually configured with --disable-bootstrap) fails with this (I was
building with -j7, so had to extract the relevant parts of the log:
checking __sync extensions...
/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc/./gcc/xgcc
-B/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc/./gcc/
-B/opt/gcc-13-20221120/x86_64-apple-darwin21/bin/
-B/opt/gcc-13-20221120/x86_64-apple-darwin21/lib/ -isystem
/opt/gcc-13-20221120/x86_64-apple-darwin21/include -isystem
/opt/gcc-13-20221120/x86_64-apple-darwin21/sys-include
--sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -c -g -O2
-fno-common -W -Wall -gnatpg -nostdinc -fno-toplevel-reorder \
g-debpoo.adb -o g-debpoo.o
...
/var/folders/ch/k_zwspdx3qsfbt1_x21zld6mgn/T//ccJJp5X6.s:11992:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
fisttp -408(%rbp)
^
/var/folders/ch/k_zwspdx3qsfbt1_x21zld6mgn/T//ccJJp5X6.s:12278:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
fisttp -408(%rbp)
^
...
make[6]: *** [g-debpoo.o] Error 1
Configure script (BUILD set to x86_64-apple-darwin21):
+++
XCODE=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
CLU=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
$GCC_SRC/configure \
--prefix=$PREFIX \
--without-libiconv-prefix \
--disable-libmudflap \
--disable-libstdcxx-pch \
--disable-libsanitizer\
--disable-libcc1 \
--disable-libcilkrts \
--disable-multilib\
--disable-nls \
--enable-languages=c,c++,ada \
--host=$BUILD \
--target=$BUILD \
--build=$BUILD\
--without-isl \
--with-build-sysroot="$(xcrun --show-sdk-path)" \
--with-sysroot= \
--with-specs="%{!sysroot=*:--sysroot=%:if-exists-else($XCODE $CLU)}" \
--with-build-config=no\
--disable-bootstrap \
CFLAGS=-Wno-deprecated-declarations \
CXXFLAGS=-Wno-deprecated-declarations
+++
[Bug bootstrap/107568] New: Bootstrap failure on macOS 12.6 (monterey)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 Bug ID: 107568 Summary: Bootstrap failure on macOS 12.6 (monterey) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- GCC 13-20221030. With Command Line Tools 14.1.0.0.1.1663981106, the following failures seen in stage 2. Bootstrap compiler: 12.2.0. /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/lex.cc: In function 'unsigned char* cpp_output_line_to_string(cpp_reader*, const unsigned char*)': /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/lex.cc:4624:15: error: 'int sprintf(char*, const char*, ...)' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror=deprecated-declarations] 4624 | sprintf ((char *) result, "#%s ", dir_name); | ^~~ In file included from /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/system.h:38, from /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/lex.cc:23: /Volumes/Miscellaneous1/x86_64/gcc-13-20221030/prev-gcc/include-fixed/stdio.h:204:10: note: declared here 204 | int sprintf(char * __restrict, const char * __restrict, ...) __printflike(2, 3); | ^~~ ... /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/charset.cc: In function 'const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)': /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/charset.cc:2207:18: error: 'int sprintf(char*, const char*, ...)' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror=deprecated-declarations] 2207 | sprintf(buf, "%03o", (int) c); | ~~~^~ In file included from /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/system.h:38, from /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/charset.cc:21: /Volumes/Miscellaneous1/x86_64/gcc-13-20221030/prev-gcc/include-fixed/stdio.h:204:10: note: declared here 204 | int sprintf(char * __restrict, const char * __restrict, ...) __printflike(2, 3); | ^~~ ... /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/macro.cc: In function 'const uchar* _cpp_builtin_macro_text(cpp_reader*, cpp_hashnode*, location_t)': /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/macro.cc:639:23: error: 'int sprintf(char*, const char*, ...)' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror=deprecated-declarations] 639 | sprintf ((char *) pfile->date, "\"%s %2d %4d\"", | ^~~~ 640 |monthnames[tb->tm_mon], tb->tm_mday, | 641 |tb->tm_year + 1900); |~~~ In file included from /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/system.h:38, from /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/macro.cc:26: /Volumes/Miscellaneous1/x86_64/gcc-13-20221030/prev-gcc/include-fixed/stdio.h:204:10: note: declared here 204 | int sprintf(char * __restrict, const char * __restrict, ...) __printflike(2, 3); | ^~~ /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/macro.cc:645:23: error: 'int sprintf(char*, const char*, ...)' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror=deprecated-declarations] 645 | sprintf ((char *) pfile->time, "\"%02d:%02d:%02d\"", | ^~~~ 646 |tb->tm_hour, tb->tm_min, tb->tm_sec); | /Volumes/Miscellaneous1/x86_64/gcc-13-20221030/prev-gcc/include-fixed/stdio.h:204:10: note: declared here 204 | int sprintf(char * __restrict, const char * __restrict, ...) __printflike(2, 3); | ^~~ /Volumes/Miscellaneous1/src/gcc-13-20221030/libcpp/macro.cc:686:15: error: 'int sprintf(char*, const char*, ...)' is deprecated: This function is provided for compatibility reasons only. Due to security concerns
[Bug ada/107536] [12/13 regression] Wrong 'not referenced' warning on renamed variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107536 --- Comment #1 from simon at pushface dot org --- Also present in GCC 13-20221030.
[Bug ada/107536] New: [12 regression] Wrong 'not referenced' warning on renamed variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107536 Bug ID: 107536 Summary: [12 regression] Wrong 'not referenced' warning on renamed variable Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 53834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53834=edit Demonstrator If a record has aspect Volatile_Full_Access, a renaming of one of the record’s components will be reported as unreferenced even though it plainly is. $ gnatmake -gnatwa -c -u -f renaming.adb -gnatl gcc -c -gnatwa -gnatl renaming.adb GNAT 12.2.0 Copyright 1992-2022, Free Software Foundation, Inc. Compiling: renaming.adb Source file time stamp: 2022-11-05 16:48:11 Compiled at: 2022-11-05 16:50:40 1. procedure Renaming is 2. 3.type T is record 4. Item : Integer; 5.end record; 6.A_T : T; 7.Item : Integer renames A_T.Item; 8. 9.type VFA_T is record 10. Item : Integer; 11.end record 12.with Volatile_Full_Access; 13.A_VFA_T : VFA_T; 14.VFA_Item : Integer renames A_VFA_T.Item; | >>> warning: renamed variable "VFA_Item" is not referenced [-gnatwu] 15. 16. begin 17.Item := 42; 18.VFA_Item := 42; 19. end Renaming; 19 lines: No errors, 1 warning This is also present on 12.1.0.
[Bug target/106961] Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 --- Comment #6 from simon at pushface dot org --- Installing the Command Line Tools 14.1 beta 3 fixes this problem.
[Bug target/106961] Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 --- Comment #5 from simon at pushface dot org --- I used the feedback app to submit FB11552589; as a first-timer I’m unsure whether I’ve done it right.
[Bug target/106961] Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 --- Comment #3 from simon at pushface dot org --- Problem still present in Xcode 4.1beta.
[Bug target/106961] Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 --- Comment #2 from simon at pushface dot org --- For the moment, installing Command Line Tools version 13(.4) fixes this problem (people using Xcode need to revert that). I guess the long-term solution will depend on whether the missing libunwind component is deliberate or an oversight on Apple’s part.
[Bug target/106961] New: Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 Bug ID: 106961 Summary: Testsuite failures after Command Line Tools update to v14 Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- On re-running 'make check-acats', I got 37 fails (can’t remember what the count was before the change that triggered this, think it was zero) of which 19 included this text, sometimes once, sometimes multiple times: libunwind: _Unwind_GetTextRelBase - _Unwind_GetTextRelBase() not implemented This appears to have been caused by Apple’s release of the Command Line Tools version 14. I get very similar results on aarch64-apple-darwin21. On that architecture, the log for 'make check-g++` contains the text listed above.
[Bug ada/105303] New: Assertion_Policy (Pre => Ignore) executes precondition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105303 Bug ID: 105303 Summary: Assertion_Policy (Pre => Ignore) executes precondition Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- System.Generic_Array_Operations starts with -- Preconditions in this unit are meant for analysis only, not for run-time -- checking, so that the expected exceptions are raised. This is enforced -- by setting the corresponding assertion policy to Ignore. Postconditions -- and contract cases should not be executed at runtime as well, in order -- not to slow down the execution of these functions. pragma Assertion_Policy (Pre=> Ignore, Post => Ignore, Contract_Cases => Ignore, Ghost => Ignore); and yet, given this clearly wrong code (compiled with -gnata) with System.Generic_Array_Operations; procedure Transposition is type Matrix is array (Integer range <>, Integer range <>) of Float; procedure Transpose is new System.Generic_Array_Operations.Transpose (Scalar => Float, Matrix => Matrix); Input : Matrix (1 .. 3, 1 .. 4); Output : Matrix (1 .. 3, 1 .. 2); begin Transpose (Input, Output); end Transposition; Ada.Assertions.Assertion_Error is in fact raised, contrary to ARM2012 11.4.2(10): $ ./transposition raised ADA.ASSERTIONS.ASSERTION_ERROR : failed precondition from s-gearop.ads:569 instantiated at transposition.adb:4 The comment noted above is confusing, if not wrong: "Preconditions ... not meant for runtime checking, so that the expected exceptions are raised" -- the checks should not be performed, and the exceptions should not be raised.
[Bug ada/61027] gnatcmd gets SIGABRT during exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027 --- Comment #7 from simon at pushface dot org --- I think we should close this: no such problem with GCC 11.2.0 on Darwin 21.4.0.
[Bug ada/89583] GNAT.Sockets.Bind_Socket fails with IPv4 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89583 --- Comment #4 from simon at pushface dot org --- I just ran "make check-gnat" with /Volumes/Miscellaneous1/x86_64/gcc/gcc/gnatmake version 12.0.1 20220311 (experimental) (x86_64-apple-darwin21), with only two fails: FAIL: gnat.dg/bias1.adb scan-assembler DW_AT_GNU_bias FAIL: gnat.dg/debug18.adb scan-assembler-not DW_AT_lower_bound so I think we can close this.
[Bug ada/63675] Non-confirming aspect doesn’t fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63675 --- Comment #2 from simon at pushface dot org --- Not sure when this was fixed, but OK in 11.2.0: $ /opt/gcc-11.2.0/bin/gnatmake -c -u -f union.ads gcc -c union.ads union.ads:15:06: warning: discriminated record has no direct equivalent in C union.ads:15:06: warning: use of convention for type "Derived_1" is dubious union.ads:15:06: warning: discriminated record has no direct equivalent in C union.ads:15:06: warning: use of convention for type "Derived_2" is dubious union.ads:15:06: warning: discriminated record has no direct equivalent in C union.ads:15:06: warning: use of convention for type "Derived_3" is dubious union.ads:24:55: derived type "Derived_2" inherits aspect "Unchecked_Union", cannot cancel union.ads:29:36: representation item not permitted before Ada 202x union.ads:29:36: parent type "Base" has primitive operations gnatmake: "union.ads" compilation error $ /opt/gcc-11.2.0/bin/gnatmake -c -u -f union.ads -gnat2020 gcc -c -gnat2020 union.ads union.ads:15:06: warning: discriminated record has no direct equivalent in C union.ads:15:06: warning: use of convention for type "Derived_1" is dubious union.ads:15:06: warning: discriminated record has no direct equivalent in C union.ads:15:06: warning: use of convention for type "Derived_2" is dubious union.ads:24:55: derived type "Derived_2" inherits aspect "Unchecked_Union", cannot cancel gnatmake: "union.ads" compilation error
[Bug ada/80869] Ada.Directories is missing Name_Case_Equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869 --- Comment #1 from simon at pushface dot org --- This was fixed 4 years ago.
[Bug c/104871] New: macosx-version-min wrong for macOS >= Big Sur (darwin20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104871
Bug ID: 104871
Summary: macosx-version-min wrong for macOS >= Big Sur
(darwin20)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: simon at pushface dot org
Target Milestone: ---
Created attachment 52603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52603=edit
Patch, discards minor version
This is the same sort of problem as in PR80204: at present, GCC 11 &
12 assume that if the OS version is >= 20, the compiler should see
--mmacosx-version-min={major - 9}.{minor -1}.0, e.g. for OS version
21.3.0 that would be 12.2.0 (the linker sees -macosx-version-min, same
arguments).
However, the native compiler clang treats 21.3.0 as 12.0.0: the
compiler sees
-triple x86_64-apple-macosx12.0.0
and the linker sees
-platform_version macos 12.0.0
the result of which is that linking a main object file built with clang
and one built with gcc results in
ld: warning: object file (null.o) was built for newer macOS version (12.2)
than being linked (12.0)
I propose the following patch, which works fine for me (darwin 21.3.0).
diff --git a/gcc/config/darwin-driver.cc b/gcc/config/darwin-driver.cc
index 30e0e64f280..ca2a1ca1a60 100644
--- a/gcc/config/darwin-driver.cc
+++ b/gcc/config/darwin-driver.cc
@@ -164,15 +164,9 @@ darwin_find_version_from_kernel (void)
version - 1 (at least for the initial releases). */
if (major_vers >= 20)
{
- int minor_vers = *version_p++ - '0';
- if (ISDIGIT (*version_p))
- minor_vers = minor_vers * 10 + (*version_p++ - '0');
- if (*version_p++ != '.')
- goto parse_failed;
- if (minor_vers > 0)
- minor_vers -= 1; /* Kernel 20.3 => macOS 11.2. */
- /* It's not yet clear whether patch level will be considered. */
- asprintf (_flag, "%d.%02d.00", major_vers - 9, minor_vers);
+ /* clang doesn't include the minor version in the object file,
+ nor does it pass it to ld */
+ asprintf (_flag, "%d.00.00", major_vers - 9);
}
else if (major_vers - 4 <= 4)
/* On 10.4 and earlier, the old linker is used which does not
[Bug ada/104751] New: Array aggregates using parens aren’t obsolescent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104751 Bug ID: 104751 Summary: Array aggregates using parens aren’t obsolescent Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Compiling procedure New_Syntax is T : array (1 .. 5) of Integer; begin T := (1, 2, 3, 4, 5); end New_Syntax; with -gnat2022 -gnatwj gives new_syntax.adb:4:09: warning: array aggregate using () is an obsolescent syntax, use [] instead [-gnatwj] but use of parens is not in Annex J; use of brackets is an option, AARM 202x Draft 32, 4.3.3(49.m). Having -gnatwj as part of -gnatwa makes this very intrusive.
[Bug ada/94181] Misidentified dangling reference in container implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94181 --- Comment #1 from simon at pushface dot org --- Fixed in 10.1.0 (also OK in 11.2.0, 12.0.1)
[Bug ada/99360] [12 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 --- Comment #9 from simon at pushface dot org --- In gcc 12.0.1 of 20220128, we get $ gnatmake -c -u -f iteration.adb gcc -c iteration.adb a-stream.ads:82:04: error: construct not allowed in configurable run-time mode a-stream.ads:82:04: error: file s-putima.ads had semantic errors a-stream.ads:82:04: error: entity "System.Put_Images.Put_Image_Unknown" not available s-putima.ads:63:53: error: "Long_Long_Long_Unsigned" not declared in "Unsigned_Types" gnatmake: "iteration.adb" compilation error which means we no longer get the ICE. Instead, the compiler complains validly that the old RTS files provided don’t provide the interfaces that the compiler now needs. Similarly for GCC 11.2. So, I think this PR should be closed as fixed.
[Bug ada/104354] ICE with Partition_Elaboration_Policy (Sequential)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104354 --- Comment #1 from simon at pushface dot org --- Created attachment 52334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52334=edit GCC 12-compatible RTS
[Bug ada/104354] New: ICE with Partition_Elaboration_Policy (Sequential)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104354 Bug ID: 104354 Summary: ICE with Partition_Elaboration_Policy (Sequential) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 52333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52333=edit Demonstrator (needs RTS) The attached ravenscar-sfp-stm32f4.zip contains a version of the Alire gnat_arm_elf_11.2.1_9343d45f runtime, edited to build with GCC 12.0.1. The attached sem_ch8.zip contains demo.ad[bs] and enough RTS code from Cortex GNAT RTS at https://github.com/simonjwright/cortex-gnat-rts to allow compiling demo.adb, which uses Ada.Containers.Bounded_Vectors, to demonstrate the problem. The command $ gprbuild -c -u -f demo.adb --target=arm-eabi --RTS=/Users/simon/tmp/ravenscar-sfp-stm32f4 (note, the --RTS= switch will have to be changed) results in +===GNAT BUG DETECTED==+ | 12.0.1 20220128 (experimental) (arm-eabi) Program_Error sem_ch8.adb:5773 explicit raise| | Error detected at demo.adb:21:14 | | Compiling /Users/simon/tmp/bugs/gcc12/sem_ch8/arm-eabi//demo.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ This error does not occur if the line pragma Partition_Elaboration_Policy (Sequential); is removed from demo.ads (the compilation fails because of other missing components).
[Bug ada/104342] New: ICE with -gnata -fcallgraph-info=su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104342 Bug ID: 104342 Summary: ICE with -gnata -fcallgraph-info=su Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 52327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52327=edit Requested source files I originally found this error compiling for STM32F4, using both ravenscar-sfp-stm32f4 and my cortex-gnat-rts equivalent. However, it also shows up in a native compilation. Neither option on its own caused a problem. Compiling from the attached source with gnatmake stm32-spi-dma.adb -c -u -f -gnata -fcallgraph-info=su gives gcc -c -gnata -fcallgraph-info=su stm32-spi-dma.adb targetname: "+===GNAT BUG DETECTED==+ | 12.0.1 20220128 (experimental) (x86_64-apple-darwin15) Assert_Failure exp_cg.adb:484| | No source file position information available| | Compiling stm32-spi-dma.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). stm32-spi-dma.adb stm32-spi-dma.ads stm32-spi.ads stm32.ads hal.ads stm32_svd.ads stm32_svd-spi.ads hal-spi.ads stm32-dma.ads stm32_svd-dma.ads stm32-dma-interrupts.ads
[Bug ada/104258] New: [11/12 regression] Generic formal ">" used incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104258 Bug ID: 104258 Summary: [11/12 regression] Generic formal ">" used incorrectly Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Host: x86_64-apple-darwin15 Target: x86_64-apple-darwin15 Build: x86_64-apple-darwin15 Created attachment 52301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52301=edit Reproducer I have a generic with a formal private type Element_Type and a formal function ">" (L, R : Element_Type) return Boolean. This gives me puzzling and compiler-dependent behaviour when I instantiate with Element_Type => Integer and ">" => "<" (or, as in the code below, ">" => Less_Than, where Less_Than outputs a message if it's called). The output from the code attached is GCC 10.1.0: Data'Length: 2 Data'Length > 1: TRUE Integer'(Data'Length) > 1: TRUE Standard.">" (Data'Length, 1): TRUE Standard.">" (Integer'(Data'Length), 1): TRUE GCC 11.2.0, 12.0.0 of 2022-01-11: Data'Length: 2 Data'Length > 1: **less_than ( 2, 1) returns FALSE** FALSE Integer'(Data'Length) > 1: TRUE Standard.">" (Data'Length, 1): **less_than ( 2, 1) returns FALSE** FALSE Standard.">" (Integer'(Data'Length), 1): TRUE
[Bug ada/70867] [9/10/11/12 regression] access discriminant in return aggregate wrongly detected as dangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70867 simon at pushface dot org changed: What|Removed |Added CC||simon at pushface dot org --- Comment #14 from simon at pushface dot org --- (In reply to Nicolas Boulenguez from comment #0) > Hello. > With GCC-6 (Debian 6.0.1-2) 6.0.1 20160423 (prerelease), > compiling the following package with "gcc-6 -c p.adb" fails: > p.adb:4:20: access discriminant in return aggregate would be a dangling > reference > The code compiles > - if the "generic" line is removed > - or if ".all" is inserted between "Position" and ".Item'Access" > I am not sure whether returning this reference is allowed by the Ada > Reference Manual, > but the semantics of "generic" and ".all" should certainly not affect the > answer. GCC 11.1.0, x86_64-apple-darwin on macOS 11.6 (Big Sur): This compiles without error, and the example below executes correctly. with P; with Ada.Text_IO; procedure P_Test is package Q is new P; R : aliased Q.R := (Item => 42); T : Q.T := Q.F (R'Access); begin Ada.Text_IO.Put_Line (T.D.all'Image); end P_Test;
[Bug ada/86916] Constraint_Error erroneous memory access instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86916 --- Comment #10 from simon at pushface dot org --- This was fixed in 10.1.0, and is still fixed in 11.1.0: $ /opt/gcc-10.1.0/bin/gnatmake -c -u -f -gnatl *.adb gcc -c -gnatl animation.adb [...] ==Error messages for source file: morph.ads 22. API_Morph_Value'(others => <>)); | >>> expected type "API_Morph_Value" defined at line 13 >>> found a composite type 30. API_Morph_Weight'(others => <>)); | >>> expected type "API_Morph_Weight" defined at line 14 >>> found a composite type 288 lines: 4 errors gnatmake: "animation.adb" compilation error
[Bug ada/99802] New: [11 regression] Assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 Bug ID: 99802 Summary: [11 regression] Assignment of aggregate done component-by-component Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 50481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50481=edit Demonstrator, with output assembler In arm-eabi-gcc version 11.0.1 20210303 (experimental) (GCC), assigning an aggregate to a memory-mapped register is performed by assigning the components of the aggregate one-by-one to the register rather than as a whole word. The same bug is present in the x86_64-apple-darwin compiler. In compiler releases up to & including 10, this was done using a whole-word assignment. with ATSAM3X8E; use ATSAM3X8E; with ATSAM3X8E.PMC; use ATSAM3X8E.PMC; procedure Clock is begin PMC_Periph.CKGR_MOR := (KEY => 16#37#, MOSCXTEN => 1, -- main crystal oscillator enable MOSCRCEN => 1, -- main on-chip rc osc. enable MOSCXTST => 8, -- startup time others => <>); end Clock; The register is a component of a record: type PMC_Peripheral is record ... CKGR_MOR : aliased CKGR_MOR_Register; pragma Volatile_Full_Access (CKGR_MOR); ... end record with Volatile; with object as so: PMC_Periph : aliased PMC_Peripheral with Import, Address => PMC_Base; and the write respects the Volatile_Full_Access *as it writes each component separately to the register*! This fails, in this case, because the PMC hardware requires each write to this register to be accompanied by a valid value of the KEY field. The attached aggregate_assignment.zip contains Ada source, and the 10.1.0 and 11.0.1 versions of the arm-eabi cortex-m3 assembler output by -S. I've tried compiling the source in aggregate_assignment.zip with the x86_64-apple-darwin compiler, and the same bug seems to be present. NOTE, this bug is also present in GNAT CE 2020.
[Bug ada/99360] [11 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 --- Comment #3 from simon at pushface dot org --- (In reply to Eric Botcazou from comment #2) > Created attachment 50297 [details] > Stopgap fix > > To be applied on the 11 branch only. Worked a treat! on both x86_64 (for the code in the reproducer, which of course then went on to fail because of partial RTS) and for the original arm-eabi problem, which then executed its test code perfectly. I thought that maybe this would only work for predefined Containers, which isn’t true (it’s the Iterators); though I guess that home-grown containers might trigger the problem? Hopefully they’re rare in the wild.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 --- Comment #5 from simon at pushface dot org --- (In reply to Eric Botcazou from comment #4) > This should compile now. It does, indeed. Thanks!
[Bug ada/99360] New: ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
Bug ID: 99360
Summary: ICE in generalized iteration
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: simon at pushface dot org
Target Milestone: ---
Created attachment 50292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50292=edit
Reproducer
This is a regression from GCC 10.
It arises when compiling a generalized iteration (in the case of the
bug box below, 'for Cursor in V.Iterate loop', also for existential &
universal quantifiers) against an independently-developed arm-eabi
RTS[1]. It does *not* happen against f.e. ravenscar-full-stm32f4.
This is the result of compiling with the native compiler against the
set of files reported by the arm-eabi compiler (attached):
$ gnatmake -c -u -f iteration.adb
gcc -c iteration.adb
+===GNAT BUG DETECTED==+
| 11.0.0 20210205 (experimental) (x86_64-apple-darwin15) Program_Error
sem_ch8.adb:5490 explicit raise|
| Error detected at iteration.adb:13:8 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ . |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
system.ads
iteration.adb
ada.ads
a-contai.ads
a-cobove.ads
a-iteint.ads
a-stream.ads
a-tags.ads
s-stoele.ads
s-secsta.ads
s-parame.ads
s-taskin.ads
s-freert.ads
interfac.ads
s-fretas.ads
s-stratt.ads
s-unstyp.ads
What investigation I've been able to do suggests that it's possibly
related to tasking and/or finalization being brought in when not
needed (it used not to be with GCC 10).
Emmanuel B. (ex-AdaCore) said in [2]:
Might be unrelated, but: we have noticed recently that a
generalized iteration ("for..of") was wrongly calling
`activate_task`. In particular, this resulted in errors when
executing such loops from a protected object and enabling the
checks that no potentially blocking operation is executed in such
contexts.
We reported this to AdaCore who fixed it in their more recent
wavefronts. I am not sure when the error started to occur though,
so maybe not that helpful to you :-)
[1] https://github.com/simonjwright/cortex-gnat-rts
[2] https://groups.google.com/g/comp.lang.ada/c/c5qncqgkgYk/m/Cp-mty5wAgAJ
[Bug ada/99020] New: ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Bug ID: 99020 Summary: ICE in record containing discriminated accesses Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 50148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50148=edit Files as requested in bug box This appears to be caused by the components of a discriminated record being themselves constrained by the containing record’s discriminants: type Instance (Panel : not null Annunciator_Panel.Class_P; Attendant : not null Analytical_Engine.Attendant.Instance_P) is new Ada.Finalization.Limited_Controlled with record Mill : Analytical_Engine.Mill.Instance_P <<< line 61 (Panel => Panel, Attendant => Attendant); $ gnatmake -c -u -f analytical_engine-framework.ads gcc -c analytical_engine-framework.ads +===GNAT BUG DETECTED==+ | 11.0.0 20210205 (experimental) (x86_64-apple-darwin15) Assert_Failure einfo.adb:4122| | Error detected at analytical_engine-framework.ads:61:9 | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). analytical_engine-framework.ads analytical_engine.ads analytical_engine-annunciator_panel.ads analytical_engine-output.ads analytical_engine-attendant.ads analytical_engine-mill.ads analytical_engine-store.ads analytical_engine-card_reader.ads analytical_engine-card.ads
