[Bug target/111829] New: Redudant register moves inside the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111829
Bug ID: 111829
Summary: Redudant register moves inside the loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
#include
int
foo (__m128i* __restrict pa, int* b,
__m128i* __restrict pc, int n)
{
__m128i vsum = _mm_setzero_si128();
for (int i = 0; i != 10; i++)
{
vsum = _mm_dpbusd_epi32 (vsum, pa[i], _mm_set1_epi32 (b[i]));
}
*pc = vsum;
int ssum = 0;
for (int i = 0; i != 4; i++)
ssum += ((__v4si)vsum)[i];
return ssum;
}
gcc -O2 -mavxvnni
foo(long long __vector(2)*, int*, long long __vector(2)*, int):
leaq40(%rsi), %rax
vpxor %xmm0, %xmm0, %xmm0
.L2:
vmovdqa (%rdi), %xmm2
vmovdqa %xmm0, %xmm1 redundant
addq$4, %rsi
addq$16, %rdi
vpbroadcastd-4(%rsi), %xmm3
{vex} vpdpbusd %xmm3, %xmm2, %xmm1
vmovdqa %xmm1, %xmm0 --- redundant
cmpq%rax, %rsi
jne .L2
vmovdqa %xmm1, (%rdx)
leaq-24(%rsp), %rax
leaq-8(%rsp), %rcx
xorl%edx, %edx
.L3:
vmovdqa %xmm0, -24(%rsp)
addq$4, %rax
addl-4(%rax), %edx
cmpq%rax, %rcx
jne .L3
movl%edx, %eax
ret
it can be better with
foo(long long __vector(2)*, int*, long long __vector(2)*, int):
leaq40(%rsi), %rax
vpxor %xmm0, %xmm0, %xmm0
.L2:
vmovdqa (%rdi), %xmm2
addq$4, %rsi
addq$16, %rdi
vpbroadcastd-4(%rsi), %xmm3
{vex} vpdpbusd %xmm3, %xmm2, %xmm0
cmpq%rax, %rsi
jne .L2
vmovdqa %xmm0, (%rdx)
leaq-24(%rsp), %rax
leaq-8(%rsp), %rcx
xorl%edx, %edx
.L3:
vmovdqa %xmm0, -24(%rsp)
addq$4, %rax
addl-4(%rax), %edx
cmpq%rax, %rcx
jne .L3
movl%edx, %eax
ret
[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103324 --- Comment #11 from Eric Gallager --- (In reply to Eric Gallager from comment #10) > (In reply to Richard Biener from comment #2) > > Thus, > > > > make check RUNTESTFLAGS="execute.exp" > > make check RUNTESTFLAGS="dg-torture.exp" > > > Just confirming that the proper way to combine these would be: > make check RUNTESTFLAGS="execute.exp dg-torture.exp" > ...correct? > (The docs said something about being whitespace-delimited, but I wasn't > quite sure if that just applied to the globbing part, or also to the .exp > filenames...) (ok, from testing, it appears that that's correct...)
[Bug tree-optimization/111799] [14 Regression] Missed Dead Code Elimination since r14-2365-g2e406f0753e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799 --- Comment #3 from Andrew Pinski --- Hmm, I think we reach __builtin_unreachable always and that is confusing everything. If we inline s early on (via using the always_inline attribute). main turns into just __builtin_unreachable .
[Bug target/111828] New: rs6000: Parse inline asm string to figure out it requires HTM feature or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828 Bug ID: 111828 Summary: rs6000: Parse inline asm string to figure out it requires HTM feature or not. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: linkw at gcc dot gnu.org CC: jan.wassenberg at gmail dot com, john_platts at hotmail dot com, linkw at gcc dot gnu.org, malat at debian dot org Depends on: 111366 Target Milestone: --- Target: powerpc64le Currently as the discussion in PR111366 we simply make the assumption that all inline asm strings are possible to adopt HTM feature and consider it as possible as conservative so that set HTM flag. Technically speaking we are able to parse the inline asm string and figure out it's HTM related or not. Excepting for the HTM specific instructions like .tbegin etc., we also need to take care of those special registers related to HTM feature. +++ This bug was initially created as a clone of Bug #111366 +++ Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366 [Bug 111366] error: inlining failed in call to 'always_inline' 'hwy::PreventElision(int&)void': target specific option mismatch
[Bug target/111366] error: inlining failed in call to 'always_inline' 'hwy::PreventElision(int&)void': target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #22 from Kewen Lin ---
Should be fixed on trunk and gcc-{12,13}.
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380
Kewen Lin changed:
What|Removed |Added
Keywords||wrong-code
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Kewen Lin ---
Should be fixed on trunk and gcc-{12,13}.
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2021-Novembe |il/gcc-patches/2023-October |r/585088.html |/633090.html --- Comment #20 from Andrew Pinski --- Updated patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633090.html
[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103324 --- Comment #10 from Eric Gallager --- (In reply to Richard Biener from comment #2) > Thus, > > make check RUNTESTFLAGS="execute.exp" > make check RUNTESTFLAGS="dg-torture.exp" Just confirming that the proper way to combine these would be: make check RUNTESTFLAGS="execute.exp dg-torture.exp" ...correct? (The docs said something about being whitespace-delimited, but I wasn't quite sure if that just applied to the globbing part, or also to the .exp filenames...)
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:a570462419f5a6ba2880a82d6394419864bd035b commit r12-9926-ga570462419f5a6ba2880a82d6394419864bd035b Author: Kewen Lin Date: Sun Oct 15 21:08:29 2023 -0500 rs6000: Use default target option node for callee by default [PR111380] As PR111380 (and the discussion in related PRs) shows, for now how function rs6000_can_inline_p treats the callee without any target option node is wrong. It considers it's always safe to inline this kind of callee, but actually its target flags are from the command line options (target_option_default_node), it's possible that the flags of callee don't satisfy the condition of inlining, but it is still inlined, then result in unexpected consequence. As the associated test case pr111380-1.c shows, the caller main is attributed with power8, but the callee foo is compiled with power9 from command line, it's unexpected to make main inline foo since foo can contain something that requires power9 capability. Without this patch, for lto (with -flto) we can get error message (as it forces the callee to have a target option node), but for non-lto, it's inlined unexpectedly. This patch is to make callee adopt target_option_default_node when it doesn't have a target option node, it can avoid wrong inlining decision and fix the inconsistency between LTO and non-LTO. It also aligns with what the other ports do. PR target/111380 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_can_inline_p): Adopt target_option_default_node when the callee has no option attributes, also simplify the existing code accordingly. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr111380-1.c: New test. * gcc.target/powerpc/pr111380-2.c: New test. (cherry picked from commit 266dfed68b881702e9660889f63408054b7fa9c0)
[Bug target/111366] error: inlining failed in call to 'always_inline' 'hwy::PreventElision(int&)void': target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366 --- Comment #21 from CVS Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:2b50ddce27be4738b494f5c4dd7083099b3de68c commit r12-9925-g2b50ddce27be4738b494f5c4dd7083099b3de68c Author: Kewen Lin Date: Sun Oct 15 21:08:26 2023 -0500 rs6000: Skip empty inline asm in rs6000_update_ipa_fn_target_info [PR111366] PR111366 exposes one thing that can be improved in function rs6000_update_ipa_fn_target_info is to skip the given empty inline asm string, since it's impossible to adopt any hardware features (so far HTM). Since this rs6000_update_ipa_fn_target_info related approach exists in GCC12 and later, the affected project highway has updated its target pragma with ",htm", see the link: https://github.com/google/highway/commit/15e63d61eb535f478bc I'd not bother to consider an inline asm parser for now but will file a separated PR for further enhancement. PR target/111366 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_update_ipa_fn_target_info): Skip empty inline asm. gcc/testsuite/ChangeLog: * g++.target/powerpc/pr111366.C: New test. (cherry picked from commit a65b38e361320e0aa45adbc969c704385ab1f45b)
[Bug target/111366] error: inlining failed in call to 'always_inline' 'hwy::PreventElision(int&)void': target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366 --- Comment #20 from CVS Commits --- The releases/gcc-13 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:4d22de945430e6f8c33ef98c90a4fad8de0ef41e commit r13-7953-g4d22de945430e6f8c33ef98c90a4fad8de0ef41e Author: Kewen Lin Date: Sun Oct 15 21:05:40 2023 -0500 rs6000: Skip empty inline asm in rs6000_update_ipa_fn_target_info [PR111366] PR111366 exposes one thing that can be improved in function rs6000_update_ipa_fn_target_info is to skip the given empty inline asm string, since it's impossible to adopt any hardware features (so far HTM). Since this rs6000_update_ipa_fn_target_info related approach exists in GCC12 and later, the affected project highway has updated its target pragma with ",htm", see the link: https://github.com/google/highway/commit/15e63d61eb535f478bc I'd not bother to consider an inline asm parser for now but will file a separated PR for further enhancement. PR target/111366 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_update_ipa_fn_target_info): Skip empty inline asm. gcc/testsuite/ChangeLog: * g++.target/powerpc/pr111366.C: New test. (cherry picked from commit a65b38e361320e0aa45adbc969c704385ab1f45b)
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380 --- Comment #2 from CVS Commits --- The releases/gcc-13 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:cc87aaeceea58389b681e3a6a63f95e54f2b59cd commit r13-7954-gcc87aaeceea58389b681e3a6a63f95e54f2b59cd Author: Kewen Lin Date: Sun Oct 15 21:05:47 2023 -0500 rs6000: Use default target option node for callee by default [PR111380] As PR111380 (and the discussion in related PRs) shows, for now how function rs6000_can_inline_p treats the callee without any target option node is wrong. It considers it's always safe to inline this kind of callee, but actually its target flags are from the command line options (target_option_default_node), it's possible that the flags of callee don't satisfy the condition of inlining, but it is still inlined, then result in unexpected consequence. As the associated test case pr111380-1.c shows, the caller main is attributed with power8, but the callee foo is compiled with power9 from command line, it's unexpected to make main inline foo since foo can contain something that requires power9 capability. Without this patch, for lto (with -flto) we can get error message (as it forces the callee to have a target option node), but for non-lto, it's inlined unexpectedly. This patch is to make callee adopt target_option_default_node when it doesn't have a target option node, it can avoid wrong inlining decision and fix the inconsistency between LTO and non-LTO. It also aligns with what the other ports do. PR target/111380 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_can_inline_p): Adopt target_option_default_node when the callee has no option attributes, also simplify the existing code accordingly. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr111380-1.c: New test. * gcc.target/powerpc/pr111380-2.c: New test. (cherry picked from commit 266dfed68b881702e9660889f63408054b7fa9c0)
[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815 --- Comment #1 from Maciej W. Rozycki --- Created attachment 56120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56120=edit Reduced testcase This triggers the same ICE in `p'. Preincrements are required so that their results land in registers and consequently an indexed addressing mode is tried or otherwise doing operations piecemeal on stack-based function arguments as direct input operands turns out more profitable in terms of RTX costs and the ICE is avoided.
[Bug tree-optimization/111827] `a > b ? ~a : ~b` is sometimes not detected until phiopt4 (or not at all)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111827 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-10-15 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine but for next year ...
[Bug tree-optimization/111827] New: `a > b ? ~a : ~b` is sometimes not detected until phiopt4 (or not at all)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111827
Bug ID: 111827
Summary: `a > b ? ~a : ~b` is sometimes not detected until
phiopt4 (or not at all)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int a, int b, int c)
{
int at = ~a;
int bt = ~b;
int ct = ~c;
int t = a < b ? at : bt;
return t;
}
```
This takes until phiopt4 (after sink) to detect ~MIN_EXPR.
Note if at is used more than once like in PR 67438, it is not detected at all
which is why the main reason `~X op ~Y` patterns have a single_use on them.
[Bug middle-end/67438] [6 Regression] ~X op ~Y pattern relocation causes loop performance degradation on 32bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67438
--- Comment #15 from Andrew Pinski ---
(In reply to Yuri Rumyantsev from comment #11)
> Richard proposed to use the same simplification for min/max operations but
> in original test-case nested min/max operation (min(x,min(y,z)) or multi
> operand min/max (min(x,y,z)) are not recognized by gcc (Note that icc does
> such transformation) and so this won't help since we have the same register
> pressure issue:
> c = ~r;
> m = ~g;
> y = ~b;
> k = min(c, m, y);
> *out++ = c - k;
> *out++ = m - k;
> *out++ = y - k;
> *out++ = k;
This is now recognized since GCC 13 (by r13-1950-g9bb19e143cfe88 and improved
for GCC 14 by r14-337-gc43819a9b4cdaa).
Now there is a missing MIN/MAX detection still:
int f(int a, int b, int c)
{
int at = ~a;
int bt = ~b;
int ct = ~c;
int t = a < b ? at : bt;
return t;
}
Which is not detected until phiopt4. I will file a bug about that.
I think once that is fixed I think we might be able to remove the single_use
again.
[Bug lto/107779] Support implicit references from inline assembler to compiler symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779 --- Comment #4 from Andi Kleen --- This whole manual annotation idea (which is equivalent to marking the symbols global and visible and that is what a large part of the kernel LTO patchkit) is dead on arrival because the kernel people already rejected it. Their argument is that they don't need it for LLVM why should they be forced to it for GCC. In LLVM it is just done by the assembler, and it works without any extra program changes. Since gcc is not the only game in town anymore they have a point. It's either heuristics or integrating the assembler.
[Bug tree-optimization/101541] Missing ABSU detection at gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-October ||/633043.html Keywords||patch --- Comment #8 from Andrew Pinski --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633043.html
[Bug libstdc++/111826] New: __cpp_lib_format should be 202110, not 202106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826 Bug ID: 111826 Summary: __cpp_lib_format should be 202110, not 202106 Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bbi5291 at gmail dot com Target Milestone: --- libstdc++ 13.1 supports std::format including P2372 and P2418, which were adopted in Oct 2021 and bumped the feature test macro to 202110L. But libstdc++ still defines `__cpp_lib_format` as 202106L.
[Bug fortran/98011] [OpenACC] 'gcc/fortran/scanner.c:load_line' should consider 'flag_openacc' in addition to 'flag_openmp' (and vice versa?)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98011 --- Comment #5 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:643a5223f1a1860a88c215d715f079d7f846843c commit r14-4651-g643a5223f1a1860a88c215d715f079d7f846843c Author: Tobias Burnus Date: Sun Oct 15 23:10:17 2023 +0200 libgomp.texi: Update "Enabling OpenMP" + OpenACC / invoke.texi: -fopenacc/-fopenmp update The OpenACC specification does not mention the '!$ ' sentinel for conditional compilation and the feature was removed in r11-5572-g1d6f6ac693a860 for PR fortran/98011; update libgomp.texi for this and update a leftover comment. - Additionally, some other updates are done as well. libgomp/ * libgomp.texi (Enabling OpenMP): Update for C/C++ attributes; improve wording especially for Fortran; mention -fopenmp-simd. (Enabling OpenACC): Minor cleanup; remove conditional compilation sentinel. gcc/ * doc/invoke.texi (-fopenacc, -fopenmp, -fopenmp-simd): Use @samp not @code; document more completely the supported Fortran sentinels. gcc/fortran * scanner.cc (skip_free_comments, skip_fixed_comments): Remove leftover 'OpenACC' from comments about OpenMP's conditional compilation sentinel.
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 --- Comment #19 from Andrew Pinski --- Created attachment 56119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56119=edit testcase from the original attachment For easier access, I posting this here so don't need to untar the file.
[Bug fortran/66969] Internal compiler error, segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66969
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Keywords||accepts-invalid
--- Comment #4 from anlauf at gcc dot gnu.org ---
We might need to tighten the check of restricted expressions:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 663fe63dea6..6996e1e93d1 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -2849,6 +2852,21 @@ check_inquiry (gfc_expr *e, int not_restricted)
&& ap->expr->expr_type == EXPR_VARIABLE
&& asym->attr.dummy && asym->attr.optional)
return MATCH_NO;
+
+ if (not_restricted == 0
+ && ap->expr->expr_type == EXPR_VARIABLE
+ && !(asym->attr.flavor == FL_PARAMETER)
+ && !asym->attr.dummy
+ && !asym->attr.in_common
+ && !asym->attr.use_assoc
+ && !asym->attr.host_assoc
+ && !asym->attr.implied_index
+ && (asym->attr.allocatable
+ || asym->attr.pointer
+ || (asym->as && asym->as->type == AS_DEFERRED)))
+ {
+ return MATCH_ERROR;
+ }
}
return MATCH_YES;
This needs to be refined further.
[Bug other/103331] There should be a rule to make build.log in the top-level Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103331 --- Comment #2 from Eric Gallager --- I'm assuming that the way that build.log is normally generated is by just appending `| tee build.log` to the end of a normal `make` command?
[Bug tree-optimization/101541] Missing ABSU detection at gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541 --- Comment #7 from Andrew Pinski --- Created attachment 56118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56118=edit Patch which I am testing which allows for more (independent of the other) This patch improves the case where we have a conversion at the end (after the negate expression). And with both of these patches together we are able to catch almost all. There is one more phi-opt patch needed to catch the case where the conversion before the negate expression is conditional but that is for another day.
[Bug tree-optimization/104376] Failure to optimize clz equivalent to clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104376 --- Comment #8 from Andrew Pinski --- Created attachment 56117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56117=edit Patch which I am testing to fix the second issue
[Bug tree-optimization/104376] Failure to optimize clz equivalent to clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104376 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Andrew Pinski --- I have a fix for the secondary issue which does not cause PR 71016 to show up again. Basically we should allow nop conversions always in factor_out_conditional_operation .
[Bug tree-optimization/101541] Missing ABSU detection at gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541 --- Comment #6 from Andrew Pinski --- Created attachment 56116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56116=edit Patch which I am testing
[Bug ada/111825] get_immediate echos without wait, no echo with wait: error?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111825 --- Comment #1 from richardthiebaud --- anga 12.2.0 not 11.4.0
[Bug ada/111825] New: get_immediate echos without wait, no echo with wait: error?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111825
Bug ID: 111825
Summary: get_immediate echos without wait, no echo with wait:
error?
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: thiebauddick2 at aol dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
When running ada.text_io.get_immediate with a wait, it does not echo the input
character from the keyboard. When running it without the wait, it does not.
Running the following program and pushing the "x" key gets: AxB on the screen.
with ada.text_io; use ada.text_io;
procedure test3 is
c: character;
avail: boolean;
begin
put("A");
loop
Get_Immediate(c, Avail);
if Avail then
exit;
end if;
delay 0.01;
end loop;
put ("B");
end test3;
However, running the following program and pushing the "X" key gets: AB on the
screen.
with ada.text_io; use ada.text_io;
procedure test4 is
c: character;
begin
put("A");
Get_Immediate(c);
put ("B");
end test4;
Is this expected behavior or an error?
gnat 11.4.0 linux mint 21.3
[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640 --- Comment #4 from Matthias Reis --- I have the same problem unfortunately. Changing '-Os' into '-O2' fixes the problem for me.
[Bug tree-optimization/101541] Missing ABSU detection at gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101541 --- Comment #5 from Andrew Pinski --- Actually using bitwise_equal_p makes this easier and no need for the nop_convert ... I have a patch where I just need to add testcases too.
[Bug libstdc++/111824] [14 Regression] is invalid under -U__STRICT_ANSI__ -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111824 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- We warn about it not being supported too: /<>/gcc-14.0.0/include/c++/14.0.0/x86_64-unknown-linux-gnu/bits/c++config.h:668:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp]
[Bug tree-optimization/111823] ICE on valid code at -O1 and above on x86_64-linux-gnu: in verify_sra_access_forest, at tree-sra.cc:2414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111823 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 111807. *** This bug has been marked as a duplicate of bug 111807 ***
[Bug tree-optimization/111807] [14 Regression] ice in verify_sra_access_forest with -O1 and bitfields in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807 Andrew Pinski changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Comment #5 from Andrew Pinski --- *** Bug 111823 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/111800] [14 Regression] ICE with -fdump-tree-ccp1-details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3bcc10b98e9ffc1296d3d1aae16e85c6bdb09d1a
commit r14-4645-g3bcc10b98e9ffc1296d3d1aae16e85c6bdb09d1a
Author: Jakub Jelinek
Date: Sun Oct 15 14:23:14 2023 +0200
wide-int: Fix estimation of buffer sizes for wide_int printing [PR111800]
As mentioned in the PR, my estimations on needed buffer size for wide_int
and especially widest_int printing were incorrect, I've used get_len ()
in the estimations, but that is true only for !wi::neg_p (x) values.
Under the hood, we have 3 ways to print numbers.
print_decs which if
if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
|| (wi.get_len () == 1))
uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive or
negative) and otherwise uses print_hex,
print_decu which if
if ((wi.get_precision () <= HOST_BITS_PER_WIDE_INT)
|| (wi.get_len () == 1 && !wi::neg_p (wi)))
uses sprintf which always fits into WIDE_INT_PRINT_BUFFER_SIZE (positive
only) and print_hex, which doesn't print most significant limbs which are
zero and the first limb which is non-zero prints such that redundant 0
hex digits aren't printed, while all limbs below that are printed with
"%016" PRIx64. For wi::neg_p (x) values, the first limb of the precision
is always non-zero, so we print all the limbs for the precision.
So, the current estimations are accurate if !wi::neg_p (x), or when
print_decs will be used and x.get_len () == 1, otherwise we need to use
estimation based on get_precision () rather than get_len ().
I've introduced new inlines print_{dec{,s,u},hex}_buf_size which compute
the
needed buffer length in bytes and return true if WIDE_INT_PRINT_BUFFER_SIZE
isn't sufficient and caller should XALLOCAVEC the buffer.
2023-10-15 Jakub Jelinek
PR tree-optimization/111800
gcc/
* wide-int-print.h (print_dec_buf_size, print_decs_buf_size,
print_decu_buf_size, print_hex_buf_size): New inline functions.
* wide-int.cc (assert_deceq): Use print_dec_buf_size.
(assert_hexeq): Use print_hex_buf_size.
* wide-int-print.cc (print_decs): Use print_decs_buf_size.
(print_decu): Use print_decu_buf_size.
(print_hex): Use print_hex_buf_size.
(pp_wide_int_large): Use print_dec_buf_size.
* value-range.cc (irange_bitmask::dump): Use print_hex_buf_size.
* value-range-pretty-print.cc
(vrange_printer::print_irange_bitmasks):
Likewise.
* tree-ssa-loop-niter.cc (do_warn_aggressive_loop_optimizations):
Use
print_dec_buf_size. Use TYPE_SIGN macro in print_dec call
argument.
gcc/c-family/
* c-warn.cc (match_case_to_enum_1): Assert w.get_precision ()
is smaller or equal to WIDE_INT_MAX_INL_PRECISION rather than
w.get_len () is smaller or equal to WIDE_INT_MAX_INL_ELTS.
[Bug libstdc++/111824] New: [14 Regression] is invalid under -U__STRICT_ANSI__ -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111824 Bug ID: 111824 Summary: [14 Regression] is invalid under -U__STRICT_ANSI__ -std=c++11 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- I think it's a regression started from r14-1433-gf150a084e25eaa Noticed on `monotone-1.1` source code where `monotone` uses `#undef __STRICT_ANSI__` for some reason. As a result build fails as: $ printf "#include " | g++ -c -x c++ - -U__STRICT_ANSI__ -std=c++11 -o /dev/null |& head -n 10 In file included from /<>/gcc-14.0.0/include/c++/14.0.0/limits:42, from :1: /<>/gcc-14.0.0/include/c++/14.0.0/x86_64-unknown-linux-gnu/bits/c++config.h:668:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp] 668 | #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" | ^~~ /<>/gcc-14.0.0/include/c++/14.0.0/limits:2100:30: error: exponent has no digits 2100 | return __extension__ 0x1.0p-16382Q; | ^~ /<>/gcc-14.0.0/include/c++/14.0.0/limits:2114:30: error: exponent has no digits 2114 | return __extension__ 0x1.p+16383Q; AFAIU it's caused by the code like #ifdef __STRICT_ANSI__ // 0x1.0p-30 * 0x1.0p-16352 return double(9.3132257461547852e-10) * _S_1pm16352(); #else return __extension__ 0x1.0p-16382Q; #endif Note that -std=gnu++11 does work. I'm not sure if it's a user error to unset `__STRICT_ANSI__` and expect libstdc++ to use only supported extensions. Filing the bug just in case.
[Bug tree-optimization/111823] New: ICE on valid code at -O1 and above on x86_64-linux-gnu: in verify_sra_access_forest, at tree-sra.cc:2414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111823
Bug ID: 111823
Summary: ICE on valid code at -O1 and above on
x86_64-linux-gnu: in verify_sra_access_forest, at
tree-sra.cc:2414
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression.
Compiler Explorer: https://godbolt.org/z/jMsxnbTcK
[514] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231015 (experimental) (GCC)
[515] %
[515] % gcctk -O1 small.c
during GIMPLE pass: esra
small.c: In function ‘main’:
small.c:9:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.cc:2414
9 | }
| ^
0x85c78c verify_sra_access_forest(access*)
../../gcc-trunk/gcc/tree-sra.cc:2414
0x1209a92 verify_all_sra_access_forests()
../../gcc-trunk/gcc/tree-sra.cc:2465
0x120d6b4 analyze_all_variable_accesses
../../gcc-trunk/gcc/tree-sra.cc:3534
0x120dc01 perform_intra_sra
../../gcc-trunk/gcc/tree-sra.cc:4726
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[516] %
[516] % cat small.c
static struct A {
int x : 4;
} a;
static int b;
int main() {
struct A t[2];
t[0] = b ? t[1] : a;
return (b ? t[1].x : 0) && 1;
}
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #23 from john.harper at vuw dot ac.nz --- Jerry I agree that that's what the standard says, though I find it odd that it allows neither 666E0 nor 666E+0 nor 666+0 in output, because any of the three would be valid input of the real value 666. But you are editing a compiler to comply with the standard, and neither of us is editing the standard itself :-) John On Sun, 15 Oct 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 15 Oct 2023 02:12:25 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Sun, 15 Oct 2023 15:13:03 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #22 from Jerry DeLisle --- > Sorry for delays. I am back looking at this. > > My take on the table 13.2 for the case: EN0.0E0 > > No matter what the E for the exponent must be shown. > > If the exponent is 0 then a plus sign must be shown. > > The value for 666. then must be 666.E+0 > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug rtl-optimization/111822] New: [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822 Bug ID: 111822 Summary: [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56115=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions testcase.C during RTL pass: lr_shrinkage testcase.C: In member function 'void SQVM::CallNative()': testcase.C:41:1: internal compiler error: in operator[], at vec.h:910 41 | } | ^ 0x7f615a vec::operator[](unsigned int) /repo/gcc-trunk/gcc/vec.h:910 0x7f63db vec::operator[](unsigned int) /repo/gcc-trunk/gcc/vec.h:936 0x7f63db pre_and_rev_post_order_compute_fn(function*, int*, int*, bool) /repo/gcc-trunk/gcc/cfganal.cc:1066 0x123b947 pre_and_rev_post_order_compute(int*, int*, bool) /repo/gcc-trunk/gcc/cfganal.cc:1079 0x1203292 init_alias_analysis() /repo/gcc-trunk/gcc/alias.cc:3429 0x285e960 sched_init() /repo/gcc-trunk/gcc/haifa-sched.cc:7331 0x286030d haifa_sched_init() /repo/gcc-trunk/gcc/haifa-sched.cc:7368 0x174ff5c schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.cc:3524 0x175063b schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.cc:3518 0x175063b rest_of_handle_live_range_shrinkage /repo/gcc-trunk/gcc/sched-rgn.cc:3720 0x175063b execute /repo/gcc-trunk/gcc/sched-rgn.cc:3807 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4642-20231015125226-g77faa3e198a-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-4642-20231015125226-g77faa3e198a-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231015 (experimental) (GCC)
