[Bug rtl-optimization/85412] [8 Regression] ICE in put_TImodes, at sel-sched.c:7191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 --- Comment #19 from Arseny Solokha --- Fixed for x86_64 on all supported branches for more than two years now. Is it fixed for IA64 too?
[Bug c++/85940] Address of label breaks ISO C++ program despite non-GNU dialect and pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85940 --- Comment #2 from Andrew Pinski --- Hmm, Even clang has the same bug: https://godbolt.org/z/fszxdGrsv :3:19: warning: use of GNU address-of-label extension [-Wgnu-label-as-value] return (bool()) && x; ^ :3:10: error: C-style cast from 'void *' to 'bool ()' is not allowed return (bool()) && x; ^ :3:22: error: use of undeclared label 'x' return (bool()) && x; ^ 1 warning and 2 errors generated. Compiler returned: 1 So what I think is happening is both GCC and clang think (bool()) is cast to a function type. This one of the areas in the C++ standard which has an ambiguity that says it should resolve to a function type and it seems like the extension gets in the way after that.
[Bug tree-optimization/98845] [9/10/11/12 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 23 which are marked as MUST COALESCE.) since r6-528-g465770e43996a132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845 --- Comment #6 from Arseny Solokha --- gcc-12.0.0-alpha20210530 snapshot (g:a0a7adeea31918deefb053a9a15257af94aecfaf) compiles the testcase w/o ICE.
[Bug c++/100282] [11/12 Regression] ICE with local class in lambda in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100282 --- Comment #2 from Arseny Solokha --- g++-12.0.0-alpha20210530 snapshot (g:a0a7adeea31918deefb053a9a15257af94aecfaf) rejects the testcase w/o ICE.
[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519 --- Comment #12 from Andrew Pinski --- My bet it is due to --enable-version-specific-runtime-libs which does not get as tested any more.
[Bug bootstrap/40516] --without-mpc, --without-ppl, --without-cloog does the same thing. No turning off mpc via configure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40516 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Andrew Pinski --- (In reply to nightstrike from comment #6) > Is it supported to build GCC without MPC? NO. GCC requires mpc to build. Also cloog/ppl support has been removed and replaced with ISL. Toplevel configure.ac has now: # Treat --without-isl as a request to disable # GRAPHITE support and skip all following checks. So I am going to assume this was fixed for ISL and MPC needs to be there and CLOOG and PPL support was removed. So closing as works for me.
[Bug tree-optimization/48387] ICE with -floop-flatten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48387 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- PPL is no longer used so closing as won't fix.
[Bug target/99842] MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842 --- Comment #4 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:df4e0359dad239854af0ea9eacb8e7e3719557d0 commit r12-1127-gdf4e0359dad239854af0ea9eacb8e7e3719557d0 Author: Peter Bergner Date: Sun May 30 22:45:55 2021 -0500 rs6000: MMA test case ICEs using -O3 [PR99842] The mma_assemble_input_operand predicate does not accept reg+reg indexed addresses which can lead to ICEs. The lxv and lxvp instructions have indexed forms (lxvx and lxvpx), so the simple solution is to just allow indexed addresses in the predicate. 2021-05-30 Peter Bergner gcc/ PR target/99842 * config/rs6000/predicates.md(mma_assemble_input_operand): Allow indexed form addresses. gcc/testsuite/ PR target/99842 * g++.target/powerpc/pr99842.C: New.
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Andrew Pinski changed: What|Removed |Added CC||merkert at comcast dot net --- Comment #219 from Andrew Pinski --- *** Bug 39128 has been marked as a duplicate of this bug. ***
[Bug target/39128] GPC polygon clipping library fails with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39128 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Known to fail|| --- Comment #6 from Andrew Pinski --- As mentioned -ffloat-store works so marking this as a dup of bug 323. 32bit x86 is less important these days too. *** This bug has been marked as a duplicate of bug 323 ***
[Bug middle-end/100839] -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 --- Comment #7 from Andrew Pinski --- (In reply to Daniel Gibson from comment #6) > Are you sure about this? > I couldn't find much about floats (and nothing about legal transformations) > in the C++ standard, and if it's in IEEE-754 it should be the same for C and > C++, right? C is just different here from C++ :).
[Bug c/47297] Inconsistent float-point to integer results depending on -O flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47297 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Inconsistent is a feature as mentioned in comment #1 and not a bug. Closing as invalid.
[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #8 from Andrew Pinski --- (In reply to Richard Biener from comment #6) > It means that the C frontend did not properly merge the _rand_ctx types. And -combine support was removed as we have -flto now. So closing as won't fix. (In reply to Michael Veksler from comment #7) > Created attachment 20340 [details] > testcase: A simple set::iterator wrapper produces the same warning This is a different issue and should be filed seperately if it still happens with a more recent GCC.
[Bug middle-end/100839] -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 --- Comment #6 from Daniel Gibson --- Are you sure about this? I couldn't find much about floats (and nothing about legal transformations) in the C++ standard, and if it's in IEEE-754 it should be the same for C and C++, right?
[Bug target/50794] [picochip] incorrect implementation of ashrsi3 for negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50794 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- picochip was removed from GCC in 2014 so closing as won't fix.
[Bug tree-optimization/51783] Missed optimization for X ==/!= (signed type) ((unsigned type) Y + Z)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783 --- Comment #5 from Andrew Pinski --- The problem with the conversion that is suggested here is the addition if changed into a signed type might have an undefined behavior when it comes to an overflow. It does not matter if it is used later with equals, it is undefined at the point of addition. if we change how GCC's gimple IR works where we have a PLUS which has a wrapping behavior or undefined overflow behavior, then this will just simplify to that. There has been some talk about that in the past but it did not get that far the last time it was started.
[Bug middle-end/52831] extract_bit_field_1: issue when str_rtx unsafe from target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52831 --- Comment #3 from Andrew Pinski --- (In reply to Aurelien Buhrig from comment #2) > Need more information about the bug? > Any comment about the provided patch? Patches should be sent to gcc-patches@, I don't think this area has changed since the bug was filed so it might still apply after 9 years.
[Bug middle-end/100839] -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #5 from Andrew Pinski ---
(In reply to Daniel Gibson from comment #4)
> Nope.
>
> 1. -std=c++11 doesn't make a difference, just tested it on compiler explorer.
> 2. What's the point of -Ofast ("It also enables optimizations that are not
> valid for all standard-compliant programs.") if the normal optimization
> levels already violate the standard?
Oh that is because C++ allows it while C does not.
/* ISO C restricts floating-point expression contraction to within
source-language expressions (-ffp-contract=on, currently an alias
for -ffp-contract=off). */
if (flag_iso
&& !c_dialect_cxx ()
&& (global_options_set.x_flag_fp_contract_mode
== (enum fp_contract_mode) 0)
&& flag_unsafe_math_optimizations == 0)
flag_fp_contract_mode = FP_CONTRACT_OFF;
[Bug other/49055] 4.6.0 libjava 64-bit + 32-bit multilib compile fails due missing -isystem and -nostdinc++ with $OBJDIR != $topsrcdir build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49055 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Target Milestone|--- |7.0 --- Comment #1 from Andrew Pinski --- libjava has been removed since GCC 7.
[Bug middle-end/100839] -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
Daniel Gibson changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Daniel Gibson ---
Nope.
1. -std=c++11 doesn't make a difference, just tested it on compiler explorer.
2. What's the point of -Ofast ("It also enables optimizations that are not
valid for all standard-compliant programs.") if the normal optimization levels
already violate the standard?
[Bug lto/70955] [6 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Andrew Pinski changed: What|Removed |Added CC||marcus at jet dot franken.de --- Comment #30 from Andrew Pinski --- *** Bug 45007 has been marked as a duplicate of this bug. ***
[Bug target/45007] LTO ICE with __builtin_ms_va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45007 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Even though this is not an exact dup of bug 70955, even with the ICE fixed, the wrong code would have happened. This was fixed with PR 70955. *** This bug has been marked as a duplicate of bug 70955 ***
[Bug middle-end/100839] -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #3 from Andrew Pinski --- Use strict language mode then, e.g. -std=c++11 or -std=c11 etc.
[Bug middle-end/100839] -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 Daniel Gibson changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Daniel Gibson --- Do I understand this correctly that optimized builds by default violate the standard? At least that's what the difference between -ffp-contract=fast and the unimplemented -ffp-contract=on suggests
[Bug bootstrap/45185] Building GCC-4.5.1 with gmp/mpfr in source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45185 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- cloog/ppl_c/ppl has been removed and replaced with isl which works ok compiling inside the gcc directory too. What was happening before is libgmpxx was picking up the shared library version which links to libgmp. The link order has changed now too such that -L/data/gcc-arm/wa/gcc_obj2/./gmp/.libs -L/data/gcc-arm/wa/gcc_obj2/./mpfr/.libs is placed before isl libraries.
[Bug middle-end/100839] -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Component|c++ |middle-end Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- -ffp-contract=off https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Optimize-Options.html#index-ffp-contract -ffp-contract=style -ffp-contract=off disables floating-point expression contraction. -ffp-contract=fast enables floating-point expression contraction such as forming of fused multiply-add operations if the target has native support for them. -ffp-contract=on enables floating-point expression contraction if allowed by the language standard. This is currently not implemented and treated equal to -ffp-contract=off. The default is -ffp-contract=fast.
[Bug middle-end/44985] warnings: gcc shifts integer by its entire size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44985 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |5.0 Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- HOST_WIDE_INT has been 64bit always since GCC 5 since r5-894 so this is no longer a bug.
[Bug c++/100839] New: -O2 does dangerous optimizations using FMA (please don't break my cross product)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
Bug ID: 100839
Summary: -O2 does dangerous optimizations using FMA (please
don't break my cross product)
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: metalcaedes at gmail dot com
Target Milestone: ---
Created attachment 50893
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50893=edit
simple test case (same as on compiler explorer)
I'm having problems with a cross-product function returning (slightly) wrong
results when built with -O2 (or above) and with FMA enabled (like
-march=znver1) - more specifically, -fexpensive-optimizations causes the
problem.
-ffast-math or related flags were *not* used.
Values that should be exactly 0 aren't, because the intermediate of the
multiplication part of vfmsub132ss has "infinite precision" while the
subtracted value (also result of a multiplication) has single-precision.
I (or rather Doom3) has a 3D Vector class called idVec3 which has three
(single-precision) float members x, y, z.
The cross product is calculated like this:
idVec3 cross( const idVec3& v1, const idVec3 ) {
float x = v1.y * v2.z - v1.z * v2.y;
float y = v1.z * v2.x - v1.x * v2.z;
float z = v1.x * v2.y - v1.y * v2.x;
return idVec3(x, y, z);
}
For brevity (and because it was what caused the bug I investigated[1]) I only
looked at the calculation of z, but the same problem should happen with x and
y:
float crossZ(const idVec3& v1, const idVec3& v2) {
float z = v1.x * v2.y - v1.y * v2.x;
return z;
}
So if v1.x * v2.y == v1.y * v2.x (like when v1 == v2) z should be exactly 0.0
However, it's not when FMA and -fexpensive-optimizations are used, because then
that function is generated as:
vmulss xmm1,xmm1,xmm2
vfmsub132ss xmm0,xmm1,xmm3
ret
So the `v1.y * v2.x` part is calculated with a normal multiplication and stored
as single-precision floats.
Then `v1.x * v2.y - other_result` is calculated with vfmsub132ss, which means
that the result of `v1.x * v2.y` is never stored, but only exist as an
"infinite precision intermediate result"[2] from which the other
(single-precision) result of the `vmulss` is subtracted.
This means that, if both multiplication results should *theoretically* be
identical, it returns the rounding error between the result as "infinite
precision" float (double at least?) and single-precision float.
This rounding error fits well into a float because floats have great precisions
near zero - and it can be relatively big: With v1.x = -277.129883 and v1.y
= -69.282471 (result of multiplications: about 23665.775), crossZ(v1, v1)
returns 0.0002170140.
With -O1 (or -O2 -fno-expensive-optimizations) the generated ASM is more
straightforward and, as expected, does two multiplications and then an
addition:
vmovss xmm0,DWORD PTR [rdi]
vmulss xmm0,xmm0,DWORD PTR [rsi+0x4]
vmovss xmm1,DWORD PTR [rdi+0x4]
vmulss xmm1,xmm1,DWORD PTR [rsi]
vsubss xmm0,xmm0,xmm1
ret
IMHO an optimization that basically causes a*b - b*a to not return exactly 0.0
should only be enabled with dangerous flags like -ffast-math, not with plain
-O2.
Incidentally, it seems like this is what clang does: It only uses vfmsub* in
crossZ() if -ffast-math is set.
Here's a compiler explorer link with a reduced (to .z) testcase, printing the
results of that function when compiled with -O2 vs -O1:
https://gcc.godbolt.org/z/8K3vKh7b3
The problem happens with all GCC versions I tested, including the 11.1 and
"trunk" versions in compiler explorer. I didn't test this, but I wouldn't be
surprised if plain C was also affected (and not just C++).
[1] https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/436
[2] https://www.felixcloutier.com/x86/vfmsub132ss:vfmsub213ss:vfmsub231ss
[Bug other/43979] MPFR can no longer be compiled together with GCC: missing target @MAINTAINER_MODE_TRUE@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43979 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Andrew Pinski --- This has been working for me and others. I suspect you are building where srcdir == objdir which is not really supported.
[Bug rtl-optimization/42367] long vector operation causes gcc to copy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42367 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Severity|normal |enhancement Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED Keywords||missed-optimization --- Comment #3 from Andrew Pinski --- Fixed in GCC 10 at least. Might have been fixed before too but I can only check GCC 7 and GCC 10 at this moment.
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |10.0 Resolution|--- |WONTFIX --- Comment #20 from Andrew Pinski --- SPU support was removed.
[Bug testsuite/40108] gcc.dg/torture/complex-* tests fail on spu-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40108 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED Target Milestone|--- |10.0 --- Comment #1 from Andrew Pinski --- spu support was removed in GCC 10.
[Bug target/36837] x86_64 linux-gnu gcc miscompiles spu-elf gcc (4.4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36837 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED --- Comment #12 from Andrew Pinski --- spu as a target has been removed since GCC 10.
[Bug target/31170] cmpxchgq not emitted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31170 --- Comment #3 from Andrew Pinski --- Note I think the volatile will block ifcvt from doing anything too. The other thing is this thread safe for C++11/C11 memory models. That is does cmpxchgq do a store always or only when the compare is true and is that guaranteed?
[Bug target/31170] cmpxchgq not emitted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31170 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement Component|rtl-optimization|target
[Bug tree-optimization/13756] [tree-ssa] documentation missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13756 --- Comment #18 from Andrew Pinski --- Note libmudflap was removed back in 2014. libgfortran is still there though. Someone has to audit the comments here to figure out if there is anything else to be done.
[Bug testsuite/30788] testsuite for libmudflap failed while using -DSTATIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30788 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Target Milestone|--- |5.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- libmudflap has been removed since at least GCC 5.
[Bug tree-optimization/95481] Failure to optimize infinite recursion for empty struct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95481 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- Created attachment 50892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50892=edit Patch which I am testing I need to change the comment before the if statement and add a few testcases. But this is the patch which I am testing which fixes the problem.
[Bug testsuite/28078] Various testsuite fails with --enable-threads=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28078 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Target Milestone|--- |7.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- GCJ has been removed since GCC 7 so closing as won't fix.
[Bug debug/96635] Feature request: PDB support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 Andrew Pinski changed: What|Removed |Added Target||mingw Severity|normal |enhancement
[Bug tree-optimization/100834] False positive of -Wstringop-overflow= with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100834 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Sebor --- 0xdeadbeef is not a valid address of either declared or allocated object so the warning takes its size to be zero. The warning can be avoided by making the pointer volatile as suggested for example in pr99578 comment 16. *** This bug has been marked as a duplicate of bug 99578 ***
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Martin Sebor changed: What|Removed |Added CC||florian.bezdeka at siemens dot com --- Comment #17 from Martin Sebor --- *** Bug 100834 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/96187] GCC at -O2 generates branch for code that should be branch-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96187 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96160 Andrew Pinski changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Has been fixed since June of last year with r11-881.
[Bug tree-optimization/95891] Missing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95891
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|rtl-optimization|tree-optimization
--- Comment #2 from Andrew Pinski ---
Confirmed. Happens on aarch64 too:
cmp w0, w1
beq .L5
mov w0, 0
ret
.p2align 2,,3
.L5:
asr x0, x0, 32
asr x1, x1, 32
cmp w0, w1
csetw0, eq
ret
I wonder if we could expose that point is passed via a 64bit argument at the
tree level and then use BIT_FIELD_REF to do the extraction or lower the field
extractions to BIT_FIELD_REF.
Also we don't optimize:
bool f1(unsigned long long a, unsigned long long b) {
return (((int)a) == ((int)b)) && ((int)(a>>32) == (int)(b>>32));
}
into just return a==b; either.
Which is another thing which needs to happen after the BIT_FIELD_REF Change ...
[Bug target/95967] Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Created attachment 50891 [details]
> Start of the patch which should fix most of it
>
> This patch which should fix the majority of the problem though I have not
> tested it on the testcase. Basically it takes the BIT_INSERT_EXPR's and
> "combines" them such that they become a CONSTRUCTOR.
> I am still deciding if this belongs in reassoc or as part of forwprop.
This patch looks like it only fixes f1 and g1.
Most likely because I did not handle CONSTRUCTOR as the initial case:
f2:
_6 = {s0_2(D), s0_2(D), s0_2(D), s0_2(D)};
__builtin_aarch64_im_lane_boundsi (16, 4, 1);
__builtin_aarch64_im_lane_boundsi (16, 4, 2);
__builtin_aarch64_im_lane_boundsi (16, 4, 3);
_10 = BIT_INSERT_EXPR <_6, s1_3(D), 32>;
_12 = BIT_INSERT_EXPR <_10, s2_4(D), 64>;
__vec_14 = BIT_INSERT_EXPR <_12, s3_5(D), 96>;
I will look into adding that in a few weeks and add a testcase for it too.
[Bug target/95967] Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Created attachment 50891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50891=edit Start of the patch which should fix most of it This patch which should fix the majority of the problem though I have not tested it on the testcase. Basically it takes the BIT_INSERT_EXPR's and "combines" them such that they become a CONSTRUCTOR. I am still deciding if this belongs in reassoc or as part of forwprop.
[Bug target/95967] Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-30 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/95967] Poor aarch64 vector constructor code when using arm_neon.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95967 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/95855] A missing ifcvt optimization to generate fcsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95855 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed.
Re: GCC Rust git branch
Hi, On Fri, May 28, 2021 at 11:18:20AM +0100, Philip Herron wrote: > On 28/05/2021 04:05, Thomas Fitzsimmons wrote: > > I tried building GCC Rust on ppc64le. With the attached patches, > > "make check-rust" succeeds with: > > > > === rust Summary === > > > > # of expected passes2368 > > # of expected failures 26 > > > > Thank you so much for doing this, we will merge these later today. The > results look the same as the numbers were getting on x86 too. And I am getting the same results on arm64. To make sure things keep zero fail I added a fedora-x86_64 and debian_arm64 worker to my buildbot setup: https://builder.wildebeest.org/buildbot/#/builders?tags=gccrust (The red builds were setup bugs, the last build is all green) I'll try to also add the ppc64le builder. Are there any other arches that are zero fail? Once we have a mailinglist I can set it up so that any failures will sent email to the rust@gcc mailinglist. It is currently tracking the master branch. Maybe we can integrate it with the bors setup you have running. But I didn't really understand where it is running and how it is configured so that it can be integrated with the buildbot workers. Note that the workers aren't very fast. Especially the arm64 one. I takes ~30 minutes for a fully make && make check. So please no more than 48 patches a day please :) Cheers, Mark
[Bug target/95704] PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/95669] -O3 generates more complicated code to return 8-byte struct of zeros, sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95669 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/95643] Optimizer fails to realize that a variable tested twice in a row is the same both times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95643 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/95531] Failure to use TZCNT for __builtin_ffs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95531 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/95481] Failure to optimize infinite recursion for empty struct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95481
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-05-30
Summary|Failure to optimize |Failure to optimize
|infinite recursion for |infinite recursion for
|struct types|empty struct types
--- Comment #1 from Andrew Pinski ---
The problem only exist for empty structs. If we add a field, we get the better
code:
foo:
.LFB0:
.cfi_startproc
.p2align 3,,7
.L2:
b .L2
The reason why this happens is because we remove the assignment for empty
struct assignment during gimplification. This messes up how tailr and tailc
works.
Note here is a testcase for tailc:
struct A {};
struct A goo(void);
struct A foo(void)
{
return goo();
}
[Bug target/95650] aarch64: Missed optimization storing addition of two shorts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95650 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Build|aarch64-none-linux-gnu | Host|aarch64-none-linux-gnu | Last reconfirmed|2020-06-12 00:00:00 |2021-5-30 --- Comment #5 from Andrew Pinski --- The problem is when combine comes in we get: Trying 3, 8 -> 10: 3: r94:SI=zero_extend(x1:HI) REG_DEAD x1:HI 8: r96:SI=zero_extend(x0:HI)+r94:SI REG_DEAD x0:HI REG_DEAD r94:SI 10: [r98:DI]=r96:SI#0 REG_DEAD r98:DI REG_DEAD r96:SI Failed to match this instruction: (set (mem:HI (reg:DI 98) [1 *ptr_5(D)+0 S2 A16]) (plus:HI (reg:HI 1 x1 [ b ]) (reg:HI 0 x0 [ a ]))) There is no plus:HI pattern for aarch64 so there is no matching happening if we do this a 3->2. I don't know if combine could be enhanced here to allow widening to SI to happen if HImode for plus does not exist.
gcc-12-20210530 is now available
Snapshot gcc-12-20210530 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20210530/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision a0a7adeea31918deefb053a9a15257af94aecfaf You'll find: gcc-12-20210530.tar.xz Complete GCC SHA256=3887b1aa0fe889244ea07104e9874e3df5985f5dc8435b210cc5f038893855aa SHA1=d0c62ed0e84000cd66cb4d24206ee916f5351b8d Diffs from 12-20210523 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC Rust git branch
Hi Philip, On Fri, May 28, 2021 at 11:31:02AM +0100, Philip Herron wrote: > As for the git hooks, is it possible that I amend the hooks within the > gccrs repo .git/hooks folder? Or is this something i need to change in > the GCC repo? Sorry i should really read up more on git hooks in general. See the email from Joseph Myers. The gcc repo already has hooks installed and you can configure them through a magic ref/branch project.config file setup. Cheers, Mark
[committed] libstdc++: Remove "Intel Compilers" bibliography entry
Actually quite a bit annoying, and searching for that document did not success (and gave me the original link). Pushed. Gerald commit a0a7adeea31918deefb053a9a15257af94aecfaf Author: Gerald Pfeifer Date: Mon May 31 00:27:17 2021 +0200 libstdc++: Remove "Intel Compilers" bibliography entry The original link redirects to a very generic page that advertises lots of tools and other things, just not this. libstdc++-v3/ChangeLog: 2021-05-31 Gerald Pfeifer * doc/xml/manual/abi.xml: Remove dead reference to "Intel Compilers for Linux: Compatibility with GNU Compilers" article. * doc/html/manual/abi.html: Regenerate. diff --git a/libstdc++-v3/doc/html/manual/abi.html b/libstdc++-v3/doc/html/manual/abi.html index 3131731daca..0b9928c5121 100644 --- a/libstdc++-v3/doc/html/manual/abi.html +++ b/libstdc++-v3/doc/html/manual/abi.html @@ -534,10 +534,6 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. https://itanium-cxx-abi.github.io/cxx-abi/; target="_top"> Itanium C++ ABI - . - https://software.intel.com/content/www/us/en/develop/articles/intel-compilers-for-linux-compatibility-with-gnu-compilers.html; target="_top"> - Intel Compilers for Linux: Compatibility with GNU Compilers - . https://docs.oracle.com/cd/E23824_01/html/819-0690/index.html; target="_top"> Linker and Libraries Guide (document 819-0690) @@ -573,4 +569,4 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. . SYRCoSE 2009 -. Pavel Shved. Denis Silakov. Prev??Up??NextTesting??Home??API Evolution and Deprecation History \ No newline at end of file +. Pavel Shved. Denis Silakov. Prev??Up??NextTesting??Home??API Evolution and Deprecation History diff --git a/libstdc++-v3/doc/xml/manual/abi.xml b/libstdc++-v3/doc/xml/manual/abi.xml index b332c978450..c2c0c028a8b 100644 --- a/libstdc++-v3/doc/xml/manual/abi.xml +++ b/libstdc++-v3/doc/xml/manual/abi.xml @@ -1141,16 +1141,6 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. - - - - http://www.w3.org/1999/xlink; - xlink:href="https://software.intel.com/content/www/us/en/develop/articles/intel-compilers-for-linux-compatibility-with-gnu-compilers.html;> - Intel Compilers for Linux: Compatibility with GNU Compilers - - - - http://www.w3.org/1999/xlink;
[Bug rtl-optimization/95685] Loop invariants can't be moved out of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95685 --- Comment #4 from Andrew Pinski --- With -funroll-loops on the trunk for the aarch64 target, I get no loop any more: bar and seems like good code: .LFB0: .cfi_startproc and w1, w1, 65535 mov w2, 8193 tst w0, 2 eor w3, w1, w2 cselw4, w1, w3, eq tst w0, 4 eor w5, w4, w2 and w6, w5, 65535 cselw7, w6, w4, ne tst w0, 8 eor w0, w7, w2 and w8, w0, 65535 cselw0, w8, w7, ne ret Oh I recongize this loop too, it is from coremark.
[Bug target/95632] Redundant zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c/95714] Poor locations for errors in calls to __atomic built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95714 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-30 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- C++ front-end does a little better than the C front-end now: apinski@xeond:~/src/upstream-gcc$ ~/upstream-gcc/bin/gcc t887.c t887.c: In function ‘main’: t887.c:5:3: error: size mismatch in argument 2 of ‘__atomic_load’ 5 | __atomic_load(, , __ATOMIC_SEQ_CST); | ^ apinski@xeond:~/src/upstream-gcc$ ~/upstream-gcc/bin/g++ t887.c t887.c: In function ‘int main()’: t887.c:5:16: error: size mismatch in argument 2 of ‘__atomic_load’ 5 | __atomic_load(, , __ATOMIC_SEQ_CST); | ~^~ Confirmed.
[committed] wwwdocs: readings: Remove PRU-ICSS documentation reference
TI's server has been telling us that "The PRU-ICSS wiki is in the process of being migrated to software-dl.ti.com" for five months. Time to pull the plug. --- htdocs/readings.html | 1 - 1 file changed, 1 deletion(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index c4c0618a..33ed5822 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -256,7 +256,6 @@ names. pru Manufacturer: Texas Instruments - https://processors.wiki.ti.com/index.php/PRU-ICSS;>Official PRU Documentation https://elinux.org/Category:PRU;>Community PRU Documentation -- 2.31.1
[committed] wwwdocs: Nick's Blog has moved
I pushed this based on a 301 (moved permanently) from developers.redhat.com. Nick, any plans to create a new Toolchain Update blog? :-) Gerald commit 47b1f39c5e4a31073311c48a51872ccf7bd51659 Author: Gerald Pfeifer Date: Mon May 31 00:11:01 2021 +0200 wwwdocs: Nick's Blog has moved diff --git a/htdocs/index.html b/htdocs/index.html index 46969457..9f8392d9 100644 --- a/htdocs/index.html +++ b/htdocs/index.html @@ -138,7 +138,7 @@ mission statement. https://gcc.gnu.org/news.html;>Older news | -https://developers.redhat.com/blog/author/nickclifton/;>Nick's Blog | +https://developers.redhat.com/author/nick-clifton;>Nick's Blog | More news? Let ger...@pfeifer.com know!
Re: [committed] wwwdocs: mirrors.html: Move gwdg.de from ftp to https
On Sun, 30 May 2021, Tim Ehlers wrote: > it's still the "FTP"-Server, even if we nowadays also allow different > protocols (http/rsync) and also have ssl for http in place. > > But could you please change: > > Germany: https://ftp.gwdg.de/pub/misc/gcc/;>ftp.gwdg.de, > thanks to emoe...@gwdg.de > > to: > > Germany: https://ftp.gwdg.de/pub/misc/gcc/;>ftp.gwdg.de, > thanks to f...@gwdg.de > > since Eberhard retired and we have the generic contact address > f...@gwdg.de for contacts now. Sure, happy to, Tim. Thank you for the confirmation and the update! I pushed the change below. If there's anything else (or I missed something), please just let me know. Cheers, Gerald commit 0ff205ff678c35addd412a6e405edb034ad65b23 Author: Gerald Pfeifer Date: Sun May 30 23:13:10 2021 +0200 mirrors: Replace emoe...@gwdg.de by f...@gwdg.de diff --git a/htdocs/mirrors.html b/htdocs/mirrors.html index 34da075a..083c6c04 100644 --- a/htdocs/mirrors.html +++ b/htdocs/mirrors.html @@ -21,7 +21,7 @@ mirrors. The following sites mirror the gcc.gnu.org download site France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/;>ftp.irisa.fr, thanks to ftpma...@irisa.fr France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/;>ftp.uvsq.fr, thanks to ftpma...@uvsq.fr Germany, Berlin: ftp://ftp.fu-berlin.de/unix/languages/gcc/;>ftp.fu-berlin.de, thanks to f...@fu-berlin.de -Germany: https://ftp.gwdg.de/pub/misc/gcc/;>ftp.gwdg.de, thanks to emoe...@gwdg.de +Germany: https://ftp.gwdg.de/pub/misc/gcc/;>ftp.gwdg.de, thanks to f...@gwdg.de Germany: https://ftp.mpi-inf.mpg.de/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/;>mpi-sb.mpg.de, thanks to ftpad...@mpi-sb.mpg.de Germany: http://gcc.cybermirror.org;>http://gcc.cybermirror.org, thanks to Sascha Schwarz (c...@cybermirror.org) Greece: http://ftp.ntua.gr/mirror/gnu/gcc/;>ntua.gr, thanks to ftp...@ntua.gr
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #11 from Dominique d'Humieres --- > I have fixed the glaring mistake in PR94331.c, could you be so gentle > as to test it to verify that it does indeed solve the problems you found? The problem seems solved with the updated PR94331.c. Thanks.
[Bug c++/100838] -fno-elide-constructors for C++14 missing required destructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838
--- Comment #1 from Amir Kirsh ---
This main:
int main() {
MyString s1 = MyString{"Hello"}; // same also for rounded brackets
std::cout << __LINE__ << std::endl;
}
works as expected.
Output with C++14 and -fno-elide-constructors:
ctor
copy ctor
dtor
22
dtor
[Bug c++/100838] New: -fno-elide-constructors for C++14 missing required destructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838
Bug ID: 100838
Summary: -fno-elide-constructors for C++14 missing required
destructor call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kirshamir at gmail dot com
Target Milestone: ---
Code: https://godbolt.org/z/jKnKTds7s
#include
class MyString {
public:
MyString(const char* s = "") {
std::cout << "ctor" << std::endl;
}
~MyString() {
std::cout << "dtor" << std::endl;
}
MyString(const MyString& s) {
std::cout << "copy ctor" << std::endl;
}
MyString& operator=(const MyString& s) {
std::cout << "operator=" << std::endl;
return *this;
}
};
int main() {
MyString s1 = "Hello";
std::cout << __LINE__ << std::endl;
}
---
When compiled with:
-std=c++14 -fno-elide-constructors
Output:
ctor
copy ctor
22
dtor
Expected output:
ctor
copy ctor
dtor
22
dtor
[Bug c/99022] When ‘long int’ is 32 bits，the conversion between 'vector(2) int' and 'vector(2) long int' can't be done without 'flax-vector-conversions'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99022 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Yes, it is similar as int* and long* cannot be done in normal C code.
[Bug rtl-optimization/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 --- Comment #9 from Andrew Pinski --- *** Bug 99455 has been marked as a duplicate of this bug. ***
[Bug middle-end/99455] internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 99454. *** This bug has been marked as a duplicate of bug 99454 ***
[Bug rtl-optimization/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #8 from Andrew Pinski --- Fixed.
[Bug c/98267] internal compiler error: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98267 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- No feedback in 5 months so closing as a dup of bug 98256 then. *** This bug has been marked as a duplicate of bug 98256 ***
[Bug tree-optimization/98256] [11 Regression] ICE at -Os and above: verify_ssa failed since r11-5957
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98256 Andrew Pinski changed: What|Removed |Added CC||ryan.burn at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 98267 has been marked as a duplicate of this bug. ***
[Bug middle-end/98132] ‘target_mem_ref’ not supported by expression internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98132 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Andrew Pinski --- No feedback in over 5 months so closing invalid.
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #10 from José Rui Faustino de Sousa --- Hi Dominique, Thank you vary much for taking the time to test the patch. If I understand you correctly the problem is on the test not on the patch itself, right? I have fixed the glaring mistake in PR94331.c, could you be so gentle as to test it to verify that it does indeed solve the problems you found? Thank you very much. Best regards, José Rui
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #9 from José Rui Faustino de Sousa --- Created attachment 50890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50890=edit Updated PR94331.c test file
[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-30 Status|UNCONFIRMED |ASSIGNED --- Comment #7 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug c++/90031] Bogus parse error trying to explicitly specialize a template variable inside class scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90031
Will Wray changed:
What|Removed |Added
CC||wjwray at gmail dot com
--- Comment #1 from Will Wray ---
The same rejects-valid still on gcc-12 trunk on any partial specialization
of a variable template in class scope (and, now, same with std=c++20).
Accepted and works on most other compilers on CE, c++17, so easy to CONFIRM
Further reduced example https://godbolt.org/z/rcne3aEd7:
struct Struct {
template static bool v;
template static bool v;
};
:3:37: error: explicit template argument list not allowed
3 | template static bool v;
| ^
Duplicate bug 100231
[Bug c++/100231] [C++17] Variable template specialization inside a class gives compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100231 Will Wray changed: What|Removed |Added CC||wjwray at gmail dot com --- Comment #1 from Will Wray --- Duplicate bug 90031 on any partial specialization of a variable template in class scope
[Bug target/100837] New: nds32le-linux: error: array subscript 2 is above array bounds of 'rtx_def* [2]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100837
Bug ID: 100837
Summary: nds32le-linux: error: array subscript 2 is above array
bounds of 'rtx_def* [2]'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbg...@lug-owl.de
Target Milestone: ---
Hi!
As I started automated testing again, I found an issue with the nds32 backend
code. Host/build compiler is nearly master, GCC source tree is
a8f588be038317bf1e9c71f7e626a3d23255ab37.
./gcc/configure --target=nds32le-linux --enable-werror-always
--enable-languages=all --disable-gcov --disable-shared --disable-threads
--without-headers
--prefix=/var/lib/laminar/run/gcc-nds32le-linux/1/toolchain-install
make all-gcc
[...]
[all 2021-05-30 18:46:49] /usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace -o insn-emit.o -MT
insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.c
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md: In
function 'rtx_def* gen_unspec_clr_pending_hwint(rtx)':
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:304:12:
warning: unquoted identifier or keyword '__nds32__clr_pending_hwint' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] 304 | error ("__nds32__clr_pending_hwint not
support NDS32_INT_SWI,"
[all 2021-05-30 18:46:51] |
^~~
[all 2021-05-30 18:46:51] 305 |" NDS32_INT_ALZ, NDS32_INT_IDIVZE,
NDS32_INT_DSSIM");
[all 2021-05-30 18:46:51] |
~~~
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:304:12:
warning: unquoted identifier or keyword 'NDS32_INT_SWI' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:304:12:
warning: unquoted identifier or keyword 'NDS32_INT_ALZ' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:304:12:
warning: unquoted identifier or keyword 'NDS32_INT_IDIVZE' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:304:12:
warning: unquoted identifier or keyword 'NDS32_INT_DSSIM' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md: In
function 'rtx_def* gen_unspec_get_pending_int(rtx, rtx)':
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:362:12:
warning: unquoted identifier or keyword 'get_pending_int' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] 362 | error ("get_pending_int not support
NDS32_INT_ALZ,"
[all 2021-05-30 18:46:51] |
^~~~
[all 2021-05-30 18:46:51] 363 |" NDS32_INT_IDIVZE,
NDS32_INT_DSSIM");
[all 2021-05-30 18:46:51] |
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:362:12:
warning: unquoted identifier or keyword 'NDS32_INT_ALZ' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:362:12:
warning: unquoted identifier or keyword 'NDS32_INT_IDIVZE' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:362:12:
warning: unquoted identifier or keyword 'NDS32_INT_DSSIM' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md: In
function 'rtx_def* gen_unspec_set_int_priority(rtx, rtx)':
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:420:12:
warning: unquoted identifier or keyword 'set_int_priority' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51] 420 | error ("set_int_priority not support
NDS32_INT_SWI,"
[all 2021-05-30 18:46:51] |
^
[all 2021-05-30 18:46:51] 421 |" NDS32_INT_ALZ, NDS32_INT_IDIVZE,
NDS32_INT_DSSIM");
[all 2021-05-30 18:46:51] |
~~~
[all 2021-05-30 18:46:51] ../../gcc/gcc/config/nds32/nds32-intrinsic.md:420:12:
warning: unquoted identifier or keyword 'NDS32_INT_SWI' in format
[-Wformat-diag]
[all 2021-05-30 18:46:51]
Re: [Patch?][RFC][RTL] clobber handling & buildin expansion - missing insn_invalid_p call [PR100418]
On 5/5/2021 7:50 AM, Tobias Burnus wrote: Hi Eric, hi all, currently, gcn (amdgcn-amdhsa) bootstrapping fails as Alexandre's patch to __builtin_memset (applied yesterday) now does more expansions. The problem is [→ PR100418] (set(reg:DI)(plus:DI(reg:DI)(const_int))) [= "adddi3"] This fails with gcn as gcn has two clobbers for "adddi3" - and when expand_insn is called, INSN_CODE == -1 via: icode = recog_memoized (insn); alias INSN_CODE (insn) = recog (PATTERN (insn), insn, 0); As the "int *pnum_clobber" argument is NULL (well, '0'), the clobbers are not available - which causes the pattern fail. I think that's a general issue with the RTX code generated by builtins.c – except that most targets either do not have clobbers for the used operators — or the code is by chance fixed: For instance, I see that several "if" blocks being processed in recog.c's insn_invalid_p via 'cleanup_cfg (CLEANUP_NO_INSN_DEL)'; the innermost parts of the call chain are: apply_change_group → verify_changes → insn_invalid_p * * * The attached patch seems to solve the GCN issue. Does it look OK? Or does the insn_invalid_p call come too late? If so, any suggestion where it would fit best? Tobias, who is more a FE and early-ME person. - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf recog.diff extract_insn: Call insn_invalid_p is insn cannot be found. gcc/ChangeLog: * recog.c (extract_insn): Call insn_invalid_p if recog_memoized did not find the insn. Was this issue on GCN fixed by Andrew/Jakub's change to use force_operand rather than emit_move_insn? Jeff
Re: [PATCH v2 01/11] Add TARGET_READ_MEMSET_VALUE/TARGET_GEN_MEMSET_VALUE
On 5/11/2021 5:35 PM, H.J. Lu via Gcc-patches wrote: Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support target instructions to duplicate QImode value to TImode/OImode/XImode value for memmset. Define SCRATCH_SSE_REG as a scratch register for ix86_gen_memset_value. gcc/ PR middle-end/90773 * builtins.c (builtin_memset_read_str): Call targetm.read_memset_value. (builtin_memset_gen_str): Call targetm.gen_memset_value. * target.def (read_memset_value): New hook. (gen_memset_value): Likewise. * targhooks.c: Inclue "builtins.h". (default_read_memset_value): New function. (default_gen_memset_value): Likewise. * targhooks.h (default_read_memset_value): New prototype. (default_gen_memset_value): Likewise. * config/i386/i386-expand.c (ix86_expand_vector_init_duplicate): Make it global. * config/i386/i386-protos.h (ix86_minimum_incoming_stack_boundary): New. (ix86_expand_vector_init_duplicate): Likewise. * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Add an argument to ignore stack_alignment_estimated. It is passed as false by default. (ix86_gen_memset_value_from_prev): New function. (ix86_gen_memset_value): Likewise. (ix86_read_memset_value): Likewise. (TARGET_GEN_MEMSET_VALUE): New. (TARGET_READ_MEMSET_VALUE): Likewise. * config/i386/i386.h (SCRATCH_SSE_REG): New. * doc/tm.texi.in: Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE hooks. * doc/tm.texi: Regenerated. gcc/testsuite/ PR middle-end/90773 * gcc.target/i386/pr90773-15.c: New test. * gcc.target/i386/pr90773-16.c: Likewise. * gcc.target/i386/pr90773-17.c: Likewise. * gcc.target/i386/pr90773-18.c: Likewise. * gcc.target/i386/pr90773-19.c: Likewise. Why does this need target hooks? ISTM the right way to go here is to just emit the constant load to the target register and let the target figure out how best to construct the constant into the register. If that means load it via QImode and broadcast, that's fine, but I'm not sure why that's not all implemented in the target files. jeff
Re: [PATCH] Optimize x < 0 ? ~y : y to (x >> 31) ^ y in match.pd
On 5/23/2021 10:21 AM, Andrew Pinski via Gcc-patches wrote: On Sun, May 23, 2021 at 6:14 AM Marc Glisse wrote: On Sun, 23 May 2021, apinski--- via Gcc-patches wrote: +(for cmp (ge lt) +/* x < 0 ? ~y : y into (x >> (prec-1)) ^ y. */ +/* x >= 0 ? ~y : y into ~((x >> (prec-1)) ^ y). */ + (simplify + (cond (cmp @0 integer_zerop) (bit_not @1) @1) + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) +&& !TYPE_UNSIGNED (TREE_TYPE (@0)) +&& TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (type)) Is there a risk that x is signed char (precision 8) and y is a vector with 8 elements? Yes there should be a check for "INTEGRAL_TYPE_P (type)" there too. I had missed it when I was doing the conversion. I will add it and resubmit the patch. Consider it approved with that fix. Thanks, Jeff
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #8 from Dominique d'Humieres --- Easier to read warnings: pr94331_1.f90:121:10: warning: type of 'checkb_o_ar' does not match original declaration [-Wlto-type-mismatch] 121 | if(.not.checkb_o_ar(a, 0, ex-1))stop 28 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:111:10: warning: type of 'checkb_o_as' does not match original declaration [-Wlto-type-mismatch] 111 | if(.not.checkb_o_as(a, 0, ex-1))stop 20 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:101:10: warning: type of 'checkb_p_ar' does not match original declaration [-Wlto-type-mismatch] 101 | if(.not.checkb_p_ar(a, lb, ub)) stop 12 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:91:10: warning: type of 'checkb_p_as' does not match original declaration [-Wlto-type-mismatch] 91 | if(.not.checkb_p_as(a, lb, ub)) stop 4 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:167:10: warning: type of 'checkb_a_ar' does not match original declaration [-Wlto-type-mismatch] 167 | if(.not.checkb_a_ar(b, lb, ub)) stop 63 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:155:10: warning: type of 'checkb_a_as' does not match original declaration [-Wlto-type-mismatch] 155 | if(.not.checkb_a_as(b, lb, ub)) stop 54 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.c:38:1: note: 'check_bounds' was previously declared here pr94331_1.c:38:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used Note that the test passes with -Wno-lto-type-mismatch.
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #7 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html With the patch the test PR94331.f90 fails with -flto: % gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90 /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c -flto /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:121:10: warning: type of 'checkb_o_ar' does not match original declaration [-Wlto-type-mismatch] 121 | if(.not.checkb_o_ar(a, 0, ex-1))stop 28 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:111:10: warning: type of 'checkb_o_as' does not match original declaration [-Wlto-type-mismatch] 111 | if(.not.checkb_o_as(a, 0, ex-1))stop 20 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:101:10: warning: type of 'checkb_p_ar' does not match original declaration [-Wlto-type-mismatch] 101 | if(.not.checkb_p_ar(a, lb, ub)) stop 12 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:91:10: warning: type of 'checkb_p_as' does not match original declaration [-Wlto-type-mismatch] 91 | if(.not.checkb_p_as(a, lb, ub)) stop 4 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:167:10: warning: type of 'checkb_a_ar' does not match original declaration [-Wlto-type-mismatch] 167 | if(.not.checkb_a_ar(b, lb, ub)) stop 63 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:155:10: warning: type of 'checkb_a_as' does not match original declaration [-Wlto-type-mismatch] 155 | if(.not.checkb_a_as(b, lb, ub)) stop 54 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: 'check_bounds' was previously declared here /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used Note that the original test seems fixed even with -flto.
[Bug target/100836] New: microblaze-linux: RTX may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100836 Bug ID: 100836 Summary: microblaze-linux: RTX may be used uninitialized in this function Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jbg...@lug-owl.de Target Milestone: --- Hi! After having started my testing efforts again, I found these two warnings which might be legit for microblaze-linux. Configured as: ../gcc/configure --target=microblaze-linux --enable-werror-always --enable-languages=all --disable-gcov --disable-shared --disable-threads --without-headers --prefix=/var/lib/laminar/run/gcc-microblaze-linux/1/toolchain-install using a recent master commit (1a87f8381085de50726634e8cb4a651c05b272b5) along with a recent GCC as $CXX. ...and then it's built with: make all-gcc [...] [all 2021-05-30 10:48:15] /usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o microblaze.o -MT microblaze.o -MMD -MP -MF ./.deps/microblaze.TPo ../../gcc/gcc/config/microblaze/microblaze.c [all 2021-05-30 10:48:18] ../../gcc/gcc/config/microblaze/microblaze.c: In function 'rtx_def* microblaze_legitimize_address(rtx, rtx, machine_mode)': [all 2021-05-30 10:48:18] ../../gcc/gcc/config/microblaze/microblaze.c:1105:11: error: 'reg' may be used uninitialized in this function [-Werror=maybe-uninitialized] [all 2021-05-30 10:48:18] 1105 | rtx reg; [all 2021-05-30 10:48:18] | ^~~ [all 2021-05-30 10:48:19] In file included from ../../gcc/gcc/rtl.h:3938, [all 2021-05-30 10:48:19] from ../../gcc/gcc/config/microblaze/microblaze.c:29: [all 2021-05-30 10:48:19] ./genrtl.h: In function 'bool microblaze_expand_move(machine_mode, rtx_def**)': [all 2021-05-30 10:48:19] ./genrtl.h:38:16: error: 'p1' may be used uninitialized in this function [-Werror=maybe-uninitialized] [all 2021-05-30 10:48:19]38 | XEXP (rt, 1) = arg1; [all 2021-05-30 10:48:19] ../../gcc/gcc/config/microblaze/microblaze.c:3415:15: note: 'p1' was declared here [all 2021-05-30 10:48:19] 3415 | rtx p0, p1, result, temp; [all 2021-05-30 10:48:19] | ^~ [all 2021-05-30 10:48:20] cc1plus: all warnings being treated as errors [all 2021-05-30 10:48:20] make[1]: *** [Makefile:2406: microblaze.o] Error 1 [all 2021-05-30 10:48:20] make[1]: Leaving directory '/var/lib/laminar/run/gcc-microblaze-linux/1/toolchain-build/gcc' [all 2021-05-30 10:48:20] make: *** [Makefile:4414: all-gcc] Error 2 [laminar] Executing cfg/after
[Bug c++/100835] New: defaulted equality gives wrong answer, if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100835
Bug ID: 100835
Summary: defaulted equality gives wrong answer, if constexpr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Short example:
struct B {
int i;
CONSTEXPR bool operator==(B const&) const = default;
};
struct D : B {
CONSTEXPR bool operator==(D const&) const = default;
};
static_assert(D{0} == D{5});
When compiled with -DCONSTEXPR=constexpr, the static assertion passes. When
compiled with -DCONSTEXPR=, the static assertion fails.
For some reason, when the equality operator is declared constexpr, there is
just no work that happens for doing equality. For instance, the function
bool check(D a, D b) {
return a == b;
}
compiles to:
check(D, D):
mov eax, 1
ret
progress update after initial GSoC virtual meetup
hello I was successfully able to build gcc with bootstrapping disabled and using xgcc directly from the build directory instead ( reducing the overall build time a lot, although it still takes about half an hour to build but it’s much faster than before ). Also I was also able to run one single test on the built compiler. Is there anything else I should be knowing to aid in development or should we start planing and preparing towards the project so that we can have a head start during coding phase ? Thanks, - Ankur
[Bug tree-optimization/100834] New: False positive of -Wstringop-overflow= with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100834
Bug ID: 100834
Summary: False positive of -Wstringop-overflow= with -Os
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: florian.bezdeka at siemens dot com
Target Milestone: ---
Compiling the testcase below with "gcc test.c" works, while "gcc -Os test.c"
produces a warning:
test.c: In function ‘main’:
test.c:59:9: warning: ‘memset’ writing 128 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]
59 | memset(_data->guest_regs, 0, sizeof(cpu_data->guest_regs));
| ^~
Tested gcc versions:
gcc 11.1.1 (Fedora 34): Affected
gcc 10.3.1 (Fedora 33): OK
gcc 10.2.1 (Debian 11): OK
test.c:
#include
#define PAGE_SIZE 4096
#define STACK_SIZE PAGE_SIZE
union registers {
struct {
unsigned long r15;
unsigned long r14;
unsigned long r13;
unsigned long r12;
unsigned long r11;
unsigned long r10;
unsigned long r9;
unsigned long r8;
unsigned long rdi;
unsigned long rsi;
unsigned long rbp;
unsigned long unused;
unsigned long rbx;
unsigned long rdx;
unsigned long rcx;
unsigned long rax;
};
unsigned long by_index[16];
};
struct per_cpu {
union {
/** Stack used while in hypervisor mode. */
unsigned char stack[STACK_SIZE];
struct {
unsigned char __fill[STACK_SIZE - sizeof(union
registers)];
/** Guest registers saved on stack during VM exit. */
union registers guest_regs;
};
};
} __attribute__((aligned(PAGE_SIZE)));
void *memset(void *s, int c, size_t n)
{
unsigned char *p = s;
while (n-- > 0)
*p++ = c;
return s;
}
static inline struct per_cpu *this_cpu_data(void)
{
return (struct per_cpu *) 0xdeadbeef;
}
int main(int argc, char **argv)
{
struct per_cpu *cpu_data = this_cpu_data();
memset(_data->guest_regs, 0, sizeof(cpu_data->guest_regs));
}
[Bug fortran/100816] Wrong span on widechar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100816 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-05-30 --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100818] A temporary is passed to associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-05-30 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100819] Wrong code generation with unlimited polymorphic objects and character type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100819 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-30 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100120] associated intrinsic failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100120 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100821] Deferred character with wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100821 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug libstdc++/100833] New: ranges::advance should return n when i == bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833
Bug ID: 100833
Summary: ranges::advance should return n when i == bound
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is specified in [range.iter.op.advance#7]:
"Returns: n - M, where M is the difference between the ending and starting
positions of i."
#include
constexpr auto diff = [] {
auto r = std::views::single(0) |
std::views::filter([](int) { return true; });
auto it = r.begin();
return std::ranges::advance(it, 100, r.begin());
}();
static_assert(diff == 100);
https://godbolt.org/z/6nh8xMWYd
