[Bug c++/80039] `constexpr` member function calls in a `constexpr` constructor are ignored if the object is defined locally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80039
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment #1 from David Stone ---
Here's another reproduction
```
struct s {
int m_value = 0;
constexpr int value() const {
return m_value;
}
constexpr s()
{
value();
m_value = 1;
}
};
constexpr auto x = s();
static_assert(x.value() == 1);
```
Still a problem on trunk.
This example shows it's not just that side effects are ignored, but also that
the return value is cached. My guess is that there is some code path that
memoizes calls to constexpr functions, replacing them with their return value,
and that code is getting invoked when it shouldn't be.
[Bug c++/99823] New: -funroll-all-loops bugs when using contexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99823 Bug ID: 99823 Summary: -funroll-all-loops bugs when using contexpr variable Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ustcw0ng at mail dot ustc.edu.cn Target Milestone: --- Created attachment 50483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50483=edit constexpr.cpp && unroll.cpp -funroll-all-loops indicates "Unroll all loops, even if their number of iterations is uncertain when the loop is entered. This usually makes programs run more slowly.". But in the following example constexpr.cpp can never turn to unroll.cpp, even if number of iterations is certain due to constexpr. compiler flag: -O3 -std=c++2a -DNDEBUG -funroll-all-loops
[Bug target/99822] New: Assembler messages: Error: integer register expected in the extended/shifted operand register at operand 3 -- `adds x1,xzr,#2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99822
Bug ID: 99822
Summary: Assembler messages: Error: integer register expected
in the extended/shifted operand register at operand 3
-- `adds x1,xzr,#2'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
GNU as 2.35.2 fails to assemble output of gcc-11.0.1-alpha20210328 snapshot
(g:499fa254ae8c9752d8c2cf3130b13ffddfd83546) generated w/ -O1 for the following
testcase:
int zt, bm, p5 = 1;
void __attribute__ ((cold))
l2 (unsigned long int hz)
{
__int128 d9 = 0;
unsigned long int *mg = hz ? : (unsigned long int *)
while (d9 < 1)
{
bm = bm > d9;
bm = bm == (d9 = bm || hz);
hz = 0x19700;
d9 = hz * hz;
while (p5 < 1)
{
bm = ((hz = 3) ? zt : 0) > 0x1001;
if (bm != 0)
{
__int128 *nd = (__int128 *) bm;
*nd /= 3;
}
*mg = 0x1001;
p5 -= *mg;
}
for (zt = 0; zt >= 0; zt += 2)
d9 = 0;
d9 += 2;
}
}
% aarch64-linux-gnu-gcc-11.0.1 -O1 -w -c drr4usrh.c
/tmp/ccu8CYtI.s: Assembler messages:
/tmp/ccu8CYtI.s:109: Error: integer register expected in the extended/shifted
operand register at operand 3 -- `adds x1,xzr,#2'
[Bug libstdc++/96592] [10 Regression] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592 Patrick Palka changed: What|Removed |Added Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #8 from Patrick Palka --- I wonder if we should remove the workaround on trunk now that the underlying frontend issue PR96926 is fixed there.
Re: [PATCH, V2] Add conversions between _Float128 and Decimal.
On Sat, Mar 27, 2021 at 04:07:18PM +0100, Florian Weimer wrote:
> This issue is still present.
>
> What about the patch below?
>
> Thanks,
> Florian
>
> rs6000: Do not build _Float128/Decimal routines with --disable-decimal-float
>
> Fixes commit 781183595acba67a37c66f59a0c1d9b5fee7e248 ("Add conversions
> between _Float128 and Decimal.).
>
> libgcc/
> * config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
> point functions for $(decimal_float) only.
>
> diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
> index 6fb1a3d871b..b1f00accdf1 100644
> --- a/libgcc/config/rs6000/t-float128
> +++ b/libgcc/config/rs6000/t-float128
> @@ -37,8 +37,11 @@ ibm128_dec_funcs = _tf_to_sd _tf_to_dd _tf_to_td \
> # New functions for software emulation
> fp128_ppc_funcs = floattikf floatuntikf fixkfti fixunskfti \
> extendkftf2-sw trunctfkf2-sw \
> - sfp-exceptions _mulkc3 _divkc3 _powikf2 \
> - $(fp128_dec_funcs) $(fp128_decstr_funcs)
> + sfp-exceptions _mulkc3 _divkc3 _powikf2
> +
> +ifeq ($(decimal_float),yes)
> +fp128_ppc_funcs += $(fp128_dec_funcs) $(fp128_decstr_funcs)
> +endif
>
> fp128_ppc_src= $(addprefix
> $(srcdir)/config/rs6000/,$(addsuffix \
> .c,$(fp128_ppc_funcs)))
>
Here is an updated version of the patch that works with the change that I
checked in today. It works on a little endian power9 system with the stage1
builds for 3 compilers built with the 3 different long double types (IEEE, IBM,
64-bit). The bootstrap builds will be starting shortly.
Honor --disable-decimal-float on PowerPC Decimal/Float128 conversions
This patch fixes the problem that the Decimal <-> Float128 conversions
were built even if the user configured GCC with --disable-decimal-float.
libgcc/
2021-03-29 Florian Weimer
Michael Meissner
* config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
point functions for $(decimal_float) only.
---
libgcc/config/rs6000/t-float128 | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
index 8b089d4433c..d745f0d82e1 100644
--- a/libgcc/config/rs6000/t-float128
+++ b/libgcc/config/rs6000/t-float128
@@ -33,8 +33,11 @@ ibm128_dec_funcs = _tf_to_sd _tf_to_dd _tf_to_td \
# New functions for software emulation
fp128_ppc_funcs= floattikf floatuntikf fixkfti fixunskfti \
extendkftf2-sw trunctfkf2-sw \
- sfp-exceptions _mulkc3 _divkc3 _powikf2 \
- $(fp128_dec_funcs)
+ sfp-exceptions _mulkc3 _divkc3 _powikf2
+
+ifeq ($(decimal_float),yes)
+fp128_ppc_funcs+= $(fp128_dec_funcs)
+endif
fp128_ppc_src = $(addprefix $(srcdir)/config/rs6000/,$(addsuffix \
.c,$(fp128_ppc_funcs)))
--
2.22.0
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: Remove RMS from the GCC Steering Committee
Joseph, On Mar 29, 2021, Joseph Myers wrote: > This is based on the longstanding, > well-documented patterns of how he has misbehaved towards women, I have a great deal of respect for your attention to detail. I can hardly believe you would make such a claim without having actually looked into available evidence and cross-checked it. Yet your claim is either (a) misleading or (b) conflicting with findings by others who did so. (a) is a distinct possibility, since many people may legitimately claim RMS has been rude or harsh towards themselves, regardless of gender, and that can be exaggerated into misbehavior, and made misleading by phrasing it as if it was directed to any specific demographics. (b) would surprise me, given how extensively evidence has been looked into by myself and others. I request that, if you found anything that holds up to your high standards of evidence-checking, you submit it to the voting members of the FSF, so that we can look into it and take appropriate action. Thanks in advance, -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
Re: Remove RMS from the GCC Steering Committee
> Sent: Tuesday, March 30, 2021 at 1:30 PM > From: "Thomas Rodgers" > To: "Ian Lance Taylor" , "GCC Development" > , "Mark Wielaard" , "Nathan Sidwell" > > Subject: Re: Remove RMS from the GCC Steering Committee > > On 2021-03-29 17:39, Christopher Dimech via Gcc wrote: > > > > You might say that the fullness of Thomas Jefferson's legacy should be > > acknowledged, but he did a bit more with his life than own slaves, just > > as the Reverend Martin Luther King Jr. did more with his time on earth > > than cheat on his wife and Mohandas Gandhi did more than write racist > > tracts about black Africans. We remember those men, and celebrate > > them, > > for other things. > > This is irrelevant to the discussion as to whether RMS should be member > of GCC SC and whether or not the SC should make a public statement > regarding the matter, one way or the other. The individuals you cite are > all long dead, their entire history and legacy can be and is evaluated > as much in the context of the time in which they lived as it is in the > time in which we live now, with all the changes in social norms and > standards that that entails. Stallman will no doubt be judged in a > similar manner by history; founding the Free Software movement - good, > the impact of his abusive and misogynistic behavior which (at best) > belongs to another time - probably not so good. I followed an interview he had with Dr. Diane Hamilton, and one cannot say he was prejudiced against her. I have had my own problems with women in higher up positions that expect they can act to any level of irresponsibility as some men have done. I thus consider women simply as people. > The question is, in this time, right now, is that specific last bit > there. Is that the legacy that the GCC project and it's community of > contributors (and by contributors, I mean those that actively currently > do so) by continued association, wants for itself? > > I fully support the idea that the Steering Committee ought to make a > definitive statement in that regard, one way or the other. Active > contributors can then make whatever decisions they deem necessary based > on that information. >
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99424, which changed state. Bug 99424 Summary: [modules] ICE tree check: expected tree_vec, have error_mark in lookup_template_class_1, at cp/pt.c:9803 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99424 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/99424] [modules] ICE tree check: expected tree_vec, have error_mark in lookup_template_class_1, at cp/pt.c:9803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99424 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org Status|WAITING |RESOLVED --- Comment #3 from Marek Polacek --- Assuming fixed.
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-30 CC||mpolacek at gcc dot gnu.org
[Bug c++/99427] [modules] in system headers: non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99427 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2021-03-30 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug c++/99684] [modules] std::visit fails to compile when is used as header unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99684 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-30 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Reproduced. The error is: /home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:966:29: error: static assertion failed: std::visit requires the visitor to have the same return type for all alternatives of a variant 966 | static_assert(is_same_v<_Tp, decltype(__tmp_element)>, | ^~~
Re: Remove RMS from the GCC Steering Committee
> Sent: Tuesday, March 30, 2021 at 12:20 PM > From: "Joseph Myers" > To: "Mark Wielaard" > Cc: "GCC Development" , "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > On Sun, 28 Mar 2021, Mark Wielaard wrote: > > > He does indeed show up randomly claiming authority even if the GNU > > community has told him no. And it is important to say upfront he has > > no authority and that his attempts to cancel the work of hardworking > > GNU contributors is unwelcome. IMHO for the GCC community this means > > to be explicit he doesn't have any authority and he shouldn't be on > > the GCC steering committee. > > For example, consider the October 2019 discussion on libc-alpha of > removing the abort "joke" from the glibc manual. We rejected RMS's claims > of authority to say that the joke should be kept, or kept indefinitely > until various general points could be decided, and removed it from the > manual anyway without waiting for conclusions on all those general points. > > RMS only has authority over decisions taken about individual GNU packages > where the people developing those packages let him have that authority and > make or refrain from making changes based on what he says. We should not > give him such authority by treating his views as having some significance > not given to such views expressed by other people; changes he suggests can > be considered, and accepted or rejected, on their merits. And the abort > joke case illustrates that in fact he is not given such authority, when > package developers are confident to stand up to claims he makes of > authority, and provides an example that can speed up the rejection of any > such assertion of authority to micromanage things that might be made in > future. > > I agree with the conclusion of Nathan's original message, that RMS behaves > in a toxic way, it is harmful to have him listed as being in a leadership > role that might suggest what he does is acceptable within the project, and > he should not be on the SC. Insofar as Stallman is the foundation of all authority, He exercises that foundation because He is the founder of His own work. He is the foundation upon which all other authority stands or falls. We use the term foundation with respect to the imagery of a building - houses and commercial buildings are erected upon a foundation. To say that Stallman defended Epstein for comments he made about his former teacher are from an oceanic distance. The person who really had ties with Epstein was Bill Gates, who, instructed Bill Gates to donate $2 million to MIT. Stallman simply did not take into account the era of diminishing freedom (not only in the digital world). Nowadays, with the left (communist) thought police, who are always on the lookout for any subject to fire their cannons on, free speech could be gone. If an opinion expressed goes against the prevailing inquisition of the time, the subject and the person is in hot waters. Well, screw the inquisition. Seems like World War I has just begun and martial law has been declared, and this is reason enough, it seems, to expel the firebrand without much ado, so he can eventually end up in concentration camps in Egypt. > This is based on the longstanding, > well-documented patterns of how he has misbehaved towards women, *not* on > the opinions he has expressed on other subjects, *not* on his choices > regarding the use of language, *not* on his attempts to insist on language > being used in particular ways, and *not* on where or when he has chosen to > express such views. > > For the same reasons, I think it is harmful for him to be Chief GNUisance > (but as above, I think GNU packages should not give a Chief GNUisance > authority to micromanage decisions, beyond ensuring GNU packages follow > basic GNU free software principles and cooperate with each other and with > their development communities), harmful for him to be on the FSF board, > and harmful for him to be seen as leader of the free software movement. > (For the last point, I don't think the free software movement needs a > single leader; it needs many people advocating free software, and > discussing issues related to free software, from diverse perspectives. > RMS's ideas that form the foundation of the free software movement are > still of fundamental importance today. But other people can now build > better on those ideas in today's context.) > > RMS does not, in fact, contribute usefully to the SC. Any time he > suggests some feature for GCC, whether a good or a bad idea, that could be > done just as well on the public mailing list (which would be a better > place to find someone possibly interested in implementing a feature, and > to discuss a feature's merits, in any case) without being an SC member. > He's sufficiently far removed from toolchain development that he's not > good at making reasonable suggestions for toolchain changes in any case. > > We can consider individual
[Bug c++/99769] [modules] internal compiler error: in tree_node, at cp/module.cc:9105 when compile module partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99769
--- Comment #2 from Marek Polacek ---
We have __dynamic_cast without DECL_CONTEXT and so ICE in
9050 if (!DECL_CONTEXT (t))
9051 {
9052 /* There are a few cases of decls with no context. We'll write
9053 these by value, but first assert they are cases we expect.
*/
9054 gcc_checking_assert (ref == WK_normal);
9055 switch (TREE_CODE (t))
9056 {
9057 default: gcc_unreachable ();
Re: Remove RMS from the GCC Steering Committee
On 2021-03-29 17:39, Christopher Dimech via Gcc wrote: You might say that the fullness of Thomas Jefferson's legacy should be acknowledged, but he did a bit more with his life than own slaves, just as the Reverend Martin Luther King Jr. did more with his time on earth than cheat on his wife and Mohandas Gandhi did more than write racist tracts about black Africans. We remember those men, and celebrate them, for other things. This is irrelevant to the discussion as to whether RMS should be member of GCC SC and whether or not the SC should make a public statement regarding the matter, one way or the other. The individuals you cite are all long dead, their entire history and legacy can be and is evaluated as much in the context of the time in which they lived as it is in the time in which we live now, with all the changes in social norms and standards that that entails. Stallman will no doubt be judged in a similar manner by history; founding the Free Software movement - good, the impact of his abusive and misogynistic behavior which (at best) belongs to another time - probably not so good. The question is, in this time, right now, is that specific last bit there. Is that the legacy that the GCC project and it's community of contributors (and by contributors, I mean those that actively currently do so) by continued association, wants for itself? I fully support the idea that the Steering Committee ought to make a definitive statement in that regard, one way or the other. Active contributors can then make whatever decisions they deem necessary based on that information.
[Bug c++/99769] [modules] internal compiler error: in tree_node, at cp/module.cc:9105 when compile module partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99769 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-30 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Reproduced.
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99483, which changed state. Bug 99483 Summary: [modules] ICE tree check: expected tree_vec, have bind_expr in lookup_template_class_1, at cp/pt.c:9803 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99483 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/99483] [modules] ICE tree check: expected tree_vec, have bind_expr in lookup_template_class_1, at cp/pt.c:9803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99483 Marek Polacek changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99482, which changed state. Bug 99482 Summary: [modules] ICE tree check: expected tree_vec, have addr_expr in lookup_template_class_1, at cp/pt.c:9803 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99482 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/99482] [modules] ICE tree check: expected tree_vec, have addr_expr in lookup_template_class_1, at cp/pt.c:9803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99482 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from Marek Polacek --- Fixed then.
[Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99479
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-03-30
Ever confirmed|0 |1
CC||mpolacek at gcc dot gnu.org
--- Comment #7 from Marek Polacek ---
Reproduced. I see:
$ xg++ -std=c++20 -fmodules-ts -x c++-system-header future
In file included from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ios_base.h:41,
from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/ios:42,
from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/ostream:38,
from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/unique_ptr.h:42,
from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:59,
from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/shared_ptr.h:53,
from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/condition_variable:43,
from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/future:39:
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:163:23:
internal compiler error: in install_entity, at cp/module.cc:7465
163 | locale(const std::string& __s) : locale(__s.c_str()) { }
| ^~
0xc09df4 trees_in::install_entity(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:7465
0xc0c78e trees_in::decl_value()
/home/mpolacek/src/gcc/gcc/cp/module.cc:7977
0xc124b7 trees_in::tree_node(bool)
/home/mpolacek/src/gcc/gcc/cp/module.cc:9151
0xc2bdd1 module_state::read_cluster(unsigned int)
/home/mpolacek/src/gcc/gcc/cp/module.cc:14791
0xc35172 module_state::load_section(unsigned int, binding_slot*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:18062
0xc37490 module_state::lazy_load(unsigned int, binding_slot*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:18720
0xc149c3 trees_in::tree_node(bool)
/home/mpolacek/src/gcc/gcc/cp/module.cc:9662
0xc07feb trees_in::lang_decl_vals(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:6867
0xc086df trees_in::lang_vals(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:7029
0xc0882e trees_in::tree_node_vals(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:7060
0xc0c587 trees_in::decl_value()
/home/mpolacek/src/gcc/gcc/cp/module.cc:7939
0xc124b7 trees_in::tree_node(bool)
/home/mpolacek/src/gcc/gcc/cp/module.cc:9151
0xbffa8e trees_in::chained_decls()
/home/mpolacek/src/gcc/gcc/cp/module.cc:4839
0xc068dc trees_in::core_vals(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:6541
0xc08812 trees_in::tree_node_vals(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:7058
0xc118d4 trees_in::tree_value()
/home/mpolacek/src/gcc/gcc/cp/module.cc:8928
0xc1249f trees_in::tree_node(bool)
/home/mpolacek/src/gcc/gcc/cp/module.cc:9146
0xc068fb trees_in::core_vals(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:6543
0xc08812 trees_in::tree_node_vals(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/module.cc:7058
0xc118d4 trees_in::tree_value()
/home/mpolacek/src/gcc/gcc/cp/module.cc:8928
[Bug c++/99735] [modules] in system headers: non-template type ‘rebind_alloc’ used as a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99735 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I can't reproduce this, can you?
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99734, which changed state. Bug 99734 Summary: [modules] ICE in most_specialized_instantiation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99734 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/99734] [modules] ICE in most_specialized_instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99734 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- All 4 work for me now. $ xg++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept -c $ xg++ -std=c++20 -fmodules-ts -x c++-system-header filesystem -c $ xg++ -std=c++20 -fmodules-ts -x c++-system-header future -c $ xg++ -std=c++20 -fmodules-ts -x c++-system-header system_error -c
[Bug c++/99573] ICE in module: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99573 Marek Polacek changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #2 from Marek Polacek --- Original test: export module A:base; #include
[Bug c++/99573] ICE in module: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99573
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code
Last reconfirmed||2021-03-30
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
Confirmed. I hit this with another, simplified example:
// x.h
namespace std {
enum class align_val_t: decltype(sizeof(int)) {};
}
// z.cc
export module A:base;
#include "x.h"
$ ./cc1plus -quiet z.cc -fmodules-ts
In file included from z.cc:2:
x.h:2:27: error: cannot define ‘enum class std::align_val_t’ in different
module
2 | enum class align_val_t: decltype(sizeof(int)) {};
| ^
: note: declared here
x.h:2:27: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15699
0x1a18873 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/mpolacek/src/gcc/gcc/tree.c:9866
0xa1e03c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/mpolacek/src/gcc/gcc/tree.h:3476
0xb4d2e1 start_enum(tree_node*, tree_node*, tree_node*, tree_node*, bool,
bool*)
/home/mpolacek/src/gcc/gcc/cp/decl.c:15699
0xc9a49d cp_parser_enum_specifier
/home/mpolacek/src/gcc/gcc/cp/parser.c:19986
0xc9725b cp_parser_type_specifier
/home/mpolacek/src/gcc/gcc/cp/parser.c:18412
0xc91963 cp_parser_decl_specifier_seq
/home/mpolacek/src/gcc/gcc/cp/parser.c:15062
0xc90054 cp_parser_simple_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:14319
0xc8ffdc cp_parser_block_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:14266
0xc8fca8 cp_parser_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:14137
0xc8fd9d cp_parser_toplevel_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:14166
0xc8f53e cp_parser_declaration_seq_opt
/home/mpolacek/src/gcc/gcc/cp/parser.c:13954
0xc9b41c cp_parser_namespace_body
/home/mpolacek/src/gcc/gcc/cp/parser.c:20454
0xc9b3c5 cp_parser_namespace_definition
/home/mpolacek/src/gcc/gcc/cp/parser.c:20432
0xc8fb8d cp_parser_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:14117
0xc8fd9d cp_parser_toplevel_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:14166
0xc7b6e5 cp_parser_translation_unit
/home/mpolacek/src/gcc/gcc/cp/parser.c:4942
0xcde6f6 c_parse_file()
/home/mpolacek/src/gcc/gcc/cp/parser.c:45257
0xea11b4 c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.c:1218
Re: Remove RMS from the GCC Steering Committee
> Sent: Tuesday, March 30, 2021 at 12:09 PM > From: "Ian Lance Taylor" > To: "Christopher Dimech" > Cc: "Soul Studios" , "GCC Development" > , "Mark Wielaard" , "Nathan Sidwell" > > Subject: Re: Remove RMS from the GCC Steering Committee > > On Mon, Mar 29, 2021 at 4:33 PM Christopher Dimech via Gcc > wrote: > > > > Here is something close to the fundamental issue: Believing in private life, > > that people are entitled to their own associations and opinions (even bad > > ones!), > > and entitled to make their own mistakes, too — and that, barring some direct > > connection to work life or extraordinary circumstance, that none of this is > > the concern of the little platoons of finks lurking in the community, > > particularly when driven by facebook lackeys muzzling everyday journalists > > who go against the grain. We see this not only here but also to medical > > information dealing with coronavirus and vaccines. > > Please work to avoid using terms like "finks" or "lackeys" when > describing members of the GCC community. Please be respectful of > other people's opinions. Thanks. > > The question here is not whether RMS is permitted to contribute to > GCC. I have not seen anybody arguing against that. The question is > whether the GCC community should put him in a declared leadership > position. For a leadership position, which serves as an example for > the community and to some extent demonstrates the values shared by the > community, I think it is reasonable that there is a decreased > expectation of privacy. It is an unrealistic expectation. I could understand such attitudes towards Harvey Weinstein and the like. But now the scalp-hunting has started to target ordinary and often obscure people, and the offenses in question have nothing to do with bigotry — it is simply having the unfashionable view of a public controversy, or being somehow associated, however lightly with that controversy. You might say that the fullness of Thomas Jefferson’s legacy should be acknowledged, but he did a bit more with his life than own slaves, just as the Reverend Martin Luther King Jr. did more with his time on earth than cheat on his wife and Mohandas Gandhi did more than write racist tracts about black Africans. We remember those men, and celebrate them, for other things. > Ian >
[Bug c++/99821] New: __attribute__((packed)) ignored on struct with a field of post-C++11-POD and non-(some_old)-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99821
Bug ID: 99821
Summary: __attribute__((packed)) ignored on struct with a field
of post-C++11-POD and non-(some_old)-POD
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yumeyao at gmail dot com
Target Milestone: ---
This is probably not an issue, but something could be done to improve the
warning message.
Consider the following code snippet(https://godbolt.org/z/n7458hcos):
struct empty {};
struct B : empty { // B is still a POD
int x;
};
struct D {
char c;
B b; // ignoring packed attribute because of unpacked non-POD field 'B
D::b'
} __attribute__((packed));
bool is_pod() { return __is_pod(B); } // on gcc5 and below it's false
int sizeofD() { return sizeof(D); }
struct B is considered as POD on C++11 onwards, but gcc gives warning like
this:
warning: ignoring packed attribute because of unpacked non-POD field 'B D::b'
and as a consequence, struct D is not packed, with sizeof(D) == 8.
When I asked for account creation, @Jonathan Wakely replied me the term
"non-POD" shall refer to "POD for the purposes of layout" as defined in the
ABI. I've looked into the document and found this under the corresponding
section:
There have been multiple published revisions to the ISO C++ standard,
and each one has included a different definition of POD. To ensure
interoperation of code compiled according to different revisions of the
standard, it is necessary to settle on a single definition for a platform.
A platform vendor may choose to follow a different revision of the standard,
but by default, the definition of POD under this ABI is the definition from
the 2003 revision (TC1).
So I guess this might not be an issue, but I think there is something worth
discussing:
1. We can improve the warning message, to change the word 'non-POD' to
something like 'non-POD(c++03)'. As inferred from the description above and
current behavior, gcc is choosing POD definition in C++03 as the ABI-level "POD
for the purposes of layout" .
2. As also shown in the code above, gcc6 and above reports __is_pod(B) == true,
and gcc5 and below reports __is_pod(B) == false. While I am aware that this is
the implementation detail used by std::is_pod in therefore
__is_pod() reflects the C++ standard specified in gcc command line, I think it
might be helpful to provide some intrinsic to tell something about the ABI
level. A possible extension might be __is_pod(type_name, cxx_std_ver =
"current"), whereas cxx_std_ver can be specified with "c++03" to get that.
I do think this issue is linked to #60972 as the class A in that issue is
obviously non-POD on c++03.
Re: Remove RMS from the GCC Steering Committee
On Sun, 28 Mar 2021, Mark Wielaard wrote: > He does indeed show up randomly claiming authority even if the GNU > community has told him no. And it is important to say upfront he has > no authority and that his attempts to cancel the work of hardworking > GNU contributors is unwelcome. IMHO for the GCC community this means > to be explicit he doesn't have any authority and he shouldn't be on > the GCC steering committee. For example, consider the October 2019 discussion on libc-alpha of removing the abort "joke" from the glibc manual. We rejected RMS's claims of authority to say that the joke should be kept, or kept indefinitely until various general points could be decided, and removed it from the manual anyway without waiting for conclusions on all those general points. RMS only has authority over decisions taken about individual GNU packages where the people developing those packages let him have that authority and make or refrain from making changes based on what he says. We should not give him such authority by treating his views as having some significance not given to such views expressed by other people; changes he suggests can be considered, and accepted or rejected, on their merits. And the abort joke case illustrates that in fact he is not given such authority, when package developers are confident to stand up to claims he makes of authority, and provides an example that can speed up the rejection of any such assertion of authority to micromanage things that might be made in future. I agree with the conclusion of Nathan's original message, that RMS behaves in a toxic way, it is harmful to have him listed as being in a leadership role that might suggest what he does is acceptable within the project, and he should not be on the SC. This is based on the longstanding, well-documented patterns of how he has misbehaved towards women, *not* on the opinions he has expressed on other subjects, *not* on his choices regarding the use of language, *not* on his attempts to insist on language being used in particular ways, and *not* on where or when he has chosen to express such views. For the same reasons, I think it is harmful for him to be Chief GNUisance (but as above, I think GNU packages should not give a Chief GNUisance authority to micromanage decisions, beyond ensuring GNU packages follow basic GNU free software principles and cooperate with each other and with their development communities), harmful for him to be on the FSF board, and harmful for him to be seen as leader of the free software movement. (For the last point, I don't think the free software movement needs a single leader; it needs many people advocating free software, and discussing issues related to free software, from diverse perspectives. RMS's ideas that form the foundation of the free software movement are still of fundamental importance today. But other people can now build better on those ideas in today's context.) RMS does not, in fact, contribute usefully to the SC. Any time he suggests some feature for GCC, whether a good or a bad idea, that could be done just as well on the public mailing list (which would be a better place to find someone possibly interested in implementing a feature, and to discuss a feature's merits, in any case) without being an SC member. He's sufficiently far removed from toolchain development that he's not good at making reasonable suggestions for toolchain changes in any case. We can consider individual proposals or patches from anyone on their merits. We can have leaders who are accepted as leaders because contributors can see their relevant expertise that gives them legitimacy as leaders, and can see a good basis for decisions they make as leaders. But longstanding patterns of bad conduct by a leader, even when formally unrelated to the project, can reach the point where considering that person a leader is harmful to the project. I think the ways RMS has behaved have long since reached the point where it is harmful for him to be considered a leader for GCC or GNU, and that's sufficient to stop considering him a leader (even if he were sufficiently involved to be able to contribute much more usefully on a technical level). -- Joseph S. Myers jos...@codesourcery.com
Re: Remove RMS from the GCC Steering Committee
On Mon, Mar 29, 2021 at 4:33 PM Christopher Dimech via Gcc wrote: > > Here is something close to the fundamental issue: Believing in private life, > that people are entitled to their own associations and opinions (even bad > ones!), > and entitled to make their own mistakes, too — and that, barring some direct > connection to work life or extraordinary circumstance, that none of this is > the concern of the little platoons of finks lurking in the community, > particularly when driven by facebook lackeys muzzling everyday journalists > who go against the grain. We see this not only here but also to medical > information dealing with coronavirus and vaccines. Please work to avoid using terms like "finks" or "lackeys" when describing members of the GCC community. Please be respectful of other people's opinions. Thanks. The question here is not whether RMS is permitted to contribute to GCC. I have not seen anybody arguing against that. The question is whether the GCC community should put him in a declared leadership position. For a leadership position, which serves as an example for the community and to some extent demonstrates the values shared by the community, I think it is reasonable that there is a decreased expectation of privacy. Ian
Re: Remove RMS from the GCC Steering Committee
Here is something close to the fundamental issue: Believing in private life, that people are entitled to their own associations and opinions (even bad ones!), and entitled to make their own mistakes, too — and that, barring some direct connection to work life or extraordinary circumstance, that none of this is the concern of the little platoons of finks lurking in the community, particularly when driven by facebook lackeys muzzling everyday journalists who go against the grain. We see this not only here but also to medical information dealing with coronavirus and vaccines. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Tuesday, March 30, 2021 at 9:41 AM > From: "Soul Studios" > To: "Richard Kenner" > Cc: gcc@gcc.gnu.org, m...@klomp.org, nat...@acm.org > Subject: Re: Remove RMS from the GCC Steering Committee > > > On 30/03/2021 1:18 am, Richard Kenner wrote: > >> I think I will leave this discussion up to those who have more > >> familiarity with the guy than I do. There's no doubt that some of the > >> stuff Stallman has written creeps me the hell out, and I think it was > >> more the tone of the OP I objected to. > > > > I mostly want to stay out of this and will leave much of this discussion to > > others (though I have met RMS personally on a number of occaisions), but I > > want to mostly say that I agree with Jeff that it's important that this > > discussion stay civil. > > > > I believe that to a large extent, the discussion here is reflective of a > > much larger discussion in society of to what extent, if at all, an entity > > associated with an person must or should take action based on things that > > that person does while not associated with that entity. > > It's worth noting that when RMS was kicked from FSF, there was a > 2k-strong petition in favour, and a 3.5k-strong petition against. So > clearly there is a discussion to be had, but as long as the left-wing > (through self-rightiousness and threats of exclusion/withdrawal) and the > right-wing (through belligerance and abuse/hostility) are trying > actively to shut down discussion, that will not take place. >
[Bug middle-end/63518] missing Wuninitialized warning independent of order of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63518
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2019-02-03 00:00:00 |2021-3-29
Known to fail||10.2.0, 11.0, 4.8.4, 4.9.4,
||5.5.0, 6.4.0, 7.2.0, 8.3.0,
||9.1.0
--- Comment #4 from Martin Sebor ---
This is a similar problem to (although not quite the same as) the one we have
been discussing in pr60488. I have changed the test case to C to shorten the
IL. Here's the C test case and the IL from a GCC instrumented to print it just
as the pass runs. At each point of a variable's use, the warning looks for
prior statements that might set its value. If it finds one, it doesn't
trigger. In foo() the first such prior statement is the call to
setTimeout(). In bar(), there is no such prior statement, and so there the
warning does trigger.
I don't see how to fix this except by running the warning in the front end or
just before Gimplification when all the arguments to the wait() call statement
are still in the IL. Once the code is Gimplified the arguments are already
broken out of the call. This isn't an option today for all the reasons that
have been discussed over the years but might perhaps be doable if/when the
__builtin_warning() idea comes to fruition. With it in place, the warning
could be scheduled to be issued early on, false positives weeded out by running
the optimizers as usual, and then issued if the __builtin_warning() call was
still left in the IL. This would have to be done under the control of the same
predicate analysis as the one in tree-ssa-uninit.c today (which is why I'm
factoring it out into a standalone reusable component).
$ cat x.c && gcc -S -Wall x.c
void wait (int, _Bool);
void wait2 (_Bool, int);
_Bool setTimeout (int*);
void foo (void)
{
int t;
wait (t, setTimeout ());
}
void bar (void)
{
int t;
wait2 (setTimeout (), t);
}
void foo ()
{
int t;
_Bool _1;
int _2;
int t.0_3;
:
# .MEM_5 = VDEF <.MEM_4(D)>
_1 = setTimeout (); <<< address of t escapes first
_2 = (int) _1;
# VUSE <.MEM_5>
t.0_3 = t;<<< missing warning
# .MEM_6 = VDEF <.MEM_5>
wait (t.0_3, _2);
# .MEM_7 = VDEF <.MEM_6>
t ={v} {CLOBBER};
# VUSE <.MEM_7>
return;
}
void bar ()
{
int t;
int t.1_1;
_Bool _2;
int _3;
:
# VUSE <.MEM_4(D)>
t.1_1 = t;<<< -Wuninitialized
# .MEM_5 = VDEF <.MEM_4(D)>
_2 = setTimeout (); <<< address of t escapes second
_3 = (int) _2;
# .MEM_6 = VDEF <.MEM_5>
wait2 (_3, t.1_1);
# .MEM_7 = VDEF <.MEM_6>
t ={v} {CLOBBER};
# VUSE <.MEM_7>
return;
}
_1 = setTimeout (); <<< address of t escapes
_2 = (int) _1;
t.0_3 = t; <<< missing warning
wait (t.0_3, _2);
t ={v} {CLOBBER};
return;
}
void bar ()
{
int t;
int t.1_1;
_Bool _2;
int _3;
:
t.1_1 = t; <<< -Wuninitialized
_2 = setTimeout (); <<< address of t escapes
_3 = (int) _2;
wait2 (_3, t.1_1);
t ={v} {CLOBBER};
return;
}
x.c: In function ‘bar’:
x.c:15:3: warning: ‘t’ is used uninitialized [-Wuninitialized]
15 | wait2 (setTimeout (), t);
| ^~
x.c:14:7: note: ‘t’ declared here
14 | int t;
| ^
Re: [PATCH] rs6000: Enable 32bit variable vec_insert [PR99718]
Hi! On Fri, Mar 26, 2021 at 10:26:57PM -0500, Xionghu Luo wrote: > 32bit and P7 VSX could also benefit a lot from the variable vec_insert > implementation with shift/insert/shift back method. > * config/rs6000/altivec.md (altivec_lvsl_reg): Change to ... > (altivec_lvsl_reg_): ... this. > (altivec_lvsr_reg): Change to ... > (altivec_lvsr_reg_): ... this. This could use parameterised names. I'll handle that in a follow-up. > * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): > Enable 32bit variable vec_insert for all TARGET_VSX. I don't see why this is only for 32 bit? It looks correct though. > * config/rs6000/vector.md: Use vec_set_index_operand. That should be * config/rs6000/vector.md (vec_set): Use vec_set_index_operand. > -(define_insn "altivec_lvsl_reg" > +(define_insn "altivec_lvsl_reg_" >[(set (match_operand:V16QI 0 "altivec_register_operand" "=v") > (unspec:V16QI > - [(match_operand:DI 1 "gpc_reg_operand" "b")] > + [(match_operand:SDI 1 "gpc_reg_operand" "b")] > UNSPEC_LVSL_REG))] SDI isn't correct: you do not want DImode here with -mno-powerpc64. Instead, you want :GPR. > +;; Return true if TARGET_VSX for vec_set with variable index. > +(define_predicate "vec_set_index_operand" > + (if_then_else (match_test "TARGET_VSX") > + (match_operand 0 "reg_or_cint_operand") > + (match_operand 0 "const_int_operand"))) That comment isn't so great. I'll make it ;; Return 1 if this operand is valid as the index for vec_set. Btw, add new code at an appropriate spot, not at the end of file. You'll get fewer patch conflicts, as happy by-effect. > + rtx (*gen_ashl)(rtx, rtx, rtx); > + rtx (*gen_lvsl)(rtx, rtx); > + rtx (*gen_lvsr)(rtx, rtx); All this stuff will be unneeded with parameterised names :-) I'll fix up the nits and commit it for you, as we discussed. Thank you! Segher
[Bug ada/99802] [11 regression] assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- Thanks for reporting the problem.
[Ada] Fix PR ada/99802
This is a regression present on the mainline: the compiler fails to assign an aggregate to a full-access component (i.e. Atomic or VFA) as a whole if the type of the component is not full access itself. Tested on x86-64/Linux, applied on the mainline. 2021-03-29 Eric Botcazou PR ada/99802 * freeze.adb (Is_Full_Access_Aggregate): Call Is_Full_Access_Object on the name of an N_Assignment_Statement to spot full access. -- Eric Botcazoudiff --git a/gcc/ada/freeze.adb b/gcc/ada/freeze.adb index 8dc8a222396..da14af9b8bd 100644 --- a/gcc/ada/freeze.adb +++ b/gcc/ada/freeze.adb @@ -1754,8 +1754,7 @@ package body Freeze is Typ := Etype (Name (Par)); if not Is_Full_Access (Typ) - and then not (Is_Entity_Name (Name (Par)) - and then Is_Full_Access (Entity (Name (Par + and then not Is_Full_Access_Object (Name (Par)) then return False; end if;
[Bug ada/99802] [11 regression] assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 --- Comment #3 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:471babd88668dbe4f9ff4dba6d2036ecef09653b commit r11-7900-g471babd88668dbe4f9ff4dba6d2036ecef09653b Author: Eric Botcazou Date: Tue Mar 30 00:41:46 2021 +0200 Fix wrong assignment of aggregate to full-access component This is a regression present on the mainline: the compiler (front-end) fails to assign an aggregate to a full-access component (i.e. Atomic or VFA) as a whole if the type of the component is not full access itself. gcc/ada/ PR ada/99802 * freeze.adb (Is_Full_Access_Aggregate): Call Is_Full_Access_Object on the name of an N_Assignment_Statement to spot full access.
[Bug c++/79070] Unhelpful error message for ambiguous type in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79070
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment #3 from Barry Revzin ---
Here are a few more cases, reduced from a larger example that took me a very
long time to understand. I'm adding as comments the compile error emitted for
each invalid use:
namespace N {
template struct Something { };
template concept C = true;
template struct X { };
}
using namespace N;
template struct Something { };
// parse error in template argument list
static_assert(C>);
// template argument 1 is invalid
X> x;
// reference to Something is ambiguous
using T = Something;
In the last case, the compiler error is super clear and it is obvious what the
error is. In the other two, not so much.
[Bug fortran/94446] Bogus "type mismatch" with TYPE(c_ptr) and sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94446
Andrew Benson changed:
What|Removed |Added
CC||abensonca at gmail dot com
--- Comment #2 from Andrew Benson ---
After some more investigation this seems to be related to the following in
target-memory.c in function gfc_simplify_sizeof():
case BT_DERIVED:
case BT_CLASS:
case BT_VOID:
case BT_ASSUMED:
case BT_PROCEDURE:
{
/* Determine type size without clobbering the typespec for ISO C
binding types. */
gfc_typespec ts;
HOST_WIDE_INT size;
ts = e->ts;
type = gfc_typenode_for_spec ();
size = int_size_in_bytes (type);
gcc_assert (size >= 0);
*siz = size;
}
return true;
The call to gfc_typenode_for_spec() seems to cause the problem. This eventually
leads to reaching the following point:
#0 gfc_typenode_for_spec(gfc_typespec*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:1177
#1 0x00962502 in gfc_sym_type(gfc_symbol*) () at
../../gcc-git/gcc/fortran/trans-types.c:2247
#2 0x00960858 in gfc_get_function_type(gfc_symbol*,
gfc_actual_arglist*) () at ../../gcc-git/gcc/fortran/trans-types.c:3060
#3 0x009611ed in gfc_get_ppc_type (c=) at
../../gcc-git/gcc/fortran/trans-types.c:2430
#4 0x00961b50 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2712
#5 0x00961ae4 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2670
#6 0x00961ae4 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2670
#7 0x00961ae4 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2670
#8 0x00962115 in gfc_typenode_for_spec(gfc_typespec*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:1166
#9 0x008bec61 in gfc_element_size(gfc_expr*, unsigned long*) () at
../../gcc-git/gcc/fortran/target-memory.c:130
#10 0x008bee33 in gfc_target_expr_size(gfc_expr*, unsigned long*) () at
../../gcc-git/gcc/fortran/target-memory.c:166
#11 0x008af4f3 in gfc_simplify_sizeof (x=0x29fd3c0) at
../../gcc-git/gcc/fortran/simplify.c:7492
#12 0x00829eea in do_simplify (specific=specific@entry=0x775bcc10,
e=e@entry=0x29fd5a0) at ../../gcc-git/gcc/fortran/intrinsic.c:4620
#13 0x008350bc in gfc_intrinsic_func_interface(gfc_expr*, int) () at
../../gcc-git/gcc/fortran/intrinsic.c:5013
#14 0x0088ec57 in resolve_unknown_f (expr=0x29fd5a0) at
../../gcc-git/gcc/fortran/resolve.c:2918
which is this code:
/* If we're dealing with either C_PTR or C_FUNPTR, we modified the
type and kind to fit a (void *) and the basetype returned was a
ptr_type_node. We need to pass up this new information to the
symbol that was declared of type C_PTR or C_FUNPTR. */
if (spec->u.derived->ts.f90_type == BT_VOID)
{
spec->type = BT_INTEGER;
spec->kind = gfc_index_integer_kind;
spec->f90_type = BT_VOID;
spec->is_c_interop = 1; /* Mark as escaping later. */
}
My guess is that this is exactly the "clobbering" that is trying to be avoided
in gfc_simplify_sizeof(). As far as I can understand this is occurring because
the variable "gsf" in the test case is an argument to a function, so its
typespec is being retrieved and modified here.
I don't have the understanding to know how to fix this though.
The "clobbering" fix was implemented (according to git blame) in this patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=48b155b991003487a50ac171ba5ca7c3409ad417
corresponding to PR50004.
[Bug tree-optimization/61869] Spurious uninitialized warning (lim1 pass, pretty-printed internal var)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61869 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:af739c8797d4cdf550366d0ef48136e0073df5c9 commit r11-7899-gaf739c8797d4cdf550366d0ef48136e0073df5c9 Author: Martin Sebor Date: Mon Mar 29 15:58:01 2021 -0600 PR tree-optimization/61869 - Spurious uninitialized warning gcc/testsuite/ChangeLog: PR tree-optimization/61869 * gcc.dg/uninit-pr61869.c: New test.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 61869, which changed state. Bug 61869 Summary: Spurious uninitialized warning (lim1 pass, pretty-printed internal var) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61869 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/61869] Spurious uninitialized warning (lim1 pass, pretty-printed internal var)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61869 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Known to work||5.3.0, 6.3.0 Target Milestone|--- |7.0 Resolution|--- |FIXED CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Fixed in r245840.
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #16 from Jan Hubicka --- I was trying to reproduce some kind of ICE for a while, trying to also rebuild with ggc forced on every ggc_collect call, but no luck. I wonder if you happen to know specific gcc regression that was failing and if it was patched or not...
Re: Remove RMS from the GCC Steering Committee
On 30/03/2021 1:18 am, Richard Kenner wrote: I think I will leave this discussion up to those who have more familiarity with the guy than I do. There's no doubt that some of the stuff Stallman has written creeps me the hell out, and I think it was more the tone of the OP I objected to. I mostly want to stay out of this and will leave much of this discussion to others (though I have met RMS personally on a number of occaisions), but I want to mostly say that I agree with Jeff that it's important that this discussion stay civil. I believe that to a large extent, the discussion here is reflective of a much larger discussion in society of to what extent, if at all, an entity associated with an person must or should take action based on things that that person does while not associated with that entity. It's worth noting that when RMS was kicked from FSF, there was a 2k-strong petition in favour, and a 3.5k-strong petition against. So clearly there is a discussion to be had, but as long as the left-wing (through self-rightiousness and threats of exclusion/withdrawal) and the right-wing (through belligerance and abuse/hostility) are trying actively to shut down discussion, that will not take place.
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > Fixed for gcc-11 only for now. And 10.3 now too.
[Bug c++/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 --- Comment #5 from Jonathan Wakely --- And for 10.3 as well.
[Bug libstdc++/99537] Wrong memory_order used in stop_token ref-counting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99537 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |10.3 --- Comment #4 from Jonathan Wakely --- Fixed for 10.3
[Bug middle-end/61677] False positive with -Wmaybe-uninitialized (predicate analysis, VRP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61677 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- The false positive for the reduced test case from comment #4 was fixed by r220696. r11-7898 adds it to the testsuite. The unreduced test case from attachment 33055 still warns with GCC 11: $ gcc -O2 -S -Wall pr61677-c0.c In file included from scripts/kconfig/zconf.tab.c:2537: scripts/kconfig/menu.c: In function ‘get_symbol_str’: scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized] In file included from scripts/kconfig/zconf.tab.c:2537: scripts/kconfig/menu.c:551:19: note: ‘jump’ was declared here
[Bug middle-end/61677] False positive with -Wmaybe-uninitialized (predicate analysis, VRP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61677 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:fecc835e216f537d3e7edb833cb3769489b983bb commit r11-7898-gfecc835e216f537d3e7edb833cb3769489b983bb Author: Martin Sebor Date: Mon Mar 29 15:21:32 2021 -0600 PR tree-optimization/61677 - False positive with -Wmaybe-uninitialized gcc/testsuite/ChangeLog: PR tree-optimization/61677 * gcc.dg/uninit-pr61677.c: New test.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 61428, which changed state. Bug 61428 Summary: wrong "maybe-uninitialized" (jump threading? predicate analysis?) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61428 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 Bug 19794 depends on bug 61428, which changed state. Bug 61428 Summary: wrong "maybe-uninitialized" (jump threading? predicate analysis?) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61428 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/61428] wrong "maybe-uninitialized" (jump threading? predicate analysis?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61428 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |8.0 Status|NEW |RESOLVED Known to fail||5.5.0, 6.4.0, 7.2.0 CC||msebor at gcc dot gnu.org --- Comment #6 from Martin Sebor --- Fixed by r256320.
Re: [PATCH] Complete __gnu_debug::basic_string
On 25/03/21 4:29 pm, Jonathan Wakely wrote:
Oh, it's the same generate(sz) bug as you already found. But I've
found other bugs, e.g. with GLIBCXX_SEED_TEST_RNG=1908970375).
I think we should also add a check for non-empty containers to those
test functions, and ensure we don't try to erase from empty
containers (see attached).
I had a look at this patch and on my side I was more thinking about
avoiding empty containers in the first place.
What do you think ?
François
diff --git a/libstdc++-v3/testsuite/util/exception/safety.h b/libstdc++-v3/testsuite/util/exception/safety.h
index 54449d2f7bb..6940f2f765d 100644
--- a/libstdc++-v3/testsuite/util/exception/safety.h
+++ b/libstdc++-v3/testsuite/util/exception/safety.h
@@ -55,14 +55,14 @@ namespace __gnu_test
// Return randomly generated integer on range [0, __max_size].
static size_type
-generate(size_type __max_size)
+generate(size_type __max_size, size_type __min_size = 0)
{
using param_type = typename distribution_type::param_type;
// Make the engine and distribution static...
static engine_type engine = get_engine();
static distribution_type distribution;
- return distribution(engine, param_type{0, __max_size});
+ return distribution(engine, param_type{__min_size, __max_size});
}
// Given an instantiating type, return a unique value.
@@ -198,7 +198,8 @@ namespace __gnu_test
// Size test container.
const size_type max_elements = 100;
- size_type n = generate(max_elements);
+ const size_type min_elements = 10;
+ size_type n = generate(max_elements, min_elements);
// Construct new container.
make_container_n made(n);
[Bug fortran/99817] [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P4 Last reconfirmed||2021-03-29 Status|UNCONFIRMED |NEW --- Comment #2 from Dominique d'Humieres --- Confirmed.
[Bug libstdc++/99077] [9 Regression] Cannot build libstdc++ with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077 Jonathan Wakely changed: What|Removed |Added Summary|[9/10 Regression] Cannot|[9 Regression] Cannot build |build libstdc++ with|libstdc++ with -fno-rtti |-fno-rtti | --- Comment #6 from Jonathan Wakely --- Fixed for 10.3 as well.
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #19 from Jonathan Wakely --- Re-fixed for 10.3 as well
[Bug target/99820] aarch64: ICE (segfault) in aarch64_analyze_loop_vinfo with -moverride=tune=use_new_vector_costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99820 Alex Coplan changed: What|Removed |Added Known to fail||11.0 Target Milestone|--- |11.0 Keywords||ice-on-valid-code CC||rsandifo at gcc dot gnu.org Target||aarch64
[Bug libstdc++/95765] std::vector should be built without warnings with -Wconversion and/or -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95765 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e5431137ca9787f6d8747c1d1c3f85f7b10fde35 commit r10-9612-ge5431137ca9787f6d8747c1d1c3f85f7b10fde35 Author: Jonathan Wakely Date: Fri Jun 19 18:15:15 2020 +0100 libstdc++: Fix some -Wsystem-headers warnings (PR 95765) PR libstdc++/95765 * include/bits/stl_algobase.h (__size_to_integer(float)) (__size_to_integer(double), __size_to_integer(long double)) (__size_to_integer(__float128)): Cast return type explicitly. (cherry picked from commit 5b6215083bd6a3e10dd142e1c5d4fab011d6f074)
[Bug libstdc++/98319] LFTS headers give errors if included as C++11 or C++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98319 --- Comment #4 from Jonathan Wakely --- And for 10.3 as well.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7dea2f84f26d454331d34b8536c261b6e96205d7 commit r10-9608-g7dea2f84f26d454331d34b8536c261b6e96205d7 Author: Jonathan Wakely Date: Thu Aug 27 22:36:03 2020 +0100 libstdc++: Make std::chrono::duration use reduced ratio for period This implements the changes from P0548 "common_type and duration". That was a change for C++17, but as it corrects some issues introduced by DRs I'm also treating it as a DR and changing it for all modes from C++11 up. The main change is that duration::period no longer denotes P, but rather P::type, the reduced ratio. The unary operator+ and operator- members of duration should now return a duration using that reduced ratio. The requirement that common_type::type is the same type as common_type::type (rather than simply T) was already implemented for PR 89102. The standard says that duration::operator+() and duration::operator-() should return common_type_t, but that seems unnecessarily expensive to compute. This uses duration, period> which is the same type, so we avoid a common_type specialization. As an optimization, this also adds partial specializations of common_type for two durations of the same type, a single duration, two time_points of the same type, and a single time_point. These specializations avoid instantiating other specializations of common_type and one or both of __duration_common_type or __timepoint_common_type for the cases where the answer is trivial to obtain. libstdc++-v3/ChangeLog: * include/std/chrono (__duration_common_type): Ensure the reduced ratio is used. Remove unused partial specialization using __failure_type. (common_type): Pass reduced ratios to __duration_common_type. Add partial specializations for simple cases involving a single duration or time_point type. (duration::period): Use reduced ratio. (duration::operator+(), duration::operator-()): Return duration type using the reduced ratio. * testsuite/20_util/duration/requirements/typedefs_neg2.cc: Adjust expected errors. * testsuite/20_util/duration/requirements/reduced_period.cc: New test. (cherry picked from commit 82030d51017323c5706d58d8c8626324ece007e4)
[Bug libstdc++/96592] [10 Regression] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:202e96058031b8ac2edc8fdab2faab06b988a253 commit r10-9607-g202e96058031b8ac2edc8fdab2faab06b988a253 Author: Jonathan Wakely Date: Thu Sep 3 16:26:16 2020 +0100 libstdc++: Add workaround for weird std::tuple error [PR 96592] This "fix" makes no sense, but it avoids an error from G++ about std::is_constructible being incomplete. The real problem is elsewhere, but this "fixes" the regression for now. libstdc++-v3/ChangeLog: PR libstdc++/96592 * include/std/tuple (_TupleConstraints): Use alternative is_constructible instead of std::is_constructible. * testsuite/20_util/tuple/cons/96592.cc: New test. (cherry picked from commit 032a4b42cc5f2105f622690ce2552f1c30e1d227)
[Bug target/99820] New: aarch64: ICE (segfault) in aarch64_analyze_loop_vinfo with -moverride=tune=use_new_vector_costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99820
Bug ID: 99820
Summary: aarch64: ICE (segfault) in aarch64_analyze_loop_vinfo
with -moverride=tune=use_new_vector_costs
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
extern short a[];
void f() {
for (int i = 0; i < 100; i++)
a[i] = 0;
}
$ aarch64-linux-gnu-gcc -c test.c -march=armv8.2-a+sve -O -ftree-vectorize
-moverride=tune=use_new_vector_costs
during GIMPLE pass: vect
test.c: In function ‘f’:
test.c:2:6: internal compiler error: Segmentation fault
2 | void f() {
| ^
0xdf6c93 crash_signal
/home/alecop01/toolchain/src/gcc/gcc/toplev.c:327
0x1252b9b aarch64_analyze_loop_vinfo
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:14463
0x1252b9b aarch64_add_stmt_cost
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64.c:15292
0x111fdd3 add_stmt_cost
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.h:1477
0x111fdd3 vect_compute_single_scalar_iteration_cost
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:1292
0x111fdd3 vect_analyze_loop_2
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:2311
0x1122169 vect_analyze_loop(loop*, vec_info_shared*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:2985
0x115847b try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1009
0x11589b3 try_vectorize_loop
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1162
0x1158cf9 vectorize_loops()
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1243
0xfd74cb execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151 --- Comment #9 from Jonathan Wakely --- And for 10.3
[Bug libstdc++/99537] Wrong memory_order used in stop_token ref-counting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99537 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ad9ae82ed1c33e1803f33bb367b0b4c9ee2e3e63 commit r10-9594-gad9ae82ed1c33e1803f33bb367b0b4c9ee2e3e63 Author: Jonathan Wakely Date: Thu Mar 11 16:44:57 2021 + libstdc++: Use acq_rel memory ordering [PR 99537] As Lewis Baker wrote in the PR: > The 'fetch_sub()' operation in _M_release_ownership() should be using > memory_order::acq_rel instead of memory_order::release. The use of > 'release' only is insufficient as it does not synchronise with any > corresponding 'acquire' operation. > With the current implementation, it's possible that a prior write to > one of the _M_value or _M_head data-members by a thread releasing the > second-to-last reference might not be visible to another thread that > releases the last reference and frees the memory, resulting in > potential write to freed memory. This simply changes the memory order to acq_rel as suggested. libstdc++-v3/ChangeLog: PR libstdc++/99537 * include/std/stop_token (_Stop_state_t::_M_release_ownership): Use acq_rel memory ordering. (cherry picked from commit 15825b17cf3fbf28181c51fe94a2898f448f915c)
[Bug c++/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:039fc1ff2b018aaba5203c89de64ddc02c7a5c17 commit r10-9592-g039fc1ff2b018aaba5203c89de64ddc02c7a5c17 Author: Jonathan Wakely Date: Thu Mar 11 16:43:51 2021 + libstdc++: Initialize std::normal_distribution::_M_saved [PR 99536] This avoids a false positive -Wmaybe-uninitialized warning, by initializing _M_saved on construction. libstdc++-v3/ChangeLog: PR libstdc++/99536 * include/bits/random.h (normal_distribution): Use default-initializer for _M_saved and _M_saved_available. (cherry picked from commit 67e397660611990efd98f9e4106c1ee81f6803a4)
[Bug libstdc++/95592] Collision with struct _Cosh when Cross compiling libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95592 Jonathan Wakely changed: What|Removed |Added Target Milestone|11.0|10.3
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6e5f662f1dd6e3d1a79e194c118c295b897fc7ef commit r10-9593-g6e5f662f1dd6e3d1a79e194c118c295b897fc7ef Author: Jonathan Wakely Date: Thu Mar 11 16:43:51 2021 + libstdc++: Handle EPERM for filesystem access errors on MacOS [PR 99537] Contrary to what POSIX says, some directory operations on MacOS can fail with EPERM instead of EACCES, so we need to handle both. libstdc++-v3/ChangeLog: PR libstdc++/99533 * src/c++17/fs_dir.cc (recursive_directory_iterator): Use new helper function to check for permission denied errors. * src/filesystem/dir.cc (recursive_directory_iterator): Likewise. * src/filesystem/dir-common.h (is_permission_denied_error): New helper function. (cherry picked from commit 8cfb387388a90730ab36ac24d9049677db633a11)
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 Jonathan Wakely changed: What|Removed |Added Target Milestone|11.0|10.3
[Bug libstdc++/93628] ranges::equal_to doesn't work for types convertible to function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93628 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:913312de92522e9e6696331fc3018e1020845c26 commit r10-9591-g913312de92522e9e6696331fc3018e1020845c26 Author: Jonathan Wakely Date: Wed Mar 10 15:27:06 2021 + libstdc++: Implement LWG 3530 for concept-constrained comparisons The proposed resolution for this library issue simplifies the constraints for compare_three_way, ranges::equal_to, ranges::less etc. so that they do not work with types which are convertible to pointers but which fail to meet the usual syntactic requirements for the comparisons. This affects the example in PR libstdc++/93628 but doesn't fix the problem described in that report. libstdc++-v3/ChangeLog: * include/bits/range_cmp.h (__eq_builtin_ptr_cmp): Remove. (ranges::equal_to, ranges::not_equal_to): Do not constrain with __eq_builtin_ptr_cmp. (ranges::less, ranges::greater, ranges::less_equal) (ranges::greater_equal): Do not constrain with __less_builtin_ptr_cmp. * libsupc++/compare (compare_three_way): Do not constrain with __3way_builtin_ptr_cmp. * testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc: Moved to... * testsuite/18_support/comparisons/object/lwg3530.cc: ...here. * testsuite/20_util/function_objects/range.cmp/lwg3530.cc: New test. (cherry picked from commit 03b6ceede733d7ae33eca695c06b181b)
[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99756 Last reconfirmed|2019-03-03 00:00:00 |2021-3-29 Known to work|6.1.0 | Known to fail||10.2.0, 11.0, 4.9.4, 5.5.0, ||6.4.0, 7.2.0, 8.3.0, 9.1.0 --- Comment #8 from Martin Sebor --- I've added both the passing test case from comment #0 and the still failing test case from comment #5 to the test suite and xfailed the latter (thus reconfirming for GCC 11). Without any further analysis, the comment #5 test case also looks similar to pr99756.
[Bug libstdc++/99077] [9/10 Regression] Cannot build libstdc++ with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1d5d30410655f21bdeee6c5f2fd970247eea4d23 commit r10-9585-g1d5d30410655f21bdeee6c5f2fd970247eea4d23 Author: Jonathan Wakely Date: Fri Feb 12 10:37:56 2021 + libstdc++: Fix bootstrap with -fno-rtti [PR 99077] When libstdc++ is built without RTTI the __ios_failure type is just an alias for std::ios_failure, so trying to construct it from an int won't compile. This changes the RTTI-enabled __ios_failure type to have the same constructor parameters as std::ios_failure, so that the constructor takes the same arguments whether RTTI is enabled or not. The __throw_ios_failure function now constructs the error_code, instead of the __ios_failure constructor. As a drive-by fix that error_code is constructed with std::generic_category() not std::system_category(), because the int comes from errno which corresponds to the generic category. libstdc++-v3/ChangeLog: PR libstdc++/99077 * src/c++11/cxx11-ios_failure.cc (__ios_failure(const char*, int)): Change int parameter to error_code, to match std::ios_failure. (__throw_ios_failure(const char*, int)): Construct error_code from int parameter. (cherry picked from commit 4591f7e5329dcc6ee9af2f314a050936d470ab5b)
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8c4620e0b085911293bd501232cdc31c81b67512 commit r10-9584-g8c4620e0b085911293bd501232cdc31c81b67512 Author: Jonathan Wakely Date: Thu Feb 11 15:35:23 2021 + libstdc++: Document when C++11/14/17 support became stable [PR 99058] libstdc++-v3/ChangeLog: PR libstdc++/99058 * doc/xml/manual/status_cxx2011.xml: Document when support became stable. * doc/xml/manual/status_cxx2014.xml: Likewise. * doc/xml/manual/status_cxx2017.xml: Likewise. * doc/html/manual/status.html: Regenerate. (cherry picked from commit ce43c906049b828c0472d8499b52ac6233c869d0)
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #18 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bad3463f257019946d8b17d6956ca058aef88eae commit r10-9583-gbad3463f257019946d8b17d6956ca058aef88eae Author: Jonathan Wakely Date: Wed Feb 10 16:51:34 2021 + libstdc++: Re-enable workaround for _wstat64 bug, again [PR 1] I forgot that the workaround is present in both filesystem::status and filesystem::symlink_status. This restores it in the latter. libstdc++-v3/ChangeLog: PR libstdc++/1 * src/c++17/fs_ops.cc (fs::symlink_status): Re-enable workaround. (cherry picked from commit b7210405ed8eb5fd723b2c99960dcc5f0aec89b4)
[Bug c++/99815] [11 Regression] ICE: in placeholder_type_constraint_dependent_p, at cp/pt.c:28193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99815 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8455158044503a25ebb044428be2ddc83d2b0473 commit r10-9582-g8455158044503a25ebb044428be2ddc83d2b0473 Author: Jonathan Wakely Date: Wed Feb 10 16:51:34 2021 + libstdc++: Re-enable workaround for _wstat64 bug [PR 1] This wasn't fixed upstream for mingw-w64 so we still need the workaround. libstdc++-v3/ChangeLog: PR libstdc++/1 * src/c++17/fs_ops.cc (fs::status): Re-enable workaround. (cherry picked from commit 3df5b249b3c81e95cdcb293a388155ae5b168f9e)
[Bug libstdc++/98319] LFTS headers give errors if included as C++11 or C++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98319 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:564e5b6ce002608f461d4275c126d8179ef806c6 commit r10-9578-g564e5b6ce002608f461d4275c126d8179ef806c6 Author: Jonathan Wakely Date: Wed Dec 16 13:37:17 2020 + libstdc++: Fix errors from Library Fundamentals TS headers in C++11 [PR 98319] Currently the , and headers can be included in C++98 and C++11 modes, but gives errors. With this change they can be included, but define nothing. libstdc++-v3/ChangeLog: PR libstdc++/98319 * include/experimental/random: Only define contents for C++14 and later. * include/experimental/source_location: Likewise. * include/experimental/utility: Likewise. * testsuite/experimental/feat-lib-fund.cc: Include all LFTS headers that are present. Allow test to run for all modes. (cherry picked from commit ab9bd93271061f436c10e35e261ecb73e2108ccc)
[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f1b7f082d09a5ebcf7632b1fd446551f480dc9a8 commit r10-9577-gf1b7f082d09a5ebcf7632b1fd446551f480dc9a8 Author: Jonathan Wakely Date: Tue Dec 15 20:28:11 2020 + libstdc++: Test errno macros directly, not via autoconf [PR 93151] This fixes a bug caused by a mismatch between the macros defined by when GCC is built and the macros defined by when users include . If the user code is compiled with _XOPEN_SOURCE defined to 500 or 600, Darwin suppresses the ENOTRECOVERABLE and EOWNERDEAD macros, which are not defined by SUSv3 (aka POSIX.1-2001). Since POSIX requires the errno macros to be macros (and not variables or enumerators) we can just test for them directly using the preprocessor. That means that will match what is actually defined when it's included, not what was defined when GCC was built. With that change there is no need for the GLIBCXX_CHECK_SYSTEM_ERROR configure checks and they can be removed. libstdc++-v3/ChangeLog: PR libstdc++/93151 * acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove. * configure.ac: Regenerate. * config/os/generic/error_constants.h: Test POSIX errno macros directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros. * testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc: Likewise. * testsuite/19_diagnostics/headers/system_error/93151.cc: New test. (cherry picked from commit a2c2eec183acf25c9b214fa0827718e4d2fdfc93)
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d7216ea6c0cd6c4fef06e9501bd630c3161b14fd commit r10-9576-gd7216ea6c0cd6c4fef06e9501bd630c3161b14fd Author: Jonathan Wakely Date: Thu Dec 10 21:57:42 2020 + libstdc++: Remove redundant branches in countl_one and countr_one [PR 98226] There's no need to explicitly check for the maximum value, because the function we call handles it correctly anyway. libstdc++-v3/ChangeLog: PR libstdc++/98226 * include/std/bit (__countl_one, __countr_one): Remove redundant branches. (cherry picked from commit 2ea62857a3fbdf091ba38cbb62e98dc76b198e2e)
[Bug libstdc++/82584] div by zero in random distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82584 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:56b810af1bdf106b132dcf1f1a01573af6a3468b commit r10-9572-g56b810af1bdf106b132dcf1f1a01573af6a3468b Author: Jonathan Wakely Date: Thu Oct 8 15:14:58 2020 +0100 libstdc++: Add assertions for preconditions in sampling distributions [PR 82584] These three distributions all require 0 < S where S is the sum of the weights. When the sum is zero there's an undefined FP division by zero. Add assertions to help users diagnose the problem. libstdc++-v3/ChangeLog: PR libstdc++/82584 * include/bits/random.tcc (discrete_distribution::param_type::_M_initialize) (piecewise_constant_distribution::param_type::_M_initialize) (piecewise_linear_distribution::param_type::_M_initialize): Add assertions for positive sums.. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line. (cherry picked from commit b2a96bf9dce41ee777b1669e4a8b4c6df3ff3613)
[Bug libstdc++/95592] Collision with struct _Cosh when Cross compiling libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95592 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fa9c46939f9a5c5eb90338b80b213ec1e3579df7 commit r10-9567-gfa9c46939f9a5c5eb90338b80b213ec1e3579df7 Author: Jonathan Wakely Date: Wed Oct 28 12:35:44 2020 + libstdc++: Fix name clash with _Cosh in QNX headers [PR 95592] This replaces unqualified names like _Cosh with struct std::_Cosh to ensure there is no ambiguity with other entities with the same name. libstdc++-v3/ChangeLog: PR libstdc++/95592 * include/bits/valarray_after.h (_DEFINE_EXPR_UNARY_OPERATOR) (_DEFINE_EXPR_BINARY_OPERATOR, _DEFINE_EXPR_BINARY_FUNCTION): Use elaborated-type-specifier and qualified-id to avoid ambiguities with QNX system headers. * testsuite/26_numerics/valarray/95592.cc: New test. (cherry picked from commit 72a87d82e0d0741d75c72c8f3d2fc070e3a02b5f)
[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:77093a75ca4f3a0d6d9ca77ca8905b77695a2599 commit r11-7896-g77093a75ca4f3a0d6d9ca77ca8905b77695a2599 Author: Martin Sebor Date: Mon Mar 29 13:52:53 2021 -0600 PR tree-optimization/61112 - repeated conditional triggers false positive -Wmaybe-uninitialized gcc/testsuite/ChangeLog: PR tree-optimization/61112 * gcc.dg/uninit-pr61112.c: New test.
[Bug fortran/99819] New: [9/10/11 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 Bug ID: 99819 Summary: [9/10/11 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r6 : $ cat z1.f90 program p type t end type contains function f(x, y) class(t) :: x(:) class(*) :: y(size(x)) end function g(z) class(*) :: z(:) type(t) :: u(size(z)) end end $ gfortran-5 -c z1.f90 $ $ gfortran-11-20210328 -c z1.f90 z1.f90:9:15: 9 |function g(z) | 1 internal compiler error: Segmentation fault 0xc09d4f crash_signal ../../gcc/toplev.c:327 0x75328b gfc_defer_symbol_init ../../gcc/fortran/trans-decl.c:841 0x756e5f gfc_defer_symbol_init ../../gcc/fortran/trans-decl.c:1229 0x756e5f gfc_build_dummy_array_decl ../../gcc/fortran/trans-decl.c:1209 0x75b443 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1697 0x76ac18 gfc_conv_variable ../../gcc/fortran/trans-expr.c:2913 0x766dda gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8938 0x769c40 gfc_conv_expr_lhs(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8968 0x73cea8 gfc_conv_ss_descriptor ../../gcc/fortran/trans-array.c:3050 0x7473ac gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.c:7367 0x77a102 gfc_conv_intrinsic_size ../../gcc/fortran/trans-intrinsic.c:8063 0x79186b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.c:10702 0x766dba gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8930 0x769c83 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:8983 0x769dd0 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*) ../../gcc/fortran/trans-expr.c:8997 0x742bbf gfc_trans_dummy_array_bias(gfc_symbol*, tree_node*, gfc_wrapped_block*) ../../gcc/fortran/trans-array.c:6770 0x75d0dc gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.c:4905 0x75f6d2 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6988 0x75f3e4 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5878 0x75f3e4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6816
[Bug fortran/99818] New: [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 Bug ID: 99818 Summary: [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20210207 and 20210214 : $ cat z1.f90 module m type t integer :: a contains procedure :: s end type contains subroutine s(x) class(t) :: x[*] end end program p use m associate (y => t(1)) call y%s end associate end $ gfortran-11-20210207 -c z1.f90 -fcoarray=single z1.f90:15:12: 15 | call y%s |1 Error: VARIABLE attribute of 'y' conflicts with PROCEDURE attribute at (1) $ gfortran-11-20210207 -c z1.f90 -fcoarray=lib z1.f90:15:12: 15 | call y%s |1 Error: VARIABLE attribute of 'y' conflicts with PROCEDURE attribute at (1) $ gfortran-11-20210328 -c z1.f90 -fcoarray=single $ $ gfortran-11-20210328 -c z1.f90 -fcoarray=lib z1.f90:15:14: 15 | call y%s | 1 internal compiler error: in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186 0x76304b gfc_get_tree_for_caf_expr(gfc_expr*) ../../gcc/fortran/trans-expr.c:2186 0x76fb7b gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:6837 0x7a8d28 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:424 0x7391a8 trans_code ../../gcc/fortran/trans.c:1990 0x7ad12f gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2304 0x738f67 trans_code ../../gcc/fortran/trans.c:2018 0x75f5e4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6884 0x6e5de6 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e5de6 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99817] [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Related variants : $ cat z3.f90 subroutine s3 (x, y) character(*), dimension(:) :: x[*] character(*) :: y end $ cat z4.f90 subroutine s4 (x, y, z) character(*), dimension(:) :: x[2, *] character(*), dimension(*) :: y character(*) :: z end $ gfortran-11-20210328 -c z3.f90 -fcoarray=lib z3.f90:1:13: 1 | subroutine s3 (x, y) | 1 internal compiler error: Segmentation fault 0xc09d4f crash_signal ../../gcc/toplev.c:327 0x754bd9 create_function_arglist ../../gcc/fortran/trans-decl.c:2625 #... $ gfortran-11-20210328 -c z4.f90 -fcoarray=lib z4.f90:1:13: 1 | subroutine s4 (x, y, z) | 1 internal compiler error: in create_function_arglist, at fortran/trans-decl.c:2628 0x75539e create_function_arglist ../../gcc/fortran/trans-decl.c:2628 #...
[Bug fortran/99817] New: [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817 Bug ID: 99817 Summary: [10/11 Regression] ICE in create_function_arglist, at fortran/trans-decl.c:2838 (etc.) Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20210314 and 20210328 : $ cat z1.f90 subroutine s1 (x) character(*) :: x(*)[*] end $ cat z2.f90 subroutine s2 (x) character(*), dimension(*), codimension[*] :: x integer :: i i = len(x) end $ gfortran-11-20210314 -c z1.f90 -fcoarray=lib $ gfortran-11-20210314 -c z1.f90 -fcoarray=single $ gfortran-11-20210328 -c z1.f90 -fcoarray=single $ $ gfortran-11-20210328 -c z1.f90 -fcoarray=lib z1.f90:1:13: 1 | subroutine s1 (x) | 1 internal compiler error: Segmentation fault 0xc09d4f crash_signal ../../gcc/toplev.c:327 0x754ed9 create_function_arglist ../../gcc/fortran/trans-decl.c:2838 0x75a153 gfc_create_function_decl(gfc_namespace*, bool) ../../gcc/fortran/trans-decl.c:3089 0x7603b6 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6778 0x6e5de6 translate_all_program_units ../../gcc/fortran/parse.c:6351 0x6e5de6 gfc_parse_file() ../../gcc/fortran/parse.c:6620 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
Re: Fix typo in ipa-modref
> > >gcc/testsuite/ChangeLog: > > > > > >2021-03-29 Jan Hubicka > > > > > > * gcc.c-torture/compile/pr99751.c: New test. > > > > Why compile torture? > > Ah, sorry, it was meant to be execute. I will move the test. It is now renamed as https://gcc.gnu.org/g:7b6ca93b2d57ead352cd5cc3e10be4c33dda674b PR ipa/99751 * gcc.c-torture/compile/pr99751.c: Rename from ... * gcc.c-torture/execute/pr99751.c: ... to this. diff --git a/gcc/testsuite/gcc.c-torture/compile/pr99751.c b/gcc/testsuite/gcc.c-torture/execute/pr99751.c similarity index 100% rename from gcc/testsuite/gcc.c-torture/compile/pr99751.c rename to gcc/testsuite/gcc.c-torture/execute/pr99751.c > > Honza
[Bug ipa/99751] [11 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751 --- Comment #11 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:7b6ca93b2d57ead352cd5cc3e10be4c33dda674b commit r11-7895-g7b6ca93b2d57ead352cd5cc3e10be4c33dda674b Author: Jan Hubicka Date: Mon Mar 29 20:59:42 2021 +0200 Fix pr99751.c testcase PR ipa/99751 * gcc.c-torture/compile/pr99751.c: Rename from ... * gcc.c-torture/execute/pr99751.c: ... to this.
Re: Fix typo in ipa-modref
> >gcc/testsuite/ChangeLog: > > > >2021-03-29 Jan Hubicka > > > > * gcc.c-torture/compile/pr99751.c: New test. > > Why compile torture? Ah, sorry, it was meant to be execute. I will move the test. Honza
Re: [PATCH 2/3] libstdc++: Simplify copy-pasted algorithms in
On Mon, 29 Mar 2021, Patrick Palka wrote:
> The header currently copies some simple algorithms from
> , which was originally done in order to avoid a
> circular dependency with the header. This is no longer an issue since
> the latter header now includes instead of all of
> .
>
> This means we could now just include and remove the
> copied algorithms, but that would double the size of .
Whoops, more like increase the size of by ~10% (33k SLOC -> 37k).
> And we
> can't use the corresponding STL-style algorithms here because they
> assume input iterators are copyable. So this patch instead simplifies
> these copied algorithms, removing their constraints and unused
> parameters, and keeps them around. In a subsequent patch we're going to
> copy ranges::find into as well.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (__detail::find_if): Simplify.
> (__detail::find_if_not): Likewise.
> (__detail::min): Remove.
> (__detail::mismatch): Simplify.
> (take_view::size): Use std::min instead of __detail::min.
> ---
> libstdc++-v3/include/std/ranges | 59 ++---
> 1 file changed, 17 insertions(+), 42 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index cfcbcaba065..9077271e4e6 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -978,65 +978,40 @@ namespace views::__adaptor
>using all_t = decltype(all(std::declval<_Range>()));
>} // namespace views
>
> - // XXX: the following algos are copied from ranges_algo.h to avoid a
> circular
> - // dependency with that header.
> + // The following simple algos are transcribed from ranges_algo.h to avoid
> + // having to include that entire header.
>namespace __detail
>{
> -template _Sent,
> - typename _Proj = identity,
> - indirect_unary_predicate> _Pred>
> +template
>constexpr _Iter
> - find_if(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
> + find_if(_Iter __first, _Sent __last, _Pred __pred)
>{
> while (__first != __last
> - && !(bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
> +&& !(bool)std::__invoke(__pred, *__first))
> ++__first;
> return __first;
>}
>
> -template _Sent,
> - typename _Proj = identity,
> - indirect_unary_predicate> _Pred>
> +template
>constexpr _Iter
> - find_if_not(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj =
> {})
> + find_if_not(_Iter __first, _Sent __last, _Pred __pred)
>{
> while (__first != __last
> - && (bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
> +&& (bool)std::__invoke(__pred, *__first))
> ++__first;
> return __first;
>}
>
> -template - indirect_strict_weak_order>
> -_Comp = ranges::less>
> - constexpr const _Tp&
> - min(const _Tp& __a, const _Tp& __b, _Comp __comp = {}, _Proj __proj =
> {})
> - {
> - if (std::__invoke(std::move(__comp),
> - std::__invoke(__proj, __b),
> - std::__invoke(__proj, __a)))
> - return __b;
> - else
> - return __a;
> - }
> -
> -template _Sent1,
> - input_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
> - typename _Pred = ranges::equal_to,
> - typename _Proj1 = identity, typename _Proj2 = identity>
> - requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
> +template _Sent2>
>constexpr pair<_Iter1, _Iter2>
> - mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
> __last2,
> -_Pred __pred = {}, _Proj1 __proj1 = {}, _Proj2 __proj2 = {})
> + mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
> __last2)
>{
> while (__first1 != __last1 && __first2 != __last2
> -&& (bool)std::__invoke(__pred,
> - std::__invoke(__proj1, *__first1),
> - std::__invoke(__proj2, *__first2)))
> - {
> - ++__first1;
> - ++__first2;
> - }
> +&& (bool)ranges::equal_to{}(*__first1, *__first2))
> + {
> + ++__first1;
> + ++__first2;
> + }
> return { std::move(__first1), std::move(__first2) };
>}
>} // namespace __detail
> @@ -1847,14 +1822,14 @@ namespace views::__adaptor
>size() requires sized_range<_Vp>
>{
> auto __n = ranges::size(_M_base);
> - return __detail::min(__n, static_cast(_M_count));
> + return std::min(__n, static_cast(_M_count));
>}
>
>constexpr auto
>size() const requires sized_range
>{
> auto __n = ranges::size(_M_base);
> - return __detail::min(__n, static_cast(_M_count));
> + return std::min(__n,
[PATCH 3/3] libstdc++: Fix split_view::_OuterIter::operator++ [LWG 3505]
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::find): Define.
(split_view::_OuterIter::operator++): Apply proposed resolution
of LWG 3505.
* testsuite/std/ranges/adaptors/split.cc (test10): New test.
---
libstdc++-v3/include/std/ranges | 28 ---
.../testsuite/std/ranges/adaptors/split.cc| 12
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 9077271e4e6..baec8c0efef 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -982,6 +982,16 @@ namespace views::__adaptor
// having to include that entire header.
namespace __detail
{
+template
+ constexpr _Iter
+ find(_Iter __first, _Sent __last, const _Tp& __value)
+ {
+ while (__first != __last
+ && !(bool)(*__first == __value))
+ ++__first;
+ return __first;
+ }
+
template
constexpr _Iter
find_if(_Iter __first, _Sent __last, _Pred __pred)
@@ -2656,21 +2666,31 @@ namespace views::__adaptor
constexpr _OuterIter&
operator++()
{
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 3505. split_view::outer-iterator::operator++ misspecified
const auto __end = ranges::end(_M_parent->_M_base);
if (__current() == __end)
return *this;
const auto [__pbegin, __pend] = subrange{_M_parent->_M_pattern};
if (__pbegin == __pend)
++__current();
+ else if constexpr (__detail::__tiny_range<_Pattern>)
+ {
+ __current() = __detail::find(std::move(__current()), __end,
+*__pbegin);
+ if (__current() != __end)
+ ++__current();
+ }
else
do
{
auto [__b, __p]
- = __detail::mismatch(std::move(__current()), __end,
-__pbegin, __pend);
- __current() = std::move(__b);
+ = __detail::mismatch(__current(), __end, __pbegin, __pend);
if (__p == __pend)
- break;
+ {
+ __current() = __b;
+ break;
+ }
} while (++__current() != __end);
return *this;
}
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
b/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
index b9fb3728708..9d2cfa8632a 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/split.cc
@@ -182,6 +182,17 @@ test09()
static_assert(requires { adapt2(s); });
}
+void
+test10()
+{
+ // LWG 3505
+ auto to_string = [] (auto r) {
+return std::string(r.begin(), ranges::next(r.begin(), r.end()));
+ };
+ auto v = "xxyx"sv | views::split("xy"sv) | views::transform(to_string);
+ VERIFY( ranges::equal(v, (std::string_view[]){"x", "x"}) );
+}
+
int
main()
{
@@ -194,4 +205,5 @@ main()
test07();
test08();
test09();
+ test10();
}
--
2.31.1.133.g84d06cdc06
[PATCH 2/3] libstdc++: Simplify copy-pasted algorithms in
The header currently copies some simple algorithms from
, which was originally done in order to avoid a
circular dependency with the header. This is no longer an issue since
the latter header now includes instead of all of
.
This means we could now just include and remove the
copied algorithms, but that would double the size of . And we
can't use the corresponding STL-style algorithms here because they
assume input iterators are copyable. So this patch instead simplifies
these copied algorithms, removing their constraints and unused
parameters, and keeps them around. In a subsequent patch we're going to
copy ranges::find into as well.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::find_if): Simplify.
(__detail::find_if_not): Likewise.
(__detail::min): Remove.
(__detail::mismatch): Simplify.
(take_view::size): Use std::min instead of __detail::min.
---
libstdc++-v3/include/std/ranges | 59 ++---
1 file changed, 17 insertions(+), 42 deletions(-)
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index cfcbcaba065..9077271e4e6 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -978,65 +978,40 @@ namespace views::__adaptor
using all_t = decltype(all(std::declval<_Range>()));
} // namespace views
- // XXX: the following algos are copied from ranges_algo.h to avoid a circular
- // dependency with that header.
+ // The following simple algos are transcribed from ranges_algo.h to avoid
+ // having to include that entire header.
namespace __detail
{
-template _Sent,
-typename _Proj = identity,
-indirect_unary_predicate> _Pred>
+template
constexpr _Iter
- find_if(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
+ find_if(_Iter __first, _Sent __last, _Pred __pred)
{
while (__first != __last
- && !(bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
+ && !(bool)std::__invoke(__pred, *__first))
++__first;
return __first;
}
-template _Sent,
-typename _Proj = identity,
-indirect_unary_predicate> _Pred>
+template
constexpr _Iter
- find_if_not(_Iter __first, _Sent __last, _Pred __pred, _Proj __proj = {})
+ find_if_not(_Iter __first, _Sent __last, _Pred __pred)
{
while (__first != __last
- && (bool)std::__invoke(__pred, std::__invoke(__proj, *__first)))
+ && (bool)std::__invoke(__pred, *__first))
++__first;
return __first;
}
-template>
- _Comp = ranges::less>
- constexpr const _Tp&
- min(const _Tp& __a, const _Tp& __b, _Comp __comp = {}, _Proj __proj = {})
- {
- if (std::__invoke(std::move(__comp),
- std::__invoke(__proj, __b),
- std::__invoke(__proj, __a)))
- return __b;
- else
- return __a;
- }
-
-template _Sent1,
-input_iterator _Iter2, sentinel_for<_Iter2> _Sent2,
-typename _Pred = ranges::equal_to,
-typename _Proj1 = identity, typename _Proj2 = identity>
- requires indirectly_comparable<_Iter1, _Iter2, _Pred, _Proj1, _Proj2>
+template
constexpr pair<_Iter1, _Iter2>
- mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
__last2,
- _Pred __pred = {}, _Proj1 __proj1 = {}, _Proj2 __proj2 = {})
+ mismatch(_Iter1 __first1, _Sent1 __last1, _Iter2 __first2, _Sent2
__last2)
{
while (__first1 != __last1 && __first2 != __last2
- && (bool)std::__invoke(__pred,
- std::__invoke(__proj1, *__first1),
- std::__invoke(__proj2, *__first2)))
- {
- ++__first1;
- ++__first2;
- }
+ && (bool)ranges::equal_to{}(*__first1, *__first2))
+ {
+ ++__first1;
+ ++__first2;
+ }
return { std::move(__first1), std::move(__first2) };
}
} // namespace __detail
@@ -1847,14 +1822,14 @@ namespace views::__adaptor
size() requires sized_range<_Vp>
{
auto __n = ranges::size(_M_base);
- return __detail::min(__n, static_cast(_M_count));
+ return std::min(__n, static_cast(_M_count));
}
constexpr auto
size() const requires sized_range
{
auto __n = ranges::size(_M_base);
- return __detail::min(__n, static_cast(_M_count));
+ return std::min(__n, static_cast(_M_count));
}
};
--
2.31.1.133.g84d06cdc06
[PATCH 1/3] libstdc++: Fix elements_view::operator* and operator[] [LWG 3502]
While we're modifying elements_view, this also implements the one-line
resolution of LWG 3492.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__returnable_element): New
concept.
(elements_view): Use this concept in its constraints. Add
missing private access specifier.
(elements_view::_S_get_element): Define as per LWG 3502.
(elements_view::operator*, elements_view::operator[]): Use
_S_get_element.
(elements_view::operator++): Remove unnecessary constraint
as per LWG 3492.
* testsuite/std/ranges/adaptors/elements.cc (test05): New test.
---
libstdc++-v3/include/std/ranges | 26 ---
.../testsuite/std/ranges/adaptors/elements.cc | 16
2 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 978578197dc..cfcbcaba065 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -3234,6 +3234,10 @@ namespace views::__adaptor
{ std::get<_Nm>(__t) }
-> convertible_to&>;
};
+
+template
+ concept __returnable_element
+ = is_reference_v<_Tp> || move_constructible>;
}
template
@@ -3241,6 +3245,7 @@ namespace views::__adaptor
&& __detail::__has_tuple_element, _Nm>
&&
__detail::__has_tuple_element>,
_Nm>
+ && __detail::__returnable_element, _Nm>
class elements_view : public view_interface>
{
public:
@@ -3298,10 +3303,23 @@ namespace views::__adaptor
template
struct _Iterator
{
+ private:
using _Base = __detail::__maybe_const_t<_Const, _Vp>;
iterator_t<_Base> _M_current = iterator_t<_Base>();
+ static constexpr decltype(auto)
+ _S_get_element(const iterator_t<_Base>& __i)
+ {
+ if constexpr (is_reference_v>)
+ return std::get<_Nm>(*__i);
+ else
+ {
+ using _Et = remove_cv_t>>;
+ return static_cast<_Et>(std::get<_Nm>(*__i));
+ }
+ }
+
friend _Iterator;
public:
@@ -3334,8 +3352,8 @@ namespace views::__adaptor
{ return std::move(_M_current); }
constexpr decltype(auto)
- operator*() const
- { return std::get<_Nm>(*_M_current); }
+ operator*() const
+ { return _S_get_element(_M_current); }
constexpr _Iterator&
operator++()
@@ -3345,7 +3363,7 @@ namespace views::__adaptor
}
constexpr void
- operator++(int) requires (!forward_range<_Base>)
+ operator++(int)
{ ++_M_current; }
constexpr _Iterator
@@ -3390,7 +3408,7 @@ namespace views::__adaptor
constexpr decltype(auto)
operator[](difference_type __n) const
requires random_access_range<_Base>
- { return std::get<_Nm>(*(_M_current + __n)); }
+ { return _S_get_element(_M_current + __n); }
friend constexpr bool
operator==(const _Iterator& __x, const _Iterator& __y)
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
b/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
index b0d122f8db5..134afd6a873 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/elements.cc
@@ -100,6 +100,21 @@ test04()
static_assert(!requires { 0 | elements; });
}
+void
+test05()
+{
+ // LWG 3502
+ std::vector vec = {42};
+ auto r1 = vec
+| views::transform([](auto c) { return std::make_tuple(c, c); })
+| views::keys;
+ VERIFY( ranges::equal(r1, (int[]){42}) );
+
+ std::tuple a[] = {{1,2},{3,4}};
+ auto r2 = a | views::keys;
+ VERIFY( r2[0] == 1 && r2[1] == 3 );
+}
+
int
main()
{
@@ -107,4 +122,5 @@ main()
test02();
test03();
test04();
+ test05();
}
--
2.31.1.133.g84d06cdc06
Re: [PATCH v2] C++ : Add the -stdlib= option.
Hi Iain, could you add a note about this change to the
gcc-11/changes.html page? There are probably some people who would be
interested in this who could use a note about it. Thanks
On Tue, Dec 22, 2020 at 3:53 PM Jason Merrill via Gcc-patches
wrote:
>
> On 12/22/20 3:39 PM, Iain Sandoe wrote:
> > Hi Jason,
> >
> > Jason Merrill wrote:
> >
> >> On 11/11/20 3:58 PM, Iain Sandoe wrote:
> >
> >>> This option allows the user to specify alternate C++ runtime libraries,
> >>> for example when a platform uses libc++ as the installed C++ runtime.
> >>> It is the same spelling as a clang option that allows that to use
> >>> libstdc++.
> >>> I have had this patch for some time now (more than a year) on Darwin
> >>> branches.
> >>>
> >
> >>> + /* Which standard library to link.
> >>> + 1 = libstdc++
> >>> + 2 = libc++. */
> >>> + int which_library = 1;
> >>
> >> Even if this variable is an int, let's introduce an enum for comparing it
> >> to specific values.
> >
> > done - it is also noted that it must track the enum in the opt file.
> >
> >>> @@ -264,6 +293,8 @@ lang_specific_driver (struct cl_decoded_option
> >>> **in_decoded_options,
> >>> /* Add one for shared_libgcc or extra static library. */
> >>> num_args = argc + added + need_math + (library > 0) * 4 + 1;
> >>> + if (which_library > 1 && LIBCXXABI != NULL)
> >>> +num_args += 4;
> >>
> >> Why does libc++ need more args than libstdc++? Please add a comment.
> >
> > done (JFTR, it’s because libc++ doesn’t include the abi library for most
> > platforms, so that also has to be
> > appended to the link line).
> >
> >>> +#ifdef GPLUSPLUS_LIBCXX_INCLUDE_DIR
> >>> +/* Pick up libc++ include files, if we have -stdlib=libc++. */
> >>> +{ GPLUSPLUS_LIBCXX_INCLUDE_DIR, "G++", 2, 1,
> >>
> >> If you're going to give cplusplus a non-boolean value, the comment in
> >> cppdefault.h needs to reflect that.
> >
> > done.
> >
> > (re-)tested on x86_64-darwin{11,16,17,19, 20} with the installed libc++ and
> > x86_64-linux-gnu with an
> > LLVM-9 build. Bootstrapped and smoke-tested for libc++ (regular testing
> > for libstdc++).
> >
> > OK for master now?
>
> OK.
>
> > thanks
> > Iain
> >
> > revised patch
> >
> >
> > This option allows the user to specifiy alternate C++ runtime libraries,
> > for example when a platform uses libc++ as the installed C++ runtime.
> >
> > We introduce the command line option: -stdlib= which is the user-facing
> > mechanism to select the C++ runtime to be used when compiling and linking
> > code. This is the same option spelling as that used by clang to allow the
> > use of libstdc++.
> >
> > The availability (and thus function) of the option are a configure-time
> > choice using the configuration control:
> > --with-gxx-libcxx-include-dir=
> >
> > Specification of the path for the libc++ headers, enables the -stdlib=
> > option (using the path as given), default values are set when the path
> > is unconfigured.
> >
> > If --with-gxx-libcxx-include-dir is given together with --with-sysroot=,
> > then we test to see if the include path starts with the sysroot and, if so,
> > record the sysroot-relative component as the local path. At runtime, we
> > prepend the sysroot that is actually active.
> >
> > At link time, we use the C++ runtime in force and (if that is libc++) also
> > append the libc++abi ABI library. As for other cases, if a target sets the
> > name pointer for the ABI library to NULL the G++ driver will omit it from
> > the link line.
> >
> > gcc/ChangeLog:
> >
> > * configure.ac: Add gxx-libcxx-include-dir handled
> > in the same way as the regular cxx header directory.
> > * Makefile.in: Regenerated.
> > * config.in: Likewise.
> > * configure: Likewise.
> > * cppdefault.c: Pick up libc++ headers if the option
> > is enabled.
> > * cppdefault.h (struct default_include): Amend comments
> > to reflect the extended use of the cplusplus field.
> > * incpath.c (add_standard_paths): Allow for multiple
> > c++ header include path variants.
> > * doc/invoke.texi: Document the -stdlib= option.
> >
> > gcc/c-family/ChangeLog:
> >
> > * c.opt: Add -stdlib= option and enumerations for
> > libstdc++ and libc++.
> >
> > gcc/cp/ChangeLog:
> >
> > * g++spec.c (LIBCXX, LIBCXX_PROFILE, LIBCXX_STATIC): New.
> > (LIBCXXABI, LIBCXXABI_PROFILE, LIBCXXABI_STATIC): New.
> > (enum stdcxxlib_kind): New.
> > (lang_specific_driver): Allow selection amongst multiple
> > c++ runtime libraries.
> > ---
> > gcc/Makefile.in | 6
> > gcc/c-family/c.opt | 14 +
> > gcc/config.in | 6
> > gcc/configure | 57 --
> > gcc/configure.ac| 44 +++
> > gcc/cp/g++spec.c| 74 -
> > gcc/cppdefault.c| 5 +++
> > gcc/cppdefault.h| 7 -
> >
Re: Fix typo in ipa-modref
On March 29, 2021 8:11:51 PM GMT+02:00, Jan Hubicka wrote:
>Hi,
>this patch fixes if (deref) that is reversed in merge_call_lhs_flags.
>I re-run stats on cc1plus that seems comparable to last run.
>
>Bootstrapped/regtested x86_64-linux.
>
>Alias oracle query stats:
>
>refs_may_alias_p: 66575703 disambiguations, 76462658 queries
>
>ref_maybe_used_by_call_p: 364568 disambiguations, 67280898 queries
>
>call_may_clobber_ref_p: 217587 disambiguations, 221304 queries
>
>nonoverlapping_component_refs_p: 0 disambiguations, 36514 queries
>
>nonoverlapping_refs_since_match_p: 17351 disambiguations, 61127 must
>overlaps, 79253 queries
>aliasing_component_refs_p: 64537 disambiguations, 2076259 queries
>
>TBAA oracle: 24082735 disambiguations 57590168 queries
>
> 11651231 are in alias set 0
> 10865812 queries asked about the same object
> 132 queries asked about the same alias set
> 0 access volatile
> 9473619 are dependent in the DAG
> 1516639 are aritificially in conflict with void *
>
>Modref stats:
>
>modref use: 13892 disambiguations, 409262 queries
>
>modref clobber: 1358267 disambiguations, 15950909 queries
>
>3287388 tbaa queries (0.206094 per modref query)
>
>519328 base compares (0.032558 per modref query)
>
>
>PTA query stats:
>
>pt_solution_includes: 11809203 disambiguations, 19340135 queries
>
>pt_solutions_intersect: 1217666 disambiguations, 13770732 queries
>
>
>gcc/ChangeLog:
>
>2021-03-29 Jan Hubicka
>
> * ipa-modref.c (merge_call_lhs_flags): Correct handling of deref.
> (analyze_ssa_name_flags): Fix typo in comment.
>
>gcc/testsuite/ChangeLog:
>
>2021-03-29 Jan Hubicka
>
> * gcc.c-torture/compile/pr99751.c: New test.
Why compile torture?
>diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
>index 7aaf53be8f4..5f33bb5b410 100644
>--- a/gcc/ipa-modref.c
>+++ b/gcc/ipa-modref.c
>@@ -1545,9 +1545,9 @@ merge_call_lhs_flags (gcall *call, int arg, int
>index, bool deref,
> tree lhs = gimple_call_lhs (call);
> analyze_ssa_name_flags (lhs, lattice, depth + 1, ipa);
> if (deref)
>- lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
>- else
> lattice[index].merge_deref (lattice[SSA_NAME_VERSION (lhs)], false);
>+ else
>+ lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
> }
> /* In the case of memory store we can do nothing. */
> else
>@@ -1621,7 +1621,7 @@ analyze_ssa_name_flags (tree name,
>vec , int depth,
> else if (gcall *call = dyn_cast (use_stmt))
> {
> tree callee = gimple_call_fndecl (call);
>-/* Return slot optiomization would require bit of propagation;
>+/* Return slot optimization would require bit of propagation;
>give up for now. */
> if (gimple_call_return_slot_opt_p (call)
> && gimple_call_lhs (call) != NULL_TREE
>diff --git a/gcc/testsuite/gcc.c-torture/compile/pr99751.c
>b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
>new file mode 100644
>index 000..f1d5101c359
>--- /dev/null
>+++ b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
>@@ -0,0 +1,20 @@
>+int *ptr1 = 0, **ptr2 =
>+
>+int *identity(int *p)
>+{
>+ return p;
>+}
>+
>+void store_to_c(int *p)
>+{
>+ *ptr2 = identity(p);
>+}
>+
>+int main()
>+{
>+ int f;
>+ store_to_c();
>+ if (ptr1 != )
>+__builtin_abort();
>+ return 0;
>+}
[Bug debug/99654] Incorrect DW_AT_entry_pc values for inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99654 --- Comment #4 from Frank Ch. Eigler --- A quick diff between the two -fverbose-asm dumps confirms that the generated object code is identical with or without the -gno-as-locview-support, but the DW_AT_entry_pc differs.
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #15 from Jan Hubicka --- I also tried to reproduce this locally w/o luck. Looking at the backtrace in detail, there is no DEF_STMT involved. It walks from dwarf dies, to RTL constant pool address that points to tree which has abstract origin that points to symtab node which points to callgraph edge which points to dead basic block. The pointer from cgraph node to edge that should be removed. I can add code to clear pointers SSA_NAME->def_stmt bit there is no def stmt in the backtrace, so it would not help here. W/o reproducer it seem hard to tell what is/was real cause of this issue... Honza
[Bug ipa/99751] [11 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jan Hubicka --- Forgot PR marker in changelog, but it is fixed by g:dd64aaafe6916ac11ccae3182b4550c8b8f5e066
Fix typo in ipa-modref
Hi,
this patch fixes if (deref) that is reversed in merge_call_lhs_flags.
I re-run stats on cc1plus that seems comparable to last run.
Bootstrapped/regtested x86_64-linux.
Alias oracle query stats:
refs_may_alias_p: 66575703 disambiguations, 76462658 queries
ref_maybe_used_by_call_p: 364568 disambiguations, 67280898 queries
call_may_clobber_ref_p: 217587 disambiguations, 221304 queries
nonoverlapping_component_refs_p: 0 disambiguations, 36514 queries
nonoverlapping_refs_since_match_p: 17351 disambiguations, 61127 must
overlaps, 79253 queries
aliasing_component_refs_p: 64537 disambiguations, 2076259 queries
TBAA oracle: 24082735 disambiguations 57590168 queries
11651231 are in alias set 0
10865812 queries asked about the same object
132 queries asked about the same alias set
0 access volatile
9473619 are dependent in the DAG
1516639 are aritificially in conflict with void *
Modref stats:
modref use: 13892 disambiguations, 409262 queries
modref clobber: 1358267 disambiguations, 15950909 queries
3287388 tbaa queries (0.206094 per modref query)
519328 base compares (0.032558 per modref query)
PTA query stats:
pt_solution_includes: 11809203 disambiguations, 19340135 queries
pt_solutions_intersect: 1217666 disambiguations, 13770732 queries
gcc/ChangeLog:
2021-03-29 Jan Hubicka
* ipa-modref.c (merge_call_lhs_flags): Correct handling of deref.
(analyze_ssa_name_flags): Fix typo in comment.
gcc/testsuite/ChangeLog:
2021-03-29 Jan Hubicka
* gcc.c-torture/compile/pr99751.c: New test.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 7aaf53be8f4..5f33bb5b410 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1545,9 +1545,9 @@ merge_call_lhs_flags (gcall *call, int arg, int index,
bool deref,
tree lhs = gimple_call_lhs (call);
analyze_ssa_name_flags (lhs, lattice, depth + 1, ipa);
if (deref)
- lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
- else
lattice[index].merge_deref (lattice[SSA_NAME_VERSION (lhs)], false);
+ else
+ lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
}
/* In the case of memory store we can do nothing. */
else
@@ -1621,7 +1621,7 @@ analyze_ssa_name_flags (tree name, vec
, int depth,
else if (gcall *call = dyn_cast (use_stmt))
{
tree callee = gimple_call_fndecl (call);
- /* Return slot optiomization would require bit of propagation;
+ /* Return slot optimization would require bit of propagation;
give up for now. */
if (gimple_call_return_slot_opt_p (call)
&& gimple_call_lhs (call) != NULL_TREE
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr99751.c
b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
new file mode 100644
index 000..f1d5101c359
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr99751.c
@@ -0,0 +1,20 @@
+int *ptr1 = 0, **ptr2 =
+
+int *identity(int *p)
+{
+ return p;
+}
+
+void store_to_c(int *p)
+{
+ *ptr2 = identity(p);
+}
+
+int main()
+{
+ int f;
+ store_to_c();
+ if (ptr1 != )
+__builtin_abort();
+ return 0;
+}
[Bug c++/99815] [11 Regression] ICE: in placeholder_type_constraint_dependent_p, at cp/pt.c:28193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99815 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-03-29 Priority|P3 |P1 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|ICE: in |[11 Regression] ICE: in |placeholder_type_constraint |placeholder_type_constraint |_dependent_p, at|_dependent_p, at |cp/pt.c:28193 |cp/pt.c:28193 CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed. Started with r11-7540.
[Bug c++/99803] [9/10/11 Regression] ICE: in make_typename_type, at cp/decl.c:4057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99803 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.4 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-03-29 Priority|P3 |P2 Summary|ICE: in make_typename_type, |[9/10/11 Regression] ICE: |at cp/decl.c:4057 |in make_typename_type, at ||cp/decl.c:4057 --- Comment #1 from Marek Polacek --- And this one is mine too -- r266710.
Re: [PATCH, V2] Add conversions between _Float128 and Decimal.
On Sat, Mar 27, 2021 at 04:07:18PM +0100, Florian Weimer wrote:
> This issue is still present.
>
> What about the patch below?
>
> Thanks,
> Florian
>
> rs6000: Do not build _Float128/Decimal routines with --disable-decimal-float
>
> Fixes commit 781183595acba67a37c66f59a0c1d9b5fee7e248 ("Add conversions
> between _Float128 and Decimal.).
>
> libgcc/
> * config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating
> point functions for $(decimal_float) only.
>
> diff --git a/libgcc/config/rs6000/t-float128 b/libgcc/config/rs6000/t-float128
> index 6fb1a3d871b..b1f00accdf1 100644
> --- a/libgcc/config/rs6000/t-float128
> +++ b/libgcc/config/rs6000/t-float128
> @@ -37,8 +37,11 @@ ibm128_dec_funcs = _tf_to_sd _tf_to_dd _tf_to_td \
> # New functions for software emulation
> fp128_ppc_funcs = floattikf floatuntikf fixkfti fixunskfti \
> extendkftf2-sw trunctfkf2-sw \
> - sfp-exceptions _mulkc3 _divkc3 _powikf2 \
> - $(fp128_dec_funcs) $(fp128_decstr_funcs)
> + sfp-exceptions _mulkc3 _divkc3 _powikf2
> +
> +ifeq ($(decimal_float),yes)
> +fp128_ppc_funcs += $(fp128_dec_funcs) $(fp128_decstr_funcs)
> +endif
>
> fp128_ppc_src= $(addprefix
> $(srcdir)/config/rs6000/,$(addsuffix \
> .c,$(fp128_ppc_funcs)))
>
That patch looks ok (assuming you've tested it). There are still the wider
issues that Segher wanted addressed, but it should fix the problem with
disabling decimal float.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
