[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 --- Comment #19 from rguenther at suse dot de --- On Wed, 21 Feb 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 > > --- Comment #17 from Jakub Jelinek --- > So, either we could somehow handle that case during expansion (treat it > basically as VCE), or tweak the > /* For integral conversions with the same precision or pointer >conversions use a NOP_EXPR instead. */ > (simplify > (view_convert @0) > (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)) >&& (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE > (@0))) >&& TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))) >(convert @0))) > match.pd rule not to do that for INTEGER_TYPEs with PRECISION > > MAX_FIXED_TYPE_PRECISION (then we don't need the gimple-lower-bitint.cc > changes > either). > --- gcc/match.pd.jj 2024-02-19 09:42:16.583617451 +0100 > +++ gcc/match.pd2024-02-21 13:32:06.567816298 +0100 > @@ -4679,7 +4679,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) >(view_convert @0) >(if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)) > && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE > (@0))) > - && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))) > + && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0)) > + /* Punt for conversions from or to barely supported huge > + INTEGER_TYPEs. Those can handle just loads/stores/moves but > + nothing else. */ > + && (TYPE_PRECISION (type) <= MAX_FIXED_MODE_SIZE > + || (TREE_CODE (type) != INTEGER_TYPE > + && TREE_CODE (TREE_TYPE (@0)) != INTEGER_TYPE))) > (convert @0))) > > /* Strip inner integral conversions that do not change precision or size, or I think the usual BLKmode check would be better here? Apart from that this looks correct, we shouldn't use a regular convert on a non-register type. In fact, it looks like all bitint types are register types because we want SSA names for them. A bit of a "bad" design ... We've used BLKmode checks elsewhere so I think it would be appropriate here, too.
[Bug tree-optimization/114041] New: wrong code with _BitInt() and -O -fgraphite-identity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041 Bug ID: 114041 Summary: wrong code with _BitInt() and -O -fgraphite-identity Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57486=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -fgraphite-identity testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)
[Bug target/114027] [14] RISC-V vector: miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #4 from Li Pan ---
Just did some hacks from the riscv backend, which is to replace the expanding
code of reduc_smax_scal_ to the reduc_xor_scal_.
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 3b32369f68c..58424baabd7 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -2107,10 +2107,8 @@ (define_expand "reduc_smax_scal_"
(match_operand:V_VLSI 1 "register_operand")]
"TARGET_VECTOR"
{
- int prec = GET_MODE_PRECISION (mode);
- rtx min = immed_wide_int_const (wi::min_value (prec, SIGNED), mode);
- riscv_vector::expand_reduction (UNSPEC_REDUC_MAX, riscv_vector::REDUCE_OP,
- operands, min);
+ riscv_vector::expand_reduction (UNSPEC_REDUC_XOR, riscv_vector::REDUCE_OP,
+ operands, CONST0_RTX (mode));
DONE;
})
My idea would like to prove that the last standard name should be .REDUC_XOR.
Then the test (include the narrowed and the original one) can pass. That may
indicates we take .REDUC_MAX by mistake in somewhere. let me try to figure it
out.
[Bug ipa/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #17 from rguenther at suse dot de ---
On Wed, 21 Feb 2024, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
>
> --- Comment #8 from Aldy Hernandez ---
> (In reply to Richard Biener from comment #5)
> > (In reply to Martin Jambor from comment #4)
> > > The right place where to free stuff in lattices post-IPA would be in
> > > ipa_node_params::~ipa_node_params() where we should iterate over lattices
> > > and deinitialize them or perhaps destruct the array because since
> > > ipcp_vr_lattice directly contains Value_Range which AFAIU directly
> > > contains
> > > int_range_max which has a virtual destructor... does not look like a POD
> > > anymore. This has escaped me when I was looking at the IPA-VR changes but
> > > hopefully it should not be too difficult to deal with.
> >
> > OK, that might work for the IPA side.
> >
> > It's quite unusual to introduce a virtual DTOR in the middle of the class
> > hierarchy though. Grepping I do see quite some direct uses of 'irange'
> > and also 'vrange' which do not have the DTOR visible but 'irange' already
> > exposes and uses 'maybe_resize'. I think those should only be introduced
> > in the class exposing the virtual DTOR (but why virtual?!).
> >
> > Would be nice to have a picture of the range class hierarchies with
> > pointers on which types to use in which circumstances ...
>
> For reference, you should always use the most base class you can. If
> you can get the work done with the vrange API, use that. If you're
> dealing with an integer, use irange. The int_range<> derived class
> should only be used for defining a variable, so:
>
> int_range<123> foobar; // Defined with storage.
>
> if (is_a )
> {
> irange = as_a (foobar);
> ...
> }
>
> // Use an irange reference here, not an int_range reference.
> void somefunc (const irange )
> {
> }
>
> Also, the reason irange does not have a destructor is because it has
> no storage. Only int_range<> has storage associated with it, so it is
> the only one able to see if the range grew:
But when I do
irange *r = new int_range<>;
delete r;
then it will fail to release memory? Are virtual DTORs not exactly
invented for this, when you delete on a reference/pointer to a base
class but the object is really a derived one?
That's what I was refering to with "introducing a virtual DTOR
in a not base-class".
I still think that's bad OO design, no?
[Bug c/114042] New: diagnostics about __builtin_stdc_bit_ceil() mentions __builtin_clzg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114042 Bug ID: 114042 Summary: diagnostics about __builtin_stdc_bit_ceil() mentions __builtin_clzg() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57487=edit reduced testcase Compiler output: $ gcc-14 bc.c bc.c: In function ‘foo’: bc.c:4:36: error: argument 1 in call to function ‘__builtin_clzg’ has signed type 4 | return __builtin_stdc_bit_ceil(i); |^ but it should talk about __builtin_stdc_bit_ceil()
[Bug tree-optimization/114041] wrong code with _BitInt() and -O -fgraphite-identity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-22 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. if (ub4_0_17(D) > 1) goto ; [59.00%] else goto ; [41.00%] is gone missing. Graphite is almost definitely not maintained either ...
[Bug c/114042] diagnostics about __builtin_stdc_bit_ceil() mentions __builtin_clzg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114042 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/114044] ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114044 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-22 CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- Confirmed. ccp1 leaves around: .CLZ (3); So does forwprop1 (if we do -fno-tree-ccp). So does fre. So does many passes really.
[Bug rtl-optimization/114044] New: ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114044 Bug ID: 114044 Summary: ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57489=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-dce testcase.c during RTL pass: expand testcase.c: In function 'foo': testcase.c:5:7: internal compiler error: in expand_fn_using_insn, at internal-fn.cc:208 5 | 5 | __builtin_stdc_bit_floor(ub256_0) & 4; | ^ 0x79b2a7 expand_fn_using_insn /repo/gcc-trunk/gcc/internal-fn.cc:208 0xf83d8f expand_call_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:2771 0xf83d8f expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.cc:3932 0xf83d8f expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:4077 0xf8a2fe expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.cc:6133 0xf8bfd7 execute /repo/gcc-trunk/gcc/cfgexpand.cc:6872 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)
[Bug target/114027] [14] RISC-V vector: miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
Li Pan changed:
What|Removed |Added
CC||pan2.li at intel dot com
--- Comment #3 from Li Pan ---
Narrow a little compares to the original test case.
---
int b[10][7] = {{}, // 0
{}, // 1
{}, // 2
{}, // 3
{}, // 4
{}, // 5
{0, 0, 0, 0, 0, 1}, // 6
{2, 3, 4, 5, 6, 7}, // 7
{8, 8, 8, 8, 8, 8}};// 8
//0 1 2 3 4 5
int c;
int main() {
int d = 0, a = 0;
c = 0x;
for (a = 0; a < 5; a++) {
for (d = 0; d < 6; d++) {
c ^= -3L;
if (b[a + 3][d])
continue;
c = 0;
}
}
if (c == -3) {
return 0;
} else {
return 1;
}
}
---
The sematics of the loop acts on 5 * 6 matrix. The upstream currently makes the
first 4 * 6 vectorized and then goes scalar for the last 6 elements. The
vectorized part may looks like below.
vect_array.16 = .MASK_LEN_LOAD_LANES ( [(void *) + 84B],
32B, { -1, ... }, POLY_INT_CST [4, 4], 0);
vect__28.17_94 = vect_array.16[0];
vect__28.18_95 = vect_array.16[1];
vect__28.19_96 = vect_array.16[2];
vect__28.20_97 = vect_array.16[3];
vect__28.21_98 = vect_array.16[4];
vect__28.22_99 = vect_array.16[5];
vect_array.16 ={v} {CLOBBER};
mask__70.24_102 = vect__28.17_94 != { 0, ... };
vect_prephitmp_76.25_104 = .VCOND_MASK (mask__70.24_102, { -1, ... }, { -3,
... });
mask__80.26_106 = vect__28.18_95 != { 0, ... };
vect_c_lsm.27_108 = .VCOND_MASK (mask__80.26_106, vect_prephitmp_76.25_104, {
0, ... });
mask__51.28_110 = vect__28.19_96 != { 0, ... };
vect_prephitmp_66.29_112 = .VCOND_MASK (mask__51.28_110, vect_c_lsm.27_108, {
-3, ... });
mask__16.30_114 = vect__28.20_97 != { 0, ... };
vect_c_lsm.31_116 = .VCOND_MASK (mask__16.30_114, vect_prephitmp_66.29_112, {
0, ... });
mask__79.32_118 = vect__28.21_98 != { 0, ... };
vect_prephitmp_56.33_120 = .VCOND_MASK (mask__79.32_118, vect_c_lsm.31_116, {
-3, ... });
mask__25.34_122 = vect__28.22_99 != { 0, ... };
vect_c_lsm.35_124 = .VCOND_MASK (mask__25.34_122, vect_prephitmp_56.33_120, {
0, ... });
_126 = .REDUC_MAX (vect_c_lsm.35_124);
Looks like the last .REDUC_MAX is kind of a surprise here? It is not easy to
get the sematics of REDUC_MAX for source code. Actually the c will depend on
the previous iteration.
For example, if b condition is 0, c will be 0 forever. If b condition is 1, the
c will be the sequence similar to [-3, 0, -3, 0...].
Not sure if my understanding is correct, will take a look into tree-vect.
[Bug tree-optimization/114040] wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040 --- Comment #2 from Andrew Pinski --- ` -fdisable-tree-evrp -fdisable-tree-vrp1` also fixes it. EVRP and VRP1 changes: _3 = IMAGPART_EXPR <_8>; _4 = (_Bool) _3; _5 = (unsigned _BitInt(8671)) _4; into _7 = .SUB_OVERFLOW (_2, 0); _3 = IMAGPART_EXPR <_7>; _4 = (unsigned _BitInt(8671)) _3; Which looks fine. Then bitlower looks to go wrong.
[Bug tree-optimization/114040] wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-22 --- Comment #1 from Andrew Pinski --- Confirmed. -fno-tree-vrp "fixes" it though. I have not looked into why though.
[Bug tree-optimization/114040] New: wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040 Bug ID: 114040 Summary: wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57485=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O2 testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)
[Bug target/112299] [14 Regression] Cross compiling to loongarch64-linux-gnuf64 fails because "HAVE_AS_TLS was not declared" after r14-4925-g1b30ef7cea773e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112299 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by LuluCheng : https://gcc.gnu.org/g:b1cad801dac215b2f594166e69759f33bd791308 commit r13-8352-gb1cad801dac215b2f594166e69759f33bd791308 Author: Xi Ruoyao Date: Mon Oct 30 19:39:27 2023 +0800 LoongArch: Define HAVE_AS_TLS to 0 if it's undefined [PR112299] Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure building a cross compiler if the cross assembler is not installed yet. gcc/ChangeLog: PR target/112299 * config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0 if not defined yet. (cherry picked from commit 6bf2cebe2bf49919c78814cb447d3aa6e3550d89)
[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #19 from GCC Commits ---
The releases/gcc-13 branch has been updated by LuluCheng
:
https://gcc.gnu.org/g:727ae33dae301d9ae5cc753493764ded1876a1ac
commit r13-8351-g727ae33dae301d9ae5cc753493764ded1876a1ac
Author: Xi Ruoyao
Date: Fri Nov 3 21:19:59 2023 +0800
LoongArch: Disable relaxation if the assembler don't support conditional
branch relaxation [PR112330]
As the commit message of r14-4674 has indicated, if the assembler does
not support conditional branch relaxation, a relocation overflow may
happen on conditional branches when relaxation is enabled because the
number of NOP instructions inserted by the assembler will be more than
the number estimated by GCC.
To work around this issue, disable relaxation by default if the
assembler is detected incapable to perform conditional branch relaxation
at GCC build time. We also need to pass -mno-relax to the assembler to
really disable relaxation. But, if the assembler does not support
-mrelax option at all, we should not pass -mno-relax to the assembler or
it will immediately error out. Also handle this with the build time
assembler capability probing, and add a pair of options
-m[no-]pass-mrelax-to-as to allow using a different assembler from the
build-time one.
With this change, if GCC is built with GAS 2.41, relaxation will be
disabled by default. So the default value of -mexplicit-relocs= is also
changed to 'always' if -mno-relax is specified or implied by the
build-time default, because using assembler macros for symbol addresses
produces no benefit when relaxation is disabled.
gcc/ChangeLog:
PR target/112330
* config/loongarch/genopts/loongarch.opt.in: Add
-m[no]-pass-relax-to-as. Change the default of -m[no]-relax to
account conditional branch relaxation support status.
* config/loongarch/loongarch.opt: Regenerate.
* configure.ac (gcc_cv_as_loongarch_cond_branch_relax): Check if
the assembler supports conditional branch relaxation.
* configure: Regenerate.
* config.in: Regenerate. Note that there are some unrelated
changes introduced by r14-5424 (which does not contain a
config.in regeneration).
* config/loongarch/loongarch-opts.h
(HAVE_AS_COND_BRANCH_RELAXATION): Define to 0 if not defined.
* config/loongarch/loongarch.h (ASM_MRELAX_DEFAULT): Define.
(ASM_MRELAX_SPEC): Define.
(ASM_SPEC): Use ASM_MRELAX_SPEC instead of "%{mno-relax}".
* doc/invoke.texi: Document -m[no-]relax and
-m[no-]pass-mrelax-to-as for LoongArch.
(cherry picked from commit fe23a2ff1f5072559552be0e41ab55bf72f5c79f)
[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #18 from GCC Commits ---
The releases/gcc-12 branch has been updated by LuluCheng
:
https://gcc.gnu.org/g:186381812dce832c95cc5c4ace47b0efb0aee41f
commit r12-10171-g186381812dce832c95cc5c4ace47b0efb0aee41f
Author: Xi Ruoyao
Date: Fri Nov 3 21:19:59 2023 +0800
LoongArch: Disable relaxation if the assembler don't support conditional
branch relaxation [PR112330]
As the commit message of r14-4674 has indicated, if the assembler does
not support conditional branch relaxation, a relocation overflow may
happen on conditional branches when relaxation is enabled because the
number of NOP instructions inserted by the assembler will be more than
the number estimated by GCC.
To work around this issue, disable relaxation by default if the
assembler is detected incapable to perform conditional branch relaxation
at GCC build time. We also need to pass -mno-relax to the assembler to
really disable relaxation. But, if the assembler does not support
-mrelax option at all, we should not pass -mno-relax to the assembler or
it will immediately error out. Also handle this with the build time
assembler capability probing, and add a pair of options
-m[no-]pass-mrelax-to-as to allow using a different assembler from the
build-time one.
With this change, if GCC is built with GAS 2.41, relaxation will be
disabled by default. So the default value of -mexplicit-relocs= is also
changed to 'always' if -mno-relax is specified or implied by the
build-time default, because using assembler macros for symbol addresses
produces no benefit when relaxation is disabled.
gcc/ChangeLog:
PR target/112330
* config/loongarch/genopts/loongarch.opt.in: Add
-m[no]-pass-relax-to-as. Change the default of -m[no]-relax to
account conditional branch relaxation support status.
* config/loongarch/loongarch.opt: Regenerate.
* configure.ac (gcc_cv_as_loongarch_cond_branch_relax): Check if
the assembler supports conditional branch relaxation.
* configure: Regenerate.
* config.in: Regenerate. Note that there are some unrelated
changes introduced by r14-5424 (which does not contain a
config.in regeneration).
* config/loongarch/loongarch-opts.h
(HAVE_AS_COND_BRANCH_RELAXATION): Define to 0 if not defined.
* config/loongarch/loongarch.h (ASM_MRELAX_DEFAULT): Define.
(ASM_MRELAX_SPEC): Define.
(ASM_SPEC): Use ASM_MRELAX_SPEC instead of "%{mno-relax}".
* doc/invoke.texi: Document -m[no-]relax and
-m[no-]pass-mrelax-to-as for LoongArch.
(cherry picked from commit fe23a2ff1f5072559552be0e41ab55bf72f5c79f)
[Bug target/112299] [14 Regression] Cross compiling to loongarch64-linux-gnuf64 fails because "HAVE_AS_TLS was not declared" after r14-4925-g1b30ef7cea773e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112299 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by LuluCheng : https://gcc.gnu.org/g:09de4b6b22bd66dacdade65ce633f29f302363b5 commit r12-10172-g09de4b6b22bd66dacdade65ce633f29f302363b5 Author: Xi Ruoyao Date: Mon Oct 30 19:39:27 2023 +0800 LoongArch: Define HAVE_AS_TLS to 0 if it's undefined [PR112299] Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure building a cross compiler if the cross assembler is not installed yet. gcc/ChangeLog: PR target/112299 * config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0 if not defined yet. (cherry picked from commit 6bf2cebe2bf49919c78814cb447d3aa6e3550d89)
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #24 from Peter Bergner --- (In reply to Jakub Jelinek from comment #23) > if the PowerPC backend maintainers wanted, there could be a similar workaround > on the rs6000 backend side, in the decisions whether the callee can use > the parameter save area or not ignore counting DECL_HIDDEN_STRING_LENGTH > PARM_DECLs, so if e.g. 9 arguments are passed but one of them is > DECL_HIDDEN_STRING_LENGTH, assume parameter save area is not there. If the callee has 9 arguments, even if one is a hidden str len arg, then there MUST be a parameter save area, since that is where the callee is supposed to load the 9th argument from. There is simply no other location that 9th argument exists at. I think the only viable rs6000 workaround is for the caller to allocate a parameter save area in some cases where it doesn't think it needs one. Ie, the caller is calling a function which it thinks has 8 parameters and there might be a hidden one (maybe one param is a string or whatever the Fortran CHARACTER with len great than 1 maps to) because the callee might be a Fortran routine. That would solve the problem of the callee scribbling data into the caller's frame, but wouldn't solve the issue of the caller didn't actually place a valid value for the missing hidden parameter. Thoughts on that?
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 Tom Tromey changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot gnu.org --- Comment #11 from Tom Tromey --- I have a patch.
[Bug target/114017] RISC-V: wrong __riscv_v_intrinsic predefined macro value (14.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114017 --- Comment #1 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:3688c2b1a604a16b9ff46935770976960016b15c commit r14-9128-g3688c2b1a604a16b9ff46935770976960016b15c Author: Pan Li Date: Wed Feb 21 12:06:22 2024 +0800 RISC-V: Upgrade RVV intrinsic version to 0.12 Upgrade the version of RVV intrinsic from 0.11 to 0.12. PR target/114017 gcc/ChangeLog: * config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Upgrade the version to 0.12. gcc/testsuite/ChangeLog: * gcc.target/riscv/predef-__riscv_v_intrinsic.c: Update the version to 0.12. * gcc.target/riscv/rvv/base/pr114017-1.c: New test. Signed-off-by: Pan Li
[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #7 from ptomsich at gcc dot gnu.org --- (In reply to Manolis Tsamis from comment #5) > On of these happens to precede a relevant vector statement and then > in one case combine does the umlal transformation but in the other not. Please attach the A/B dump-files for the combine pass.
[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #6 from ptomsich at gcc dot gnu.org --- (In reply to Manolis Tsamis from comment #5) > On of these happens to precede a relevant vector statement and then > in one case combine does the umlal transformation but in the other not. Please attach the A/B dump-files for the combine pass.
[Bug tree-optimization/114030] redundant load due to unions and different size loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|redundant load of inline|redundant load due to
|function's arguments|unions and different size
||loads
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-02-21
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
union U0 {
int f2;
char f4;
};
int g_3;
union U0 g_34 = {-1L};
char func_1() {
int t11 = g_34.f2;
char t1 = g_34.f4;
g_3 = t11;
return t1;
}
```
This is just due to unions. I am not sure if this is important to optimize
really since techincally the original code is undefined by the C/C++ standard
(though GCC does an extension which makes it defined). Unions used in this way
is not used much either.
[Bug target/114039] Unroll loops with SSE/AVX intrinsic where an immediate argument is a loop var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114039 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Component|c |target --- Comment #1 from Andrew Pinski --- This is not going to be fixed. This is how the intrinsics are specified. if you want to the switch statement, you can use a switch. You can do some tricks using the preprocessor to make things smaller though if you don't want to duplicate them.
[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #7 from GCC Commits --- The master branch has been updated by Edwin Lu : https://gcc.gnu.org/g:bc6b42666cfe1467774b942c7afabe480e3b5ccb commit r14-9123-gbc6b42666cfe1467774b942c7afabe480e3b5ccb Author: Edwin Lu Date: Wed Feb 14 12:06:38 2024 -0800 RISC-V: Quick and simple fixes to testcases that break due to reordering The following test cases are easily fixed with small updates to the expected assembly order. Additionally make calling-convention testcases more robust PR target/113249 gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c: Rearrange and adjust asm-checker times * gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c: Ditto * gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c: Ditto * gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c: Ditto * gcc.target/riscv/rvv/autovec/vls/calling-convention-5.c: Ditto * gcc.target/riscv/rvv/autovec/vls/calling-convention-6.c: Ditto * gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: Rearrange assembly * gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: Ditto * gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: Ditto * gcc.target/riscv/rvv/vsetvl/avl_single-107.c: Change expected vsetvl Signed-off-by: Edwin Lu
[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #6 from GCC Commits --- The master branch has been updated by Edwin Lu : https://gcc.gnu.org/g:67a29f99cc81384b9245ac5997e47bcf3ff84545 commit r14-9122-g67a29f99cc81384b9245ac5997e47bcf3ff84545 Author: Edwin Lu Date: Wed Feb 14 12:04:59 2024 -0800 RISC-V: Use default cost model for insn scheduling Use default cost model scheduling on these test cases. All these tests introduce scan dump failures with -mtune generic-ooo. Since the vector cost models are the same across all three tunes, some of the tests in PR113249 will be fixed with this patch series. PR target/113249 gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/bug-1.C: Use default scheduling * gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-102.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-108.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-114.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-119.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-50.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-56.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-62.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-68.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-74.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-79.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-84.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-90.c: Ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-96.c: Ditto * gcc.target/riscv/rvv/base/float-point-dynamic-frm-30.c: Ditto * gcc.target/riscv/rvv/base/pr108185-1.c: Ditto * gcc.target/riscv/rvv/base/pr108185-2.c: Ditto * gcc.target/riscv/rvv/base/pr108185-3.c: Ditto * gcc.target/riscv/rvv/base/pr108185-4.c: Ditto * gcc.target/riscv/rvv/base/pr108185-5.c: Ditto * gcc.target/riscv/rvv/base/pr108185-6.c: Ditto * gcc.target/riscv/rvv/base/pr108185-7.c: Ditto * gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: Ditto * gcc.target/riscv/rvv/vsetvl/pr111037-3.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-28.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-29.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-32.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-33.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_single_block-19.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: Ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: Ditto * gfortran.dg/vect/vect-8.f90: Ditto Signed-off-by: Edwin Lu
[Bug c/114039] New: Unroll loops with SSE/AVX intrinsic where an immediate argument is a loop var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114039
Bug ID: 114039
Summary: Unroll loops with SSE/AVX intrinsic where an immediate
argument is a loop var
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniil.iaitskov at soostone dot com
Target Milestone: ---
Lots of SSE/AVX intrinsic functions can accept only literal constants in
arguments.
Current workaround is turning a variable with a small cardinality into a switch
wrapped with a macro. I think extending unrolling semantic to this case should
help a lot with reducing code boilerplate.
Program expected to pass compilation:
```
#include
#include
inline __m128i testUnrollSse(__m128i x, __m128i d, int n) {
for (int i = n; i <= n; ++i) { // loop does always just a single iteration
return _mm_srli_si128(x, i);
}
return d;
}
__m128i foo(int i, __m128i x, __m128i d) {
if (i < 16) {
return testUnrollSse(x, d, i);
}
return d;
}
```
Compiler options: gcc -mavx2 -O3
```
Output of x86-64 gcc 13.2 (Compiler #1)
In file included from
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/include/xmmintrin.h:1322,
from
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/include/immintrin.h:31,
from :2:
In function '_mm_srli_si128',
inlined from 'testUnrollSse' at :6:12,
inlined from 'foo' at :13:16:
/opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/include/emmintrin.h:1229:19:
error: the last argument must be an 8-bit immediate
1229 | return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
| ^~~~
Compiler returned: 1
```
Expected code:
```
switch(i) {
case 1: return _mm_srli_si128(x, 1);
case 2: return _mm_srli_si128(x, 2);
// ...
case 16: return _mm_srli_si128(x, 16);
defaut:
fprintf(stderr, "Panic ", __FILE__, __LINE__, i);
exit(-1);
```
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #10 from Jakub Jelinek ---
So, I believe the really problematic change was r14-2389-g3cce8d98f270f48f
which introduced at least in theory the buffer overflow, before that the
maximum string length no matter what m_val was was 62 chars.
Now, I wonder what is the reason to have methods dump it into a buffer and then
dump the buffer to FILE *, when the former method is only used in the latter
method and nowhere else.
2024-02-21 Jakub Jelinek
PR ipa/111960
* profile-count.h (profile_count::dump): Remove overload with
char * first argument.
* profile-count.cc (profile_count::dump): Change overload with char *
first argument which uses sprintf into the overfload with FILE *
first argument and use fprintf instead. Remove overload which wrapped
it.
--- gcc/profile-count.h.jj 2024-01-03 11:51:30.309748150 +0100
+++ gcc/profile-count.h 2024-02-21 21:04:22.338905728 +0100
@@ -1299,9 +1299,6 @@ public:
/* Output THIS to F. */
void dump (FILE *f, struct function *fun = NULL) const;
- /* Output THIS to BUFFER. */
- void dump (char *buffer, struct function *fun = NULL) const;
-
/* Print THIS to stderr. */
void debug () const;
--- gcc/profile-count.cc.jj 2024-01-03 11:51:40.782602796 +0100
+++ gcc/profile-count.cc2024-02-21 21:05:28.521994913 +0100
@@ -84,34 +84,24 @@ const char *profile_quality_display_name
"precise"
};
-/* Dump THIS to BUFFER. */
+/* Dump THIS to F. */
void
-profile_count::dump (char *buffer, struct function *fun) const
+profile_count::dump (FILE *f, struct function *fun) const
{
if (!initialized_p ())
-sprintf (buffer, "uninitialized");
+fprintf (f, "uninitialized");
else if (fun && initialized_p ()
&& fun->cfg
&& ENTRY_BLOCK_PTR_FOR_FN (fun)->count.initialized_p ())
-sprintf (buffer, "%" PRId64 " (%s, freq %.4f)", m_val,
+fprintf (f, "%" PRId64 " (%s, freq %.4f)", m_val,
profile_quality_display_names[m_quality],
to_sreal_scale (ENTRY_BLOCK_PTR_FOR_FN (fun)->count).to_double
());
else
-sprintf (buffer, "%" PRId64 " (%s)", m_val,
+fprintf (f, "%" PRId64 " (%s)", m_val,
profile_quality_display_names[m_quality]);
}
-/* Dump THIS to F. */
-
-void
-profile_count::dump (FILE *f, struct function *fun) const
-{
- char buffer[64];
- dump (buffer, fun);
- fputs (buffer, f);
-}
-
/* Dump THIS to stderr. */
void
patch certainly fixes the buffer overflow... Or of course just enlarge the
buffer.
But, I don't really see anything that would bound sreal values to be within
some small double range, the range of m_exp is range of int, so in theory the
ldexp can always overflow to infinity or result in close to maximum finite
representable doubles.
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #9 from Jakub Jelinek ---
Ok, so what I see is a buffer overflow during
97 sprintf (buffer, "%" PRId64 " (%s, freq %.4f)", m_val,
98 profile_quality_display_names[m_quality],
99 to_sreal_scale (ENTRY_BLOCK_PTR_FOR_FN
(fun)->count).to_double ());
in
#0 profile_count::dump (this=0x7fffe9f37a18, buffer=0x7fffd7a0
"\300\327\377\377\377\177", fun=0x7fffea3020b8) at
../../gcc/profile-count.cc:97
#1 0x00c92609 in profile_count::dump (this=0x7fffe9f37a18,
f=0x3ab2930, fun=0x7fffea3020b8) at ../../gcc/profile-count.cc:111
#2 0x0065fefc in dump_bb_info (outf=0x3ab2930, bb=, indent=2, flags=266692985, do_header=true,
do_footer=false) at ../../gcc/cfg.cc:812
#3 0x0068f3eb in dump_bb (outf=0x3ab2930, bb=, indent=2, flags=266692985) at ../../gcc/cfghooks.cc:302
#4 0x00e31800 in dump_function_to_file (fndecl=, file=0x3ab2930, flags=266692985) at
../../gcc/tree-cfg.cc:8458
#5 0x00c4e038 in execute_function_dump (fn=0x7fffea3020b8,
data=0x3a156d0) at ../../gcc/passes.cc:1797
#6 0x00c4dbd9 in do_per_function (callback=0xc4dfd0
, data=0x3a156d0) at
../../gcc/passes.cc:1687
#7 0x00c503e1 in execute_one_pass (pass=) at ../../gcc/passes.cc:2722
buffer points to
107 void
108 profile_count::dump (FILE *f, struct function *fun) const
109 {
110 char buffer[64];
variable and the values I see are:
(gdb) p m_val
$18 = 2305843009213693950
(gdb) p profile_quality_display_names[m_quality]
$19 = 0x2ba5722 "estimated locally"
(gdb) p to_sreal_scale (((basic_block)0x7fffea2df600)->count, (bool *)
0).to_double ()
$20 = 1.4411518807585587e+17
So, that is 19 chars for m_val, 17 chars for the name and printing
144115188075855872. double value, 23 chars, plus 11 chars on top of that.
That is 70 chars, overflow by 6 bytes.
Whether the above comes from some badly initialized values or what, no idea.
That said, generally %PRId64 can print at most 20 chars, %s 38 chars and %.4f
can print
at most 309 digits before the decimal dot, then 1 char for the decimal dot and
4 digits after the dot.
That is already 69 chars without the double at all, plus 314 for the double.
Are you sure you want to print %.4f and not say %.4g so that there is a
reasonable upper bound for the size of the double printing? Or use %.4f or
%.4e conditionally depending on if the double is larger than some limit.
[Bug tree-optimization/114038] wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114038 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-21 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 57484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57484=edit gcc14-pr114038.patch Untested fix.
[Bug fortran/114023] complex part%ref of complex named constant array cannot be used in an initialization expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #1 from kargl at gcc dot gnu.org --- This one is a bit uglier. For the testcase, program foo implicit none complex(kind=8), parameter :: cmp1(3) = [(1,2),(3,4),(5,6)] real :: rr(3) = cmp1%re if (any(int(rr) /= [1,3,5])) then print '(3(F4.1))', rr stop 1 end if end one gets an ICE % gfcx -o z a.f90 && ./z a.f90:5:11: 5 | program foo | 1 internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.cc:6662 0x6eb2cf gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gccx/gcc/fortran/trans-array.cc:6662 This caused by the insertion of a conversion function __convert_r8_r4() into the initializer where gfc_conv_array_initializer() is not prepared to hand it. Now, if the type declaration of rr is changed to 'real(8)', then a conversion function is not inserted but wrong code is generated. I suspect that we need to go code spelunking in resolve.cc.
[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 --- Comment #6 from Richard Sandiford --- For me the miscompilation is in jkdmem_, where we end up allocating the same registers to both arms of an fcsel. It sounds like it occurs elsewhere too. I have a candidate fix, but need to think a bit more about it.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #17 from Jakub Jelinek --- Created attachment 57483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57483=edit gcc14-pr114007.patch So far very lightly tested fix. The FEs only use 8-bit flags on tokens unlike libcpp, so we are fairly tight on the bits there, fortunately PURE_ZERO is only used by C++ FE (though, set for both C/C++) and additionally only on CPP_NUMBERs, so reusing the same bit on CPP_COLON tokens in C FE + libcpp only (and only before C23 in strict modes) is I think fine. Still, the JOIN2(:,:) case works in C23 or GNU modes but not in the old modes, but that is because it is a preprocessor error, trying to paste tokens into something which is not a valid preprocessing token. I'm not afraid people would try to use that widely if they want < C23 compatibility of attributes.
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 57482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57482=edit patch The attached patch fixes this PR. It includes a new testcase and passes regression testing.
[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 --- Comment #5 from Tobias Burnus --- For: int *q; #pragma omp target device(y5) map(q, q[:5]) GCC currently generates: map(tofrom:q [len: 8]) map(tofrom:*q.4_1 [len: 20]) map(attach:q [bias: 0]) Expected: 'alloc:' instead of 'attach:' or even: map(tofrom:*q [len: 20]) map(firstprivate:q [pointer assign, bias: 0]) In any case, the first 'tofrom' is pointless! NOTE: GCC 13 shows: error: 'q' appears both in data and map clauses * * * For #pragma omp target map(s.p[:5]) GCC should do: map(tofrom:s [len: 24][implicit]) map(tofrom:*_5 [len: 16]) map(attach:s.p [bias: 0]) But (regression!) it does: map(struct:s [len: 1]) map(alloc:s.p [len: 8]) map(tofrom:*_5 [len: 16]) map(attach:s.p [bias: 0]) Solution: --- a/gcc/gimplify.cc +++ b/gcc/gimplify.cc @@ -12381,3 +12381,4 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p, if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_ATTACH - || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_DETACH) + || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_DETACH + || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_ATTACH_DETACH) break; However, unless I messed up, this will cause tons of ICE(segfault).
[Bug tree-optimization/114038] New: wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114038 Bug ID: 114038 Summary: wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57481=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9091-20240220194451-g0a6a5f8656c-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9091-20240220194451-g0a6a5f8656c-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)
[Bug target/113742] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx set) in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8416 with -O2 -finstrument-functions -mtune=sifive-p600-se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742 --- Comment #3 from GCC Commits --- The master branch has been updated by Edwin Lu : https://gcc.gnu.org/g:3232ebd91ed55b275b9d5a6e8355336382c4afd5 commit r14-9118-g3232ebd91ed55b275b9d5a6e8355336382c4afd5 Author: Edwin Lu Date: Tue Feb 20 13:53:40 2024 -0800 RISC-V: Specify mtune and march for PR113742 The testcase pr113742.c is failing for 32 bit targets due to the following cc1 error: cc1: error: ABI requries '-march=rv64' Specify '-march=rv64gc' with '-mtune=sifive-p600-series' PR target/113742 gcc/testsuite/ChangeLog: * gcc.target/riscv/pr113742.c: change mcpu to mtune and add march Signed-off-by: Edwin Lu
[Bug c/114029] -Warray-bounds does not warn for const global arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029 Andrew Pinski changed: What|Removed |Added Component|middle-end |c --- Comment #2 from Andrew Pinski --- const form is optimized/removed in the front-end
[Bug middle-end/114029] -Warray-bounds does not warn for global arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029 --- Comment #1 from Andrew Pinski --- Without `const`, GCC warns at -O2 also.
[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90798 --- Comment #15 from Andrew Pinski --- (In reply to ktkachov from comment #7) > Yes, GCC could be more helpful here. And the diagnostic issue with target option mismatch is recorded in PR 90798 though there might be some target specific changes needed really.
[Bug tree-optimization/111770] predicated loads inactive lane values not modelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #2 from Alex Coplan ---
I think to progress this and related cases we need to have .MASK_LOAD defined
to zero in the case that the predicate is false (either unconditionally for all
targets if possible or otherwise conditionally for targets where that is safe).
Here is a related case:
int bar(int n, char *a, char *b, char *c) {
int sum = 0;
for (int i = 0; i < n; ++i)
if (c[i] == 0)
sum += a[i] * b[i];
return sum;
}
in this case we get the missed optimization even before vectorization during
ifcvt (in some ways it is a simpler case to consider as only scalars are
involved). Here with -O3 -march=armv9-a from ifcvt we get:
[local count: 955630224]:
# sum_23 = PHI <_ifc__41(8), 0(18)>
# i_25 = PHI
_1 = (sizetype) i_25;
_2 = c_16(D) + _1;
_3 = *_2;
_29 = _3 == 0;
_43 = _42 + _1;
_4 = (char *) _43;
_5 = .MASK_LOAD (_4, 8B, _29);
_6 = (int) _5;
_45 = _44 + _1;
_7 = (char *) _45;
_8 = .MASK_LOAD (_7, 8B, _29);
_9 = (int) _8;
_46 = (unsigned int) _6;
_47 = (unsigned int) _9;
_48 = _46 * _47;
_10 = (int) _48;
_ifc__41 = .COND_ADD (_29, sum_23, _10, sum_23);
for this case it should be possible to use an unpredicated add instead of a
.COND_ADD. We essentially need to show that this transformation is valid:
_29 ? sum_23 + _10 : sum_23 --> sum_23 + _10
and this essentially boils down to showing that:
_29 = false => _10 = 0
now I'm not sure if there's a way of match-and-simplifying some GIMPLE
expression under the assumption that a given SSA name takes a particular value;
but if there were, and we defined .MASK_LOAD to zero given a false predicate,
then we could evaluate _10 under the assumption that _29 = false, which if we
added some simple match.pd rule for .MASK_LOAD with a false predicate would
allow it to evaluate to zero, and thus we could establish _10 = 0 proving the
transformation is correct. If such an approach is possible then I guess ifcvt
could use it to avoid conditionalizing statements unnecessarily.
Richi: any thoughts on the above or on how we should handle this sort of thing?
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #16 from Joseph S. Myers --- I think it's clear that __has_c_attribute(gnu::unused) should only return 1 if the [[gnu::unused]] syntax is actually parsed. (An unavoidable limitation if it might return 1 in pre-C23 modes is that if it's used with -pedantic / -pedantic-errors, such a usage of [[gnu::unused]] would then be diagnosed - since another principle is that -pedantic / -pedantic-errors should not affect semantics, in particular not change the return value of __has_c_attribute.) I also think that __has_c_attribute(gnu::unused) should always parse successfully in #if, even if it returns 0 in some cases. It's probably reasonable to accept :: in [[]] attributes in pre-C23 standard modes where those are two consecutive : tokens (the use of the [[]] syntax at all would result in a pedwarn-if-pedantic). Ideally there might be a marker on the tokens as suggested to indicate whether two such tokens would have been :: if in C23 mode, to avoid accepting other variants where the two tokens are separated in the sources. (The only reason it's not valid to produce a single preprocessing token in pre-C23 mode is to deal with corner cases such as ##-concatenating < :: > where the concatenations are valid in pre-C23 mode, producing digraphs equivalent to [], but invalid in C23 mode. Once the preprocessing tokens are converted to tokens, pre-C23 doesn't have any valid cases of two consecutive : tokens.)
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #17 from Joseph S. Myers --- The tests that GCC's internal notion of the types agrees with the headers are in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint-6.c.
[Bug sanitizer/114037] New: ASAN fork should ensure no unwind is in progress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114037 Bug ID: 114037 Summary: ASAN fork should ensure no unwind is in progress Product: gcc Version: 12.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: fhsueh at roku dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- On systems with slower unwind operations, multiple unwind can be in progress, held up by _dl_iterate_phdr() being serialized. In this case, the process may be fork()'ed while the mutex use by that function is in the locked state. When the child process runs to where ASAN does the unwind operation, that mutex will never be unlocked and no progress is made. Stacktrace: #0 __lll_lock_wait (futex=0x6956f544 <_rtld_local+1268>, private=0) at lowlevellock.c:43 #1 0x62b9d920 in __GI___pthread_mutex_lock (mutex=0x6956f544 <_rtld_local+1268>) at pthread_mutex_lock.c:116 #2 0x6065e56c in __GI___dl_iterate_phdr (callback=0x6065f518 <__gnu_Unwind_Find_exidx+40>, data=0x6065e56c <__GI___dl_iterate_phdr+52>, data@entry=0x50be5ddc) at dl-iteratephdr.c:41 #3 0x6065f518 in __gnu_Unwind_Find_exidx (pc=pc@entry=1761897354, pcount=0x50be5e04, pcount@entry=0x50be5dfc) at ../sysdeps/arm/find_exidx.c:74 #4 0x606b1fb0 in get_eit_entry (ucbp=ucbp@entry=0x50be5e18, return_address=1761897354) at gcc/libgcc/unwind-arm-common.inc:276 #5 0x606b2544 in __gnu_Unwind_Backtrace (trace=0x69046978 <__sanitizer::(anonymous namespace)::Unwind_Trace(_Unwind_Context*, void*)>, trace_argument=0x50be60c0, entry_vrs=) at gcc/libgcc/unwind-arm-common.inc:768 #6 0x606b2ef4 in _Unwind_Backtrace () at gcc/libgcc/config/arm/libunwind.S:360 #7 0x69046b8c in __sanitizer::BufferedStackTrace::UnwindSlow (this=0x50be6140, pc=pc@entry=1761766388, max_depth=max_depth@entry=30) at gcc/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cpp:130 #8 0x6903f6e4 in __sanitizer::BufferedStackTrace::Unwind (this=this@entry=0x50be6140, max_depth=30, max_depth@entry=1761766436, pc=pc@entry=1761766388, bp=bp@entry=1354655084, context=context@entry=0x0, stack_top=stack_top@entry=1354662664, stack_bottom=1353617408, request_fast_unwind=request_fast_unwind@entry=false) at gcc/libsanitizer/sanitizer_common/sanitizer_stacktrace_libcdep.cpp:157 #9 0x6902eff4 in __sanitizer::BufferedStackTrace::UnwindImpl (this=0x50be6140, pc=1761766388, bp=1354655084, context=0x0, request_fast=false, max_depth=30) at gcc/libsanitizer/asan/asan_stack.cpp:77 #10 0x68fa6f58 in __sanitizer::BufferedStackTrace::Unwind (this=this@entry=0x50be6140, pc=pc@entry=1761766388, bp=bp@entry=1354655084, context=context@entry=0x0, request_fast=request_fast@entry=false, max_depth=30) at gcc/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:131 #11 0x69026c24 in __interceptor_free (ptr=0x5e327c30) at gcc/libsanitizer/asan/asan_malloc_linux.cpp:52 #12 0x5fd8241a in ?? () from /lib/libmali.so.0 #13 0x605f5fa4 in __libc_fork () at ../sysdeps/nptl/fork.c:184 #14 0x6061a214 in __spawni (pid=pid@entry=0x5f3077e0, file=file@entry=0x606731f4 "", file_actions=file_actions@entry=0x50be6b84, attrp=attrp@entry=0x0, argv=0x50be6b74, argv@entry=0x1f, envp=0x5e1005e0, envp@entry=0x68fd1b48 (void *, int (*)(int *, const char *, const void *, const void *, char * const *, char * const *), __sanitizer::pid_t *, const char *, const void *, const void *, char * const *, char * const *)+1744>, xflags=xflags@entry=2) at ../sysdeps/posix/spawni.c:108 #15 0x6065f570 in __posix_spawn_compat (pid=pid@entry=0x5f3077e0, file=file@entry=0x606731f4 "", file_actions=file_actions@entry=0x50be6b84, attrp=attrp@entry=0x0, argv=argv@entry=0x50be6b74, envp=envp@entry=0x5e1005e0) at spawn.c:43 #16 0x68fd1b48 in PosixSpawnImpl(void *, int (*)(int *, const char *, const void *, const void *, char * const *, char * const *), __sanitizer::pid_t *, const char *, const void *, const void *, char * const *, char * const *) (ctx=0x50be6b14, ctx@entry=0x50be6b0c, real_posix_spawn=0x6065f54c <__posix_spawn_compat>, pid=pid@entry=0x5f3077e0, file_or_path=file_or_path@entry=0x606731f4 "", file_actions=file_actions@entry=0x50be6b84, attrp=attrp@entry=0x0, argv=argv@entry=0x50be6b74, envp=envp@entry=0x5e1005e0) at gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2449 #17 0x68fd1d3c in __interceptor_posix_spawn (pid=0x5f3077e0, path=0x606731f4 "", file_actions=0x50be6b84, attrp=0x0, argv=0x50be6b74, envp=0x5e1005e0) at gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2460 #18 0x605b86c8 in spawn_process (child_pipe_fd=, child_end=, parent_end=1354663776, pipe_fds=0x1, do_cloexec=0, command=0x50be79e0 "", fp=0x5f307740, fa=0x50be6b84) at iopopen.c:134 #19 _IO_new_proc_open (fp=fp@entry=0x5f307740, command=command@entry=0x50be79e0 "", mode=,
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 --- Comment #8 from Jakub Jelinek --- Ah, not that easily, only in -O0 built compilers, including stage1 of bootstrapped compilers, stage2/3 don't.
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 --- Comment #7 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #6) > Strange, reproduces for me just fine > /volume/tor/opt/notnfs/gcc-bisect/obj/gcc/cc1.r14-9114 -quiet -O > --param=max-inline-recursive-depth=100 > -fdump-tree-rebuild_frequencies-all pr111960.c > during GIMPLE pass: rebuild_frequencies > dump file: pr111960.c.111t.rebuild_frequencies1 > Segmentation fault (core dumped) Now I am guessing some stack corruption going on due to both the location of the crash and not everyone able to reproduce it.
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Strange, reproduces for me just fine /volume/tor/opt/notnfs/gcc-bisect/obj/gcc/cc1.r14-9114 -quiet -O --param=max-inline-recursive-depth=100 -fdump-tree-rebuild_frequencies-all pr111960.c during GIMPLE pass: rebuild_frequencies dump file: pr111960.c.111t.rebuild_frequencies1 Segmentation fault (core dumped)
[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail Component|target |testsuite --- Comment #2 from Andrew Pinski --- I think we should remove `-lgcov` from the dg-options here since -fgenerate-profile (and -ftest-coverage) will add it anyways. That is why you are getting 2 on the command line of ld/collect2.
[Bug modula2/114026] incorrect location during for loop type check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing now the patch has been applied. Another PR will be opened citing the BY incompatible expression type check failure.
[Bug modula2/114026] incorrect location during for loop type check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:161a67b2bee84d8fd5ab7711e411f76221c1ea52 commit r14-9116-g161a67b2bee84d8fd5ab7711e411f76221c1ea52 Author: Gaius Mulley Date: Wed Feb 21 16:21:05 2024 + PR modula2/114026 Incorrect location during for loop type checking If a for loop contains an incompatible type expression between the designator and the second expression then the location used when generating the error message is set to token 0. The bug is fixed by extending the range checking InitForLoopBeginRangeCheck. The range checking is processed after all types, constants have been resolved (and converted into gcc trees). The range check will check for assignment compatibility between des and expr1, expression compatibility between des and expr2. Separate token positions for des, exp1, expr2 and by are stored in the Range record and used to create virtual tokens if they are on the same source line. gcc/m2/ChangeLog: PR modula2/114026 * gm2-compiler/M2GenGCC.mod (Import): Remove DisplayQuadruples. Remove DisplayQuadList. (MixTypesBinary): Replace check with overflowCheck. New variable typeChecking. Use GenQuadOTypetok to retrieve typeChecking. Use typeChecking to suppress error message. * gm2-compiler/M2LexBuf.def (MakeVirtual2Tok): New procedure function. * gm2-compiler/M2LexBuf.mod (MakeVirtualTok): Improve comment. (MakeVirtual2Tok): New procedure function. * gm2-compiler/M2Quads.def (GetQuadOTypetok): New procedure. * gm2-compiler/M2Quads.mod (QuadFrame): New field CheckType. (PutQuadO): Rewrite using PutQuadOType. (PutQuadOType): New procedure. (GetQuadOTypetok): New procedure. (BuildPseudoBy): Rewrite. (BuildForToByDo): Remove type checking. Add parameters e2, e2tok, BySym, bytok to InitForLoopBeginRange. Push the RangeId. (BuildEndFor): Pop the RangeId. Use GenQuadOTypetok to generate AddOp without type checking. Call PutRangeForIncrement with the RangeId and IncQuad. (GenQuadOtok): Rewrite using GenQuadOTypetok. (GenQuadOTypetok): New procedure. * gm2-compiler/M2Range.def (InitForLoopBeginRangeCheck): Rename d as des, e as expr. Add expr1, expr1tok, expr2, expr2tok, byconst, byconsttok parameters. (PutRangeForIncrement): New procedure. * gm2-compiler/M2Range.mod (Import): MakeVirtual2Tok. (Range): Add expr2, byconst, destok, exprtok, expr2tok, incrementquad. (InitRange): Initialize expr2 to NulSym. Initialize byconst to NulSym. Initialize tokenNo, destok, exprtok, expr2tok, byconst to UnknownTokenNo. Initialize incrementquad to 0. (PutRangeForIncrement): New procedure. (PutRangeDesExpr2): New procedure. (InitForLoopBeginRangeCheck): Rewrite. (ForLoopBeginTypeCompatible): New procedure function. (CodeForLoopBegin): Call ForLoopBeginTypeCompatible and only code the for loop assignment if all the type checks succeed. gcc/testsuite/ChangeLog: PR modula2/114026 * gm2/extensions/run/pass/callingc10.mod: New test. * gm2/extensions/run/pass/callingc11.mod: New test. * gm2/extensions/run/pass/callingc9.mod: New test. * gm2/extensions/run/pass/strconst.def: New test. * gm2/pim/fail/forloop.mod: New test. * gm2/pim/pass/forloop2.mod: New test. Signed-off-by: Gaius Mulley
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #2)
> This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS
> 14.3).
> I am attaching the preprocessed source.
>
> The code from CFData.h that is triggering this is:
>
> typedef CF_OPTIONS(CFOptionFlags, CFDataSearchFlags) {
> kCFDataSearchBackwards = 1UL << 0,
> kCFDataSearchAnchored = 1UL << 1
> } API_AVAILABLE(macos(10.6), ios(4.0), watchos(2.0), tvos(9.0));
>
> which preprocesses to:
>
> typedef __attribute__((availability(swift,unavailable))) CFOptionFlags
> CFDataSearchFlags; enum : CFDataSearchFlags {
> kCFDataSearchBackwards = 1UL << 0,
> kCFDataSearchAnchored = 1UL << 1
> } ;
So - it seems we have an unguarded use of __attribute__ availability - we'll
need to track back to why API_AVAILABLE is not DTRT.
* I did post patches to enable us to consume the availability attribute, but
did not have time to address review comments got GCC-14; although it would
remain an option for darwin-local branches.
> There is similar code linked to the error in CFString.h:
>
> typedef CF_OPTIONS(CFOptionFlags, CFStringCompareFlags) {
> kCFCompareCaseInsensitive = 1,
> kCFCompareBackwards = 4,/* Starting from the end of the
> string */
> kCFCompareAnchored = 8, /* Only at the specified starting
> point */
> kCFCompareNonliteral = 16, /* If specified, loose equivalence
> is performed (o-umlaut == o, umlaut) */
> kCFCompareLocalized = 32, /* User's default locale is used for
> the comparisons */
> kCFCompareNumerically = 64, /* Numeric comparison is used; that
> is, Foo2.txt < Foo7.txt < Foo25.txt */
> kCFCompareDiacriticInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
> watchos(2.0), tvos(9.0)) = 128, /* If specified, ignores diacritics
> (o-umlaut == o) */
> kCFCompareWidthInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
> watchos(2.0), tvos(9.0)) = 256, /* If specified, ignores width differences
> ('a' == UFF41) */
> kCFCompareForcedOrdering API_AVAILABLE(macos(10.5), ios(2.0),
> watchos(2.0), tvos(9.0)) = 512 /* If specified, comparisons are forced to
> return either kCFCompareLessThan or kCFCompareGreaterThan if the strings are
> equivalent but not strictly equal, for stability when sorting (e.g. "aaa" >
> "AAA" with kCFCompareCaseInsensitive specified) */
> };
I guess the same glitch here.
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #3 from Francois-Xavier Coudert --- There's only one symbol we care about here, and its name is known, so I'll make a patch with your suggestion and test it.
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 --- Comment #3 from Francois-Xavier Coudert --- Created attachment 57480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57480=edit Preprocessed source
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #2 from Francois-Xavier Coudert ---
This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS 14.3).
I am attaching the preprocessed source.
The code from CFData.h that is triggering this is:
typedef CF_OPTIONS(CFOptionFlags, CFDataSearchFlags) {
kCFDataSearchBackwards = 1UL << 0,
kCFDataSearchAnchored = 1UL << 1
} API_AVAILABLE(macos(10.6), ios(4.0), watchos(2.0), tvos(9.0));
which preprocesses to:
typedef __attribute__((availability(swift,unavailable))) CFOptionFlags
CFDataSearchFlags; enum : CFDataSearchFlags {
kCFDataSearchBackwards = 1UL << 0,
kCFDataSearchAnchored = 1UL << 1
} ;
There is similar code linked to the error in CFString.h:
typedef CF_OPTIONS(CFOptionFlags, CFStringCompareFlags) {
kCFCompareCaseInsensitive = 1,
kCFCompareBackwards = 4,/* Starting from the end of the string
*/
kCFCompareAnchored = 8, /* Only at the specified starting point
*/
kCFCompareNonliteral = 16, /* If specified, loose equivalence is
performed (o-umlaut == o, umlaut) */
kCFCompareLocalized = 32, /* User's default locale is used for
the comparisons */
kCFCompareNumerically = 64, /* Numeric comparison is used; that is,
Foo2.txt < Foo7.txt < Foo25.txt */
kCFCompareDiacriticInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
watchos(2.0), tvos(9.0)) = 128, /* If specified, ignores diacritics (o-umlaut
== o) */
kCFCompareWidthInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
watchos(2.0), tvos(9.0)) = 256, /* If specified, ignores width differences ('a'
== UFF41) */
kCFCompareForcedOrdering API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0),
tvos(9.0)) = 512 /* If specified, comparisons are forced to return either
kCFCompareLessThan or kCFCompareGreaterThan if the strings are equivalent but
not strictly equal, for stability when sorting (e.g. "aaa" > "AAA" with
kCFCompareCaseInsensitive specified) */
};
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #2 from Iain Sandoe --- if there are lots of symbols that need to be undefined .. then one can use an undefined symbols file. Of course, it does not work if we do not know the symbol names at build-time.
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #1 from Iain Sandoe --- yeah, there is a better way to do this with ld64 (and presumably dyld-ld), my guess is that this is an anachronism from the ld_classic (v1) days. We can tell the linker it's OK for a symbol to be undefined - and then that makes it behave like the ELF case. "-Wl,-U,_symbol_name " is the incantation to do this - and AFAIK should work back to i686-darwin9 (which is the earliest I test these days).
[Bug target/114035] Failure of pr97172-2.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035 Francois-Xavier Coudert changed: What|Removed |Added Target||x86_64-apple-darwin23 Last reconfirmed||2024-02-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Target||x86_64-apple-darwin23 Ever confirmed|0 |1 Last reconfirmed||2024-02-21
[Bug target/114036] New: Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Bug ID: 114036
Summary: Test failure of gcov-14.c on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
FAIL: gcc.misc-tests/gcov-14.c (test for excess errors)
Excess errors:
ld: warning: -undefined suppress is deprecated
The test has specific option for darwin:
/* The following line arranges that Darwin has behavior like elf weak import.
*/
/* { dg-additional-options "-flat_namespace -undefined suppress" { target
*-*-darwin* } } */
Maybe on modern systems we should simply remove that? The test appears to be
passing anyway :)
[Bug target/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 --- Comment #1 from Iain Sandoe --- let me see if we're adding an extra in the Darwin specs that is covered elsewhere (sometimes the specs get changed in gcc/gcc.cc and it takes us some time to sync the ones in darwin.h)
[Bug target/114035] New: Failure of pr97172-2.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035 Bug ID: 114035 Summary: Failure of pr97172-2.c on darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- on x86_64-apple-darwin23 (https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/808546.html) I see: FAIL: gcc.dg/pr97172-2.c (test for excess errors) The excess error in question is really weird: Excess errors: ld: Undefined symbols: _f2_n, referenced from: _g2_n in ccFWgwRZ.o _f2_np1, referenced from: _g2_np1 in ccFWgwRZ.o _g2_nd2p1 in ccFWgwRZ.o _fn, referenced from: _gn in ccFWgwRZ.o _fn_3, referenced from: _gn_3 in ccFWgwRZ.o _fn_n, referenced from: _gn_n in ccFWgwRZ.o _fn_n_n, referenced from: _gn_n_n in ccFWgwRZ.o _fn_n_np1, referenced from: _gn_n_np1 in ccFWgwRZ.o _fn_np1, referenced from: _gn_np1 in ccFWgwRZ.o _fn_np1_np1, referenced from: _gn_np1_np1 in ccFWgwRZ.o _fna3_1, referenced from: _gna3_1 in ccFWgwRZ.o _fna3_2_3_4, referenced from: _gna3_2_3_4 in ccFWgwRZ.o _fnp1, referenced from: _gnp1 in ccFWgwRZ.o _gnd2p1 in ccFWgwRZ.o _fnp1_3, referenced from: _gnp1_3 in ccFWgwRZ.o _gnd2p1_3 in ccFWgwRZ.o _fnp1_np1, referenced from: _gnp1_np1 in ccFWgwRZ.o _gnd2p1_nd2p1 in ccFWgwRZ.o _fnp1_np1_np1, referenced from: _gnp1_np1_np1 in ccFWgwRZ.o _gnd2p1_nd2p1_nd2p1 in ccFWgwRZ.o _fx_n, referenced from: _gx_n in ccFWgwRZ.o _fx_np1, referenced from: _gx_np1 in ccFWgwRZ.o _gx_nd2p1 in ccFWgwRZ.o
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 --- Comment #1 from Iain Sandoe --- which actual SDK is this? you should be able to look at the SDKsettings.plist in the root of the SDK, if there's any need to discriminate versions with the same name. (and is it possible to get pre-processed output?) [I hope we do not have the situation where we have a broken header in the Frameworks ...]
[Bug target/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Target||x86_64-apple-darwin23 Last reconfirmed||2024-02-21 CC||iains at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/114034] New: Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Bug ID: 114034
Summary: Failure of tests gcov-dump-{1,2}.C
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
We have the following failures on x86_64-apple-darwin23:
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-1.C -std=gnu++20 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/gcov/gcov-dump-2.C -std=gnu++20 (test for excess errors)
Excess errors:
ld: warning: ignoring duplicate libraries: '-lgcov'
The compilation line only includes one -lgcov:
/Users/fx/ibin-20240219/gcc/testsuite/g++1/../../xg++
-B/Users/fx/ibin-20240219/gcc/testsuite/g++1/../../
/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/gcov/gcov-dump-1.C
-fdiagnostics-plain-output -nostdinc++
-I/Users/fx/ibin-20240219/x86_64-apple-darwin23/libstdc++-v3/include/x86_64-apple-darwin23
-I/Users/fx/ibin-20240219/x86_64-apple-darwin23/libstdc++-v3/include
-I/Users/fx/gcc-upstream/libstdc++-v3/libsupc++
-I/Users/fx/gcc-upstream/libstdc++-v3/include/backward
-I/Users/fx/gcc-upstream/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -fprofile-generate -ftest-coverage -lgcov
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-B/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/experimental/.libs
-B/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm/
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm/.libs -lm -o
./gcov-dump-1.exe
but the driver somehow includes another one when calling collect2:
/Users/fx/ibin-20240219/gcc/testsuite/g++1/../../collect2 -demangle -syslibroot
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64
-platform_version macos 14.0.0 0.0 -o ./gcov-dump-1.exe
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/experimental/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm/.libs
-L/Users/fx/ibin-20240219/gcc/testsuite/g++1/../..
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libstdc++-v3/src/.libs
-L/Users/fx/ibin-20240219/x86_64-apple-darwin23/./libitm -lemutls_w -lheapt_w
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccyOpfRM.o -lgcov -lstdc++
-lgcov -lgcc_s.1.1 -lgcc -lSystem -no_compact_unwind -rpath @loader_path -rpath
/Users/fx/ibin-20240219/gcc -rpath
/Users/fx/ibin-20240219/x86_64-apple-darwin23/libstdc++-v3/src/.libs -rpath
/Users/fx/ibin-20240219/x86_64-apple-darwin23/libitm
I'm wondering if it's a good idea to simply ignore the warning in the two test
cases. It's not such a frequent use case, and darwin linker to being a pain
here.
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed||2024-02-21 Ever confirmed|0 |1 Target||x86_64-apple-darwin23 Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org
[Bug target/114033] New: Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 Bug ID: 114033 Summary: Failure of test darwin-cfstring1.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- The test g++.dg/other/darwin-cfstring1.C fails on x86_64-apple-darwin23 for -std=gnu++14 and later: FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++17 (test for excess errors) FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++20 (test for excess errors) But the same test passes with -std=gnu++98: PASS: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for excess errors) The excess errors that result in failure are: Excess errors: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFData.h:67:9: error: 'unavailable' was not declared in this scope /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:420:9: error: 'unavailable' was not declared in this scope
[Bug c++/114031] gcc rejects valid code with pointer to member field cast inside a class not completed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114031
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
// PR c++/114031
struct A { int a; };
struct B:A {
int y = 0;
constexpr static bool b = (int A::*) ::y;
};
[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802 --- Comment #7 from Martin Jambor --- I have proposed a patch on the mailing list: https://inbox.sourceware.org/gcc-patches/ri6y1bdx3yg@virgil.suse.cz/T/#u
[Bug ipa/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Jambor --- Fixed.
[Bug ipa/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #15 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:c8742849e22d004b6ab94b3f573639f763e42e3a commit r14-9115-gc8742849e22d004b6ab94b3f573639f763e42e3a Author: Martin Jambor Date: Wed Feb 21 15:43:13 2024 +0100 ipa: Convert lattices from pure array to vector (PR 113476) In PR 113476 we have discovered that ipcp_param_lattices is no longer a POD and should be destructed. In a follow-up discussion it transpired that their initialization done by memsetting their backing memory to zero is also invalid because now any write there before construction can be considered dead. Plus that having them in an array is a little bit old-school and does not get the extra checking offered by vector along with automatic construction and destruction when necessary. So this patch converts the array to a vector. That however means that ipcp_param_lattices cannot be just a forward declared type but must be known to all code that deals with ipa_node_params and thus to all code that includes ipa-prop.h. Therefore I have moved ipcp_param_lattices and the type it depends on to a new header ipa-cp.h which now ipa-prop.h depends on. Because we have the (IMHO not a very wise) rule that headers don't include what they need themselves, I had to add inclusions of ipa-cp.h and sreal.h (on which it depends) to very many files, which made the patch rather ugly. gcc/lto/ChangeLog: 2024-02-16 Martin Jambor PR ipa/113476 * lto-common.cc: Include sreal.h and ipa-cp.h. * lto-partition.cc: Include ipa-cp.h, move inclusion of sreal higher. * lto.cc: Include sreal.h and ipa-cp.h. gcc/ChangeLog: 2024-02-16 Martin Jambor PR ipa/113476 * ipa-prop.h (ipa_node_params): Convert lattices to a vector, adjust initializers in the contructor. (ipa_node_params::~ipa_node_params): Release lattices as a vector. * ipa-cp.h: New file. * ipa-cp.cc: Include sreal.h and ipa-cp.h. (ipcp_value_source): Move to ipa-cp.h. (ipcp_value_base): Likewise. (ipcp_value): Likewise. (ipcp_lattice): Likewise. (ipcp_agg_lattice): Likewise. (ipcp_bits_lattice): Likewise. (ipcp_vr_lattice): Likewise. (ipcp_param_lattices): Likewise. (ipa_get_parm_lattices): Remove assert latticess is non-NULL. (ipa_value_from_jfunc): Adjust a check for empty lattices. (ipa_context_from_jfunc): Likewise. (ipa_agg_value_from_jfunc): Likewise. (merge_agg_lats_step): Do not memset new aggregate lattices to zero. (ipcp_propagate_stage): Allocate lattices in a vector as opposed to just in contiguous memory. (ipcp_store_vr_results): Adjust a check for empty lattices. * auto-profile.cc: Include sreal.h and ipa-cp.h. * cgraph.cc: Likewise. * cgraphclones.cc: Likewise. * cgraphunit.cc: Likewise. * config/aarch64/aarch64.cc: Likewise. * config/i386/i386-builtins.cc: Likewise. * config/i386/i386-expand.cc: Likewise. * config/i386/i386-features.cc: Likewise. * config/i386/i386-options.cc: Likewise. * config/i386/i386.cc: Likewise. * config/rs6000/rs6000.cc: Likewise. * config/s390/s390.cc: Likewise. * gengtype.cc (open_base_files): Added sreal.h and ipa-cp.h to the files to be included in gtype-desc.cc. * gimple-range-fold.cc: Include sreal.h and ipa-cp.h. * ipa-devirt.cc: Likewise. * ipa-fnsummary.cc: Likewise. * ipa-icf.cc: Likewise. * ipa-inline-analysis.cc: Likewise. * ipa-inline-transform.cc: Likewise. * ipa-inline.cc: Include ipa-cp.h, move inclusion of sreal.h higher. * ipa-modref.cc: Include sreal.h and ipa-cp.h. * ipa-param-manipulation.cc: Likewise. * ipa-predicate.cc: Likewise. * ipa-profile.cc: Likewise. * ipa-prop.cc: Likewise. (ipa_node_params_t::duplicate): Assert new lattices remain empty instead of setting them to NULL. * ipa-pure-const.cc: Include sreal.h and ipa-cp.h. * ipa-split.cc: Likewise. * ipa-sra.cc: Likewise. * ipa-strub.cc: Likewise. * ipa-utils.cc: Likewise. * ipa.cc: Likewise. * toplev.cc: Likewise. * tree-ssa-ccp.cc: Likewise. * tree-ssa-sccvn.cc: Likewise. * tree-vrp.cc: Likewise.
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #13 from Wilco --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646189.html
[Bug tree-optimization/114032] ifcvt may introduce UB calls to __builtin_clz(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Indeed, this feels like a bug, though unlikely to actually trigger anything
wrong.
I wouldn't worry that much about ifcvt IL, but about what makes it out of the
vectorizer.
void
foo (unsigned *p)
{
for (int i = 0; i < 1024; ++i)
p[i] = p[i] ? __builtin_clz (p[i]) : 42;
}
void
bar (unsigned *p)
{
for (int i = 0; i < 1024; ++i)
p[i] = p[i] ? __builtin_clz (p[i]) : 32;
}
with -O3 -mavx512{cd,bw,vl,dq} -mlzcnt -mbmi -mbmi2 -fvect-cost-model=unlimited
Before ifcvt we have conditional __builtin_clz in foo and .CLZ (_4, 32); in
bar,
and out of the vectorizer get the same .CLZ (vect__4.10_37, 32); in both cases,
that looks ok. But without the -mlzcnt -mbmi -mbmi2 options, we have
conditional __builtin_clz in both cases, and vectorizer results in .CLZ
(vect__4.10_37) in both cases. We don't have value ranges on vectors though,
so not really sure what could misbehave during the optimizations later on and I
bet all the targets which support vector .CLZ/.CTZ actually have some well
defined value for zero.
Maybe just the backends even for cases like -mlzcnt -mbmi -mbmi2 should
announce C?Z_VALUE_DEFINED_AT_ZERO for vector modes if it supports vector c?z
optabs? even
if it isn't defined for scalar?
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #15 from Jakub Jelinek --- (In reply to Richard Sandiford from comment #14) > I might have misunderstood the suggestion and so be arguing against > something that no-one is suggesting, but I think [[__extension__ …]] should > accept the same things for all standard versions (C23, pre-C23, and GNU). > It was intended to be something that header files and macros could use > without needing to be sensitive to the user's choice of standard. That is still the case of [[__extension__ arm::streaming]] and similar. The only thing in the suggestion that would be only sometimes allowed would be [[__extension__ arm: :streaming]] (or [[__extension__ arm:/**/:streaming]] etc. which I'd hope nobody is planning to use in the header files. Basically, with the flag_iso && !flag_isoc23 modes, :: is not one token but 2, and while we in some cases could look at location info if they are adjacent in the source, if column info isn't accurate (too long lines or too many lines) that information is lost. Or of course if you'd strongly like to accept [[__extension__ arm: :streaming]] in all language modes (but it won't be accepted in C++ anyway), I'd at least like to see accepting [[arm::streaming]] in the flag_iso && !flag_isoc23 modes (with the usual pedwarn). If we only wanted adjacent ::s and nothing in between, perhaps the preprocessor could set some flag on one of the CPP_COLONs (or both) if otherwise for CPP_OPTION (pfile, scope) it would be creating CPP_SCOPE, and check that flag during attribute and __has*attribute parsing?
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #14 from Richard Sandiford --- I might have misunderstood the suggestion and so be arguing against something that no-one is suggesting, but I think [[__extension__ …]] should accept the same things for all standard versions (C23, pre-C23, and GNU). It was intended to be something that header files and macros could use without needing to be sensitive to the user's choice of standard.
[Bug tree-optimization/114032] New: ifcvt may introduce UB calls to __builtin_clz(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
Bug ID: 114032
Summary: ifcvt may introduce UB calls to __builtin_clz(0)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
The ifcvt pass may make the code more UB, which can be seen by compiling the
following function with -O3 for X86_64:
int a, b, i;
int scaleValueSaturate(int value) {
if (value) {
int result = __builtin_clz(value);
if (-result <= a)
return 0;
}
return b;
}
short dst;
short *src;
void scaleValuesSaturate() {
for (; i; i++)
dst = scaleValueSaturate(src[i]);
}
What is happening here is that the code for .LOOP_VECTORIZED (1, 2) != 0 always
calls __builtin_clz, even when value is 0:
[local count: 955630224]:
# i.5_21 = PHI <_7(9), i.5_20(24)>
_2 = (long unsigned int) i.5_21;
_3 = _2 * 2;
_4 = src.2_1 + _3;
_5 = *_4;
value.0_11 = (unsigned int) _5;
result_14 = __builtin_clz (value.0_11);
_47 = (unsigned int) result_14;
_48 = -_47;
_15 = (int) _48;
_23 = _5 != 0;
_28 = _15 <= a.1_16;
_46 = _23 & _28;
prephitmp_31 = _46 ? 0 : _30;
dst = prephitmp_31;
_7 = i.5_21 + 1;
i = _7;
if (_7 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #13 from Jakub Jelinek ---
Ah, the thing is that while in -std=gnu* modes or -std=c23 the preprocessor
recognizes CPP_SCOPE as one token, in -std=c{89,99,11,17} modes it doesn't, ::
are 2 CPP_COLONs.
So, we could either:
--- gcc/c-family/c-lex.cc.jj2024-01-03 12:07:02.171734141 +0100
+++ gcc/c-family/c-lex.cc 2024-02-21 14:30:37.247945782 +0100
@@ -357,7 +357,24 @@ c_common_has_attribute (cpp_reader *pfil
do
nxt_token = cpp_peek_token (pfile, idx++);
while (nxt_token->type == CPP_PADDING);
- if (nxt_token->type == CPP_SCOPE)
+ if (!c_dialect_cxx ()
+ && flag_iso
+ && !flag_isoc23
+ && nxt_token->type == CPP_COLON)
+ {
+ do
+ nxt_token = cpp_peek_token (pfile, idx++);
+ while (nxt_token->type == CPP_PADDING);
+ if (nxt_token->type == CPP_COLON)
+ {
+ /* __has_attribute (vendor::attr) in -std=c17 etc. modes.
+:: isn't CPP_SCOPE in there and [[vendor::attr]] will
+not work, only [[__extension__ vendor::attr]]. */
+ have_scope = true;
+ get_token_no_padding (pfile); // Eat first colon.
+ }
+ }
+ if (nxt_token->type == CPP_SCOPE || have_scope)
{
have_scope = true;
get_token_no_padding (pfile); // Eat scope.
but then on testcase like:
#if __has_c_attribute (gnu::unused)
[[gnu::unused]]
#endif
int i;
#if __has_cpp_attribute (gnu::unused)
[[gnu::unused]]
#endif
int j;
fails to compile with e.g -std=c11:
pr114007.c:2:1: warning: ‘gnu’ attribute ignored [-Wattributes]
2 | [[gnu::unused]]
| ^
pr114007.c:2:6: error: expected ‘]’ before ‘:’ token
2 | [[gnu::unused]]
| ^
| ]
pr114007.c:6:1: warning: ‘gnu’ attribute ignored [-Wattributes]
6 | [[gnu::unused]]
| ^
pr114007.c:6:6: error: expected ‘]’ before ‘:’ token
6 | [[gnu::unused]]
| ^
| ]
or we could force always returning 0 from __has_attribute/__has_cpp_attribute
in that case, like:
--- gcc/c-family/c-lex.cc.jj2024-01-03 12:07:02.171734141 +0100
+++ gcc/c-family/c-lex.cc 2024-02-21 14:41:33.768992572 +0100
@@ -357,7 +357,33 @@ c_common_has_attribute (cpp_reader *pfil
do
nxt_token = cpp_peek_token (pfile, idx++);
while (nxt_token->type == CPP_PADDING);
- if (nxt_token->type == CPP_SCOPE)
+ if (!c_dialect_cxx ()
+ && flag_iso
+ && !flag_isoc23
+ && nxt_token->type == CPP_COLON)
+ {
+ do
+ nxt_token = cpp_peek_token (pfile, idx++);
+ while (nxt_token->type == CPP_PADDING);
+ if (nxt_token->type == CPP_COLON)
+ /* __has_attribute (vendor::attr) in -std=c17 etc. modes.
+ :: isn't CPP_SCOPE in there but 2 CPP_COLON tokens. */
+ have_scope = true;
+ }
+ if (have_scope)
+ {
+ /* [[vendor::attr]] will not work, only
+[[__extension__ vendor::attr]] will. Better always return 0
+for scoped attributes. */
+ get_token_no_padding (pfile); // Eat first colon.
+ get_token_no_padding (pfile); // Eat second colon.
+ nxt_token = get_token_no_padding (pfile);
+ if (nxt_token->type != CPP_NAME)
+ cpp_error (pfile, CPP_DL_ERROR,
+ "attribute identifier required after scope");
+ attr_name = NULL_TREE;
+ }
+ else if (nxt_token->type == CPP_SCOPE)
{
have_scope = true;
get_token_no_padding (pfile); // Eat scope.
The drawback of the second patch is that then users in -std=c{89,99,11,17}
modes don't have a way to query whether a certain scoped attribute is supported
in the preprocessor if they are aware that they need to use [[__extension__
vendor::attr]] rather then
[[vendor::attr]]. On the other side, e.g. in -std=gnu11 -pedantic-errors
compilation
we give 1 for __has_c_attribute (gnu::unused), but it is still rejected, just
with -std=c11 it is rejected even without -Wpedantic.
Maybe instead of loose_scope_p we should be using flag_iso && !flag_isoc23 and
accept [[vendor: :attr]] in the -std=c{89,99,11,17} modes too (with pedwarn for
the [[]] use), and on the other side reject [[__extension__ vendor: :attr]] in
-std=c23
or -std=gnu{89,99,11,17} modes, so that people don't feel using 2 colons rather
than a scope is correct. And then perhaps go with the first patch rather than
second.
Joseph/Richard, your thoughts on this?
[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646105.html
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from Jonathan Wakely --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) >> * When checking clang, there were more surprises: >> >> #define __INT8_TYPE__ signed char >> >> With very few exceptions, clang uses the default definitions of the >> intN_t types everywhere. > > That's interesting. I think GCC defines those __INTn_TYPE__ macros after > inspecting the target headers (assuming the target provides or > ) to ensure they agree. I wonder if Clang intentionally deviated Unfortunately not: gcc hardcodes all those types all over gcc/config (e.g. sol2.h) as INT8_TYPE. > from the Solaris headers to "fix" this issue, or if they just define > __INT8_TYPE__ to signed char for all 8-bit targets because "obviously" that's > correct for all targets (even though it isn't actually correct for Solaris). I guess no one cared enough about Solaris in Clang to notice this. There isn't even a test to check if Clang's internal idea of e.g. int8_t and that of the system headers match (but neither does gcc). > That means GCC and Clang will disagree about the mangling of a C++ function > like > void foo(int8_t); As I found, they won't: while their internal definitions of __INT8_TYPE__ differ, when one wants to use int8_t, one needs to include a corresponding header (//), thus will always get what the header defines. Only when using __INT8_TYPE__ directly will you get the mangled form of the compiler's internal idea of int8_t. To check what happens, I've re-run last night bootstraps (sparc and x86) with changed to define int8_t and friends as signed char, at the same time modifying gcc/config/sol2.h to match. The bootstrap (i386 so far, sparc still running, though I don't expect any difference) went without issues: the only regression seen is +UNRESOLVED: gdc.test/runnable_cxx/stdint.d compilation failed to produce executable +UNRESOLVED: gdc.test/runnable_cxx/stdint.d -shared-libphobos compilation failed to produce executable where the executable fails to link: Undefined first referenced symbol in file _Z15testCppI8Manglechchch /var/tmp//ccJLlOBa.o This test has D (stdint.d) and C++ (extra-files/stdint.cpp) components, checking the gdc and g++'s ideas of various types match. Unlike C/C++, where the definition of int8_t is from , D has it's equivalent in libphobos/libdruntime/core/stdc/stdint.d which will have to be adjusted, too. >> However, the question remains how much that counts: given clang/llvm >> has seen years of neglect on Solaris, I wonder how much actual code is >> really built with it on Solaris. >> >> * The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all >> AFAICT. If that's true, one could change the type's definition simply >> by adjusting , which would be nice and easy. > > I think those macros are a GCC thing not required by any standard. Oracle > Studio can just rely on being present, because they know that's > true > for Solaris. GCC can't (or couldn't historically) rely on being > present for all targets so needed some other way to make those types > available. I guess so: I just meant to find out if cc/CC has it's own idea of the types apart from the system headers. However, going forward, this can certainly learned from Oracle. I'll think given the information so far, I'll take the idea of changing int8_t for C99+ conformance to them and see what they think.
[Bug c++/114031] New: gcc rejects valid code with pointer to member field cast inside a class not completed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114031
Bug ID: 114031
Summary: gcc rejects valid code with pointer to member field
cast inside a class not completed
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: diagnostic, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
The following code is rejected by gcc 13 ,which does not trigger any error in
both clang and MSVC:
https://godbolt.org/z/5T7sx8vs8:
~
#include
struct A { int a; };
struct B:A {
int y=0;
constexpr static bool b=(int(A::*))::y;
};
int main(){
std::cout<:5:42: error: '::y' is not a constant expression when the class 'B'
is still incomplete
5 | constexpr static bool b=(int(A::*))::y;
| ^
~
Note that merely using ::y without the member pointer conversion
expression(int (A:: *)) does not trigger any error:
https://godbolt.org/z/7oErdvKv8.
If it's ::y that indeed causes the error, that shouldn't compile either.
This looks somewhat similar to PR107574. At least the error message needs
further improvement.
[Bug tree-optimization/114030] New: redundant load of inline function's arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030
Bug ID: 114030
Summary: redundant load of inline function's arguments
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
hi, here's the code. Redundant load will be introduced compiled with gcc-13.2.0
-O3.
```
// https://godbolt.org/z/3oGWq6anq
union U0 {
int f0;
long long f1;
int f2;
const unsigned char f3;
char f4;
};
union U2 {
char f0;
unsigned short f1;
unsigned short f2;
};
/* --- GLOBAL VARIABLES --- */
int g_3 = 0xD86E52D8L;
union U0 g_34 = {-1L};
union U2 g_35 = {0L};
int g_49 = 0xDC590CB2L;
int g_54[6][5] =
{{0L,0L,0L,0L,0L},{0x6833E1ABL,(-2L),0x6833E1ABL,(-2L),0x6833E1ABL},{0L,0L,0L,0L,0L},{0x6833E1ABL,(-2L),0x6833E1ABL,(-2L),0x6833E1ABL},{0L,0L,0L,0L,0L},{0x6833E1ABL,(-2L),0x6833E1ABL,(-2L),0x6833E1ABL}};
union U2 g_81 = {0L};
/* --- FORWARD DECLARATIONS --- */
static char(safe_rshift_func_int8_t_s_s)(char left, int right) { return
((left < 0) || (((int)right) < 0) || (((int)right) >= 32)) ? ((left))
: (left >> ((int)right));}
static unsigned char(safe_lshift_func_uint8_t_u_u)(unsigned char left, unsigned
int right) { return unsigned int)right) >= 32) || (left >
((255) >> ((unsigned int)right ? ((left)) :
(left << ((unsigned int)right));}
static char(safe_lshift_func_int8_t_s_s)(char left, int right) { return
((left < 0) || (((int)right) < 0) || (((int)right) >= 32) || (left >
((127) >> ((int)right ? ((left)) : (left <<
((int)right));}
void func_1(void);
void func_31(union U0 p_32, union U2 p_33);
int func_42(union U0 p_43, int * p_44);
void func_1() {
func_31(g_34, g_35);
}
void func_31(union U0 g, union U2 h) {
int *i = _3;
g_34.f2 = 1;
*i = func_42((safe_rshift_func_int8_t_s_s(0, g.f4), g), _49);
}
int func_42(union U0 j, int *k) {
unsigned l_51 = 4294967295UL;
int *l = _3;
*l = g_54[4][0] |=
~safe_lshift_func_uint8_t_u_u(safe_lshift_func_int8_t_s_s((0x7BD129AC07F4C733LL
^ l_51), 6), j.f3);
return j.f0;
}
```
compiled binary is:
```
004015b0 :
func_1():
/root/myCSmith/test/output2.c:57
4015b0: movzbl 0x2b49(%rip),%ecx# 404100 # not
necessary
4015b7: mov0x2b43(%rip),%edx# 404100
safe_lshift_func_uint8_t_u_u():
/root/myCSmith/test/output2.c:62
4015bd: mov$0xff33,%eax
func_31():
/root/myCSmith/test/output2.c:62
4015c2: movl $0x1,0x2b34(%rip)# 404100
safe_lshift_func_uint8_t_u_u():
/root/myCSmith/test/output2.c:49
4015cc: cmp$0x1f,%cl
4015cf: ja 4015ec
/root/myCSmith/test/output2.c:49 (discriminator 1)
4015d1: mov$0xff,%esi
4015d6: sar%cl,%esi
4015d8: cmp$0xcb,%esi
4015de: jle4015ec
/root/myCSmith/test/output2.c:49 (discriminator 3)
4015e0: mov$0xcc,%eax
4015e5: shl%cl,%eax
func_42():
/root/myCSmith/test/output2.c:69 (discriminator 2)
4015e7: movzbl %al,%eax
4015ea: not%eax
/root/myCSmith/test/output2.c:68
4015ec: or %eax,0x2ade(%rip)# 4040d0
func_31():
/root/myCSmith/test/output2.c:63 (discriminator 2)
4015f2: mov%edx,0x2b10(%rip)# 404108
func_1():
/root/myCSmith/test/output2.c:58
4015f8: retq
4015f9: nopl 0x0(%rax)
```
the load at address 0x4015b0 is redundant.
This behavior is regression with gcc-13.2.0 and a necessary flag -O3, and can
be triggered with gcc-8.2.0 with -O2 flag.
if compiled with gcc-13.2.0 -O2, there won't be such a load operation.
[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 --- Comment #18 from Jakub Jelinek --- Created attachment 57479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57479=edit gcc14-pr113988.patch Full untested patch for that variant.
[Bug target/113542] [14 Regression] gcc.target/arm/bics_3.c regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542 Maxim Kuvyrkov changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org Assignee|mkuvyrkov at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Maxim Kuvyrkov --- Reply from Richard Earnshaw on gcc-patches@ to my patch to make the testcase accept both "bic" and "bics" instructions: The test was added (r6-823-g0454e698401a3e) specifically to check that a BICS instruction was being generated. Whether or not that is right is somewhat debatable, but this change seems to be papering over a different issue. Either we should generate BICS, making this change incorrect, or we should disable the test for thumb code on the basis that this isn't really a win. But really, we should fix the compiler to do better here. We really want something like BICS r0, r0, r1 // r0 is 0 or non-zero MOVNE r0, #1 // convert all non-zero to 1 in Arm state (ie using the BICS instruction to set the result to zero); and in thumb2, perhaps something like: BICS r0, r0, r1 ITne MOVNE r0, #1 or maybe even better: BIC r0, r0, r1 SUBS r1, r0, #1 SBC r0, r0, r1 which is slightly better than BICS because SUBS breaks a condition-code chain (all the flag bits are set). There are similar quality issues for other NE(arith-op, 0) cases; we just don't have tests for those.
[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #17 from Jakub Jelinek ---
So, I've tried
--- gcc/gimple-lower-bitint.cc.jj 2024-02-15 09:52:40.999145971 +0100
+++ gcc/gimple-lower-bitint.cc 2024-02-21 12:48:38.704163901 +0100
@@ -5307,12 +5307,15 @@ bitint_large_huge::lower_stmt (gimple *s
final_cast_p = true;
if (TREE_CODE (TREE_TYPE (lhs)) == INTEGER_TYPE
&& TYPE_PRECISION (TREE_TYPE (lhs)) > MAX_FIXED_MODE_SIZE
- && gimple_assign_rhs_code (stmt) == VIEW_CONVERT_EXPR)
+ && (gimple_assign_rhs_code (stmt) == VIEW_CONVERT_EXPR
+ || (TYPE_PRECISION (TREE_TYPE (lhs))
+ == TYPE_PRECISION (TREE_TYPE (rhs1)
{
- /* Handle VIEW_CONVERT_EXPRs to not generally supported
-huge INTEGER_TYPEs like uint256_t or uint512_t. These
-are usually emitted from memcpy folding and backends
-support moves with them but that is usually it. */
+ /* Handle VIEW_CONVERT_EXPRs or same precision casts to not
+generally supported huge INTEGER_TYPEs like uint256_t or
+uint512_t. These are usually emitted from memcpy folding
+and backends support moves with them but that is usually
+it. */
if (TREE_CODE (rhs1) == INTEGER_CST)
{
rhs1 = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (lhs),
@@ -5339,6 +5342,7 @@ bitint_large_huge::lower_stmt (gimple *s
rhs1 = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs),
m_vars[part]);
gimple_assign_set_rhs1 (stmt, rhs1);
+ gimple_assign_set_rhs_code (stmt, VIEW_CONVERT_EXPR);
}
update_stmt (stmt);
return;
and while that fixes #c14 bar and qux, foo and baz still ICE, this time during
expansion:
pr113988.c: In function ‘foo’:
pr113988.c:12:3: internal compiler error: in convert_move, at expr.cc:223
12 | __builtin_memcpy (p, , sizeof x);
| ^~
0x801435 convert_move(rtx_def*, rtx_def*, int)
../../gcc/expr.cc:223
0x826b99 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.cc:9799
0x82c8f5 expand_expr_real_gassign(gassign*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11096
0x82d4b2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11277
0x825541 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.cc:9440
0x81a2df store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.cc:6740
0x818717 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.cc:6461
The problem is that for bar/qux it is a VCE from an array, so nothing tries to
change it into something else, for e.g. foo bitintlower turns it into
uint256_t _2;
[local count: 1073741824]:
_2 = VIEW_CONVERT_EXPR(x);
MEM [(char * {ref-all})p_4(D)] = _2;
where x is TREE_ADDRESSABLE _BitInt(256) PARM_DECL, but forwprop3 turns that
into
_2 = (uint256_t) x_1(D);
and expansion isn't able to expand that (BLKmode PARM_DECL expanded as a MEM
NOP_EXPR converted to OImode.
So, either we could somehow handle that case during expansion (treat it
basically as VCE), or tweak the
/* For integral conversions with the same precision or pointer
conversions use a NOP_EXPR instead. */
(simplify
(view_convert @0)
(if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type))
&& (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
&& TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0)))
(convert @0)))
match.pd rule not to do that for INTEGER_TYPEs with PRECISION >
MAX_FIXED_TYPE_PRECISION (then we don't need the gimple-lower-bitint.cc changes
either).
--- gcc/match.pd.jj 2024-02-19 09:42:16.583617451 +0100
+++ gcc/match.pd2024-02-21 13:32:06.567816298 +0100
@@ -4679,7 +4679,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(view_convert @0)
(if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type))
&& (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE
(@0)))
- && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0)))
+ && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))
+ /* Punt for conversions from or to barely supported huge
+ INTEGER_TYPEs. Those can handle just loads/stores/moves but
+ nothing else. */
+ && (TYPE_PRECISION (type) <= MAX_FIXED_MODE_SIZE
+ || (TREE_CODE (type) != INTEGER_TYPE
+ && TREE_CODE (TREE_TYPE (@0)) != INTEGER_TYPE)))
(convert @0)))
/* Strip inner integral conversions that do not change precision or size, or
[Bug target/113994] [13/14 Regression] Probable C++ code generation bug with -O2 on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994 --- Comment #5 from Jakub Jelinek --- Bisected to r13-1268-g8c99e307b20c502e55c425897fb3884ba8f05882 . But that just means the bug was latent before that.
[Bug middle-end/114029] New: -Warray-bounds does not warn for global arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029
Bug ID: 114029
Summary: -Warray-bounds does not warn for global arrays
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Testcase https://gcc.godbolt.org/z/n3zPPE7bq
const int test[]={1, 2, 3};
int main()
{
return test[3];
}
GCC doesn't warn under -O2 -Wall. It does emit a -Warray-bounds warning if the
`test` array is moved inside `main`; but why not warning for a global variable?
For comparison, Clang always warns (even without any optimization/warning
flag).
[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |13.3 Keywords||accepts-invalid
[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #14 from Jakub Jelinek --- Ah, ok, in that case it can wait for stage1.
[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #5 from Manolis Tsamis --- Also, I further investigated the codegen difference in the second example (zip + umlal vs umull) and it looks to be some sort of RTL ordering + combine issue. Specifically, when the we expand the RTL for the example there are some very slight ordering differences where some non-dependent insns have swapped order. On of these happens to precede a relevant vector statement and then in one case combine does the umlal transformation but in the other not. Afaik combine has some limits about the instruction window that it looks, so it looks feasible that ordering differences in RTL can later transform into major codegen differences in a number of ways. Other differences seem to come from register allocation, as you mentioned. This doesn't yet provide any useful insights whether the vectorization improvements are accidental or not.
[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #18 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #15) > void nexttoward(float32_t, long double) = delete; > void nexttoward(float64_t, long double) = delete; > void nexttoward(float128_t, long double) = delete; > > We could also add deleted overloads for bfloat16_t and float16_t although > they don't currently compile anyway, because the float/double/long double > overloads are ambiguous. For consistency in diagnostics, I think defining > them all as deleted would be better. The suitable preprocessor conditions could be by placing those declarations (of course with _Float32, _Float64, _Float128, _Float16 etc., cmath doesn't rely on stdfloat inclusion) right after the nextafter _Float32 etc. overloads. Anyway, if your template works properly even for the integers, even better.
[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #4 from Manolis Tsamis --- Hi Andrew, Thank for your insights on this. Let me reply to some of your points: (In reply to Andrew Pinski from comment #1) > >The most important case I have observed is that the vectorizer can fail or > >create inferior code with more shuffles/moves when the SSA names aren't > >monotonically increasing. > > That should not be true. Indeed, after further cleaning-up the dumps, some differences that I was considering were just due to the diff algorithm not doing a good job and that confused me (sigh). So, for this example while we're in tree form I observe only naming changes, but no different code or order of statements. (In reply to Andrew Pinski from comment #2) > Note what I had found in the past it is not exactly SSA_NAMEs that cause the > difference but rather the RTL register pesdu # causes differences in > register allocation which was exposed from the different in operands > canonicalization. Yes, I have also observed this and it looks to be the main issue. (In reply to Andrew Pinski from comment #3) > The first example (of assembly here) in comment #0 is extra moves due to the > RA not handling subreg that decent for the load/store lane. There are other > bug reports dealing with that. Why the SSA_NAMES being monotonically help is > just by an accident really. > > Do you happen to recall the relevant ticket(s)? I would like to have a look but couldn't find them so far. Also, while I agree than in some cases changes like this 'just happen' to improve codegen in some particular case, it was in multiple experiments that vectorized code was superior with sorted names and it never was worse with sorted names. In most cases that I recall the version that used unsorted names had additional shuffles of different sorts or moves. So, which anecdotal, the effects doesn't look accidental to me in this case. I feel like there may be some subtle difference due to the names that helps in this case? > > Also: > > This mostly affects all the bitmaps that use SSA_NAME_VERSION as a key. > > Most use sparse bitmaps there so it is not a big deal. > Agreed and that's probably why I couldn't measure any non-trivial difference in compilation times. I should just note that there are also places that create vectors or other data structures sized to the number of ssa_names, so in theory this could still help in extreme cases. > I think this should be split up in a few different bug reports really. > One for each case where better optimizations happen. > Ok, the only cases that I found to be clearly better are the ones related to vectorization. Would it help to create a ticket just for that now, or should I wait for the discussion in this one to conclude first? > Also: > >I have seen two similar source files generating the exact same GIMPLE code > >up to some optimization pass but then completely diverging due to different > >freelists. > > The only case where I have seen this happen is expand will have different > pesdu # really. Yes I noticed this effect while I did > r14-569-g21e2ef2dc25de3 really. Afaik, the codegen differences that I observed was due to the same reason, but it nonetheless felt weird that the same GIMPLE could produce two different w.r.t. name ordering files later on just because the freelists were different (but invisible in the dumps). So I naturally questioned 'why don't we just flush the freelists after every pass if it's not a performance issue'?
[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #17 from Jonathan Wakely --- Or just: template __enable_if_t::value> nexttoward(_Tp, long double) = delete; So that it is present for C++11 and so works when _Float32 and _Float64 names are used instead of the C++23 aliases.
[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #16 from Jonathan Wakely --- We could also just add: #if __cplusplus > 202002L template void nexttoward(_Tp, long double) = delete; #endif The existing overloads would be preferred for float, double, long double and integral types, so this would only be chosen for extended floating-point types.
[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #13 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #12) > (In reply to Aldy Hernandez from comment #11) > > Both patches pass test. Up to the release maintainers to decide if they > > want to include them in this release. Otherwise, I'll queue them up for > > later. > > This is an important regression, why shouldn't it be included in GCC 14? > GCC trunk is open for regression and documentation fixes... Martin's change to IPA fixes the leak in the PR. My changes are just cleanups, as no other pass is using ranges in GC space.
[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #15 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #13) > Then I wonder what was the reason for the final LWG3790 revision, the middle > proposed resolution seems to be much more readable and understandable where > one could see exactly what is valid in the synopsis and if the standard > attempts to save lines, > the extra 2 lines in the synopsis are the same size as the extra paragraph > hidden at the end. Ah, I've checked the minutes, and the reason for the final form of the wording is that we wanted to prevent: std::nexttoward((std::float32_t)0, 0.0L) With the three overloads for float/double/long double (as implemented in libstdc++ today) that would be well-formed if float is IEEE binary32. There is an implicit conversion to float, but that means it returns a float, not a _Float32 as you would expect it to. Similarly for nexttoward((std::float64_t)0, 0.0L). So we do need a change here, because we need to explicitly make that ill-formed. Maybe just (with suitable preprocessor checks for the types): void nexttoward(float32_t, long double) = delete; void nexttoward(float64_t, long double) = delete; void nexttoward(float128_t, long double) = delete; We could also add deleted overloads for bfloat16_t and float16_t although they don't currently compile anyway, because the float/double/long double overloads are ambiguous. For consistency in diagnostics, I think defining them all as deleted would be better.
[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #13 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:c8c587b854c9e85fc9ce58c8192d532205f0ee1f commit r14-9104-gc8c587b854c9e85fc9ce58c8192d532205f0ee1f Author: Tamar Christina Date: Wed Feb 21 11:42:13 2024 + AArch64: skip modes_1.f90 [PR107071] This test has never worked on AArch64 since the day it was committed. It has a number of issues that prevent it from working on AArch64: The testfailures seem to be known and triaged, so until that's fixed there's no point in running this test. gcc/testsuite/ChangeLog: PR fortran/107071 * gfortran.dg/ieee/modes_1.f90: skip aarch64, arm.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #15 from Jonathan Wakely --- (In reply to r...@cebitec.uni-bielefeld.de from comment #14) > Further research has uncovered some interesting facts: > > * Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386 > psABI (4th Edition, 1997) specify int8_t at all. Actually no wonder > because both predate C99. > > However, even the current Intel386 psABI 1.1 (2015) has nothing here, > nor does the AMD64 psABI 1.0 (2024). > > To my astonishment however, the SPARC Compliance Definition 2.4.1 > (1999), defacto if not in name the SPARC V9 psABI, lists in Figure > 6-140: , p.6P-13: > > typedef signed char int8_t; > > So it seems at least Solaris/SPARCV9 violates its own ABI ;-( Ouch! > * When checking clang, there were more surprises: > > #define __INT8_TYPE__ signed char > > With very few exceptions, clang uses the default definitions of the > intN_t types everywhere. That's interesting. I think GCC defines those __INTn_TYPE__ macros after inspecting the target headers (assuming the target provides or ) to ensure they agree. I wonder if Clang intentionally deviated from the Solaris headers to "fix" this issue, or if they just define __INT8_TYPE__ to signed char for all 8-bit targets because "obviously" that's correct for all targets (even though it isn't actually correct for Solaris). That means GCC and Clang will disagree about the mangling of a C++ function like void foo(int8_t); > However, the question remains how much that counts: given clang/llvm > has seen years of neglect on Solaris, I wonder how much actual code is > really built with it on Solaris. > > * The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all > AFAICT. If that's true, one could change the type's definition simply > by adjusting , which would be nice and easy. I think those macros are a GCC thing not required by any standard. Oracle Studio can just rely on being present, because they know that's true for Solaris. GCC can't (or couldn't historically) rely on being present for all targets so needed some other way to make those types available. Thanks for digging into this!
[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- (In reply to Aldy Hernandez from comment #11) > Both patches pass test. Up to the release maintainers to decide if they > want to include them in this release. Otherwise, I'll queue them up for > later. This is an important regression, why shouldn't it be included in GCC 14? GCC trunk is open for regression and documentation fixes...
[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #11 from Aldy Hernandez --- Both patches pass test. Up to the release maintainers to decide if they want to include them in this release. Otherwise, I'll queue them up for later.
[Bug target/113995] ICE: in change_address_1, at emit-rtl.cc:2299 with [[arm::streaming_compatible]] and -march=armv9-a+sve -finstrument-functions -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Sandiford --- Fixed.
[Bug target/113220] [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Sandiford --- Fixed
