[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604 --- Comment #3 from YunQiang Su --- I got it. it is not due to gcc itself, while due to *stat problem in glibc 2.33 for MIPS64. It seems we introduce a bug when try to fix y2106 problem for mips64. I am try to dig it.
[Bug tree-optimization/90433] POINTER_DIFF_EXPR in vectorizer prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90433 --- Comment #3 from Marc Glisse --- (In reply to Andrew Pinski from comment #2) > The trunk we don't vectorize the code any more . I thought it might be because we found a way to use memcpy instead, which would have been good, but no, the vect dump shows an extremely common gcc issue missed: not vectorized: more than one data ref in stmt: MEM[(struct _Tuple_impl *)__cur_14].D.36092 = MEM[(struct _Tuple_impl &)__first_19].D.36092;
[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #66 from Arseny Solokha --- Should I file my commend 38 as a separate PR, then?
[Bug target/103515] Unexpected OPTION_MASK_SAVE_TOC_INDIRECT of rs6000_isa_flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515 --- Comment #4 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:01ad8c54fdca1db3d71bf6c4b861a9d1db3c2a59 commit r12-5920-g01ad8c54fdca1db3d71bf6c4b861a9d1db3c2a59 Author: Kewen Lin Date: Sun Dec 12 23:27:51 2021 -0600 pragma: Update target option node when optimization changes [PR103515] For a function with optimize pragma, it's possible that the target options change as optimization options change. Now we create one optimization option node when optimize pragma parsing, but don't create target option node for possible target option changes. It makes later processing not detect the target options can actually change and further doesn't update the target options accordingly. This patch is to check whether target options have changed when creating one optimization option node for pragma optimize, and make one target option node if needed. The associated test case shows the difference. Without this patch, the function foo1 will perform unrolling which is unexpected. The reason is that flag unroll_only_small_loops isn't correctly set for it. The value is updated after parsing function foo2, but doesn't get restored later since both decls don't have DECL_FUNCTION_SPECIFIC_TARGET set and the hook thinks we don't need to switch. With this patch, there is no unrolling for foo1, which is also consistent with the behavior by replacing pragma by attribute whether w/ and w/o this patch. As Martin noted, this change does the similar thing like what his previous commit r12-1039 did. gcc/ChangeLog: PR target/103515 * attribs.c (decl_attributes): Check if target options change and create one node if so. gcc/testsuite/ChangeLog: PR target/103515 * gcc.target/powerpc/pr103515.c: New test.
[Bug middle-end/98420] Invalid simplification of x - x with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98420 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > probably conditional on HONOR_SIGNED_ZEROS. That is checked now: + || (!tree_expr_maybe_nan_p (@0) + && !tree_expr_maybe_infinite_p (@0))) The part that is missed is the flag_rounding_math .
[Bug middle-end/95126] [9/10/11/12 Regression] Missed opportunity to turn static variables into immediates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=65408, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58744, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=36043 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > So this has to be a patch which was backported to the GCC 5 branch which > caused to produce even worse code. The patch which made the worse code was r6-52-g984b20545fee1 which was backported to the GCC 5 branch.
[Bug middle-end/95126] [9/10/11/12 Regression] Missed opportunity to turn static variables into immediates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Severity|normal |enhancement Summary|Missed opportunity to turn |[9/10/11/12 Regression] |static variables into |Missed opportunity to turn |immediates |static variables into ||immediates Target Milestone|--- |9.5 Known to work||5.1.0 Known to fail||5.2.0 --- Comment #2 from Andrew Pinski --- Hmm, in GCC 5.1.0 (and before) we used to produce: mov rdi, QWORD PTR s.1839[rip] jmp func In GCC 5.2.0 and above GCC produces: movzx edi, WORD PTR s.1839[rip+2] movzx edx, WORD PTR s.1839[rip] sal rdi, 16 mov rax, rdi movzx edi, WORD PTR s.1839[rip+4] or rax, rdx sal rdi, 32 or rdi, rax jmp func In both cases, the expander sees: : func (s); [tail call] return; But the expander goes bad. So this has to be a patch which was backported to the GCC 5 branch which caused to produce even worse code.
[Bug middle-end/91709] Missed optimization for multiplication on 1.5 and 1.25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91709
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #6 from Andrew Pinski ---
unsigned test(unsigned i) {
return i * 1.5;
}
[Bug middle-end/91739] Missed optimization for arithmetic operations of integers and floating point constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91739 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2019-09-12 00:00:00 |2021-12-12 --- Comment #2 from Andrew Pinski --- convert(32bit)*integerinfp -> 32bit*32bit widening multiple+converttofp . You might still end up with 2 conversions but integer multiples rather than fp multiplies as there is a rounding issue depending on how many bits are used in the integerinfp are done.
[Bug middle-end/60085] ICE in get_frame_type on weird code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60085 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98621 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > The testcase in comment #3 was spun out in PR 103679 Actually it was already filed as PR 98621.
[Bug c/98621] [9/10/11/12 Regression] ICE: x from g referenced in f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98621 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 103679 has been marked as a duplicate of this bug. ***
[Bug c/103679] ICE after error on nested function with VLA as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103679 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Except it is a dup of bug 98621. *** This bug has been marked as a duplicate of bug 98621 ***
[Bug c/30552] gcc crashes when compiling examples with GNU statement expressions in VLAs (also involved: nested functions declared K)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552 Andrew Pinski changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #14 from Andrew Pinski --- *** Bug 60085 has been marked as a duplicate of this bug. ***
[Bug middle-end/60085] ICE in get_frame_type on weird code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60085 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > The testcase in comment #0 started to be rejected in GCC 9. And that is a dup of bug 30552. So closing as such. *** This bug has been marked as a duplicate of bug 30552 ***
[Bug c/30552] gcc crashes when compiling examples with GNU statement expressions in VLAs (also involved: nested functions declared K)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/60085] ICE in get_frame_type on weird code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60085 Andrew Pinski changed: What|Removed |Added Known to fail||8.5.0 Known to work||10.1.0, 9.1.0 --- Comment #5 from Andrew Pinski --- The testcase in comment #0 started to be rejected in GCC 9. The testcase in comment #3 was spun out in PR 103679
[Bug c/103679] ICE after error on nested function with VLA as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103679 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=60085 --- Comment #1 from Andrew Pinski --- Note this was split out of bug 60085.
[Bug c/103679] New: ICE after error on nested function with VLA as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103679
Bug ID: 103679
Summary: ICE after error on nested function with VLA as
argument
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
void fn1 ()
{
void fnx ()
int n;
int a[n];
}
CUT ---
We currently have error messages and then some ICEs:
: In function 'fnx':
:7:1: error: expected declaration specifiers before '}' token
7 | }
| ^
:6:7: error: declaration for parameter 'a' but no such parameter
6 | int a[n];
| ^
:5:7: error: declaration for parameter 'n' but no such parameter
5 | int n;
| ^
:8: error: expected '{' at end of input
: In function 'fn1':
:7:1: error: expected declaration or statement at end of input
7 | }
| ^
:2:6: internal compiler error: n from fnx referenced in fn1
2 | void fn1 ()
| ^~~
[Bug middle-end/55217] False -Wstrict-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0 Keywords||needs-bisection --- Comment #7 from Andrew Pinski --- The diagnostic seems to be gone in GCC 8+.
[Bug tree-optimization/91019] Missed optimization on sequential memcpy calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91019 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-06-27 00:00:00 |2021-12-12 Severity|normal |enhancement
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 --- Comment #7 from Arseny Solokha --- > Arseny, does this properly diagnose the issue for you? Sure, thanks. But please note that I don't do any real computations on 32-bit powerpc. I've filed this series of PRs during my regular testing of the compiler.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625 --- Comment #6 from Kewen Lin --- (In reply to Bill Schmidt from comment #4) > Kewen, how did you confirm this? My cross doesn't accept -mvsx as valid. > > $ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 -mvsx pr103625.c > -B/home/wschmidt/gcc/build/gcc-e300/gcc > /home/wschmidt/gcc/build/gcc-e300/gcc/as: line 114: exec: -m: invalid option > exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...] I used the original command which doesn't specify -O2. I just confirmed that it's reproducible with that, just noticed that with O2 all seems optimized out, then it's going to invoke assembler (-S can make it silent).
[Bug tree-optimization/90433] POINTER_DIFF_EXPR in vectorizer prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90433 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- The trunk we don't vectorize the code any more .
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to sandra from comment #4) > The proposed fix in comment 2 looks OK to me, although I'd like to see a > comment here like > > "This case corresponds to an assumed-rank actual passed to a function > without an explicit interface, which is diagnosed in gfc_procedure_use." > > to explain what is going on. I no longer commit patches. Feel free to do whatever you want here; although, I think the comment is unwarranted.
[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604 YunQiang Su changed: What|Removed |Added CC||syq at debian dot org --- Comment #2 from YunQiang Su --- root@sid-mips64el:/build/gcc-12/gcc-12-12-20211211# /build/gcc-12/gcc-12-12-20211211/build/./gcc/gdc -B/build/gcc-12/gcc-12-12-20211211/build/./gcc/ -B/usr/mips64el-linux-gnuabi64/bin/ -B/usr/mips64el-linux-gnuabi64/lib/ -isystem /usr/mips64el-linux-gnuabi64/include -isystem /usr/mips64el-linux-gnuabi64/sys-include -isystem /build/gcc-12/gcc-12-12-20211211/build/sys-include -fno-checking -c -fno-druntime -nostdinc -I /build/gcc-12/gcc-12-12-20211211/src/libphobos/libdruntime -g -O2 xx.d read error: Success read error: Success d21: error: unable to read module 'xx' d21: note: Expected 'xx.d' or 'xx/package.d' in one of the following import paths: import path[0] = /build/gcc-12/gcc-12-12-20211211/src/libphobos/libdruntime
[Bug c++/103678] New: [concepts] Constrained partial specialization of dependent template conflicts with unconstrained partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103678
Bug ID: 103678
Summary: [concepts] Constrained partial specialization of
dependent template conflicts with unconstrained
partial specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matthewjbarichello at gmail dot com
Target Milestone: ---
Reduced example:
template
struct A {
template
struct B;
};
template
template
struct A::B {};
template
template
requires requires {
typename B_t;
}
struct A::B {};
Cmdline:
g++ -std=c++20 example.cpp
Expected behaviour:
Example compiles. The partial specialization defined on line 16 should be a
distinct partial specialization as it is more constrained than the base
template and the partial specialization on line 9.
Actual behaviour:
Example does not compile and compiler emits the following diagnostic:
:16:16: error: redefinition of 'struct A<
>::B'
16 | struct A::B {};
|^~
:9:16: note: previous definition of 'struct A<
>::B'
9 | struct A::B {};
|^~
Affected versions:
GCC 10 through 12.
Notes:
- Compiles fine on Clang and MSVC.
- Only seems to happen for partially specialized dependent templates, as the
following code compiles without an error:
template
struct A;
template
struct A {};
template
requires requires {
typename A_t;
}
struct A {};
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- The proposed fix in comment 2 looks OK to me, although I'd like to see a comment here like "This case corresponds to an assumed-rank actual passed to a function without an explicit interface, which is diagnosed in gfc_procedure_use." to explain what is going on.
[Bug tree-optimization/88569] Track relations between variable values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88569 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/88603] optimization missed for saturation arithmetic add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88603
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from Andrew Pinski ---
I think this gives the best code really:
uint32_t saturation_add1(uint32_t a, uint32_t b)
{
uint32_t t;
if (__builtin_add_overflow (a, b, ))
return UINT32_MAX;
return t;
}
That is recognizing:
_1 = (long unsigned int) a_4(D);
_2 = (long unsigned int) b_5(D);
tmp_6 = _1 + _2;
if (tmp_6 > 4294967295)
As:
_6 = .ADD_OVERFLOW (a_4(D), b_5(D));
_2 = IMAGPART_EXPR <_6>;
if (_2 != 0)
[Bug tree-optimization/87576] Static analysis generating errors on branch never taken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87576 Andrew Pinski changed: What|Removed |Added Known to fail||11.2.0 --- Comment #4 from Andrew Pinski --- The warning seems to be have fixed on the trunk but I could not understand why though.
[Bug bootstrap/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #12 from Andrew Pinski --- You don't have the sysroot setup or anything. Cross compiling to darwin is not for the faint of heart and really this is not the place to get help doing it.
[Bug bootstrap/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 Andrew Pinski changed: What|Removed |Added Component|libgcc |bootstrap --- Comment #11 from Andrew Pinski --- Cross compiling to darwin is going to be hard these days.
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #10 from cqwrteur --- (In reply to Andrew Pinski from comment #4) > configure:13965: checking for as > configure:13998: result: no > configure:14076: checking for x86_64-apple-darwin20.6.0-as > configure:14106: result: no > ... > > configure:14425: checking for dsymutil > configure:14458: result: no > configure:14536: checking for x86_64-apple-darwin20.6.0-dsymutil > configure:14566: result: no > configure:14655: checking for ld > configure:14688: result: no > configure:14766: checking for x86_64-apple-darwin20.6.0-ld > configure:14796: result: no > configure:14885: checking for lipo > configure:14918: result: no > configure:14996: checking for x86_64-apple-darwin20.6.0-lipo > configure:15026: result: no > ... > configure:15805: checking for otool > configure:15838: result: no > configure:15916: checking for x86_64-apple-darwin20.6.0-otool > configure:15946: result: no > > > Darwin's as is special, in that it is the one from LLVM. > Darwin's ld (and dsymutl, lipo, and otool) is from cctools but you don't > have that installed either.
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #9 from cqwrteur --- Created attachment 51987 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51987=edit status
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #8 from cqwrteur --- Created attachment 51986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51986=edit new config.log Still does not work
[Bug tree-optimization/87543] Inconsistency in noticing a constant result rather than emitting code for a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87543 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97077 --- Comment #4 from Andrew Pinski --- PR 97077 has a similar issue.
[Bug tree-optimization/87543] Inconsistency in noticing a constant result rather than emitting code for a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87543 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/86341] Aggressive loop unrolling in gcc 7.x produces out-of-bounds index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86341 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- Hmm, even though we still unroll the same in GCC 8/9/10/11, we don't warn about: _50 = MEM[(const int *)].items[3]; Though on the trunk we do the correct thing and don't unroll the loop past the bounds and don't produce the [3] load.
[Bug tree-optimization/86628] Missed simplification of division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2018-07-23 00:00:00 |2021-12-12 --- Comment #7 from Andrew Pinski --- Note -fwrapv is able to detect the multiply because we can association when dealing with wrapping case.
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #7 from cqwrteur --- (In reply to Andrew Pinski from comment #4) > configure:13965: checking for as > configure:13998: result: no > configure:14076: checking for x86_64-apple-darwin20.6.0-as > configure:14106: result: no > ... > > configure:14425: checking for dsymutil > configure:14458: result: no > configure:14536: checking for x86_64-apple-darwin20.6.0-dsymutil > configure:14566: result: no > configure:14655: checking for ld > configure:14688: result: no > configure:14766: checking for x86_64-apple-darwin20.6.0-ld > configure:14796: result: no > configure:14885: checking for lipo > configure:14918: result: no > configure:14996: checking for x86_64-apple-darwin20.6.0-lipo > configure:15026: result: no > ... > configure:15805: checking for otool > configure:15838: result: no > configure:15916: checking for x86_64-apple-darwin20.6.0-otool > configure:15946: result: no > > > Darwin's as is special, in that it is the one from LLVM. > Darwin's ld (and dsymutl, lipo, and otool) is from cctools but you don't > have that installed either. cqwrteur@Home-Server:~/cross/x86_64-apple-darwin/bin$ ln -s /usr/local/bin/dsymutil x86_64-apple-darwin-dsymutil cqwrteur@Home-Server:~/cross/x86_64-apple-darwin/bin$ ls -l total 8404 -rwxr-xr-x 1 cqwrteur cqwrteur 558880 Dec 12 19:39 x86_64-apple-darwin-addr2line -rwxr-xr-x 2 cqwrteur cqwrteur 591488 Dec 12 19:39 x86_64-apple-darwin-ar lrwxrwxrwx 1 cqwrteur cqwrteur 22 Dec 12 19:56 x86_64-apple-darwin-as -> /usr/local/bin/llvm-as -rwxr-xr-x 1 cqwrteur cqwrteur 554240 Dec 12 19:39 x86_64-apple-darwin-c++filt lrwxrwxrwx 1 cqwrteur cqwrteur 23 Dec 12 19:58 x86_64-apple-darwin-dsymutil -> /usr/local/bin/dsymutil -rwxr-xr-x 1 cqwrteur cqwrteur 39720 Dec 12 19:39 x86_64-apple-darwin-elfedit lrwxrwxrwx 1 cqwrteur cqwrteur 21 Dec 12 19:56 x86_64-apple-darwin-ld -> /usr/local/bin/ld.lld lrwxrwxrwx 1 cqwrteur cqwrteur 24 Dec 12 19:57 x86_64-apple-darwin-lipo -> /usr/local/bin/llvm-lipo -rwxr-xr-x 2 cqwrteur cqwrteur 576120 Dec 12 19:39 x86_64-apple-darwin-nm -rwxr-xr-x 2 cqwrteur cqwrteur 702072 Dec 12 19:39 x86_64-apple-darwin-objcopy -rwxr-xr-x 2 cqwrteur cqwrteur 2180408 Dec 12 19:39 x86_64-apple-darwin-objdump lrwxrwxrwx 1 cqwrteur cqwrteur 25 Dec 12 19:57 x86_64-apple-darwin-otool -> /usr/local/bin/llvm-otool -rwxr-xr-x 2 cqwrteur cqwrteur 591488 Dec 12 19:39 x86_64-apple-darwin-ranlib -rwxr-xr-x 2 cqwrteur cqwrteur 961216 Dec 12 19:39 x86_64-apple-darwin-readelf -rwxr-xr-x 1 cqwrteur cqwrteur 558616 Dec 12 19:39 x86_64-apple-darwin-size -rwxr-xr-x 1 cqwrteur cqwrteur 562880 Dec 12 19:39 x86_64-apple-darwin-strings -rwxr-xr-x 2 cqwrteur cqwrteur 702072 Dec 12 19:39 x86_64-apple-darwin-strip I just manually set symlink to llvm in the sysroot/bin. Would that work?
[Bug tree-optimization/82135] Missed constant propagation through possible unsigned wraparound, with std::align() variable pointer, constant everything else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82135 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2017-09-12 00:00:00 |2021-12-12
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #6 from cqwrteur --- (In reply to Andrew Pinski from comment #4) > configure:13965: checking for as > configure:13998: result: no > configure:14076: checking for x86_64-apple-darwin20.6.0-as > configure:14106: result: no > ... > > configure:14425: checking for dsymutil > configure:14458: result: no > configure:14536: checking for x86_64-apple-darwin20.6.0-dsymutil > configure:14566: result: no > configure:14655: checking for ld > configure:14688: result: no > configure:14766: checking for x86_64-apple-darwin20.6.0-ld > configure:14796: result: no > configure:14885: checking for lipo > configure:14918: result: no > configure:14996: checking for x86_64-apple-darwin20.6.0-lipo > configure:15026: result: no > ... > configure:15805: checking for otool > configure:15838: result: no > configure:15916: checking for x86_64-apple-darwin20.6.0-otool > configure:15946: result: no > > > Darwin's as is special, in that it is the one from LLVM. > Darwin's ld (and dsymutl, lipo, and otool) is from cctools but you don't > have that installed either. cqwrteur@Home-Server:~/myhome/gcc_build/cross/x86_64-apple-darwin/gcc$ which dsymutil /usr/local/bin/dsymutil
[Bug tree-optimization/70455] spurious "assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70455 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0 Keywords||needs-bisection Known to work||8.1.0 --- Comment #8 from Andrew Pinski --- Seems to be fixed in GCC 8+.
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #5 from cqwrteur --- (In reply to Andrew Pinski from comment #4) > configure:13965: checking for as > configure:13998: result: no > configure:14076: checking for x86_64-apple-darwin20.6.0-as > configure:14106: result: no > ... > > configure:14425: checking for dsymutil > configure:14458: result: no > configure:14536: checking for x86_64-apple-darwin20.6.0-dsymutil > configure:14566: result: no > configure:14655: checking for ld > configure:14688: result: no > configure:14766: checking for x86_64-apple-darwin20.6.0-ld > configure:14796: result: no > configure:14885: checking for lipo > configure:14918: result: no > configure:14996: checking for x86_64-apple-darwin20.6.0-lipo > configure:15026: result: no > ... > configure:15805: checking for otool > configure:15838: result: no > configure:15916: checking for x86_64-apple-darwin20.6.0-otool > configure:15946: result: no > > > Darwin's as is special, in that it is the one from LLVM. > Darwin's ld (and dsymutl, lipo, and otool) is from cctools but you don't > have that installed either. wait. I do have that install from llvm. how do i use that?
[Bug tree-optimization/80937] redundant bcopy/memcpy/strcpy to a non-local object not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80937 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-13 Severity|normal |enhancement Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/80215] VN has trouble with conditional equivalences (DOM/FRE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80215 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-13 --- Comment #1 from Andrew Pinski --- Confirmed. bar can be optimized at the RTL level which I find interesting. Neither bar nor baz can be optimized by clang.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 Antoni changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Antoni --- Fixed in master.
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- configure:13965: checking for as configure:13998: result: no configure:14076: checking for x86_64-apple-darwin20.6.0-as configure:14106: result: no ... configure:14425: checking for dsymutil configure:14458: result: no configure:14536: checking for x86_64-apple-darwin20.6.0-dsymutil configure:14566: result: no configure:14655: checking for ld configure:14688: result: no configure:14766: checking for x86_64-apple-darwin20.6.0-ld configure:14796: result: no configure:14885: checking for lipo configure:14918: result: no configure:14996: checking for x86_64-apple-darwin20.6.0-lipo configure:15026: result: no ... configure:15805: checking for otool configure:15838: result: no configure:15916: checking for x86_64-apple-darwin20.6.0-otool configure:15946: result: no Darwin's as is special, in that it is the one from LLVM. Darwin's ld (and dsymutl, lipo, and otool) is from cctools but you don't have that installed either.
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #3 from cqwrteur --- Created attachment 51985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51985=edit config.log
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #2 from cqwrteur --- Created attachment 51984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51984=edit error
[Bug libgcc/103677] cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 --- Comment #1 from cqwrteur --- Created attachment 51983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51983=edit config.log
[Bug tree-optimization/61747] min,max pattern not always properly optimized (for sse4 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed||2021-12-13 Status|UNCONFIRMED |NEW --- Comment #6 from Andrew Pinski --- Confirmed.
[Bug libgcc/103677] New: cross compile apple darwin from linux. cannot compute suffix of object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103677 Bug ID: 103677 Summary: cross compile apple darwin from linux. cannot compute suffix of object files Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- checking for x86_64-apple-darwin20.6.0-gcc... /home/cqwrteur/myhome/gcc_build/cross/x86_64-apple-darwin20.6.0/gcc/./gcc/xgcc -B/home/cqwrteur/myhome/gcc_build/cross/x86_64-apple-darwin20.6.0/gcc/./gcc/ -B/home/cqwrteur/cross/x86_64-apple-darwin20.6.0/x86_64-apple-darwin20.6.0/bin/ -B/home/cqwrteur/cross/x86_64-apple-darwin20.6.0/x86_64-apple-darwin20.6.0/lib/ -isystem /home/cqwrteur/cross/x86_64-apple-darwin20.6.0/x86_64-apple-darwin20.6.0/include -isystem /home/cqwrteur/cross/x86_64-apple-darwin20.6.0/x86_64-apple-darwin20.6.0/sys-include checking for suffix of object files... configure: error: in `/home/cqwrteur/myhome/gcc_build/cross/x86_64-apple-darwin20.6.0/gcc/x86_64-apple-darwin20.6.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details make[1]: *** [Makefile:15260: configure-target-libgcc] Error 1 make[1]: Leaving directory '/home/cqwrteur/myhome/gcc_build/cross/x86_64-apple-darwin20.6.0/gcc' make: *** [Makefile:991: all] Error 2
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 41464, which changed state. Bug 41464 Summary: vector loads are unnecessarily split into high and low loads https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.9.0
Known to work||4.9.0
Known to fail||4.4.7, 4.5.3, 4.7.1, 4.8.1,
||4.8.5
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #10 from Andrew Pinski ---
4.8.5 did:
movaps xmm0, xmm1
add ecx, 1
movlps xmm0, QWORD PTR [rdi+rax]
movhps xmm0, QWORD PTR [rdi+8+rax]
mulps xmm0, xmm2
movlps QWORD PTR [rsi+rax], xmm0
movhps QWORD PTR [rsi+8+rax], xmm0
But 4.9.0 has:
movaps xmm0, XMMWORD PTR [rbp+0+r9]
add r10d, 1
mulps xmm0, xmm1
movups XMMWORD PTR [rax+r9], xmm0
So all fixed for GCC 4.9.0.
4.9.0
vect__11.13_94 = MEM[base: vectp_i.12_90, index: ivtmp.28_28, offset: 0B];
vect__12.14_96 = vect__11.13_94 * { 3.1415927410125732421875e+0,
3.1415927410125732421875e+0, 3.1415927410125732421875e+0,
3.1415927410125732421875e+0 };
MEM[base: vectp_f.17_97, index: ivtmp.28_28, offset: 0B] = vect__12.14_96;
[Bug tree-optimization/103660] Sub-optimal code with relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103660 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-12 CC||pinskia at gcc dot gnu.org Status|UNCONFIRMED |NEW Severity|normal |enhancement Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- For min3/min4: _3 = a_7(D) < b_8(D) ? a_7(D) : 0; _6 = a_7(D) >= b_8(D) ? b_8(D) : 0; _9 = _3 | _6; A pattern like: (for op (add bit_ior) (simplify (op:c (cond (lt @0 @1) @0 integer_zero_p@2) (cond (ge @0 @1) @0 @2)) (min @0 @1))) And make one for the others too. min5/6 is more complex: min5: _1 = a_5(D) < b_6(D); c_7 = (const int) _1; _2 = a_5(D) * c_7; _3 = 1 - c_7; _4 = _3 * b_6(D); _8 = _2 + _4; min6: _5 = a_1(D) < b_2(D); _6 = (int) _5; _7 = a_1(D) * _6; _8 = a_1(D) >= b_2(D); _9 = (int) _8; _10 = b_2(D) * _9; _11 = _7 + _10; I think I have a patch which helps these, I have to finish it up and then it goes back to min3/min4 issue.
[Bug target/103676] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #4 from Patrick Oppenlander --- It's open source, but probably a bit of work to reproduce. I'll see if I can produce a reduced testcase. Thanks for the link to the instructions.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 --- Comment #5 from Segher Boessenkool --- It should work for 32-bit though?
[Bug target/103676] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #3 from Patrick Oppenlander --- gcc -v output is: % armv7em-linux-musleabihf-g++ -v Using built-in specs. COLLECT_GCC=armv7em-linux-musleabihf-g++ COLLECT_LTO_WRAPPER=/opt/cross/armv7em-linux-musleabihf/bin/../libexec/gcc/armv7em-linux-musleabihf/11.2.0/lto-wrapper Target: armv7em-linux-musleabihf Configured with: ../src_gcc/configure --enable-languages=c,c++ --with-float=hard CFLA GS='-g0 -Os' CXXFLAGS='-g0 -Os' LDFLAGS=-s --disable-nls --with-debug-prefix-map=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf= --enable-languages=c,c++ --disable-libquadmath --disable-decimal-float --with-arch=armv7e-m --with-fpu=fpv5-d16 --enable-default-pie --enable-cxx-flags=-ffunction-sections --disable-bootstrap --disable-assembly --disable-werror --target=armv7em-linux-musleabihf --prefix= --libdir=/lib --disable-multilib --with-sysroot=/armv7em-linux-musleabihf --enable-tls --disable-libmudflap --disable-libsanitizer --disable-gnu-indirect-function --disable-libmpx --enable-initfini-array --enable-libstdcxx-time=rt --with-build-sysroot=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_sysroot AR_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/binutils/ar AS_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/gas/as-new LD_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/ld/ld-new NM_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/binutils/nm-new OBJCOPY_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/binutils/objcopy OBJDUMP_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/binutils/objdump RANLIB_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/binutils/ranlib READELF_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/binutils/readelf STRIP_FOR_TARGET=/tmp/makepkg/armv7em-linux-musleabihf/src/musl-cross-make/build/local/armv7em-linux-musleabihf/obj_binutils/binutils/strip-new --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (GCC)
[Bug target/103676] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > If it is private software you might want to read > https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs and > try to reduce the sources yourself. Otherwise reporting the exact version of the source you used, for both the open source software and GCC. For GCC you can provide the output of "armv7em-linux-musleabihf-g++ -v" as a start.
[Bug target/103676] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-12 Target||armv7em-linux-musleabihf Keywords||ice-on-valid-code, ||inline-asm, lto Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- This is rather interesting as usually inline asm would not cause an unrecognizable insn error. >I'm not quite sure how to provide more information. The first thing you could do is say if this is private software or open source. If it is private software you might want to read https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs and try to reduce the sources yourself.
[Bug middle-end/103670] Incorrect optimization of loop termination: Early exit with any optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103670 --- Comment #4 from Andrew Pinski --- Please read https://gcc.gnu.org/bugs/. A code snippet is not what we want. We need a full compilable (not always runable) testcase for wrong code.
[Bug middle-end/103670] Incorrect optimization of loop termination: Early exit with any optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103670 --- Comment #3 from Robert M. Münch --- I updated to GCC 11.2, which has the same problem but after 4 rounds, not 3. GCC 10.3 Output: 9512] ==> GetAdapterMACAddress [9512] parameter check dwRetVal: 0 number: 0 [9512] AddressLenth: 6 [9512] i: 0 offset: 0, AddressLenth: 6 [9512] i: 1 offset: 3, AddressLenth: 6 [9512] i: 2 offset: 6, AddressLenth: 6 [9512] <- OK: 00-1C-42- AddressLength: 3 GCC 11.2 Output: [7128] ==> GetAdapterMACAddress [7128] parameter check dwRetVal: 0 number: 0 [7128] AddressLenth: 6 [7128] i: 0 offset: 0, AddressLenth: 6 [7128] i: 1 offset: 3, AddressLenth: 6 [7128] i: 2 offset: 6, AddressLenth: 6 [7128] i: 3 offset: 9, AddressLenth: 6 [7128] <- OK: 00-1C-42-10- AddressLength: 4
[Bug middle-end/103670] Incorrect optimization of loop termination: Early exit with any optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103670
--- Comment #2 from Robert M. Münch ---
That's the code snippet. The for(...) loop is where things start to become
strange.
The thing is, if we use the code from a pure C program, it works. We are using
this code from a Windows DLL which we call via an FFI from an interpreter.
However, omitting any optimization makes it work.
if (pAdapter != NULL) {
int i = 0;
int offset = 0;
// loop for as many bytes as given by the address length
// sprintf returns num char written, take: out buffer, max size of buffer,
format, ...
// format: %[flags][width][.precision][size]type
// .2 = two characters
// type X = Unsigned hexadecimal integer; uses "ABCDEF"
// %.2X
LOG(" AddressLenth: %i", pAdapter->AddressLength); // MAC-48 = 48 bit, 6
bytes, 6 two char blocks
LOG(" mac: %.12X", pAdapter->Address);
for (i = 0; i < pAdapter->AddressLength; i++) {
LOG(" i: %i offset: %i, AddressLenth: %i", i, offset,
pAdapter->AddressLength);
// omit outputting the - char for the last byte
if (i == (pAdapter->AddressLength - 1)) {
LOG("%s", " finalizing MAC address buidling");
offset += sprintf_s(MacAddress + offset, MAX_ADAPTER_ADDRESS_LENGTH,
"%02X",pAdapter->Address[i]);
} else {
offset += sprintf_s(MacAddress + offset, MAX_ADAPTER_ADDRESS_LENGTH,
"%02X-",pAdapter->Address[i]);
}
}
LOG("<- OK: %s AddressLength: %i", MacAddress, i);
return MacAddress;
}
[Bug target/103676] New: internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
Bug ID: 103676
Summary: internal compiler error: in extract_constrain_insn, at
recog.c:2671
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.oppenlander at gmail dot com
Target Milestone: ---
Hi,
I'm encountering this internal compiler error with gcc 11.2.0. I'm not quite
sure how to provide more information.
armv7em-linux-musleabihf-g++ -mcpu=cortex-m7 -mthumb -g -pipe -Wall -O2 -flto
-Wframe-larger-than=384 -fno-pie -masm-syntax-unified -mslow-flash-data
-Wframe-larger-than=384 -Wundef -fno-pie -masm-syntax-unified
-mslow-flash-data -nostdinc++ -fno-exceptions -std=gnu++20 -DKERNEL
-D_GNU_SOURCE -fuse-linker-plugin -fno-use-cxa-atexit -o apex/sys/apex.elf
-T/home/patrick/src/apex-examples/apex/sys/arch/arm/kernel.ld
apex/sys/fs/mount.o apex/sys/fs/pipe.o apex/sys/fs/syscalls.o
apex/sys/fs/util/dirbuf_add.o apex/sys/fs/vfs.o apex/sys/fs/vnode.o
apex/sys/kern/clone.o apex/sys/kern/debug.o apex/sys/kern/dma.o
apex/sys/kern/elf_load.o apex/sys/kern/exec.o apex/sys/kern/irq.o
apex/sys/kern/main.o apex/sys/kern/prctl.o apex/sys/kern/proc.o
apex/sys/kern/sch.o apex/sys/kern/sig.o apex/sys/kern/syscall_table.o
apex/sys/kern/syscalls.o apex/sys/kern/syslog.o apex/sys/kern/task.o
apex/sys/kern/thread.o apex/sys/kern/timer.o apex/sys/lib/crypto/sha256.o
apex/sys/lib/errno.o apex/sys/lib/jhash3.o apex/sys/lib/queue.o
apex/sys/lib/raise.o apex/sys/lib/string_utils.o apex/sys/mem/access.o
apex/sys/mem/kmem.o apex/sys/mem/page.o apex/sys/mem/vm.o apex/sys/sync/cond.o
apex/sys/sync/futex.o apex/sys/sync/mutex.o apex/sys/sync/rwlock.o
apex/sys/sync/semaphore.o apex/sys/sync/spinlock.o apex/sys/mem/untranslated.o
apex/sys/fs/arfs/vnops.o apex/sys/fs/devfs/vnops.o apex/sys/fs/ramfs/vfsops.o
apex/sys/fs/ramfs/vnops.o apex/sys/dev/arm/armv7m-systick/armv7m-systick.o
apex/sys/dev/arm/mps2-uart/early.o apex/sys/dev/arm/mps2-uart/mps2-uart.o
apex/sys/dev/bootdisk/bootdisk.o apex/sys/dev/console/console.o
apex/sys/dev/null/null.o apex/sys/dev/zero/zero.o apex/sys/dev/tty/tty.o
apex/sys/dev/block/device.o apex/sys/arch/arm/v7em/arch.o
apex/sys/arch/arm/v7em/atomic.o apex/sys/arch/arm/v7em/cache.o
apex/sys/arch/arm/v7em/context.o apex/sys/arch/arm/v7em/emulate.o
apex/sys/arch/arm/v7em/exception.o apex/sys/arch/arm/v7em/interrupt.o
apex/sys/arch/arm/v7em/io.o apex/sys/arch/arm/v7em/locore.o
apex/sys/arch/arm/v7em/syscall.o apex/sys/arch/arm/v7em/mpu.o
custom_driver/custom_driver.o apex/machine/qemu/arm/mps2-an500/sys/machine.o
apex/libc++/libc++.a apex/libcxxrt/libcxxrt.a apex/libc/libc.a
/opt/cross/armv7em-linux-musleabihf/lib/gcc/armv7em-linux-musleabihf/11.2.0/libgcc.a
-Wl,--gc-sections -z max-page-size=32 -nostartfiles -nostdlib -static -no-pie
/home/patrick/src/apex-examples/apex/sys/kern/timer.cpp: In function
'timer_callout':
/home/patrick/src/apex-examples/apex/sys/kern/timer.cpp:210:1: error:
unrecognizable insn:
210 | }
| ^
(insn 92 211 102 6 (parallel [
(set (reg:DI 7 r7 [orig:136 tmp ] [136])
(asm_operands/v:DI ("ldrd %Q0, %R0, %1
") ("=lh") 0 [
(mem/v/c:DI (reg/f:SI 1 r1 [137]) [16 MEM[(const
volatile uint64_t *)]+0 S8 A64])
]
[
(asm_input:DI ("m")
/home/patrick/src/apex-examples/apex/sys/arch/arm/v7em/atomic.cpp:24)
]
[]
/home/patrick/src/apex-examples/apex/sys/arch/arm/v7em/atomic.cpp:24))
(clobber (mem:BLK (scratch) [0 A8]))
])
"/home/patrick/src/apex-examples/apex/sys/arch/arm/v7em/atomic.cpp":24:2 -1
(nil))
during RTL pass: postreload
/home/patrick/src/apex-examples/apex/sys/kern/timer.cpp:210:1: internal
compiler error: in extract_constrain_insn, at recog.c:2671
0xff3469 internal_error(char const*, ...)
???:0
0x5d22e2 fancy_abort(char const*, int, char const*)
???:0
0x5d1ded _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x5d1e10 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0x8a659a extract_constrain_insn(rtx_insn*)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/99256] ICE in variable_check, at fortran/check.c:1012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99256
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
We could get approximate locus info with e.g.
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index 3682f9ae21f..78dfdbe7c92 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -5108,6 +5108,15 @@ gfc_intrinsic_sub_interface (gfc_code *c, int
error_flag)
if (!do_ts29113_check (isym, c->ext.actual))
goto fail;
+ gfc_actual_arglist *actual;
+ for (actual = c->ext.actual; actual; actual = actual->next)
+if (actual->label)
+ {
+ gfc_error ("Label %d not allowed as argument of intrinsic %qs at %L",
+ actual->label->value, name, >loc);
+ goto fail;
+ }
+
if (isym->check.f1 != NULL)
{
if (!do_check (isym, c->ext.actual))
which regtests ok.
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #30 from Mikael Morin --- *** Bug 103671 has been marked as a duplicate of this bug. ***
[Bug fortran/103671] arrays with negative strides are wrongly passed as argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103671 Mikael Morin changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Mikael Morin --- Well, I thought there was an independent problem, but on closer look, it seems to be the same as the original. *** This bug has been marked as a duplicate of bug 102043 ***
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #9 from CVS Commits --- The master branch has been updated by Antoni Boucher : https://gcc.gnu.org/g:0b52083ea2c2dd9897031fdc3802a68fd4aa45ef commit r12-5917-g0b52083ea2c2dd9897031fdc3802a68fd4aa45ef Author: Antoni Boucher Date: Sun Dec 12 16:16:21 2021 -0500 libgccjit: Add support for setting the link section of global variables [PR100688] 2021-12-12 Antoni Boucher gcc/jit/ PR target/100688 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_18): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_lvalue_set_link_section. * jit-playback.h: New function (set_link_section). * jit-recording.c: New function (set_link_section) and support for setting the link section. * jit-recording.h: New function (set_link_section) and new field m_link_section. * libgccjit.c: New function (gcc_jit_lvalue_set_link_section). * libgccjit.h: New function (gcc_jit_lvalue_set_link_section). * libgccjit.map (LIBGCCJIT_ABI_18): New ABI tag. gcc/testsuite/ PR target/100688 * jit.dg/all-non-failing-tests.h: Mention new test link-section-assembler. * jit.dg/test-link-section-assembler.c: New test. * jit.dg/jit.exp: New helper function to test that the assembly contains a pattern.
[Bug middle-end/103670] Incorrect optimization of loop termination: Early exit with any optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103670 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-12 Status|UNCONFIRMED |WAITING Keywords||wrong-code Ever confirmed|0 |1 Component|c |middle-end
[Bug tree-optimization/90447] Missed opportunities to use adc (worse when -1 is involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90447 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-12 Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- 0: works -1: works on the trunk 1: f2 still has an issue. -2: f2 still has an issue. Confirmed.
[Bug fortran/103606] [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297 since r9-3324-g2b03b800d866d345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103606 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ce80f2c0e7a86e555201e9e61a26306adff4a074 commit r11-9378-gce80f2c0e7a86e555201e9e61a26306adff4a074 Author: Harald Anlauf Date: Fri Dec 10 22:41:24 2021 +0100 Fortran: fix checking of elemental functions of type CLASS gcc/fortran/ChangeLog: PR fortran/103606 * resolve.c (resolve_fl_procedure): Do not access CLASS components before class container has been built. gcc/testsuite/ChangeLog: PR fortran/103606 * gfortran.dg/pr103606.f90: New test. (cherry picked from commit 7e913caad081ea85da4f257265f2d3383cdbe8d5)
[Bug c++/103668] constexpr std::vector not working as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103668 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Wakely --- Ah yes, Jakub is right.
[Bug ipa/103669] [12 Regression] wrong code with -O --param=modref-max-depth=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103669 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/103472] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:4527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-12-12 Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #1) > We could workaround it by replacing warnings with errors. > Are there cases where we do want warnings, not errors? I would consider the testcase as invalid, so an error appears ok. But technically the lower bound of a is 1 and upper bound is 0, so the error message is a bit misleading. E.g. NAG gives: Error: pr103472-z1.f90, line 2: First subscript (1) is greater than upper bound (0) for array A
[Bug target/103675] New: gather is a loss for floats and win for doubles at zen3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103675 Bug ID: 103675 Summary: gather is a loss for floats and win for doubles at zen3 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Currently we disable gather on zen1/2 and enable it for zen3. This was based on testing I did before Richard's code for open coding it. Testing the only kernels using gather in zen3 with double I get: jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=use_gather jh@ryzen3:~/tsvc/src> ./a.out LoopTime(sec) Checksum s3527.529 1.644903 s41121.317 1127072.247160 s41141.377 32000.000684 s41151.250 1.038812 s41160.873 0.753265 s41171.283 32002.208699 s41210.583 196490.281734 jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=^use_gather jh@ryzen3:~/tsvc/src> ./a.out LoopTime(sec) Checksum s3527.618 1.644903 s41121.223 1127072.247160 s41141.523 32000.000684 s41152.019 1.038812 s41161.531 0.753265 s41171.388 32002.208699 s41210.549 196490.281734 So it using gather is a win. For floats I get: jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=use_gather ; ./a.out LoopTime(sec) Checksum s3527.419 1.644808 s41121.183 1127128.875000 s41141.198 32000.00 s41151.056 1.038788 s41160.817 0.753265 s41171.179 32002.205078 s41210.264 196500.265625 jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=^use_gather ; ./a.out LoopTime(sec) Checksum s3527.435 1.644808 s41120.742 1127128.875000 s41141.078 32000.00 s41150.673 1.038788 s41160.532 0.753264 s41171.044 32002.205078 s41210.266 196500.265625 so using gather is loss. For long I get: jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=use_gather ; ./a.out LoopTime(sec) Checksum s3524.327 1.00 s41121.576 132000.00 s41141.603 32000.00 s41151.453 0.00 s41161.131 0.00 s41171.432 32001.00 s41210.629 132000.00 jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=^use_gather ; ./a.out LoopTime(sec) Checksum s3524.532 1.00 s41121.630 132000.00 s41141.808 32000.00 s41151.431 0.00 s41161.130 0.00 s41171.646 32001.00 s41210.638 132000.00 so gather is a win For int I get: jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=use_gather ; ./a.out LoopTime(sec) Checksum s3521.345 1.00 s41121.057 132000.00 s41141.095 32000.00 s41151.055 0.00 s41160.817 0.00 s41171.022 32001.00 s41210.266 132000.00 jh@ryzen3:~/tsvc/src> ~/trunk-install/bin/gcc tsvc.c -Ofast -march=native common.c dummy.c -lm -mtune-ctrl=^use_gather ; ./a.out LoopTime(sec) Checksum s3521.345 1.00 s41120.730 132000.00 s41141.089 32000.00 s41150.679 0.00 s41160.528 0.00 s41171.013 32001.00 s41210.262 132000.00 so gather is a loss. So i suppose we want to disable gathers for 32bit and smaller datatypes?
[Bug tree-optimization/103674] New: Poor codegen for C++ casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103674
Bug ID: 103674
Summary: Poor codegen for C++ casts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Compiling:
struct a {int a;};
struct b {int b;};
struct c : a, b {};
int
test(struct c *c)
{
struct b *b=c;
return b->b;
}
with -O2 leads to:
.text
.LHOTB0:
.p2align 4
.globl _Z4testP1c
.type _Z4testP1c, @function
_Z4testP1c:
.LFB0:
.cfi_startproc
testq %rdi, %rdi
je .L2
movl4(%rdi), %eax
ret
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.type _Z4testP1c.cold, @function
_Z4testP1c.cold:
.LFSB0:
.L2:
movl0, %eax
ud2
.cfi_endproc
.LFE0:
while clang does:
_Z4testP1c: # @_Z4testP1c
.cfi_startproc
# %bb.0:
leaq4(%rdi), %rax
testq %rdi, %rdi
cmoveq %rdi, %rax
movl(%rax), %eax
retq
And so does gcc 4.8.5:
test(c*):
leaq4(%rdi), %rdx
xorl%eax, %eax
testq %rdi, %rdi
cmovne %rdx, %rax
movl(%rax), %eax
ret
So this is technically a regression.
[Bug c/103670] Incorrect optimization of loop termination: Early exit with any optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103670 --- Comment #1 from Andrew Pinski --- Can you provide the preprocessed source that is used to generate the assembly file?
[Bug other/103673] avr-gcc with -mrelax with .balign is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103673 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- You should report this to binutils (https://sourceware.org/bugzilla) as this is the assembler you are complaining about and gcc does not contain the assembler.
[Bug other/103673] New: avr-gcc with -mrelax with .balign is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103673 Bug ID: 103673 Summary: avr-gcc with -mrelax with .balign is buggy Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: therealdragony at gmx dot de Target Milestone: --- Compile the following assembler code with avr-gcc .rept 300 call test .endr ldi ZL,lo8(matrix) ldi ZH,hi8(matrix) 1:rjmp 1b test: ret .balign 256 matrix: .byte 1,2,3,4,5 Then look at .lss 250: 06 d0 rcall .+12; 0x25e 252: 05 d0 rcall .+10; 0x25e 254: 04 d0 rcall .+8 ; 0x25e 256: 03 d0 rcall .+6 ; 0x25e 258: e8 ea ldi r30, 0xA8 ; 168 25a: f2 e0 ldi r31, 0x02 ; 2 25c: ff cf rjmp.-2 ; 0x25c 025e : 25e: 08 95 ret ... 0300 : 300: 01 02 mulsr16, r17 302: 03 04 cpc r0, r3 304: 05 00 .word 0x0005 ; As you can see, the ldi is loading 0x02AB, which is wrong, as the matrix is (correctly) located at 0x0300. Compiled via: #avr-gcc --version avr-gcc (GCC) 10.2.0 #avr-gcc main.S -o main.elf -Wall -Wextra -std=gnu99 -mmcu=atxmega384c3 -nostartfiles -mrelax -Wl,--no-stubs -Wa,--no-pad-sections #avr-objdump -DSg main.elf > main.lss PS: This is my first bug report at all. I'm sorry if it contains formal mistakes.
[Bug c++/103672] New: using with template class> causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103672
Bug ID: 103672
Summary: using with template class> causes
internal compiler error
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: turtlefight at ymail dot com
Target Milestone: ---
The following example results in an internal compiler error.
It does compile fine with clang and msvc.
Example Code:
#include
#include
template
struct unique {
auto operator()(auto&&... args) {
return std::make_unique(std::forward(args)...);
}
};
template class T, class... Args>
using deduced_type = decltype(T{std::declval()...});
template class F, template class T, class... Args>
auto make(Args&&... args) {
return F>{}(std::forward(args)...);
}
template
struct Foo { Foo(A,B) {} };
int main(){
auto foo_unique = make(1, 2);
}
Full Error Message:
: In instantiation of 'auto make(Args&& ...) [with F = unique; T = Foo;
Args = {int, int}]':
:24:40: required from here
:16:41: internal compiler error: in tsubst, at cp/pt.c:15632
16 | return F>{}(std::forward(args)...);
|~^
0x21004e9 internal_error(char const*, ...)
???:0
0x7e96eb fancy_abort(char const*, int, char const*)
???:0
0xa5fde7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xa5d3af tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xa89b76 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xa5d954 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xa5eb8d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xa63a47 instantiate_decl(tree_node*, bool, bool)
???:0
0x904ebe maybe_instantiate_decl(tree_node*)
???:0
0x906980 mark_used(tree_node*, int)
???:0
0x819197 build_new_function_call(tree_node*, vec**, int)
???:0
0xaca89c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xa29b8d c_parse_file()
???:0
0xbb6bb2 c_common_parse_file()
???:0
Godbolt Example: https://godbolt.org/z/rd4PdYrq8
What's interesting is that the code compiles without problems if a using
declaration is not used, e.g.:
template class F, template class T, class... Args>
auto make(Args&&... args) {
return
F()...})>{}(std::forward(args)...);
}
Godbolt Example: https://godbolt.org/z/Pd3Mjs8rG
[Bug fortran/103671] New: arrays with negative strides are wrongly passed as argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103671 Bug ID: 103671 Summary: arrays with negative strides are wrongly passed as argument. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- This has been identified in PR102043 comment #13. Testcase from there: program main implicit none integer, dimension :: a(4, 4) a = 0 call s(a(4:1:-1,:)) if (any(a /= 10)) stop 1 contains subroutine s(b) implicit none integer, dimension(:,:) :: b b = 10 end subroutine s end program main
[Bug fortran/103472] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:4527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Created attachment 51982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51982=edit draft patch We could workaround it by replacing warnings with errors. Are there cases where we do want warnings, not errors?
[Bug c/103670] New: Incorrect optimization of loop termination: Early exit with any optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103670 Bug ID: 103670 Summary: Incorrect optimization of loop termination: Early exit with any optimization Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: robert.muench at saphirion dot com Target Milestone: --- Created attachment 51981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51981=edit Assembly output with & without -Os optimization Whenever any -Ox option is used, the loop exits after 3 rounds, even the counter should run for 6 rounds. Without any -O option, the code works as expected.
[Bug c++/103668] constexpr std::vector not working as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103668 --- Comment #4 from Andrei-Edward Popa --- Yes, I really missed this constexpr instead of const, this is clear for me. Thank you! I think this thread can be closed now.
[Bug c++/103668] constexpr std::vector not working as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103668 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #1) > I don't think this is valid C++. > > A vector created in a constexpr function must be destroyed there as well, it > cannot escape from the function. Not a C++ lawyer, but I think returning it from constexpr function is just fine, what is wrong is if it isn't destructed in the same constant evaluation as the construction. So the bug in the testcase IMHO is the constexpr keyword before auto vec = get_vector();, that means one constant evaluation is the computation of the initializer of vec and that doesn't destruct what it constructed. Now, if you remove that bogus constexpr keyword or replace it with const keyword, it works just fine, vec is constructed, vec.size() is computed and then vec is destructed.
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 --- Comment #6 from Bill Schmidt --- With a quick and dirty patch to implement this, I get: $ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 pr103623.c -B/home/wschmidt/gcc/build/gcc-e300/gcc -mcpu=401 pr103623.c: In function 'main': pr103623.c:2:16: error: '__builtin_unpack_longdouble' requires long double to be IBM 128-bit format 2 | #define UNPACK __builtin_unpack_longdouble |^ pr103623.c:11:15: note: in expansion of macro 'UNPACK' 11 | double x0 = UNPACK (a, 0); | ^~ Arseny, does this properly diagnose the issue for you?
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 --- Comment #5 from Bill Schmidt --- Agreed that this needs a new attribute, and digging through the macros used to guard the associated patterns, this really does need to be restricted to the case when long double is implemented by IBM-128. Safest is to use FLOAT128_2REG_P (TFmode), i.e., applied to the mode used for long double, which is what enables the corresponding pack and unpack patterns.
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #4 from sandra at gcc dot gnu.org --- Created attachment 51980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51980=edit hacky patch Attached patch has not been regression tested, but it does seem to fix the original testcase, which now produces: $ gfortran -c pr103258.f90 pr103258.f90:3:13: 3 | character(n+m) :: c | 1 Error: Symbol 'm' at (1) has no IMPLICIT type pr103258.f90:1:14: 1 | subroutine s(n) | 1 Error: Symbol 'n' at (1) has no IMPLICIT type
[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258 --- Comment #3 from sandra at gcc dot gnu.org --- This looks like an existing bug in error checking that was exposed by my patch to do... more error checking. :-S The problem is that gfc_set_default_type in symbol.c is setting sym->attr.untyped even when errors are suppressed or buffered and discarded during parsing. Since it's marked as having already been diagnosed, we aren't giving an error in subsequent calls where errors are *not* being suppressed or discarded, and thus compilation continues as if nothing were wrong, until it falls over. Previously we were resolving only the second operand "m" in the "(n+m)" expression in a situation where errors are buffered in the parsing stage, leaving "n" without the attr.untyped flag set so that it was being diagnosed later during the actual resolve phase of processing. Now it is setting that flag on both "n" and "m" so neither ever gives a real error. I've got a hacky patch to avoid setting sym->attr.untyped when a real error might not be given, but I'm not sure if it's the right solution. Maybe a better solution would be to emit the diagnostic somewhere other than gfc_set_default_type, at a known point in the processing where it'll only happen once?
[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513
--- Comment #7 from Jan Hubicka ---
OK, i suppose we do not really have interface to fold ternary expression? It
could still do useful work merging the value ranges of both arms...
I am testing the following:
gcc/ChangeLog:
2021-12-12 Jan Hubicka
* ipa-fnsummary.c (evaluate_conditions_for_known_args): Do not ICE
on ternary expression.
gcc/testsuite/ChangeLog:
2021-12-12 Jan Hubicka
* gcc.c-torture/compile/pr103513.c: New test.
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 6c1cdf17e47..cb3c198ec0c 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -513,7 +513,7 @@ evaluate_conditions_for_known_args (struct cgraph_node
*node,
op->index ? : );
}
else
- gcc_unreachable ();
+ res.set_varying (op->type);
type = op->type;
vr = res;
}
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr103513.c
b/gcc/testsuite/gcc.c-torture/compile/pr103513.c
new file mode 100644
index 000..ca876a9816c
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr103513.c
@@ -0,0 +1,8 @@
+int a;
+void b(int c) {
+ int d = 3;
+ d ^= c < 2;
+ if (d < 3 && a)
+while (1)
+ b(!a);
+}
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80645 --- Comment #29 from Mikael Morin --- PR #80645 is possibly related to this.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #4 from Bill Schmidt ---
__builtin_darn and __builtin_darn_raw are in the wrong stanza. Moving them to
[power9-64] fixes it on my cross:
diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
b/gcc/config/rs6000/rs6000-builtin-new.def
index 30556e5c7f2..2becd96a36c 100644
--- a/gcc/config/rs6000/rs6000-builtin-new.def
+++ b/gcc/config/rs6000/rs6000-builtin-new.def
@@ -2799,15 +2799,9 @@
; Miscellaneous P9 functions
[power9]
- signed long long __builtin_darn ();
-DARN darn {}
-
signed int __builtin_darn_32 ();
DARN_32 darn_32 {}
- signed long long __builtin_darn_raw ();
-DARN_RAW darn_raw {}
-
const signed int __builtin_dtstsfi_eq_dd (const int<6>, _Decimal64);
TSTSFI_EQ_DD dfptstsfi_eq_dd {}
@@ -2840,6 +2834,12 @@
void __builtin_altivec_stxvl (vsc, void *, long);
STXVL stxvl {}
+ signed long long __builtin_darn ();
+DARN darn {}
+
+ signed long long __builtin_darn_raw ();
+DARN_RAW darn_raw {}
+
const signed int __builtin_scalar_byte_in_set (signed int, signed long
long);
CMPEQB cmpeqb {}
[Bug c++/103668] constexpr std::vector not working as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103668 --- Comment #2 from Andrei-Edward Popa --- This code is valid in MSVC compiler, that's why I'm wondering about it.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-12 Status|UNCONFIRMED |NEW --- Comment #5 from Bill Schmidt --- Confirmed by Kewen, so setting status.
[Bug target/103625] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103625 --- Comment #4 from Bill Schmidt --- Kewen, how did you confirm this? My cross doesn't accept -mvsx as valid. $ /home/wschmidt/gcc/build/gcc-e300/gcc/xgcc -c -O2 -mvsx pr103625.c -B/home/wschmidt/gcc/build/gcc-e300/gcc /home/wschmidt/gcc/build/gcc-e300/gcc/as: line 114: exec: -m: invalid option exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-12 Ever confirmed|0 |1 --- Comment #3 from Bill Schmidt --- Hm, I see a slightly different error (just a seg fault), but still, confirmed.
[Bug target/103622] [12 Regression] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103622 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-12 --- Comment #6 from Bill Schmidt --- Confirmed.
[Bug c++/103668] constexpr std::vector not working as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103668 --- Comment #1 from Jonathan Wakely --- I don't think this is valid C++. A vector created in a constexpr function must be destroyed there as well, it cannot escape from the function.
[Bug target/103635] size_t and uintptr_t have wrong sizes with x86_64-w64-mingw32-g++ -mabi=sysv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103635 --- Comment #12 from Jonathan Wakely --- Arguably sysv ABI on Windows is a distinct target, and you need to provide your own libc for it.
