[Bug c++/109385] decltype in lambda causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109385
--- Comment #2 from Andrew Pinski ---
clang rejects it with:
:4:16: error: expression contains unexpanded parameter pack 'vals'
return [=]() {
^
:9:10: error: variable has incomplete type 'void'
auto result = sort_fn();
^
[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707 --- Comment #9 from Andrew Pinski --- (In reply to rvalue from comment #8) > (In reply to Andrew Pinski from comment #7) > > > since all modern operating systems have a large enough parameter space > > > (all of them have 262k at least). > > > > Windows still does not > > I don't think this code will make anything better or worse in Windows since > it simply compares the path with "/lib/" and "/usr/lib/", which never exist > in Windows. Cross compilers ...
[Bug c++/109385] decltype in lambda causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109385 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-04-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100035 --- Comment #3 from Andrew Pinski --- Confirmed. Related to PR 100035.
[Bug tree-optimization/109386] New: [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386
Bug ID: 109386
Summary: [13 Regression] Frange value relation related
miscompilation
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
I've totally missed a regression caused by my recent frange improvements (most
likely
r13-6967-g5fe05ffefd21c4fa):
+FAIL: libphobos.phobos/std/math/algebraic.d execution test
+FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test
Reduced testcase in C:
static inline float
foo (float x, float y)
{
float u = __builtin_fabsf (x);
float v = __builtin_fabsf (y);
if (!(u >= v))
{
v = u;
u = __builtin_fabsf (y);
if (__builtin_isinf (u)) return u;
if (__builtin_isinf (v)) return v;
}
return 42.0f;
}
int
main ()
{
if (!__builtin_isinf (foo (__builtin_inff (), __builtin_nanf (""
__builtin_abort ();
}
for -O2.
I believe the bug is that (as discussed earlier) we don't implement the full
set of VREL_* relations for the case where NAN may be seen and in this case
register VREL_LT for the if block, which is wrong, the inverse of VREL_GE is
VREL_UNLT which we don't currently have.
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0
[Bug c++/109387] New: "definition of explicitly-defaulted" error with explicit template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109387
Bug ID: 109387
Summary: "definition of explicitly-defaulted" error with
explicit template instantiation
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
Given this code:
template struct S { S(); };
// extern template struct S;
template S::S() = default;
template S::S();
GCC fails to compile with this error:
error: definition of explicitly-defaulted 'S<
>::S()
[with = int]'
3 | template S::S() = default;
| ^~~~
Uncommenting the extern template fixes compilation. Clang compiles the original
code without any issue.
Live example on Compiler Explorer:
- https://gcc.godbolt.org/z/YoPhvKnxa
Related StackOverflow thread:
- https://stackoverflow.com/questions/75913223
[Bug modula2/109388] New: clang warnings related to Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109388 Bug ID: 109388 Summary: clang warnings related to Modula-2 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- I see some clang warnings related to M2: m2/gm2-compiler-boot/M2GCCDeclare.c:8085:67: warning: unused parameter 'module' [-Wunused-parameter] m2/gm2-compiler-boot/PHBuild.c:3384:13: warning: unused function 'PeepToken' [-Wunused-function] m2/gm2-compiler-boot/PHBuild.c:3880:13: warning: unused function 'PushQualident' [-Wunused-function] m2/gm2-compiler-boot/PHBuild.c:6735:13: warning: unused function 'SimpleDes' [-Wunused-function] m2/gm2-compiler-boot/PHBuild.c:6755:13: warning: unused function 'ActualParameters' [-Wunused-function]
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #1 from Jakub Jelinek --- Created attachment 54802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54802&action=edit gcc13-pr109386.patch Untested patch. I've tried to fix the incorrect registraction of value relation (in the scope of the current set of VREL_*), but unfortunately it didn't fix it.
[Bug driver/108241] [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108241 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615048.html
[Bug driver/108241] [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108241 --- Comment #3 from Martin Liška --- (In reply to Martin Liška from comment #2) > Patch candidate: > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615048.html Sorry, this link: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615044.html
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #16 from Martin Liška --- Patch candidate has been sent: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615048.html
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #8 from Martin Liška --- Patch candidate has been sent: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615048.html
[Bug rtl-optimization/108086] [11/12 Regression] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086 --- Comment #18 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:160c5f354a6dc8a660ff8ad8574279b0d3fb412d commit r12-9377-g160c5f354a6dc8a660ff8ad8574279b0d3fb412d Author: Richard Sandiford Date: Mon Apr 3 09:57:05 2023 +0100 rtl-ssa: Extend m_num_defs to a full unsigned int [PR108086] insn_info tried to save space by storing the number of definitions in a 16-bit bitfield. The justification was: // ... FIRST_PSEUDO_REGISTER + 1 // is the maximum number of accesses to hard registers and memory, and // MAX_RECOG_OPERANDS is the maximum number of pseudos that can be // defined by an instruction, so the number of definitions should fit // easily in 16 bits. But while that reasoning holds (I think) for real instructions, it doesn't hold for artificial instructions. I don't think there's any sensible higher limit we can use, so this patch goes for a full unsigned int. gcc/ PR rtl-optimization/108086 * rtl-ssa/insns.h (insn_info): Make m_num_defs a full unsigned int. Adjust size-related commentary accordingly. (cherry picked from commit cd41085a37b8288dbdfe0f81027ce04b978578f1)
[Bug rtl-optimization/108508] [12 Regression] ICE in insert_def_after, at rtl-ssa/accesses.cc:622 since r12-4759-g95bb87b2458bfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:44ca5bc6800987e56db3e5537079b10ad5faac88 commit r12-9379-g44ca5bc6800987e56db3e5537079b10ad5faac88 Author: Richard Sandiford Date: Mon Apr 3 09:57:06 2023 +0100 rtl-ssa: Fix splitting of clobber groups [PR108508] Since rtl-ssa isn't a real/native SSA representation, it has to honour the constraints of the underlying rtl representation. Part of this involves maintaining an rpo list of definitions for each rtl register, backed by a splay tree where necessary for quick lookup/insertion. However, clobbers of a register don't act as barriers to other clobbers of a register. E.g. it's possible to move one flag-clobbering instruction across an arbitrary number of other flag-clobbering instructions. In order to allow passes to do that without quadratic complexity, the splay tree groups all consecutive clobbers into groups, with only the group being entered into the splay tree. These groups in turn have an internal splay tree of clobbers where necessary. This means that, if we insert a new definition and use into the middle of a sea of clobbers, we need to split the clobber group into two groups. This was quite a difficult condition to trigger during development, and the PR shows that the code to handle it had (at least) two bugs. First, the process involves searching the clobber tree for the split point. This search can give either the previous clobber (which will belong to the first of the split groups) or the next clobber (which will belong to the second of the split groups). The code for the former case handled the split correctly but the code for the latter case didn't. Second, I'd forgotten to add the second clobber group to the main splay tree. :-( gcc/ PR rtl-optimization/108508 * rtl-ssa/accesses.cc (function_info::split_clobber_group): When the splay tree search gives the first clobber in the second group, make sure that the root of the first clobber group is updated correctly. Enter the new clobber group into the definition splay tree. gcc/testsuite/ PR rtl-optimization/108508 * gcc.target/aarch64/pr108508.c: New test. (cherry picked from commit f4e1b46618ef3bd7933992ab79f663ab9112bb80)
[Bug target/108603] [12 Regression] ICE in output_operand_lossage with SVE and ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:caecd24e230c4727c88ad117bab0342f378e81f7 commit r12-9380-gcaecd24e230c4727c88ad117bab0342f378e81f7 Author: Richard Sandiford Date: Mon Apr 3 09:57:07 2023 +0100 Avoid creating (const (reg ...)) [PR108603] convert_memory_address_addr_space_1 has two modes: one in which it tries to create a self-contained RTL expression (which might fail) and one in which it can emit new instructions where necessary. When handling a CONST, the function recurses into the CONST's operand and then constifies the result. But that's only valid if the result is still a self-contained expression. If new instructions have been emitted, the expression will refer to the (non-constant) results of those instructions. In the PR, this caused us to emit a nonsensical (const (reg ...)) REG_EQUAL note. gcc/ PR tree-optimization/108603 * explow.cc (convert_memory_address_addr_space_1): Only wrap the result of a recursive call in a CONST if no instructions were emitted. gcc/testsuite/ PR tree-optimization/108603 * gcc.target/aarch64/sve/pr108603.c: New test. (cherry picked from commit b09dc74801cf4e19bdf5fcd18a5cd53fc9e9ca9a)
[Bug tree-optimization/108430] [12 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:33a69d0b0b772610463d1d586f3f0c9820fc969e
commit r12-9378-g33a69d0b0b772610463d1d586f3f0c9820fc969e
Author: Richard Sandiford
Date: Mon Apr 3 09:57:06 2023 +0100
vect: Fix voluntarily-masked negative conditionals [PR108430]
vectorizable_condition checks whether a COND_EXPR condition is used
elsewhere with a loop mask. If so, it applies the loop mask to the
COND_EXPR too, to reduce the number of live masks and to increase the
chance of combining the AND with the comparison.
There is also code to do this for inverted conditions. E.g. if
we have a < b ? c : d and something else is conditional on !(a < b)
(such as a load in d), we use !(a < b) ? d : c and apply the loop
mask to !(a < b).
This inversion relied on the function's bitop1/bitop2 mechanism.
However, that mechanism is skipped if the condition is split out of
the COND_EXPR as a separate statement. This meant that we could end
up using the inverse of the intended condition.
There is a separate way of negating the condition when a mask
is being applied (which is also used for EXTRACT_LAST reductions).
This patch uses that instead.
As well as the testcase, this fixes aarch64/sve/vcond_{4,17}_run.c.
gcc/
PR tree-optimization/108430
* tree-vect-stmts.cc (vectorizable_condition): Fix handling
of inverted condition.
gcc/testsuite/
PR tree-optimization/108430
* gcc.target/aarch64/sve/pr108430.c: New test.
(cherry picked from commit 2a8ce4b52f5892a10a02b94d7be689e59a444ff6)
[Bug tree-optimization/108608] [12 Regression] AArch64 vectorizer ICE in vect_transform_reduction and __builtin_fmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:65216cd44b8c89640ad987b6227ea1d748456a41 commit r12-9381-g65216cd44b8c89640ad987b6227ea1d748456a41 Author: Richard Sandiford Date: Mon Apr 3 09:57:07 2023 +0100 vect: Fix single def-use cycle for ifn reductions [PR108608] The patch that added support for fmin/fmax reductions didn't handle single def-use cycles. In some ways, this seems like going out of our way to make things slower, but that's a discussion for another day. gcc/ PR tree-optimization/108608 * tree-vect-loop.cc (vect_transform_reduction): Handle single def-use cycles that involve function calls rather than tree codes. gcc/testsuite/ PR tree-optimization/108608 * gcc.dg/vect/pr108608.c: New test. * gcc.target/aarch64/sve/pr108608-1.c: Likewise. (cherry picked from commit 2bb444787ed17a9e786f544cdf51ee2ac6779ab2)
[Bug target/96373] SVE miscompilation on vectorized division loop, leading to FP exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373 --- Comment #19 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e11513c7688f583d1f4d0961d79d8aa775add03d commit r12-9384-ge11513c7688f583d1f4d0961d79d8aa775add03d Author: Richard Sandiford Date: Mon Apr 3 09:57:09 2023 +0100 vect: Make partial trapping ops use predication [PR96373] PR96373 points out that a predicated SVE loop currently converts trapping unconditional ops into unpredicated vector ops. Doing the operation on inactive lanes can then raise an exception. As discussed in the PR trail, we aren't 100% consistent about whether we preserve traps or not. But the direction of travel is clearly to improve that rather than live with it. This patch tries to do that for the SVE case. Doing this regresses gcc.target/aarch64/sve/fabd_1.c. I've added -fno-trapping-math for now and filed PR108571 to track it. A similar problem applies to fsubr_1.c. I think this is likely to regress Power 10, since conditional operations are only available for masked loops. I think we'll need to add -fno-trapping-math to any affected testcases, but I don't have a Power 10 system to test on. gcc/ PR tree-optimization/96373 PR tree-optimization/108979 * tree-vect-stmts.cc (vectorizable_operation): Predicate trapping operations on the loop mask. Reject partial vectors if this isn't possible. Don't mask operations on invariants. gcc/testsuite/ PR tree-optimization/96373 PR tree-optimization/108571 PR tree-optimization/108979 * gcc.target/aarch64/sve/fabd_1.c: Add -fno-trapping-math. * gcc.target/aarch64/sve/fsubr_1.c: Likewise. * gcc.target/aarch64/sve/fmul_1.c: Expect predicate ops. * gcc.target/aarch64/sve/fp_arith_1.c: Likewise. * gfortran.dg/vect/pr108979.f90: New test.
[Bug rtl-optimization/108681] [12 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 --- Comment #15 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:61bdd3c38039e1e309d5cf78c16c4052f6e09bea commit r12-9382-g61bdd3c38039e1e309d5cf78c16c4052f6e09bea Author: Richard Sandiford Date: Mon Apr 3 09:57:08 2023 +0100 lra: Replace subregs in bare uses & clobbers [PR108681] In this PR we had a write to one vector of a 4-vector tuple. The vector had mode V1DI, and the target doesn't provide V1DI moves, so this was converted into: (clobber (subreg:V1DI (reg/v:V4x1DI 92 [ b ]) 24)) followed by a DImode move. (The clobber isn't really necessary or helpful for a single word, but would be for wider moves.) The subreg in the clobber survived until after RA: (clobber (subreg:V1DI (reg/v:V4x1DI 34 v2 [orig:92 b ] [92]) 24)) IMO this isn't well-formed. If a subreg of a hard register simplifies to a hard register, it should be replaced by the hard register. If the subreg doesn't simplify, then target-independent code can't be sure which parts of the register are affected and which aren't. A clobber of such a subreg isn't useful and (again IMO) should just be removed. Conversely, a use of such a subreg is effectively a use of the whole inner register. LRA has code to simplify subregs of hard registers, but it didn't handle bare uses and clobbers. The patch extends it to do that. One question was whether the final_p argument to alter_subregs should be true or false. True is IMO dangerous, since it forces replacements that might not be valid from a dataflow perspective, and uses and clobbers only exist for dataflow. As said above, I think the correct way of handling a failed simplification would be to delete clobbers and replace uses of subregs with uses of the inner register. But I didn't want to write untested code to do that. In the PR, the clobber caused an infinite loop in DCE, because of a disagreement about what effect the clobber had. But for the reasons above, I think that was GIGO rather than a bug in DF or DCE. gcc/ PR rtl-optimization/108681 * lra-spills.cc (lra_final_code_change): Extend subreg replacement code to handle bare uses and clobbers. gcc/testsuite/ PR rtl-optimization/108681 * gcc.target/aarch64/pr108681.c: New test. (cherry picked from commit 3cac06d84f334705ed0bce12fbc3a4cec4a8fd3b)
[Bug tree-optimization/108979] [13 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e11513c7688f583d1f4d0961d79d8aa775add03d commit r12-9384-ge11513c7688f583d1f4d0961d79d8aa775add03d Author: Richard Sandiford Date: Mon Apr 3 09:57:09 2023 +0100 vect: Make partial trapping ops use predication [PR96373] PR96373 points out that a predicated SVE loop currently converts trapping unconditional ops into unpredicated vector ops. Doing the operation on inactive lanes can then raise an exception. As discussed in the PR trail, we aren't 100% consistent about whether we preserve traps or not. But the direction of travel is clearly to improve that rather than live with it. This patch tries to do that for the SVE case. Doing this regresses gcc.target/aarch64/sve/fabd_1.c. I've added -fno-trapping-math for now and filed PR108571 to track it. A similar problem applies to fsubr_1.c. I think this is likely to regress Power 10, since conditional operations are only available for masked loops. I think we'll need to add -fno-trapping-math to any affected testcases, but I don't have a Power 10 system to test on. gcc/ PR tree-optimization/96373 PR tree-optimization/108979 * tree-vect-stmts.cc (vectorizable_operation): Predicate trapping operations on the loop mask. Reject partial vectors if this isn't possible. Don't mask operations on invariants. gcc/testsuite/ PR tree-optimization/96373 PR tree-optimization/108571 PR tree-optimization/108979 * gcc.target/aarch64/sve/fabd_1.c: Add -fno-trapping-math. * gcc.target/aarch64/sve/fsubr_1.c: Likewise. * gcc.target/aarch64/sve/fmul_1.c: Expect predicate ops. * gcc.target/aarch64/sve/fp_arith_1.c: Likewise. * gfortran.dg/vect/pr108979.f90: New test.
[Bug target/109072] [12 Regression] SLP costs for vec duplicate too high since g:4963079769c99c4073adfd799885410ad484cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #11 from CVS Commits ---
The releases/gcc-12 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:eff10fe7384d1504f2c92db1fd44c663f737f57d
commit r12-9383-geff10fe7384d1504f2c92db1fd44c663f737f57d
Author: Richard Sandiford
Date: Mon Apr 3 09:57:08 2023 +0100
aarch64: Restore vectorisation of vld1 inputs [PR109072]
Before GCC 12, we would vectorize:
int32_t arr[] = { x, x, x, x };
at -O3. Vectorizing the store on its own is often a loss, particularly
for integers, so g:4963079769c99c4073adfd799885410ad484cbbe suppressed it.
This was necessary to fix regressions from enabling vectorisation at -O2,
However, the vectorisation is important if the code subsequently loads
from the array using vld1:
return vld1q_s32 (arr);
This approach of initialising an array and loading from it is the
recommend endian-agnostic way of constructing an ACLE vector.
As discussed in the PR notes, the general fix would be to fold the
store and load-back to a constructor (preferably before vectorisation).
But that's clearly not stage 4 material.
This patch instead delays folding vld1 until after inlining and
records which decls a vld1 loads from. It then treats vector
stores to those decls as free, on the optimistic assumption that
they will be removed later. The patch also brute-forces
vectorization of plain constructor+store sequences, since some
of the CPU costs make that (dubiously) expensive even when the
store is discounted.
Delaying folding showed that we were failing to update the vops.
The patch fixes that too.
Thanks to Tamar for discussion & help with testing.
gcc/
PR target/109072
* config/aarch64/aarch64-protos.h (aarch64_vector_load_decl):
Declare.
* config/aarch64/aarch64.h (machine_function::vector_load_decls):
New
variable.
* config/aarch64/aarch64-builtins.cc
(aarch64_record_vector_load_arg):
New function.
(aarch64_general_gimple_fold_builtin): Delay folding of vld1 until
after inlining. Record which decls are loaded from. Fix handling
of vops for loads and stores.
* config/aarch64/aarch64.cc (aarch64_vector_load_decl): New
function.
(aarch64_accesses_vector_load_decl_p): Likewise.
(aarch64_vector_costs::m_stores_to_vector_load_decl): New member
variable.
(aarch64_vector_costs::add_stmt_cost): If the function has a vld1
that loads from a decl, treat vector stores to those decls as
zero cost.
(aarch64_vector_costs::finish_cost): ...and in that case,
if the vector code does nothing more than a store, give the
prologue a zero cost as well.
gcc/testsuite/
PR target/109072
* gcc.target/aarch64/pr109072_1.c: New test.
* gcc.target/aarch64/pr109072_2.c: Likewise.
(cherry picked from commit fcb411564a655a01f759eea3bb16bfd1bc879bfd)
[Bug tree-optimization/108571] Fix for PR96373 regresses fabd_1.c with -ftrapping-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108571 --- Comment #2 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e11513c7688f583d1f4d0961d79d8aa775add03d commit r12-9384-ge11513c7688f583d1f4d0961d79d8aa775add03d Author: Richard Sandiford Date: Mon Apr 3 09:57:09 2023 +0100 vect: Make partial trapping ops use predication [PR96373] PR96373 points out that a predicated SVE loop currently converts trapping unconditional ops into unpredicated vector ops. Doing the operation on inactive lanes can then raise an exception. As discussed in the PR trail, we aren't 100% consistent about whether we preserve traps or not. But the direction of travel is clearly to improve that rather than live with it. This patch tries to do that for the SVE case. Doing this regresses gcc.target/aarch64/sve/fabd_1.c. I've added -fno-trapping-math for now and filed PR108571 to track it. A similar problem applies to fsubr_1.c. I think this is likely to regress Power 10, since conditional operations are only available for masked loops. I think we'll need to add -fno-trapping-math to any affected testcases, but I don't have a Power 10 system to test on. gcc/ PR tree-optimization/96373 PR tree-optimization/108979 * tree-vect-stmts.cc (vectorizable_operation): Predicate trapping operations on the loop mask. Reject partial vectors if this isn't possible. Don't mask operations on invariants. gcc/testsuite/ PR tree-optimization/96373 PR tree-optimization/108571 PR tree-optimization/108979 * gcc.target/aarch64/sve/fabd_1.c: Add -fno-trapping-math. * gcc.target/aarch64/sve/fsubr_1.c: Likewise. * gcc.target/aarch64/sve/fmul_1.c: Expect predicate ops. * gcc.target/aarch64/sve/fp_arith_1.c: Likewise. * gfortran.dg/vect/pr108979.f90: New test.
[Bug tree-optimization/108430] [12 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug rtl-optimization/108508] [11 Backport] ICE in insert_def_after, at rtl-ssa/accesses.cc:622 since r12-4759-g95bb87b2458bfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[12 Regression] ICE in |[11 Backport] ICE in |insert_def_after, at|insert_def_after, at |rtl-ssa/accesses.cc:622 |rtl-ssa/accesses.cc:622 |since |since |r12-4759-g95bb87b2458bfa|r12-4759-g95bb87b2458bfa --- Comment #6 from rsandifo at gcc dot gnu.org --- I'm intending to backport the rtl-ssa part to GCC 11 too.
[Bug target/108603] [12 Regression] ICE in output_operand_lossage with SVE and ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816 Martin Liška changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||patch --- Comment #11 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615049.html
[Bug tree-optimization/108608] [12 Regression] AArch64 vectorizer ICE in vect_transform_reduction and __builtin_fmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from rsandifo at gcc dot gnu.org --- FIxed.
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/103429] Optimization of Auto-generated condition chain is not giving good lookup tables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103429 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 Martin Liška changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/109072] [12 Regression] SLP costs for vec duplicate too high since g:4963079769c99c4073adfd799885410ad484cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/101301] Improving sparse switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug rtl-optimization/108681] [12 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from rsandifo at gcc dot gnu.org --- Fixed for GCC 12 too.
[Bug modula2/109388] clang warnings related to Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109388 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-04-03 --- Comment #1 from Gaius Mulley --- Indeed thanks for reporting this - will fix.
[Bug libstdc++/109383] [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-04-03 --- Comment #1 from Jonathan Wakely --- I guess we've all just implemented exactly what the standard says, without thinking about optimizing it. It's a good idea though, thanks!
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386
--- Comment #2 from Jakub Jelinek ---
The swapping isn't really needed, the testcase can be simplified to:
static inline float
foo (float x, float y)
{
float u = __builtin_fabsf (x);
float v = __builtin_fabsf (y);
if (!(u >= v))
{
if (__builtin_isinf (v)) return v;
if (__builtin_isinf (u)) return u;
}
return 42.0f;
}
int
main ()
{
if (!__builtin_isinf (foo (__builtin_inff (), __builtin_nanf (""
__builtin_abort ();
}
[Bug libstdc++/109383] [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/typeindex
+++ b/libstdc++-v3/include/std/typeindex
@@ -87,13 +87,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
strong_ordering
operator<=>(const type_index& __rhs) const noexcept
{
+#if __GXX_TYPEINFO_EQUALITY_INLINE
+# if __GXX_MERGED_TYPEINFO_NAMES
+ return _M_target->name() <=> __rhs._M_target->name();
+# else
+ return __builtin_strcmp(_M_target->name(), __rhs._M_target->name()) <=>
0;
+# endif
+#else // __GXX_TYPEINFO_EQUALITY_INLINE
if (*_M_target == *__rhs._M_target)
return strong_ordering::equal;
if (_M_target->before(*__rhs._M_target))
return strong_ordering::less;
return strong_ordering::greater;
+#endif // __GXX_TYPEINFO_EQUALITY_INLINE
}
-#endif
+#endif // __cpp_lib_three_way_comparison
size_t
hash_code() const noexcept
[Bug libstdc++/109383] [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383 --- Comment #3 from Jonathan Wakely --- For !__GXX_TYPEINFO_EQUALITY_INLINE we need to export a new symbol from the library, so the patch above doesn't optimize that case.
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-03
[Bug target/109380] inline member function symbol not exported with explicit template instantiation declaration on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #4 from LIU Hao --- Looks like GCC doesn't generate `-export:` after `.section .drectve`. The functions are generated in `.linkonce` sections correctly; they are just not exported.
[Bug c++/109389] New: g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389
Bug ID: 109389
Summary: g++ file.cpp -lgmp (option only works after filename)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frechbengel at gmx dot de
Target Milestone: ---
Hello,
1. »g++ --version« outputs:
g++ (Debian 10.2.1-6) 10.2.1 20210110
2. »g++ --help« says:
Usage: g++ [options] file...
3. But if I try to compile:
#include
int main(){
mpz_t n;
mpz_init(n);
mpz_clear(n);
return 0;}
4. with »g++ -lgmp file.cpp« the error is:
/usr/bin/ld: /tmp/cc8lgHAc.o: in function `main':
guard_driver.cpp:(.text+0x10): undefined reference to `__gmpz_init'
/usr/bin/ld: guard_driver.cpp:(.text+0x21): undefined reference to
`__gmpz_set_ui'
/usr/bin/ld: guard_driver.cpp:(.text+0x34): undefined reference to
`operator<<(std::ostream&, __mpz_struct const*)'
/usr/bin/ld: guard_driver.cpp:(.text+0x55): undefined reference to
`__gmpz_clear'
collect2: error: ld returned 1 exit status
5. There is no error if I compile with:
»g++ file.cpp -lgmp«
6. As the --help says the options should be given BEFORE the filename it is a
feature if it works with options given after the filename, too. But I is
propably a bug that compilation only works with the option given after the
filename.
Regards and thank you for you valuable work
Bernd
[Bug c++/109390] New: Does not reject specialized non-type argument of dependent type in class template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109390
Bug ID: 109390
Summary: Does not reject specialized non-type argument of
dependent type in class template partial
specialization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
As seen with e.g. gcc-c++-12.2.1-4.fc37.x86_64, it does not reject
> $ cat test.cc
> template struct S {};
> template struct S {};
> $ g++ -fsyntax-only test.cc
even though I think it should per (e.g. C++20) [temp.class.spec]/9.1 "The type
of a template parameter corresponding to a specialized non-type argument shall
not be dependent on a parameter of the specialization."
(I'm not sure whether or not this should be considered a duplicate of bug
102158 "[C++20] Specialized non-type template argument violates
[temp.spec.partial#general-9] but accepted by GCC".)
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #3 from Jakub Jelinek --- Created attachment 54803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54803&action=edit gcc13-pr109386.patch Untested fix. When LT/LE/GT/GE have lhs [0, 0] or UNLT/UNLE/UNGT/UNGE have lhs [1, 1], we don't know anything (VARYING) about one operand if the other operand may be a NAN, not just is known to be a NAN, because if it happens to be NAN at runtime, the comparison is false (resp. true) regardless of the finite/infinite comparison results.
[Bug analyzer/107733] -Wanalyzer-null-dereference false positive with wrong path note "(3) 'e' is NULL" and inconsistent behaviors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107733 --- Comment #4 from Geoffrey --- (In reply to David Malcolm from comment #2) > ...and also, as you note: > * deleting the unrelated code ` int *d = 0;` should not affect the result > (but does) > > > > the path note `(3) 'e' is NULL` is wrong, this may suggest some problems. > > Note (3) seems correct to me; (1) says "following 'true' branch (when 'e' is > NULL)..." so we're on the "e is NULL" branch. Hi. David. Could you spare some time to explain this phenomenon to me ?
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Firstly, this is a proeprty of your linker, which is not part of GCC. GCC just passes the arguments to the linker in the order you give them. Secondly, this is not a bug, it's the expected behaviour for the linker. https://c-faq.com/lib/libsearch.html
[Bug rtl-optimization/109391] New: Inefficient codegen on AArch64 when structure types are returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391
Bug ID: 109391
Summary: Inefficient codegen on AArch64 when structure types
are returned
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
This example https://godbolt.org/z/Pe3f3ozGf
---
#include
int16x8x3_t bsl(const uint16x8x3_t *check, const int16x8x3_t *in1,
const int16x8x3_t *in2) {
int16x8x3_t out;
for (uint32_t j = 0; j < 3; j++) {
out.val[j] = vbslq_s16(check->val[j], in1->val[j], in2->val[j]);
}
return out;
}
---
Generates:
bsl:
ldp q6, q16, [x1]
ldp q0, q4, [x2]
ldp q5, q7, [x0]
bsl v5.16b, v6.16b, v0.16b
ldr q0, [x2, 32]
bsl v7.16b, v16.16b, v4.16b
ldr q6, [x1, 32]
mov v1.16b, v5.16b
ldr q5, [x0, 32]
bsl v5.16b, v6.16b, v0.16b
mov v0.16b, v1.16b
mov v1.16b, v7.16b
mov v2.16b, v5.16b
ret
with 3 superfluous moves. It looks like reload is having trouble dealing
with the new compound types as return arguments.
So in RTL We have:
(insn 17 20 22 2 (set (subreg:V8HI (reg/v:V3x8HI 105 [ out ]) 16)
(xor:V8HI (and:V8HI (xor:V8HI (reg:V8HI 115 [ in2_11(D)->val[1] ])
(reg:V8HI 114 [ in1_10(D)->val[1] ]))
(reg:V8HI 113 [ check_9(D)->val[1] ]))
(reg:V8HI 115 [ in2_11(D)->val[1] ]))) "/app/example.c":7:16
discrim 1 2558 {aarch64_simd_bslv8hi_internal}
(expr_list:REG_DEAD (reg:V8HI 115 [ in2_11(D)->val[1] ])
(expr_list:REG_DEAD (reg:V8HI 114 [ in1_10(D)->val[1] ])
(expr_list:REG_DEAD (reg:V8HI 113 [ check_9(D)->val[1] ])
(nil)
(insn 22 17 29 2 (set (subreg:V8HI (reg/v:V3x8HI 105 [ out ]) 32)
(xor:V8HI (and:V8HI (xor:V8HI (reg:V8HI 118 [ in2_11(D)->val[2] ])
(reg:V8HI 117 [ in1_10(D)->val[2] ]))
(reg:V8HI 116 [ check_9(D)->val[2] ]))
(reg:V8HI 118 [ in2_11(D)->val[2] ]))) "/app/example.c":7:16
discrim 1 2558 {aarch64_simd_bslv8hi_internal}
(expr_list:REG_DEAD (reg:V8HI 118 [ in2_11(D)->val[2] ])
(expr_list:REG_DEAD (reg:V8HI 117 [ in1_10(D)->val[2] ])
(expr_list:REG_DEAD (reg:V8HI 116 [ check_9(D)->val[2] ])
(nil)
(insn 29 22 30 2 (set (reg/i:V3x8HI 32 v0)
(reg/v:V3x8HI 105 [ out ])) "/app/example.c":10:1 3964
{*aarch64_movv3x8hi}
(expr_list:REG_DEAD (reg/v:V3x8HI 105 [ out ])
(nil)))
(insn 30 29 37 2 (use (reg/i:V3x8HI 32 v0)) "/app/example.c":10:1 -1
(nil))
Reload then decides to insert a bunch of reloads:
Choosing alt 0 in insn 17: (0) =w (1) 0 (2) w (3) w
{aarch64_simd_bslv8hi_internal}
Creating newreg=126 from oldreg=113, assigning class FP_REGS to r126
17: r126:V8HI=r115:V8HI^r114:V8HI&r126:V8HI^r115:V8HI
REG_DEAD r115:V8HI
REG_DEAD r114:V8HI
REG_DEAD r113:V8HI
Inserting insn reload before:
43: r126:V8HI=r113:V8HI
Inserting insn reload after:
44: r105:V3x8HI#16=r126:V8HI
which introduces these moves. The problem existed with the previous structure
types as well (OImode etc) so it's not new but costs us lots of perf.
I don't think I can fix this with the same pass as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106 can I? It looks like in
this case the RTL looks fine.
[Bug analyzer/108428] -Wanalyzer-null-dereference false negative with *f = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108428 --- Comment #2 from Geoffrey --- Hi, David! Could you spare a little time to explain this case for me? Please ^v^
[Bug analyzer/109190] GCC Static Analyzer cannot handle the initialization of an array with a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109190 --- Comment #1 from Geoffrey --- Hi, David! Could you spare a little time to explain this case to me? Thanks a lt!
[Bug tree-optimization/108888] [13 Regression] error: definition in block 26 follows the use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #6 from avieira at gcc dot gnu.org --- After this patch Andrew Stubbs patch (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3da77f217c8b2089ecba3eb201e727c3fcdcd19d) to use in-branch simd-clones for cases like in gcc/testsuite/gcc.dg/vect/vect-simd-clone-16.c no longer work. I believe this is because this patch changes the 'if (gimple_call ..)' into a else 'if (...is_gimple_call (stmt))' which doesn't work because stmt will be 0 (it's a dyn_cast of gassign). I'm testing a patch locally to fix this.
[Bug target/109384] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jiawei at iscas dot ac.cn, ||kito at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The formatting of the r13-6930-gb2f327b9be81326c9e59 patch is also incorrect (missing spaces before (, wrong indentation. The wording should probably use floating-point extensions because that is how the RISCV extensions are called. The point of the warning is make sure float which is typically a keyword is quoted, e.g. % .
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 Jakub Jelinek changed: What|Removed |Added Summary|unquoted keyword 'float' in |[13 Regression] unquoted |format |keyword 'float' in format |[-Werror=format-diag] |[-Werror=format-diag] Target Milestone|--- |13.0
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 --- Comment #2 from Jakub Jelinek --- And something is conflict with something_else is incorrect grammar, so %<-march=%s%>: z*inx conflicts with floating-point extensions ?
[Bug c++/109319] [12 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319 Jakub Jelinek changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |build_min_non_dep_op_overlo |build_min_non_dep_op_overlo |ad, at cp/tree.cc:3793 |ad, at cp/tree.cc:3793 |since r12-5510 |since r12-5510 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 --- Comment #8 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug c++/109381] [10/11/12/13 Regression] Ambiguous member lookup with this-> accepted when it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109381 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||ppalka at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=15272 --- Comment #2 from Patrick Palka --- (In reply to Andrew Pinski from comment #1) > Confirmed. most likely caused by the way which got it right without this-> Yep, started with r8-5270-g2b031ef48e365e.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #2 from Bernd --- @ Jonathan Wakely Thank you for correcting me and setting the issue solved. Sorry for the wrong report. For a long time g++ accepted the -lgmp before the filename, clang++ still does. That's why I thought that this must a bug.
[Bug analyzer/109190] GCC Static Analyzer cannot handle the initialization of an array with a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109190 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- With -O0 GCC does not attempt to analyze any loops. I doubt if "-O0 -fanalyzer" really makes sense. Maybe we should just emit a warning when -fanalyzer is used with -O0.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- It accepts it, but it does something different from when it is after the objects.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #4 from Jonathan Wakely --- Clang is not a linker either. Both Clang and GCC just pass the options to the linker. Any difference in behaviour is a difference in the linker, not a difference between Clang and GCC.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #5 from Andrew Pinski --- Note for shared libraries it might the case the gcc you using defaults to passing --as-needed to the linker and the clang driver does not.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #6 from Andrew Pinski --- Note Debian (and Ubuntu) has a patch to their GCC which does cause the default arguments to ld to include --as-needed . That is why you are seeing a difference between gcc and clang. Note if you build GCC from source, you would not have seen a difference here. Also note this is not a bug in GCC nor in debian's gcc; just you misunderstanding the how linking works too.
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Martin Jambor --- Fixed.
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:da3fd01757297c1d20cf3dcd76046488da737569 commit r13-6986-gda3fd01757297c1d20cf3dcd76046488da737569 Author: Martin Jambor Date: Mon Apr 3 15:53:36 2023 +0200 ipa: Avoid constructing aggregate jump functions with huge offsets (PR 109303) We are in the process of changing data structures holding information about constants passed by reference and in aggregates to use unsigned int offsets rather than HOST_WIDE_INT (which was selected simply because that is what fell out of get_ref_base_and_extent at that time) in order to conserve memory, especially at WPA time. PR 109303 testcase discovers that we do not properly check that we only create jump functions with offsets (plus sizes) that fit into the smaller type. This patch adds the necessary check. gcc/ChangeLog: 2023-03-30 Martin Jambor PR ipa/109303 * ipa-prop.cc (determine_known_aggregate_parts): Check that the offset + size will be representable in unsigned int. gcc/testsuite/ChangeLog: 2023-03-30 Jakub Jelinek Martin Jambor PR ipa/109303 * gcc.dg/pr109303.c: New test.
[Bug modula2/109388] clang warnings related to Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109388 --- Comment #2 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:9a75f0a02e5006e081b335acd36300a85bef8eb8 commit r13-6987-g9a75f0a02e5006e081b335acd36300a85bef8eb8 Author: Gaius Mulley Date: Mon Apr 3 15:04:06 2023 +0100 PR modula2/109388 clang warnings related to Modula-2 This patch removes an unused parameter 'module' from DoVariableDeclaration in M2GCCDeclare.mod. It also removes unused procedures from PHBuild.bnf. gcc/m2/ChangeLog: PR modula2/109388 * gm2-compiler/M2GCCDeclare.mod (DoVariableDeclaration): Remove second parameter module. Adjust all callers to remove the second parameter. * gm2-compiler/PHBuild.bnf (CheckAndInsert): Remove. (InStopSet): Remove. (PeepToken): Remove. (PushQualident): Remove. (SimpleDes): Remove. (ActualParameters): Remove. Signed-off-by: Gaius Mulley
[Bug modula2/109388] clang warnings related to Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109388 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Gaius Mulley --- Closing as the patch has been applied - thanks for reporting the bug.
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Jason, any thoughts on why we for build_type_attribute_qual_variant call build_distinct_type_copy rather than build_variant_type_copy, which is e.g. what all spots in c-family/c-attribs.cc that need a separate type use? Or could we use build_variant_type_copy say for a subset of types (perhaps integral/pointer/reference/vector/complex types or something similar) and use distinct copies of the rest (function/method types, aggregates)?
[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Martin, any progress on this? Feels like PRs we've discussed in the past (and some of them have been fixed), where IPA passes assume something isn't really needed to be computed because all its uses will be dead, but doesn't actually DCE them and because DCE is disabled, it is still needed?
[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 --- Comment #8 from Jakub Jelinek --- E.g. PR93385.
[Bug analyzer/109361] RFE: SARIF output could contain timing/profile information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361 --- Comment #3 from David Malcolm --- Created attachment 54804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54804&action=edit v1 of patch for this This patch works, but it also enables the output on stderr, and I see significant differences in output with this. Hence I'm working on a v2 patch that adds a separate command-line option for enabling this.
[Bug fortran/104272] finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Last reconfirmed||2023-04-03 Ever confirmed|0 |1 --- Comment #2 from Paul Thomas --- Hi Kai, Thanks for the report. nagfor agrees that the finalization shouldn't occur. From the work that I did on finalization, nagfor was the most compliant of all the compilers that I have access to. I am currently working on ASSOCIATE bugs but will come back to tidy up some of the finalization nits in a few weeks time. Confirming and taking the bug. Cheers Paul
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 --- Comment #3 from Damian --- Hello Jakub, withe the change "%<-march=%s%>: z*inx conflicts with floating-point extensions ?" the build works again Best regards Damian
[Bug fortran/104272] finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272
--- Comment #3 from Paul Thomas ---
Following the allocation itself, we get:
solver._data.dim[0].lbound = 1;
solver._data.dim[0].ubound = 2;
solver._data.dim[0].stride = 1;
solver._data.offset = -1;
solver._data.span = 64;
{
integer(kind=8) D.4532;
integer(kind=8) D.4533;
integer(kind=8) D.4534;
struct solver_sparse_gpu_t * D.4535;
D.4532 = solver._data.offset;
D.4533 = solver._data.dim[0].lbound;
D.4534 = solver._data.dim[0].ubound;
D.4535 = &source.16;
{
integer(kind=8) S.20;
S.20 = D.4533;
while (1)
{
if (S.20 > D.4534) goto L.28;
{
struct __vtype_solver_m_Solver_base_t * {ref-all} D.4537;
solver._vptr = (struct __vtype_solver_m_Solver_base_t *
{ref-all}) &__vtab_solver_m_Solver_sparse_gpu_t;
D.4537 = solver._vptr;
solver._vptr->_copy (D.4535, (struct solver_base_t *)
solver._data.data + (sizetype) ((S.20 + D.4532) * solver._vptr->_size));
}
S.20 = S.20 + 1;
}
L.28:;
}
}
desc.17.dtype = {.elem_len=64, .rank=0, .type=5};
desc.17.data = (void * restrict) &source.16.solver_gpu_t;
desc.17.span = (integer(kind=8)) desc.17.dtype.elem_len;
__final_solver_m_Solver_gpu_t (&desc.17, 64, 1);
if ((complex(kind=4)[0:] * restrict) source.16.solver_gpu_t.x.data !=
0B)
{
__builtin_free ((void *) source.16.solver_gpu_t.x.data);
(complex(kind=4)[0:] * restrict) source.16.solver_gpu_t.x.data =
0B;
}
So there it is, writ large at the end. For some reason, gfc_trans_allocate
applies a default initializer and the finalizes and nulls the component.
Paul
[Bug c/109392] New: [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392
Bug ID: 109392
Summary: [12/13 Regression] ICE in tree_vec_extract, at
tree-vect-generic.cc:177
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r12 before 20210502 :
$ cat z1.c
typedef short __attribute__ ((__vector_size__ (64))) V;
V v, w;
inline V foo (V a, V b);
V
foo (V a, V b)
{
vfork();
b &= v < b;
return (V){foo (b, w)[3], (V){}[3]};
}
$ gcc-13-20230402 -c z1.c
z1.c: In function 'foo':
z1.c:6:1: warning: AVX512F vector return without AVX512F enabled changes the
ABI [-Wpsabi]
6 | {
| ^
z1.c:7:3: warning: implicit declaration of function 'vfork'
[-Wimplicit-function-declaration]
7 | vfork();
| ^
z1.c:5:1: note: the ABI for passing parameters with 64-byte alignment has
changed in GCC 4.6
5 | foo (V a, V b)
| ^~~
during GIMPLE pass: veclower
z1.c:5:1: internal compiler error: in tree_vec_extract, at
tree-vect-generic.cc:177
0x111bdd6 tree_vec_extract(gimple_stmt_iterator*, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/tree-vect-generic.cc:177
0x111f8fb expand_vector_condition
../../gcc/tree-vect-generic.cc:1140
0x6cac8d expand_vector_comparison
../../gcc/tree-vect-generic.cc:453
0x11229c1 expand_vector_operation
../../gcc/tree-vect-generic.cc:1239
0x11229c1 expand_vector_operations_1
../../gcc/tree-vect-generic.cc:2357
0x11229c1 expand_vector_operations
../../gcc/tree-vect-generic.cc:2391
0x11229c1 execute
../../gcc/tree-vect-generic.cc:2445
[Bug tree-optimization/109393] New: Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
Bug ID: 109393
Summary: Very trivial address calculation does not fold
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: manolis.tsamis at vrull dot eu
Target Milestone: ---
The following function
int func(int *a, int j) {
int k = j - 1;
return a[j - 1] == a[k];
}
surprisingly does not fold to `return 1;` at -O2 or higher (with any GCC
version). It can also be seen here: https://godbolt.org/z/cqr43q7fq
There are a lot of variants for this behaviour but this is the most apparent.
As can be seen in the godbolt link, the issue seems to be a combination of:
1) The -1 in a[j - 1] is turned into GIMPLE equivalent with *((a + (ulong) j)
+ (ulong) -1) but a[k] is turned into *(a + (ulong) (j - 1)).
2) The -1 is never propagated outside of the (long unsigned int) casts even
if it's completely legal/possible.
I feel that I'm missing something here about pointer rules / historical context
of these choices and I would appreciate if someone more knowlegable could
explain this combination to me.
There are a lot of cases where this can lead to inefficient codegen but most
prominently this is the reason for a additional redundant load in a hot loop of
SPEC2017's nab in the function downheap_pairs and similar missed optimizations
in omnetpp's shiftup function.
Hence this issue can both cause very unexpected missed optimization (as in the
example) and also decreases the performance of important benchmarks.
Note: The testcase is not optimized even with -fno-wrapv or -fstrict-overflow,
but does optimize with -fwrapv which is the reverse of what I would expect
since -fno-wrapv should be more permissive?
[Bug tree-optimization/109393] Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393 --- Comment #1 from Andrew Pinski --- Note sometimes -fwrapv will optimize things because it can assume that overflow is defined as wrapping and this is one case that is true. Yes it sounds counter intuitive but it is true. Even re-association happens more with -fwrapv :).
[Bug tree-optimization/109392] [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |12.3
[Bug fortran/109394] New: list-directed read of character from complex number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109394 Bug ID: 109394 Summary: list-directed read of character from complex number Product: gcc Version: og11 (devel/omp/gcc-11) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: snavece at hotmail dot com Target Milestone: --- My question is how should a complex number be parsed when using a list-directed read to a string? Currently complex numbers are parsed to two tokens in gfortran. An alternative is to parse complex numbers to one token. See examples below. I recognize that it is a judgment call. I would argue the second technique makes the handling of complex numbers easier, although it may raise a number of unintended consequences that I have not considered. Using the following file, test.f: PROGRAM MAIN C IMPLICIT NONE C INTEGER, PARAMETER :: MXTOKS = 10 INTEGER IERR C CHARACTER * 20 TOKENS(MXTOKS) CHARACTER * 132 LINE C LINE = '''A B C'' "A B C" (1.0, 2.0) 1 2 3 1.0 2.0 3.0' print *, 'Line: /', TRIM(LINE), '/' READ (LINE, *, IOSTAT=IERR) TOKENS print *, TOKENS print *, 'Ierr:', IERR STOP END and the commands in a Cygwin mksh shell: $ gfortarn -o test.exe test.f $ ./test.exe The result is: Line: /'A B C' "A B C" (1.0, 2.0) 1 2 3 1.0 2.0 3.0/ A B C A B C (1.02.0) 1 2 3 1.0 2.0 3.0 Ierr: 0 An alternate parsing could be: 'A B C' "A B C" (1.0, 2.0) 1 2 3 1.0 2.0 3.0 Ierr: -1 The IERR = -1 indicating that end of line was encountered before reading 10 tokens. My environment is mksh in a Cygwin 64 delivery running on Windows 10 Version 12H2 (OS Build 19044.2728) $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/11/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.3.0/configure --srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.3.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --with-gcc-major-version-only --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.3.0 (GCC)
[Bug fortran/109394] list-directed read of character from complex number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109394 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Please see "13.10 List-directed formatting" in the Fortran standard. For the program you posted, a comma, blank, and semicolon are value separators. If you look at each token with do i = 1, mxtoks print *, trim(tokens(i)) end do you a b c a b c (1.0 2.0) 1 2 3 1.0 2.0 3.0 where the comma is the end of the character string "(1.0"
[Bug debug/78212] Fortran allocatable strings in derived type elements debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78212 John DelSignore changed: What|Removed |Added CC||jdelsignore at perforce dot com --- Comment #2 from John DelSignore --- A user recently reported that TotalView could not print the value of Fortran variable length character strings in user defined types. Here is the test program they submitted, which is similar to the one contained in this bug report: program test implicit none type my_type character(:), allocatable :: str end type my_type type (my_type) a character(:), allocatable :: t allocate (character(10):: t) t = 'abc' a%str = 'xyz' print *, 't="', t, '", a%str="', a%str, '"' end program test The DWARF for "t" is OK, but the DWARF for field "str" in "my_type" is not. The GNU Fortran (gfortran) compiler does not generate a DWARF string length attribute for the string type. Dumping the DWARF for gfortran 10.2.0, we see: <1><2e>: Abbrev Number: 2 (DW_TAG_structure_type) <2f> DW_AT_name: (indirect string, offset: 0x0): my_type <33> DW_AT_byte_size : 16 <34> DW_AT_decl_file : 1 <35> DW_AT_decl_line : 4 <36> DW_AT_sibling : <0x55> <2><3a>: Abbrev Number: 3 (DW_TAG_member) <3b> DW_AT_name: str <3f> DW_AT_decl_file : 1 <40> DW_AT_decl_line : 7 <41> DW_AT_decl_column : 37 <42> DW_AT_type: <0x57> <46> DW_AT_data_member_location: 0 <2><47>: Abbrev Number: 4 (DW_TAG_member) <48> DW_AT_name: (indirect string, offset: 0x188): _str_length <4c> DW_AT_decl_file : 1 <4d> DW_AT_decl_line : 4 <4e> DW_AT_decl_column : 12 <4f> DW_AT_type: <0x5d> <53> DW_AT_data_member_location: 8 <1><57>: Abbrev Number: 6 (DW_TAG_pointer_type) <58> DW_AT_byte_size : 8 <59> DW_AT_type: <0x55> <1><55>: Abbrev Number: 5 (DW_TAG_string_type) Member "str" is at offset 0 in the structure and has a type that references DIE <57>. DIE <57> is a pointer type, which isn't the correct way of handling Fortran, but TotalView is smart enough to automatically dereference pointer types in Fortran codes. The target of the pointer type is a reference to DIE <55>. DIE <55> is a string type, but it does not contain an attribute that provides the string length, which I think is a compiler bug. The compiler DOES generate the correct DWARF string type DIE for "t", which is: <2>: Abbrev Number: 12 (DW_TAG_variable) DW_AT_name: t DW_AT_decl_file : 1 DW_AT_decl_line : 10 DW_AT_decl_column : 32 DW_AT_type: <0x10e> <103> DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24) <1><10e>: Abbrev Number: 6 (DW_TAG_pointer_type) <10f> DW_AT_byte_size : 8 <110> DW_AT_type: <0x107> <1><107>: Abbrev Number: 14 (DW_TAG_string_type) <108> DW_AT_string_length: 5 byte block: 99 ee 0 0 0 (DW_OP_call4: <0xee>) <2>: Abbrev Number: 13 (DW_TAG_variable) DW_AT_name: .t DW_AT_type: <0x5d> DW_AT_artificial : 1 DW_AT_location: 2 byte block: 91 60 (DW_OP_fbreg: -32) Notice that the compiler generates a string type with a string length attribute, which is a reference to an artificial variable that holds the length of the string. I think that DWARF 5 can support this by generating an string length attribute that is an exprloc containing an operation that pushes the object address and adds the offset to the length field.
[Bug fortran/104349] ICE in (tree_to_uhwi) gfc_conv_array_initializer, at fortran/trans-array.cc:6337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104349
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-04-03
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
The following removal of two very old lines of code remove the ICE and
fix an accepts-invalid:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 7fb33f81788..4b5529d7136 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3504,8 +3509,8 @@ check_restricted (gfc_expr *e)
|| sym->attr.implied_index
|| sym->attr.flavor == FL_PARAMETER
|| is_parent_of_current_ns (sym->ns)
- || (sym->ns->proc_name != NULL
- && sym->ns->proc_name->attr.flavor == FL_MODULE)
+ // || (sym->ns->proc_name != NULL
+ //&& sym->ns->proc_name->attr.flavor == FL_MODULE)
|| (gfc_is_formal_arg () && (sym->ns == gfc_current_ns)))
{
t = true;
Before, we would have silently accepted
module m
character(n), parameter :: c= 'b' ! accepts invalid
end
This change needs adjustment of the diagnostics for testcase
gfortran.dg/der_charlen_1.f90
[Bug fortran/104349] ICE in (tree_to_uhwi) gfc_conv_array_initializer, at fortran/trans-array.cc:6337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104349 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-April/059140.html
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||anlauf at gcc dot gnu.org
Keywords||diagnostic
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Remove ice-on-invalid-code as I don't get an ICE.
>
> The following patch suppresses the error message with the temporary variable
> and removes duplicated code. Please commit.
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 46585879ddc..3462d43f346 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -9909,11 +9909,6 @@ resolve_select_rank (gfc_code *code, gfc_namespace
> *old_ns)
> || gfc_expr_attr (code->expr1).pointer))
> gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> "allocatable selector at %L", &c->where,
> &code->expr1->where);
> -
> - if (case_value == -1 && (gfc_expr_attr (code->expr1).allocatable
> -|| gfc_expr_attr (code->expr1).pointer))
> - gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> -"allocatable selector at %L", &c->where,
> &code->expr1->where);
> }
>
>/* Add EXEC_SELECT to switch on rank. */
This is a gem: not dead code, but un-dead code ... ;-)
> @@ -12948,7 +12943,9 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int
> mp_flag)
>
>if (allocatable)
> {
> - if (dimension && as->type != AS_ASSUMED_RANK)
> + if (dimension
> + && as->type != AS_ASSUMED_RANK
> + && !sym->attr.select_rank_temporary)
> {
> gfc_error ("Allocatable array %qs at %L must have a deferred "
>"shape or assumed rank", sym->name, &sym->declared_at);
I remember that spot of code as it was hit by one of Gerhard's testcases
with as == NULL ...
I'll have a look. The diagnostic indeed was bogus.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #5 from John David Anglin --- I'm not sure what is expected here: (gdb) r Starting program: /home/dave/gnu/gcc/objdir/gcc/testsuite/gnat/div_zero.exe warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Program received signal SIGFPE, Arithmetic exception. $$divoI () at ../../../gcc/libgcc/config/pa/milli64.S:448 448 addit,= 0,arg1,r0 /* trap if divisor == 0 */ (gdb) c Continuing. Breakpoint 1, __gnat_error_handler (sig=8, si=0xf8f02488, ucontext=0xf8f02508) at init.c:538 538 now, before we possibly trigger a recursive fault below. */ (gdb) p/x ((ucontext_t *) ucontext)->uc_mcontext.sc_iaoq[0] $2 = 0x1d1bf (gdb) bt #0 __gnat_error_handler (sig=8, si=0xf8f02488, ucontext=0xf8f02508) at init.c:538 #1 #2 $$divoI () at ../../../gcc/libgcc/config/pa/milli64.S:448 #3 0x0001a124 in div_zero () (gdb) frame 2 #2 $$divoI () at ../../../gcc/libgcc/config/pa/milli64.S:448 448 addit,= 0,arg1,r0 /* trap if divisor == 0 */ (gdb) disass $pc-16,$pc+16 Dump of assembler code from 0x1d1ac to 0x1d1cc: 0x0001d1ac <$$divoI+428>:bv,n r0(r31) 0x0001d1b0 <$$divoI+432>:nop 0x0001d1b4 <$$divoI+436>:blr,n r25,r0 0x0001d1b8 <$$divoI+440>:nop => 0x0001d1bc <$$divoI+444>:addi,tc,= 0,r25,r0 0x0001d1c0 <$$divoI+448>:nop 0x0001d1c4 <$$divoI+452>:bv r0(r31) 0x0001d1c8 <$$divoI+456>:copy r26,ret1 End of assembler dump. (gdb) frame 0 #0 __gnat_error_handler (sig=8, si=0xf8f02488, ucontext=0xf8f02508) at init.c:538 538 now, before we possibly trigger a recursive fault below. */ (gdb) ptype ((ucontext_t *) ucontext)->uc_mcontext.sc_iaoq[0] type = unsigned long As things stands, the pc (head iaoq value) points at the nop after the addi,tc,= which caused the trap. As far as I can tell, this test has always failed on both 32-bit linux and hpux.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #35 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #34)
> Created attachment 54787 [details]
> patch for C FE to add size expressions to VM types in structs
thanks a lot for the patch.
could you please provide a small testing case that works with this patch that I
can take a further look?
I tried very simple one, didn't compile:
struct P {
int k;
int x[.k];
};
void
foo (int n)
{
struct P p;
p.k = n;
return;
}
>
> It works with UBSan, but it isn't clear how this could pass the
> information to the object size pass. This also does not work for
> parameters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334
>From your change, I can see that you put the ".k" info to the index of the
array type for x[.k], so I guess that other passes can refer the index of the
array type to get the max size of this array.
>
> So it seems for an attribute it might make sense to implement
> it differently.
implement should be different. but the functionality of the user interface is
better to be kept consistent between attribute and language extension. i.e
in addition to the basic:
struct P {
int k;
int x[.k];
};
will you support expressions:
struct P {
int k;
int x[.k * 4];
}
?
or other more complicated syntax?
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607 --- Comment #4 from anlauf at gcc dot gnu.org --- BTW: the "un-dead code" was introduced with r10-2912-g70570ec1927450 .
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #6 from Eric Botcazou --- > As far as I can tell, this test has always failed on both 32-bit linux and > hpux. Does libgcc/config/pa/milli64.S contain CFI directives or EH tables?
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #7 from dave.anglin at bell dot net --- On 2023-04-03 4:46 p.m., ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 > > --- Comment #6 from Eric Botcazou --- >> As far as I can tell, this test has always failed on both 32-bit linux and >> hpux. > Does libgcc/config/pa/milli64.S contain CFI directives or EH tables? No.
[Bug c/109395] New: -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395
Bug ID: 109395
Summary: -Wvla-larger-than has no effect when compiling without
optimizations
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dev at joren dot ga
Target Milestone: ---
Let's take the following for an example:
int bar(int n, int[n]);
void foo(int n)
{
int arr[n];
for (int i = 0; i < n; ++i) {
arr[i] = i;
}
bar(n, arr);
}
When compiled with
$ gcc -O -Wvla-larger-than=0 -c foo.c
a warning is shown as expected:
foo.c: In function ‘foo’:
foo.c:5:9: warning: argument to variable-length array may be too large
[-Wvla-larger-than=]
5 | int arr[n];
| ^~~
It works with -O, -O1, -O2, -O3, -Os, -Oz, -Ofast
On the other hand, when compiling with -O0, -Og or no -O flag, no warning is
triggered (https://godbolt.org/z/Penjbqojh).
I've tried to find if only a flag implied by optimization is required, but to
no avail.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #8 from Eric Botcazou --- > No. Then the unwinder cannot unwind through it and the test cannot pass.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Keywords||diagnostic Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- This is by designed and is even documented: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wvla-larger-than_003d -Wvla-larger-than=‘PTRDIFF_MAX’ is enabled by default but is typically only effective when -ftree-vrp is active (default for -O2 and above).
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #2 from Jakub Łukasiewicz --- (In reply to Andrew Pinski from comment #1) > This is by designed and is even documented: > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index- > Wvla-larger-than_003d > > -Wvla-larger-than=‘PTRDIFF_MAX’ is enabled by default but is typically only > effective when -ftree-vrp is active (default for -O2 and above). Passing `-ftree-vrp` doesn't activate it either
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #3 from Andrew Pinski --- (In reply to Jakub Łukasiewicz from comment #2) > Passing `-ftree-vrp` doesn't activate it either Because of another part of the documentation: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options Most optimizations are completely disabled at -O0 or if an -O level is not set on the command line, even if individual optimization flags are specified. Similarly, -Og suppresses many optimization passes.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #4 from Jakub Łukasiewicz --- (In reply to Andrew Pinski from comment #3) > (In reply to Jakub Łukasiewicz from comment #2) > > Passing `-ftree-vrp` doesn't activate it either > > Because of another part of the documentation: > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options > > Most optimizations are completely disabled at -O0 or if an -O level is not > set on the command line, even if individual optimization flags are > specified. Similarly, -Og suppresses many optimization passes. So there is not way of detecting automatic VLA in "debug release"?
[Bug sanitizer/108497] UBsan at -O1 failed to report an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108497 --- Comment #4 from Li Shaohua --- (In reply to Jakub Jelinek from comment #3) > Not now nor in the near future. After all, it isn't a regression, so > couldn't be fixed during stage4 anyway. This bug affects GCC>=8. GCC<=7 work fine on this case.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Łukasiewicz from comment #4) > So there is not way of detecting automatic VLA in "debug release"? -Wvla works. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wvla
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #6 from Jakub Łukasiewicz --- (In reply to Andrew Pinski from comment #5) > (In reply to Jakub Łukasiewicz from comment #4) > > So there is not way of detecting automatic VLA in "debug release"? > > -Wvla works. > > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wvla But also marks desired VLA (like in function parameters) $ gcc -std=c99 -Wvla -c foo.c foo.c:1:1: warning: ISO C90 forbids variable length array [-Wvla] 1 | int bar(int n, int[n]); | ^~~ foo.c: In function ‘foo’: foo.c:5:5: warning: ISO C90 forbids variable length array ‘arr’ [-Wvla] 5 | int arr[n]; | ^~~
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607
--- Comment #5 from Steve Kargl ---
On Mon, Apr 03, 2023 at 08:16:20PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #2)
> > Remove ice-on-invalid-code as I don't get an ICE.
> >
> > The following patch suppresses the error message with the temporary variable
> > and removes duplicated code. Please commit.
> >
> > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > index 46585879ddc..3462d43f346 100644
> > --- a/gcc/fortran/resolve.cc
> > +++ b/gcc/fortran/resolve.cc
> > @@ -9909,11 +9909,6 @@ resolve_select_rank (gfc_code *code, gfc_namespace
> > *old_ns)
> >|| gfc_expr_attr (code->expr1).pointer))
> > gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> >"allocatable selector at %L", &c->where,
> > &code->expr1->where);
> > -
> > - if (case_value == -1 && (gfc_expr_attr (code->expr1).allocatable
> > - || gfc_expr_attr (code->expr1).pointer))
> > - gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> > - "allocatable selector at %L", &c->where,
> > &code->expr1->where);
> > }
> >
> >/* Add EXEC_SELECT to switch on rank. */
>
> This is a gem: not dead code, but un-dead code ... ;-)
>
What I haven't concluded yet is if the code was copied
with the intention to edit for another error condition,
e.g., "case_value == -2" or check on code->expr2.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #7 from Andrew Pinski --- Yes and that is still a VLA in terms of C99 definition ...
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #8 from Andrew Pinski --- Note GCC's C++ front-end even rejects VLA definitions like that for parameters so I don't know how useful they are really.
