[Bug tree-optimization/117859] New: ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859
Bug ID: 117859
Summary: ICE on valid code at -O{2,3} with "-fno-ssa-phiopt
-fno-expensive-optimization": Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 14.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/rz7fehsbW
[679] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241129 (experimental) (GCC)
[680] %
[680] % gcctk -O2 -fno-ssa-phiopt -fno-expensive-optimizations small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug c/100501] [12/13/14 Regression] ICE with inline-asm and void statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100501 Joseph S. Myers changed: What|Removed |Added Known to work||15.0 Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE |ICE with inline-asm and |with inline-asm and void |void statement expression |statement expression --- Comment #15 from Joseph S. Myers --- Fixed so far for GCC 15.
[Bug ada/117861] New: pragma Suppress (Overflow_check) is ignored and overflow fails at compilation rather than throwing an exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117861 Bug ID: 117861 Summary: pragma Suppress (Overflow_check) is ignored and overflow fails at compilation rather than throwing an exception Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: 00120260a at gmail dot com CC: dkm at gcc dot gnu.org Target Milestone: --- +===GNAT BUG DETECTED==+ | 14.2.0 (x86_64-pc-linux-gnu) GCC error: | | in gnat_to_gnu, at ada/gcc-interface/trans.cc:6333 | | Error detected at increment_integer.adb:6:29 | | Compiling increment_integer.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ > procedure Increment_integer (I: in out Integer) is > A: Integer := Integer'Last; > pragma suppress (Overflow_Check, A); > pragma suppress (Range_Check, A); > begin > A := Integer'Succ (A); > end Increment_integer; It's to showcase a need I have a variable that risks causing an overflow (of its subtype or base type) at the end of a loop that fills an array, but only at the last iteration so it doesn't matter, and only in case the array's last index equals the index's base type last possible value. While a table is unlikely to have Positive'Last as an index, it could be indexed with Boolean, so the last iteration of the loop WILL necessarily causes overflow. It should normally trigger a Constraint_Error, that I can catch, but I want to suppress the check instead. But `A := Integer'Succ (A);` is straight up refused.
[Bug c/100792] ICE: gimplify_expr, at gimplify.c:14879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100792 Joseph S. Myers changed: What|Removed |Added Known to work||15.0 Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |15.0 --- Comment #5 from Joseph S. Myers --- Fixed for GCC 15.
[Bug c/100792] ICE: gimplify_expr, at gimplify.c:14879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100792 --- Comment #4 from GCC Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:abea0dbd63ddb7e16d13806df929e1ef3b060091 commit r15-5827-gabea0dbd63ddb7e16d13806df929e1ef3b060091 Author: Joseph Myers Date: Sat Nov 30 16:15:51 2024 + gimplify: Handle void expression as asm input [PR100501, PR100792] As reported in bug 100501 (plus duplicates), the gimplifier ICEs for C tests involving a statement expression not returning a value as an asm input; this includes the variant bug 100792 where the statement expression ends with another asm statement. The expected diagnostic for this case (as seen for C++ input) is one coming from the gimplifier and so it seems reasonable to fix the gimplifier to handle the GENERIC generated for this case by the C front end, rather than trying to make the C front end detect it earlier. Thus the gimplifier to handle a void expression like other non-lvalues for such a memory input. Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit? PR c/100501 PR c/100792 gcc/ * gimplify.cc (gimplify_asm_expr): Handle void expressions for memory inputs like other non-lvalues. gcc/testsuite/ * gcc.dg/pr100501-1.c, gcc.dg/pr100792-1.c: New tests. * gcc.dg/pr48552-1.c, gcc.dg/pr48552-2.c, gcc.dg/torture/pr98601.c: Update expected errors. Co-authored-by: Richard Biener
[Bug c/100501] [12/13/14/15 Regression] ICE with inline-asm and void statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100501 --- Comment #14 from GCC Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:abea0dbd63ddb7e16d13806df929e1ef3b060091 commit r15-5827-gabea0dbd63ddb7e16d13806df929e1ef3b060091 Author: Joseph Myers Date: Sat Nov 30 16:15:51 2024 + gimplify: Handle void expression as asm input [PR100501, PR100792] As reported in bug 100501 (plus duplicates), the gimplifier ICEs for C tests involving a statement expression not returning a value as an asm input; this includes the variant bug 100792 where the statement expression ends with another asm statement. The expected diagnostic for this case (as seen for C++ input) is one coming from the gimplifier and so it seems reasonable to fix the gimplifier to handle the GENERIC generated for this case by the C front end, rather than trying to make the C front end detect it earlier. Thus the gimplifier to handle a void expression like other non-lvalues for such a memory input. Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit? PR c/100501 PR c/100792 gcc/ * gimplify.cc (gimplify_asm_expr): Handle void expressions for memory inputs like other non-lvalues. gcc/testsuite/ * gcc.dg/pr100501-1.c, gcc.dg/pr100792-1.c: New tests. * gcc.dg/pr48552-1.c, gcc.dg/pr48552-2.c, gcc.dg/torture/pr98601.c: Update expected errors. Co-authored-by: Richard Biener
[Bug ada/117861] pragma Suppress (Overflow_check) is ignored and overflow fails at compilation rather than throwing an exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117861 --- Comment #1 from Saada Mehdi <00120260a at gmail dot com> --- On the other hand the following > pragma suppress (Overflow_Check); > pragma suppress (Range_Check); > procedure Increment_integer is > A: Boolean := Boolean'Last; > begin > A := Boolean'Base'Succ (A); > end Increment_integer; does raise an exception but doesn't suppress anything. Is this the intended behavior ?
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-11-30
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Summary|ICE on valid code at|[15 Regression] ICE on
|-O{2,3} with|valid code at -O{2,3} with
|"-fno-ssa-phiopt|"-fno-ssa-phiopt
|-fno-expensive-optimization |-fno-expensive-optimization
|": Segmentation fault |": Segmentation fault
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Target Milestone|--- |15.0
--- Comment #1 from Andrew Pinski ---
67
#21 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#22 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#23 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#24 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#25 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#26 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#27 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#28 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#29 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#30 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#31 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#32 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#33 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#34 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#35 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#36 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
#37 0x01a32d47 in insert_predicates_for_cond (code=NE_EXPR,
lhs=0x77200678, rhs=0x774242a0, true_e=0x775e2f30,
false_e=0x775e2f60) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-sccvn.cc:7967
Mine.
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859
--- Comment #2 from Andrew Pinski ---
/* (A CMP B) != 0 is the same as (A CMP B).
(A CMP B) == 0 is just (A CMP B) with the edges swapped. */
if (is_gimple_assign (def_stmt)
&& TREE_CODE_CLASS (gimple_assign_rhs_code (def_stmt)) ==
tcc_comparison)
{
tree_code nc = gimple_assign_rhs_code (def_stmt);
tree nlhs = vn_valueize (gimple_assign_rhs1 (def_stmt));
tree nrhs = vn_valueize (gimple_assign_rhs2 (def_stmt));
edge nt = true_e;
edge nf = false_e;
if (code == EQ_EXPR)
std::swap (nt, nf);
insert_predicates_for_cond (nc, nlhs, nrhs, nt, nf);
}
Looks like nrhs could return back to rhs.
Will fix this tomorrow.
[Bug tree-optimization/110405] missing nonzerobits on branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405
--- Comment #3 from Andrew Pinski ---
Another testcase:
```
int g(int);
int f(int a)
{
short t = a;
if (t != 1)
return 0;
// t is known to be 1 so `a&0x == 1` is true
// and `0x1&0x == 0` which is false
return g(a == 0x1);
}
```
Basically I am asking for value/mask to prop for branches and not just the
ranges.
[Bug target/117834] [14/15 Regression] libgfortran doesn't compile unless `PTHREAD_RWLOCK_INITIALIZER` is defined on powerpc-darwin since r14-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834 --- Comment #4 from Gleb Mazovetskiy --- Created attachment 59750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59750&action=edit example patch for tiger The following patch fixes that particular error (the proper fix should probably be either guarded for darwin8 or avoid that function altogether).
[Bug libfortran/117857] New: libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857 Bug ID: 117857 Summary: libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname` Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: glex.spb at gmail dot com Target Milestone: --- :info:build /opt/local/var/macports/build/_Users_gleb_macports-ports_lang_gcc14/libgcc14/work/gcc-14.2.0/libgfortran/io/unix.c: In function 'stream_ttyname': :info:build /opt/local/var/macports/build/_Users_gleb_macports-ports_lang_gcc14/libgcc14/work/gcc-14.2.0/libgfortran/io/unix.c:2097:10: error: returning 'char *' from a function with return type 'int' makes integer from pointer without a cast [-Wint-conversion] :info:build 2097 | return ttyname_r (((unix_stream *)s)->fd, buf, buflen); :info:build | ^~~ :info:build make[3]: *** [io/unix.lo] Error 1 Note that libgfortran is also affected by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834. Reproducing this requires fixing that bug first.
[Bug libfortran/117857] libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857 --- Comment #1 from Gleb Mazovetskiy --- On my macOS 10.4 Tiger PowerPC, /usr/include/unistd.h contains the following: #if __DARWIN_UNIX03 int ttyname_r(int, char *, size_t) __DARWIN_ALIAS(ttyname_r); #else /* !__DARWIN_UNIX03 */ char*ttyname_r(int, char *, size_t); #endif /* __DARWIN_UNIX03 */
[Bug target/117088] [15 regression] 548.exchange_r regressed by ~11% with -O2 -march=x86-64-v3 on EMR after r15-4225-g70c3db511ba14f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117088
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #4 from Andrew Macleod ---
(In reply to Jan Hubicka from comment #3)
> > digits_2.isra (1);
> >
> > so we at least know row is [1, +INF] since the add is signed.
> >
> > We might be able to use a SCEV-like range computation for recursive cases
> > like
> > this, then being able to compute [2, 8] for the recursion invocation. Not
> > sure whether doing this in local VRP is possible and how much of help symtab
> > is here (single caller).
>
> ipa-prop already understands that the recursion depth is bounded
> by 10 for cloning reasons, so perhaps this can be turned to value range
> easily?
>
> Honza
void digits_2.isra (integer(kind=4) ISRA.6607)
{
integer(kind=4) ISRA.6607_927(D) = ISRA.6607;
...
# RANGE [irange] integer(kind=4) [-2147483647, 8][10, +INF]
_494 = ISRA.6607_927(D) + 1;
by the time VRP sees it, i think ISRA.6607_927(D) is the actual parameter? if
you set SSA_NAME_RANGE_INFO (ISRA.6607_927(D)) to [1, +INF] or [1, 10] or
whatever, VRP will likely do some useful things.
VRP can't figure out the non-negative part on its own as the fact that it is
always [1, INF] is not apparent from within the function. Someone has to
provide that info via the ssa-name passed as the parameter.
_494 will share the lower bound (well, +1) of whatever ISRA.6607_927(D) has.
It currently has no value, so it is VARYING as far as VRP known. which is why
_494 has a lower bound of -INF+1. It also appears to be in a loop with the
condition being _494 != 9 or something related like that.
Its never been clear ot me why we still change loop branches to use !=. We turn
for (int y = 0 ; y < 10; y++)
b[y] = x;
into
if (y_1 != 10)
goto ; [INV]
else
goto ; [INV]
and as a result, range analysis only picks up that y_1 is not 10. whereas if
that had remained
if (y_1 < 10)
goto ; [INV]
else
goto ; [INV]
we'd at least have picked up y_1 is [-INF, 9] at in BB3 instead of [-INF,9[11,
+INF]
Instead, it has to depend on loop analysis to find values that could just be
apparent.
[Bug target/117811] [12/13/14/15 Regression] bad code for conditional right shift with autovec and neon since r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Sam James changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #10 from Sam James ---
I can't bisect that far back in my environment ("/tmp/a.c:1:0: sorry,
unimplemented: -mfloat-abi=hard and VFP") and got fed up.
[Bug libstdc++/117858] [15 regression] openrct2-0.4.16 fails to build (optional:823:52: error: incomplete type ‘std::__converts_from_optional’ used in nested name specifier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
#include
struct Focus
{
template
constexpr explicit Focus(T newValue, int t = 0) {}
};
std::optional f;
void g()
{
std::optional a;
f = a;
}
```
[Bug libstdc++/117858] [15 regression] openrct2-0.4.16 fails to build (optional:823:52: error: incomplete type ‘std::__converts_from_optional’ used in nested name specifier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug fortran/84245] [12/13/14/15 Regression] ICE in delete_root, at fortran/bbt.c:150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
CC||pault at gcc dot gnu.org
--- Comment #12 from Paul Thomas ---
Created attachment 59753
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59753&action=edit
Fix for this PR
Testcase. Regressions tests OK. Will submit when my tree is cleared of other
work.
! { dg-do compile }
!
! Fix ICEs caused by patch for PR78026
!
! Contributed by Gerhard Steinmetz
!
module m
contains
! z04, z06-z10 and z12-z16 were all variants, picked up by the errors below.
subroutine z01
select type (x%a) ! { dg-error "nonderived-type variable" }
end select ! { dg-error "Expecting END SUBROUTINE" }
end
subroutine z02
select type (x%! { dg-error "nonderived-type variable" }
end select ! { dg-error "Expecting END SUBROUTINE" }
end
subroutine z03
select type (x%&! { dg-error "nonderived-type variable" }
end select
end
subroutine z05
select type (x(! { dg-error "Syntax error" }
end select ! { dg-error "Expecting END SUBROUTINE" }
end
subroutine z11
select type (x[1] ! { dg-error "not a coarray" }
end select ! { dg-error "Expecting END SUBROUTINE" }
end
end module
[Bug target/117860] New: GCC emits an unnecessary mov for x86 _addcarry/_subborrow intrinsic calls where the second operand is a constant that is within the range of a 32-bit integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117860
Bug ID: 117860
Summary: GCC emits an unnecessary mov for x86
_addcarry/_subborrow intrinsic calls where the second
operand is a constant that is within the range of a
32-bit integer
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: john_platts at hotmail dot com
Target Milestone: ---
Here is a snippet of C99/C++ code where GCC fails to optimize the adc/sbb down
to a single instruction in the case where the second adc/sbb operand (or the
third argument of the _addcarry_u32/_addcarry_u64/_subborrow_u32/_subborrow_u64
intrinsics) is known to be constant and within the range of a 32-bit integer:
#include
#if (defined(__GNUC__) || defined(__clang__))
#include
#elif defined(_MSC_VER)
#include
#endif
typedef struct {
uint64_t lo64;
uint64_t mid64;
uint64_t hi64;
} UInt192;
UInt192 SomeAddFunc(uint64_t a_lo, uint64_t a_hi, uint64_t b) {
UInt192 result;
unsigned char cf;
unsigned long long sum;
cf = _addcarry_u64(0, a_lo, b, &sum);
result.lo64 = sum;
cf = _addcarry_u64(cf, a_hi, 5, &sum);
result.mid64 = sum;
result.hi64 = cf;
return result;
}
UInt192 SomeSubFunc(uint64_t a_lo, uint64_t a_hi, uint64_t b) {
UInt192 result;
unsigned char cf;
unsigned long long diff;
cf = _subborrow_u64(0, a_lo, b, &diff);
result.lo64 = diff;
cf = _subborrow_u64(cf, a_hi, 17, &diff);
result.mid64 = diff;
(void)_subborrow_u64(cf, 0, 0, &diff);
result.hi64 = diff;
return result;
}
Here is the code that GCC 14.2.0 generates for the above snippet with the -O2
option:
SomeAddFunc:
add rsi, rcx
mov ecx, 5
mov rax, rdi
adc rdx, rcx
movqxmm0, rsi
movqxmm1, rdx
setcdl
punpcklqdq xmm0, xmm1
movzx edx, dl
mov QWORD PTR [rdi+16], rdx
movups XMMWORD PTR [rdi], xmm0
ret
SomeSubFunc:
sub rsi, rcx
mov ecx, 17
mov rax, rdi
sbb rdx, rcx
movqxmm0, rsi
movqxmm1, rdx
sbb rdx, rdx
punpcklqdq xmm0, xmm1
mov QWORD PTR [rdi+16], rdx
movups XMMWORD PTR [rdi], xmm0
ret
In the SomeAddFunc code that is generated by GCC 14.2.0, GCC fails to optimize
the following instructions down to adc rdx, 5 when optimizations are enabled:
mov ecx, 5
adc rdx, rcx
Likewise, in the SomeSubFunc code that is generated by GCC 14.2.0, GCC fails to
optimize the following instructions down to sbb rdx, 17 when optimizations are
enabled:
mov ecx, 17
sbb rdx, rcx
A demonstration of the above snippet being compiled with GCC 14.2.0, Clang
19.1.0, and MSVC v19.40 can be found at https://godbolt.org/z/zW8WToP5G.
[Bug libstdc++/117858] [15 regression] openrct2-0.4.16 fails to build (optional:823:52: error: incomplete type ‘std::__converts_from_optional’ used in nested name specifier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Ever confirmed|0 |1 Last reconfirmed||2024-11-30 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed. I think it was one of the commits in the July timeframe which is optimizing std::optional compile time for C++20.
[Bug libstdc++/117858] [15 regression] openrct2-0.4.16 fails to build (optional:823:52: error: incomplete type ‘std::__converts_from_optional’ used in nested name specifier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 --- Comment #4 from Andrew Pinski --- This has been failing sometime before 20240727 (which is right after the patches I mentioned).
[Bug libgomp/117851] all amdgcn offload tests fail with a host compiler configured with --enable-default-pie (or compiled/linked with PIE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117851 --- Comment #6 from Matthias Klose --- tested on the trunk, and on the gcc-14 branch with offload compilers configured. libgomp test failures down from 1000 to 10.
[Bug libstdc++/117858] [15 regression] std::optional with a constructor template ctor(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858
--- Comment #5 from Andrew Pinski ---
Reduced all the way:
```
#include
struct Focus
{
template
Focus(T newValue) { }
};
void g(std::optional f)
{
f = f;
}
```
I could use auto as the type for the Focus's ctor but I wanted it still be
compilable for C++17.
[Bug fortran/105054] [12/13/14 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:dd1d74cb548428f5928c10f7d3ba2b3cdd5ddc80 commit r14-11012-gdd1d74cb548428f5928c10f7d3ba2b3cdd5ddc80 Author: Paul Thomas Date: Wed Nov 13 08:57:55 2024 + Fortran: Fix failing character pointer fcn assignment [PR105054] 2024-11-14 Paul Thomas gcc/fortran PR fortran/105054 * resolve.cc (get_temp_from_expr): If the pointer function has a deferred character length, generate a new deferred charlen for the temporary. gcc/testsuite/ PR fortran/105054 * gfortran.dg/ptr_func_assign_6.f08: New test. (cherry picked from commit f530a8c61383b174a476b64f46d56adeedf49dc4)
[Bug libfortran/117857] libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857 --- Comment #5 from Andrew Pinski --- https://gcc.gnu.org/legacy-ml/fortran/2011-01/msg00256.html Why is autoconfig's AC_USE_SYSTEM_EXTENSIONS not working for darwin8 here? Or is darwin8 just that broken. This was 13 years ago even.
[Bug libgomp/117851] all amdgcn offload tests fail with a host compiler configured with --enable-default-pie (or compiled/linked with PIE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117851
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f089ef880e385e2193237b1f53ec81dac4141680
commit r15-5820-gf089ef880e385e2193237b1f53ec81dac4141680
Author: Jakub Jelinek
Date: Sat Nov 30 11:19:12 2024 +0100
openmp: Add crtoffloadtableS.o and use it [PR117851]
Unlike crtoffload{begin,end}.o which just define some symbols at the
start/end
of the various .gnu.offload* sections, crtoffloadtable.o contains
const void *const __OFFLOAD_TABLE__[]
__attribute__ ((__visibility__ ("hidden"))) =
{
&__offload_func_table, &__offload_funcs_end,
&__offload_var_table, &__offload_vars_end,
&__offload_ind_func_table, &__offload_ind_funcs_end,
};
The problem is that linking this into PIEs or shared libraries doesn't
work when it is compiled without -fpic/-fpie - __OFFLOAD_TABLE__ for
non-PIC
code is put into .rodata section, but it really needs relocations, so for
PIC it should go into .data.rel.ro/.data.rel.ro.local.
As I think we don't want .data.rel.ro section in non-PIE binaries, this
patch
follows the path of e.g. crtbegin.o vs. crtbeginS.o and adds
crtoffloadtableS.o
next to crtoffloadtable.o, where crtoffloadtableS.o is compiled with -fpic.
2024-11-30 Jakub Jelinek
PR libgomp/117851
gcc/
* lto-wrapper.cc (find_crtoffloadtable): Add PIE_OR_SHARED
argument,
search for crtoffloadtableS.o rather than crtoffloadtable.o if
true.
(run_gcc): Add pie_or_shared variable. If OPT_pie or OPT_shared or
OPT_static_pie is seen, set pie_or_shared to true, if OPT_no_pie is
seen, set pie_or_shared to false. Pass it to find_crtoffloadtable.
libgcc/
* configure.ac (extra_parts): Add crtoffloadtableS.o.
* Makefile.in (crtoffloadtableS$(objext)): New goal.
* configure: Regenerated.
[Bug fortran/105054] [12/13/14 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:351fc7565610574f7677972b0d9c4559eaff32f0 commit r13-9223-g351fc7565610574f7677972b0d9c4559eaff32f0 Author: Paul Thomas Date: Wed Nov 13 08:57:55 2024 + Fortran: Fix failing character pointer fcn assignment [PR105054] 2024-11-14 Paul Thomas gcc/fortran PR fortran/105054 * resolve.cc (get_temp_from_expr): If the pointer function has a deferred character length, generate a new deferred charlen for the temporary. gcc/testsuite/ PR fortran/105054 * gfortran.dg/ptr_func_assign_6.f08: New test. (cherry picked from commit f530a8c61383b174a476b64f46d56adeedf49dc4)
[Bug fortran/105054] [12/13/14 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:da848c3b9396456c85d8c8055af8158148cbc1a6 commit r12-10840-gda848c3b9396456c85d8c8055af8158148cbc1a6 Author: Paul Thomas Date: Wed Nov 13 08:57:55 2024 + Fortran: Fix failing character pointer fcn assignment [PR105054] 2024-11-14 Paul Thomas gcc/fortran PR fortran/105054 * resolve.cc (get_temp_from_expr): If the pointer function has a deferred character length, generate a new deferred charlen for the temporary. gcc/testsuite/ PR fortran/105054 * gfortran.dg/ptr_func_assign_6.f08: New test. (cherry picked from commit f530a8c61383b174a476b64f46d56adeedf49dc4)
[Bug fortran/105054] [12/13/14 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Paul Thomas --- Fixed on all affected branches. Thanks for the report. Paul
[Bug tree-optimization/117057] [15 Regression] XFAIL of parts of gcc.dg/strlenopt-32.c, strlenopt doesn't handle MEM[&string + CST] = { 0, a_1 };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117057 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6bebb3b0f3fa422d248a1c2075da0598a44c7320 commit r15-5821-g6bebb3b0f3fa422d248a1c2075da0598a44c7320 Author: Jakub Jelinek Date: Sat Nov 30 11:30:08 2024 +0100 strlen: Handle vector CONSTRUCTORs [PR117057] The following patch handles VECTOR_TYPE_P CONSTRUCTORs in count_nonzero_bytes, including handling them if they have some elements non-constant. If there are still some constant elements before it (in the range queried), we derive info at least from those bytes and consider the rest as unknown. The first 3 hunks just punt in IMHO problematic cases, the spaghetti code considers byte_size 0 as unknown size, determine yourself, so if offset is equal to exp size, there are 0 bytes to consider (so nothing useful to determine), but using byte_size 0 would mean use any size. Similarly, native_encode_expr uses int type for offset (and size), so padding it offset larger than INT_MAX could be silent miscompilation. I've guarded the test to just a couple of targets known to handle it, because e.g. on ia32 without -msse forwprop1 seems to lower the CONSTRUCTOR into 4 BIT_FIELD_REF stores and I haven't figured out on what exactly that depends on (e.g. powerpc* is fine on any CPUs, even with -mno-altivec -mno-vsx, even -m32). 2024-11-30 Jakub Jelinek PR tree-optimization/117057 * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes): Punt also when byte_size is equal to offset or nchars. Punt if offset is bigger than INT_MAX. Handle vector CONSTRUCTOR with some elements constant, possibly followed by non-constant. * gcc.dg/strlenopt-32.c: Remove xfail and vect_slp_v2qi_store_unalign specific scan-tree-dump-times directive. * gcc.dg/strlenopt-96.c: New test.
[Bug c++/117849] constraint variable in requires expression rejected, but P2280R4 made it valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117849
--- Comment #5 from Matthias Kretz (Vir) ---
Thanks for looking into this issue!
Yes, GCC is currently the compiler that comes closest to implementing P2280 -
Clang fails on so many more examples here. However, WG21 just voted library
wording into the working draft that relies on this feature. :-)
I modified your reduced example to be closer to the original code.
(ranges::size(r) returns r.size(); integral_constant (i) is convertible to the
value, making it comparable - no need for operator==). I also added a 'size(t)
> 0' check and a check for a type that is not statically sized, where the
concept shouldn't become ill-formed either.
https://godbolt.org/z/dE6sjnaKP
```
template struct a {
constexpr int size () const { return N; }
};
struct v {
int _size = 3;
constexpr int size () const { return _size; }
};
template struct i {
constexpr operator int () const { return N; }
};
template
constexpr auto size (T &&t) { return t.size (); }
template
concept StaticSizedRange = requires (T &&t) {
typename i;
requires (size (t) > 0);
};
a<5> b;
static_assert (size (b) == size (b));
static_assert (StaticSizedRange>);
static_assert (StaticSizedRange &>);
static_assert (StaticSizedRange &>);
// a std::vector is not a statically sized range
static_assert (!StaticSizedRange);
```
[Bug fortran/117805] complex type, -Ofast and IEEE-754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805 --- Comment #20 from mjr19 at cam dot ac.uk --- I am not convinced that gfortran's current behaviour is wholly consistent with what a mathematician would reasonably expect. When I was taught complex arithmetic, multiplication by one and addition of zero were both identity operations. But in gfortran they can move one across a branch cut. program test print *,sqrt(-(1.0,0.0)) ! Below branch cut print *,sqrt(-(1.0,-0.0)) ! Above branch cut print *,sqrt(-(1*(1.0,-0.0))) ! Now below branch cut print *,sqrt((-1.0,-0.0)) ! Below branch cut print *,sqrt((-1.0,-0.0)+0)! Now above branch cut end program test I don't think it is possible to produce rules for complex arithmetic based on a Cartesian representation with signed zeros which do not produce surprises similar to the above.
[Bug libfortran/117857] libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857 --- Comment #6 from Gleb Mazovetskiy --- > This has been "broken" since r0-106339-g6a0f6e7799c988 (GCC 4.6.0) Over 13 > years ago. I don't think so. GCC7 has been the version used by macports for a while, and more recently some reported compiling GCC12. Looking through the code, I'm not quite sure what could've changed to result in a regression? The only way this could've worked is if `HAVE_TTYNAME_R` wasn't defined previously, so I'm guessing it's some autoconf change? Patching this and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834 results in a successful build.
[Bug libfortran/117857] libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857 --- Comment #2 from Gleb Mazovetskiy --- Created attachment 59751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59751&action=edit workaround patch for darwin8
[Bug target/84211] [avr] Perform a post-reload register optimization pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84211 --- Comment #4 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:214985f6b35ea8038c4e96590b435aaef2919769 commit r15-5822-g214985f6b35ea8038c4e96590b435aaef2919769 Author: Georg-Johann Lay Date: Sat Nov 30 14:58:05 2024 +0100 AVR: ad target/84211 - Split MOVW into MOVs in try_split_any. When splitting multi-byte REG-REG moves in try_split_any(), it's not clear whether propagating constants will turn out as profitable. When MOVW is available, split into REG-REG moves instead of a possible REG-CONST. gcc/ PR target/84211 * config/avr/avr-passes.cc (try_split_any) [SET, MOVW]: Prefer reg=reg move over reg=const when splitting a reg=reg insn.
[Bug tree-optimization/117057] [15 Regression] XFAIL of parts of gcc.dg/strlenopt-32.c, strlenopt doesn't handle MEM[&string + CST] = { 0, a_1 };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117057 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Should be fixed now.
[Bug lto/114542] -flto=4294967296 is treated the same as -flto=0 and -flto=4294967297 is treated the same as -flto=1 instead of being invalid options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114542 Heiko Eißfeldt changed: What|Removed |Added CC||heiko at hexco dot de --- Comment #1 from Heiko Eißfeldt --- FYI funnily enough GNUmake seems to have a problem with ridiculous high n, like -flto=65537 or higher. On my system using that will hang in GNUmake...
[Bug lto/114542] -flto=4294967296 is treated the same as -flto=0 and -flto=4294967297 is treated the same as -flto=1 instead of being invalid options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114542 --- Comment #2 from Heiko Eißfeldt --- Filed a GNUmake bug report for that: https://savannah.gnu.org/bugs/index.php?66499
[Bug target/117850] GCC emits DUP, UMULL instead of UMULL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117850 --- Comment #4 from rguenther at suse dot de --- > Am 29.11.2024 um 19:08 schrieb rsandifo at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117850 > > --- Comment #3 from Richard Sandiford --- > (In reply to rguent...@suse.de from comment #2) >> I dont See how this is easier? > > It's not to simplify things :) But isn't gimple_fold_builtin restricted to > the > same search/valueisation domain as match.pd? Or does gimple_fold_builtin have > more freedom to follow the argument definitions as far as it likes? Yes. Following use -> def as you Like is always OK From fold_stmt. Richard > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c/117806] [14 Regression] ICE: in composite_type_internal with C23 tag compatibility and packed/aligned attribute on a field (defined 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117806 Sam James changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |uecker at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libfortran/117857] libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Andrew Pinski --- This has been "broken" since r0-106339-g6a0f6e7799c988 (GCC 4.6.0) Over 13 years ago. We are not going to fix this for an old out dated OS.
[Bug libfortran/117857] libgfortran on powerpc-darwin8 doesn't compile: `-Wint-conversion` in `stream_ttyname`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=47432 --- Comment #3 from Andrew Pinski --- https://pubs.opengroup.org/onlinepubs/9799919799/functions/ttyname.html
[Bug target/117834] [14/15 Regression] libgfortran doesn't compile unless `PTHREAD_RWLOCK_INITIALIZER` is defined on powerpc-darwin since r14-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Andrew Pinski --- This is not going to be fixed. Mac OS X 10.4 has not been supported for years now as GCC. At least update to Mac OS X 10.5
[Bug libstdc++/117858] New: [15 regression] openrct2-0.4.16 fails to build (optional:823:52: error: incomplete type ‘std::__converts_from_optional’ used in nested name specifier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858
Bug ID: 117858
Summary: [15 regression] openrct2-0.4.16 fails to build
(optional:823:52: error: incomplete type
‘std::__converts_from_optional’ used in
nested name specifier)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
```
$ g++ ./CMakeFiles/openrct2.dir/src/openrct2-ui/windows/Staff.cpp.ii
-std=gnu++20 -march=znver2 -fno-char8_t
In file included from
/var/tmp/portage/games-simulation/openrct2-0.4.16/work/OpenRCT2-0.4.16/src/openrct2-ui/../openrct2/interface/../localisation/../core/Guard.hpp:13,
from
/var/tmp/portage/games-simulation/openrct2-0.4.16/work/OpenRCT2-0.4.16/src/openrct2-ui/../openrct2/interface/../localisation/Formatter.h:13,
from
/var/tmp/portage/games-simulation/openrct2-0.4.16/work/OpenRCT2-0.4.16/src/openrct2-ui/../openrct2/interface/Window.h:14,
from
/var/tmp/portage/games-simulation/openrct2-0.4.16/work/OpenRCT2-0.4.16/src/openrct2-ui/windows/../interface/Theme.h:13,
from
/var/tmp/portage/games-simulation/openrct2-0.4.16/work/OpenRCT2-0.4.16/src/openrct2-ui/windows/Staff.cpp:10:
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/optional: In instantiation
of ‘constexpr const bool
std::optional::__construct_from_contained_value’:
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/optional:881:7: required
by substitution of ‘template requires
!(is_same_v, typename std::remove_cvref<_It2>::type>) &&
(is_constructible_v<_Tp, const _Up&>) && (__construct_from_contained_value<_Up,
typename std::remove_cv< >::type>) constexpr
std::optional::optional(const std::optional<_Tp>&) [with _Up = Focus]’
881 | && __construct_from_contained_value<_Up>
| ^
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/type_traits:1143:25:
required by substitution of ‘template using
std::__is_constructible_impl = std::__bool_constant<__is_constructible(_Tp,
_Args ...)> [with _Tp = Focus; _Args = {std::optional&}]’
1143 | = __bool_constant<__is_constructible(_Tp, _Args...)>;
| ^
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/type_traits:1148:12:
required from ‘struct std::is_constructible&>’
1148 | struct is_constructible
|^~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/type_traits:181:35:
required by substitution of ‘template
std::__detail::__first_t, typename
std::enable_if<(!(bool)(_Bn::value)), void>::type ...>
std::__detail::__or_fn(int) [with _Bn = {std::is_constructible&>, std::is_convertible&, Focus>,
std::is_constructible >,
std::is_convertible, Focus>, std::is_constructible&>, std::is_convertible&,
Focus>, std::is_constructible >,
std::is_convertible, Focus>}]’
181 |
__enable_if_t...>;
| ^
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/type_traits:199:41:
required from ‘struct std::__or_&>, std::is_convertible&, Focus>,
std::is_constructible >,
std::is_convertible, Focus>, std::is_constructible&>, std::is_convertible&,
Focus>, std::is_constructible >,
std::is_convertible, Focus> >’
199 | : decltype(__detail::__or_fn<_Bn...>(0))
|~^~~
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/optional:1083:45:
required by substitution of ‘template requires
!(is_same_v, typename std::remove_cvref<_It2>::type>) &&
(is_constructible_v<_Tp, _Up>) && (is_assignable_v<_Tp&, _Up>) &&
!(std::__converts_from_optional<_Tp, _From>::value) &&
!(std::__assigns_from_optional<_Tp, _Up>::value) constexpr
std::optional& std::optional::operator=(std::optional<_Tp>&&)
[with _Up = Focus]’
1083 | && (!__converts_from_optional<_Tp, _Up>::value)
|^
/var/tmp/portage/games-simulation/openrct2-0.4.16/work/OpenRCT2-0.4.16/src/openrct2-ui/windows/Staff.cpp:1168:21:
required from here
1168 | focus = tempFocus;
| ^
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/optional:823:52: error:
incomplete type ‘std::__converts_from_optional’ used in nested
name specifier
823 | = !__converts_from_optional<_Tp, _From>::value;
|^
```
[Bug libstdc++/117858] [15 regression] openrct2-0.4.16 fails to build (optional:823:52: error: incomplete type ‘std::__converts_from_optional’ used in nested name specifier)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 --- Comment #1 from Sam James --- Created attachment 59752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59752&action=edit Staff.cpp.ii.xz
[Bug c/64526] No warning on function call with excessive arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64526 --- Comment #8 from Eric Gallager --- (In reply to Andrew Pinski from comment #7) > I am not sure if this needed any more since now () means the same as (void) > with C23 and GCC defaults to C23 ... Some people may still wish to compile for earlier standards.
[Bug rust/116561] [15 regression] gcc/testsuite/rust/execute/torture/iter1.rs:350:5: internal compiler error: 'verify_gimple' failed since r15-3328-g673a448aa24efedd5ac140ebf7bfe652d7a6a846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116561 --- Comment #2 from Sam James --- (In reply to Thomas Schwinge from comment #1) > This appears to be due to recent commit > r15-3328-g673a448aa24efedd5ac140ebf7bfe652d7a6a846 "Optimize initialization > of small padded objects". > > Given this commit doesn't appear to be causing any other issues, chances are > that the Rust front end is doing "something funny"? It seems to have started passing yesterday or so, probably after r15-5772-gf93059c82e61d6.
[Bug c++/19501] Redundant "template" keyword rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19501 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Marek Polacek from comment #5) > Yeah, seems fixed by r12-6754-g30f2c22def7392 > > commit 30f2c22def7392119f1ffaca30ef998b3b43f336 > Author: Jason Merrill > Date: Tue Jan 18 18:28:22 2022 -0500 > > c++: template-id with current inst qualifier [PR102300] So, OK to close, then?
[Bug rtl-optimization/112398] Suboptimal code generation for xor pattern on subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- So I looked at the neg16 case with zbb off. Even with the additional instruction budget, I don't see that an xor base sequence will be any better as we need two instructions to struct 0x. I also looked at the 3rd testcase. As I noted before the output of the NOT is used in multiple contexts, so trivial adjustment to XOR doesn't work. On targets with bitfield extractions we will recognize the zero extended bitfield extraction as-such. Closing as I think the generic changes to simplify-rtx are doing what they should.
[Bug c/64526] No warning on function call with excessive arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64526 --- Comment #9 from Sam James --- Of course, it's just about whether it's very important anymore. If it hasn't happened by now, it probably won't. I nearly left a similar comment to pinskia.
[Bug libfortran/117820] Formatted output gives wrong result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117820
--- Comment #7 from Jerry DeLisle ---
The root of the problem here is that the function write_boz uses a type int to
pass in the value n, this value is then tested for zero which fails for a 64
bit integer.
The following hack makes it work but I don't like this fix.
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 2f414c6b57d..378013dbd18 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1392,6 +1392,8 @@ write_b (st_parameter_dt *dtp, const fnode *f, const char
*source, int len)
{
n = extract_uint (source, len);
p = btoa (n, itoa_buf, sizeof (itoa_buf));
+ if (n != 0)
+ n = 1;
write_boz (dtp, f, p, n, len);
For larger integers, the test for zero is done in the big_btoa functions where
the unsigned value is known and it can be explicitly tested. the variable n in
write_boz really ought to be a bool so that it is more obvious to maintainers
what is going on.
I will clean this up and submit a patch for approval.
[Bug ipa/117862] Missed Optimization: Failure to Inline Functions When Generating Position-Independent Code (PIC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117862 --- Comment #3 from Jonathan Gruber --- (In reply to Andrew Pinski from comment #1) > https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Optimize-Options.html#index- > fsemantic-interposition > > This is by design. You need -fno-semantic-interposition.. (In reply to Andreas Schwab from comment #2) > Or declare the function with hidden visibility. Thanks for the tips. Sorry to have wasted y'all's time.
[Bug c++/117837] ICE: verify_cgraph_node failed with weakref to comdat function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117837 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-12-01 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/117837] ICE: verify_cgraph_node failed with weakref to comdat function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117837
Andrew Pinski changed:
What|Removed |Added
Summary|ICE: verify_cgraph_node |ICE: verify_cgraph_node
|failed |failed with weakref to
||comdat function
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
struct A {
A() {}
};
static void ref_to_A(void) __attribute__((weakref("_ZN1AC2Ev")));
bool t = ref_to_A ? 1 : 0;
```
[Bug fortran/117797] [13/14/15 Regression] ICE in gfc_get_array_span
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117797 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #1 from Paul Thomas --- This is caused by my fix for PR109345. Taking this one. Thanks for the report. Paul
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #430 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #429) > Could be related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770 You mean comment #419? If you could merge 59432 and 59550 into your tree and rebase, I can test now that a fix for PR 117770 has landed.
[Bug ipa/117862] Missed Optimization: Failure to Inline Functions When Generating Position-Independent Code (PIC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117862 --- Comment #4 from Sam James --- It's a common footgun in ELF. :)
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e1009b3de2d05782ae1e0c62f9e81da14c4d6156 commit r15-5844-ge1009b3de2d05782ae1e0c62f9e81da14c4d6156 Author: Andrew Pinski Date: Sat Nov 30 14:09:48 2024 -0800 VN: Don't recurse on for the same value of `a != 0` [PR117859] Like r15-5063-g6e84a41622f56c, but this is for the `a != 0` case. After adding vn_valueize to the handle the `a ==/!= 0` case of insert_predicates_for_cond, it would go into an infinite loop as the Value number for a could be the same as what it is for the whole expression. This avoids that recursion so there is no infinite loop here. Note lim was introducing `bool_var2 = bool_var1 != 0` originally but with the gimple testcase in -2, there is no dependency on what passes before hand will do. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/117859 gcc/ChangeLog: * tree-ssa-sccvn.cc (insert_predicates_for_cond): If the valueization for the new lhs for `lhs != 0` is the same as the old ones, don't recurse. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr117859-1.c: New test. * gcc.dg/torture/pr117859-2.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:24949e640307f91a831e0fb699fea85fb9276a09 commit r15-5843-g24949e640307f91a831e0fb699fea85fb9276a09 Author: Andrew Pinski Date: Sat Nov 30 13:12:13 2024 -0800 gimple-lim: Reuse boolean var when moving PHI While looking into PR 117859, I noticed that LIM sometimes would produce `bool_var2 = bool_var1 != 0` instead of just using bool_var2. This patch allows LIM to reuse bool_var1 in the place where bool_var2 was going to be used. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * tree-ssa-loop-im.cc (move_computations_worker): While moving phi, reuse the lhs of the conditional if it is a boolean type. Signed-off-by: Andrew Pinski
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Andrew Pinski --- Fixed.
[Bug rust/116561] [15 regression] gcc/testsuite/rust/execute/torture/iter1.rs:350:5: internal compiler error: 'verify_gimple' failed since r15-3328-g673a448aa24efedd5ac140ebf7bfe652d7a6a846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116561 --- Comment #3 from Andrew Pinski --- Note I think there is still a rust front-end issue. Because if error_mark_node is making a difference that should not happen since error_mark_node should not happen as a type unless there is an error and there was no error.
[Bug rust/116561] [15 regression] gcc/testsuite/rust/execute/torture/iter1.rs:350:5: internal compiler error: 'verify_gimple' failed since r15-3328-g673a448aa24efedd5ac140ebf7bfe652d7a6a846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116561 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #429 from Oleg Endo --- Could be related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770
[Bug target/117860] GCC emits an unnecessary mov for x86 _addcarry/_subborrow intrinsic calls where the second operand is a constant that is within the range of a 32-bit integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117860
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
Ever confirmed|0 |1
Last reconfirmed||2024-11-30
--- Comment #1 from Andrew Pinski ---
Confirmed.
I think it should be easy to support it with a slight change to this pattern:
```
(define_insn "addcarry"
[(set (reg:CCC FLAGS_REG)
(compare:CCC
(zero_extend:
(plus:SWI48
(plus:SWI48
(match_operator:SWI48 5 "ix86_carry_flag_operator"
[(match_operand 3 "flags_reg_operand") (const_int 0)])
(match_operand:SWI48 1 "nonimmediate_operand" "%0,0,rm,r"))
(match_operand:SWI48 2 "nonimmediate_operand" "r,rm,r,m")))
(plus:
(zero_extend: (match_dup 2))
(match_operator: 4 "ix86_carry_flag_operator"
[(match_dup 3) (const_int 0)]
(set (match_operand:SWI48 0 "nonimmediate_operand" "=rm,r,r,r")
(plus:SWI48 (plus:SWI48 (match_op_dup 5
[(match_dup 3) (const_int 0)])
(match_dup 1))
(match_dup 2)))]
"ix86_binary_operator_ok (PLUS, mode, operands, TARGET_APX_NDD)"
"@
adc{}\t{%2, %0|%0, %2}
adc{}\t{%2, %0|%0, %2}
adc{}\t{%2, %1, %0|%0, %1, %2}
adc{}\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "isa" "*,*,apx_ndd,apx_ndd")
(set_attr "type" "alu")
(set_attr "use_carry" "1")
(set_attr "pent_pair" "pu")
(set_attr "mode" "")])
```
operand 2 would need to change.
[Bug target/117834] [14/15 Regression] libgfortran doesn't compile unless `PTHREAD_RWLOCK_INITIALIZER` is defined on powerpc-darwin since r14-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Andrew Pinski from comment #5) > This is not going to be fixed. Mac OS X 10.4 has not been supported for > years now as GCC. At least update to Mac OS X 10.5 I thought Iain still tested on 10.4 occasionally...
[Bug libstdc++/117858] [15 regression] std::optional with a constructor template ctor(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 --- Comment #11 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c2c7d71eeeab7c6e2a8124b53d6eae6c59781e79 commit r15-5833-gc2c7d71eeeab7c6e2a8124b53d6eae6c59781e79 Author: Jonathan Wakely Date: Sat Nov 30 21:37:02 2024 + libstdc++: Fix constraints on std::optional converting assignments [PR117858] It looks like I copied these constraints from operator=(U&&) and didn't correct them to account for the parameter being optional not U. libstdc++-v3/ChangeLog: PR libstdc++/117858 * include/std/optional (operator=(const optional&)): Fix copy and paste error in constraints. (operator=(optional&&)): Likewise. * testsuite/20_util/optional/assignment/117858.cc: New test.
[Bug target/117834] [14/15 Regression] libgfortran doesn't compile unless `PTHREAD_RWLOCK_INITIALIZER` is defined on powerpc-darwin since r14-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834 --- Comment #7 from Iain Sandoe --- (In reply to Eric Gallager from comment #6) > (In reply to Andrew Pinski from comment #5) > > This is not going to be fixed. Mac OS X 10.4 has not been supported for > > years now as GCC. At least update to Mac OS X 10.5 > > I thought Iain still tested on 10.4 occasionally... * I no longer test 10.4, it's not practical in terms of turn-around time when trying to chase Darwin2x to hold it up for Darwin8 * However, the policy for Darwin is that we do not deprecate old OS Versions, but OTOH when things are not tested they bit rot * I realise that for some hardware 10.4 is the end of the road (and actually it was a very solid OS revision, i used it for field data collection for a long time) * If you want to make progress, and help keep it alive, then the best way is to test regularly - in this case you need to bisect to find what change caused the problem - and hopefully that will suggest a patch. * Patches to fix Darwin8 that break or limit Darwin2x are not likely to be useful.
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859 --- Comment #4 from Andrew Pinski --- Created attachment 59755 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59755&action=edit gimple testcase
[Bug target/117818] vec_add incorrectly generates vadduwm for vector char const inputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818
--- Comment #5 from Steven Munroe ---
I expected compiling for -mcpu=power9 to do a better job generating splats for
small constants.
Given the new instructions like VSX Vector Splat Immediate Byte (xxspltib) and
Vector Extend Sign Byte To Word/Doubleword the compiler should have a easier
time generating vec_splats(). It would seem that Vector Splat Immediate Byte
would be the perfect way to generate a constant shift quadword left/right.
But that is not what I am seeing. First note there is no direct intrinsic for
xxspltib. It is sometimes generated for vec_splat_u8(0-15) and
vec_splats((vector unsigned char) x). But sometimes it gets weird.
For example:
vui128_t
test_slqi_char_18_V3 (vui128_t vra)
{
vui8_t result;
vui8_t tmp = vec_splats((unsigned char)18);
result = vec_vslo ((vui8_t) vra, tmp);
return (vui128_t) vec_vsl (result, tmp);
}
Which I would expect to generate:
xxspltib 34,18
vslo 2,2,0
vsl 2,2,0
But generates:
vspltisb 0,9
vadduwm 0,0,0
vslo 2,2,0
vsl 2,2,0
It recognizes that it can't generate 18 with vspltisb and uses the 18 = 9 * 2
pattern. It also erroneously generates vector add word. Seem like GCC is
reusing the old pattern and ignoring the new instructions.
This is weird because:
vui8_t
test_splat6_char_18 ()
{
vui8_t tmp = vec_splat_u8(9);
return vec_add (tmp, tmp);
}
Generates:
xxspltib 34,9
vaddubm 2,2,2
But:
vui8_t
test_splat6_char_31 ()
{
// 31 = (16+15) = (15 - (-16))
vui8_t v16 = vec_splat_u8(-16);
vui8_t tmp = vec_splat_u8(15);
return vec_sub (tmp, v16);
}
Generates:
xxspltib 34,31
Which seems like a miracle. Is this constant propagation?
But:
vui8_t
test_slqi_char_31_V0 (vui8_t vra)
{
vui8_t result;
// 31 = (16+15) = (15 - (-16))
vui8_t v16 = vec_splat_u8(-16);
vui8_t tmp = vec_splat_u8(15);
tmp = vec_sub (tmp, v16);
result = vec_slo (vra, tmp);
return vec_sll (result, tmp);
}
Generates:
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
lxv 32,0(9)
vslo 2,2,0
vsl 2,2,0
Ok I think I can fix ths with:
vui8_t
test_slqi_char_31_V3 (vui8_t vra)
{
vui8_t result;
vui8_t tmp = vec_splats((unsigned char)31);
result = vec_slo (vra, tmp);
return vec_sll (result, tmp);
}
But no. it still generated:
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
lxv 32,0(9)
vslo 2,2,0
vsl 2,2,0
Which is all very confusing.
[Bug target/117818] vec_add incorrectly generates vadduwm for vector char const inputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818 --- Comment #4 from Steven Munroe --- Created attachment 59756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59756&action=edit Updated Test case Vector shift long with const shift count -mcpu=power9 This is an extension of the original with example using vec_splats() that generate weird code for power9.
[Bug c/117865] New: "error: too many arguments to function" with C23 doesn't show function pointer location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117865 Bug ID: 117865 Summary: "error: too many arguments to function" with C23 doesn't show function pointer location Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- ``` # gcc ./paths.i paths.c: In function ‘t1_Loc’: paths.c:219:9: error: too many arguments to function ‘S->convert’ 219 |(*S->convert)(&r->dest, S, x, y); |~^~~~ paths.c: In function ‘t1_ILoc’: paths.c:240:9: error: too many arguments to function ‘S->iconvert’ 240 |(*S->iconvert)(&r->dest, S, (int32_t) x, (int32_t) y); |~^ paths.c: In function ‘t1_Hint’: paths.c:374:17: error: too many arguments to function ‘S->convert’ 374 |(*S->convert)(&r->ref, S, 0.0, ref); |~^~~~ paths.c:375:17: error: too many arguments to function ‘S->convert’ 375 |(*S->convert)(&r->width, S, 0.0, width); |~^~~~ paths.c:378:17: error: too many arguments to function ‘S->convert’ 378 |(*S->convert)(&r->ref, S, ref, 0.0); |~^~~~ paths.c:379:17: error: too many arguments to function ‘S->convert’ 379 |(*S->convert)(&r->width, S, width, 0.0); |~^~~~ paths.c: In function ‘t1_PathXform’: paths.c:945:17: error: too many arguments to function ‘S->iconvert’ 945 |(*S->iconvert)(&p->dest, S, p->dest.x + oldx, p->dest.y + oldy); |~^ paths.c:959:25: error: too many arguments to function ‘S->iconvert’ 959 |(*S->iconvert)(&cp->M, S, cp->M.x + oldx, cp->M.y + oldy); |~^ paths.c:973:25: error: too many arguments to function ‘S->iconvert’ 973 |(*S->iconvert)(&bp->B, S, bp->B.x + oldx, bp->B.y + oldy); |~^ paths.c:976:25: error: too many arguments to function ‘S->iconvert’ 976 |(*S->iconvert)(&bp->C, S, bp->C.x + oldx, bp->C.y + oldy); |~^ paths.c:986:25: error: too many arguments to function ‘S->iconvert’ 986 |(*S->iconvert)(&hp->ref, S, hp->ref.x + oldx, hp->ref.y + oldy); |~^ paths.c:989:25: error: too many arguments to function ‘S->iconvert’ 989 |(*S->iconvert)(&hp->width, S, hp->width.x, hp- >width.y); |~^ ``` Couldn't we show the location of convert, iconvert?
[Bug c/117865] "error: too many arguments to function" with C23 doesn't show function pointer location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117865 --- Comment #1 from Sam James --- Created attachment 59757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59757&action=edit paths.i.xz
[Bug c/117865] "error: too many arguments to function" with C23 doesn't show function pointer location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117865
--- Comment #2 from Sam James ---
```
struct p {
int (*bar)();
};
void baz() {
struct p q;
q.bar(1);
}
```
```
$ gcc /tmp/a.c
/tmp/a.c: In function ‘baz’:
/tmp/a.c:7:5: error: too many arguments to function ‘q.bar’
7 | q.bar(1);
| ^
```
[Bug c/117866] [15 regression] Confusing 'expected ... but argument is of type ...' (same type repeated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-12-01
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
```
void convert(struct fractpoint *pt);
struct fractpoint {
int x;
};
void f(struct fractpoint dest)
{
convert(&dest);
}
```
I know the tag rules changed so I am not sure. Obvious fix is to forward
declare the tag by adding `struct fractpoint;` in front of the struct XYspace
definition.
[Bug c/117866] [15 regression] Confusing 'expected ... but argument is of type ...' (same type repeated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866
--- Comment #3 from Andrew Pinski ---
Semi reduced:
```
struct XYspace {
void (*convert)(struct fractpoint *pt);
} ;
struct fractpoint {
double x,y;
} ;
struct segment {
struct fractpoint dest;
} ;
void t1_Loc(register struct XYspace *S)
{
register struct segment *r;
(*S->convert)(&r->dest);//, S, x, y);
}
```
[Bug c/100064] False positive with -Wincompatible-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100064 --- Comment #3 from Andrew Pinski --- Note you could also do: `f(&b.parent);`
[Bug c/100064] False positive with -Wincompatible-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100064 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Invalid as explained, `struct a*` and `struct b*` are incompatible types.
[Bug driver/117867] New: -Wfatal-errors vs -fmax-errors=1 inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117867 Bug ID: 117867 Summary: -Wfatal-errors vs -fmax-errors=1 inconsistency Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Using my example from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866#c0, I see: ``` $ gcc paths.i -fmax-errors=1 -Wall -Wextra paths.c: In function ‘t1_Loc’: paths.c:219:22: error: passing argument 1 of ‘S->convert’ from incompatible pointer type [-Wincompatible-pointer-types] 219 |r->context = S->context; | ^~~~ | | | struct fractpoint * paths.c:219:22: note: expected ‘struct fractpoint *’ but argument is of type ‘struct fractpoint *’ compilation terminated due to -fmax-errors=1. ``` vs ``` $ gcc paths.i -Wfatal-errors -Wall -Wextra paths.c: In function ‘t1_Loc’: paths.c:219:22: error: passing argument 1 of ‘S->convert’ from incompatible pointer type [-Wincompatible-pointer-types] 219 |r->context = S->context; | ^~~~ | | | struct fractpoint * compilation terminated due to -Wfatal-errors. ``` i.e. for -Wfatal-errors, we don't get the note.
[Bug c/97687] -Wfatal-errors prints some notes but not others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #8 from Sam James --- *** Bug 117867 has been marked as a duplicate of this bug. ***
[Bug driver/117867] -Wfatal-errors vs -fmax-errors=1 inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117867 --- Comment #1 from Sam James --- Maybe a dupe of PR97687?
[Bug driver/117867] -Wfatal-errors vs -fmax-errors=1 inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117867 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Sam James --- OK, yes, it is. *** This bug has been marked as a duplicate of bug 97687 ***
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859 --- Comment #5 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670483.html
[Bug tree-optimization/110405] missing nonzerobits on branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/dtcxzyw/ ||llvm-tools/issues/36 --- Comment #4 from Andrew Pinski --- Sounds like this comes up a lot in rust code: https://github.com/dtcxzyw/llvm-tools/issues/36
[Bug tree-optimization/117859] [15 Regression] ICE on valid code at -O{2,3} with "-fno-ssa-phiopt -fno-expensive-optimization": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117859 --- Comment #3 from Andrew Pinski --- Actually the problem is lim in the first place: t.c.149t.lim2: _50 = _59 != 0; That is not Canonical since _59 is a bool ...
[Bug target/117863] New: Missing pcmpeq splitters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117863
Bug ID: 117863
Summary: Missing pcmpeq splitters
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
$ cat vector_eq-2.c
/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
/* { dg-additional-options "-O2 -march=x86-64-v3" } */
typedef int v4si __attribute__((vector_size(16)));
v4si __RTL (startwith ("vregs")) foo (void)
{
(function "foo"
(insn-chain
(block 2
(edge-from entry (flags "FALLTHRU"))
(cnote 1 [bb 2] NOTE_INSN_BASIC_BLOCK)
(cnote 2 NOTE_INSN_FUNCTION_BEG)
(cinsn 3 (set (reg:V4SI <0>) (const_vector:V4SI [(const_int -1)
(const_int -1) (const_int -1) (const_int -1)])))
(cinsn 4 (set (reg:V4SI <1>) (const_vector:V4SI [(const_int -1)
(const_int -1) (const_int -1) (const_int -1)])))
(cinsn 5 (set (reg:V4SI <2>)
(eq:V4SI (reg:V4SI <0>) (reg:V4SI <1>
(cinsn 6 (set (reg:V4SI <3>) (reg:V4SI <2>)))
(cinsn 7 (set (reg:V4SI xmm0) (reg:V4SI <3>)))
(edge-to exit (flags "FALLTHRU"))
)
)
(crtl (return_rtx (reg/i:V4SI xmm0)))
)
}
/* { dg-final { scan-assembler-times "vpcmpeqd" 1 } } */
$ /export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2
-march=x86-64-v3 -S vector_eq-2.c
$ cat vector_eq-2.s
.file "vector_eq-2.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
vpcmpeqd%xmm0, %xmm0, %xmm0
vpcmpeqd%xmm0, %xmm0, %xmm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 15.0.0 20241129 (experimental) [master
r15-5113-g858912fa675]"
.section.note.GNU-stack,"",@progbits
$
(insn 5 3 7 2 (set (reg:V4SI 100)
(eq:V4SI (reg:V4SI 98)
(reg:V4SI 98))) 7910 {*sse2_eqv4si3}
(expr_list:REG_DEAD (reg:V4SI 98)
(expr_list:REG_EQUAL (eq:V4SI (const_vector:V4SI [
(const_int -1 [0x]) repeated x4
])
(const_vector:V4SI [
(const_int -1 [0x]) repeated x4
]))
(nil
should be converted to
(insn 5 10 12 2 (set (reg:V4SI 100)
(const_vector:V4SI [
(const_int -1 [0x]) repeated x4
])) 2363 {movv4si_internal}
(nil))
[Bug c/48091] No warning when given function arguments mismatch earlier function definition which GCC assumes to be K&R, even with --std=c99 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48091 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 14030 ***
[Bug c/14030] missing parameter count check ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14030 Andrew Pinski changed: What|Removed |Added CC||eerott at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 48091 has been marked as a duplicate of this bug. ***
[Bug c/14030] missing parameter count check ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14030 --- Comment #8 from Andrew Pinski --- *** Bug 92212 has been marked as a duplicate of this bug. ***
[Bug c/26732] different argument type not rejected for K&R style function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 14030 ***
[Bug c/92212] incompatible calls to K&R functions not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92212 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 14030 ***
[Bug c/117866] New: Confusing 'expected ... but argument is of type ...' (same type repeated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866 Bug ID: 117866 Summary: Confusing 'expected ... but argument is of type ...' (same type repeated) Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 59758 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59758&action=edit path.i.xz Pretty sure I've made an error here but the diagnostic is weird either way: ``` # gcc paths.i -fmax-errors=1 paths.c: In function ‘t1_Loc’: paths.c:219:22: error: passing argument 1 of ‘S->convert’ from incompatible pointer type [-Wincompatible-pointer-types] 219 |(*S->convert)(&r->dest, S, x, y); | ^~~~ | | | struct fractpoint * paths.c:219:22: note: expected ‘struct fractpoint *’ but argument is of type ‘struct fractpoint *’ compilation terminated due to -fmax-errors=1. ``` "expected 'struct X *' but argument is of type 'struct X *' It's the same type according to the text? If I build it with Clang, I get a warning which makes way more sense at least: ``` ./spaces.h:63:31: warning: declaration of 'struct fractpoint' will not be visible outside of this function [-Wvisibility] 63 |void (*convert)(struct fractpoint *pt, struct XYspace *S, float X, float Y); /* calculate "fractpoint" X,Y from float X,Y*/ | ^ ./spaces.h:64:32: warning: declaration of 'struct fractpoint' will not be visible outside of this function [-Wvisibility] 64 |void (*iconvert)(struct fractpoint *pt, struct XYspace *S, int X, int Y);/* calculate "fractpoint" X,Y from int X,Y */ | ```
[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476 --- Comment #36 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:e4c1b3d45a33cfb9d76be11c362f81aa77e29882 commit r15-5836-ge4c1b3d45a33cfb9d76be11c362f81aa77e29882 Author: Alexey Merzlyakov Date: Sat Nov 30 19:01:28 2024 -0700 [PATCH v3] zero_extend(not) -> xor optimization [PR112398] This patch adds optimization of the following patterns: (zero_extend:M (subreg:N (not:O==M (X:Q==M -> (xor:M (zero_extend:M (subreg:N (X:M)), mask)) ... where the mask is GET_MODE_MASK (N). For the cases when X:M doesn't have any non-zero bits outside of mode N, (zero_extend:M (subreg:N (X:M)) could be simplified to just (X:M) and whole optimization will be: (zero_extend:M (subreg:N (not:M (X:M -> (xor:M (X:M, mask)) Patch targets to handle code patterns like: not a0,a0 andi a0,a0,0xff to be optimized to: xori a0,a0,255 PR rtl-optimization/112398 PR rtl-optimization/117476 gcc/ChangeLog: * simplify-rtx.cc (simplify_context::simplify_unary_operation_1): Simplify ZERO_EXTEND (SUBREG (NOT X)) to XOR (X, GET_MODE_MASK(SUBREG)) when X doesn't have any non-zero bits outside of SUBREG mode. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr112398.c: New test. * gcc.dg/torture/pr117476-1.c: New test. From Zhendong Su. * gcc.dg/torture/pr117476-2.c: New test. From Zdenek Sojka.
[Bug rtl-optimization/112398] Suboptimal code generation for xor pattern on subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398 --- Comment #10 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:e4c1b3d45a33cfb9d76be11c362f81aa77e29882 commit r15-5836-ge4c1b3d45a33cfb9d76be11c362f81aa77e29882 Author: Alexey Merzlyakov Date: Sat Nov 30 19:01:28 2024 -0700 [PATCH v3] zero_extend(not) -> xor optimization [PR112398] This patch adds optimization of the following patterns: (zero_extend:M (subreg:N (not:O==M (X:Q==M -> (xor:M (zero_extend:M (subreg:N (X:M)), mask)) ... where the mask is GET_MODE_MASK (N). For the cases when X:M doesn't have any non-zero bits outside of mode N, (zero_extend:M (subreg:N (X:M)) could be simplified to just (X:M) and whole optimization will be: (zero_extend:M (subreg:N (not:M (X:M -> (xor:M (X:M, mask)) Patch targets to handle code patterns like: not a0,a0 andi a0,a0,0xff to be optimized to: xori a0,a0,255 PR rtl-optimization/112398 PR rtl-optimization/117476 gcc/ChangeLog: * simplify-rtx.cc (simplify_context::simplify_unary_operation_1): Simplify ZERO_EXTEND (SUBREG (NOT X)) to XOR (X, GET_MODE_MASK(SUBREG)) when X doesn't have any non-zero bits outside of SUBREG mode. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr112398.c: New test. * gcc.dg/torture/pr117476-1.c: New test. From Zhendong Su. * gcc.dg/torture/pr117476-2.c: New test. From Zdenek Sojka.
[Bug libstdc++/117858] [15 regression] std::optional with a constructor template ctor(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 --- Comment #9 from Jonathan Wakely --- Looks like a copy & paste error in r15-2309-g6d86486292acbe: --- a/libstdc++-v3/include/std/optional +++ b/libstdc++-v3/include/std/optional @@ -1043,7 +1043,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template #ifdef _GLIBCXX_USE_CONSTRAINTS_FOR_OPTIONAL - requires (!is_same_v>) + requires (!is_same_v<_Tp, remove_cvref_t<_Up>>) && is_constructible_v<_Tp, const _Up&> && is_assignable_v<_Tp&, const _Up&> && (!__converts_from_optional<_Tp, _Up>::value) @@ -1077,7 +1077,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template #ifdef _GLIBCXX_USE_CONSTRAINTS_FOR_OPTIONAL - requires (!is_same_v>) + requires (!is_same_v<_Tp, remove_cvref_t<_Up>>) && is_constructible_v<_Tp, _Up> && is_assignable_v<_Tp&, _Up> && (!__converts_from_optional<_Tp, _Up>::value)
[Bug libstdc++/117858] [15 regression] std::optional with a constructor template ctor(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 --- Comment #10 from Jonathan Wakely --- Actually it should be: --- a/libstdc++-v3/include/std/optional +++ b/libstdc++-v3/include/std/optional @@ -1043,7 +1043,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template #ifdef _GLIBCXX_USE_CONSTRAINTS_FOR_OPTIONAL - requires (!is_same_v>) + requires (!is_same_v<_Tp, _Up>) && is_constructible_v<_Tp, const _Up&> && is_assignable_v<_Tp&, const _Up&> && (!__converts_from_optional<_Tp, _Up>::value) @@ -1077,7 +1077,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template #ifdef _GLIBCXX_USE_CONSTRAINTS_FOR_OPTIONAL - requires (!is_same_v>) + requires (!is_same_v<_Tp, _Up>) && is_constructible_v<_Tp, _Up> && is_assignable_v<_Tp&, _Up> && (!__converts_from_optional<_Tp, _Up>::value)
[Bug fortran/84245] [12/13/14/15 Regression] ICE in delete_root, at fortran/bbt.c:150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--- Comment #13 from kargls at comcast dot net ---
(In reply to Paul Thomas from comment #12)
> Created attachment 59753 [details]
> Fix for this PR
>
> Testcase. Regressions tests OK. Will submit when my tree is cleared of other
> work.
>
> ! { dg-do compile }
> !
> ! Fix ICEs caused by patch for PR78026
> !
> ! Contributed by Gerhard Steinmetz
> !
> module m
> contains
> ! z04, z06-z10 and z12-z16 were all variants, picked up by the errors below.
>subroutine z01
> select type (x%a) ! { dg-error "nonderived-type variable" }
> end select ! { dg-error "Expecting END SUBROUTINE" }
>end
>subroutine z02
> select type (x%! { dg-error "nonderived-type variable" }
> end select ! { dg-error "Expecting END SUBROUTINE" }
>end
>subroutine z03
> select type (x%&! { dg-error "nonderived-type variable" }
> end select
>end
>subroutine z05
> select type (x(! { dg-error "Syntax error" }
> end select ! { dg-error "Expecting END SUBROUTINE" }
>end
>subroutine z11
> select type (x[1] ! { dg-error "not a coarray" }
> end select ! { dg-error "Expecting END SUBROUTINE" }
>end
> end module
If something goes wrong, do you possibly need to free expr1 and expr2.
Elsewhere in gfc_match_select_type() one seems the the idiom
if (...)
{
m = MATCH_ERROR;
goto cleanup;
}
[Bug libstdc++/117858] [15 regression] std::optional with a constructor template ctor(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jonathan Wakely --- Fixed. Thanks for the reduced testcase, Andrew.
[Bug libstdc++/117858] [15 regression] std::optional with a constructor template ctor(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117858 --- Comment #13 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:abed4806ddd75d4450c40f4064977024be460f4c commit r15-5834-gabed4806ddd75d4450c40f4064977024be460f4c Author: Jonathan Wakely Date: Sat Nov 30 21:43:47 2024 + libstdc++: Improve new testcase for std::optional assignment [PR117858] The copy & paste bug affected two assignment operators, so ensure the new test covers both. libstdc++-v3/ChangeLog: PR libstdc++/117858 * testsuite/20_util/optional/assignment/117858.cc: Also test assignment from rvalue optional.
[Bug c/14030] missing parameter count check ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14030 Andrew Pinski changed: What|Removed |Added CC||ramana.radhakrishnan@codito ||.com --- Comment #9 from Andrew Pinski --- *** Bug 26732 has been marked as a duplicate of this bug. ***
[Bug c/117866] [15 regression] Confusing 'expected ... but argument is of type ...' (same type repeated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866 Sam James changed: What|Removed |Added Summary|Confusing 'expected ... but |[15 regression] Confusing |argument is of type ...'|'expected ... but argument |(same type repeated)|is of type ...' (same type ||repeated) --- Comment #1 from Sam James --- With -std=gnu17, we do this right. # gcc paths.i -fmax-errors=1 -Wall -Wextra -std=gnu17 In file included from paths.c:47: spaces.h:63:31: warning: ‘struct fractpoint’ declared inside parameter list will not be visible outside of this definition or declaration 63 |void (*convert)(struct fractpoint *pt, struct XYspace *S, float X, float Y); /* calculate "fractpoint" X,Y from float X,Y*/ | ^~ spaces.h:64:32: warning: ‘struct fractpoint’ declared inside parameter list will not be visible outside of this definition or declaration 64 |void (*iconvert)(struct fractpoint *pt, struct XYspace *S, int X, int Y);/* calculate "fractpoint" X,Y from int X,Y */ |^~ paths.c: In function ‘t1_Loc’: paths.c:219:22: error: passing argument 1 of ‘S->convert’ from incompatible pointer type [-Wincompatible-pointer-types] 219 |r->context = S->context; | ^~~~ | | | struct fractpoint * paths.c:219:22: note: expected ‘struct fractpoint *’ but argument is of type ‘struct fractpoint *’ Hence a regression in the default mode.
