[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-09-15 Ever confirmed|0 |1 Keywords||needs-reduction, wrong-code Status|UNCONFIRMED |WAITING --- Comment #4 from Richard Biener --- OK, so this is clang/llvm ICEing when clang/llvm is built with GCC and LTO. Obviously needs a more reduced testcase.
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Priority|P3 |P4
[Bug fortran/106946] [10/11/12/13 Regression] ICE in resolve_component, at fortran/resolve.cc:14726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106946 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Priority|P3 |P4
[Bug c/106947] [12/13 Regression] -Waddress + bool + pragma generates meaningless diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106947 Richard Biener changed: What|Removed |Added Keywords||easyhack Priority|P3 |P2
[Bug target/106550] [rs6000] sub-optimal 64bit constant generation for P10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106550 Jiu Fu Guo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jiu Fu Guo --- Committed
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #2 from Richard Biener --- The rev. in question shows changes in what PRE does. Before the change disabling PRE also leads to the diagnostic so there's a missed optimization there. I see less fully redundant values discovered. I'm trying to reduce a testcase.
[Bug libgcc/106949] New: Memory leak using VLA with -fsplit-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949 Bug ID: 106949 Summary: Memory leak using VLA with -fsplit-stack Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: iam at datacompboy dot ru Target Milestone: --- Created attachment 53575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53575&action=edit minimal repro case Having a function with couple of VLA arrays enough to cause a memory leak. If you run the function in a loop, memory leak only grows. ``` $ gcc -fsplit-stack -g b.c && valgrind ./a.out ==6861== HEAP SUMMARY: ==6861== in use at exit: 20,040 bytes in 2 blocks ==6861== total heap usage: 2 allocs, 0 frees, 20,040 bytes allocated ==6861== ==6861== LEAK SUMMARY: ==6861==definitely lost: 24 bytes in 1 blocks ==6861==indirectly lost: 20,016 bytes in 1 blocks ``` With a loop running function 10k times: ``` $ gcc -fsplit-stack -g c.c && valgrind ./a.out ==6931== HEAP SUMMARY: ==6931== in use at exit: 569,801,800 bytes in 32,162 blocks ==6931== total heap usage: 32,162 allocs, 0 frees, 569,801,800 bytes allocated ==6931== ==6931== LEAK SUMMARY: ==6931==definitely lost: 385,944 bytes in 16,081 blocks ==6931==indirectly lost: 569,121,904 bytes in 16,072 blocks ==6931== possibly lost: 293,952 bytes in 9 blocks ```
[Bug libgcc/106949] Memory leak using VLA with -fsplit-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949 --- Comment #1 from Anton Fedorov --- Dunno, is this related to this point? https://github.com/gcc-mirror/gcc/blob/master/libgcc/generic-morestack.c#L796 /* If we are still on the initial stack, then we have a space leak. FIXME. */
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #3 from Richard Biener --- Created attachment 53576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53576&action=edit testcase for missed PRE here's a reduction that works around r12-3918-g5b8b1522e04adc but not on the tip of the GCC 12 branch or trunk. I'm going to reduce another for current trunk.
[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #7 from Alexander Monakov ---
Lawrence, thank you for the nice work reducing the testcase. For RawTherapee
the recommended course of action would be to compile everything with
-ffp-contract=off, then manually reintroduce use of fma in
performance-sensitive places by testing the FP_FAST_FMA macro to know if
hardware fma is available. This way you'll know that all systems without fma
get the same results, and all systems with fma also get the same results (but
different from the former).
For example, my function 'f1' could be adapted like this:
void f1(void)
{
double x1 = 0, x2 = 0, x3 = 0;
for (int i = 0; i < 99; ) {
double t;
#ifdef FP_FAST_FMA
t = fma(x1, b1, fma(x2, b2, fma(x3, b3, B * one)));
#else
t = B * one + x1 * b1 + x2 * b2 + x3 * b3;
#endif
printf("%d %g\t%a\n", i++, t, t);
x3 = x2, x2 = x1, x1 = t;
}
}
[Bug target/106910] roundss not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910 --- Comment #4 from Hongtao.liu --- > The vectorizer would go the direct internal fn way for those, querying the > floor optab but the x86 backend only has scalar modes supported for the > rounding optabs. For CFN_BUILT_IN_ICEIL, the modifier is narrow, and currently vectorizable_call require op_in and op_out to be simple_integer_narrowing, which means it fails to go the direct internal fn way. -cut from vectorizable_call--- tree_code convert_code = ERROR_MARK; if (cfn != CFN_LAST && (modifier == NONE || (modifier == NARROW && simple_integer_narrowing (vectype_out, vectype_in, &convert_code ifn = vectorizable_internal_function (cfn, callee, vectype_out, vectype_in); ---cut end-- Similar for CFN_BUILT_IN_LCEIL under 32-bit target. For 64-bit target CFN_BUILT_IN_LCEIL, CFN_BUILT_IN_LLCEIL will go the direct internal fn way, add lceilmn2 expanders works. Not sure whether vectorizable_call should be extended or just leave CFN_BUILT_IN_ICEIL/IFLOOR/IRINT/IROUND part in ix86_builtin_vectorized_function.
[Bug c++/106567] [13 Regression] An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jason Merrill --- Fixed.
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #4 from Richard Biener ---
Created attachment 53577
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53577&action=edit
testcase for missed PRE on trunk
Here's one.
So the issue is that PRE EXP_GEN now contains
exp_gen[10] := {
{component_ref,mem_ref<0B>,addr_expr<&external>}@.MEM_31 (0009)
}
for the block
[local count: 97603128]:
# .MEM_31 = VDEF <.MEM_55>
internal ={v} {CLOBBER};
# VUSE <.MEM_32>
_10 = MEM[(struct optional_base *)&external].m_initialized;
if (_10 != 0)
instead of the one with last_vuse .MEM_45. That in turn causes
prune_clobbered_mems to prune the expression from ANTIC_OUT of BB 9 which
has a 9->10 edge removing the incentive to perform FRE on this value inside
the loop. prune_clobbered_mems does this because
if (ref->vuse)
{
gimple *def_stmt = SSA_NAME_DEF_STMT (ref->vuse);
if (!gimple_nop_p (def_stmt)
&& ((gimple_bb (def_stmt) != block
&& !dominated_by_p (CDI_DOMINATORS,
block, gimple_bb (def_stmt)))
|| (gimple_bb (def_stmt) == block
&& value_dies_in_block_x (expr, block
to_remove = i;
where block == BB9 so the dominance test fails. The dominance test should
be redundant (unless we have translated something over a backedge!?) but
it really shows the issue that we fail to record the memory expression
with the correct VUSE into EXP_GEN and fail to adjust the VUSE when
translating from ANTIC_OUT to ANTIC_IN as well. When we'd do all this
"correctly", then we'd get a) a ton more hashtable entries with questionable
value, b) the dominance test will never fail.
By that reasoning a cheaper fix should be to instead perform the
value_dies_in_block_x when a dominance check cannot elide it.
There's a possible latent issue with virtual operands PHI translation
over backedges then though. The safest thing would be to eventually
force a set of the virtual operand when any virtual PHI is on the
edge we are translating over - we are actually doing this but the
no-PHI-nodes optimization in phi_translate_set defeats the intent of
adjusting to BB_LIVE_VOP_ON_EXIT that translate_vuse_through_block
performs and its simple check of BB equality means we don't fixup later
either.
Fixing that spot in the simplistic way as well (rather than consistently
handling the virtual operand everywhere) fixes the observed bogus
diagnostic.
[Bug target/106910] roundss not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910 --- Comment #5 from rguenther at suse dot de --- On Thu, 15 Sep 2022, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910 > > --- Comment #4 from Hongtao.liu --- > > > The vectorizer would go the direct internal fn way for those, querying the > > floor optab but the x86 backend only has scalar modes supported for the > > rounding optabs. > For CFN_BUILT_IN_ICEIL, the modifier is narrow, and currently > vectorizable_call > require op_in and op_out to be simple_integer_narrowing, which means it fails > to go the direct internal fn way. > > -cut from vectorizable_call--- > tree_code convert_code = ERROR_MARK; > if (cfn != CFN_LAST > && (modifier == NONE > || (modifier == NARROW > && simple_integer_narrowing (vectype_out, vectype_in, >&convert_code > ifn = vectorizable_internal_function (cfn, callee, vectype_out, > vectype_in); > ---cut end-- > > Similar for CFN_BUILT_IN_LCEIL under 32-bit target. > For 64-bit target CFN_BUILT_IN_LCEIL, CFN_BUILT_IN_LLCEIL will go the direct > internal fn way, add lceilmn2 expanders works. > > Not sure whether vectorizable_call should be extended or just leave > CFN_BUILT_IN_ICEIL/IFLOOR/IRINT/IROUND part in > ix86_builtin_vectorized_function. I think this is a known issue (we may even have a bugreport) so I'd leave handling of those cases in ix86_builtin_vectorized_function.
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #5 from Richard Biener --- Created attachment 53578 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53578&action=edit CFG of the second testcase With -m32 one can see the full redundancy discovery is a bit fragile since it requires an out-of-loop use to make the cross loop redundancy anticipated. See the CFG graph for illustration. It should be possible to create a smaller testcase from this, when the use of external.m_initialized is removed then the PRE does no longer work. That somehow happens with -m32 but not -m64 ...
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #6 from Richard Biener --- Anyhow - I'm testing a (half-way) fix for the issue in PRE, the testcase proved quite useful. Thanks a lot for opening this bugreport!
[Bug tree-optimization/106476] ICE generating FOLD_EXTRACT_LAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106476 --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > I think EXTRACT_LAST_REDUCTION cannot simply do > >/* Instead of doing ~x ? y : z do x ? z : y. */ >vec_compare = new_temp; >std::swap (vec_then_clause, vec_else_clause); > > So either the fix could be to not support bitop2 == BIT_NOT_EXPR for > EXTRACT_LAST_REDUCTION or we have to perform the BIT_NOT_EXPR as > vector operation. > > Richard? Agreed. This case seems to be specific to EQ_EXPR on booleans, and I'm not sure why we can't just emit an EQ_EXPR for that case. Anything else would lead to redundant ops for EXTRACT_LAST_REDUCTION. There again, having (predicate, predicate → predicate) comparisons for EQ_EXPR might be a weird special case, and might be similar to having things like NAND and NOR (which we deliberately don't have). So maybe emitting the separate NOT_EXPR is better after all.
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #7 from Jan Žižka --- > Thanks a lot for opening this bugreport! You are welcome! :-) Unfortunately I'm not familiar with gcc internals that much in order to comment on the analysis :-(. But once there will be patch for this issue I can quickly try that on our production code.
[Bug tree-optimization/106922] [12/13 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5edf02ed2b6de024f83a023d046a6a18f645bc83 commit r13-2683-g5edf02ed2b6de024f83a023d046a6a18f645bc83 Author: Richard Biener Date: Thu Sep 15 13:33:23 2022 +0200 tree-optimization/106922 - PRE and virtual operand translation PRE implicitely keeps virtual operands at the blocks incoming version but the explicit updating point during PHI translation fails to trigger when there are no PHIs at all in a block. Later lazy updating then fails because of a too lose block check. A similar issues plagues reference invalidation when checking the ANTIC_OUT to ANTIC_IN translation. The following fixes both and makes the lazy updating work. The diagnostic testcase unfortunately requires boost so the testcase is the one I reduced for a missed optimization in PRE. The testcase fails with -m32 on x86_64 because we optimize too much before PRE which causes PRE to not trigger so we fail to eliminate a full redundancy. I'm going to open a separate bug for this. Hopefully the !lp64 selector is good enough. PR tree-optimization/106922 * tree-ssa-pre.cc (translate_vuse_through_block): Only keep the VUSE if its def dominates PHIBLOCK. (prune_clobbered_mems): Rewrite logic so we check whether a value dies in a block when the VUSE def doesn't dominate it. * g++.dg/tree-ssa/pr106922.C: New testcase.
[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] Bogus|[12 Regression] Bogus |uninitialized warning on|uninitialized warning on |boost::optional<>>, missed|r>>, missed |FRE |FRE Known to work||13.0 --- Comment #9 from Richard Biener --- I verified the fix cherry-picks to GCC 12 and fixes the testcase there as well (on x86_64-linux, that is).
[Bug tree-optimization/106950] New: Missed PRE full redundancy without post-loop use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106950
Bug ID: 106950
Summary: Missed PRE full redundancy without post-loop use
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
when we have the situation of PR106922, aka g++.dg/tree-ssa/pr106922.C which is
XFAILed on !lp64 because of this there's
mem = 0;
do
{
if (mem)
mem = 0;
if (mem) // as 'char' instead of 'bool', maybe relevant
bar ();
if (i++ != n)
break;
}
while (1);
.. = mem;
with the use of 'mem' after the loop we get that antic-in in the loop
exit condition block and eventually figure the full redundancy in
the conditional redundant set to zero during PRE insertion. When that
'mem' after the loop is _not_ there this isn't triggered (possibly
because of the 'char' vs. 'bool' here, but then one can eventually
elide the whole if (mem) bar () code).
[Bug c++/106951] New: Segmentation fault during compilation while using modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106951 Bug ID: 106951 Summary: Segmentation fault during compilation while using modules Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: huscar at gmail dot com Target Milestone: --- Created attachment 53579 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53579&action=edit Zipper preprocessor source Got a segmentation fault during compilation when porting a project over to modules. encountered on 12.2.0 (from docker gcc:12.2.0) and 11.2.0 (from apt) command used: g++ -c src/creatures.cpp -Ilibs/game-engine/include -std=c++20 -Wall -Wextra -Werror -fmodules-ts -o src/creatures.o -freport-bug compiler output: In module imported at libs/game-engine/src/engine.cpp:17:1, of module GameEngine.Main, imported at src/creatures.cpp:10: GameEngine.Components.Transform: note: unable to represent further imported source locations In module imported at libs/game-engine/src/engine.cpp:21:1: Segmentation fault 0x1b9fe76 internal_error(char const*, ...) ???:0 0x1bab157 pp_format(pretty_printer*, text_info*) ???:0 0x1bac520 pp_verbatim(pretty_printer*, char const*, ...) ???:0 0x1b9eca1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ???:0 0x1b9f782 warning_at(unsigned int, int, char const*, ...) ???:0 0x9a6c07 do_warn_unused_parameter(tree_node*) ???:0 0x7cd12f finish_function(bool) ???:0 0x8c11c9 instantiate_decl(tree_node*, bool, bool) ???:0 0x8d5cab instantiate_pending_templates(int) ???:0 0x7db2df c_parse_final_cleanups() ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). I've attached the preprocessor source attached. Segfault goes away after removing the line: import GameEngine.Main; The other import declaration in the same source file do not cause segmentation faults, nor does that same import (GameEngine.Main) from a different source file.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #17 from Peter Bergner --- (In reply to ibuclaw from comment #15) > (In reply to Peter Bergner from comment #14) > > Similar error on a long double == IEEE128 system: > > > > /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math.d:281:5: > > error: static assert "Only 64-bit, 80-bit, and 128-bit reals are supported > > for LittleEndian CPUs" > > 281 | static assert(real.mant_dig == 53 || real.mant_dig == 64 > > | ^ > Looks like you configured for IBM128 to me. Bah, you are correct. I forgot I needed to add an explicit configure option to get the IEEE128 default. I'll kick it off again! Thanks!
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #18 from Kalev Lember --- If it helps in any way, I have a copr at https://copr.fedorainfracloud.org/coprs/kalev/gdc_bootstrap/ that has GCC 12 bootstrapped on ppc64le for F36 (but built with LIBDRUNTIME_ONLY=yes").
[Bug target/106491] ICE when compiling ArmSVE intrinsics in PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106491 rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Last reconfirmed||2022-09-15 CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #6 from rsandifo at gcc dot gnu.org --- Thanks for the testcase. It looks like some of the SVE garbage-collection markers are being silently ignored. Testing a patch...
[Bug c/106947] [12/13 Regression] -Waddress + bool + pragma generates meaningless diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106947 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/106952] New: Missed optimization: x < y ? x : y not lowered to minss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
Bug ID: 106952
Summary: Missed optimization: x < y ? x : y not lowered to
minss
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
Created attachment 53580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53580&action=edit
Assembly from gcc -O3 -S bug.c
The following is an implementation of a ray/axis-aligned box intersection test:
struct ray {
float origin[3];
float dir_inv[3];
};
struct box {
float min[3];
float max[3];
};
static inline float min(float x, float y) {
return x < y ? x : y;
}
static inline float max(float x, float y) {
return x < y ? x : y;
}
_Bool intersection(const struct ray *ray, const struct box *box) {
float tmin = 0.0, tmax = 1.0 / 0.0;
for (int i = 0; i < 3; ++i) {
float t1 = (box->min[i] - ray->origin[i]) * ray->dir_inv[i];
float t2 = (box->max[i] - ray->origin[i]) * ray->dir_inv[i];
tmin = min(max(t1, tmin), max(t2, tmin));
tmax = max(min(t1, tmax), min(t2, tmax));
}
return tmin < tmax;
}
However, gcc -O3 doesn't use minss/maxss for every min()/max(). Instead, some
of them are lowered to conditional jumps which regresses performance
significantly since the branches are unpredictable.
Simpler variants like
tmin = max(tmin, min(t1, t2));
tmax = min(tmax, max(t1, t2));
get the desired codegen, but that behaves differently if t1 or t2 is NaN.
"Bisecting" with godbolt.org, it seems this is an old regression: 4.8.5 was
good, but 4.9.0 was bad.
[Bug c++/106937] [10/11/12/13 Regression] ICE tree check: expected identifier_node, have tree_list in pp_tree_identifier, at tree-pretty-print.cc:4606 since r10-1214-g1bf32c1141e23074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106937 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Marek Polacek --- Mine then.
[Bug target/106952] Missed optimization: x < y ? x : y not lowered to minss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- Note, your 'max' function is the same as 'min' (the issue remains with that corrected).
[Bug target/106952] Missed optimization: x < y ? x : y not lowered to minss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952 --- Comment #2 from Tavian Barnes --- (In reply to Alexander Monakov from comment #1) > Note, your 'max' function is the same as 'min' (the issue remains with that > corrected). Whoops, thanks. Also I just noticed that GCC 12.2 does better (but not perfect) with #define min(x, y) ((x) < (y) ? (x) : (y)) #define max(x, y) ((x) > (y) ? (x) : (y)) instead of the inline functions. Doesn't seem to help GCC trunk though.
[Bug c++/92505] Using mutable in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/106926] string_view construction from literal string containing null/zero should warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106926
--- Comment #2 from John Zwinck ---
Jonathan, yes it was a real problem, I wrote such buggy code myself. I was
more complacent with string_view than I might have been with std::string
because everyone knows string_view doesn't have to be null terminated (bad
excuse, but it's mine).
I agree the same problem could happen with std::string. As for your idea to
add an attribute, I assume you mean something like this:
string_view(const char* s __attribute__((does_strlen)));
I think this would work but it seems like the attribute would have to be added
in many places. Instead, the compiler could statically determine that the
length of the string is lost in code like this:
string_view foo("bad\0string");
And maybe even here:
const char* bar = "another\0one";
Though that may be a step too far because someone could hard-code the length 12
elsewhere, and there probably is code in the wild doing that.
In general the diagnostic could apply wherever the compiler knows the contents
will be copied. Since that's not always possible to know, maybe it could
assume copying will happen when the literal is passed to an out-of-line
function.
I recognize this might be too harsh for -Wall; I'd still be quite happy to see
the warning with -Wextra. The attribute idea is also fine, if you think it's
feasible to apply it in enough places and not too ugly.
Thank you.
[Bug fortran/106948] pure subroutine with pure procedure as dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-09-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Likely a problem due to use of submodules. A simplified, but otherwise equivalent version, such as below, works: module a implicit none interface new module procedure :: b end interface new contains subroutine b(x, f) integer, intent(inout) :: x interface pure function f(x) result(r) real, intent(in) :: x real :: r end function f end interface x = int(f(real(x)) * 0.1) end subroutine b end module a
[Bug fortran/106911] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-15 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. Potential fix for the ICE: diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc index bc178d54891..c7202ec0b9a 100644 --- a/gcc/fortran/simplify.cc +++ b/gcc/fortran/simplify.cc @@ -3955,6 +3955,9 @@ gfc_simplify_ishftc (gfc_expr *e, gfc_expr *s, gfc_expr *sz) return NULL; gfc_extract_int (sz, &ssize); + + if (ssize > isize || ssize <= 0) + return NULL; } else ssize = isize; However, this would change the issue to an accepts-invalid.
[Bug fortran/104314] ICE in deferred_op_assign, at fortran/resolve.cc:11794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7bd4deb2a7c1394550610ab27507d1ed2af817c2 commit r13-2690-g7bd4deb2a7c1394550610ab27507d1ed2af817c2 Author: Harald Anlauf Date: Thu Sep 15 22:06:53 2022 +0200 Fortran: error recovery for bad deferred character length assignment [PR104314] gcc/fortran/ChangeLog: PR fortran/104314 * resolve.cc (deferred_op_assign): Do not try to generate temporary for deferred character length assignment if types do not agree. gcc/testsuite/ChangeLog: PR fortran/104314 * gfortran.dg/pr104314.f90: New test. Co-authored-by: Steven G. Kargl
[Bug c++/106926] string_view construction from literal string containing null/zero should warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106926
--- Comment #3 from Jonathan Wakely ---
(In reply to John Zwinck from comment #2)
> I agree the same problem could happen with std::string. As for your idea to
> add an attribute, I assume you mean something like this:
>
> string_view(const char* s __attribute__((does_strlen)));
Yes.
> I think this would work but it seems like the attribute would have to be
> added in many places.
Why? I don't think there are that many places.
> Instead, the compiler could statically determine that
> the length of the string is lost in code like this:
>
> string_view foo("bad\0string");
How would it determine that? By inlining the eventual call to strlen (several
function calls down from the location of the literal)?
> And maybe even here:
>
> const char* bar = "another\0one";
>
> Though that may be a step too far because someone could hard-code the length
> 12 elsewhere, and there probably is code in the wild doing that.
I agree that's not a good idea.
> In general the diagnostic could apply wherever the compiler knows the
> contents will be copied.
But that doesn't apply to string_view, there's no copying. And such a warning
would require optimization and inlining to be effective. How would the compiler
know that? That's why I suggested an attribute, because the call site can give
a warning without having to know what happens inside the function, and
everything that it calls.
Relying on arbitrarily deep inlining doesn't sound like it will be very
effective, nor does expecting the compiler to just "know" which functions this
applies to.
> Since that's not always possible to know, maybe it
> could assume copying will happen when the literal is passed to an
> out-of-line function.
That seems like a bad idea too. Every function is "an out of line function" at
-O0.
[Bug fortran/104314] ICE in deferred_op_assign, at fortran/resolve.cc:11794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline. Closing. Thanks for the report!
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Obvious fix for NULL pointer dereference:
>
> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> index bc178d54891..d5c4fe8443d 100644
> --- a/gcc/fortran/simplify.cc
> +++ b/gcc/fortran/simplify.cc
> @@ -6431,7 +6432,7 @@ gfc_simplify_pack (gfc_expr *array, gfc_expr *mask,
> gfc_expr *vector)
>/* Copy only those elements of ARRAY to RESULT whose
>MASK equals .TRUE.. */
>mask_ctor = gfc_constructor_first (mask->value.constructor);
> - while (mask_ctor)
> + while (mask_ctor && array_ctor)
> {
> if (mask_ctor->expr->value.logical)
> {
This regtests fine. Taking.
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2b75d5f533b9d6b39f4055949aff64ed0d22dd24 commit r13-2691-g2b75d5f533b9d6b39f4055949aff64ed0d22dd24 Author: Harald Anlauf Date: Thu Sep 15 22:39:24 2022 +0200 Fortran: catch NULL pointer dereferences while simplifying PACK [PR106857] gcc/fortran/ChangeLog: PR fortran/106857 * simplify.cc (gfc_simplify_pack): Check for NULL pointer dereferences while walking through constructors (error recovery). gcc/testsuite/ChangeLog: PR fortran/106857 * gfortran.dg/pr106857.f90: New test.
[Bug c++/106761] [13 regression] g++.dg/modules/xtreme-header-*_b.C test cases fails after r13-2158-g02f6b405f0e9dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106761 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922 --- Comment #10 from Jan Žižka --- Created attachment 53581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53581&action=edit Second reproducer failing with 5edf02ed2b6de024f83a023d046a6a18f645bc83 I have cherry-picked the fix on top of gcc 12 and I confirm that my original reproducer passes. But our production code still fails. I have created new reproducer, the change is that the optional is inside a struct and seems there need to be two elements. With first reproducer I have eliminated this additional struct as that was also failing. Please try with: g++ -Werror -std=c++20 -O2 -Wall -o reproduce1.o -c reproduce1.cpp
