[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #22 from Eric Botcazou --- Thanks for reporting the problem.
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #5 from Eric Botcazou ---
static void
sparc_asm_function_epilogue (FILE *file)
{
/* If the last two instructions of a function are "call foo; dslot;"
the return address might point to the first instruction in the next
function and we have to output a dummy nop for the sake of sane
backtraces in such cases. This is pointless for sibling calls since
the return address is explicitly adjusted. */
[Bug middle-end/99151] Missed optimization: Superfluous stack frame and code with noreturn or __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151 --- Comment #7 from Eric Botcazou --- > This nop behaviour could be a bit inconsistent across architectures. For > example, arm and powerpc don't generate a nop here. Well, it's low-level trickery so architecture-dependent by definition. > I still think that the profiling counter increment in the > __builtin_unreachable() path is a bug. How so? I only see a missed optimization, but with -fprofile-arcs -ftest-coverage you're splitting hairs IMO.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-01 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | --- Comment #2 from Eric Botcazou --- Fixing.
[Bug ada/99020] ICE in record containing discriminated accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Eric Botcazou --- This should compile now.
[Bug ada/99095] [10/11 regression] couple of issues with unconstrained array of limited record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |10.3 Last reconfirmed||2021-03-02 Status|UNCONFIRMED |NEW Summary|Unconstrained array of |[10/11 regression] couple |limited records results in |of issues with |a bounds bug. |unconstrained array of ||limited record CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug ada/99095] [10/11 regression] couple of issues with unconstrained array of limited record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org CC|ebotcazou at gcc dot gnu.org | Status|NEW |ASSIGNED --- Comment #2 from Eric Botcazou --- Fixing.
[Bug ada/99095] [10/11 regression] issue with function returning unconstrained array of limited record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Thanks for reporting the problem.
[Bug ada/99358] Ada2020 assignment target name as return value triggers bug box
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99358 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2021-03-03 Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code --- Comment #1 from Eric Botcazou --- Probably a loophole in the parser.
[Bug ada/99360] [11 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |11.0 CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2021-03-04 Status|UNCONFIRMED |NEW Summary|ICE in generalized |[11 regression] ICE in |iteration |generalized iteration Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug ada/99360] [11 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 --- Comment #2 from Eric Botcazou --- Created attachment 50297 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50297&action=edit Stopgap fix To be applied on the 11 branch only.
[Bug ada/99360] [11 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug rtl-optimization/99376] Sanitizer detects undefined behaviour in rtlanal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376 Eric Botcazou changed: What|Removed |Added Summary|Sanitizer detects undefined |Sanitizer detects undefined |behaviour in rtlanal.c |behaviour in rtlanal.c |compiling ada | --- Comment #1 from Eric Botcazou --- Nothing specific to Ada, it's (mult:DI (reg:DI 87 [ _9 ]) (reg:DI 87 [ _9 ])) with (reg:DI 87) equal to LONG_MIN so low0 = low1 = 63. Clearly a pair of tests against HOST_BITS_PER_WIDE_INT is missing in: if (result_width < mode_width) nonzero &= (HOST_WIDE_INT_1U << result_width) - 1; if (result_low > 0) nonzero &= ~((HOST_WIDE_INT_1U << result_low) - 1);
[Bug rtl-optimization/99376] Sanitizer detects undefined behaviour in rtlanal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug rtl-optimization/99376] sanitizer detects undefined behaviour in rtlanal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376 --- Comment #2 from Eric Botcazou --- > Clearly a pair of tests against HOST_BITS_PER_WIDE_INT is missing in: > > if (result_width < mode_width) > nonzero &= (HOST_WIDE_INT_1U << result_width) - 1; > > if (result_low > 0) > nonzero &= ~((HOST_WIDE_INT_1U << result_low) - 1); Actually only for result_low, as mode_width <= HOST_BITS_PER_WIDE_INT.
[Bug rtl-optimization/70094] missed optimization when passing a constant struct argument by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug ada/99360] [11 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 --- Comment #4 from Eric Botcazou --- > 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. OK, thanks for trying it. > 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. Yes, certainly not a generic solution, but good enough in the meantime.
[Bug c++/99401] GCC11 MinGW-w64 32-bit build fails with undefined reference to `LC0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2021-03-05 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- This looks like an issue with the base compiler, could you post the output of 'gcc -v'? Could you also avoid forcing -O2 during stage #1, i.e. use the default -O0 or only -O1?
[Bug target/99401] GCC11 MinGW-w64 32-bit build fails with undefined reference to `LC0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401 --- Comment #3 from Eric Botcazou --- > gcc -v No, what's needed is the output for the *base* compiler, i.e. the compiler you start from, not the compiler you're building.
[Bug rtl-optimization/99376] sanitizer detects undefined behaviour in rtlanal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 --- Comment #4 from Eric Botcazou --- .
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 99376, which changed state. Bug 99376 Summary: sanitizer detects undefined behaviour in rtlanal.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ada/99264] latest glibc release breaks Ada build on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99264 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|11.0|9.4 --- Comment #10 from Eric Botcazou --- Fixed on mainline, 10 and 9 branches.
[Bug target/99401] Rebuilding the compiler with itself fails at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW Summary|GCC11 MinGW-w64 32-bit |Rebuilding the compiler |build fails with undefined |with itself fails at -O2 |reference to `LC0' | Keywords|build | --- Comment #4 from Eric Botcazou --- OK, I missed that you're explicitly rebuilding the compiler with itself after having bootstrapped it first... You're on your own here, no one does that.
[Bug c++/90448] [8/9/10/11 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org CC||ebotcazou at gcc dot gnu.org --- Comment #12 from Eric Botcazou --- Likewise on SPARC 32-bit, so let's find a way out.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
Target|powerpc64*-linux-gnu, |powerpc64*-linux-gnu,
|sparc*-sun-solaris2.11 |sparc*-*-*
CC||ebotcazou at gcc dot gnu.org
--- Comment #30 from Eric Botcazou ---
AFAICS the code implicitly assumes that __float128 exists, which is *not* the
common case among 64-bit architectures since "long double" is generally
128-bit.
Tentative fix for the SPARC at least:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 5c9258c65c3..ae359a07973 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -407,7 +407,10 @@ build_round_expr (tree arg, tree restype)
if (kind < 0)
gfc_internal_error ("Could not find real kind with at least %d bits",
resprec);
- arg = fold_convert (gfc_float128_type_node, arg);
+ if (gfc_real16_is_float128)
+ arg = fold_convert (gfc_float128_type_node, arg);
+ else
+ arg = fold_convert (long_double_type_node, arg);
fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind);
}
else
[Bug other/99486] Feature request: -fstack-check option for embedded processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99486 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2021-03-09 --- Comment #1 from Eric Botcazou --- > The -fstack-limit option of gcc is of no use in systems using RTOS because the > stack limit is different for each task. I don't think that's true, because you can either set a per-thread value in the limit register or a per-thread value for the appropriate symbol; the latter was done with VxWorks 6 for example, although it might not work with VxWorks 7. > I propose an additional option for implementing -fstack-check that does not > require memory paging hardware. This option would have the compiler call a > stack-check function near the start of the code generated for each function. > A single parameter would be passed to that function, which would be the > lowest (if the stack grows downwards) stack address used in the remainder of > the function. Similarly, when allocating objects of dynamic size on the > stack, the stack check function would be called. Contributions are always welcome!
[Bug c++/90448] [8/9/10/11 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|8.5 |10.3 Resolution|--- |FIXED --- Comment #15 from Eric Botcazou --- .
[Bug bootstrap/94918] [8/9/10/11 regression] Ada bootstrap errors on Cygwin64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #13 from Eric Botcazou --- Hopefully fixed everywhere.
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #19 from Eric Botcazou ---
> a-ztflau.adb: In function 'Ada.Float_Wide_Wide_Text_Io.Aux_Float.Puts':
> a-ztflau.adb:132:8: error: insn does not satisfy its constraints:
> (insn 174 39 180 2 (set (mem/c:DF (plus:SI (reg/f:SI 30 %fp)
> (const_int -5216 [0xeba0])) [37 %sfp+-5216 S8
> A64])
> (reg:DF 40 %f8 [203])) "a-ztflau.adb":117:7 153 {*movdf_insn_sp32}
> (nil))
The offset is out of the allowed range [-4096, 4095] so something is broken.
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #24 from Eric Botcazou ---
> Technically, you have ;-) There's gcc211 in the cfarm, but
> unfortunately the installation is highly nonstandard, doesn't follow
> cfarm conventions, and lacks GNAT. While I do have a local gcc
> installation on the box without these issues, I agree it would be quite
> tedious to use. I suspect that the same issue occurs on Linux/sparc64,
> too (gcc202), but trying that on a machine that's pretty unreliable
> wouldn't be my idea of fun.
This can be reproduced with a minimal Ada cross-compiler, i.e. you just need
the gnat1 compiler, the skeleton of libada and the command line:
$(srcdir)/configure --target=sparc-sun-solaris2.11
--enable-languages=c,c++,ada
make CFLAGS=-g CXXFLAGS=-g ADAFLAGS="-gnatpga -gnatws"
cd gcc/ada; make gnatlib
cd rts; ../../gnat1 -quiet a-lfztio.ads -gnatpg
a-ztflau.adb: In function 'Ada.Long_Float_Wide_Wide_Text_Io.Aux_Float.Put':
a-ztflau.adb:101:8: error: insn does not satisfy its constraints:
(insn 32 31 88 2 (set (mem/c:DF (plus:SI (reg/f:SI 30 %fp)
(const_int -5232 [0xeb90])) [29 %sfp+-5232 S8 A64])
(reg:DF 40 %f8 [orig:109 _1 ] [109])) "a-ztflau.adb":99:7 153
{*movdf_insn_sp32}
(nil))
during RTL pass: reload
+===GNAT BUG DETECTED==+
| 11.0.1 20210310 (experimental) [master revision
1c3c12b0a6f:f62bd375583:47403a0eefac52636db768dc46c3c88a2cd4b28e]
(sparc-sun-solaris2.11) GCC error:|
| in extract_constrain_insn, at recog.c:2670 |
| Error detected around a-ztflau.adb:101:8
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #27 from Eric Botcazou --- > Before the patches function process_address_1 used CONSTRAINT__UNKNOWN > (taken from '=' of constraint "=T,..." and this is wrong) to check validity > address. It was invalid and LRA added reloads for the address. Is that because T is a special_memory_constraint or did it happen with a regular memory_constraint as well? > After the patches, the function uses CONTSTRAINT_T (taken from 'T'). For > constraint T sparc code says that the memory address is ok and LRA keeps the > address and does not generate reloads. So LRA does not check that the memory is valid for special_memory_constraint or memory_constraint, and the constraint must do it on its own? Then it's probably inherited from reload and I guess that if (! can_create_pseudo_p () && !strict_memory_address_p (Pmode, XEXP (op, 0))) return 0; was supposed to do it, in which case David and I missed it when we converted the port to LRA. This would point to: diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c index f1504172022..d8860f908e9 100644 --- a/gcc/config/sparc/sparc.c +++ b/gcc/config/sparc/sparc.c @@ -9227,7 +9227,7 @@ memory_ok_for_ldd (rtx op) if (TARGET_ARCH32 && !mem_min_alignment (op, 8)) return 0; - if (! can_create_pseudo_p () + if ((lra_in_progress || reload_in_progress) && !strict_memory_address_p (Pmode, XEXP (op, 0))) return 0; Thanks for the investigation, I'll take over from there.
[Bug testsuite/99607] [11 regression] new test case gcc.dg/pr98099.c in r11-5706 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99607 Eric Botcazou changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Eric Botcazou --- Please avoid opening a new PR for the testcase of another PR, this wastes space, time and resources. *** This bug has been marked as a duplicate of bug 98099 ***
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #6 from Eric Botcazou --- *** Bug 99607 has been marked as a duplicate of this bug. ***
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- The bug is fixed though and no warning is expected on big-endian targets so it's just a matter of tweaking or disabling the testcase for them.
[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from Eric Botcazou --- > While building the ada compiler the address sanitizer detecst an > heap-buffer-overflow in namet.adb line 157: > > Index : constant Int := Name_Entries.Table (Id).Name_Chars_Index; > > because Id=-3 The table is declared like this though: package Name_Entries is new Table.Table ( Table_Component_Type => Name_Entry, Table_Index_Type => Valid_Name_Id'Base, Table_Low_Bound => First_Name_Id, Table_Initial=> Alloc.Names_Initial, Table_Increment => Alloc.Names_Increment, Table_Name => "Name_Entries"); with: First_Name_Id : constant Name_Id := Names_Low_Bound + 2; -- Subscript of first entry in names table subtype Valid_Name_Id is Name_Id range First_Name_Id .. Name_Id'Last; -- All but No_Name and Error_Name and: Names_Low_Bound : constant := -3; so Id = -3 is well within the allowed range (9997 0-based index). Are you sure that Id is not equal to Names_Low_Bound, which would be the -2 0-based index and, therefore, -32 bytes since the size of Name_Entry is 16? On the other hand, this would mean that: pragma Assert (Is_Valid_Name (Id)); would have triggered because the compiler is supposed to be configured with assertions enabled on the mainline, so I'm quite at a loss here. It looks like the address sanitizer is miscompiling the Ada compiler?
[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624 Eric Botcazou changed: What|Removed |Added Status|WAITING |SUSPENDED --- Comment #3 from Eric Botcazou --- > Yes, probably gcc -fsanitize=address is miscompiling the Ada compiler. > I had to take out the -gnata option to disable pragma assert that was > failing. OK, thanks for the confirmation. > So I do not know if this is a genuine compiler bug or it is due to > miscompilation. Most probably -fsanitize=address does not work correctly on Ada code. > The Ada compiler compiled with the undefined behavior sanitizer > compiles and works fine with a successful run of the testsuite. Interesting data point, thanks.
[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624 --- Comment #5 from Eric Botcazou --- > I am very very rusty on Ada, what should I do to check that Id is good? Probably put back the original assert on line 155.
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
--- Comment #10 from Eric Botcazou ---
> 2021-03-17 Jakub Jelinek
>
> PR middle-end/98099
> * gcc.dg/pr98099.c: Don't compile the test on pdp endian.
> For big endian use -fsso-struct=little-endian dg-options.
>
> --- gcc/testsuite/gcc.dg/pr98099.c.jj 2020-12-04 10:53:56.306043973 +0100
> +++ gcc/testsuite/gcc.dg/pr98099.c2021-03-17 20:05:07.714417723 +0100
> @@ -1,8 +1,9 @@
> /* PR middle-end/98099 */
> /* Reported by G. Steinmetz */
>
> -/* { dg-do compile { target dfp } } */
> -/* { dg-options "-fsso-struct=big-endian" } */
> +/* { dg-do compile { target { dfp && { be || le } } } } */
> +/* { dg-options "-fsso-struct=big-endian" { target le } } */
> +/* { dg-options "-fsso-struct=little-endian" { target be } } */
>
> struct S { _Decimal128 a; };
Yes, even better, thanks.
[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624 --- Comment #7 from Eric Botcazou --- > If I compile the build with -gnata, thereby arming the pragma assert, > the build fails. Then this proves that the sanitizer does not work since the assertion does not trigger in a regular build, so there is no need to dig deeper. > Did you try building Ada with address sanitation? No, I don't think so.
[Bug ada/99641] [11 Regression] opt30.adb, opt49.adb and loop_optimization3.adb fail to build at m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641 --- Comment #1 from Eric Botcazou --- I can reproduce, it's the expansion of __builtin_memcmp.
[Bug middle-end/99641] [11 Regression] opt30.adb, opt49.adb and loop_optimization3.adb fail to build at m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641
Eric Botcazou changed:
What|Removed |Added
Component|ada |middle-end
Target Milestone|--- |11.0
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #2 from Eric Botcazou ---
The offset calculation in native_encode_initializer is incorrect:
if (index && TREE_CODE (index) == RANGE_EXPR)
{
if (!tree_fits_shwi_p (TREE_OPERAND (index, 0))
|| !tree_fits_shwi_p (TREE_OPERAND (index, 1)))
return 0;
pos = (tree_to_shwi (TREE_OPERAND (index, 0)) - min_index)
* fieldsize;
count = (tree_to_shwi (TREE_OPERAND (index, 1))
- tree_to_shwi (TREE_OPERAND (index, 0)));
}
else if (index)
{
if (!tree_fits_shwi_p (index))
return 0;
pos = (tree_to_shwi (index) - min_index) * fieldsize;
}
It must not be done in HOST_WIDE_INT but in sizetype instead, like in e.g.
get_inner_reference or get_ref_base_and_extent.
[Bug middle-end/99641] [11 Regression] opt30.adb, opt49.adb and loop_optimization3.adb fail to build at m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Thanks for reporting the problem.
[Bug target/99719] ICE during RTL pass: pro_and_epilogue on MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2021-03-26 CC||ebotcazou at gcc dot gnu.org --- Comment #6 from Eric Botcazou --- > However, it looks like swapping to ms_abi from sysv_abi will cleanup SIMD > registers. Is that correct? Fiddling with the ABI is highly discouraged in anything else than very low-level code, so templatized C++ very likely does not qualify.
[Bug ada/99802] [11 regression] Assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-29 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed, this was working by chance before.
[Bug ada/99802] [11 regression] assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 Eric Botcazou changed: What|Removed |Added Summary|[11 regression] Assignment |[11 regression] assignment |of aggregate done |of aggregate done |component-by-component |component-by-component Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Eric Botcazou --- Fixing.
[Bug ada/99802] [11 regression] assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- Thanks for reporting the problem.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Eric Botcazou changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #8 from Eric Botcazou --- Richard, did you mean to CC me for another PR by any chance?
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #9 from Eric Botcazou --- > Richard, did you mean to CC me for another PR by any chance? Never mind, I was confused by your commit.
[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 Eric Botcazou changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED CC||ebotcazou at gcc dot gnu.org --- Comment #9 from Eric Botcazou --- This breaks the build with older compilers: ../../src/gcc/cp/pt.c: In function 'tree_node* instantiate_class_template_1(tree)': ../../src/gcc/cp/pt.c:12137:17: error: range-based 'for' loops are not allowed in C++98 mode
[Bug rtl-optimization/98973] [11 regression] Wrong code with gcse store motion pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #11 from Eric Botcazou --- I don't seem to be able to reproduce with a cross. Can you post the configure line for the compiler?
[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 --- Comment #13 from Eric Botcazou --- Yes, thanks for the quick turnaround.
[Bug ada/99360] [12 regression] ICE in generalized iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org Summary|[11/12 regression] ICE in |[12 regression] ICE in |generalized iteration |generalized iteration --- Comment #6 from Eric Botcazou --- To be properly fixed on the mainline.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2020-10-22 Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #3 from Eric Botcazou --- This occurs on Aarch64 and SPARC as well.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #12 from Eric Botcazou --- > It still fails for me with g:2118438f49f0c193abe3fa3def350a8129045746 > Commit Date: Mon Oct 26 19:05:53 2020 +0100 The PowerPC64 issue is different, let me have a quick look at it.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #13 from Eric Botcazou --- This builds for me on powerpc64-linux, so I gather it's on powerpc64le-linux?
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #16 from Eric Botcazou --- > It's actually a partial cross compiler (-m32), please take a look at the > build log. What's this beast exactly? I'm afraid the build log is useless here, it would be better to post the configure line and the CC or CXX variables if any.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #23 from Eric Botcazou --- > It's a build log from OpenSUSE OBS, so it contains all that you requested. AFAICS this log is for a native compiler: [ 131s] checking build system type... powerpc64-suse-linux-gnu [ 131s] checking host system type... powerpc64-suse-linux-gnu [ 131s] checking target system type... powerpc64-suse-linux-gnu but I gather that --with-cpu=default32 somehow forces it to default to 32-bit, making it really powerpc-suse-linux-gnu under the hood? Again this Debian-like abomination if you ask me, which probably fools the logic in Makefile.rtl.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #26 from Eric Botcazou --- Created attachment 49471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49471&action=edit Tentative fix for the SuSE PowerPC compiler Martin, can you give it a try when you get a chance?
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Eric Botcazou changed: What|Removed |Added Attachment #49471|0 |1 is obsolete|| --- Comment #27 from Eric Botcazou --- Created attachment 49472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49472&action=edit Slightly better tentative fix
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Eric Botcazou changed: What|Removed |Added Attachment #49472|0 |1 is obsolete|| --- Comment #30 from Eric Botcazou --- Created attachment 49510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49510&action=edit Tentative fix #2 With the missing ampersand.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #31 from Eric Botcazou --- > Unfortunately, it still fails. OK, can you try the new one?
[Bug ada/97557] [11 regression] several ada test case failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97557 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Eric Botcazou --- Try to delete your previous installation in the install tree.
[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711 --- Comment #5 from Eric Botcazou --- > as the comments says the check isn't correct but it might work for simple > non-LTO cases. Anybody willing to try? But isn't LTO towards being the default these days? If so, what's the point of punishing every function for something that doesn't really work with LTO? Cannot we clear the nothrow flag on the functions selectively instead?
[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711 --- Comment #7 from Eric Botcazou --- > The issue with clearing nothrow is that those pesky builtins have > that "sticky" while the per-stmt flag (gimple_call_nothrow ()) > just amends it. Guess we might want to fix that (in gimple_call_flags) > and then clear the flag always for -fnon-call-exceptions? > > I suppose all/most noexcept specifications in libstdc++ are similarly > questionable. Let's not use too big a hammer though, -fnon-call-exceptions works fine for languages (Ada, Go) that enable it by default and I'm quite wary of C++ folks who try it once in a while, want to pessimize it because it doesn't work on their questionable testcase, and then forget about it. Why not just extend what's done in build_common_builtin_nodes for __builtin_alloca to the family of __builtin_mem* functions?
[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-13 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |11.0 --- Comment #1 from Eric Botcazou --- Obviously.
[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 --- Comment #2 from Eric Botcazou --- Created attachment 49555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49555&action=edit Tentative fix Please give it a try when you get a chance.
[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 --- Comment #5 from Eric Botcazou --- > We need: > > #include We cannot do that unconditionally because it's also compiled as a C file.
[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 Eric Botcazou changed: What|Removed |Added Attachment #49555|0 |1 is obsolete|| --- Comment #6 from Eric Botcazou --- Created attachment 49574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49574&action=edit Tentative fix #2 Second try.
[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97859 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-11-17 CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- It should be defined there though: eric@fomalhaut:~/build/gcc/native/gcc/ada/rts> nm s-vai.o D system__val_llli_E T system__val_llli__impl__scan_integer 00f0 T system__val_llli__impl__value_integer U system__val_lllu__impl__scan_raw_unsigned U system__val_util__bad_value U system__val_util__scan_sign U system__val_util__scan_trailing_blanks In any case, the output of 'gcc -v' would be helpful as always.
[Bug ada/97859] [11 Regression] bootstrap error building a gnat cross compiler targeting ppc64le on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97859 --- Comment #6 from Eric Botcazou --- > target_cpu is powerpc64le > > Makefile.rtl: > > ifeq ($(strip $(filter-out powerpc64,$(target_cpu))),) > ifneq ($(strip $(MULTISUBDIR)),/ppc) > LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS) > EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS) > else > SO_OPTS += -m32 > endif > else > ifeq ($(strip $(MULTISUBDIR)),/ppc64) > SO_OPTS += -m64 > LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS) > EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS) > endif > endif > endif It's the MacOS section though. Can you replace "powerpc64" with "powerpc64%" in the Linux section? ifeq ($(strip $(filter-out powerpc64,$(target_cpu))),) ifneq ($(strip $(MULTISUBDIR)),/32) LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS) EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS) endif else ifeq ($(strip $(MULTISUBDIR)),/64) LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_PAIRS) EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS) endif endif
[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 --- Comment #8 from Eric Botcazou --- > Fix #2 works for me. OK, thanks. > Probably, should be new PR. Nope, it's PR ada/97504, please follow up there.
[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Eric Botcazou --- Thanks for reporting the problem.
[Bug other/97911] [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Last reconfirmed||2020-11-19 --- Comment #4 from Eric Botcazou --- See also https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559580.html
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- > I don't get any error on the following constants: 2048, 4095, 4097, 8192. > 4096 seems special! Welcome to the RISC world and its magic integer constants! :-)
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Investigating.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 --- Comment #8 from Eric Botcazou --- Sorry for dropping the ball, I'll get back to it momentarily.
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #6 from Eric Botcazou ---
> Not sure how useful this is but all of the following toss the same ICE :
>
> long f(long arg){return arg + 4096;}
>
> long f(long arg){return arg - 4096;}
>
> long f(long arg){return 4096 + arg;}
>
> long f(long arg){return arg - 4096;}
>
> However these work fine :
>
> long f(long arg){return 4096 - arg;}
>
> long f(long arg){return arg * 4096;}
>
> long f(long arg){return 4096 * arg;}
>
> long f(long arg){return arg / 4096;}
>
> etc etc etc as well as other powers of 2.
It's specific to 4096 and additive operations. A look at the assembly
generated for the first 4 without -fsanitize=undefined may give a hunch about
what happens.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #36 from Eric Botcazou --- > The s390x build failure is still preset. Can you please take a look? This one looks unrelated to r11-4029 or other Ada changes. Do you know which revision has introduced it?
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |9.4 --- Comment #12 from Eric Botcazou --- Fixed on mainline, 10 and 9 branches.
[Bug target/97939] ICE on sparc64 with UBsan for "i + 4096" on long: unrecognizable insn during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |9.4 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Eric Botcazou --- Thanks for reporting the problem.
[Bug rtl-optimization/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082 --- Comment #1 from Eric Botcazou --- What's the point of using -fipa-icf at -O0 exactly? P1 for this...
[Bug rtl-optimization/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082 --- Comment #3 from Eric Botcazou --- > It's an option fuzzing. OK, but let's please do that in a smarter way and avoid nonsense like this.
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-03 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed. Does this come from real code or is it an artificial test?
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- We cannot support it on 32-bit platforms in any case.
[Bug ipa/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Eric Botcazou --- OK, it's the return by invisible reference business, where a PARM_DECL and a RESULT_DECL are tied. There is already a comment in use_register_for_decl: /* Otherwise, if RESULT_DECL is DECL_BY_REFERENCE, it will take the function_result_decl's assignment. Since it's a pointer, we can short-circuit a number of the tests below, and we must duplicate them because we don't have the function_result_decl to test. */ so I'm testing the duplication of the one I added in r11-3257.
[Bug middle-end/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Eric Botcazou --- .
[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- .
[Bug ada/98127] [11 regression] libada lacks objects needed for 128-bit types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98127 Eric Botcazou changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 97504 ***
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Eric Botcazou changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #39 from Eric Botcazou --- *** Bug 98127 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/96344] 3rdd case of gnat.dg/opt86a.adb fails because of VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344 --- Comment #5 from Eric Botcazou --- > A fresh build of trunk on x86_64 shows the following Ada failures: > > ! FAIL: gnat.dg/opt86a.adb (1: +1) > ! FAIL: gnat.dg/opt86b.adb (1: +1) > ! FAIL: gnat.dg/opt86c.adb (1: +1) > > The logs show this: > > $ grep "FAIL: gnat.dg/opt86" gcc/testsuite/gnat/gnat.log > FAIL: gnat.dg/opt86a.adb scan-tree-dump-times optimized ">>" 4 > FAIL: gnat.dg/opt86b.adb scan-tree-dump-not optimized "> 29" > FAIL: gnat.dg/opt86c.adb scan-tree-dump-not optimized "> 26" Introduced on 12/01, probably by: 2020-12-01 Martin Liska PR tree-optimization/14799 PR ipa/88702 * Makefile.in: Add gimple-if-to-switch.o. * dbgcnt.def (DEBUG_COUNTER): Add new debug counter. * passes.def: Include new pass_if_to_switch pass. * timevar.def (TV_TREE_IF_TO_SWITCH): New timevar. * tree-pass.h (make_pass_if_to_switch): New. * tree-ssa-reassoc.c (struct operand_entry): Move to the header. (dump_range_entry): Move to header file. (debug_range_entry): Likewise. (no_side_effect_bb): Make it global. * tree-switch-conversion.h (simple_cluster::simple_cluster): Add inline for couple of functions in order to prevent error about multiple defined symbols. * gimple-if-to-switch.cc: New file. * tree-ssa-reassoc.h: New file.
[Bug ada/98134] [11 Regression] bootstrap error building gnat on mips64el-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98134 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 97504 ***
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 Eric Botcazou changed: What|Removed |Added CC||doko at debian dot org --- Comment #40 from Eric Botcazou --- *** Bug 98134 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/96344] 3rdd case of gnat.dg/opt86a.adb fails because of VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|NEW |RESOLVED --- Comment #7 from Eric Botcazou --- Fixed everywhere.
[Bug target/96470] [10/11 regression] gnat.dg/opt39.adb is not scalarized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96470 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Eric Botcazou --- Fixed everywhere.
[Bug tree-optimization/98199] [11 Regression] ICE: Aborted (stack smashing detected)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98199
--- Comment #3 from Eric Botcazou ---
> struct b {
> long a;
> short d;
> int c;
> int f;
> int e;
> int g;
> };
> struct h {
> int a;
> int i;
> short j;
> struct b k;
> signed : 20;
> int e;
> int g;
> } __attribute__((packed));
> struct {
> short a;
> unsigned i;
> unsigned k;
> struct h d;
> const int : 30;
> signed e : 20;
> signed : 18;
> } const l = {1, 6, 0, {}, 0};
> int m() { return l.e || 0; }
>
> since r11-5706-g277ff3406d533990e98cf1c2075b9dc9db6fa48a.
Something went wrong on your side here, this cannot possibly be true.
[Bug target/90458] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 --- Comment #4 from Eric Botcazou --- > In general on x86 the compiler handles stack allocation (and probing when > stack clash protection is enabled). However, on Windows targets that stuff > is actually handled by calls to __chkstk_ms. > > One could easily argue that stack-clash-protection should be a NOP or > generate an error in a Windows environment. Right, Windows has been doing stack clash protection since day #1, like for example Tru64, so the option should just be a NOP on Windows.
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 --- Comment #20 from Eric Botcazou --- > So I'm going to look at this again. Some random thoughts on the Ada bools > though. It would be nice if the Ada FE could leave boolean_type_node > untouched so that when the middle-end produces a compare to feed a branch > it does not end up using the 8-bit precision bool (because there's no out-of > range values to be considered for a compare result). Basically keep the > Ada boolean "data type" separate from the middle-end boolean "logical type". IIRC I tried that but this was pessimizing because of spurious conversions.
[Bug ada/98230] Bug in Type'Modulus during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-10 Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Rather curious indeed.
[Bug ada/98230] Bug in Type'Modulus during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Investigating.
