[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Hi Patrick, thank you for that patch. I guess that it also fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070. Will this patch be backported to gcc-10? Great work!
[Bug c++/61259] [Regression 8/9/10/11] Spurious "ISO C++ forbids zero-size array" warning with -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259
Volker Reichelt changed:
What|Removed |Added
Known to fail||10.3.0, 4.4.0
CC||reichelt at gcc dot gnu.org
Summary|Spurious "ISO C++ forbids |[Regression 8/9/10/11]
|zero-size array" warning|Spurious "ISO C++ forbids
|with -pedantic |zero-size array" warning
||with -pedantic
Last reconfirmed|2014-05-20 00:00:00 |2021-4-20
Keywords||rejects-valid
--- Comment #4 from Volker Reichelt ---
If you compile the code with "-pedantic-errors" the code is wrongly rejected,
so marking it as rejects-valid.
Self-contained example:
==
int foo(int x[2])
{
int i(int(x[0])*1);
return i;
}
==
[Bug target/99960] MVE: Wrong code storing V2DI vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99960 Alex Coplan changed: What|Removed |Added Last reconfirmed||2021-04-20 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #2 from Alex Coplan --- Taking a look at this.
[Bug tree-optimization/100113] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100113 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-20 Ever confirmed|0 |1 Version|unknown |11.0 --- Comment #1 from Richard Biener --- dom3 manages to optimize it with -O1 but it gets different input with -O3.
[Bug c/100150] New: ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 Bug ID: 100150 Summary: ice in bp_unpack_string Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 50633 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50633&action=edit x86_64 object module For recent gcc, I get $ /home/dcb/gcc/results/bin/gcc -o /dev/null src/bin/tolua.o lib/libtolua++-5.3.so lto1: internal compiler error: Segmentation fault 0xbdfb79 crash_signal(int) ../../trunk.git/gcc/toplev.c:327 0x70d3a0 bp_unpack_string(data_in*, bitpack_d*) ../../trunk.git/gcc/data-streamer-in.c:112 0xae67df cl_optimization_stream_in(data_in*, bitpack_d*, cl_optimization*) /home/dcb/gcc/working/gcc/options-save.c:12731 0xe44dda streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) ../../trunk.git/gcc/tree-streamer-in.c:552 The fault first seems to occur sometime between git hash 4a1493f0603262a7 and 329d2f0df7d6d22c.
[Bug ipa/100112] missed optimization for dead code elimination at -O3, -Os (vs. -O1, -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100112 Richard Biener changed: What|Removed |Added Component|tree-optimization |ipa Keywords||missed-optimization Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Version|unknown |11.0 Last reconfirmed||2021-04-20 --- Comment #1 from Richard Biener --- It's very late eliminated at -O1 (DCE7) while with -O3 we still have [local count: 1073741824]: _2 = e; _3 = _2 + 1; e = _3; c.1_4 = c; if (c.1_4 == 0B) goto ; [48.88%] else goto ; [51.12%] [local count: 524845000]: foo (); there. In the end it's some IPA issue, failing to make 'c' readonly at -O3 vs. -O1.
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #1 from David Binderman --- Created attachment 50634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50634&action=edit x86_64 object module
[Bug ipa/100145] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100145
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |ipa
Keywords||missed-optimization
Ever confirmed|0 |1
Last reconfirmed||2021-04-20
CC||hubicka at gcc dot gnu.org,
||marxin at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Version|unknown |11.0
--- Comment #1 from Richard Biener ---
At -O2 we optimize things in thread3, at -O3 we have a PHI less there and thus
do no backwards threading which is because 'c' wasn't PREd for some reason
(-fno-tree-vectorize or -fno-tree-partial-pre do not help)
int main ()
{
- int D.2001;
- int b.1_7;
- int prephitmp_16;
+ int _1;
+ int b.1_6;
[local count: 1073741824]:
c = 0;
- b.1_7 = b;
- if (b.1_7 != 0)
+ b.1_6 = b;
+ if (b.1_6 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
- [local count: 3318838410]:
+ [local count: 365072224]:
c = 1;
[local count: 1073741824]:
- # prephitmp_16 = PHI <0(2), 1(3)>
d = 1;
- if (prephitmp_16 > 100)
+ _1 = c;
+ if (_1 > 100)
goto ; [33.00%]
else
goto ; [67.00%]
the issue seems to be the guessed profile (but BB counts are the same!):
+Skipping partial redundancy for expression {mem_ref<0B>,addr_expr<&c>}@.MEM_7
(
0001), no redundancy on to be optimized for speed edge
so that leaves the "global" hot count we IPA compute somehow? Honza?
[Bug middle-end/100144] [OpenMP] Data race with "omp parallel master taskloop ... shared(scalar)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144 --- Comment #2 from Tobias Burnus --- Sollve_vv's testcase has been fixed: Issue: https://github.com/SOLLVE/sollve_vv/issues/324 Patch test_parallel_master_taskloop.c: https://github.com/SOLLVE/sollve_vv/pull/325 Patch test_parallel_master_taskloop_device.c: https://github.com/SOLLVE/sollve_vv/pull/326
[Bug gcov-profile/100145] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100145
Richard Biener changed:
What|Removed |Added
Component|ipa |gcov-profile
--- Comment #2 from Richard Biener ---
So we get optimize_edge_for_size_p () returning OPTIMIZE_SIZE_BALANCED and
thus optimize_edge_for_speed_p which is
340 bool
341 optimize_edge_for_speed_p (edge e)
342 {
343 return !optimize_edge_for_size_p (e);
344 }
return false. And that's likely because this is 'main'. At -O2 BB counts
are broken:
[local count: 1073741824]:
c = 0;
b.1_7 = b;
if (b.1_7 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 708669600]:
goto ; [100.00%]
[local count: 3318838410]:
c = 1;
[local count: 1073741824]:
d = 1;
here 3->4 artificially appears 'hot'. The bogus counts appear during IPA
inlining of g() into main.
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #2 from David Binderman --- Starting git bisect ...
[Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #19 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8642b73a0f0df1f8e1e2d2102d67a76f8ed0a255
commit r10-9720-g8642b73a0f0df1f8e1e2d2102d67a76f8ed0a255
Author: Jakub Jelinek
Date: Sat Apr 3 10:05:32 2021 +0200
rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee
[PR97653]
__floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so}
entrypoints for backwards compatibility should mean IBM double double
handling (i.e. IFmode), gcc emits such calls for that format and
form IEEE long double emits *kf* instead.
When gcc is configured without --with-long-double-format=ieee ,
everything is fine, but when it is not, we need to compile those
libgcc sources with -mno-gnu-attribute -mabi=ibmlongdouble.
The following snippet in libgcc/config/rs6000/t-linux was attempting
to ensure that, and for some routines it works fine (e.g. for _powitf2).
But, due to 4 different types of bugs it doesn't work for most of those
functions, which means that in --with-long-double-format=ieee
configured gcc those *tf* entrypoints instead handle the long double
arguments as if they were KFmode.
The bugs are:
1) the first few objs properly use $(objext) as suffix, but
several other contain a typo and use $(object) instead,
which is a variable that isn't set to anything, so we don't
add .o etc. extensions
2) while unsigned fix are properly called _fixuns*, unsigned float
are called _floatun* (without s), but the var was using there
the extra s and so didn't match
3) the variable didn't cover any of the TF <-> TI conversions,
only TF <-> DI conversions
4) nothing in libgcc_s.so was handled, as those object files are
called *_s.o rather than *.o and IBM128_SHARED_OBJS used wrong
syntax of the GNU make substitution reference, which should be
$(var:a=b) standing for $(patsubst a,b,$(var)) but it used
$(var:a:b) instead
2021-04-03 Jakub Jelinek
PR target/97653
* config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use
$(objext) instead of $(object). Use _floatunditf instead of
_floatunsditf. Add tf <-> ti conversion objects.
(IBM128_SHARED_OBJS): Use proper substitution reference syntax.
(cherry picked from commit cda41ce0e8414aec59e6b9fbe645d96e6e8193e2)
[Bug rtl-optimization/99863] [10 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #21 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a2f91d413eb7a3eb0ba52c7ac9618a35addd12a commit r10-9721-g7a2f91d413eb7a3eb0ba52c7ac9618a35addd12a Author: Jakub Jelinek Date: Sat Apr 3 10:07:09 2021 +0200 dse: Fix up hard reg conflict checking in replace_read [PR99863] Since PR37922 fix RTL DSE has hard register conflict checking in replace_read, so that if the replacement sequence sets (or typically just clobbers) some hard register (usually condition codes) we verify that hard register is not live. Unfortunately, it compares the hard reg set clobbered/set by the sequence (regs_set) against the currently live hard register set, but it then emits the insn sequence not at the current insn position, but before store_insn->insn. So, we should not compare against the current live hard register set, but against the hard register live set at the point of the store insn. Fortunately, we already have that remembered in store_insn->fixed_regs_live. In addition to bootstrapping/regtesting this patch on x86_64-linux and i686-linux, I've also added statistics gathering and it seems the only place where we end up rejecting the replace_read is the newly added testcase (the PR37922 is no longer effective at that) and fixed_regs_live has been always non-NULL at the if (store_insn->fixed_regs_live) spot. Rather than having there an assert, I chose to just keep regs_set as is, which means in that hypothetical case where fixed_regs_live wouldn't be computed for some store we'd still accept sequences that don't clobber/set any hard registers and just punt on those that clobber/set those. 2021-04-03 Jakub Jelinek PR rtl-optimization/99863 * dse.c (replace_read): Drop regs_live argument. Instead of regs_live, use store_insn->fixed_regs_live if non-NULL, otherwise punt if insns sequence clobbers or sets any hard registers. * gcc.target/i386/pr99863.c: New test. (cherry picked from commit 9c7473688e78dc41fd4312a983453df195dd7786)
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859 --- Comment #20 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e961da38630c892dfc0723e0726b6a0b0833e951 commit r10-9722-ge961da38630c892dfc0723e0726b6a0b0833e951 Author: Jakub Jelinek Date: Thu Apr 8 17:15:39 2021 +0200 c++: Don't cache constexpr functions which are passed pointers to heap or static vars being constructed [PR99859] When cxx_bind_parameters_in_call is called e.g. on a method on an automatic variable, we evaluate the argument and because ADDR_EXPR of an automatic decl is not TREE_CONSTANT, we set *non_constant_args and don't cache it. But when it is called on an object located on the heap (allocated using C++20 constexpr new) where we represent it as TREE_STATIC artificial var, or when it is called on a static var that is currently being constructed, such ADDR_EXPRs are TREE_CONSTANT and we happily cache such calls, but they can in those cases have side-effects in the heap or static var objects and so caching them means such side-effects will happen only once and not as many times as that method or function is called. Furthermore, as Patrick mentioned in the PR, the argument doesn't need to be just ADDR_EXPR of the heap or static var or its components, but it could be a CONSTRUCTOR that has the ADDR_EXPR embedded anywhere. And the incorrectly cached function doesn't need to modify the pointed vars or their components, but some caller could be changing them in between the call that was cached and the call that used the cached result. The following patch fixes it by setting *non_constant_args also when the argument contains somewhere such an ADDR_EXPR, either of a heap artificial var or component thereof, or of a static var currently being constructed (where for that it uses the same check as cxx_eval_store_expression, ctx->global->values.get (...); addresses of other static variables would be rejected by cxx_eval_store_expression and therefore it is ok to cache such calls). 2021-04-08 Jakub Jelinek PR c++/99859 * constexpr.c (addr_of_non_const_var): New function. (cxx_bind_parameters_in_call): Set *non_constant_args to true even if cp_walk_tree on arg with addr_of_non_const_var callback returns true. * g++.dg/cpp1y/constexpr-99859-1.C: New test. * g++.dg/cpp1y/constexpr-99859-2.C: New test. * g++.dg/cpp2a/constexpr-new18.C: New test. * g++.dg/cpp2a/constexpr-new19.C: New test. (cherry picked from commit 559d2f1e0eafd96c19dc5324db1a466286c0e7fc)
[Bug rtl-optimization/98601] [8/9/10 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e68ac8c2b46997af1464f2549ac520a192c928b1 commit r10-9723-ge68ac8c2b46997af1464f2549ac520a192c928b1 Author: Jakub Jelinek Date: Sat Apr 10 12:46:09 2021 +0200 rtlanal: Another fix for VOIDmode MEMs [PR98601] This is a sequel to the PR85022 changes, inline-asm can (unfortunately) introduce VOIDmode MEMs and in PR85022 they have been changed so that we don't pretend we know their size (as opposed to assuming they have zero size). This time we ICE in rtx_addr_can_trap_p_1 because it assumes that all memory but BLKmode has known size. The patch just treats VOIDmode MEMs like BLKmode in that regard. And, the STRICT_ALIGNMENT change is needed because VOIDmode has GET_MODE_SIZE of 0 and we don't want to check if something is a multiple of 0. 2021-04-10 Jakub Jelinek PR rtl-optimization/98601 * rtlanal.c (rtx_addr_can_trap_p_1): Allow in assert unknown size not just for BLKmode, but also for VOIDmode. For STRICT_ALIGNMENT unaligned_mems handle VOIDmode like BLKmode. * gcc.dg/torture/pr98601.c: New test. (cherry picked from commit 7a493fcd27d6a1af896c4f5ef4ab1e0afe8a839d)
[Bug lto/99849] [8/9/10 Regression] ICE in expand_expr_real_1, at expr.c:11556 since r5-5407-g30d5d8c5189064c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99849 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2e57bc7eedb084869d17fe07b538d907b8fee819 commit r10-9724-g2e57bc7eedb084869d17fe07b538d907b8fee819 Author: Jakub Jelinek Date: Sat Apr 10 12:49:01 2021 +0200 expand: Fix up LTO ICE with COMPOUND_LITERAL_EXPR [PR99849] The gimplifier optimizes away COMPOUND_LITERAL_EXPRs, but they can remain in the form of ADDR_EXPR of COMPOUND_LITERAL_EXPRs in static initializers. By the TREE_STATIC check I meant to check that the underlying decl of the compound literal is a global rather than automatic variable which obviously can't be referenced in static initializers, but unfortunately with LTO it might end up in another partition and thus be DECL_EXTERNAL instead. 2021-04-10 Jakub Jelinek PR lto/99849 * expr.c (expand_expr_addr_expr_1): Test is_global_var rather than just TREE_STATIC on COMPOUND_LITERAL_EXPR_DECLs. * gcc.dg/lto/pr99849_0.c: New test. (cherry picked from commit 22aede7a1228617661105048a91fddd8797e141b)
[Bug c/99990] [8/9/10 Regression] ICE in gimplifier on invalid va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:91e076f3a66c1c9f6aa51e9d53d07803606e3bf1 commit r10-9725-g91e076f3a66c1c9f6aa51e9d53d07803606e3bf1 Author: Jakub Jelinek Date: Sat Apr 10 17:01:54 2021 +0200 c: Avoid clobbering TREE_TYPE (error_mark_node) [PR0] The following testcase ICEs during error recovery, because finish_decl overwrites TREE_TYPE (error_mark_node), which better should stay always to be error_mark_node. 2021-04-10 Jakub Jelinek PR c/0 * c-decl.c (finish_decl): Don't overwrite TREE_TYPE of error_mark_node. * gcc.dg/pr0.c: New test. (cherry picked from commit 9f7d77bd6d65aa1cf2e195d3776052705c6e636b)
[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ac7483ede91fef7cfd548ff6e30e46eeb9d95ae commit r10-9726-g4ac7483ede91fef7cfd548ff6e30e46eeb9d95ae Author: Jakub Jelinek Date: Tue Apr 13 01:00:48 2021 +0200 combine: Don't fold away side-effects in simplify_and_const_int_1 [PR99830] Here is an alternate patch for the PR99830 bug. As discussed on IRC and in the PR, the reason why a (clobber:TI (const_int 0)) has been propagated into the debug insns is that it got optimized away during simplification from the i3 instruction pattern. And that happened because simplify_and_const_int_1 (SImode, varop, 255) with varop of (ashift:SI (subreg:SI (and:TI (clobber:TI (const_int 0 [0])) (const_int 255 [0xff])) 0) (const_int 16 [0x10])) was called and through nonzero_bits determined that (whatever << 16) & 255 is const0_rtx. It is, but if there are side-effects in varop and such clobbers are considered as such, we shouldn't optimize those away. 2021-04-13 Jakub Jelinek PR debug/99830 * combine.c (simplify_and_const_int_1): Don't optimize varop away if it has side-effects. * gcc.dg/pr99830.c: New test. (cherry picked from commit 9c1c8ad8339d551ac91a7af5614f29b9a687189a)
[Bug rtl-optimization/99905] [8/9/10 Regression] wrong code with -mno-mmx -mno-sse since r7-4540-gb229ab2a712ccd44
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99905
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c965254e5af9dc68444e0289250c393ae0cd6131
commit r10-9727-gc965254e5af9dc68444e0289250c393ae0cd6131
Author: Jakub Jelinek
Date: Tue Apr 13 01:01:45 2021 +0200
combine: Fix up expand_compound_operation [PR99905]
The following testcase is miscompiled on x86_64-linux.
expand_compound_operation is called on
(zero_extract:DI (mem/c:TI (reg/f:DI 16 argp) [3 i+0 S16 A128])
(const_int 16 [0x10])
(const_int 63 [0x3f]))
so mode is DImode, inner_mode is TImode, pos 63, len 16 and modewidth 64.
A couple of lines above the problematic spot we have:
if (modewidth >= pos + len)
{
tem = gen_lowpart (mode, XEXP (x, 0));
where the code uses gen_lowpart and then shift left/right to extract it
in mode. But the guarding condition is false - 64 >= 63 + 16
and so we enter the next condition, where the code shifts XEXP (x, 0)
right by pos and then adds AND. It does so incorrectly though.
Given the modewidth < pos + len, inner_mode must be necessarily larger
than mode and XEXP (x, 0) has the innermode, but it was calling
simplify_shift_const with mode rather than inner_mode, which meant
inconsistent arguments to simplify_shift_const and in this case made
a DImode MEM shift out of it.
The following patch fixes it, by doing the shift in inner_mode properly
and then after the shift doing the lowpart subreg and masking already
in mode.
2021-04-13 Jakub Jelinek
PR rtl-optimization/99905
* combine.c (expand_compound_operation): If pos + len > modewidth,
perform the right shift by pos in inner_mode and then convert to
mode,
instead of trying to simplify a shift of rtx with inner_mode by pos
as if it was a shift in mode.
* gcc.target/i386/pr99905.c: New test.
(cherry picked from commit ffc4155b6e45b8ab71d49a4b584f7cacb693e6b9)
[Bug c++/99833] [8/9/10 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:06d50ebc9fb2761ed2bdda5e76adb4d47a8ca983 commit r10-9728-g06d50ebc9fb2761ed2bdda5e76adb4d47a8ca983 Author: Jakub Jelinek Date: Fri Apr 16 09:32:44 2021 +0200 c++: Fix up handling of structured bindings in extract_locals_r [PR99833] The following testcase ICEs in tsubst_decomp_names because the assumptions that the structured binding artificial var is followed in DECL_CHAIN by the corresponding structured binding vars is violated. I've tracked it to extract_locals* which is done for the constexpr IF_STMT. extract_locals_r when it sees a DECL_EXPR adds that decl into a hash set so that such decls aren't returned from extract_locals*, but in the case of a structured binding that just means the artificial var and not the vars corresponding to structured binding identifiers. The following patch fixes it by pushing not just the artificial var for structured bindings but also the other vars. 2021-04-16 Jakub Jelinek PR c++/99833 * pt.c (extract_locals_r): When handling DECL_EXPR of a structured binding, add to data.internal also all corresponding structured binding decls. * g++.dg/cpp1z/pr99833.C: New test. * g++.dg/cpp2a/pr99833.C: New test. (cherry picked from commit 20eb7a1891cfd7fa85295a236cebe0322d041edd)
[Bug target/99767] [9/10 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1730b5d6793127b1a47970f44d60da8082bab514
commit r10-9729-g1730b5d6793127b1a47970f44d60da8082bab514
Author: Jakub Jelinek
Date: Fri Apr 16 11:44:04 2021 +0200
vectorizer: Remove dead scalar .COND_* calls from vectorized loops
[PR99767]
The following testcase ICEs because disabling of DCE means there are dead
stmts in the loop (though, in theory they could become dead only shortly
before if-conv through some optimization), ifcvt which goes through all
stmts in the loop if-converts them into .COND_DIV etc. internal fn calls
in the copy of the loop meant for vectorization only, the loop is
successfully vectorized but the particular .COND_* call is not because
it isn't a live statement and the scalar .COND_* remains in the IL until
expansion where it ICEs because these ifns only support vectors and not
scalars.
These ifns are similar to .MASK_{LOAD,STORE} in this behavior.
One possible fix could be to expand scalar versions of them during
expansion, basically undoing what if-conv did to create them, i.e.
expand them as the lhs = else; if (mask) { lhs = statement; } or so.
For .MASK_LOAD we have code to replace them in vect_transform_loop already
though (not needed for .MASK_STORE, as stores should be always live
and thus always vectorized), so this patch instead replaces .COND_*
similarly to .MASK_LOAD in that loop, with the small difference
that lhs = .MASK_LOAD (...); is replaced by lhs = 0; while
lhs = .COND_* (..., else_arg); is replaced by lhs = else_arg.
The statement must be dead, otherwise it would be vectorized, so I think
it is not a big deal we don't turn it back into multiple basic blocks etc.
(and it might be not possible to do that at that point).
2021-04-16 Jakub Jelinek
PR target/99767
* tree-vect-loop.c (vect_transform_loop): Don't remove just
dead scalar .MASK_LOAD calls, but also dead .COND_* calls - replace
them by their last argument.
* gcc.target/aarch64/pr99767.c: New test.
(cherry picked from commit b44ab138b7d4aaa5a9ee7956121ffc94777f6a42)
[Bug c++/100111] [10 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:31447dcaf15c37e5b9c42b2984f4c8b649fe9b74 commit r10-9730-g31447dcaf15c37e5b9c42b2984f4c8b649fe9b74 Author: Jakub Jelinek Date: Fri Apr 16 17:37:07 2021 +0200 c++: Fix empty base stores in cxx_eval_store_expression [PR100111] In r11-6895 handling of empty bases has been fixed such that non-lval stores of empty classes are not added when the type of *valp doesn't match the type of the initializer, but as this testcase shows it is done only when *valp is non-NULL. If it is NULL, we still shouldn't add empty class constructors if the type of the constructor elt *valp points to doesn't match. 2021-04-16 Jakub Jelinek PR c++/100111 * constexpr.c (cxx_eval_store_expression): Don't add CONSTRUCTORs for empty classes into *valp when types don't match even when *valp is NULL. * g++.dg/cpp0x/constexpr-100111.C: New test. (cherry picked from commit 35e8b38a91d9fb49a4759649576f15e76c129d99)
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #25 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a11f31102706e33f66b60367d6863613ab3bd051 commit r10-9731-ga11f31102706e33f66b60367d6863613ab3bd051 Author: Jakub Jelinek Date: Fri Apr 16 18:32:27 2021 +0200 intl: Add --enable-host-shared support [PR100096] As mentioned in the PR, building gcc with jit enabled and --enable-host-shared doesn't work on NetBSD/i?86, as libgccjit.so.0 has text relocations. The r0-125846-g459260ecf8b420b029601a664cdb21c185268ecb changes added --enable-host-shared support to various libraries, but didn't add it to intl/ subdirectory; on Linux it isn't really needed, because all: all-no all-no: #nothing but on other OSes intl/libintl.a is built. The following patch makes sure it is built with -fPIC when --enable-host-shared is used. 2021-04-16 Jakub Jelinek PR jit/100096 * configure.ac: Add --enable-host-shared support. * Makefile.in: Update copyright. Add @PICFLAG@ to CFLAGS. * configure: Regenerated. (cherry picked from commit 4a1493f0603262a7dc1114d9827353e9810e63dc)
[Bug sanitizer/100114] libasan built against latest glibc doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:950bac27d63c1c2ac3a6ed867692d6a13f21feb3 commit r10-9732-g950bac27d63c1c2ac3a6ed867692d6a13f21feb3 Author: Jakub Jelinek Date: Sat Apr 17 11:27:14 2021 +0200 sanitizer: Fix asan against glibc 2.34 [PR100114] As mentioned in the PR, SIGSTKSZ is no longer a compile time constant in glibc 2.34 and later, so static const uptr kAltStackSize = SIGSTKSZ * 4; needs dynamic initialization, but is used by a function called indirectly from .preinit_array and therefore before the variable is constructed. This results in using 0 size instead and all asan instrumented programs die with: ==91==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of SetAlternateSignalStack (error code: 22) Here is a cherry-pick from upstream to fix this. 2021-04-17 Jakub Jelinek PR sanitizer/100114 * sanitizer_common/sanitizer_posix_libcdep.cpp: Cherry-pick llvm-project revisions 82150606fb11d28813ae6da1101f5bda638165fe and b93629dd335ffee2fc4b9b619bf86c3f9e6b0023. (cherry picked from commit d9f462fb372fb02da032cefd6b091d7582c425ae)
[Bug rtl-optimization/99863] [10 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #22 from Jakub Jelinek --- Fixed.
[Bug lto/99849] [8/9 Regression] ICE in expand_expr_real_1, at expr.c:11556 since r5-5407-g30d5d8c5189064c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99849 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |expand_expr_real_1, at |expand_expr_real_1, at |expr.c:11556 since |expr.c:11556 since |r5-5407-g30d5d8c5189064c8 |r5-5407-g30d5d8c5189064c8 --- Comment #7 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c/99990] [8/9 Regression] ICE in gimplifier on invalid va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |gimplifier on invalid |gimplifier on invalid |va_arg |va_arg --- Comment #9 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug rtl-optimization/98601] [8/9 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] aarch64: |aarch64: ICE in |ICE in |rtx_addr_can_trap_p_1, at |rtx_addr_can_trap_p_1, at |rtlanal.c:467 |rtlanal.c:467 --- Comment #10 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug rtl-optimization/99905] [8/9 Regression] wrong code with -mno-mmx -mno-sse since r7-4540-gb229ab2a712ccd44
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99905 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] wrong |[8/9 Regression] wrong code |code with -mno-mmx -mno-sse |with -mno-mmx -mno-sse |since |since |r7-4540-gb229ab2a712ccd44 |r7-4540-gb229ab2a712ccd44 --- Comment #12 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c++/99833] [8/9 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] structured |structured binding + if |binding + if init + generic |init + generic lambda = |lambda = internal compiler |internal compiler error |error --- Comment #14 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug target/99767] [9 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |expand_direct_optab_fn, at |expand_direct_optab_fn, at |internal-fn.c:3360 |internal-fn.c:3360 --- Comment #10 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c++/100111] [10 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jakub Jelinek --- Fixed for 10.4 too.
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2021-04-20 --- Comment #3 from Martin Liška --- Can you please attach a pre-processed source file for src/bin/tolua.o and the corresponding command line that was used?
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #4 from David Binderman --- Created attachment 50635 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50635&action=edit preprocessed C source code file
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #5 from Martin Liška --- and the command line please?
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #6 from David Binderman --- The command line seems to be: gcc -o src/bin/tolua.o -c -g -O3 -funroll-all-loops -freport-bug -flto=auto -ffat-lto-objects -fexceptions -pipe -Wall -Werror=format-security -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection src/bin/tolua.c git bisect seems to indicate commit 329d2f0df7d6d22c87ab3338b94caef68139cd58, which seems to be something about GORI, which AFAIK isn't lto related.
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #7 from Martin Liška --- I cannot reproduce it without lib/libtolua++-5.3.so. How is libtolua++-5.3.so built?
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #8 from David Binderman --- (In reply to Martin Liška from comment #7) > How is libtolua++-5.3.so built? $ gcc -o lib/libtolua++-5.3.so -Wl,-soname,libtolua++-5.3.so -shared src/lib/tolua_event.os src/lib/tolua_is.os src/lib/tolua_map.os src/lib/tolua_push.os src/lib/tolua_to.os $( -Llib $) -llua -ldl -lm I am merely picking lines out of a build of fedora package tolua++ version 1.0.93 You might be better off trying to build the package yourself.
[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555 --- Comment #10 from Tom de Vries --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568295.html
[Bug fortran/84119] Type parameter inquiry for PDT returns array instead of scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84119 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 50636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50636&action=edit Fix for the PR Sorry for the wait. Your analysis is completely correct. Thanks for pointing it out. The attached will be submitted to the fortran list in a few minutes. It regression tests OK. Paul
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f1a68574b1f8d2961d3a676dbcf0cc24b6368578 commit r12-6-gf1a68574b1f8d2961d3a676dbcf0cc24b6368578 Author: Jonathan Wakely Date: Tue Apr 20 12:46:11 2021 +0100 libstdc++: Define __cpp_lib_to_chars for C++20 [PR 100146] This defines the feature test macro when uselocale is available, because the floating-point std::from_chars support currently depends on that. Co-authored-by: Jakub Jelinek libstdc++-v3/ChangeLog: PR libstdc++/100146 * include/std/charconv (__cpp_lib_to_chars): Define conditionally. * include/std/version (__cpp_lib_to_chars): Likewise.. * testsuite/20_util/from_chars/4.cc: Only check feature test macro, not _GLIBCXX_HAVE_USELOCALE. * testsuite/20_util/from_chars/5.cc: Likewise. * testsuite/20_util/from_chars/6.cc: Likewise. * testsuite/20_util/to_chars/long_double.cc: Likewise.
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:73ac2cfc69f466d082bf6fd68f10447575ae0612 commit r11-8261-g73ac2cfc69f466d082bf6fd68f10447575ae0612 Author: Jonathan Wakely Date: Tue Apr 20 12:46:11 2021 +0100 libstdc++: Define __cpp_lib_to_chars for C++20 [PR 100146] This defines the feature test macro when uselocale is available, because the floating-point std::from_chars support currently depends on that. Co-authored-by: Jakub Jelinek libstdc++-v3/ChangeLog: PR libstdc++/100146 * include/std/charconv (__cpp_lib_to_chars): Define conditionally. * include/std/version (__cpp_lib_to_chars): Likewise.. * testsuite/20_util/from_chars/4.cc: Only check feature test macro, not _GLIBCXX_HAVE_USELOCALE. * testsuite/20_util/from_chars/5.cc: Likewise. * testsuite/20_util/from_chars/6.cc: Likewise. * testsuite/20_util/to_chars/long_double.cc: Likewise. (cherry picked from commit f1a68574b1f8d2961d3a676dbcf0cc24b6368578)
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #9 from Jonathan Wakely --- Fixed for 11.1 There should be a test to verify that __cpp_lib_to_chars is actually defined, but that can be added later.
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 --- Comment #10 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you!
[Bug jit/100151] New: libgccjit tutorial hello world program leaves temporary files on MS-Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100151 Bug ID: 100151 Summary: libgccjit tutorial hello world program leaves temporary files on MS-Windows Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: eliz at gnu dot org Target Milestone: --- I compiled the tut01-hello-world program on MS-Windows using MinGW GCC 9.2.0. Running the program leaves a libjccgit-N directory (where "N" is a random suffix) under $TEMP with a single file called fake.so. Each time the program is run, another directory with the same content is deposited there.
[Bug c++/100109] [8/9/10/11/12 Regression] ICE: unexpected expression 'E' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7f5deba1c21888aacedae93e9f324827073a1d1e commit r12-7-g7f5deba1c21888aacedae93e9f324827073a1d1e Author: Jason Merrill Date: Tue Apr 20 00:50:49 2021 -0400 c++: unexpanded pack in enum in lambda [PR100109] Another construct we need to look inside. gcc/cp/ChangeLog: PR c++/100109 * pt.c (find_parameter_packs_r): Look into enum initializers. gcc/testsuite/ChangeLog: PR c++/100109 * g++.dg/cpp0x/lambda/lambda-variadic14.C: New test.
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:902b40c797a86f76791c32d537ba06dff5f1ba27 commit r12-8-g902b40c797a86f76791c32d537ba06dff5f1ba27 Author: Patrick Palka Date: Tue Apr 20 09:18:50 2021 -0400 libstdc++: Implement P2259R1 changes [PR95983] This implements the wording changes of P2259R1 "Repairing input range adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408. The wording changes are relatively straightforward, but they require some boilerplate to implement: the changes to make a type alias "conditionally present" in some iterator class are realized by defining a base class template and an appropriately constrained partial specialization thereof that contains the type alias, and having the iterator class derive from this base class. Sometimes the relevant condition depend on members from the iterator class, but because a class is incomplete when instantiating its bases, the constraints on the partial specialization can't use anything from the iterator class. This patch works around this by hoisting these members out to the enclosing scope (e.g. transform_view::_Iterator::_Base is hoisted out to transform_view::_Base so that transform_view::__iter_cat can use it). This patch also implements the proposed resolution of LWG 3291 to rename iota_view::iterator_category to iota_view::iterator_concept, which was previously problematic due to LWG 3408. libstdc++-v3/ChangeLog: PR libstdc++/95983 * include/bits/stl_iterator.h (__detail::__move_iter_cat): Define. (move_iterator): Derive from the above in C++20 in order to conditionally define iterator_category as per P2259. (move_iterator::__base_cat): No longer used, so remove. (move_iterator::iterator_category): Remove in C++20. (__detail::__common_iter_use_postfix_proxy): Define. (common_iterator::_Proxy): Rename to ... (common_iterator:__arrow_proxy): ... this. (common_iterator::__postfix_proxy): Define as per P2259. (common_iterator::operator->): Adjust. (common_iterator::operator++): Adjust as per P2259. (iterator_traits::_S_iter_cat): Define. (iterator_traits::iterator_category): Change as per P2259. (__detail::__counted_iter_value_type): Define. (__detail::__counted_iter_concept): Define. (__detail::__counted_iter_cat): Define. (counted_iterator): Derive from the above three classes in order to conditionally define value_type, iterator_concept and iterator category respectively as per P2259. (counted_iterator::operator->): Define as per P2259. (incrementable_traits): Remove as per P2259. (iterator_traits): Adjust as per P2259. * include/std/ranges (__detail::__iota_view_iter_cat): Define. (iota_view::_Iterator): Derive from the above in order to conditionally define iterator_category as per P2259. (iota_view::_S_iter_cat): Rename to ... (iota_view::_S_iter_concept): ... this. (iota_view::iterator_concept): Use it to apply LWG 3291 changes. (iota_view::iterator_category): Remove. (__detail::__filter_view_iter_cat): Define. (filter_view::_Iterator): Derive from the above in order to conditionally define iterator_category as per P2259. (filter_view::_Iterator): Move to struct __filter_view_iter_cat. (filter_view::_Iterator::iterator_category): Remove. (transform_view::_Base): Define. (transform_view::__iter_cat): Define. (transform_view::_Iterator): Derive from the above in order to conditionally define iterator_category as per P2259. (transform_view::_Iterator::_Base): Just alias transform_view::_Base. (transform_view::_Iterator::_S_iter_cat): Move to struct transform_view::__iter_cat. (transform_view::_Iterator::iterator_category): Remove. (transform_view::_Sentinel::_Base): Just alias transform_view::_Base. (join_view::_Base): Define. (join_view::_Outer_iter): Define. (join_view::_Inner_iter): Define. (join_view::_S_ref_is_glvalue): Define. (join_view::__iter_cat): Define. (join_view::_Iterator): Derive from it in order to conditionally define iterator_category as per P2259. (join_view::_Iterator::_Base): Just alias join_view::_Base. (join_view::_Iterator::_S_ref_is_glvalue): Just alias join_view::_S_ref_is_glvalue. (join_view::_Iterato
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:eecefcb78c311b509d9fac2fe38b5b293e095bec commit r11-8262-geecefcb78c311b509d9fac2fe38b5b293e095bec Author: Patrick Palka Date: Tue Apr 20 09:18:50 2021 -0400 libstdc++: Implement P2259R1 changes [PR95983] This implements the wording changes of P2259R1 "Repairing input range adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408. The wording changes are relatively straightforward, but they require some boilerplate to implement: the changes to make a type alias "conditionally present" in some iterator class are realized by defining a base class template and an appropriately constrained partial specialization thereof that contains the type alias, and having the iterator class derive from this base class. Sometimes the relevant condition depend on members from the iterator class, but because a class is incomplete when instantiating its bases, the constraints on the partial specialization can't use anything from the iterator class. This patch works around this by hoisting these members out to the enclosing scope (e.g. transform_view::_Iterator::_Base is hoisted out to transform_view::_Base so that transform_view::__iter_cat can use it). This patch also implements the proposed resolution of LWG 3291 to rename iota_view::iterator_category to iota_view::iterator_concept, which was previously problematic due to LWG 3408. libstdc++-v3/ChangeLog: PR libstdc++/95983 * include/bits/stl_iterator.h (__detail::__move_iter_cat): Define. (move_iterator): Derive from the above in C++20 in order to conditionally define iterator_category as per P2259. (move_iterator::__base_cat): No longer used, so remove. (move_iterator::iterator_category): Remove in C++20. (__detail::__common_iter_use_postfix_proxy): Define. (common_iterator::_Proxy): Rename to ... (common_iterator:__arrow_proxy): ... this. (common_iterator::__postfix_proxy): Define as per P2259. (common_iterator::operator->): Adjust. (common_iterator::operator++): Adjust as per P2259. (iterator_traits::_S_iter_cat): Define. (iterator_traits::iterator_category): Change as per P2259. (__detail::__counted_iter_value_type): Define. (__detail::__counted_iter_concept): Define. (__detail::__counted_iter_cat): Define. (counted_iterator): Derive from the above three classes in order to conditionally define value_type, iterator_concept and iterator category respectively as per P2259. (counted_iterator::operator->): Define as per P2259. (incrementable_traits): Remove as per P2259. (iterator_traits): Adjust as per P2259. * include/std/ranges (__detail::__iota_view_iter_cat): Define. (iota_view::_Iterator): Derive from the above in order to conditionally define iterator_category as per P2259. (iota_view::_S_iter_cat): Rename to ... (iota_view::_S_iter_concept): ... this. (iota_view::iterator_concept): Use it to apply LWG 3291 changes. (iota_view::iterator_category): Remove. (__detail::__filter_view_iter_cat): Define. (filter_view::_Iterator): Derive from the above in order to conditionally define iterator_category as per P2259. (filter_view::_Iterator): Move to struct __filter_view_iter_cat. (filter_view::_Iterator::iterator_category): Remove. (transform_view::_Base): Define. (transform_view::__iter_cat): Define. (transform_view::_Iterator): Derive from the above in order to conditionally define iterator_category as per P2259. (transform_view::_Iterator::_Base): Just alias transform_view::_Base. (transform_view::_Iterator::_S_iter_cat): Move to struct transform_view::__iter_cat. (transform_view::_Iterator::iterator_category): Remove. (transform_view::_Sentinel::_Base): Just alias transform_view::_Base. (join_view::_Base): Define. (join_view::_Outer_iter): Define. (join_view::_Inner_iter): Define. (join_view::_S_ref_is_glvalue): Define. (join_view::__iter_cat): Define. (join_view::_Iterator): Derive from it in order to conditionally define iterator_category as per P2259. (join_view::_Iterator::_Base): Just alias join_view::_Base. (join_view::_Iterator::_S_ref_is_glvalue): Just alias join_view::_S_ref_is_glvalue. (join_vi
[Bug rtl-optimization/100148] [10/11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug rtl-optimization/100148] [10/11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148 --- Comment #3 from Jakub Jelinek --- Created attachment 50637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50637&action=edit gcc11-pr100148.patch Untested fix.
[Bug target/100108] [10/11/12 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108 --- Comment #8 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:6156df483fa50a08f561b6c248819f2992aa380d commit r12-9-g6156df483fa50a08f561b6c248819f2992aa380d Author: Segher Boessenkool Date: Tue Apr 20 12:00:50 2021 + rs6000: Fix cpu selection w/ isel (PR100108) There are various non-IBM CPUs with isel as well, so it is easiest if we just don't consider that flag here (it is not needed). 2021-04-20 Segher Boessenkool PR target/100108 * config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not consider OPTION_MASK_ISEL.
[Bug target/100152] New: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Bug ID: 100152 Summary: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina) Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: lucier at math dot purdue.edu Target Milestone: --- With this compiler: [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper Target: x86_64-apple-darwin19.6.0 Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0 --enable-languages=c --disable-multilib --enable-checking=release --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.3.0 (GCC) and these compiler options: /usr/local/gcc-10.3.0/bin/gcc -save-temps -g -O3 -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fomit-frame-pointer -fPIC -fno-common -mpc64 -I"../include" -c -o c_intf.o -I. -DHAVE_CONFIG_H -D___GAMBITDIR="\"/usr/local/Gambit\"" -D___GAMBITDIR_USERLIB="\"~/.gambit_userlib\"" -D___GAMBITDIR_INSTLIB="\"~~userlib\"" -D___SYS_TYPE_CPU="\"x86_64\"" -D___SYS_TYPE_VENDOR="\"apple\"" -D___SYS_TYPE_OS="\"darwin19.6.0\"" -D___CONFIGURE_COMMAND="\"./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps -g' '--enable-single-host' '--enable-shared'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL c_intf.c -D___LIBRARY on Mac OS 10.5.7 (Catalina), I get a runtime failure, with console message: Exception Type:EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x000c, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Illegal instruction: 4 Termination Reason:Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [98080] Application Specific Information: dyld2 mode Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libgambit.dylib 0x00010dfaf010 ___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280) The disassembly (with arrow pointing to the noted instruction) is: (lldb) di -s 0x000103d6 -c 10 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING: 0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at c_intf.c:3282:9 0x103d60002 <+1506>: orb%al, 0x31(%rbp) 0x103d60005 <+1509>: shlb %cl, 0x2e(%rsi) 0x103d60008 <+1512>: nopl (%rax,%rax) -> 0x103d60010 <+1520>: movl (%rbp,%r10,4), %esi 0x103d60015 <+1525>: callq 0x103fba9a0 ; symbol stub for: ___UTF_8_put 0x103d6001a <+1530>: movq %r10, %rax 0x103d6001d <+1533>: addq $0x1, %r10 0x103d60021 <+1537>: cmpq %r12, %rax 0x103d60024 <+1540>: jne0x103d60010 ; <+1520> at c_intf.c:3280:173 I'll add the .i and .s files. I apologize for their length, I don't know how much I can cut out and still keep them relevant.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #1 from lucier at math dot purdue.edu --- Created attachment 50638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50638&action=edit preprocessed source file
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #2 from lucier at math dot purdue.edu --- Created attachment 50639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50639&action=edit Gzipped assembly file
[Bug target/100108] [10/11/12 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:8bd3b0c11cb08f63d2ca41a21596d16635626661 commit r11-8264-g8bd3b0c11cb08f63d2ca41a21596d16635626661 Author: Segher Boessenkool Date: Tue Apr 20 12:00:50 2021 + rs6000: Fix cpu selection w/ isel (PR100108) There are various non-IBM CPUs with isel as well, so it is easiest if we just don't consider that flag here (it is not needed). 2021-04-20 Segher Boessenkool PR target/100108 * config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not consider OPTION_MASK_ISEL. (cherry picked from commit 6156df483fa50a08f561b6c248819f2992aa380d)
[Bug libstdc++/100153] New: Undefined behavior in stl_bvector.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100153
Bug ID: 100153
Summary: Undefined behavior in stl_bvector.h
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
stl_bvector.h#L505:
_Bit_type*
_M_end_addr() const _GLIBCXX_NOEXCEPT
{
if (this->_M_end_of_storage)
return std::__addressof(this->_M_end_of_storage[-1]) + 1;
return 0;
}
This one will cause UB if _M_end_of_storage is not nullptr and
_M_end_of_storage is equal to _M_start._M_p.
Consider (https://godbolt.org/z/vvrG6KcWP):
std::vector bv{true, false, true};
bv.clear();
bv.shrink_to_fit();
bv.capacity();
When shrink_to_fit() ends, _M_end_of_storage will be equal to _M_start._M_p and
not nullptr. In capacity():
size_type
capacity() const _GLIBCXX_NOEXCEPT
{ return size_type(const_iterator(this->_M_impl._M_end_addr(), 0)
- begin()); }
we will call _M_end_addr() and perform illegal dereference which cause UB, same
with push_back(), insert() and flip().
[Bug c++/100109] [8/9/10/11 Regression] ICE: unexpected expression 'E' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109 Jason Merrill changed: What|Removed |Added Summary|[8/9/10/11/12 Regression] |[8/9/10/11 Regression] ICE: |ICE: unexpected expression |unexpected expression 'E' |'E' of kind |of kind template_parm_index |template_parm_index | --- Comment #3 from Jason Merrill --- Fixed for 12 so far.
[Bug libstdc++/89322] Use of new and -lsupc++ requires -lstdc++ on architectures without atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89322 --- Comment #1 from Jonathan Wakely --- This should be fixed by the changes for PR 96657
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- thanks for the report. please could you check the uploaded assembly file, it seems to be truncated?
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #4 from Iain Sandoe --- (In reply to Iain Sandoe from comment #3) > please could you check the uploaded assembly file, it seems to be truncated? Ignore that - decompressor glitch.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #5 from lucier at math dot purdue.edu --- I didn't have this trouble with 10.2 or 9.3; should I add these to the "Known to work" field?
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #6 from Iain Sandoe --- (In reply to lucier from comment #5) > I didn't have this trouble with 10.2 or 9.3; should I add these to the > "Known to work" field? yes please - also the original source, if that's OK?
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #7 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #6) > yes please - also the original source, if that's OK? It's highly macrofied C code with a lot of "includes"; is the .i file not enough? Brad
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #8 from Iain Sandoe --- (In reply to lucier from comment #7) > (In reply to Iain Sandoe from comment #6) > > > yes please - also the original source, if that's OK? > > It's highly macrofied C code with a lot of "includes"; is the .i file not > enough? enough for me to replicate the assembly produced, yes. would it be possible to set a breakpoint on the function itself and step through - the reported "invalid insn" seems odd, for sure. the values of rbp. r10 and esi would be interesting too.
[Bug libstdc++/100153] Undefined behavior in stl_bvector.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100153 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-20 --- Comment #1 from Jonathan Wakely --- I think the bug is that vector::shrink_to_fit() always allocates, even if the new capacity is zero. It should set _M_start._M_p == _M_end_of_storage == nullptr
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #9 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #8) > (In reply to lucier from comment #7) > > (In reply to Iain Sandoe from comment #6) > > > > > yes please - also the original source, if that's OK? > > > > It's highly macrofied C code with a lot of "includes"; is the .i file not > > enough? > > enough for me to replicate the assembly produced, yes. > > would it be possible to set a breakpoint on the function itself and step > through - the reported "invalid insn" seems odd, for sure. I'll look into this---the way the program is called is not simple, it's a Scheme->C compiler building a "module", so it's hidden behind a number of scripts. > the values of rbp. r10 and esi would be interesting too. This is from the console crash report: Thread 0 crashed with X86 Thread State (64-bit): rax: 0x7fff924cfba8 rbx: 0x0001 rcx: 0x00010e4bdf90 rdx: 0x00010e4bdca0 rdi: 0x7ffee1c853a8 rsi: 0x002f rbp: 0x7fdf00595ec0 rsp: 0x7ffee1c853a0 r8: 0x0460 r9: 0x0466 r10: 0x7fff924cfba9 r11: 0x00010dfab920 r12: 0x0042 r13: 0x7ffee1c853f8 r14: 0x00010e4bdca0 r15: 0x06d8 rip: 0x00010dfaf010 rfl: 0x00010206 cr2: 0x00010dfaea20
[Bug c++/96994] Missing code from consteval constructor initializing const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96994 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #10 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #8) > (In reply to lucier from comment #7) > > (In reply to Iain Sandoe from comment #6) > > > > > yes please - also the original source, if that's OK? > > > > It's highly macrofied C code with a lot of "includes"; is the .i file not > > enough? > > enough for me to replicate the assembly produced, yes. OK, the .i file is also attached to this bug report.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #11 from Iain Sandoe --- (In reply to lucier from comment #10) > (In reply to Iain Sandoe from comment #8) > > (In reply to lucier from comment #7) > > > (In reply to Iain Sandoe from comment #6) > > > > > > > yes please - also the original source, if that's OK? > > > > > > It's highly macrofied C code with a lot of "includes"; is the .i file not > > > enough? > > > > enough for me to replicate the assembly produced, yes. > > OK, the .i file is also attached to this bug report. indeed, thanks. is this specific to macOS? (or is it unknown if the effect would also show on Linux)?
[Bug c/97748] Preincrement of _Complex gives bogus warning = "value computed is not used"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97748 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed for 10.3+.
[Bug middle-end/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #12 from Martin Sebor --- Sounds like this is effectively the same request as pr70069 for which there's a POC prototype: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565514.html Let's track the request there and resolve this as a duplicate. *** This bug has been marked as a duplicate of bug 70069 ***
[Bug middle-end/70069] Uninitialized value default to zero, plus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069 Martin Sebor changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #4 from Martin Sebor --- *** Bug 99797 has been marked as a duplicate of this bug. ***
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #12 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #11) > is this specific to macOS? (or is it unknown if the effect would also show > on Linux)? It does not show up on Linux with gcc-10.3.0. I forgot to mention one thing that may be important---it shows up only when configuring and building a shared library, not when building a static library. I'm sorry, I should have just included the entire console crash report, here it is. Process: gsc [98080] Path: /Users/USER/*/gsc Identifier:gsc Version: 0 Code Type: X86-64 (Native) Parent Process:bash [98061] Responsible: X11.bin [3613] User ID: 502 Date/Time: 2021-04-19 20:46:16.292 -0400 OS Version:Mac OS X 10.15.7 (19H524) Report Version:12 Bridge OS Version: 5.2 (18P4346) Anonymous UUID:502BD235-3A7B-DBA1-5FD5-B92502CEE0D5 Sleep/Wake UUID: 7F858BB5-C456-41BC-888B-282D50F0E93B Time Awake Since Boot: 250 seconds Time Since Wake: 210 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x000c, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Illegal instruction: 4 Termination Reason:Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [98080] Application Specific Information: dyld2 mode Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libgambit.dylib 0x00010dfaf010 ___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280) Thread 0 crashed with X86 Thread State (64-bit): rax: 0x7fff924cfba8 rbx: 0x0001 rcx: 0x00010e4bdf90 rdx: 0x00010e4bdca0 rdi: 0x7ffee1c853a8 rsi: 0x002f rbp: 0x7fdf00595ec0 rsp: 0x7ffee1c853a0 r8: 0x0460 r9: 0x0466 r10: 0x7fff924cfba9 r11: 0x00010dfab920 r12: 0x0042 r13: 0x7ffee1c853f8 r14: 0x00010e4bdca0 r15: 0x06d8 rip: 0x00010dfaf010 rfl: 0x00010206 cr2: 0x00010dfaea20 Logical CPU: 4 Error Code: 0x Trap Number: 12 Binary Images: 0x10df75000 -0x10df80ff7 +gsc (0) /Users/USER/*/gsc 0x10df9b000 -0x10e21afff +libgambit.dylib (0) <8B13D756-0995-39A9-A32E-6A42E6D0635A> /Users/USER/*/libgambit.dylib 0x10e726000 -0x10e9f1fff +libgambitgsc.dylib (0) /Users/USER/*/libgambitgsc.dylib 0x10f027000 -0x10f03efff +libgcc_s.1.dylib (1) <8BF2E6A1-4FDE-3DAB-B58E-45A8624D3FA1> /usr/local/gcc-10.3.0/lib/libgcc_s.1.dylib 0x112a0b000 -0x112a9cf47 dyld (750.6) <326C6480-04F4-3164-A363-53079A148E2F> /usr/lib/dyld 0x7fff68dc9000 - 0x7fff68dcafff libSystem.B.dylib (1281.100.1) /usr/lib/libSystem.B.dylib 0x7fff690af000 - 0x7fff69101fff libc++.1.dylib (902.1) <59A8239F-C28A-3B59-B8FA-11340DC85EDC> /usr/lib/libc++.1.dylib 0x7fff69102000 - 0x7fff69117ffb libc++abi.dylib (902) /usr/lib/libc++abi.dylib 0x7fff6ac29000 - 0x7fff6ac5cfde libobjc.A.dylib (787.1) <6DF81160-5E7F-3E31-AA1E-C875E3B98AF6> /usr/lib/libobjc.A.dylib 0x7fff6bbc6000 - 0x7fff6bbcbff3 libcache.dylib (83) /usr/lib/system/libcache.dylib 0x7fff6bbcc000 - 0x7fff6bbd7fff libcommonCrypto.dylib (60165.120.1) /usr/lib/system/libcommonCrypto.dylib 0x7fff6bbd8000 - 0x7fff6bbd libcompiler_rt.dylib (101.2) <49B8F644-5705-3F16-BBE0-6FFF9B17C36E> /usr/lib/system/libcompiler_rt.dylib 0x7fff6bbe - 0x7fff6bbe9ff7 libcopyfile.dylib (166.40.1) <3C481225-21E7-370A-A30E-0CCFDD64A92C> /usr/lib/system/libcopyfile.dylib 0x7fff6bbea000 - 0x7fff6bc7cfdb libcorecrypto.dylib (866.140.1) <60567BF8-80FA-359A-B2F3-A3BAEFB288FD> /usr/lib/system/libcorecrypto.dylib 0x7fff6bd89000 - 0x7fff6bdc9ff0 libdispatch.dylib (1173.100.2) /usr/lib/system/libdispatch.dylib 0x7fff6bdca000 - 0x7fff6be00fff libdyld.dylib (750.6) <789A18C2-8AC7-3C88-813D-CD674376585D> /usr/lib/system/libdyld.dylib 0x7fff6be01000 - 0x7fff6be01ffb libkeymgr.dylib (30) /usr/lib/system/libkeymgr.dylib 0x7fff6be0f000 - 0x7fff6be0fff7 liblaunch.dylib (1738.140.2) <7200E214-9B4D-3B22-9844-4C7892FC890B> /usr/lib/system/liblaunch.dylib 0x7fff6be1 - 0x7fff6be15ff7 libmacho.dylib (959.0.1) /usr/lib/system/libmacho.dylib 0x7fff6be16000 - 0x7fff6be18ff3 libquarantine.dylib (110.40.3) /usr/lib/system/libquarantine.dylib 0x7fff6be19000 - 0x7fff6be1aff7 libremovefile.dylib (48) <7C7EFC79-BD24-33EF-B073-06AED234593E> /usr/lib/system/libremovefile.dylib 0x7fff6be1b000 - 0x7fff6be32ff3 libsystem_asl.dylib (377.60.2) <1563EE02-0657-3B78-99BE-A947C24122EF> /usr/lib/system/libsystem_asl.dylib
[Bug libstdc++/100153] Undefined behavior in stl_bvector.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100153 --- Comment #2 from Jonathan Wakely --- Fixed downstream: https://gitlab.com/jonathan-wakely/gcc/-/commit/0df97f13e88fe8383b5663bb51de1fa691537cc4
[Bug libstdc++/98749] No precondition checks in , and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98749 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-20
[Bug libstdc++/96070] std::views::* won't work with non-legacy iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Patrick Palka --- This is also fixed by P2259R1, so let's mark this PR as a dup of PR95893. *** This bug has been marked as a duplicate of bug 95893 ***
[Bug fortran/95893] pr95690.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95893 Patrick Palka changed: What|Removed |Added CC||gcc-bugs at marehr dot dialup.fu-b ||erlin.de --- Comment #3 from Patrick Palka --- *** Bug 96070 has been marked as a duplicate of this bug. ***
[Bug libstdc++/96070] std::views::* won't work with non-legacy iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070 --- Comment #4 from Patrick Palka --- Whoops, rather PR95983... *** This bug has been marked as a duplicate of bug 95983 ***
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #7 from Patrick Palka --- *** Bug 96070 has been marked as a duplicate of this bug. ***
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #8 from Patrick Palka --- (In reply to gcc-bugs from comment #4) > Hi Patrick, > > thank you for that patch. I guess that it also fixes > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070. Ah indeed, thanks. The testcase there seems similar enough to mark the PR as a dup of this one. > > Will this patch be backported to gcc-10? I believe so; fortunately, the patch applies pretty cleanly to the 10 branch, so I don't expect many changes will be needed in order to backport.
[Bug c++/99885] CTAD fails for auto const& NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99885 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:904cbf6ae2a1e45b3a272365cca19f9dd9a27fa2 commit r10-9733-g904cbf6ae2a1e45b3a272365cca19f9dd9a27fa2 Author: Patrick Palka Date: Tue Apr 20 12:06:24 2021 -0400 c++: Fix deduction with reference NTTP [PR83476] In the testcase ref11.C below, during deduction for the call f(a), uses_deducible_template_parms returns false for the dependent specialization A because the generic template argument V here is wrapped in an implicit INDIRECT_REF (formed from template_parm_to_arg). Since uses_deducible_template_parms returns false, unify_one_argument exits early without ever attempting to deduce 'n' for 'V'. This patch fixes this by making deducible_expression look through such implicit INDIRECT_REFs. gcc/cp/ChangeLog: PR c++/83476 PR c++/99885 * pt.c (deducible_expression): Look through implicit INDIRECT_REFs as well. gcc/testsuite/ChangeLog: PR c++/83476 PR c++/99885 * g++.dg/cpp1z/class-deduction85.C: New test. * g++.dg/template/ref11.C: New test. (cherry picked from commit 2ccc05a5141506fde0e20dec702c717fd67bf6ee)
[Bug c++/83476] [8/9/10 Regression] Template argument deduction fails with reference template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83476 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:904cbf6ae2a1e45b3a272365cca19f9dd9a27fa2 commit r10-9733-g904cbf6ae2a1e45b3a272365cca19f9dd9a27fa2 Author: Patrick Palka Date: Tue Apr 20 12:06:24 2021 -0400 c++: Fix deduction with reference NTTP [PR83476] In the testcase ref11.C below, during deduction for the call f(a), uses_deducible_template_parms returns false for the dependent specialization A because the generic template argument V here is wrapped in an implicit INDIRECT_REF (formed from template_parm_to_arg). Since uses_deducible_template_parms returns false, unify_one_argument exits early without ever attempting to deduce 'n' for 'V'. This patch fixes this by making deducible_expression look through such implicit INDIRECT_REFs. gcc/cp/ChangeLog: PR c++/83476 PR c++/99885 * pt.c (deducible_expression): Look through implicit INDIRECT_REFs as well. gcc/testsuite/ChangeLog: PR c++/83476 PR c++/99885 * g++.dg/cpp1z/class-deduction85.C: New test. * g++.dg/template/ref11.C: New test. (cherry picked from commit 2ccc05a5141506fde0e20dec702c717fd67bf6ee)
[Bug c++/95434] ICE for CTAD in generic lambda within variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95434
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:2400f81c2c2489f4b6fbb245ef946a39be40defd
commit r10-9734-g2400f81c2c2489f4b6fbb245ef946a39be40defd
Author: Patrick Palka
Date: Tue Apr 20 12:06:27 2021 -0400
c++: Fix tsubsting CLASS_PLACEHOLDER_TEMPLATE [PR95434]
Here, during partial instantiation of the generic lambda, we do
tsubst_copy on the CLASS_PLACEHOLDER_TEMPLATE for U{0} which yields a
(level-lowered) TEMPLATE_TEMPLATE_PARM rather than the corresponding
TEMPLATE_DECL. This later confuses do_class_deduction which expects
that a CLASS_PLACEHOLDER_TEMPLATE is always a TEMPLATE_DECL.
gcc/cp/ChangeLog:
PR c++/95434
* pt.c (tsubst) : If tsubsting
CLASS_PLACEHOLDER_TEMPLATE yields a TEMPLATE_TEMPLATE_PARM,
adjust to its TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL.
gcc/testsuite/ChangeLog:
PR c++/95434
* g++.dg/cpp2a/lambda-generic9.C: New test.
(cherry picked from commit cafcfcb5840b62d9fc80c12192189351e995a4f2)
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ebb734aac092cc1ea1208b3a96cc2b6ad85cf5a1 commit r10-9735-gebb734aac092cc1ea1208b3a96cc2b6ad85cf5a1 Author: Patrick Palka Date: Tue Apr 20 12:06:37 2021 -0400 c++: ICE in dependent_type_p with constrained auto [PR97052] This patch fixes an "unguarded" call to coerce_template_parms in build_standard_check: processing_template_decl could be zero if we get here during processing of the first 'auto' parameter of an abbreviated function template, or if we're processing the type constraint of a non-templated variable. In the testcase below, this leads to an ICE when coerce_template_parms instantiates C's dependent default template argument. gcc/cp/ChangeLog: PR c++/97052 * constraint.cc (build_type_constraint): Temporarily increment processing_template_decl before calling build_concept_check. * pt.c (make_constrained_placeholder_type): Likewise. gcc/testsuite/ChangeLog: PR c++/97052 * g++.dg/cpp2a/concepts-defarg2.C: New test. (cherry picked from commit c1c62aec6751678e958ab5c61b2d903a09d7efd9)
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 10.4/11.
[Bug c++/95434] ICE for CTAD in generic lambda within variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95434 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/96380] [10/11 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96380 Marek Polacek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in tree check: expected |tree check: expected |integer_cst, have |integer_cst, have |view_convert_expr in|view_convert_expr in |get_len, at tree.h:5954 |get_len, at tree.h:5954 --- Comment #5 from Marek Polacek --- (In reply to Marek Polacek from comment #3) > (In reply to Jakub Jelinek from comment #2) > > Marek, have you made any progress on this? > > Not yet, sorry. Hopefully this week then. Testing a patch now.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #13 from lucier at math dot purdue.edu ---
(In reply to Iain Sandoe from comment #8)
> the values of rbp. r10 and esi would be interesting too.
I'm not really familiar with assembler, don't know what register esi is, here's
what lldb says:
(lldb) register read -a
General Purpose Registers:
rax = 0x7fff924cfba8 sGlobalMutex + 32
rbx = 0x0001
rcx = 0x00010426ef90 libgambit.dylib`___gstate0 + 752
rdx = 0x00010426eca0 libgambit.dylib`___gstate0
rdi = 0x7ffeebed73d8
rsi = 0x002f
rbp = 0x7fa600595ec0
rsp = 0x7ffeebed73d0
r8 = 0x045c
r9 = 0x0462
r10 = 0x7fff924cfba9 sGlobalMutex + 33
r11 = 0x000103d5c920 libgambit.dylib`___UTF_8_put at c_intf.c:407:6
r12 = 0x0042
r13 = 0x7ffeebed7428
r14 = 0x00010426eca0 libgambit.dylib`___gstate0
r15 = 0x06d8
rip = 0x000103d60010 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING +
1520 at c_intf.c:3280:173
rflags = 0x00010206
cs = 0x002b
fs = 0x
gs = 0x
Floating Point Registers:
fcw = 0x0005
fsw = 0x
ftw = 0x83
fop = 0x
ip = 0x25ff5699
cs = 0x8670
dp = 0x027f
ds = 0x
mxcsr = 0x
mxcsrmask = 0x
stmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xa0 0x1f}
stmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
stmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
stmm7 = {0xc8 0x5f 0x59 0x02 0x00 0x00 0x00 0x00 0xff 0xff}
xmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm7 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm8 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm9 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm10 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm11 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm12 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm13 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm14 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm15 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
Exception State Registers:
trapno = 0x
err = 0x
faultvaddr = 0x
[Bug fortran/70244] [OOP] ICE in spec_dimen_size(): Bad dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70244 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #5 from G. Steinmetz --- Some presumably related examples, where z1.f90 gives an ICE, while minimal less complex examples z2.f90 and z3.f90 compile : $ cat z1.f90 program p type t procedure(g), pointer, nopass :: f end type type(t) :: a(1) a(1)%f => g contains function g() result(z) real :: z(2,2) end end $ cat z2.f90 program p type t procedure(g), pointer, nopass :: f end type type(t) :: a a%f => g contains function g() result(z) real :: z(2,2) end end $ cat z3.f90 program p type t procedure(g), pointer, nopass :: f end type type(t) :: a(1) a(1)%f => g contains function g() result(z) real :: z(2) end end $ gfortran-11-20210418 -c z1.f90 f951: internal compiler error: spec_dimen_size(): Bad dimension 0x686b09 gfc_report_diagnostic ../../gcc/fortran/error.c:782 0x68822a gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1402 0x65705e spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1]) ../../gcc/fortran/array.c:2300 0x6f299f expression_shape ../../gcc/fortran/resolve.c:5439 0x6f299f gfc_expression_rank(gfc_expr*) ../../gcc/fortran/resolve.c:5513 0x6f4a6e resolve_variable ../../gcc/fortran/resolve.c:5943 0x6f4a6e gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7107 0x6fc384 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7072 0x6fc384 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11820 0x6fd997 resolve_codes ../../gcc/fortran/resolve.c:17396 0x6fda5e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17431 0x6e5fb4 resolve_all_program_units ../../gcc/fortran/parse.c:6290 0x6e5fb4 gfc_parse_file() ../../gcc/fortran/parse.c:6542 0x7329cf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/100154] New: [9/10/11 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154
Bug ID: 100154
Summary: [9/10/11 Regression] ICE in gfc_conv_procedure_call,
at fortran/trans-expr.c:6131
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20180916 and 20180923 :
$ cat z1.f90
program p
n = fget('c')
end
$ gfortran-9-20180916 -c z1.f90
$
$ gfortran-11-20210418 -c z1.f90
z1.f90:2:16:
2 |n = fget('c')
|1
internal compiler error: Segmentation fault
0xc0b22f crash_signal
../../gcc/toplev.c:327
0x771d0f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6131
0x78e23e gfc_conv_intrinsic_funcall
../../gcc/fortran/trans-intrinsic.c:4443
0x791467 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:10170
0x76766a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8967
0x7774a1 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11259
0x739707 trans_code
../../gcc/fortran/trans.c:1932
0x75fd34 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6884
0x6e66b6 translate_all_program_units
../../gcc/fortran/parse.c:6351
0x6e66b6 gfc_parse_file()
../../gcc/fortran/parse.c:6620
0x7329cf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212
[Bug fortran/100155] New: [9/10/11 Regression] ICE in gfc_conv_intrinsic_size, at fortran/trans-intrinsic.c:805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100155 Bug ID: 100155 Summary: [9/10/11 Regression] ICE in gfc_conv_intrinsic_size, at fortran/trans-intrinsic.c:805 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20181014 and 20181021 : (r8 changed between 20190503 and 20190614) $ cat z1.f90 program p type t end type contains recursive function f(x) result(z) class(*):: x(:) type(t) :: z(size(x)) class(t), allocatable :: a(:) class(t), allocatable :: b(:) b = f((a)) end end $ cat z2.f90 program p type t end type contains recursive function f(x) result(z) class(*):: x(:) type(t) :: z(size(x)) class(t), pointer :: a(:) class(t), allocatable :: b(:) b = f((a)) end end $ gfortran-9-20181014 -c z1.f90 $ $ gfortran-11-20210418 -c z1.f90 z1.f90:10:16: 10 | b = f((a)) |1 internal compiler error: Segmentation fault 0xc0b22f crash_signal ../../gcc/toplev.c:327 0x77abf7 gfc_conv_intrinsic_size ../../gcc/fortran/trans-intrinsic.c:8055 0x79211b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:10702 0x76766a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8967 0x769b0a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:4830 0x73c647 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) ../../gcc/fortran/trans-array.c:940 0x773e5e gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:7041 0x77547c gfc_trans_arrayfunc_assign ../../gcc/fortran/trans-expr.c:10441 0x778fd4 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool) ../../gcc/fortran/trans-expr.c:11610 0x739707 trans_code ../../gcc/fortran/trans.c:1932 0x75fd34 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6884 0x75fb34 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5878 0x75fb34 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6816 0x6e66b6 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e66b6 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x7329cf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/100155] [9/10/11 Regression] ICE in gfc_conv_intrinsic_size, at fortran/trans-intrinsic.c:805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100155 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Compiles without these extra parentheses in f((a)) : $ cat z0.f90 program p type t end type contains recursive function f(x) result(z) class(*):: x(:) type(t) :: z(size(x)) class(t), allocatable :: a(:) class(t), allocatable :: b(:) b = f(a) end end
[Bug fortran/100156] New: ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100156 Bug ID: 100156 Summary: ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6257 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With option -fcoarray=single, affects versions down to at least r5 : (compiles with -fcoarray=lib) (compiles always without attribute volatile) $ cat z1.f90 program p integer, volatile :: a = 1 integer, volatile :: b[*] = 1 if (a /= b) stop end $ gfortran-11-20210418 -c z1.f90 -fcoarray=lib $ $ gfortran-11-20210418 -c z1.f90 -fcoarray=single z1.f90:5:3: 5 | end | 1 internal compiler error: Segmentation fault 0xc0b22f crash_signal ../../gcc/toplev.c:327 0x7425b1 gfc_trans_array_cobounds(tree_node*, stmtblock_t*, gfc_symbol const*) ../../gcc/fortran/trans-array.c:6257 0x75e271 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.c:4858 0x75fe22 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6988 0x6e66b6 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e66b6 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x7329cf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c++/100157] New: Support `__type_pack_element` like Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157 Bug ID: 100157 Summary: Support `__type_pack_element` like Clang Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vittorio.romeo at outlook dot com Target Milestone: --- Clang provides a `__type_pack_element` builtin which allows efficient indexing of parameter packs in variadic templates, and it seems that GCC has no equivalent. This forces users interested in minimizing compilation times to resort to arcane implemenations such as these ones: https://github.com/kvasir-io/mpl/blob/development/src/kvasir/mpl/sequence/lookup.hpp A builtin like `__type_pack_element` would not only allow user code to compile faster, but also anything inside libstdc++ that needs to index a type list (e.g. `std::tuple_element_t`) would benefit from it. This is the Clang test driver, to show an usage example: https://github.com/llvm-mirror/clang/blob/master/test/SemaCXX/type_pack_element.cpp This is the Clang pull request: https://reviews.llvm.org/D15421
[Bug fortran/100158] New: Some issues with fortran testsuite files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100158 Bug ID: 100158 Summary: Some issues with fortran testsuite files Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- In the following some issues with fortran test files itself : --- Two test files substr* are placed at top level, should be better moved to catalog gfortran.dg $ ls ./gcc-11-20210418/gcc/testsuite 200704 19. Apr 00:32 gfortran.dg 57 19. Apr 00:32 gfortran.fortran-torture 438 19. Apr 00:32 substr_10.f90 766 19. Apr 00:32 substr_9.f90 --- pr100018 contributed a file PR10018.f90 in gfortran.dg, with a missing digit, should be renamed to PR100018.f90 --- These two testsuite files are identical, one seems to be superfluous : $ diff gfortran.dg/pr99602c.f90 gfortran.dg/pr99602d.f90 $ --- Some testsuite files disappeared without an entry in ChangeLog*. What happend with dtio_5.f90 and pdt_5.f03 ? They existed here : ./gcc-10-20200110/gcc/testsuite/gfortran.dg/pdt_5.f03 ./gcc-10-20200110/gcc/testsuite/gfortran.dg/dtio_5.f90 --- Other testsuite files existed here and are later gone somehow without an entry in ChangeLog* : ./gcc-8-20201210/gcc/testsuite/gfortran.dg/external_procedures_4.f90 ./gcc-7-20191107/gcc/testsuite/gfortran.dg/pr78686.f90 ./gcc-7-20191107/gcc/testsuite/gfortran.dg/pr91686.f90 ./gcc-5-20171003/gcc/testsuite/gfortran.dg/pr58754.f90 ---
[Bug testsuite/100159] New: Typos in testsuite files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100159
Bug ID: 100159
Summary: Typos in testsuite files
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Found the following :
A missing letter : s/cpluspls/cplusplus/
./gcc/testsuite/g++.dg/template/nontype29.C:6:#if __cpluspls >= 201103L
./gcc/testsuite/g++.dg/template/nontype29.C:63:#if __cpluspls >= 201103L
An extra letter, likely s/expreession/expression/
./gcc/testsuite/gcc.dg/Wstring-compare.c:24:// {
dg-bogus "in this expreession" "unwanted note" { target *-*-* } .-1 }
./gcc/testsuite/gcc.dg/Wstring-compare.c:47:// {
dg-bogus "in this expreession" "unwanted note" { target *-*-* } .-1 }
./gcc/testsuite/gcc.dg/Wstring-compare.c:89:// {
dg-bogus "in this expreession" "unwanted note" { target *-*-* } .-1 }
./gcc/testsuite/gcc.dg/Wstring-compare.c:134:
// { dg-bogus "in this expreession" "unwanted note" { target *-*-* } .-1 }
./gcc/testsuite/gcc.dg/Wstring-compare.c:164:// {
dg-bogus "in this expreession" "unwanted note" { target *-*-* } .-1 }
[Bug c++/100160] New: MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100160 Bug ID: 100160 Summary: MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- Created attachment 50640 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50640&action=edit Test source code to reproduce issue (see issue reported here: https://github.com/brechtsanders/winlibs_mingw/issues/51) Several issues when using GCC built against MinGW-w64 for Windows to compile gomp test code (see attached minimal source code). Code compiles fine with: g++ -c -o test.o test.cpp -fopenmp -foffload=nvptx-none Linking fails when done like this: g++ -o test.exe test.o -lgomp mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set compilation terminated. lto-wrapper.exe: fatal error: d:/prog/winlibs64-10.3.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0//accel/nvptx-none/mkoffload.exe returned 1 exit status compilation terminated. d:/prog/winlibs64-10.3.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status Avoiding LTO seems to work around this and the following links fine: g++ -o test.exe test.o -fno-lto -lgomp When executing test.exe the output starts with: libgomp: while loading libgomp-plugin-nvptx.so.1: "libgomp-plugin-nvptx.so.1": The specified module could not be found. The correct file on Windows is libgomp-plugin-nvptx-1.dll, not libgomp-plugin-nvptx.so.1 After that the application runs, but I assume without gomp optimizations. The g++ used in my case is the one I built myself from source, including nvptx offload engine (can be downloaded from http://winlibs.com/): g++ --version g++.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/100161] New: Impossible to suppress Wtype-limits warning involving template parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100161
Bug ID: 100161
Summary: Impossible to suppress Wtype-limits warning involving
template parameter.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
If a comparison involving a template parameter is always true or false, it
should not raise a warning if it could take other values for other template
parameters.
In particular, the type-limits warning from the code below,
```
void f(unsigned);
template
void g()
{
for (unsigned i = 0; i < n; i++) {
f(i);
}
}
void h()
{
g<0>();
}
```
seems to be impossible to suppress. I think this is a regression around GCC 9
time. (I remember seeing it roughly around the same time/slightly after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90728)
This is partially related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95148
(which would at least provide a way to suppress the warning).
Also somewhat related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81642
though supposedly the C++ template example given there is fixed.
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:31a5cc60428b968c9ff3f505fcd1a5ef5c0083bb commit r9-9369-g31a5cc60428b968c9ff3f505fcd1a5ef5c0083bb Author: Jonathan Wakely Date: Thu Oct 8 15:14:58 2020 +0100 libstdc++: Add assertions for preconditions in sampling distributions [PR 82584] These three distributions all require 0 < S where S is the sum of the weights. When the sum is zero there's an undefined FP division by zero. Add assertions to help users diagnose the problem. libstdc++-v3/ChangeLog: PR libstdc++/82584 * include/bits/random.tcc (discrete_distribution::param_type::_M_initialize) (piecewise_constant_distribution::param_type::_M_initialize) (piecewise_linear_distribution::param_type::_M_initialize): Add assertions for positive sums.. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line. (cherry picked from commit b2a96bf9dce41ee777b1669e4a8b4c6df3ff3613)
