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