[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912 --- Comment #5 from rguenther at suse dot de --- On Tue, 30 Nov 2021, eggert at cs dot ucla.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912 > > --- Comment #4 from eggert at cs dot ucla.edu --- > (In reply to Aldy Hernandez from comment #3) > > > && !(leapcnt == 0 > > >|| (prevcorr < corr > > >? corr == prevcorr + 1 > > >: (corr == prevcorr > > > || corr == prevcorr - 1) > > > > > > > I guess the question is whether language rules allow us to read prevcorr > > when leapcnt== 0? > > The C language rules do not allow that. When leapcnt is zero, behavior must be > as if the prevcorr expression is not evaluated. > > Although the compiler can generate machine code that evaluates prevcorr at the > machine level (so long as the observable behavior is the same, which is the > case as prevcorr is not volatile and no untoward behavior can result from > evaluating the prevcorr expression), it's incorrect if the compiler warns the > programmer that prevcorr is used uninitialized. Correct. I think we have quite some duplicates around this issue of making short-circuiting conditionals not short-circuiting (we do that even early during GENERIC folding). "Proving" that all participating sub-expressions are fully initialized is impossible so the only reasonable way to "fix" the issue (the uninit warnings) might be to mark the now unconditionally evaluated sub-expressions with -Wno-uninitialized (aka no-warning or suppress uninit warnings).
[Bug target/102239] powerpc suboptimal boolean test of contiguous bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #11 from luoxhu at gcc dot gnu.org ---
+(define_insn_and_split "*anddi3_insn_dot"
+ [(set (pc)
+(if_then_else (eq (and:DI (match_operand:DI 1 "gpc_reg_operand" "%r,r")
+ (match_operand:DI 2 "const_int_operand" "n,n"))
+ (const_int 0))
+ (label_ref (match_operand 3 ""))
+ (pc)))
+ (clobber (match_scratch:DI 0 "=r,r"))]
+ "rs6000_is_valid_2insn_and (operands[2], DImode)
+ && !(rs6000_is_valid_and_mask (operands[2], DImode)
+ || logical_const_operand (operands[2], DImode))"
+ "#"
+ "&& reload_completed"
+ [(pc)]
+{
+ int nb, ne;
+ if (rs6000_is_valid_mask (operands[2], , , DImode) && nb >= ne)
+ {
+ unsigned HOST_WIDE_INT val = INTVAL (operands[2]);
+ int shift = 63 - nb;
+ rtx tmp = gen_rtx_ASHIFT (DImode, operands[1], GEN_INT (shift));
+ tmp = gen_rtx_AND (DImode, tmp, GEN_INT (val << shift));
+ rtx cr0 = gen_rtx_REG (CCmode, CR0_REGNO);
+ rs6000_emit_dot_insn (operands[0], tmp, 1, cr0);
+ rtx loc_ref = gen_rtx_LABEL_REF (VOIDmode, operands[3]);
+ rtx cond = gen_rtx_EQ (CCEQmode, cr0, const0_rtx);
+ rtx ite = gen_rtx_IF_THEN_ELSE (VOIDmode, cond, loc_ref, pc_rtx);
+ emit_jump_insn (gen_rtx_SET (pc_rtx, ite));
+ DONE;
+ }
+ else
+ FAIL;
+}
+ [(set_attr "type" "shift")
+ (set_attr "dot" "yes")
+ (set_attr "length" "8,12")])
+
This pattern could combine the two instructions from
9: {r123:CC=cmp(r124:DI&0x6,0);clobber scratch;}
REG_DEAD r124:DI
10: pc={(r123:CC==0)?L15:pc}
REG_DEAD r123:CC
to:
10: {pc={(r124:DI&0x6==0)?L15:pc};clobber scratch;}
then split2 will split it to one rotate dot instruction, is this OK?
(insn 32 9 33 2 (parallel [
(set (reg:CC 100 0)
(compare:CC (and:DI (ashift:DI (reg:DI 3 3 [124])
(const_int 29 [0x1d]))
(const_int -4611686018427387904 [0xc000]))
(const_int 0 [0])))
(clobber (reg:DI 3 3 [125]))
]) "pr102239.c":4:6 239 {*rotldi3_mask_dot}
(nil))
(jump_insn 33 32 11 2 (set (pc)
(if_then_else (eq:CCEQ (reg:CC 100 0)
(const_int 0 [0]))
(label_ref 15)
(pc))) "pr102239.c":4:6 869 {*cbranch}
(int_list:REG_BR_PROB 536870916 (nil))
-> 15)
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #11 from Martin Storsjö --- (In reply to Eric Botcazou from comment #10) > Thanks for reporting the problem. Thanks for the fix! I can confirm that the version of the patch backported on the gcc-10 branch fixes the testcase at least. Let's hope that it manages to fix all the instances of the issue in real-world use too.
[Bug tree-optimization/103514] Missing XOR-EQ-AND Optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103514 --- Comment #2 from Navid Rahimi --- Exactly. Actually in my final version I had it with single loop, but didn't know I can remove the condition too. Thanks Andrew.
[Bug tree-optimization/103514] Missing XOR-EQ-AND Optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103514 --- Comment #1 from Andrew Pinski --- Note the loop should be: (for first_op (bit_xor eq ) second_op (eq bit_xor) (simplify (first_op:c (bit_and:c truth_valued_p@0 truth_valued_p@1) (second_op:c @0 @1)) (bit_not (bit_ior @0 @1) No reason fore the double for loop
[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513 --- Comment #3 from Andrew Pinski --- Note we disable the creation of the cond_expr here normally until !canonicalize_math_p () is true But evrp does: Folding statement: _10 = _9 * 20; Matching expression match.pd:2075, gimple-match.c:819 Matching expression match.pd:2078, gimple-match.c:892 Matching expression match.pd:2085, gimple-match.c:952 Applying pattern match.pd:5297, gimple-match.c:53296 Matching expression match.pd:1718, gimple-match.c:280 Matching expression match.pd:2075, gimple-match.c:819 Matching expression match.pd:2078, gimple-match.c:892 Matching expression match.pd:2085, gimple-match.c:952 gimple_simplified to _10 = _1 == 0 ? 0 : 20; We should definitely be more defensive in evaluate_conditions_for_known_args for the cond_expr but also I think evrp should disable this transformation until later if we produce a cond_expr ...
[Bug tree-optimization/103514] New: Missing XOR-EQ-AND Optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103514
Bug ID: 103514
Summary: Missing XOR-EQ-AND Optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: navidrahimi at microsoft dot com
Target Milestone: ---
We are not optimizing &&-^-== combination, LLVM does it [1]:
// Proof of correctness https://alive2.llvm.org/ce/z/a4tuWF
bool
src (bool a, bool b)
{
return (a && b) == (a ^ b);
}
bool
tgt (bool a, bool b)
{
return !(a || b);
}
// Proof of correctness https://alive2.llvm.org/ce/z/w-iotd
bool
src (bool a, bool b)
{
return (a && b) ^ (a == b);
}
bool
tgt (bool a, bool b)
{
return !(a || b);
}
I will be sending a patch for this. This will solve it, I have to run the
testsuite and write a few tests:
/* (a && b) first_op (a second_op b) -> !(a || b) */
(for first_op (bit_xor eq)
(for second_op (bit_xor eq)
(simplify
(first_op:c (bit_and:c truth_valued_p@0 truth_valued_p@1) (second_op:c @0
@1))
(if (first_op != second_op)
(bit_not (bit_ior @0 @1))
1) https://compiler-explorer.com/z/WqTxYhG3s
[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||jamborm at gcc dot gnu.org --- Comment #2 from Richard Biener --- Yeah, more defensive would have been else res.set_varying (); unreachable is always a bit on the hard side...
[Bug fortran/103506] [10/11/12 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.4 Priority|P3 |P4
[Bug middle-end/103500] Stack slots for overaligned stack temporaries are not properly aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103500 Richard Biener changed: What|Removed |Added Target||aarch64 --- Comment #1 from Richard Biener --- IIRC on x86 we are using callee copying to put stack arguments into an appropriately aligned local stack slot because the ABI does not pass over-aligned types differently from naturally aligned types. Note that is IIRC not for reference passing but for passing on the stack.
[Bug c++/103497] [9/10/11/12 Regression] ICE when decltype(auto)... as parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103497 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510
--- Comment #1 from ashimida ---
For example, such a c code works find in clang with libunwind,
and will cause a crash in gcc with libgcc in aarch64.
#include
#include
#include
_Unwind_Reason_Code callback(struct _Unwind_Context *context, void *args)
{
printf("Unwind Frame X0:%016lx\n", _Unwind_GetGR(context, 0));
return _URC_NO_REASON;
}
int main(void)
{
_Unwind_Backtrace(callback, NULL);
return 0;
}
[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-01 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- _1 = e_4(D) == -1; _5 = _1 ? 20 : 0; It is not expecting the COND_EXPR here
[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug ipa/103513] New: [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513
Bug ID: 103513
Summary: [12 Regression] ICE in
evaluate_conditions_for_known_args, at
ipa-fnsummary.c:516 with -O2 and above
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi all.
It seems to be a recent regression issue.
$cat small.c
#include
uint16_t(a)();
uint16_t(b)(int f, int g) { return f * g; }
uint64_t c();
void d() { c(a()); }
uint64_t c(int e) {
for (;;)
if (b(20, -1L == e))
for (;;)
;
return 0;
}
$gcc -c -O2 small.c
during IPA pass: inline
small.c:12:1: internal compiler error: in evaluate_conditions_for_known_args,
at ipa-fnsummary.c:516
12 | }
| ^
0x6c881e evaluate_conditions_for_known_args
../../gcc/ipa-fnsummary.c:516
0xa6133f do_estimate_edge_size(cgraph_edge*)
../../gcc/ipa-inline-analysis.c:330
0xa6247a estimate_edge_size
../../gcc/ipa-inline.h:79
0xa6247a estimate_edge_growth
../../gcc/ipa-inline.h:100
0xa6247a do_estimate_growth_1
../../gcc/ipa-inline-analysis.c:429
0xa625fd cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/cgraph.h:3411
0xa625fd estimate_growth(cgraph_node*)
../../gcc/ipa-inline-analysis.c:467
0x18d8d6c inline_small_functions
../../gcc/ipa-inline.c:1980
0x18d8d6c ipa_inline
../../gcc/ipa-inline.c:2743
0x18d8d6c execute
../../gcc/ipa-inline.c:3142
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/haoxin/haoxin-data/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/haoxin-data/compilers/gcc/build --enable-bootstrap
--enable-checking=release --enable-languages=c,c++ --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211130 (experimental) (GCC)
Can also quickly check here: https://godbolt.org/z/W18G8jn7E
Thanks,
Haoxin
[Bug tree-optimization/64992] More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 --- Comment #11 from Andrew Pinski --- Note the latest patch for PR 98954 fixes this one.
[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954 Andrew Pinski changed: What|Removed |Added Attachment #50271|0 |1 is obsolete|| --- Comment #5 from Andrew Pinski --- Created attachment 51911 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51911=edit New patch New partial patch, still need testcases. But this fixes this bug, PR 98956 and PR 64992 .
[Bug c++/103512] New: The failure of the substitution in explicit-specifier should be considered when overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103512
Bug ID: 103512
Summary: The failure of the substitution in explicit-specifier
should be considered when overload resolution
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
#include
struct A{
static bool const value = true;
};
struct C{
template
explicit(T::value) C(T){}
// template
// explicit(T::value) C(T*){}
};
int main(){
A* ptr = nullptr;
C d(ptr);
}
This example is accepted by GCC, whilst it is rejected by other compilers.
According to [temp.deduct.general] p8
If a substitution results in an invalid type or expression, type deduction
fails. An invalid type or expression is one that would be ill-formed, with a
diagnostic required, if written in the same context using the substituted
arguments. Only invalid types and expressions in the immediate context of the
function type, its template parameter types, and its explicit-specifier can
result in a deduction failure.
Since there is no other candidate and the unique candidate should be considered
as deducing failure, the overload resolution should be a failure, the program
should be ill-formed.
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #8 from cqwrteur --- (In reply to cqwrteur from comment #7) > (In reply to cqwrteur from comment #6) > > (In reply to Jonathan Wakely from comment #3) > > > Fixed on trunk so far, but this is backportable. > > > > Turns out _GLIBCXX_SANITIZE_VECTOR is not defined if libsanitizer is not > > built with GCC. But GCC does not support sanitizers on windows. > > > > Can we just remove this macro and only use _GLIBCXX_SANITIZE_STD_ALLOCATOR? > > clang++ -o vec vec.cc -Ofast -std=c++2b -fuse-ld=lld > -fsanitize=address,undefined -D_GLIBCXX_SANITIZE_VECTOR > > D:\hg\fast_io\examples\0007.legacy>vec > = > ==10284==ERROR: AddressSanitizer: container-overflow on address > 0x021fa68f6bd8 at pc 0x7ff7dae516df bp 0x00347beff840 sp 0x00347beff888 > WRITE of size 8 at 0x021fa68f6bd8 thread T0 > > Also works Does this toggle need to turn on manually for std::vector?
[Bug c++/103511] New: __builtin_bit_cast requires a constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511
Bug ID: 103511
Summary: __builtin_bit_cast requires a constructor call
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
According to [class.prop] p1, a trivially copyable class may have all of its
constructors deleted. And according to [bit.cast] p1, an object of such a class
type can be created or copied by std::bit_cast since C++20.
But currently gcc's __builtin_bit_cast seemly requires that the target type has
at least one eligible copy or move constructor.
#include
class Weird {
Weird(const Weird&) = delete;
Weird(Weird&&) = delete;
// works when either constructor is changed to = default
Weird =(const Weird&) = default;
Weird =(Weird&&) = default;
int value_;
};
int main()
{
auto x [[maybe_unused]] = std::bit_cast(0);
}
wandbox links:
https://wandbox.org/permlink/giaPU2R4O2XeF6UF
https://wandbox.org/permlink/lrMmtVw1mt5nZjqY
[Bug libgcc/103510] New: _Unwind_GetGR crashed for uninitialized registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510 Bug ID: 103510 Summary: _Unwind_GetGR crashed for uninitialized registers Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: ashimida at linux dot alibaba.com Target Milestone: --- When use _Unwind_Backtrace with a callback funciton for backtrace, if the reg corresponding to i is not initialized when calling _Unwind_GetGR(context, i) in the callback, it will cause a crash due to 0 address dereference. Although the register status can be predicted by calling _Unwind_GetGRPtr or other methods, these functions are not within the LSB standard. Clang works fine for this. Is there any way for me to write a common backtrace function that uses _Unwind_Backtrace, or is it reasonable to initialize all context->reg[x] with the values of all hardware registers at the beginning of unwind?
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 66839, which changed state. Bug 66839 Summary: g++ accepts NSDMI with -std=c++98 when the intializer is a macro defined in a standard header https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66839 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/103347] [9/10/11 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #12 from ensadc at mailnesia dot com --- *** Bug 66839 has been marked as a duplicate of this bug. ***
[Bug c++/66839] g++ accepts NSDMI with -std=c++98 when the intializer is a macro defined in a standard header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66839 ensadc at mailnesia dot com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from ensadc at mailnesia dot com --- Seems to be fixed by r12-5488 *** This bug has been marked as a duplicate of bug 103347 ***
[Bug target/103017] Fix redundant check in aut insn generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103017 ashimida changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from ashimida --- Submitted at https://gcc.gnu.org/pipermail/gcc-patches/2021-November/582997.html
[Bug c++/103478] More explanation for error on constexpr function parameter used in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103478 Jason Merrill changed: What|Removed |Added Severity|normal |enhancement Summary|Possible regression in |More explanation for error |constexpr processing|on constexpr function ||parameter used in a ||constant expression
[Bug tree-optimization/103144] vectorizer failed to recognize shift>>=1 in loop as shift>>i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103144
--- Comment #2 from Hongtao.liu ---
Another issue is for SLP, when trip count is small and loop is completely
unrolled. SLP failed to generate vlshr_optab.
#include
void
foo (uint64_t* __restrict pdst, uint64_t* psrc, uint64_t shift)
{
for (int64_t i = 0; i != 4; i++)
{
pdst[i] = psrc[i] + shift;
shift >>= 1;
}
}
.175t.slp1 dump:
_8 = *psrc_12(D);
_28 = _8 + shift_10(D);
shift_30 = shift_10(D) >> 1;
_39 = psrc_12(D) + 8;
_40 = *_39;
_41 = pdst_13(D) + 8;
_42 = shift_30 + _40;
shift_44 = shift_30 >> 1;
_53 = psrc_12(D) + 16;
_54 = *_53;
_55 = pdst_13(D) + 16;
_56 = shift_44 + _54;
shift_58 = shift_44 >> 1;
_3 = psrc_12(D) + 24;
_4 = *_3;
_5 = pdst_13(D) + 24;
_6 = _4 + shift_58;
_15 = {_28, _42, _56, _6};
vectp.8_18 = pdst_13(D);
MEM [(uint64_t *)vectp.8_18] = _15;
[Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502 --- Comment #7 from Stas Sergeev --- (In reply to Eric Gallager from comment #6) > -Wstrict-aliasing is kind of confusing in this regards since it's different > from how other warnings with numerical levels work. Normally a higher > numerical value to a warning option means "print more warnings" but for > -Wstrict-aliasing it means "try harder to reduce the number of warnings". Number of warnings, or number of false-positives? This is what is still unclear to me. If it reduces the number of warnings (including valid ones, by not applying some checks for example), then indeed what you propose can be done (or not done - it would be rather straight-forward anyway). But I had the following assumptions: 1. It reduces the number of only false-positives 2. It increases the amount of warnings by avoiding false-negatives (i.e. by not "hiding" the warnings that lower levels could miss) 3. The warning I've seen on lower levels was a valid one I suppose what you propose, can be done if 2 is not true. I still don't know which of the above wasn't true.
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #7 from cqwrteur --- (In reply to cqwrteur from comment #6) > (In reply to Jonathan Wakely from comment #3) > > Fixed on trunk so far, but this is backportable. > > Turns out _GLIBCXX_SANITIZE_VECTOR is not defined if libsanitizer is not > built with GCC. But GCC does not support sanitizers on windows. > > Can we just remove this macro and only use _GLIBCXX_SANITIZE_STD_ALLOCATOR? clang++ -o vec vec.cc -Ofast -std=c++2b -fuse-ld=lld -fsanitize=address,undefined -D_GLIBCXX_SANITIZE_VECTOR D:\hg\fast_io\examples\0007.legacy>vec = ==10284==ERROR: AddressSanitizer: container-overflow on address 0x021fa68f6bd8 at pc 0x7ff7dae516df bp 0x00347beff840 sp 0x00347beff888 WRITE of size 8 at 0x021fa68f6bd8 thread T0 Also works
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #6 from cqwrteur --- (In reply to Jonathan Wakely from comment #3) > Fixed on trunk so far, but this is backportable. Turns out _GLIBCXX_SANITIZE_VECTOR is not defined if libsanitizer is not built with GCC. But GCC does not support sanitizers on windows. Can we just remove this macro and only use _GLIBCXX_SANITIZE_STD_ALLOCATOR?
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453
--- Comment #5 from cqwrteur ---
(In reply to Jonathan Wakely from comment #3)
> Fixed on trunk so far, but this is backportable.
#include
int main()
{
std::vector vec;
vec.reserve(20);
vec[3]=40;
}
clang++ -o vec vec.cc -Ofast -std=c++2b -fuse-ld=lld
-fsanitize=address,undefined
Nothing.
clang++ -o vec vec.cc -Ofast -std=c++2b -I../../include -fuse-ld=lld
-fsanitize=address,undefined -D_GLIBCXX_SANITIZE_STD_ALLOCATOR
-D_GLIBCXX_SANITIZE_VECTOR
=
==15804==ERROR: AddressSanitizer: container-overflow on address 0x01e922536bd8
at pc 0x7ff6596d16df bp 0x0001000ff700 sp 0x0001000ff748
WRITE of size 8 at 0x01e922536bd8 thread T0
#0 0x7ff6596d16de in main
(D:\hg\fast_io\examples\0007.legacy\vec.exe+0x1400016de)
#1 0x7ff6596d13b0 in __tmainCRTStartup
/home/cqwrteur/myhome/gcc_build/canadian/x86_64-w64-mingw32/mingw-w64/mingw-w64-crt/../../../../../mingw-w64/mingw-w64-crt/crt/crtexe.c:321:15
#2 0x7ff6596d14e5 in mainCRTStartup
/home/cqwrteur/myhome/gcc_build/canadian/x86_64-w64-mingw32/mingw-w64/mingw-w64-crt/../../../../../mingw-w64/mingw-w64-crt/crt/crtexe.c:202:9
#3 0x7ffc57577033 (C:\WINDOWS\System32\KERNEL32.DLL+0x180017033)
#4 0x7ffc58fe2650 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x180052650)
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #4 from cqwrteur --- (In reply to Jonathan Wakely from comment #3) > Fixed on trunk so far, but this is backportable. Still Does not work on x86_64-w64-mingw32 on windows by default, -D_GLIBCXX_SANITIZE_STD_ALLOCATOR -D_GLIBCXX_SANITIZE_VECTOR works but the default option does not. Why?
[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64992 --- Comment #4 from Andrew Pinski --- This is actually the general case of PR 64992 where CST1 in that case is just a mask of all 1s. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992#c8
[Bug target/103484] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -O2 -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103484 --- Comment #6 from Hongtao.liu --- Fixed in GCC12.
[Bug target/103463] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -Os -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103463 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Hongtao.liu --- Really fixed in GCC12.
[Bug analyzer/100524] pragma GCC diagnostic ignored "-Wanalyzer-too-complex" ignored by cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100524 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- (In reply to David Malcolm from comment #1) > Firstly, what you wrote in comment #0 has the directive transposed as: > #pragma diagnostic GCC [...action...] > whereas the directive should be: > #pragma GCC diagnostic [...action...] Maybe that itself should be a warning? Does -Wpragmas have anything to say?
[Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > The documentation > (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options) > for the warning is clear here: > "Takes care of the common pun+dereference pattern in the front end: > *(int*)_float. " > > >3 is documented as the most precise option > > I think you misunderstood what precise means in this context really. > "Higher levels correspond to higher accuracy (fewer false positives). " -Wstrict-aliasing is kind of confusing in this regards since it's different from how other warnings with numerical levels work. Normally a higher numerical value to a warning option means "print more warnings" but for -Wstrict-aliasing it means "try harder to reduce the number of warnings". Perhaps this is an inconsistency that should be rectified?
[Bug tree-optimization/103509] ((-1u >> t) & b) != 0 is not optimized to b != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103509 Navid Rahimi changed: What|Removed |Added CC||navidrahimi at microsoft dot com --- Comment #1 from Navid Rahimi --- Thanks Andrew. How about we close [1] in favor of this, to make sure we have only single place to track this issue. Previous discussion about this was here [2]. 1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956 2) https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585783.html
[Bug target/103463] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -Os -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103463 --- Comment #6 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:f5e2f2d0ad1b293c534338a72094926313e12039 commit r12-5647-gf5e2f2d0ad1b293c534338a72094926313e12039 Author: liuhongt Date: Tue Nov 30 16:24:39 2021 +0800 Fix ICE in ix86_attr_length_immediate_default. ix86_attr_length_immediate_default assume TYPE ishift only have 1 constant operand, but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or INTVAL (operands[3]) == 64 - INTVAL (operands[2]), and hit gcc_assert. Explicitly set_attr length_immediate for these patterns. gcc/ChangeLog: PR target/103463 PR target/103484 * config/i386/i386.md (*x86_64_shld_1): Set_attr length_immediate to 1. (*x86_shld_1): Ditto. (*x86_64_shrd_1): Ditto. (*x86_shrd_1): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr103463.c: New test. * gcc.target/i386/pr103463-2.c: New test.
[Bug target/103484] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -O2 -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103484 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:f5e2f2d0ad1b293c534338a72094926313e12039 commit r12-5647-gf5e2f2d0ad1b293c534338a72094926313e12039 Author: liuhongt Date: Tue Nov 30 16:24:39 2021 +0800 Fix ICE in ix86_attr_length_immediate_default. ix86_attr_length_immediate_default assume TYPE ishift only have 1 constant operand, but *x86_64_shld_1/*x86_shld_1/*x86_64_shrd_1/*x86_shrd_1 has 2, with condition: INTVAL (operands[3]) == 32 - INTVAL (operands[2]) or INTVAL (operands[3]) == 64 - INTVAL (operands[2]), and hit gcc_assert. Explicitly set_attr length_immediate for these patterns. gcc/ChangeLog: PR target/103463 PR target/103484 * config/i386/i386.md (*x86_64_shld_1): Set_attr length_immediate to 1. (*x86_shld_1): Ditto. (*x86_64_shrd_1): Ditto. (*x86_shrd_1): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr103463.c: New test. * gcc.target/i386/pr103463-2.c: New test.
[Bug tree-optimization/103509] New: ((-1u >> t) & b) != 0 is not optimized to b != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103509
Bug ID: 103509
Summary: ((-1u >> t) & b) != 0 is not optimized to b != 0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
bool f1(bool a, int t)
{
unsigned tt = -1;
tt >>= t;
return (a) != 0;
}
bool f2(bool a, int t)
{
unsigned tt = -1;
tt >>= t;
return (tt) != 0;
}
As shown by the above, we know that (-1u>>t)!=0 is always true Therefore we
should be able to optimize f1 to just a!=0
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217 --- Comment #11 from David Malcolm --- Excellent! Thanks for the feedback.
[Bug tree-optimization/103491] nextafter does not raise "overflow" and "inexact" floating-point exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491 --- Comment #3 from joseph at codesourcery dot com --- This testcase is incorrect. This call to nextafter has a finite result, so it's correct that no exceptions are raised and so an exit status of 1 from the provided testcase is what should be expected. A GCC bug could only be demonstrated if the call were elided for arguments for which overflow or underflow occurs (such as (DBL_MAX, INFINITY) or (DBL_MIN, 0) or (DBL_TRUE_MIN, 0)). I haven't tested whether that is the case.
[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #14 from David Malcolm --- Looking at recents posts to gcc-testresults, I don't see any reference to "analyzer"; e.g.: Results for 12.0.0 (DEFMODE=thumb DEFARCH=armv7-a DEFCPU=default DEFFPU=default TESTFLAGS=) [r12-4816] (GCC) testsuite on arm-none-linux-gnueabi https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/732306.html Results for 12.0.0 (DEFMODE=default DEFARCH=default DEFCPU=default DEFFPU=default TESTFLAGS=-mthumb/-mfloat-abi=hard/-march=armv7e-m+fp) [r12-4816] (GCC) testsuite on arm-none-eabi https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/732304.html Results for 12.0.0 (DEFMODE=default DEFARCH=default DEFCPU=default DEFFPU=default TESTFLAGS=-mabi=ilp32) [r12-4816] (GCC) testsuite on aarch64-none-elf https://gcc.gnu.org/pipermail/gcc-testresults/2021-November/732301.html Is anyone still seeing these failures with trunk? I'm going to go ahead and mark this as resolved; please reopen it if you're still seeing issues.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #43 from cqwrteur --- Created attachment 51910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51910=edit new patch after today's update Can we just push this to main?
[Bug analyzer/100524] pragma GCC diagnostic ignored "-Wanalyzer-too-complex" ignored by cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100524 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- I've added a regression test for this. I'm going to mark this as resolved; feel free to reopen it if you can reproduce the issue (with the preprocessed source and the command-line options); see the notes in comment #1 above. Thanks.
[Bug analyzer/94579] OVS compiled with gcc10 with -fanalyzer since r10-7502-ga96f1c38a787fbc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94579 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from David Malcolm --- I've heavily rewritten the code since gcc 10, and can't reproduce the issue. I've added the reproducer from comment #3 to the regression tests (as per comment #5). Marking as resolved.
[Bug target/102239] powerpc suboptimal boolean test of contiguous bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239 --- Comment #10 from Segher Boessenkool --- (In reply to luoxhu from comment #9) > > It does matter, if what you are want to see is if it is smaller than zero or > > greater than zero. CCmode includes those things. There is a CCEQmode for > > if only the EQ bit is set correctly. > > Got it, thanks. As the example in c#7. If CCmode is LT, rotate data to > highest bits will get negative result and set CR0 to negative, which is > unexpected. CCmode is all three (or four, for non-fast FP) comparison results at once. You can use for example both LT and EQ on the same result. In CCEQmode only the EQ bit is valid. > > Some pattern that just does this as an rldicr, as a single insn. It will > > have to be excluded by the 2insn thing (it is only a single insn itself!), > > and it will have to have comparison mode CCEQ only. > > I was motivated by the clang code, and tried to rotate the data to LSB > instead, it doesn't suffer from CCmode issue again? Will this be simpler > than the combine & new pattern solution? It is incorrect, in a similar way. It also is sub-optimal, it is better to tell GCC that this pattern will be only one machine insn, so that it can consider that when choosing the best insn patterns to use. Also note the comment right before this code: /* If it is one stretch of ones, it is DImode; shift left, mask, then shift right. This generates better code than doing the masks without shifts, or shifting first right and then left. */
[Bug analyzer/99269] False positive -Wanalyzer-malloc-leak/-Wanalyzer-double-free with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99269 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Fixed in GCC 11; test coverage added by above commit to GCC 12 onwards.
[Bug analyzer/94579] OVS compiled with gcc10 with -fanalyzer since r10-7502-ga96f1c38a787fbc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94579 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:955ea7b58e4f1e3cc5083e88575161168c147254 commit r12-5642-g955ea7b58e4f1e3cc5083e88575161168c147254 Author: David Malcolm Date: Tue Nov 30 15:31:59 2021 -0500 analyzer: add regression test [PR94579] gcc/testsuite/ChangeLog: PR analyzer/94579 * gcc.dg/analyzer/pr94579.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/99269] False positive -Wanalyzer-malloc-leak/-Wanalyzer-double-free with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99269 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:9603bccba62e250d0ff64863a1730a167d571a25 commit r12-5641-g9603bccba62e250d0ff64863a1730a167d571a25 Author: David Malcolm Date: Tue Nov 30 14:47:24 2021 -0500 analyzer: add regression test [PR99269] gcc/testsuite/ChangeLog: PR analyzer/99269 * gcc.dg/analyzer/pr99269.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/100524] pragma GCC diagnostic ignored "-Wanalyzer-too-complex" ignored by cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100524 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:03ea0ca1189a39e095188b0425c66446cc84a0a5 commit r12-5640-g03ea0ca1189a39e095188b0425c66446cc84a0a5 Author: David Malcolm Date: Tue Nov 30 14:21:31 2021 -0500 analyzer: verify that -Wanalyzer-too-complex can be disabled via pragmas [PR100524] gcc/testsuite/ChangeLog: PR analyzer/100524 * gcc.dg/analyzer/pragma-2.c: New test. Signed-off-by: David Malcolm
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 --- Comment #5 from John McFarlane --- Here is an example of the real-world code causing this warning: https://github.com/johnmcfarlane/cnl/blob/6d46b6cf10a998e3bdcc32557f202c8579b5717c/test/unit/scaled_int/to_chars.h#L60 It is converting a numeric type to a string with a `to_chars`-like API. It's entirely feasible that a user might wish to convert a number to a 1-digit string and encounter a false positive. I've tried adding the recommended `__builtin_unreachable()` statement at several points in `test` and `to_chars_natural` and it doesn't suppress the warning. The best course of action I can see is to disable the warnings for GCC-12 and beyond: https://github.com/johnmcfarlane/cnl/blob/main/test/toolchain/gcc-head.cmake#L5 I feel that this is counterproductive.
[Bug libstdc++/103501] associative containers left invalid after allocator-extended move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103501 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-30 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This causes the following failures when using --enable-fully-dynamic-string on trunk: FAIL: 23_containers/multiset/allocator/move_cons.cc execution test FAIL: 23_containers/map/allocator/move_cons.cc execution test FAIL: 23_containers/multimap/allocator/move_cons.cc execution test FAIL: 23_containers/set/allocator/move_cons.cc execution test This is because a moved-from fully-dynamic string is no longer empty. As shown above, the problem is broader than just fully-dynamic strings.
[Bug tree-optimization/64992] More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> Note for rotate it is as simple as:
> (for cmp (eq ne)
> (simplify
> (cmp (rotate @0 INTEGER_CST@1) INTEGER_CST@2)
> (cmp @0 (rotate @2 @1
>
> Let me see if that is already there or not and test that one out.
Well it is already done (and I messed up the above which should have been
invrotote anyways):
/* (X >>r C1) cmp C2 may simplify to X cmp C3. */
(simplify
(cmp (rotate @0 INTEGER_CST@1) INTEGER_CST@2)
(cmp @0 { const_binop (invrot, TREE_TYPE (@0), @2, @1); }))
So it is just lshift and rshift that need to be implemented.
[Bug tree-optimization/64992] More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 --- Comment #9 from Andrew Pinski --- Note for rotate it is as simple as: (for cmp (eq ne) (simplify (cmp (rotate @0 INTEGER_CST@1) INTEGER_CST@2) (cmp @0 (rotate @2 @1 Let me see if that is already there or not and test that one out.
[Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502 --- Comment #5 from Stas Sergeev --- Note that this code example is trivial. If the warning have disappeared as a false-negative, then I am surprised you close this as NOTABUG, as there is definitely something to fix or improve here. Not detecting such a trivial case is a bug. If OTOH gcc actually deduced that this code is safe, then I am more than happy, but this have to be confirmed explicitly. You inserted the seemingly redundant "not" in your sentence, so I am not sure what you actually meant to say.
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217 --- Comment #10 from Dominique Martinet --- Thank you for this work! I can confirm this indeed fixed the warning in my application as well, time to add a fanalyzer build to my CI :)
[Bug tree-optimization/98956] Failure to optimize out boolean left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956 Andrew Pinski changed: What|Removed |Added Depends on||64992 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- I just realized this is the same as PR 64992 which I almost have a patch. You don't even need bools. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992#c8 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 [Bug 64992] More optimize opportunity
[Bug fortran/103283] ICE in gfc_trans_array_constructor_subarray, at fortran/trans-array.c:1972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103283 --- Comment #3 from anlauf at gcc dot gnu.org --- There's more to it: program p type t integer :: a(1) = 2 end type type(t), parameter :: x(1) = t(3) integer, parameter :: k(*) = x(1)%a end This fails with: pr103283-z1.f90:6:28: 6 | integer, parameter :: k(*) = x(1)%a |1 Error: Cannot initialize implied-shape array at (1) with scalar Funny.
[Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502 --- Comment #4 from Stas Sergeev --- (In reply to Andrew Pinski from comment #3) > Because GCC can optimize that pun+dereference pattern without _not_ breaking Did you mean to say "without breaking the code"? I will assume it is the case: > the code, GCC decided it should not warn with =3. So there is no breakage then? Can I trust this no-warning? Or what did the above "not" meant?
[Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502 --- Comment #3 from Andrew Pinski --- (In reply to Stas Sergeev from comment #2) > (In reply to Andrew Pinski from comment #1) > > I think you misunderstood what precise means in this context really. > > "Higher levels correspond to higher accuracy (fewer false positives). " > > So was it a false-positive? There are still false negatives. You missed the first part: "Takes care of the common pun+dereference pattern in the front end: *(int*)_float. " Because GCC can optimize that pun+dereference pattern without not breaking the code, GCC decided it should not warn with =3.
[Bug fortran/103283] ICE in gfc_trans_array_constructor_subarray, at fortran/trans-array.c:1972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103283 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-11-30 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Reduced testcase: program p type t integer :: a(1) = 2 end type type(t), parameter :: x(1) = t(3) print *, (x(1)%a) ! ICE end
[Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502 --- Comment #2 from Stas Sergeev --- (In reply to Andrew Pinski from comment #1) > I think you misunderstood what precise means in this context really. > "Higher levels correspond to higher accuracy (fewer false positives). " So was it a false-positive?
[Bug c++/103408] ICE when requires auto(x) in C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103408
--- Comment #4 from Marek Polacek ---
(In reply to 康桓瑋 from comment #3)
> (In reply to Marek Polacek from comment #2)
> > Started with r12-5386, obviously.
>
> I don't know if it is caused by the same bug.
>
> template
> concept C = auto([]{});
> static_assert(C<0>);
>
> https://godbolt.org/z/nj6qbGxP7
That's a different bug, but I think I can fix that too.
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787 --- Comment #12 from anlauf at gcc dot gnu.org --- *** Bug 103263 has been marked as a duplicate of this bug. ***
[Bug fortran/103263] ICE in gfc_check_reshape, at fortran/check.c:4830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103263 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from anlauf at gcc dot gnu.org --- Should be fixed by: The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6b8ecbc6d6652d061d7c72c64352d51eca2df6ca commit r12-5639-g6b8ecbc6d6652d061d7c72c64352d51eca2df6ca Author: Harald Anlauf Date: Sat Nov 27 21:43:52 2021 +0100 Fortran: improve expansion of constant array expressions within constructors gcc/fortran/ChangeLog: PR fortran/102787 * array.c (expand_constructor): When encountering a constant array expression or array section within a constructor, simplify it to enable better expansion. gcc/testsuite/ChangeLog: * gfortran.dg/array_constructor_54.f90: New test. *** This bug has been marked as a duplicate of bug 102787 ***
[Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- The documentation (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options) for the warning is clear here: "Takes care of the common pun+dereference pattern in the front end: *(int*)_float. " >3 is documented as the most precise option I think you misunderstood what precise means in this context really. "Higher levels correspond to higher accuracy (fewer false positives). "
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||gs...@t-online.de --- Comment #11 from anlauf at gcc dot gnu.org --- *** Bug 103261 has been marked as a duplicate of this bug. ***
[Bug fortran/103261] ICE in gfc_check_reshape, at fortran/check.c:4742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103261 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Should be fixed by: The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6b8ecbc6d6652d061d7c72c64352d51eca2df6ca commit r12-5639-g6b8ecbc6d6652d061d7c72c64352d51eca2df6ca Author: Harald Anlauf Date: Sat Nov 27 21:43:52 2021 +0100 Fortran: improve expansion of constant array expressions within constructors gcc/fortran/ChangeLog: PR fortran/102787 * array.c (expand_constructor): When encountering a constant array expression or array section within a constructor, simplify it to enable better expansion. gcc/testsuite/ChangeLog: * gfortran.dg/array_constructor_54.f90: New test. *** This bug has been marked as a duplicate of bug 102787 ***
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787 --- Comment #10 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6b8ecbc6d6652d061d7c72c64352d51eca2df6ca commit r12-5639-g6b8ecbc6d6652d061d7c72c64352d51eca2df6ca Author: Harald Anlauf Date: Sat Nov 27 21:43:52 2021 +0100 Fortran: improve expansion of constant array expressions within constructors gcc/fortran/ChangeLog: PR fortran/102787 * array.c (expand_constructor): When encountering a constant array expression or array section within a constructor, simplify it to enable better expansion. gcc/testsuite/ChangeLog: * gfortran.dg/array_constructor_54.f90: New test.
[Bug target/103503] RFE: no save registers attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/103503] RFE: no save registers attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503 --- Comment #3 from Andrew Pinski --- the only major target which does not have the interrupt attribute is aarch64.
[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 --- Comment #2 from Tobias Burnus --- (In reply to anlauf from comment #1) > https://j3-fortran.org/doc/year/21/21-134r2.txt > but it still requires using interoperable types etc. > Just asking: did you simply forget to "decorate" your declarations? If you talk about something like 'kind=c_int': On most systems, c_int == c_int32_t == 4 - and gfortran has (by default) a default integer == 4. But also 'kind=8' is very likely to be interoperable; whether it is with c_long or only c_int64_t or ... does not really matter in case of c_sizeof – we just need to know that some C type exists, which is interoperable. [Likewise, integer(kind=c_int128_t) may or may not be interoperable, depending whether that kind is available - and if not, c_int128_t should be a negative number. (Ignoring for now that c_int128_t is a vendor extension.)] But granted, usually you want to be sure that kind matches a specific C integer type and then c_... becomes useful and more portable. * * * 'interoperable type': I have to admit that I tend to get confused whether * "18.3.5 Interoperability of array variables" applies or whether also * "18.3.6 Interoperability of procedures and procedure interfaces" applies. In the latter case, array descriptors are permitted - and that permits allocatables, pointer, sub-sections etc. The former is more restrictive by only permitting explicit shape or assumed size – while the latter permits more. Given that the current wording for c_sizeof is about "that is not an assumed-size array or an assumed-rank array that is associated with an assumed-size array." I think one reasonable reading is that 18.3.6 applies as 18.3.5 does not permit assumed rank. As 21-134r2 shows, the current wording is not ideal – but at the end, the modification just implies that 18.3.5 applies (IMHO).
[Bug target/103503] RFE: no save registers attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503 --- Comment #2 from Andrew Pinski --- RISCV does have the interrupt attribute too which should work here.
[Bug target/103503] RFE: no save registers attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503 --- Comment #1 from Andrew Pinski --- x86 (and I think MIPS) has an interrupt attribute, will that work instead?
[Bug c++/101027] Short-circuit behavior not respected with co_await in while head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101027
kiwixz at outlook dot com changed:
What|Removed |Added
CC||kiwixz at outlook dot com
--- Comment #1 from kiwixz at outlook dot com ---
Hello, I encountered the same problem with gcc evaluating the two asio
coroutine operands of && even when the left one returned false.
See on godbolt: https://godbolt.org/z/Wo8z5PoP3
Expected output (confirmed on clang 12 with libc++):
a
0
GCC 11.2 or trunk:
a
b
0
---
#include
#include
namespace asio = boost::asio;
asio::awaitable a() {
std::cout << "a\n";
co_return false;
}
asio::awaitable b() {
std::cout << "b\n";
co_return false;
}
asio::awaitable f() {
std::cout << ((co_await a()) && (co_await b())) << "\n";
}
int main() {
asio::io_context io;
asio::co_spawn(io, f, asio::detached);
io.run();
}
[Bug fortran/103504] ICE in get_sym_storage_size, at fortran/interface.c:2800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103504 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-11-30 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Likely related to PR103505. The spec for dummy x of subroutine s is foul. symtree: 'x' || symbol: 'x' type spec : (REAL 4) attributes: (VARIABLE DIMENSION DUMMY) Array spec:(1 [0] AS_EXPLICIT 1 1. )
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Priority|P3 |P4 --- Comment #2 from kargl at gcc dot gnu.org --- diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c index 6552eaf3b0c..1b2f5b310a7 100644 --- a/gcc/fortran/array.c +++ b/gcc/fortran/array.c @@ -492,6 +492,9 @@ match_array_element_spec (gfc_array_spec *as) if (!gfc_expr_check_typed (*upper, gfc_current_ns, false)) return AS_UNKNOWN; + if ((*upper)->expr_type != EXPR_CONSTANT) +gfc_simplify_expr (*upper,0); + if (((*upper)->expr_type == EXPR_CONSTANT && (*upper)->ts.type != BT_INTEGER) || ((*upper)->expr_type == EXPR_FUNCTION
[Bug analyzer/100546] -Wanayzer-null-dereference false positive through noreturn function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Fixed on trunk by the above commit for GCC 12: https://godbolt.org/z/17acsYMx5 Marking this one as resolved.
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-11-30 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- How come we let pass a non-integer into the array spec? program p integer, parameter :: a((2.)) = [4, 8] end symtree: 'a' || symbol: 'a' type spec : (INTEGER 4) attributes: (PARAMETER IMPLICIT-SAVE DIMENSION) value: (/ 4 , 8 /) Array spec:(1 [0] AS_EXPLICIT 1 2. ) (Without the extra parentheses this does not happen...)
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #8) > Simpler and better patch which handles array sections as well as vector > subscripts: @Bill: does this patch or the submitted one in https://gcc.gnu.org/pipermail/fortran/2021-November/057066.html fix the regression for you?
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #3 from Jonathan Wakely --- Fixed on trunk so far, but this is backportable.
[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- I learned from Steve that there is a recent interp regarding C_SIZEOF arguments, https://j3-fortran.org/doc/year/21/21-134r2.txt but it still requires using interoperable types etc. Just asking: did you simply forget to "decorate" your declarations?
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cca6090b13ab503bef1cfa327e2d107789d6bd30 commit r12-5636-gcca6090b13ab503bef1cfa327e2d107789d6bd30 Author: Jonathan Wakely Date: Tue Nov 30 13:14:38 2021 + libstdc++: Make Asan detection work for Clang [PR103453] Clang doesn't define __SANITIZE_ADDRESS__ so use its __has_feature check to detect Asan instead. libstdc++-v3/ChangeLog: PR libstdc++/103453 * config/allocator/malloc_allocator_base.h (_GLIBCXX_SANITIZE_STD_ALLOCATOR): Define for Clang. * config/allocator/new_allocator_base.h (_GLIBCXX_SANITIZE_STD_ALLOCATOR): Likewise.
[Bug fortran/101565] ICE in gfc_simplify_image_index, at fortran/simplify.c:8234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101565 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed for gcc-12. Closing. Thanks for the report!
[Bug analyzer/99269] False positive -Wanalyzer-malloc-leak/-Wanalyzer-double-free with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99269 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-11-30 Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Thanks for filing this bug. I'm able to reproduce it with gcc 10.3: https://godbolt.org/z/xajnz8abn but it seems to be fixed in gcc 11 onwards (I heavily rewrote the internals of the analyzer in gcc 11). I'll add this as a regression test to the testsuite and then close this out; thanks again.
[Bug fortran/103473] [11/12 Regression] ICE in simplify_minmaxloc_nodim, at fortran/simplify.c:5287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103473 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:36421e76a7150621f2a5c7060ddd3f80aa825a40 commit r12-5635-g36421e76a7150621f2a5c7060ddd3f80aa825a40 Author: Harald Anlauf Date: Mon Nov 29 22:56:30 2021 +0100 Fortran: error recovery when simplifying MINLOC/MAXLOC gcc/fortran/ChangeLog: PR fortran/103473 * simplify.c (simplify_minmaxloc_nodim): Avoid NULL pointer dereference when shape is not set. gcc/testsuite/ChangeLog: PR fortran/103473 * gfortran.dg/minmaxloc_15.f90: New test.
[Bug fortran/101565] ICE in gfc_simplify_image_index, at fortran/simplify.c:8234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101565 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:814f52a8bfc66aff8c453b040f0e730b034b7f52 commit r12-5634-g814f52a8bfc66aff8c453b040f0e730b034b7f52 Author: Harald Anlauf Date: Mon Nov 29 22:23:02 2021 +0100 Fortran: check type of SUB argument to IMAGE_INDEX gcc/fortran/ChangeLog: PR fortran/101565 * check.c (gfc_check_image_index): Verify that SUB argument to IMAGE_INDEX is of type integer. gcc/testsuite/ChangeLog: PR fortran/101565 * gfortran.dg/coarray_49.f90: New test. Co-authored-by: Steven G. Kargl
[Bug analyzer/100524] pragma GCC diagnostic ignored "-Wanalyzer-too-complex" ignored by cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100524 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-11-30 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug. Firstly, what you wrote in comment #0 has the directive transposed as: #pragma diagnostic GCC [...action...] whereas the directive should be: #pragma GCC diagnostic [...action...] I've tested the latter with a simple reproducer and verified that I can disable -Wanalyzer-too-complex with it, whereas the transposed version of the directive is ignored by GCC and thus does nothing; I'm working on a regression test for this. Secondly, there's an issue with source locations in the diagnostic you quoted: the prefix: "cc1: error: " doesn't contain a source location. Internally this comes from diagnostic_build_prefix when the diagnostic's location has a NULL filename, which is most likely due to a statement with an UNKNOWN_LOCATION. So the issue is due to a statement in GCC's gimple-ssa IR having UNKNOWN_LOCATION for its location, which thus doesn't show up within the range of source locations expressed by the pragma, and thus the diagnostic isn't affected by the pragmas. The fix would be to fix the location of the statement in the gimple-ssa IR, but without a reproducer to identify where that statement's coming from (e.g. in one of the passes that runs before the analyzer), that's hard to do. Do you still have the code that reproduces this issue? (and the precise optimization flags)
[Bug target/103484] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -O2 -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103484 --- Comment #4 from Jakub Jelinek --- Oops, seems Hongtao posted the same patch in the other PR. Will test it but defer to him.
[Bug target/103484] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -O2 -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103484 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 51909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51909=edit gcc12-pr103484.patch This one is my fault. Untested fix.
[Bug fortran/103508] ICE in gfc_find_symtree, at fortran/symbol.c:2979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103508 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- This is the working version : $ cat z2.f90 program p type t(n) integer, len :: n = 1 character(n) :: c end type block block type(t(3)) :: x x%c = 'abc' print *, len(x%c) end block end block end
[Bug fortran/103508] New: ICE in gfc_find_symtree, at fortran/symbol.c:2979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103508 Bug ID: 103508 Summary: ICE in gfc_find_symtree, at fortran/symbol.c:2979 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p type t(n) integer, len :: n = 1 character(n) :: c end type block block type(t(3)) :: x x%c = 'abc' print *, len(x%c) end end end $ gfortran-12-20211128 -c z1.f90 z1.f90:11:9: 11 | end | 1 Error: END BLOCK statement expected at (1) f951: internal compiler error: Segmentation fault 0xf0942f crash_signal ../../gcc/toplev.c:322 0x87a999 gfc_find_symtree(gfc_symtree*, char const*) ../../gcc/fortran/symbol.c:2979 0x87d157 gfc_find_sym_tree(char const*, gfc_namespace*, int, gfc_symtree**) ../../gcc/fortran/symbol.c:3224 0x87d2ae gfc_get_ha_sym_tree(char const*, gfc_symtree**) ../../gcc/fortran/symbol.c:3452 0x809fbe gfc_match_sym_tree(gfc_symtree**, int) ../../gcc/fortran/match.c:680 0x841bec match_variable ../../gcc/fortran/primary.c:4012 0x80a916 gfc_match(char const*, ...) ../../gcc/fortran/match.c:1137 0x80c1dd gfc_match_assignment() ../../gcc/fortran/match.c:1315 0x835a40 match_word ../../gcc/fortran/parse.c:67 0x835a40 decode_statement ../../gcc/fortran/parse.c:363 0x83753a next_free ../../gcc/fortran/parse.c:1397 0x83753a next_statement ../../gcc/fortran/parse.c:1629 0x83ad40 parse_executable ../../gcc/fortran/parse.c:5935 0x83c05f parse_progunit ../../gcc/fortran/parse.c:6205 0x83afbc parse_block_construct ../../gcc/fortran/parse.c:4873 0x83afbc parse_executable ../../gcc/fortran/parse.c:5786 0x83c05f parse_progunit ../../gcc/fortran/parse.c:6205 0x83d2a1 gfc_parse_file() ../../gcc/fortran/parse.c:6724 0x88b37f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/103507] New: ICE in resolve_block_construct, at fortran/resolve.c:10787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103507 Bug ID: 103507 Summary: ICE in resolve_block_construct, at fortran/resolve.c:10787 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Seems to have started with r6 : $ cat z1.f90 subroutine s block end if end program p end $ cat z2.f90 subroutine s block end do end program p end $ cat z4.f90 subroutine s(x) block end if end end $ cat z5.f90 subroutine s(x) block end subroutine end end $ gfortran-12-20211128 -c z1.f90 z1.f90:3:3: 3 | end if | 1 Error: Expecting END BLOCK statement at (1) z1.f90:5:9: 5 | program p | 1 Error: Unexpected PROGRAM statement at (1) f951: internal compiler error: Segmentation fault 0xf0942f crash_signal ../../gcc/toplev.c:322 0x853098 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17556 0x853098 resolve_block_construct ../../gcc/fortran/resolve.c:10787 0x853098 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:12182 0x854f97 resolve_codes ../../gcc/fortran/resolve.c:17536 0x85505e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17571 0x83d314 resolve_all_program_units ../../gcc/fortran/parse.c:6573 0x83d314 gfc_parse_file() ../../gcc/fortran/parse.c:6829 0x88b37f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/103506] New: [10/11/12 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 Bug ID: 103506 Summary: [10/11/12 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20190818 and 20190825 : $ cat z1.f90 module m stop end program p call m end $ cat z2.f90 module m continue end program p call m end $ cat z3.f90 module m do end program p call m end $ gfortran-12-20211128 -c z1.f90 z1.f90:2:4: 2 | stop |1 Error: Unexpected STOP statement in MODULE at (1) z1.f90:5:6: 1 | module m |2 .. 5 | call m | 1 Error: Global name 'm' at (1) is already being used as a MODULE at (2) f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:4039 0x87bf15 gfc_free_namespace(gfc_namespace*&) ../../gcc/fortran/symbol.c:4039 0x87c459 gfc_symbol_done_2() ../../gcc/fortran/symbol.c:4105 0x8140f8 gfc_done_2() ../../gcc/fortran/misc.c:382 0x83152a clean_up_modules ../../gcc/fortran/parse.c:6596 0x8314ec clean_up_modules ../../gcc/fortran/parse.c:6586 0x83d9d1 translate_all_program_units ../../gcc/fortran/parse.c:6661 0x83d9d1 gfc_parse_file() ../../gcc/fortran/parse.c:6925 0x88b37f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/103505] New: ICE in compare_bound_mpz_t, at fortran/resolve.c:4587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 Bug ID: 103505 Summary: ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r8 : $ cat z1.f90 program p integer, parameter :: a((2.)) = [4, 8] integer(a(1:1)) :: b end $ cat z2.f90 program p integer, parameter :: a((2.)) = [4, 8] print *, [integer(a(1:1)) :: 2] end $ cat z3.f90 program p integer, parameter :: a((2.)) = [4, 8] integer :: b(a(1:1)) end $ gfortran-12-20211128 -c z1.f90 f951: internal compiler error: compare_bound_int(): Bad expression 0x7977b9 gfc_report_diagnostic ../../gcc/fortran/error.c:874 0x799327 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1494 0x807111 compare_bound_mpz_t ../../gcc/fortran/resolve.c:4587 0x80765c check_dimension ../../gcc/fortran/resolve.c:4770 0x81a51d compare_spec_to_ref ../../gcc/fortran/resolve.c:4835 0x81a51d resolve_array_ref ../../gcc/fortran/resolve.c:5126 0x81a51d gfc_resolve_ref(gfc_expr*) ../../gcc/fortran/resolve.c:5340 0x80a7a7 resolve_variable ../../gcc/fortran/resolve.c:5842 0x80a7a7 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7168 0x79d694 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3130 0x7a0560 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3178 0x781265 gfc_match_kind_spec(gfc_typespec*, bool) ../../gcc/fortran/decl.c:3241 0x787ae9 gfc_match_decl_type_spec(gfc_typespec*, int) ../../gcc/fortran/decl.c:4672 0x78947c gfc_match_data_decl() ../../gcc/fortran/decl.c:6226 0x7f49c3 match_word ../../gcc/fortran/parse.c:67 0x7f49c3 decode_statement ../../gcc/fortran/parse.c:378 0x7f640a next_free ../../gcc/fortran/parse.c:1397 0x7f640a next_statement ../../gcc/fortran/parse.c:1629 0x7f7b2b parse_spec ../../gcc/fortran/parse.c:4168 0x7fae8c parse_progunit ../../gcc/fortran/parse.c:6179
[Bug fortran/103504] New: ICE in get_sym_storage_size, at fortran/interface.c:2800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103504 Bug ID: 103504 Summary: ICE in get_sym_storage_size, at fortran/interface.c:2800 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 subroutine s(x) real :: x(abs(1.)) end program p real :: y(1) call s(y) end $ cat z2.f90 program p real :: y(1) call s(y) contains subroutine s(x) real :: x(abs(1.)) end end $ gfortran-12-20211128 -c z1.f90 z1.f90:2:13: 2 |real :: x(abs(1.)) | 1 Error: Expression at (1) must be of INTEGER type, found REAL z1.f90:2:13: 2 |real :: x(abs(1.)) | 1 Error: Expression at (1) must be of INTEGER type, found REAL f951: internal compiler error: Segmentation fault 0xf0942f crash_signal ../../gcc/toplev.c:322 0x7e94f9 get_sym_storage_size ../../gcc/fortran/interface.c:2800 0x7e94f9 gfc_compare_actual_formal(gfc_actual_arglist**, gfc_formal_arglist*, int, int, bool, locus*) ../../gcc/fortran/interface.c:3292 0x94dff6 check_externals_procedure ../../gcc/fortran/frontend-passes.c:5725 0x952ce9 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.c:5333 0x95454b gfc_check_externals0 ../../gcc/fortran/frontend-passes.c:5844 0x9553d4 gfc_check_externals(gfc_namespace*) ../../gcc/fortran/frontend-passes.c:5866 0x83d3c2 gfc_parse_file() ../../gcc/fortran/parse.c:6856 0x88b37f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 103483, which changed state. Bug 103483 Summary: context-sensitive ranges change triggers stringop-overread https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 Martin Sebor changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Martin Sebor --- I don't think this can be "fixed." Most middle end warnings work a single statement at a time and depend on optimization like constant propagation and dead code elimination to do their job. If one optimization exposes an invalid statement that would otherwise be eliminated by another optimization that doesn't take place, the warnings trigger. That's all by design and there's no way change that. In the test case in comment #0 where the precondition is that d be less than a, making it explicit (e.g., either as Andrew suggests in comment #1 or by adding an equivalen assert statement) seems like the best and only solution.
