[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Justin Bassett changed: What|Removed |Added CC||jbassett271 at gmail dot com --- Comment #11 from Justin Bassett --- An additional use case: to test that header files can compile in isolation, one could compile the header file with -fsyntax-only ( g++ -xc++ -fsyntax-only myheader.hpp ). However, this emits the "#pragma once in main file" warning, which is undesirable, especially because it makes -Werror impossible. This means that a tool for checking header file isolation would have to emit a new file to check header isolation.
[Bug c++/99223] [modules] stdl header-unit ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99223 --- Comment #4 from Alexander Lelyakin --- Currently these two sequences produce same error: internal compiler error: in install_entity, at cp/module.cc:7464 Which is duplicate of 99241. Should be closed.
[Bug c++/99222] [modules] system header-unit ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99222 Alexander Lelyakin changed: What|Removed |Added CC||alexander.lelyakin@googlema ||il.com --- Comment #1 from Alexander Lelyakin --- This is not more reproducible for more than month. Should be closed.
[Bug c++/99246] [modules] ICE in write_location, at cp/module.cc:15687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99246 --- Comment #4 from Alexander Lelyakin --- This report is marked as resolved, but it is stable reproducible all the time. /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bit /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header istream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bitset /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header new /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ciso646 /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header thread /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex In module imported at /usr/local/include/c++/11.0.1/sstream:38:1, included from /usr/local/include/c++/11.0.1/regex:46: /usr/local/include/c++/11.0.1/istream: note: unable to represent further imported source locations /usr/local/include/c++/11.0.1/regex: internal compiler error: in write_location, at cp/module.cc:15593 0x6e02cf module_state::write_location(bytes_out&, unsigned int) ../../gcc/gcc/cp/module.cc:15593 0xa60ff3 trees_out::core_vals(tree_node*) ../../gcc/gcc/cp/module.cc:5900 0xa64464 trees_out::tree_node_vals(tree_node*) ../../gcc/gcc/cp/module.cc:7050 0xa64464 trees_out::tree_value(tree_node*) ../../gcc/gcc/cp/module.cc:8887 0xa604f4 trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9085 0xa6484a trees_out::write_var_def(tree_node*) ../../gcc/gcc/cp/module.cc:11472 0xa65ae5 module_state::write_cluster(elf_out*, depset**, unsigned int, depset::hash&, unsigned int*, unsigned int*) ../../gcc/gcc/cp/module.cc:14648 0xa6743e module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17720 0xa6801f finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19831 0x9fb4cb c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210330 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/99284] [modules] ICE in key_mergeable, at cp/module.cc:10441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99284 --- Comment #2 from Alexander Lelyakin --- Not reproduced anymore.
Re: Remove RMS from the GCC Steering Committee
On Mar 30, 2021, JeanHeyd Meneide wrote:
> Taking the correction into account
*nod*
> What you've presented here is your word ("This
> accusation is outright false, beyond any possible doubt."),
True, I didn't claim to be offering evidence, and that didn't seem
necessary since all the supporting evidence you'd brought was hearsay.
I can't link to the message that is presumably removed, and I suppose I
could get permission to share the email in which he issued the request,
but please be honest: would you believe it?
> they were NOT allowed to attack people like this and go this far and
> being banned by moderation, RMS taking explicit actions to UNDO that
> moderation and explicitly, in the internal mailing list, state
> (paraphrased): 'I have put a new moderator in. Have at it.'
This description suggests we're not even talking about the same events.
My description was about a doxxing web site/email posted no more than a
week ago.
Your description appears to resemble events of 2019: the illegitimate
censorious moderation that was imposed on a GNU mailing list, against
GNU and mailing list policies, after someone abused their autonomy to
grant moderation privileges to a group that started suppressing views
they disagreed with, while allowing personal attacks they supported to
go through. List rules were restored and censorship ceased with the
legitimate installation of a larger group of moderators with more
diverse stances, that applied list rules and blocked inappropriate posts
while allowing through civil criticism on all sides. Richard was
criticized for insisting on enabling the debate to carry on, but he
insisted on the principled stance of free speech, and then some, to
allow for what some perceived as personal attacks against him.
Now, you appear to believe a very different interpretation of these
facts. I can't imagine that showing public posts will prove anything,
since the difference is in the interpretation and attribution of
motivations and allegiances, rather than on facts. As law and history
have taught us, proving innocence or honesty are often impossible tasks;
it is the burden of the accuser to offer enough evidence to sustain an
accusation, and all you've brought is hearsay. Popular, widespread
hateful hearsay, but still hearsay.
> where someone who was already banned
No such thing happened. That's yet another distortion.
There was an attempt to attach shocking labels to an honest man.
The labels failed to stick, though some people still believe them.
Part of the problem is the reasoning that, if so many people are
parroting the same false allegations, there must be truth to them.
When any one of them is proven wrong, with the great effort required to
overcome preconceptions, the goal post is moved onto all of the others
that appear to remain, because the preconceptions still mistake them for
granted, and the accused remains guilty for having taken multiple shots.
That's not the way civilizations have long carried out justice.
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
[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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a3bf6ce7f2e17f2c977c13df23eb718e7b433dcd commit r11-7921-ga3bf6ce7f2e17f2c977c13df23eb718e7b433dcd Author: Patrick Palka Date: Tue Mar 30 22:57:11 2021 -0400 c++: Adjust mangling of __alignof__ [PR88115] r11-4926 made __alignof__ get mangled differently from alignof, encoding __alignof__ as a vendor extended operator. But this mangling is problematic for the reasons mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6. This patch changes our mangling of __alignof__ to instead use the new "vendor extended expression" syntax that's proposed in https://github.com/itanium-cxx-abi/cxx-abi/issues/112. Clang does the same thing already, so after this patch Clang and GCC agree about the mangling of __alignof__(type) and __alignof__(expr). gcc/cp/ChangeLog: PR c++/88115 * mangle.c (write_expression): Adjust the mangling of __alignof__. include/ChangeLog: PR c++/88115 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_VENDOR_EXPR. libiberty/ChangeLog: PR c++/88115 * cp-demangle.c (d_dump, d_make_comp, d_expression_1) (d_count_templates_scopes): Handle DEMANGLE_COMPONENT_VENDOR_EXPR. (d_print_comp_inner): Likewise. : Revert r11-4926 change. : Likewise. * testsuite/demangle-expected: Adjust __alignof__ tests. gcc/testsuite/ChangeLog: PR c++/88115 * g++.dg/cpp0x/alignof7.C: Adjust expected mangling.
[Bug c++/99844] New: ICE: unexpected expression 'B' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99844
Bug ID: 99844
Summary: ICE: unexpected expression 'B' of kind
template_parm_index
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Related to fixed PR 99745 and PR 99757.
https://godbolt.org/z/5qW5a1Mnq
template
struct S {
constexpr explicit(B) S() {}
};
constexpr S s;
:3:25: internal compiler error: unexpected expression 'B' of kind
template_parm_index
3 | constexpr explicit(B) S() {}
| ^
0x1cfb6a9 internal_error(char const*, ...)
???:0
0x9164c7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x959fc9 instantiate_class_template(tree_node*)
???:0
0x77fbc7 start_decl_1(tree_node*, bool)
???:0
0x7a728f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0x8e12ad c_parse_file()
???:0
0xa600a2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[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 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0bbf0edbfc782f8e4e416d5fbd1b52a515adb585 commit r11-7920-g0bbf0edbfc782f8e4e416d5fbd1b52a515adb585 Author: Patrick Palka Date: Tue Mar 30 22:54:37 2021 -0400 c++: placeholder type constraint and argument pack [PR99815] When checking dependence of a placeholder type constraint, if the first template argument of the constraint is an argument pack, we need to expand it in order to properly separate the implicit 'auto' argument from the rest. gcc/cp/ChangeLog: PR c++/99815 * pt.c (placeholder_type_constraint_dependent_p): Expand argument packs to separate the first non-pack argument from the rest. gcc/testsuite/ChangeLog: PR c++/99815 * g++.dg/cpp2a/concepts-placeholder5.C: New test.
[Bug tree-optimization/99823] -funroll-all-loops bugs when using contexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99823 --- Comment #2 from apple --- (In reply to Richard Biener from comment #1) > -funroll-all-loops applies to the RTL loop unroller, the GIMPLE level > concludes: > > Estimating sizes for loop 1 > BB: 3, after_exit: 0 > size: 1 _1 = MEM[(int (*) (int) &)__for_begin_21]; > size: 5 _13 = _1 (s_20); > size: 1 __for_begin_14 = __for_begin_21 + 8; > size: 1 ivtmp_4 = ivtmp_11 - 1; >Induction variable computation will be folded away. > size: 2 if (ivtmp_4 != 0) >Exit condition will be eliminated in peeled copies. >Exit condition will be eliminated in last copy. >Constant conditional. > BB: 5, after_exit: 1 > size: 10-3, last_iteration: 10-3 > Loop size: 10 > Estimated size after unrolling: 14 > Not unrolling loop 1: contains call and code would grow. > > so it concludes unrolling isn't profitable (but it would turn indirect into > direct calls). Anyway, I should mention here that clang can unroll it without this flag and turn out constexpr.cpp equal to unroll.cpp. And you can try to insert "#pragma GCC unroll 2“ the loop finally unrolled, even in this pragma, constexpr.cpp is not equal to unroll.cpp. But this is technically another issue
Re: Remove RMS from the GCC Steering Committee
Dear Alexandre,
As stated here, shortly after I sent my message
(https://gcc.gnu.org/pipermail/gcc/2021-March/235197.html):
> Apologies, a correction here. I should have more carefully read
> it, but this paragraph:
>
> > My problem is Dr. Richard M. Stallman stands credibly and
> > factually accused of Doxxing and GCC contributor/participant and
> > knowingly manipulating the project for his own personal reasons.
>
> This should be "RMS explicitly sanctioned, encouraged, and
> blessed the Doxxing of an individual". Apologies, he did not do the
> doxxing himself; this was a fat finger on my part. Please take that
> into account; the rest is accurate.
Taking the correction into account, no, the accusation is not
even close to false. What you've presented here is your word ("This
accusation is outright false, beyond any possible doubt."), with a
shortened version of what happened and no evidence, and that does not
match the quoted responses from Stallman and other people who were
present in both the public mailing list discussion and the internal
mailing list. I was given quoted evidence of, after people being told
they were NOT allowed to attack people like this and go this far and
being banned by moderation, RMS taking explicit actions to UNDO that
moderation and explicitly, in the internal mailing list, state
(paraphrased): 'I have put a new moderator in. Have at it.'
That the same individuals (who Stallman, again, explicitly and
knowingly) unshackled were then banned for continuing to do things
that were against the Community Guidelines and grossly inappropriate
(including the Doxxing). Stallman was not born yesterday, neither were
any of the moderators or contributors involved: Stallman deliberately
overturned moderator decisions and that decision went poorly after he
explicitly signaled to people that they should Go All Out.
If you (or anyone else) have evidence to the contrary, logs,
screenshots, etc. that counteract what I know and I have already
received, then I would LOVE to be proven wrong and have ABSOLUTELY no
problem walking back every word I said and giving Richard M. Stallman
an apology and respect as well as apologizing to the mailing list for
believing to be led astray. If you feel the exact words should not be
shared publicly, you can e-mail me or message me privately; I have
honored everyone's right to privacy, and I will continue to do so.
I must be explicitly clear here that the current body of evidence
gives me my current conviction. There is no planet, no galaxy, no
UNIVERSE, where someone who was already banned for going **way**
beyond acceptable behavior, and then brought back with their
punishment undone with the *explicit go-ahead to go forward* and a
*new moderator for that purpose*, would not take that as a signal to
be even nastier. If you are in a Leadership position and your thought
process here was "well, things will go better the second time" after
doing those actions, then you absolutely do not deserve to be in a
Leadership position, and you absolutely should not have stewardship
over me or my contributions. Especially if this is not your first time
on a mailing list and this is not your first time being a leader.
All my best,
JeanHeyd
[Bug c++/99843] New: Making a function a friend of a class will hide function constructor priority if has constructor(n) attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99843
Bug ID: 99843
Summary: Making a function a friend of a class will hide
function constructor priority if has constructor(n)
attribute
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: itirg1 at optusnet dot com.au
Target Milestone: ---
When declaring a function a friend of a class and that function uses the
__attribute__((constructor(priority))) attribute, the priority is lost. I have
only tested this on the arm-none-eabi-g++ on windows.
In the code below I made a quick demo of the problem, all of the initialisation
functions correctly have a section called .init_array.(5 digit priority number)
containing a pointer to the function except for the function that was made a
friend which is placed in .init_array which as a result the linker script will
place after the numbered ones.
F:\Test>arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Arm Embedded Toolchain 9-2020-q3-update) 9.3.1 20200408
(release)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
F:\Test>cat testinit.cpp
// Initialization order test
void Init101(void) __attribute__((constructor(101)));
void Init101(void)
{
while(1);
}
static void Init102(void) __attribute__((constructor(102)));
static void Init102(void)
{
while(1);
}
namespace Something
{
void Init103(void) __attribute__((constructor(103)));
void Init103(void)
{
while(1);
}
static void Init104(void) __attribute__((constructor(104)));
static void Init104(void)
{
while(1);
}
class SomeClass
{
friend void Init105(void);
private:
int foo;
public:
int bar;
};
SomeClass * AClassPtr = nullptr;
void Init105(void) __attribute__((constructor(105)));
void Init105(void)
{
if (AClassPtr == nullptr)
{
AClassPtr = new SomeClass;
}
AClassPtr->foo = 219;
}
void Init106(void) __attribute__((constructor(106)));
void Init106(void)
{
while(1);
}
}
F:\Test>arm-none-eabi-g++ -mcpu=cortex-m0 -c -fno-exceptions testinit.cpp
F:\Test>arm-none-eabi-objdump -h -r -t testinit.o
testinit.o: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 004c 0034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 0080 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0004 0080 2**2
ALLOC
3 .init_array.00101 0004 0080 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .init_array.00102 0004 0084 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
5 .init_array.00103 0004 0088 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
6 .init_array.00104 0004 008c 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
7 .init_array 0004 0090 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
8 .init_array.00106 0004 0094 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
9 .comment 004d 0098 2**0
CONTENTS, READONLY
10 .ARM.attributes 002c 00e5 2**0
CONTENTS, READONLY
SYMBOL TABLE:
ldf *ABS* testinit.cpp
ld .text .text
ld .data .data
ld .bss .bss
ld .init_array.00101 .init_array.00101
0006 l F .text 0006 _ZL7Init102v
ld .init_array.00102 .init_array.00102
ld .init_array.00103 .init_array.00103
0012 l F .text 0006 _ZN9SomethingL7Init104Ev
ld .init_array.00104 .init_array.00104
ld .init_array .init_array
ld .init_array.00106 .init_array.00106
ld .comment .comment
ld .ARM.attributes .ARM.attributes
g F .text 0006 _Z7Init101v
000c g F .text 0006 _ZN9Something7Init103Ev
g O .bss 0004 _ZN9Something9AClassPtrE
0018 g F .text
[Bug tree-optimization/63660] -Wmaybe-uninitialized false positive (uninit pass limits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63660 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to fail|4.8.3, 4.9.2, 5.0 |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 Last reconfirmed|2014-10-28 00:00:00 |2021-3-30 --- Comment #4 from Martin Sebor --- Reconfirmed with GCC 11. The limits don't come into play here. There is an uninitialized use in a PHI in the IL: [local count: 1073741824]: # xj_35 = PHI # .MEM_55 = PHI <.MEM_54(53), .MEM_77(21)> if (m_3 > 63) goto ; [51.12%] else goto ; [48.88%] ... [local count: 262422500]: # .MEM_88 = VDEF <.MEM_64> x_25->j = xj_35;
Re: Remove RMS from the GCC Steering Committee
On Mar 30, 2021, JeanHeyd Meneide via Gcc wrote: > My problem is Dr. Richard M. Stallman stands credibly and > factually accused of Doxxing and GCC contributor/participant and > knowingly manipulating the project for his own personal reasons. This accusation is outright false, beyond any possible doubt. A misguided person thought that reciprocating the doxxing against RMS was a good way to defend him. It's not. The message went through because there is no censorship regime in effect. RMS asked the unacceptable post to be deleted from the archives hosted in GNU servers as soon as he learned about it. I did not check whether that was done. If you have any evidence that it wasn't, please let me know. That you got confirmation of a false claim from multiple developers you talked to should now have you doubting other of their allegations. If you look into them outside the attacking coalition, you *will* find them to be built on just as flaky foundations. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #8 from Marek Polacek ---
The problem is that post-r277865 in defaulted_late_check we call
synthesize_method here:
if (kind == sfk_comparison)
{
/* If the function was declared constexpr, check that the definition
qualifies. Otherwise we can define the function lazily. */
if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
synthesize_method (fn);
return;
}
and that results in garbage collection, which then frees {} that we created
when parsing the braced-list in string<"a">{}. Then of course accessing the
freed data fails.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 luoxhu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from luoxhu at gcc dot gnu.org --- Fixed on mater.
[Bug c++/99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
Re: Remove RMS from the GCC Steering Committee
Are you still responding to me? Your response reads like a thinly veiled threat. Angry friends on a jihad? Sounds serious. On Tue, Mar 30, 2021, 7:14 PM Christopher Dimech wrote: > > I have some friends in this movement who have been getting rather angry > recently. There is a lot of anger in the world, > in fact, in politics. Our political movement is not the only one > suffering from anger at the moment. But some of my angry > friends, have come to the conclusion that they’re on a jihad for free > software. > > That way won’t work. If a campaign of coercive compliance is carried just > a moment too far, willingness to use free > software among rational people will decline to a point which is dangerous > to freedom. > > - > 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:* Wednesday, March 31, 2021 at 9:55 AM > *From:* "Andrew Sutton" > *To:* "Christopher Dimech" > *Cc:* "Joseph Myers" , "GCC Development" < > gcc@gcc.gnu.org>, "Nathan Sidwell" > *Subject:* Re: Remove RMS from the GCC Steering Committee > Sorry for the confusion, but was this response directed to me? It seems > entirely unrelated to what I wrote. > > On Tue, Mar 30, 2021, 5:35 PM Christopher Dimech wrote: > >> >> Seriously. When you want something to happen within society, it is >> complex. Just >> because you want to push something - an ideology - you chant about it >> every day, >> does not mean things will go your way. >> >> Perhaps you can start donating money to Antifa! >> >> >> >> >> >> *Sent:* Wednesday, March 31, 2021 at 9:09 AM >> *From:* "Andrew Sutton" >> *To:* "Christopher Dimech" >> *Cc:* "Joseph Myers" , "GCC Development" < >> gcc@gcc.gnu.org>, "Nathan Sidwell" >> *Subject:* Re: Remove RMS from the GCC Steering Committee >> I guess I'll add my two cents. It seems everyone else is... >> >> I'm not a maintainer or frequent contributor, but I did implement >> concepts for C++, and I'd like to continue contributing, time permitting. >> My company (as in, I own it) also does some work on GCC, implementing new >> and experimental features like contracts, which we intend to upstream, >> pending review. Some modules-related stuff too (I hope). >> >> Maybe my response is a little different because I'm writing as a business >> owner and not a contributor. >> >> >> >> I understand that RMS is not actually on the steering committee and not >> an active contributor, and the SC web page should be updated to reflect >> that if it hasn't already. >> >> I agree with Nathan. >> >> The SC needs to be forward-looking --- you can't steer effectively if >> you're always looking in the rear-view mirror. My understanding is that GCC >> put RMS behind it a long time ago. And for the better. >> >> Part of the SC's job is (or should be) considering recruitment and >> retention for this community, including corporate participation. This idea >> that we have to somehow revere a person who has managed to make himself >> controversial for reasons entirely unrelated to his ideology on free >> software actively works against both of those goals. >> >> Undeniably so. If RMS were actually in the SC, I would have serious >> reservations about committing my employees time to this community. His >> documented behavior readily violates my company's code of conduct. At best, >> I'd risk burn out employees in a toxic environment. At worst, I could end >> up as a defendant in a sexual harassment case. And this 100% not hyperbole. >> >> (Thanks to everyone who makes GCC a good community to participate in.) >> >> I think it's perfectly reasonable for GCC to acknowledge RMS' past >> contributions, both ideological and code-wise, but it's time to move on. >> Nothing good comes from lionizing a man who purportedly asked teenage girls >> to eat candy out of his hand. >> >> >> >> On Tue, Mar 30, 2021, 2:14 PM Christopher Dimech via Gcc >> wrote: >> >>> >>> > Sent: Wednesday, March 31, 2021 at 5:45 AM >>> > From: "Joseph Myers" >>> > To: "JeanHeyd Meneide" >>> > Cc: "GCC Development" , "Nathan Sidwell" < >>> nat...@acm.org> >>> > Subject: Re: Remove RMS from the GCC Steering Committee >>> > >>> > On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote: >>> > >>> > > So, it boils down to this for me: either GCC is a place where >>> all >>> > > contributions are welcome, or GCC is a place of hypocrisy, where >>> > > contributions are welcome except when Stallman (or someone else in a >>> > > position of power) lobbies a non-technical, non-factual argument >>> > > against you and jumps from their high tower to slam down on >>> > > rank-and-file contributors and participants. You cannot have it both >>> > > ways. >>> > >>> > All contributions are welcome. One of the key functions of the SC is >>> > actually
[PATCH] rs6000: MMA test case ICEs using -O3
The mma_assemble_input_operand predicate does not accept reg+reg indexed
addresses which can lead to ICEs. The problem is that the quad_address_p
function only accepts reg+offset addresses that are valid for quad word
accesses, but not reg+reg addresses which are also valid for quad word
accesses when dealing with vector types. The solution used here is to
call memory_operand, which uses rs6000_legitimate_address_p to ensure
the address is valid. For reg+offset addresses, it uses quad_address_p like
before, but for reg+reg addresses, it calls legitimate_indexed_address_p
addresses which fixes this specific ICE.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
I also compiled some non-trivial DGEMM and SGEMM test cases that use our
MMA builtins and I don't see any generated code differences.
Ok for trunk?
The same bad test in mma_assemble_input_operand exists in GCC 10, but I
have been unable to get it to ICE there with this test case. I assume
we still want to fix it there too? If so, ok for GCC 10 after some trunk
burn in?
Peter
gcc/
PR target/99842
* config/rs6000/predicates.md:
gcc/testsuite/
PR target/99842
* g++.target/powerpc/pr99842.C: New.
diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 859af75dfbd..e48c6eee19e 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -1171,8 +1171,7 @@
(define_special_predicate "mma_assemble_input_operand"
(match_test "(mode == V16QImode
&& (vsx_register_operand (op, mode)
- || (MEM_P (op)
- && quad_address_p (XEXP (op, 0), mode, false"))
+ || memory_operand (op, mode)))"))
;; Return 1 if this operand is valid for an MMA disassemble insn.
(define_predicate "mma_disassemble_output_operand"
diff --git a/gcc/testsuite/g++.target/powerpc/pr99842.C
b/gcc/testsuite/g++.target/powerpc/pr99842.C
new file mode 100644
index 000..d84de3b4570
--- /dev/null
+++ b/gcc/testsuite/g++.target/powerpc/pr99842.C
@@ -0,0 +1,188 @@
+/* PR target/99842 */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-O3 -mdejagnu-cpu=power10 -w" } */
+
+/* Verify we do not ICE on the following source. */
+
+enum { a, b, c, d };
+template struct e;
+template struct e {
+ typedef h f;
+};
+template struct ac;
+template struct ac : ac {};
+template struct l;
+template class n;
+template class o;
+template class ag;
+template class af;
+template struct ad;
+template struct an {
+ typedef n::ai, ac::aj> f;
+};
+template struct am { typedef o f; };
+template ::ao,
+ typename = typename ac::av>
+struct ak;
+template struct ak {
+ typedef typename am::f f;
+};
+template struct aq;
+template struct aq { typedef ar at; };
+template ap bf(const typename ad::f *);
+template ap aw(typename ad::f *ax) { return bf(ax);
}
+typedef __attribute__((altivec(vector__))) double au;
+template <> struct ad { typedef double f; };
+template <> au bf(const double *ax) { return __builtin_vec_vsx_ld(0, ax); }
+template struct az {};
+template class o : public l {
+public:
+ typedef typename ac::ah ah;
+ template al +=(const o &);
+};
+template struct l {};
+template struct ac> {
+ typedef typename ba::ah ah;
+ enum { ai, aj };
+};
+template
+class af
+: public ak<
+ af, const n>,
+ n, bd>,
+ int, int>::f {};
+template struct be;
+template void bi(bj, bg bm, g) {
+ typename an::f bk(bm);
+}
+template void bl(bj, bg bm, g bp) {
+ be::bn(a, bm, bp);
+}
+template struct bo;
+class bs {
+public:
+ bs(double *, int);
+ double ()(int, int) { return bq[br]; }
+ template bw bt(int i, int j) {
+double = operator()(i, j);
+return aw();
+ }
+ double *bq;
+ int br;
+};
+class ca : public bs {
+public:
+ ca(double *by, int bz) : bs(by, bz) {}
+};
+template class ce : public am::f {
+protected:
+ template void cb(l) {
+af, const n>,
+ n>
+cc;
+bl(0, cc, az());
+ }
+ template void ch(long);
+ template void ch(l cf) { cb(cf); }
+};
+template
+struct ac> {
+ typedef cg ah;
+ typedef int av;
+};
+template
+class n : public ce> {
+public:
+ template n(ab p) { n::template ch(p); }
+};
+template struct ac> {
+ typedef ba ao;
+ typedef typename e::f ah;
+ typedef typename aq::av, typename ac::av, bc>::at av;
+};
+template class cm;
+template
+class ag
+: public cm::av, typename ac::av, int>::at>
{
+};
+template
+class cm : public ak, n>>::f {};
+template
+template
+al ::operator+=(const o &) {
+ af, const n>,
+ n>
+ co;
+ bi(0, co, int());
+}
+enum { cp };
+template struct cq;
+template struct cr {
+ enum { q };
+ enum { ae = cq::at };
+};
+template <> struct cq {
+ enum { at = d };
+};
+struct t {
+ template static void bn(ba, bb, s) {
+typedef typename bb::ah x;
+x u;
+bo::bn(0, 0, ca(0, 0), ca(, 1), 0, 0, 0);
+ }
+};
Remove RMS from the GCC Steering Committee
Giacomo wrote: >Stallman cannot betray Free Software AND get away with it. >So to me (and to many others) Stallman is a sort of a living warranty. That's fine. He doesn't need to be in the GCC SC to do that. He can continue to provide guidance on the spirit of Free Software without having an SC position, or any official leadership position. The people in the GCC SC are very reasonable people; I have worked with some of them, and they will listen to reasonable arguments. RMS doesn't have veto powers anyway, and doesn't need them. The proposed removal from the SC doesn't prevent RMS from giving the aforementioned guidance in any way, nor does it even make it any more difficult. In fact, that removal shouldn't have any effect on his ability to give such guidance, nor does it actually have any effect on what the consequences of his guidance will be. The warranty you speak of does not boil down to a particular individual being there in the SC. That's by RMS's own design; the copyright and the license give you that warranty, not the SC presence of any single person. And a removal from an SC doesn't equal the removal from the set of people who can meaningfully contribute. That is certainly, I would think, not the intent of anyone who has spoken in favor of the removal. There is certainly a fair amount of heat in this discussion. Whether the proposed removal has the effects it seeks, I don't know. But I don't buy the surreptitious suggestions that the proposed removal somehow spells doom for the continued availability of GCC as Free Software, or for the spirit of Free Software in general. In my anecdotal case, it doesn't. I have fairly good reasons to think that it doesn't spell such doom for quite many other contributors to these projects, some far more frequently active than me. I am, Yours Most Sincerely, Ville Voutilainen an occasional libstdc++ contributor a less-frequently occasional g++ contributor
[Bug target/99842] MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842 Peter Bergner changed: What|Removed |Added Target||powerpc64le-linux Ever confirmed|0 |1 Known to fail||11.0 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Last reconfirmed||2021-03-30 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.0 --- Comment #1 from Peter Bergner --- Mine. The problem is that the mma_assemble_input_operand predicate is rejecting valid reg+reg indexed addresses in the MEMs in the above rtl. The predicate is calling quad_address_p() which accepts reg+offset addresses (with constrained offset values), but doesn't allow reg+reg addresses, which are valid. Replacing the MEM_P() && quad_address_p() test with a call to memory_operand() fixes the ICE, since it calls down to rs6000_legitimate_address_p(), which calls quad_address_p() to validate reg+offset addresses, but also allows reg+reg addresses. I'll submit a patch with that fix.
[Bug target/99842] New: MMA test case ICEs using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99842
Bug ID: 99842
Summary: MMA test case ICEs using -O3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
A reduced test case from Eigen using MMA builtins ICEs using -O3:
bergner@pike:~/gcc/BUGS/$ g++ -w -S -O3 -mcpu=power10 bug.ii
bug.ii: In function ‘n< , , m, ,
, >::n(ab) [with ab = af, const n >, n >; cg = double; int
= -1; int m = 1; int = 3; int = 0; int
= 1]’:
bug.ii:90:59: error: could not split insn
90 | template n(ab p) { n::template ch(p); }
| ^
(insn:TI 28 335 29 (set (reg:OO 32 0 [orig:125 _28 ] [125])
(unspec:OO [
(mem:V16QI (plus:DI (reg/f:DI 26 26 [orig:223 MEM
[(struct ca *)_253] ] [223])
(reg:DI 27 27 [222])) [0 MEM [(void *)_25]+0 S16
A8])
(mem:V16QI (plus:DI (reg/f:DI 26 26 [orig:223 MEM
[(struct ca *)_253] ] [223])
(reg:DI 27 27 [222])) [0 MEM [(void *)_25]+0 S16
A8])
] UNSPEC_MMA_ASSEMBLE)) 2080 {*vsx_assemble_pair}
(expr_list:REG_EQUIV (mem/c:OO (plus:DI (reg/f:DI 31 31 [217])
(const_int 160 [0xa0])) [6 MEM[(__vector_pair *)_173]+0 S32
A256])
(nil)))
during RTL pass: final
bug.ii:90:59: internal compiler error: in final_scan_insn_1, at final.c:3092
0x101fa5fb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/rtl-error.c:108
0x10a2b5cb final_scan_insn_1
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:3092
0x10a2c613 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:3171
0x10a2c9b3 final_1
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:2022
0x10a2dc57 rest_of_handle_final
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:4676
0x10a2dc57 execute
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:4754
[Bug c++/99790] [8/9/10 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7cdd30b43a63832d6f908b2dd64bd19a0817cd7b commit r10-9626-g7cdd30b43a63832d6f908b2dd64bd19a0817cd7b Author: Jakub Jelinek Date: Tue Mar 30 18:15:32 2021 +0200 c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790] The following testcase ICEs (since the addition of inline var support), because the lambda contains PTRMEM_CST but finish_function is called for the lambda quite early during parsing it (from finish_lambda_function) when the containing class is still incomplete. That means that during genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but later nothing lowers it when the class is finalized. Using sizeof etc. on the class in such contexts is rejected by both g++ and clang++, and when the PTRMEM_CST appears e.g. in static var initializers rather than in functions, we handle it correctly because c_parse_final_cleanups -> lower_var_init will handle those cplus_expand_constant when all classes are already finalized. The following patch fixes it by calling cplus_expand_constant again during gimplification, as we are now unconditionally unit at a time, I'd think everything that could be completed will be before we start gimplification. 2021-03-30 Jakub Jelinek PR c++/99790 * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST. * g++.dg/cpp1z/pr99790.C: New test.
[Bug tree-optimization/99777] [11 Regression] ICE in build2, at tree.c:4869 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99777
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:afe9a630eae114665e77402ea083201c9d406e99
commit r10-9625-gafe9a630eae114665e77402ea083201c9d406e99
Author: Jakub Jelinek
Date: Mon Mar 29 12:35:32 2021 +0200
fold-const: Fix ICE in extract_muldiv_1 [PR99777]
extract_muldiv{,_1} is apparently only prepared to handle scalar integer
operations, the callers ensure it by only calling it if the divisor or
one of the multiplicands is INTEGER_CST and because neither multiplication
nor division nor modulo are really supported e.g. for pointer types,
nullptr
type etc. But the CASE_CONVERT handling doesn't really check if it isn't
a cast from some other type kind, so on the testcase we end up trying to
build MULT_EXPR in POINTER_TYPE which ICEs. A few years ago Marek has
added ANY_INTEGRAL_TYPE_P checks to two spots, but the code uses
TYPE_PRECISION which means something completely different for vector types,
etc.
So IMNSHO we should just punt on conversions from non-integrals or
non-scalar integrals.
2021-03-29 Jakub Jelinek
PR tree-optimization/99777
* fold-const.c (extract_muldiv_1): For conversions, punt on casts
from
types other than scalar integral types.
* g++.dg/torture/pr99777.C: New test.
[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f5df18504c1790413f293bfb50d40faa7f1ea860 commit r10-9624-gf5df18504c1790413f293bfb50d40faa7f1ea860 Author: Jakub Jelinek Date: Sat Mar 27 00:20:42 2021 +0100 dwarf2cfi: Defer queued register saves some more [PR99334] On the testcase in the PR with -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing -mstackrealign we have prologue: <_func_with_dwarf_issue_>: 0: 4c 8d 54 24 08 lea0x8(%rsp),%r10 5: 48 83 e4 f0 and$0xfff0,%rsp 9: 41 ff 72 f8 pushq -0x8(%r10) d: 55 push %rbp e: 48 89 e5mov%rsp,%rbp 11: 41 57 push %r15 13: 41 56 push %r14 15: 41 55 push %r13 17: 41 54 push %r12 19: 41 52 push %r10 1b: 53 push %rbx 1c: 48 83 ec 20 sub$0x20,%rsp and emit 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -8 Return address column: 16 Augmentation data: 1b DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_nop DW_CFA_nop 0018 0044 001c FDE cie= pc=..01d5 DW_CFA_advance_loc: 5 to 0005 DW_CFA_def_cfa: r10 (r10) ofs 0 DW_CFA_advance_loc: 9 to 000e DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 13 to 001b DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) ... unwind info for that. The problem is when async signal (or stepping through in the debugger) stops after the pushq %rbp instruction and before movq %rsp, %rbp, the unwind info says that caller's %rbp is saved there at *%rbp, but that is not true, caller's %rbp is either still available in the %rbp register, or in *%rsp, only after executing the next instruction - movq %rsp, %rbp - the location for %rbp is correct. So, either we'd need to temporarily say: DW_CFA_advance_loc: 9 to 000e DW_CFA_expression: r6 (rbp) (DW_OP_breg7 (rsp): 0) DW_CFA_advance_loc: 3 to 0011 DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 10 to 001b or to me it seems more compact to just say: DW_CFA_advance_loc: 12 to 0011 DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) DW_CFA_advance_loc: 10 to 001b I've tried instead to deal with it through REG_FRAME_RELATED_EXPR from the backend, but that failed miserably as explained in the PR, dwarf2cfi.c has some rules (Rule 16 to Rule 19) that are specific to the dynamic stack realignment using drap register that only the i386 backend does right now, and by using REG_FRAME_RELATED_EXPR or REG_CFA* notes we can't emulate those rules. The following patch instead does the deferring of the hard frame pointer save rule in dwarf2cfi.c Rule 18 handling and emits it on the (set hfp sp) assignment that must appear shortly after it and adds assertion that it is the case. The difference before/after the patch on the assembly is: --- pr99334.s~ 2021-03-26 15:42:40.881749380 +0100 +++ pr99334.s 2021-03-26 17:38:05.729161910 +0100 @@ -11,8 +11,8 @@ _func_with_dwarf_issue_: andq$-16, %rsp pushq -8(%r10) pushq %rbp - .cfi_escape 0x10,0x6,0x2,0x76,0 movq%rsp, %rbp + .cfi_escape 0x10,0x6,0x2,0x76,0 pushq %r15 pushq %r14 pushq %r13 i.e. does just what we IMHO need, after pushq %rbp %rbp still contains parent's frame value and so the save rule doesn't need to be overridden there, ditto at the start of the next insn before the side-effect took effect, and we override it only after it when %rbp already has the right value. If some other target adds dynamic stack realignment in the future and the offset 0 case wouldn't be true there, the code can be adjusted so that it works on all the drap architectures, I'm pretty sure the code would need other adjustments too. For the rule 18 and for the (set hfp sp) after it we already have asserts for
[Bug c++/99705] [10 Regression] ICE in expand_expr_real_1 since r10-3661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1c82b47137ab4212b7618da3458d2949b2dff1a3
commit r10-9623-g1c82b47137ab4212b7618da3458d2949b2dff1a3
Author: Jakub Jelinek
Date: Fri Mar 26 09:35:26 2021 +0100
c++: Fix ICE with nsdmi [PR99705]
When adding P0784R7 constexpr new support, we still didn't have
P1331R2 implemented and so I had to change also build_vec_delete_1
- instead of having uninitialized tbase temporary later initialized
by MODIFY_EXPR I've set the DECL_INITIAL for it - because otherwise
it would be rejected during constexpr evaluation which didn't like
uninitialized vars. Unfortunately, that change broke the following
testcase.
The problem is that these temporaries (not just tbase but tbase was
the only one with an initializer) are created during NSDMI parsing
and current_function_decl is NULL at that point. Later when we
clone body of constructors, auto_var_in_fn_p is false for those
(as they have NULL DECL_CONTEXT) and so they aren't duplicated,
and what is worse, the DECL_INITIAL isn't duplicated either nor processed,
and during expansion we ICE because the code from DECL_INITIAL of that
var refers to the abstract constructor's PARM_DECL (this) rather than
the actual constructor's one.
So, either we can just revert those build_vec_delete_1 changes (as done
in the second patch - in attachment), or, as the first patch does, we can
copy the temporaries during bot_manip like we copy the temporaries of
TARGET_EXPRs. To me that looks like a better fix because e.g. if
break_out_of_target_exprs is called for the same NSDMI multiple times,
sharing the temporaries looks just wrong to me. If the temporaries
are declared as BIND_EXPR_VARS of some BIND_EXPR (which is the case
of the tbase variable built by build_vec_delete_1 and is the only way
how the DECL_INITIAL can be walked by *walk_tree*), then we need to
copy it also in the BIND_EXPR BIND_EXPR_VARS chain, other temporaries
(those that don't need DECL_INITIAL) often have just DECL_EXPR and no
corresponding BIND_EXPR.
Note, ({ }) are rejected in nsdmis, so all we run into are temporaries
the FE creates artificially.
2021-03-26 Jakub Jelinek
PR c++/99705
* tree.c (bot_manip): Remap artificial automatic temporaries
mentioned
in DECL_EXPR or in BIND_EXPR_VARS.
* g++.dg/cpp0x/new5.C: New test.
[Bug c++/99745] ICE when parameter pack not expanded in bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99745 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f8780caf07340f5d5e55cf5fb1b2be07cabab1ea commit r10-9622-gf8780caf07340f5d5e55cf5fb1b2be07cabab1ea Author: Jakub Jelinek Date: Thu Mar 25 21:06:09 2021 +0100 c++: Diagnose bare parameter packs in bitfield widths [PR99745] The following invalid tests ICE because we don't diagnose (and drop) bare parameter packs in bitfield widths. 2021-03-25 Jakub Jelinek PR c++/99745 * decl2.c (grokbitfield): Diagnose bitfields containing bare parameter packs and don't set DECL_BIT_FIELD_REPRESENTATIVE in that case. * g++.dg/cpp0x/variadic181.C: New test.
[Bug c++/99650] ICE when trying to form reference to void in structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99650 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d5e379e3fe19362442b5d0ac608fb8ddf67fecd3 commit r10-9621-gd5e379e3fe19362442b5d0ac608fb8ddf67fecd3 Author: Jakub Jelinek Date: Tue Mar 23 10:23:42 2021 +0100 c++: Diagnose references to void in structured bindings [PR99650] We ICE on the following testcase, because std::tuple_element<...,...>::type is void and for structured bindings we therefore need to create void & or void && which is invalid. We created such REFERENCE_TYPE and later ICEd in the middle-end. The following patch fixes it by diagnosing that. 2021-03-23 Jakub Jelinek PR c++/99650 * decl.c (cp_finish_decomp): Diagnose void initializers when using tuple_element and get. * g++.dg/cpp1z/decomp55.C: New test.
[Bug debug/99388] Invalid debug info for __fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d3dd3703f1d42b14c88b91e51a2a775fe00a2974
commit r10-9620-gd3dd3703f1d42b14c88b91e51a2a775fe00a2974
Author: Jakub Jelinek
Date: Sun Mar 21 17:27:39 2021 +0100
dwarf2out: Fix debug info for 2 byte floats [PR99388]
Aarch64, ARM and a couple of other architectures have 16-bit floats,
HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but
putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of
vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode
could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of
endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-21 Jakub Jelinek
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
[Bug c/99588] variable set but not used warning on static _Atomic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99588 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b1fc1f1c4b2e9005c40ed476b067577da2d2ce84 commit r10-9619-gb1fc1f1c4b2e9005c40ed476b067577da2d2ce84 Author: Jakub Jelinek Date: Fri Mar 19 22:54:31 2021 +0100 c: Fix up -Wunused-but-set-* warnings for _Atomics [PR99588] As the following testcases show, compared to -D_Atomic= case we have many -Wunused-but-set-* warning false positives. When an _Atomic variable/parameter is read, we call mark_exp_read on it in convert_lvalue_to_rvalue, but build_atomic_assign does not. For consistency with the non-_Atomic case where we mark_exp_read the lhs for lhs op= ... but not for lhs = ..., this patch does that too. But furthermore we need to pattern match the trees emitted by _Atomic store, so that _Atomic store itself is not marked as being a variable read, but when the result of the store is used, we mark it. 2021-03-19 Jakub Jelinek PR c/99588 * c-typeck.c (mark_exp_read): Recognize what build_atomic_assign with modifycode NOP_EXPR produces and mark the _Atomic var as read if found. (build_atomic_assign): For modifycode of NOP_EXPR, use COMPOUND_EXPRs rather than STATEMENT_LIST. Otherwise call mark_exp_read on lhs. Set TREE_SIDE_EFFECTS on the TARGET_EXPR. * gcc.dg/Wunused-var-5.c: New test. * gcc.dg/Wunused-var-6.c: New test.
Re: Remove RMS from the GCC Steering Committee
On Tue, 30 Mar 2021, Giacomo Tesio wrote: > That being said (and for full disclosure), I also consider his return to > the FSF fair, because the shitstorm that caused his resign two years > ago was built on top of a severe misrepresentation of his words, as > described here https://jorgemorais.gitlab.io/justice-for-rms/ and > admitted also by the people arguing against his return (see the > various edits at https://rms-open-letter.github.io/appendix ). I explicitly stated in my comments that my agreement with Nathan's conclusion is *not* based on the views RMS has expressed, whether on that occasion or on any other. > But I'd want Stallman in GCC's SC for a totally different reason: > > On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote: > > > Nobody suggested that GCC would be relicensed and certainly not to a > > non-free license. If you decide to contribute your port upstream, it > > will be safe with us, regardless of who will or will not be on the > > steering committee The GCC SC doesn't have the power to relicense GCC; that lies with the FSF. We can correct clear licensing mistakes where the underlying licensing policy is already established (e.g. if someone forgets to put the runtime exception in a file in a target library) and there are certain cases with delegated relicensing powers (e.g. copying documentation for target hooks between GFDL and GPL files). But in general relicensing depends on the FSF and that doesn't depend on who is on the SC. (The original owner of code who assigned it to the FSF can also license copies of the code they contributed (not anyone else's changes to that code) under different licenses if they so wish, in accordance with the terms of the standard assignment agreements. The standard assignment agreements also prevent the FSF from distributing the code under proprietary terms.) > On Tue, 30 Mar 2021 17:45:24 + Joseph Myers wrote: > > One of the key functions of the SC is actually saying no to RMS. > > My bad experiences with Google and SFC makes me ask: "about what?" Any time he comes up with an idea, technical or otherwise, that doesn't make sense (he's too far removed from actually following GCC development or use to be able to judge that effectively himself). If an idea makes sense, of course we'll let him know that we'll consider patches. (It's only likely to be in very routine cases that someone on the SC just makes the requested change themselves, e.g. if he points out somewhere in the GCC documentation saying "Linux" that should be "GNU/Linux" in accordance with GNU conventions.) -- Joseph S. Myers jos...@codesourcery.com
[committed] analyzer: remove old decl of region::dump_to_pp
This was made redundant in the GCC 11 rewrite of state (808f4dfeb3a95f50f15e71148e5c1067f90a126d). Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as d0b7c821754e2b16e9e84d877082105799adf238. gcc/analyzer/ChangeLog: * region.h (region::dump_to_pp): Remove old decl. --- gcc/analyzer/region.h | 5 - 1 file changed, 5 deletions(-) diff --git a/gcc/analyzer/region.h b/gcc/analyzer/region.h index ea24b38b6a1..175a82a0cb2 100644 --- a/gcc/analyzer/region.h +++ b/gcc/analyzer/region.h @@ -128,11 +128,6 @@ public: pretty_printer *pp) const; label_text get_desc (bool simple=true) const; - void dump_to_pp (const region_model , - pretty_printer *pp, - const char *prefix, - bool is_last_child) const; - virtual void dump_to_pp (pretty_printer *pp, bool simple) const = 0; void dump (bool simple) const; -- 2.26.2
[committed] analyzer: only call get_diagnostic_tree when it's needed
impl_sm_context::get_diagnostic_tree could be expensive, and
I find myself needing to put a breakpoint on it to debug
PR analyzer/99771, so only call it if we're about to use
the result.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7917-g0f9aa35c79a0fe195d5076375b5794246cf44819.
gcc/analyzer/ChangeLog:
* sm-file.cc (fileptr_state_machine::on_stmt): Only call
get_diagnostic_tree if the result will be used.
* sm-malloc.cc (malloc_state_machine::on_stmt): Likewise.
(malloc_state_machine::on_deallocator_call): Likewise.
(malloc_state_machine::on_realloc_call): Likewise.
(malloc_state_machine::on_realloc_call): Likewise.
* sm-sensitive.cc
(sensitive_state_machine::warn_for_any_exposure): Likewise.
* sm-taint.cc (taint_state_machine::on_stmt): Likewise.
---
gcc/analyzer/sm-file.cc | 2 +-
gcc/analyzer/sm-malloc.cc| 10 +++---
gcc/analyzer/sm-sensitive.cc | 8 +---
gcc/analyzer/sm-taint.cc | 4 +++-
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/gcc/analyzer/sm-file.cc b/gcc/analyzer/sm-file.cc
index 7a81c8ff632..d64c313e31c 100644
--- a/gcc/analyzer/sm-file.cc
+++ b/gcc/analyzer/sm-file.cc
@@ -344,7 +344,6 @@ fileptr_state_machine::on_stmt (sm_context *sm_ctxt,
if (is_named_call_p (callee_fndecl, "fclose", call, 1))
{
tree arg = gimple_call_arg (call, 0);
- tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
sm_ctxt->on_transition (node, stmt, arg, m_start, m_closed);
@@ -356,6 +355,7 @@ fileptr_state_machine::on_stmt (sm_context *sm_ctxt,
if (sm_ctxt->get_state (stmt, arg) == m_closed)
{
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
sm_ctxt->warn (node, stmt, arg,
new double_fclose (*this, diag_arg));
sm_ctxt->set_next_state (stmt, arg, m_stop);
diff --git a/gcc/analyzer/sm-malloc.cc b/gcc/analyzer/sm-malloc.cc
index ef250c80915..ae03b068a88 100644
--- a/gcc/analyzer/sm-malloc.cc
+++ b/gcc/analyzer/sm-malloc.cc
@@ -1674,11 +1674,11 @@ malloc_state_machine::on_stmt (sm_context *sm_ctxt,
if (TREE_CODE (op) == MEM_REF)
{
tree arg = TREE_OPERAND (op, 0);
- tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
state_t state = sm_ctxt->get_state (stmt, arg);
if (unchecked_p (state))
{
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
sm_ctxt->warn (node, stmt, arg,
new possible_null_deref (*this, diag_arg));
const allocation_state *astate = as_a_allocation_state (state);
@@ -1686,12 +1686,14 @@ malloc_state_machine::on_stmt (sm_context *sm_ctxt,
}
else if (state == m_null)
{
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
sm_ctxt->warn (node, stmt, arg,
new null_deref (*this, diag_arg));
sm_ctxt->set_next_state (stmt, arg, m_stop);
}
else if (freed_p (state))
{
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
const allocation_state *astate = as_a_allocation_state (state);
sm_ctxt->warn (node, stmt, arg,
new use_after_free (*this, diag_arg,
@@ -1738,7 +1740,6 @@ malloc_state_machine::on_deallocator_call (sm_context
*sm_ctxt,
if (argno >= gimple_call_num_args (call))
return;
tree arg = gimple_call_arg (call, argno);
- tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
state_t state = sm_ctxt->get_state (call, arg);
@@ -1752,6 +1753,7 @@ malloc_state_machine::on_deallocator_call (sm_context
*sm_ctxt,
if (!astate->m_deallocators->contains_p (d))
{
/* Wrong allocator. */
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
pending_diagnostic *pd
= new mismatching_deallocation (*this, diag_arg,
astate->m_deallocators,
@@ -1766,6 +1768,7 @@ malloc_state_machine::on_deallocator_call (sm_context
*sm_ctxt,
else if (state == d->m_freed)
{
/* freed -> stop, with warning. */
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
sm_ctxt->warn (node, call, arg,
new double_free (*this, diag_arg, d->m_name));
sm_ctxt->set_next_state (call, arg, m_stop);
@@ -1773,6 +1776,7 @@ malloc_state_machine::on_deallocator_call (sm_context
*sm_ctxt,
else if (state == m_non_heap)
{
/* non-heap -> stop, with warning. */
+ tree diag_arg = sm_ctxt->get_diagnostic_tree (arg);
sm_ctxt->warn (node, call, arg,
new free_of_non_heap (*this, diag_arg,
d->m_name));
@@ -1806,7 +1810,6 @@
[committed] analyzer testsuite: fix typo
gcc/testsuite/ChangeLog: * gcc.dg/analyzer/symbolic-1.c: Fix typo. --- gcc/testsuite/gcc.dg/analyzer/symbolic-1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/analyzer/symbolic-1.c b/gcc/testsuite/gcc.dg/analyzer/symbolic-1.c index 9d228e6331c..feab9ce3a2d 100644 --- a/gcc/testsuite/gcc.dg/analyzer/symbolic-1.c +++ b/gcc/testsuite/gcc.dg/analyzer/symbolic-1.c @@ -1,6 +1,6 @@ #include "analyzer-decls.h" -/* The example from store2.h */ +/* The example from store.h */ void test_1 (char a, char b, char c, char d, char e, char f, int i, int j) -- 2.26.2
Re: [PATCH v9] Practical improvement to libgcc complex divide
Thank you for your interest in this project.
On 3/27/2021 6:18 PM, Bernhard Reutner-Fischer wrote:
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
Changes in Version 9 since Version 8:
Revised code to meet gcc coding standards in all files, especially
with respect to adding spaces around operations and removing
excess () in #define macro definitions.
Did you gather cycle counter diffs for current against new for the
normal and some edge cases?
I don't see additional value in looking at cycle counters in addition
to the timing information I presented. I prefer wall clock time to
cycle counters, perhaps because cycle counters are less reliably
implemented on some platforms (that's a separate discussion, though).
Every platform will have different counters and different timing.
Let me run through a rough operation count analysis of the double
precision case. I will also postulate instruction latencies
that might be typical of a recent processor. Real processors
will different somewhat but not by large amounts.
The current method uses Smith's method. Showing half of that method:
if (fabs(c) < fabs(d))
{
ratio = c / d;
denom = (c * ratio) + d;
xx = ((a * ratio) + b) / denom;
yy = ((b * ratio) - a) / denom;
}
It requires:
two fabs computations (typically 1 cycle each)
one floating point compare (typically 2 cycles)
1 branch decision (50-50 prediction reliabilty)
(1 cycle if predicted, 9 cycles if not predicted; ave=5)
3 multiplys, 3 divides, 3 add/subtract operations
(assume 5 cycle latency for add/mul and 15 cycle for divide)
(75 cycles)
Total: 84 cycles (typical average, old method)
I omit the NAN analysis as that is unchanged.
The cost of the new method is data dependent.
First, assume all scaling tests are false and ratio does not underflow.
Further, assume that data is consistently in those ranges, to allow
all branch predictions except the first to be predicted.
I'll also assume we have an excellent branch predictor mechanism
that can handle predicting
Then we have:
5 additional fabs, and 4 additional compare and branches (all predicted)
and one || operations for 18 additional cycles.
[This optimistic count assumes fabs(a,b) > RMIN, allowing
us to bypass the fabs < RMAX2 tests.
New total: 84+18 = 102 (optimistic average, new method)
If we can't bypass the fabs < RMAX2 tests, we need to add
four more fabs, and four && operations, and four compare
operations for 12 more cycles.
Possible total: 84+18+12 = 114
Finally, if we hit a scaling operation, then we have four
multiply operations for an additional 20 cycles plus
we've mispredicted the branch for 9 more.
114+28 = 144 cycles.
This analysis is not particularly accurate. It does not account for
some architectures having several floating point units or for
speculative execution hiding latency or many other variations in
computer architecture. Still, its good enough for a ballpark estimate
that says the typical case will be around 15-25% slower and the most
extreme cases will be around 70% slower.
When we look at the patch writeup, I report that for double precision,
the "moderate set" which represents the typical case, we see 4% to 24%
measured slowdown. The "full set" which represents having a
substantial number of values which might cause branch predictors to go
wrong as costing 38% to 56% overhead. Apparently my 'back of the
envelope' analysis above is not too far off.
Oh, I failed to cover the case where fabs(ratio) < RMIN.
That happens in the full set about 1-2% of the time.
It requires two additional divide operations for an extra
30 cycles, plus maybe 10 cycles for the mispredicted branch.
That might bump up the worst case to be about double the
normal case. That's acceptable when you consider that slow
path prevents the code from returning a completely wrong result.
As a quick aside, the test for ratio underflowing reduces the error
rate by a factor of 4 from 1.70% to 0.35% in the full exponent range
data set with about half the total overhead of the new method. Adding
all the other tests and scaling code reduces errors larger than 12
bits to roughly 1 in 10 million and 18 bits or larger to roughly 1 in
100 million. Those remaining errors are due to the issue of
subtraction cancellation, which is a harder problem than avoiding
underflow/overflow issues.
Can you please share data for -Os between current and your proposed new?
As for data for -Os for current and proposed new, it's not very interesting.
There are no differences as complex divide is not inlined by gcc.
Instead, there is a simple call to __divdc3.
I checked for inlining with gcc 4.8, gcc8.3, and gcc11.0.1 as well as with
a compiler that has my code changes.
If one uses -fcx-fortran-rules then Smith's method for complex divide is
inlined with -Os.
If one uses -fcx-limited-range then the naive method for complex divide
is inlined with -Os.
The new code does not change
[Bug analyzer/99771] Analyzer diagnostics should not say ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99771 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0f9aa35c79a0fe195d5076375b5794246cf44819 commit r11-7917-g0f9aa35c79a0fe195d5076375b5794246cf44819 Author: David Malcolm Date: Fri Mar 26 13:26:15 2021 -0400 analyzer: only call get_diagnostic_tree when it's needed impl_sm_context::get_diagnostic_tree could be expensive, and I find myself needing to put a breakpoint on it to debug PR analyzer/99771, so only call it if we're about to use the result. gcc/analyzer/ChangeLog: * sm-file.cc (fileptr_state_machine::on_stmt): Only call get_diagnostic_tree if the result will be used. * sm-malloc.cc (malloc_state_machine::on_stmt): Likewise. (malloc_state_machine::on_deallocator_call): Likewise. (malloc_state_machine::on_realloc_call): Likewise. (malloc_state_machine::on_realloc_call): Likewise. * sm-sensitive.cc (sensitive_state_machine::warn_for_any_exposure): Likewise. * sm-taint.cc (taint_state_machine::on_stmt): Likewise.
[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #17 from Vladimir Makarov --- (In reply to Peter Bergner from comment #16) > (In reply to seurer from comment #15) > > It still fails on gcc 10, though > > Vlad, can we get this backported to GCC 10? Maybe in time for GCC 10.3? Nobody complained about this patch since its commit. So I believe we can backport it and the patch should be safe for GCC 10 branch.
Re: Remove RMS from the GCC Steering Committee
Hi everybody, thanks for your feedbacks. I've to say I'm a bit confused, but maybe we have different sources and experience so we have different perspective on the matter. Let's start with something I want to clarify: On Tue, 30 Mar 2021 13:07:07 -0400 JeanHeyd Meneide wrote: > You state it here and many others say it throughout the thread > that Stallman is the only reason they contribute to GCC, or similar > Free Software projects. This deeply concerns me I'm sorry, but apperently I was not clear. I do NOT follow RMS as a prophet or something. He does NOT "lead" me. We do not agree on several relevant political issues (even some important one related to Free Software!) and I find statements like https://stallman.org/notes/2016-jul-oct.html#31_October_2016_(Down's_syndrome) plain disgusting. So I'm NOT, in any way, a RMS fanboy. That being said (and for full disclosure), I also consider his return to the FSF fair, because the shitstorm that caused his resign two years ago was built on top of a severe misrepresentation of his words, as described here https://jorgemorais.gitlab.io/justice-for-rms/ and admitted also by the people arguing against his return (see the various edits at https://rms-open-letter.github.io/appendix ). But I'd want Stallman in GCC's SC for a totally different reason: On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote: > Nobody suggested that GCC would be relicensed and certainly not to a > non-free license. If you decide to contribute your port upstream, it > will be safe with us, regardless of who will or will not be on the > steering committee When I joined the Harvey project they were all fun and welcoming. When I asked how and where to write my copyright statement, I was answered by the seasoned and well known Google's engineer that a few years later completely removed my name from the project without removing the contributions. Harvey is copylefted too (GPLv2) and as you know, this sort of behaviour would trigger GPL termination, but Harvey is part of Software Freedom Conservancy and the violation of my copyright likely occurred during the working hours of the above engineer. So they were the good guys and the most powerful guys, together. I had no hope in a US court (and I'm Italian and... let say "not rich"). They taught me a valuable lesson, though. In the long run, even the good guys betray your trust if they have a reason to and they think they can get away with that. Stallman cannot betray Free Software AND get away with it. So to me (and to many others) Stallman is a sort of a living warranty. Unless, obviously, you have reasons that I ignore to not trust him on his loyalty to the Free Software vision and movement. Do you have any? For example when I read On Tue, 30 Mar 2021 17:45:24 + Joseph Myers wrote: > One of the key functions of the SC is actually saying no to RMS. My bad experiences with Google and SFC makes me ask: "about what?" So if you (all) have good reason to think that RMS could betray Free Software, well... THAT would be a good argument to put on the table! But note that to many of us, GCC is not just a great compiler suite! More importantly, it's a Free Software compiler suite. This means that its core value, its main "selling point", is not how cool it is, but how it is designed, developed and distributed to maximise software freedom. IOW, I can imagine scenarios where some features should NOT be introduced to reach this political goal which is MORE important than the technical goal of compiler suite To this aim, I'd prefer to see RMS in the GCC's SC. Because to me GCC is not just "open source", it's not just matter of seeing the source: it's Free Software, it should be designed and developed TO maximize software freedom! That's a fundamental difference that still stay between Free Software and Open Source. On Tue, 30 Mar 2021 18:56:02 +0200 Markus Böck wrote: > At least I would hope that most countries are in pursuit > or see value in having an inclusive environment where no one has to > feel treated unfairly due to either their gender, race or other > things. I want to clarify that I hope this too. Really. And in fact thousands of people of very different races and genders worldwide expressed their support for RMS and FSF by signing https://rms-support-letter.github.io/ Some of them are my close friends, but I will not, obviously, doxe them. However you can find very variegate people arguing on the web for RMS from all of genders and races. Just a few valuable examples are Leah Rowe https://mobile.twitter.com/n4of7/status/1374844604101591047 and Mary Kate Fain https://mobile.twitter.com/mkay_fain/status/1374766567544737793 On Tue, 30 Mar 2021 18:56:02 +0200 Markus Böck wrote: > I am also of the opinion that legally wrong does not equal morally > wrong. RMS does not have to have committed a crime for the developers > of GCC, the SC or whoever, to feel like he is not representing their > values as a
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
Re: [PATCH] c++: placeholder type constraint and argument packs [PR99815]
On 3/30/21 4:35 PM, Patrick Palka wrote:
When checking dependence of a placeholder type constraint, if the first
template argument of the constraint is an argument pack, we need to
expand it so that we properly separate the implicit 'auto' argument from
the rest.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
gcc/cp/ChangeLog:
PR c++/99815
* pt.c (placeholder_type_constraint_dependent_p): Expand
argument packs to separate the first non-pack argument
from the rest.
gcc/testsuite/ChangeLog:
PR c++/99815
* g++.dg/cpp2a/concepts-placeholder5.C: New test.
---
gcc/cp/pt.c | 5 +++
.../g++.dg/cpp2a/concepts-placeholder5.C | 32 +++
2 files changed, 37 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a056ecefd1d..dc6f2f37f9b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28189,6 +28189,11 @@ placeholder_type_constraint_dependent_p (tree t)
tree id = unpack_concept_check (t);
tree args = TREE_OPERAND (id, 1);
tree first = TREE_VEC_ELT (args, 0);
+ if (ARGUMENT_PACK_P (first))
+{
+ args = expand_template_argument_pack (args);
+ first = TREE_VEC_ELT (args, 0);
+}
gcc_checking_assert (TREE_CODE (first) == WILDCARD_DECL
|| is_auto (first));
for (int i = 1; i < TREE_VEC_LENGTH (args); ++i)
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
new file mode 100644
index 000..eaea41a36eb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
@@ -0,0 +1,32 @@
+// PR c++/99815
+// { dg-do compile { target c++20 } }
+
+template
+struct is_same { static constexpr bool value = false; };
+
+template
+struct is_same { static constexpr bool value = true; };
+
+template
+concept C = is_same::value; // { dg-error "wrong number" }
+
+template void f() {
+ C auto x = 0; // { dg-error "constraints" }
+}
+
+template void f(); // { dg-bogus "" }
+template void f(); // { dg-message "required from here" }
+template void f<>(); // { dg-message "required from here" }
+template void f(); // { dg-message "required from here" }
+
+template void g() {
+ C auto x = 0; // { dg-error "constraints" }
+}
+
+template void g<>(); // { dg-bogus "" }
+template void g(); // { dg-message "required from here" }
+
+template void h() {
+ C auto x = 0; // { dg-error "constraints" }
+ C auto y = 0;
+}
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833
--- Comment #3 from Marek Polacek ---
Reduced:
namespace std {
template struct integral_constant {
static constexpr int value = __v;
};
template struct tuple_size;
template struct tuple_element;
template
using __tuple_element_t = typename tuple_element<__i, _Tp>::type;
template class tuple;
template tuple(_UTypes...) -> tuple<_UTypes...>;
template class tuple<_T1, _T2> {
public:
template tuple(_U1, _U2);
};
template
struct tuple_size>
: integral_constant {};
template
struct tuple_element<__i, tuple<_Head, _Tail...>>
: tuple_element<__i - 1, tuple<_Tail...>> {};
template
struct tuple_element<0, tuple<_Head, _Tail...>> {
typedef _Head type;
};
template
__tuple_element_t<__i, tuple<_Elements...>> get(tuple<_Elements...>);
} // namespace std
void f(auto x) {
[&](auto...) {
auto y = std::tuple{"", x};
if constexpr (auto [_, z] = y; requires { z; })
;
}();
}
auto main() -> int { f(2); }
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 Marek Polacek changed: What|Removed |Added Build|-std=c++20 | CC||ppalka at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r11-372. So may be a P1 :(.
Re: [PATCH] c++: Adjust mangling of __alignof__ [PR88115]
On 3/30/21 3:17 PM, Patrick Palka wrote:
We currently mangle __alignof__ as a vendor extended operator,
but that's problematic for the reasons mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6.
This patch changes the mangling of __alignof__ to instead use the
new "vendor extended expression" syntax that's proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/112. Clang does
the same thing already, so after this patch both GCC and Clang agree
about the mangling of __alignof__(type) and __alignof__(expr).
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
gcc/cp/ChangeLog:
PR c++/88115
* mangle.c (write_expression): Adjust the mangling of
__alignof__.
include/ChangeLog:
PR c++/88115
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_VENDOR_EXPR.
libiberty/ChangeLog:
PR c++/88115
* cp-demangle.c (d_dump, d_make_comp, d_expression_1)
(d_count_templates_scopes): Handle DEMANGLE_COMPONENT_VENDOR_EXPR.
(d_print_comp_inner): Likewise.
: Revert r11-4926
change.
: Likewise.
* testsuite/demangle-expected: Adjust __alignof__ mangling
tests.
gcc/testsuite/ChangeLog:
PR c++/88115
* g++.dg/cpp0x/alignof7.C: Adjust expected mangling.
---
gcc/cp/mangle.c | 8 ++---
gcc/testsuite/g++.dg/cpp0x/alignof7.C | 4 +--
include/demangle.h| 3 ++
libiberty/cp-demangle.c | 47 +++
libiberty/testsuite/demangle-expected | 4 +--
5 files changed, 37 insertions(+), 29 deletions(-)
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 0a9e5aa79a0..57ce9a6710f 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3124,11 +3124,9 @@ write_expression (tree expr)
if (abi_version_at_least (15))
{
/* We used to mangle __alignof__ like alignof. */
- write_string ("v111__alignof__");
- if (TYPE_P (TREE_OPERAND (expr, 0)))
- write_type (TREE_OPERAND (expr, 0));
- else
- write_expression (TREE_OPERAND (expr, 0));
+ write_string ("u11__alignof__");
+ write_template_arg (TREE_OPERAND (expr, 0));
+ write_char ('E');
return;
}
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/alignof7.C
b/gcc/testsuite/g++.dg/cpp0x/alignof7.C
index a4d7f24a4d7..2369b879392 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alignof7.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alignof7.C
@@ -18,5 +18,5 @@ template void f4(std::size_t);
// { dg-final { scan-assembler "_Z2f1IiEvDTatT_E" } }
// { dg-final { scan-assembler "_Z2f2IiEvDTaztlT_EE" } }
-// { dg-final { scan-assembler "_Z2f3IiEvDTv111__alignof__T_E" } }
-// { dg-final { scan-assembler "_Z2f4IiEvDTv111__alignof__tlT_EE" } }
+// { dg-final { scan-assembler "_Z2f3IiEvDTu11__alignof__T_EE" } }
+// { dg-final { scan-assembler "_Z2f4IiEvDTu11__alignof__XtlT_" } }
diff --git a/include/demangle.h b/include/demangle.h
index 23b47265d94..b45234e6887 100644
--- a/include/demangle.h
+++ b/include/demangle.h
@@ -408,6 +408,9 @@ enum demangle_component_type
number which involves neither modifying the mangled string nor
allocating a new copy of the literal in memory. */
DEMANGLE_COMPONENT_LITERAL_NEG,
+ /* A vendor's builtin expression. The left subtree holds the name of
+ the type, and the right subtree is a template argument list. */
+ DEMANGLE_COMPONENT_VENDOR_EXPR,
/* A libgcj compiled resource. The left subtree is the name of the
resource. */
DEMANGLE_COMPONENT_JAVA_RESOURCE,
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index d3e798455cc..a528b7b5ed3 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -815,6 +815,9 @@ d_dump (struct demangle_component *dc, int indent)
case DEMANGLE_COMPONENT_LITERAL_NEG:
printf ("negative literal\n");
break;
+case DEMANGLE_COMPONENT_VENDOR_EXPR:
+ printf ("vendor expression\n");
+ break;
case DEMANGLE_COMPONENT_JAVA_RESOURCE:
printf ("java resource\n");
break;
@@ -976,6 +979,7 @@ d_make_comp (struct d_info *di, enum
demangle_component_type type,
case DEMANGLE_COMPONENT_TRINARY_ARG1:
case DEMANGLE_COMPONENT_LITERAL:
case DEMANGLE_COMPONENT_LITERAL_NEG:
+case DEMANGLE_COMPONENT_VENDOR_EXPR:
case DEMANGLE_COMPONENT_COMPOUND_NAME:
case DEMANGLE_COMPONENT_VECTOR_TYPE:
case DEMANGLE_COMPONENT_CLONE:
@@ -3345,6 +3349,7 @@ d_unresolved_name (struct d_info *di)
::= st
::=
::=
+ ::= u * E # vendor extended
expression
::=
::=
@@ -3425,6 +3430,15 @@ d_expression_1 (struct d_info *di)
return d_make_comp (di, DEMANGLE_COMPONENT_INITIALIZER_LIST,
Re: [PATCH] dwarf2out: Fix up ranges for -gdwarf-5 -gsplit-dwarf [PR99490]
On 3/12/21 3:20 AM, Jakub Jelinek wrote:
Hi!
For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section
(so in the binaries/shared libraries) with DW_AT_ranges from skeleton
units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset
(and DW_AT_GNU_ranges_base pointing into section, not sure for what
reason exactly).
When DWARF5 support was being added, we've started using .debug_rnglists
section, added DW_AT_rnglists_base to the DW_TAG_skeleton_unit, kept
DW_AT_ranges with DW_FORM_sec_offset in the skeleton and switched
over to DW_FORM_rnglistx for DW_AT_ranges in .debug_info.dwo.
But the DWARF5 spec actually means for the ranges section (at least
everything for those DW_AT_ranges in .debug_info.dwo) to sit
in .debug_rnglists.dwo section next to the .debug_info.dwo, rather than
having consumers look it up in the binary/shared library instead.
Based on some discussions in the DWARF discuss mailing list:
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-March/thread.html#4765
this patch mostly follows what LLVM emits for that right now:
1) small .debug_rnglists section (when needed) just to cover the
skeleton DW_AT_ranges (if present); the content of the section
uses the Split DWARFy DW_RLE_* codes with addrx encodings where
possible
2) DW_AT_ranges in the skeleton uses DW_FORM_sec_offset (difference
from LLVM which uses DW_FORM_rnglistx, which makes it larger
and ambiguous)
3) DW_AT_rnglists_base attribute is gone from the skeleton (again,
unlike LLVM where it is just confusing what exactly it means because
it is inherited; it would make sense if we emitted DW_FORM_rnglistx
in non-split DWARF, but unless ranges are shared, I'm afraid we'd
make DWARF larger with fewer relocations by that)
4) usually big .debug_rnglists.dwo section again with using DW_RLE_*x*
where possible
5) DW_AT_ranges with DW_FORM_rnglistx from .debug_info.dwo referring to
that .debug_rnglists.dwo ranges
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-03-12 Jakub Jelinek
PR debug/99490
* dwarf2out.c (debug_ranges_dwo_section): New variable.
(DW_RANGES_IDX_SKELETON): Define.
(struct dw_ranges): Add begin_entry and end_entry members.
(DEBUG_DWO_RNGLISTS_SECTION): Define.
(add_ranges_num): Adjust r initializer for addition of *_entry
members.
(add_ranges_by_labels): For -gsplit-dwarf and force_direct,
set idx to DW_RANGES_IDX_SKELETON.
(index_rnglists): Don't set r->idx if it is equal to
DW_RANGES_IDX_SKELETON. Initialize r->begin_entry and
r->end_entry for -gsplit-dwarf if those will be needed by
output_rnglists.
(output_rnglists): Add DWO argument. If true, switch to
debug_ranges_dwo_section rather than debug_ranges_section.
Adjust l1/l2 label indexes. Only output the offset table when
dwo is true and don't include in there the skeleton range
entry if present. For -gsplit-dwarf, skip ranges that belong
to the other rnglists section. Change return type from void
to bool and return true if there are any range entries for
the other section. For dwarf_split_debug_info use
DW_RLE_startx_endx, DW_RLE_startx_length and DW_RLE_base_addressx
entries instead of DW_RLE_start_end, DW_RLE_start_length and
DW_RLE_base_address.
(init_sections_and_labels): Initialize debug_ranges_dwo_section
if -gsplit-dwarf and DWARF >= 5. Adjust ranges_section_label
and range_base_label indexes.
(dwarf2out_finish): Call index_rnglists earlier before finalizing
.debug_addr. Never emit DW_AT_rnglists_base attribute. For
-gsplit-dwarf and DWARF >= 5 call output_rnglists up to twice
with different dwo arguments.
(dwarf2out_c_finalize): Clear debug_ranges_dwo_section.
--- gcc/dwarf2out.c.jj 2021-03-10 17:36:37.037537129 +0100
+++ gcc/dwarf2out.c 2021-03-11 12:50:00.402418873 +0100
@@ -171,6 +171,7 @@ static GTY(()) section *debug_line_str_s
static GTY(()) section *debug_str_dwo_section;
static GTY(()) section *debug_str_offsets_section;
static GTY(()) section *debug_ranges_section;
+static GTY(()) section *debug_ranges_dwo_section;
static GTY(()) section *debug_frame_section;
/* Maximum size (in bytes) of an artificially generated label. */
@@ -3152,11 +3153,17 @@ struct GTY(()) dw_ranges {
/* If this is positive, it's a block number, otherwise it's a
bitwise-negated index into dw_ranges_by_label. */
int num;
+ /* If idx is equal to DW_RANGES_IDX_SKELETON, it should be emitted
+ into .debug_rnglists section rather than .debug_rnglists.dwo
+ for -gsplit-dwarf and DWARF >= 5. */
+#define DW_RANGES_IDX_SKELETON ((1U << 31) - 1)
/* Index for the range list for DW_FORM_rnglistx. */
unsigned int idx : 31;
/* True if this range might be
[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 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed then. Thanks for checking!
[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 99427, which changed state. Bug 99427 Summary: [modules] in system headers: non-constant condition for static assertion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99427 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[PATCH] c++: placeholder type constraint and argument packs [PR99815]
When checking dependence of a placeholder type constraint, if the first
template argument of the constraint is an argument pack, we need to
expand it so that we properly separate the implicit 'auto' argument from
the rest.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/99815
* pt.c (placeholder_type_constraint_dependent_p): Expand
argument packs to separate the first non-pack argument
from the rest.
gcc/testsuite/ChangeLog:
PR c++/99815
* g++.dg/cpp2a/concepts-placeholder5.C: New test.
---
gcc/cp/pt.c | 5 +++
.../g++.dg/cpp2a/concepts-placeholder5.C | 32 +++
2 files changed, 37 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a056ecefd1d..dc6f2f37f9b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28189,6 +28189,11 @@ placeholder_type_constraint_dependent_p (tree t)
tree id = unpack_concept_check (t);
tree args = TREE_OPERAND (id, 1);
tree first = TREE_VEC_ELT (args, 0);
+ if (ARGUMENT_PACK_P (first))
+{
+ args = expand_template_argument_pack (args);
+ first = TREE_VEC_ELT (args, 0);
+}
gcc_checking_assert (TREE_CODE (first) == WILDCARD_DECL
|| is_auto (first));
for (int i = 1; i < TREE_VEC_LENGTH (args); ++i)
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
new file mode 100644
index 000..eaea41a36eb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder5.C
@@ -0,0 +1,32 @@
+// PR c++/99815
+// { dg-do compile { target c++20 } }
+
+template
+struct is_same { static constexpr bool value = false; };
+
+template
+struct is_same { static constexpr bool value = true; };
+
+template
+concept C = is_same::value; // { dg-error "wrong number" }
+
+template void f() {
+ C auto x = 0; // { dg-error "constraints" }
+}
+
+template void f(); // { dg-bogus "" }
+template void f(); // { dg-message "required from here" }
+template void f<>(); // { dg-message "required from here" }
+template void f(); // { dg-message "required from here" }
+
+template void g() {
+ C auto x = 0; // { dg-error "constraints" }
+}
+
+template void g<>(); // { dg-bogus "" }
+template void g(); // { dg-message "required from here" }
+
+template void h() {
+ C auto x = 0; // { dg-error "constraints" }
+ C auto y = 0;
+}
--
2.31.1.133.g84d06cdc06
[Bug c++/99427] [modules] in system headers: non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99427 --- Comment #4 from Alexander Lelyakin --- Not reproduced anymore
Re: [PATCH, rs6000 V3] Update "prefix" attribute for Power10 [PR99133]
Hi! On Tue, Mar 30, 2021 at 02:38:32PM -0500, Pat Haugen wrote: > Update prefixed attribute for Power10. > > This patch creates a new attribute, "maybe_prefixed", which is used to mark > those instructions that may have a prefixed form. The existing "prefixed" > attribute is now used to mark all instructions that are prefixed form. It doesn't yet set maybe_prefixed on most insns that will need it? What does that mean for say movsi that can be plwz? > +;; Whether this insn has a prefixed form and a non-prefixed form. > +(define_attr "maybe_prefixed" "no,yes" > + (if_then_else (eq_attr "type" "load,fpload,vecload,store,fpstore,vecstore, > + integer,add") > + (const_string "yes") > + (const_string "no"))) Ah. Okay :-) It probably is better to set the maybe_prefixed attribute explicitly, but this will do for now. Status quo and all that. I don't see how the "add" and "integer" cases can work... > (define_attr "prefixed" "no,yes" >(cond [(ior (match_test "!TARGET_PREFIXED") > - (match_test "!NONJUMP_INSN_P (insn)")) > + (match_test "!NONJUMP_INSN_P (insn)") > + (eq_attr "maybe_prefixed" "no")) >(const_string "no") It's a cond, so you can have separate cases instead of ior, if that reads better (the generated compiler code will be equivalent). It can help if you want to place some comments, for example ;-) Okay for trunk. Thank you! Segher
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2021-03-30
Keywords||ice-on-valid-code
Target Milestone|--- |8.5
Status|UNCONFIRMED |NEW
Summary|structured binding + if |[8/9/10/11 Regression]
|init + generic lambda = |structured binding + if
|internal compiler error |init + generic lambda =
||internal compiler error
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed.
$ xg++-7 -c 99833.C -std=c++17 -fconcepts
# ok
$ xg++-8 -c 99833.C -std=c++17 -fconcepts
99833.C: In instantiation of ‘f(auto:1&&) [with auto:1 = int]:: [with auto:2 = {}]’:
99833.C:8:10: required from ‘auto f(auto:1&&) [with auto:1 = int]’
99833.C:12:13: required from here
99833.C:6:32: internal compiler error: in tsubst_decomp_names, at cp/pt.c:16673
if constexpr (auto [_, z] = y; requires { z; })
^~
0xa44cc6 tsubst_decomp_names
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16673
0xa46041 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16837
0xa4b103 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17512
0xa46e75 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16961
0xa45012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16714
0xa475be tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17014
0xa475be tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17014
0xa45012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16714
0xa475be tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17014
0xa68a40 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:24161
0x90b1e3 maybe_instantiate_decl
/home/mpolacek/src/gcc8/gcc/cp/decl2.c:5211
0x90bb8a mark_used(tree_node*, int)
/home/mpolacek/src/gcc8/gcc/cp/decl2.c:5312
0x814c71 build_over_call
/home/mpolacek/src/gcc8/gcc/cp/call.c:8286
0x804e91 build_op_call_1
/home/mpolacek/src/gcc8/gcc/cp/call.c:4589
0x805053 build_op_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc8/gcc/cp/call.c:4618
0xa9a847 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc8/gcc/cp/semantics.c:2567
0xa503bf tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:18594
0xa4b422 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:17530
0xa4512d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16728
0xa45012 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc8/gcc/cp/pt.c:16714
[PATCH] aarch64: Fix up *add3_poly_1 [PR99813]
Hi!
As mentioned in the PR, Uai constraint stands for
aarch64_sve_scalar_inc_dec_immediate
while Uav for
aarch64_sve_addvl_addpl_immediate.
Both *add3_aarch64 and *add3_poly_1 patterns use
* return aarch64_output_sve_scalar_inc_dec (operands[2]);
* return aarch64_output_sve_addvl_addpl (operands[2]);
in that order, but the former with Uai,Uav order, while the
latter with Uav,Uai instead. This patch swaps the constraints
so that they match the output.
Bootstrapped/regtested on aarch64-linux, ok for trunk?
2021-03-30 Jakub Jelinek
Richard Sandiford
PR target/99813
* config/aarch64/aarch64.md (*add3_poly_1): Swap Uai and Uav
constraints on operands[2] and similarly 0 and rk constraints
on operands[1] corresponding to that.
* g++.target/aarch64/sve/pr99813.C: New test.
--- gcc/config/aarch64/aarch64.md.jj2021-02-25 23:07:07.851319165 +0100
+++ gcc/config/aarch64/aarch64.md 2021-03-30 11:13:35.994077470 +0200
@@ -2050,8 +2050,8 @@
[(set
(match_operand:GPI 0 "register_operand" "=r,r,r,r,r,r,")
(plus:GPI
- (match_operand:GPI 1 "register_operand" "%rk,rk,rk,rk,rk,0,rk")
- (match_operand:GPI 2 "aarch64_pluslong_or_poly_operand"
"I,r,J,Uaa,Uav,Uai,Uat")))]
+ (match_operand:GPI 1 "register_operand" "%rk,rk,rk,rk,0,rk,rk")
+ (match_operand:GPI 2 "aarch64_pluslong_or_poly_operand"
"I,r,J,Uaa,Uai,Uav,Uat")))]
"TARGET_SVE && operands[0] != stack_pointer_rtx"
"@
add\\t%0, %1, %2
--- gcc/testsuite/g++.target/aarch64/sve/pr99813.C.jj 2021-03-30
11:22:13.430290522 +0200
+++ gcc/testsuite/g++.target/aarch64/sve/pr99813.C 2021-03-30
11:22:55.526819721 +0200
@@ -0,0 +1,27 @@
+// PR target/99813
+/* { dg-do assemble { target aarch64_asm_sve_ok } } */
+/* { dg-options "-O3 -march=armv8.2-a+sve -fvect-cost-model=unlimited
-fno-tree-dominator-opts -mtune=cortex-a72" } */
+
+long a, b;
+bool c[2][14][2][16], f[2][14][2][16];
+bool d;
+char e[2][4][2][6];
+void g() {
+ a = 0;
+ for (int h = 0; h < 2; ++h)
+for (int i = 0; i < 14; ++i)
+ for (int j = 0; j < 2; ++j)
+for (int k = 0; k < 16; ++k)
+ c[h][i][j][k] = 0;
+ d = 0;
+ for (int h; h < 2; ++h)
+for (int i = 0; i < 4; ++i)
+ for (int j = 0; j < 2; ++j)
+for (int k = 0; k < 6; ++k)
+ e[h][i][j][k] = 6;
+ for (int h = 0; h < 2; ++h)
+for (int i = 0; i < 14; ++i)
+ for (int j = 0; j < 2; ++j)
+for (int k = 0; k < 16; ++k)
+ f[h][i][j][k] = b = 9;
+}
Jakub
[Bug fortran/99839] [8/9/10/11 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |8.5 Summary|ICE in |[8/9/10/11 Regression] ICE |inline_matmul_assign, at|in inline_matmul_assign, at |fortran/frontend-passes.c:4 |fortran/frontend-passes.c:4 |234 |234
[Bug c++/99841] (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
(In reply to g.peterhoff from comment #2)
> That is not the problem. I only made using type = ... and type(x) in the
> ctor calls so that I can test different types. You like to throw that out -
> has no influence.
I think you misunderstood.
Take a look at:
mm_pair_t m{type(1), type(2)};
there are two temps here created by type(1) and type(2). The lifetime of those
temps normally end at the end of the statement, unless they are extended due to
the C++ rules of binding the temp to a reference. In this case they are not
bound to a reference as the reference is not m but rather the constructor
arguments (this is why mm_t works while the others don't).
Adding -W -Wall -Werror to the command line we get the following
warnings/errors:
: In function 'int main()':
:33:24: error: '' is used uninitialized
[-Werror=uninitialized]
33 | std::cout << m.first << std::endl;
|^
:34:24: error: '' is used uninitialized
[-Werror=uninitialized]
34 | std::cout << m.second << std::endl;
|^~
:39:35: error: '' is used uninitialized
[-Werror=uninitialized]
39 | std::cout << std::get<0>(m) << std::endl;
| ^
:40:35: error: '' is used uninitialized
[-Werror=uninitialized]
40 | std::cout << std::get<1>(m) << std::endl;
| ^
:45:24: error: '' is used uninitialized
[-Werror=uninitialized]
45 | std::cout << m.min << std::endl;
|^~~
:46:24: error: '' is used uninitialized
[-Werror=uninitialized]
46 | std::cout << m.max << std::endl;
|^~~
- CUT
Which is exactly what you expect when the temp rvalue does not gets its
timeline extended past the end of that statement.
[Bug fortran/99839] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||anlauf at gcc dot gnu.org,
||tkoenig at gcc dot gnu.org
Last reconfirmed||2021-03-30
Ever confirmed|0 |1
Priority|P3 |P4
--- Comment #1 from anlauf at gcc dot gnu.org ---
This one is funny. Simply punting on non-numeric and non-logical results
works around the ICE.
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 7d3eae67632..213530e46e1 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -4193,6 +4193,19 @@ inline_matmul_assign (gfc_code **c, int *walk_subtrees,
if (m_case == none)
return 0;
+ /* We only handle assignment to numeric or logical variables. */
+ switch(expr1->ts.type)
+{
+case BT_INTEGER:
+case BT_LOGICAL:
+case BT_REAL:
+case BT_COMPLEX:
+ break;
+
+default:
+ return 0;
+}
+
ns = insert_block ();
/* Assign the type of the zero expression for initializing the resulting
Adding Thomas, who knows the code better.
[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648 --- Comment #4 from seurer at gcc dot gnu.org --- Which RTL do you want to see?
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Patch. Check if a or b is zero-sized. diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c index 388aca7c38c..6c5259c648d 100644 --- a/gcc/fortran/simplify.c +++ b/gcc/fortran/simplify.c @@ -4728,7 +4728,9 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr *matrix_b) int stride_a, offset_a, stride_b, offset_b; if (!is_constant_array_expr (matrix_a) - || !is_constant_array_expr (matrix_b)) + || gfc_is_size_zero_array (matrix_a) + || !is_constant_array_expr (matrix_b) + || gfc_is_size_zero_array (matrix_b)) return NULL; /* MATMUL should do mixed-mode arithmetic. Set the result type. */
[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648 --- Comment #3 from seurer at gcc dot gnu.org --- The assembler isn't that long so here it is (from -Os): .file "pr71522.c" .machine power8 .section".text" .section.rodata.str1.1,"aMS",@progbits,1 .LC1: .string "AAA" .section.text.startup,"ax",@progbits .align 2 .globl main .type main, @function main: .LFB0: .cfi_startproc lis 9,.LC0@ha stwu 1,-48(1) .cfi_def_cfa_offset 48 mflr 0 la 9,.LC0@l(9) lis 4,.LC1@ha la 4,.LC1@l(4) lfd 0,0(9) lfd 1,8(9) lis 9,0x4151 ori 9,9,0x4141 addi 3,1,8 stw 0,52(1) .cfi_offset 65, 4 stw 9,8(1) lis 9,0x4141 ori 9,9,0x4120 stfd 0,32(1) stfd 1,40(1) stw 9,12(1) lis 9,0x3e00 stw 9,16(1) li 9,0 stw 9,20(1) bl strcmp cmpwi 0,3,0 beq 0,.L2 bl abort .L2: lwz 0,52(1) addi 1,1,48 .cfi_def_cfa_offset 0 mtlr 0 .cfi_restore 65 blr .cfi_endproc .LFE0: .size main,.-main .section.rodata.cst16,"aM",@progbits,16 .align 4 .LC0: .long 1095844161 .long 1094795552 .long 1040187392 .long 0 .ident "GCC: (GNU) 11.0.1 20210329 (experimental) [remotes/origin/HEAD revision c277abd:ad0a649:953624089be3f51c2ebacba65be8521bf6ae8430]" .gnu_attribute 4, 5 .section.note.GNU-stack,"",@progbits
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283
--- Comment #16 from Alexander Lelyakin ---
Still reproduces:
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header system_error
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ccomplex
In file included from /usr/local/include/c++/11.0.1/ios:42,
from /usr/local/include/c++/11.0.1/istream:38,
from /usr/local/include/c++/11.0.1/sstream:38,
from /usr/local/include/c++/11.0.1/complex:45,
from /usr/local/include/c++/11.0.1/ccomplex:39:
/usr/local/include/c++/11.0.1/bits/ios_base.h:205:69: internal compiler error:
in assert_definition, at cp/module.cc:4491
205 | template <> struct is_error_code_enum : public true_type {
};
| ^
0x6e20eb trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4491
0xa5db60 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11323
0xa6d21f trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11403
0xa6f711 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14806
0xa6fd8d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18068
0xa6fe4f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18726
0xa6a0d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa6aee6 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6662
0xa68937 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68937 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68d6f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6ab71 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
0xa68937 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68937 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68d6f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6ab71 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
0xa68937 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68937 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68d6f trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6ab71 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
g++ (GCC) 11.0.1 20210330 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
commit 5f3c6027257118469a722816e228394b5978ddb0 (HEAD -> master, origin/trunk,
origin/master, origin/HEAD)
Author: Nathan Sidwell
Date: Tue Mar 30 09:45:59 2021 -0700
c++: duplicate const static members [PR 99283]
[Bug c++/99841] (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841 --- Comment #2 from g.peterh...@t-online.de --- That is not the problem. I only made using type = ... and type(x) in the ctor calls so that I can test different types. You like to throw that out - has no influence.
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-30 Known to fail||10.2.1, 11.0, 8.4.1, 9.3.1 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. This one is funny. The TRANSPOSE seems to screw up the simplification. Works without TRANSPOSE.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #5 from Jan Hubicka --- > Btw, one solution would be to drop __always_inline__ after always-inline > inlining > and thus make it reliably not present for IPA inlining. Removing it would make you to lose those errors, but we can ignore it for late inlining if we decide we do not really care about always inlining indirect calls (that are not reliably inlined by early inliner). But I tried that at some point and broke kernel. Note that we could also use syntactic aliase and consider two decls unmergeable if they differ by always_inline attribute. That should make it to behave consistently... Honza
[Bug c++/99841] (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841
--- Comment #1 from Andrew Pinski ---
The question is:
mm_pair_t m{type(1), type(2)};
I think GCC is correct here, type(1) is a temp and it does not bind to a field
directly, it goes through a constructure and therefor the temp goes away right
after the statement is done.
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 --- Comment #7 from Marek Polacek --- There was en error + ICE, but since r11-5752 we only have the ICE. Looks like the ICE started with r277865.
Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU
Hi,
this patch backports the initial support to gcc10 branch. Since the
trunk and branch diverged there is non-trivial change to cpuinfo
discovery. I do;
--- a/libgcc/config/i386/cpuinfo.c
+++ b/libgcc/config/i386/cpuinfo.c
@@ -111,6 +111,12 @@ get_amd_cpu (unsigned int family, unsigned int model)
if (model >= 0x30)
__cpu_model.__cpu_subtype = AMDFAM17H_ZNVER2;
break;
+case 0x19:
+ __cpu_model.__cpu_type = AMDFAM19H;
+ /* AMD family 19h version 1. */
+ if (model <= 0x0f)
+ __cpu_model.__cpu_subtype = AMDFAM19H_ZNVER3;
+ break;
default:
break;
}
While your patch also sets ZNVER3 for case where VAES is supporte that
would require backporting more of logic detecting VAES. Is that
necessary? I see it may make znver3 to be defaulted on future znver4 if
it stays with amdfam19, but we did not do this before.
Bootstrapped/regtested x86_64-linux. With -march=native on znver3
machine we get right flags, but trunk in addition passes:
-mno-amx-bf16
-mno-amx-int8
-mno-amx-tile
-mno-avxvnni
-mno-hreset
-mno-kl
-mno-serialize
-mno-tsxldtrk
-mno-uintr
-mno-widekl
Which are options we did not backported.
Atop of that I plan to backport the tuning patches with exception of
gather which seems bit controversal and can wait for gcc11.
Honza
2021-03-30 Jan Hubicka
Backport
Venkataramanan Kumar
Sharavan Kumar
* common/config/i386/cpuinfo.h (get_amd_cpu) recognize znver3.
* common/config/i386/i386-common.c (processor_names): Add
znver3.
(processor_alias_table): Add znver3 and AMDFAM19H entry.
* common/config/i386/i386-cpuinfo.h (processor_types): Add
AMDFAM19H.
(processor_subtypes): AMDFAM19H_ZNVER3.
* config.gcc (i[34567]86-*-linux* | ...): Likewise.
* config/i386/driver-i386.c: (host_detect_local_cpu): Let
-march=native recognize znver3 processors.
* config/i386/i386-c.c (ix86_target_macros_internal): Add
znver3.
* config/i386/i386-options.c (m_znver3): New definition.
(m_ZNVER): Include m_znver3.
(processor_cost_table): Add znver3.
* config/i386/i386.c (ix86_reassociation_width): Likewise.
* config/i386/i386.h (TARGET_znver3): New definition.
(enum processor_type): Add PROCESSOR_ZNVER3.
* config/i386/i386.md (define_attr "cpu"): Add znver3.
* config/i386/x86-tune-sched.c: (ix86_issue_rate): Likewise.
(ix86_adjust_cost): Likewise.
* config/i386/x86-tune.def (X86_TUNE_AVOID_256FMA_CHAINS:
Likewise.
* config/i386/znver1.md: Add new reservations for znver3.
* doc/extend.texi: Add details about znver3.
* doc/invoke.texi: Likewise.
gcc/testsuite/ChangeLog:
2021-03-30 Jan Hubicka
* gcc.target/i386/funcspec-56.inc: Handle new march.
libgcc/ChangeLog:
2021-03-30 Jan Hubicka
* config/i386/cpuinfo.c (get_amd_cpu): Support amdfam19.
* config/i386/cpuinfo.h (enum processor_types): Add AMDFAM19H.
(enum processor_subtypes): Add AMDFAM19H_ZNVER3.
diff --git a/gcc/common/config/i386/i386-common.c
b/gcc/common/config/i386/i386-common.c
index 1e4d25f052a..97335d42af1 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -1582,7 +1582,8 @@ const char *const processor_names[] =
"btver1",
"btver2",
"znver1",
- "znver2"
+ "znver2",
+ "znver3"
};
/* Guarantee that the array is aligned with enum processor_type. */
@@ -1775,6 +1776,16 @@ const pta processor_alias_table[] =
| PTA_CLZERO | PTA_CLFLUSHOPT | PTA_XSAVEC | PTA_XSAVES
| PTA_SHA | PTA_LZCNT | PTA_POPCNT | PTA_CLWB | PTA_RDPID
| PTA_WBNOINVD},
+ {"znver3", PROCESSOR_ZNVER2, CPU_ZNVER2,
+PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
+ | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
+ | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_AVX2
+ | PTA_BMI | PTA_BMI2 | PTA_F16C | PTA_FMA | PTA_PRFCHW
+ | PTA_FXSR | PTA_XSAVE | PTA_XSAVEOPT | PTA_FSGSBASE
+ | PTA_RDRND | PTA_MOVBE | PTA_MWAITX | PTA_ADX | PTA_RDSEED
+ | PTA_CLZERO | PTA_CLFLUSHOPT | PTA_XSAVEC | PTA_XSAVES
+ | PTA_SHA | PTA_LZCNT | PTA_POPCNT | PTA_CLWB | PTA_RDPID
+ | PTA_WBNOINVD | PTA_VAES | PTA_VPCLMULQDQ | PTA_PKU},
{"btver1", PROCESSOR_BTVER1, CPU_GENERIC,
PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
| PTA_SSSE3 | PTA_SSE4A | PTA_ABM | PTA_CX16 | PTA_PRFCHW
diff --git a/gcc/config.gcc b/gcc/config.gcc
index d093b6b7f79..6fcdd771d4c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -662,7 +662,7 @@ pentium4 pentium4m pentiumpro prescott lakemont"
# 64-bit x86 processors supported by --with-arch=. Each processor
# MUST be separated by exactly one space.
x86_64_archs="amdfam10 athlon64 athlon64-sse3 barcelona bdver1 bdver2 \
-bdver3 bdver4 znver1 znver2 btver1 btver2 k8 k8-sse3 opteron \
+bdver3 bdver4
[Bug other/99496] [11 regression] g++.dg/modules/xtreme-header-3_c.C ICEs after r11-7557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496 seurer at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from seurer at gcc dot gnu.org --- I just double checked and these are all fixed now. Thanks!
[Bug fortran/99819] [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 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-30 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. I believe there are tons of duplicates of this one.
[PATCH, rs6000 V3] Update "prefix" attribute for Power10 [PR99133]
Update prefixed attribute for Power10. This patch creates a new attribute, "maybe_prefixed", which is used to mark those instructions that may have a prefixed form. The existing "prefixed" attribute is now used to mark all instructions that are prefixed form. This patch differs from the prior version in that it doesn't modify the existing settings of the "prefixed" attribute but just adds the new attribute and sets/tests it appropriately. Bootstrap/regtest on powerpc64le (Power10) and powerpc64 (Power8 32/64) with no new regressions. Ok for trunk? -Pat 2021-03-30 Pat Haugen gcc/ PR target/99133 * config/rs6000/altivec.md (xxspltiw_v4si, xxspltiw_v4sf_inst, xxspltidp_v2df_inst, xxsplti32dx_v4si_inst, xxsplti32dx_v4sf_inst, xxblend_, xxpermx_inst, xxeval): Mark prefixed. * config/rs6000/mma.md (mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_, mma_): Likewise. * config/rs6000/rs6000.c (rs6000_final_prescan_insn): Adjust test. * config/rs6000/rs6000.md (define_attr "maybe_prefixed"): New. (define_attr "prefixed"): Update initializer. diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md index 27a269b9e72..21f1cc6f15b 100644 --- a/gcc/config/rs6000/altivec.md +++ b/gcc/config/rs6000/altivec.md @@ -826,7 +826,8 @@ (define_insn "xxspltiw_v4si" UNSPEC_XXSPLTIW))] "TARGET_POWER10" "xxspltiw %x0,%1" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") + (set_attr "prefixed" "yes")]) (define_expand "xxspltiw_v4sf" [(set (match_operand:V4SF 0 "register_operand" "=wa") @@ -845,7 +846,8 @@ (define_insn "xxspltiw_v4sf_inst" UNSPEC_XXSPLTIW))] "TARGET_POWER10" "xxspltiw %x0,%1" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") + (set_attr "prefixed" "yes")]) (define_expand "xxspltidp_v2df" [(set (match_operand:V2DF 0 "register_operand" ) @@ -864,7 +866,8 @@ (define_insn "xxspltidp_v2df_inst" UNSPEC_XXSPLTID))] "TARGET_POWER10" "xxspltidp %x0,%1" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") + (set_attr "prefixed" "yes")]) (define_expand "xxsplti32dx_v4si" [(set (match_operand:V4SI 0 "register_operand" "=wa") @@ -893,7 +896,8 @@ (define_insn "xxsplti32dx_v4si_inst" UNSPEC_XXSPLTI32DX))] "TARGET_POWER10" "xxsplti32dx %x0,%2,%3" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") + (set_attr "prefixed" "yes")]) (define_expand "xxsplti32dx_v4sf" [(set (match_operand:V4SF 0 "register_operand" "=wa") @@ -921,7 +925,8 @@ (define_insn "xxsplti32dx_v4sf_inst" UNSPEC_XXSPLTI32DX))] "TARGET_POWER10" "xxsplti32dx %x0,%2,%3" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") + (set_attr "prefixed" "yes")]) (define_insn "xxblend_" [(set (match_operand:VM3 0 "register_operand" "=wa") @@ -931,7 +936,8 @@ (define_insn "xxblend_" UNSPEC_XXBLEND))] "TARGET_POWER10" "xxblendv %x0,%x1,%x2,%x3" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") + (set_attr "prefixed" "yes")]) (define_expand "xxpermx" [(set (match_operand:V2DI 0 "register_operand" "+wa") @@ -975,7 +981,8 @@ (define_insn "xxpermx_inst" UNSPEC_XXPERMX))] "TARGET_POWER10" "xxpermx %x0,%x1,%x2,%x3,%4" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") + (set_attr "prefixed" "yes")]) (define_expand "vstrir_" [(set (match_operand:VIshort 0 "altivec_register_operand") @@ -3623,7 +3630,8 @@ (define_insn "xxeval" UNSPEC_XXEVAL))] "TARGET_POWER10" "xxeval %0,%1,%2,%3,%4" - [(set_attr "type" "vecsimple")]) + [(set_attr "type" "vecsimple") +(set_attr "prefixed" "yes")]) (define_expand "vec_unpacku_hi_v16qi" [(set (match_operand:V8HI 0 "register_operand" "=v") diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md index a00d3a3de26..1f6fc03d2ac 100644 --- a/gcc/config/rs6000/mma.md +++ b/gcc/config/rs6000/mma.md @@ -540,7 +540,8 @@ (define_insn "mma_" MMA_VVI4I4I8))] "TARGET_MMA" " %A0,%x1,%x2,%3,%4,%5" - [(set_attr "type" "mma")]) + [(set_attr "type" "mma") + (set_attr "prefixed" "yes")]) (define_insn "mma_" [(set (match_operand:XO 0 "fpr_reg_operand" "=") @@ -553,7 +554,8 @@ (define_insn "mma_" MMA_AVVI4I4I8))] "TARGET_MMA" " %A0,%x2,%x3,%4,%5,%6" - [(set_attr "type" "mma")]) + [(set_attr "type" "mma") + (set_attr "prefixed" "yes")]) (define_insn "mma_" [(set (match_operand:XO 0 "fpr_reg_operand" "=") @@ -565,7 +567,8 @@ (define_insn "mma_" MMA_VVI4I4I2))] "TARGET_MMA" " %A0,%x1,%x2,%3,%4,%5" - [(set_attr "type" "mma")]) + [(set_attr "type" "mma") + (set_attr "prefixed" "yes")]) (define_insn "mma_" [(set (match_operand:XO 0 "fpr_reg_operand" "=")
[Bug c++/99841] New: (temporary) refs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99841 Bug ID: 99841 Summary: (temporary) refs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- please see https://godbolt.org/z/Ez1K7eofr gcc gives different (false?) results than clang/icc. If you set O0 or remove O-option gives same results.
Re: Looking at UNSUPPORTED dejagnu tests for a port...
On Tue, 30 Mar 2021 at 20:23, Alan Lehotsky wrote:
>
> I’m doing some final polishing on a gcc 8.3 upgrade and taking a look at the
> unsupported tests. Most of them are completely sensible (my port doesn’t
> support trampolines, for example). But gcc.c-torture/execute/pr78622.c is
> marked as unsupported. That appears to be due to the line
>
>{ dg-require-effective-target c99_runtime }
>
> I’m using newlib, and if I manually compile the test case with or without an
> explicit —std=c99, it compiles and links without error.
> Do I need to set something in the baseboards file or in a local .exp file to
> indicate that c99 is okay?
That effective-target is defined by this check:
# Return 1 if the target provides a full C99 runtime.
proc check_effective_target_c99_runtime { } {
return [check_cached_effective_target c99_runtime {
global srcdir
set file [open "$srcdir/gcc.dg/builtins-config.h"]
set contents [read $file]
close $file
append contents {
#ifndef HAVE_C99_RUNTIME
#error !HAVE_C99_RUNTIME
#endif
}
check_no_compiler_messages_nocache c99_runtime assembly $contents
}]
}
So it comes from the gcc/testsuite/gcc.dg/builtins-config.h header, which says:
/* Define HAVE_C99_RUNTIME if the entire C99 runtime is available on
the target system. The value of HAVE_C99_RUNTIME should be the
same as the value of TARGET_C99_FUNCTIONS in the GCC machine
description. (Perhaps GCC should predefine a special macro
indicating whether or not TARGET_C99_FUNCTIONS is set, but it does
not presently do that.) */
and then later:
/* Newlib has the "f" variants of the math functions, but not the "l"
variants. TARGET_C99_FUNCTIONS is only defined if all C99
functions are present. Therefore, on systems using newlib, tests
of builtins will fail the "l" variants, and we should therefore not
define HAVE_C99_RUNTIME. Including gives us a way of
seeing if _NEWLIB_VERSION is defined. Including would work
too, but the GLIBC math inlines cause us to generate inferior code,
which causes the test to fail, so it is not safe. Including
also fails because the include search paths are ordered such that GCC's
version will be found before the newlib version. Similarly, uClibc
lacks the C99 functions. */
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #6 from Marek Polacek ---
Even shorter:
// PR c++/99831
template struct S {
constexpr S(const char ()[N]) : value{} { }
char value[N];
};
template struct string {
constexpr bool operator==(const string &) const = default;
};
template void operator+(string) {
char value[1];
S{value};
}
static_assert(string<"a">{} == string<"a">{});
[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 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org, ||burnus at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- The ICE happens in Program received signal SIGSEGV, Segmentation fault. create_function_arglist (sym=) at ../../gcc-trunk/gcc/fortran/trans-decl.c:2838 2838 hidden_typelist = TREE_CHAIN (hidden_typelist); (gdb) git blame points to: commit 212f4988f37ccf788c8c72b1dc952980bc9be3b7 Author: Tobias Burnus Date: Tue Mar 23 15:45:36 2021 +0100 Fortran: Fix func decl mismatch [PR93660] Adding Tobias.
[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781 --- Comment #5 from Vladimir Makarov --- I've reproduced it too and started to work on it. I hope the fix will be ready this week.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #4 from rguenther at suse dot de --- On March 30, 2021 7:44:56 PM GMT+02:00, andi-gcc at firstfloor dot org wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 > >--- Comment #3 from Andi Kleen --- >So what do you want to fix in the kernel? > >Use a wrapper for taking the address of the memcpy? >(I hope nothing in gcc would remove such a wrapper) Remove the always_inline or also place it on the definition.
Looking at UNSUPPORTED dejagnu tests for a port...
I’m doing some final polishing on a gcc 8.3 upgrade and taking a look at the
unsupported tests. Most of them are completely sensible (my port doesn’t
support trampolines, for example). But gcc.c-torture/execute/pr78622.c is
marked as unsupported. That appears to be due to the line
{ dg-require-effective-target c99_runtime }
I’m using newlib, and if I manually compile the test case with or without an
explicit —std=c99, it compiles and links without error.
Do I need to set something in the baseboards file or in a local .exp file to
indicate that c99 is okay?
[PATCH] c++: Adjust mangling of __alignof__ [PR88115]
We currently mangle __alignof__ as a vendor extended operator,
but that's problematic for the reasons mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6.
This patch changes the mangling of __alignof__ to instead use the
new "vendor extended expression" syntax that's proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/112. Clang does
the same thing already, so after this patch both GCC and Clang agree
about the mangling of __alignof__(type) and __alignof__(expr).
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/88115
* mangle.c (write_expression): Adjust the mangling of
__alignof__.
include/ChangeLog:
PR c++/88115
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_VENDOR_EXPR.
libiberty/ChangeLog:
PR c++/88115
* cp-demangle.c (d_dump, d_make_comp, d_expression_1)
(d_count_templates_scopes): Handle DEMANGLE_COMPONENT_VENDOR_EXPR.
(d_print_comp_inner): Likewise.
: Revert r11-4926
change.
: Likewise.
* testsuite/demangle-expected: Adjust __alignof__ mangling
tests.
gcc/testsuite/ChangeLog:
PR c++/88115
* g++.dg/cpp0x/alignof7.C: Adjust expected mangling.
---
gcc/cp/mangle.c | 8 ++---
gcc/testsuite/g++.dg/cpp0x/alignof7.C | 4 +--
include/demangle.h| 3 ++
libiberty/cp-demangle.c | 47 +++
libiberty/testsuite/demangle-expected | 4 +--
5 files changed, 37 insertions(+), 29 deletions(-)
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 0a9e5aa79a0..57ce9a6710f 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3124,11 +3124,9 @@ write_expression (tree expr)
if (abi_version_at_least (15))
{
/* We used to mangle __alignof__ like alignof. */
- write_string ("v111__alignof__");
- if (TYPE_P (TREE_OPERAND (expr, 0)))
- write_type (TREE_OPERAND (expr, 0));
- else
- write_expression (TREE_OPERAND (expr, 0));
+ write_string ("u11__alignof__");
+ write_template_arg (TREE_OPERAND (expr, 0));
+ write_char ('E');
return;
}
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/alignof7.C
b/gcc/testsuite/g++.dg/cpp0x/alignof7.C
index a4d7f24a4d7..2369b879392 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alignof7.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alignof7.C
@@ -18,5 +18,5 @@ template void f4(std::size_t);
// { dg-final { scan-assembler "_Z2f1IiEvDTatT_E" } }
// { dg-final { scan-assembler "_Z2f2IiEvDTaztlT_EE" } }
-// { dg-final { scan-assembler "_Z2f3IiEvDTv111__alignof__T_E" } }
-// { dg-final { scan-assembler "_Z2f4IiEvDTv111__alignof__tlT_EE" } }
+// { dg-final { scan-assembler "_Z2f3IiEvDTu11__alignof__T_EE" } }
+// { dg-final { scan-assembler "_Z2f4IiEvDTu11__alignof__XtlT_" } }
diff --git a/include/demangle.h b/include/demangle.h
index 23b47265d94..b45234e6887 100644
--- a/include/demangle.h
+++ b/include/demangle.h
@@ -408,6 +408,9 @@ enum demangle_component_type
number which involves neither modifying the mangled string nor
allocating a new copy of the literal in memory. */
DEMANGLE_COMPONENT_LITERAL_NEG,
+ /* A vendor's builtin expression. The left subtree holds the name of
+ the type, and the right subtree is a template argument list. */
+ DEMANGLE_COMPONENT_VENDOR_EXPR,
/* A libgcj compiled resource. The left subtree is the name of the
resource. */
DEMANGLE_COMPONENT_JAVA_RESOURCE,
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index d3e798455cc..a528b7b5ed3 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -815,6 +815,9 @@ d_dump (struct demangle_component *dc, int indent)
case DEMANGLE_COMPONENT_LITERAL_NEG:
printf ("negative literal\n");
break;
+case DEMANGLE_COMPONENT_VENDOR_EXPR:
+ printf ("vendor expression\n");
+ break;
case DEMANGLE_COMPONENT_JAVA_RESOURCE:
printf ("java resource\n");
break;
@@ -976,6 +979,7 @@ d_make_comp (struct d_info *di, enum
demangle_component_type type,
case DEMANGLE_COMPONENT_TRINARY_ARG1:
case DEMANGLE_COMPONENT_LITERAL:
case DEMANGLE_COMPONENT_LITERAL_NEG:
+case DEMANGLE_COMPONENT_VENDOR_EXPR:
case DEMANGLE_COMPONENT_COMPOUND_NAME:
case DEMANGLE_COMPONENT_VECTOR_TYPE:
case DEMANGLE_COMPONENT_CLONE:
@@ -3345,6 +3349,7 @@ d_unresolved_name (struct d_info *di)
::= st
::=
::=
+ ::= u * E # vendor extended
expression
::=
::=
@@ -3425,6 +3430,15 @@ d_expression_1 (struct d_info *di)
return d_make_comp (di, DEMANGLE_COMPONENT_INITIALIZER_LIST,
type, d_exprlist (di, 'E'));
}
+ else if (peek == 'u')
+{
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #5 from Marek Polacek ---
And here's a reduced version of there original test. Will try to reduce
further.
template struct remove_cv { using type = int; };
template using __remove_cvref_t = typename remove_cv<_Tp>::type;
template using remove_cvref_t = __remove_cvref_t<_Tp>;
template
concept derived_from = __is_base_of(_Base, _Derived);
template struct iterator_traits;
struct input_iterator_tag;
namespace __detail {
template struct __iter_traits_impl {
using type = iterator_traits;
};
template
using __iter_traits = typename __iter_traits_impl<_Iter>::type;
template
using __iter_diff_t = typename __iter_traits<_Tp>::difference_type;
} // namespace __detail
template
using iter_difference_t = __detail::__iter_diff_t>;
namespace __detail {
template struct __iter_concept_impl;
template requires requires { typename _Iter; }
struct __iter_concept_impl<_Iter> {
using type = typename __iter_traits<_Iter>::iterator_concept;
};
template
using __iter_concept = typename __iter_concept_impl<_Iter>::type;
} // namespace __detail
template concept weakly_incrementable = requires(_Iter __i) {
__i;
};
template
concept input_iterator =
derived_from<__detail::__iter_concept<_Iter>, input_iterator_tag>;
template struct iterator_traits {
using iterator_concept = input_iterator_tag;
using difference_type = int;
};
template struct in_out_result {};
template using copy_n_result = in_out_result<_Out>;
struct {
template
constexpr copy_n_result<_Iter, _Out>
operator()(_Iter __first, iter_difference_t<_Iter> __n, _Out __result) {
for (; __n; --__n, ++__result)
*__result = *__first;
return {};
}
} copy_n;
template struct StringLiteral {
constexpr StringLiteral(const char ()[N]) { copy_n(str, N, value); }
char value[N];
};
template struct string {
constexpr bool operator==(const string &) const = default;
};
template void operator+(string) {
char value[1];
StringLiteral{value};
}
static_assert(string<"hello, world">{} == string<"hello"
", world">{});
static_assert(string<"a rose is a rose is a rose">{} == string<"a rose"
" is "
"a rose"
" is "
"a rose">{});
[Bug fortran/99840] New: [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 Bug ID: 99840 Summary: [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777 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: --- Started with r8, compiles with r7 : $ cat z1.f90 program p integer, parameter :: x(0,0) = 0 integer :: y(0,0) y = matmul(x, transpose(x)) end $ gfortran-7 -c z1.f90 $ $ gfortran-11-20210328 -c z1.f90 f951: internal compiler error: Segmentation fault 0xc09d4f crash_signal ../../gcc/toplev.c:327 0x716f87 gfc_simplify_matmul(gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:4777 0x69b9d3 do_simplify ../../gcc/fortran/intrinsic.c:4664 0x6a63fa gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5050 0x6f5699 resolve_unknown_f ../../gcc/fortran/resolve.c:2926 0x6f5699 resolve_function ../../gcc/fortran/resolve.c:3270 0x6f5699 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7105 0x6fbb24 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:11728 0x6fbb24 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11824 0x6fd0b7 resolve_codes ../../gcc/fortran/resolve.c:17395 0x6fd17e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17430 0x6e56e4 resolve_all_program_units ../../gcc/fortran/parse.c:6290 0x6e56e4 gfc_parse_file() ../../gcc/fortran/parse.c:6542 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99839] New: ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 Bug ID: 99839 Summary: ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234 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 r7, at -O1+ : $ cat z1.f90 program p real :: x(3, 3) = 1.0 class(*), allocatable :: z(:, :) z = matmul(x, x) end $ gfortran-11-20210328 -c z1.f90 -O0 $ $ gfortran-11-20210328 -c z1.f90 -O2 f951: internal compiler error: in inline_matmul_assign, at fortran/frontend-passes.c:4234 0x7bf248 inline_matmul_assign ../../gcc/fortran/frontend-passes.c:4234 0x7bfd69 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) ../../gcc/fortran/frontend-passes.c:5320 0x7c1172 optimize_namespace ../../gcc/fortran/frontend-passes.c:1500 0x7c154f gfc_run_passes(gfc_namespace*) ../../gcc/fortran/frontend-passes.c:169 0x6fd1a7 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17436 0x6e56e4 resolve_all_program_units ../../gcc/fortran/parse.c:6290 0x6e56e4 gfc_parse_file() ../../gcc/fortran/parse.c:6542 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99838] New: ICE in gfc_format_decoder, at fortran/error.c:970
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99838 Bug ID: 99838 Summary: ICE in gfc_format_decoder, at fortran/error.c:970 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With option -Warray-temporaries, affects versions down to at least r5 : $ cat z1.f90 program p type t integer :: a end type type(t) :: x(3)[*] data x%a /1, 2, 3/ end $ gfortran-11-20210328 -c z1.f90 -fcoarray=lib $ gfortran-11-20210328 -c z1.f90 -Warray-temporaries -fcoarray=single $ $ gfortran-11-20210328 -c z1.f90 -Warray-temporaries -fcoarray=lib z1.f90:1:9: 1 | program p | 1 in gfc_format_decoder, at fortran/error.c:970 0x686202 gfc_format_decoder ../../gcc/fortran/error.c:970 0x162f05e pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:1475 0x1622fe1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:1244 0x685fc5 gfc_report_diagnostic ../../gcc/fortran/error.c:782 0x685fc5 gfc_warning ../../gcc/fortran/error.c:815 0x686d86 gfc_warning(int, char const*, ...) ../../gcc/fortran/error.c:846 0x73c613 gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*, tree_node*, tree_node*, bool, bool, bool, locus*) ../../gcc/fortran/trans-array.c:1355 0x746663 trans_array_constructor ../../gcc/fortran/trans-array.c:2724 0x746663 gfc_add_loop_ss_code ../../gcc/fortran/trans-array.c:3012 0x746d95 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/fortran/trans-array.c:5317 0x776b0d gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11179 0x753cd8 generate_coarray_sym_init ../../gcc/fortran/trans-decl.c:5736 0x71d2b2 do_traverse_symtree ../../gcc/fortran/symbol.c:4170 0x753135 generate_coarray_init ../../gcc/fortran/trans-decl.c:5786 0x75f9c4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6822 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/99837] ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Similar cases with "select type" instead : $ cat z3.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[:] select type (y => x) end select end $ cat z4.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[*] select type (y => x) end select end
[Bug fortran/99837] New: ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 Bug ID: 99837 Summary: ICE in parse_associate, at fortran/parse.c:4780 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: --- Follow-up of pr88357, affects versions down to at least r5. With a missing attribute allocatable or pointer : $ cat z1.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[:] associate (y => x) end associate end $ cat z2.f90 program p type t integer, allocatable :: a(:) end type class(t) :: x[*] associate (y => x) end associate end $ gfortran-11-20210328 -c z1.f90 -fcoarray=single f951: internal compiler error: in parse_associate, at fortran/parse.c:4780 0x6e3f39 parse_associate ../../gcc/fortran/parse.c:4780 0x6e3f39 parse_executable ../../gcc/fortran/parse.c:5524 0x6e401f parse_progunit ../../gcc/fortran/parse.c:5922 0x6e5671 gfc_parse_file() ../../gcc/fortran/parse.c:6437 0x7320ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212 With that attribute : $ cat z0z1.f90 program p type t integer, allocatable :: a(:) end type class(t), allocatable :: x[:] associate (y => x) end associate end $ gfortran-11-20210328 -c z0z1.f90 -fcoarray=single z0z1.f90:1:9: 1 | program p | 1 Error: Pointer assignment target in initialization expression does not have the TARGET attribute at (1)
[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #16 from Peter Bergner --- (In reply to seurer from comment #15) > It still fails on gcc 10, though Vlad, can we get this backported to GCC 10? Maybe in time for GCC 10.3?
Re: Remove RMS from the GCC Steering Committee
I encourage everyone to please try to keep this discussion focused on GCC. If there is a message that is completely unrelated to GCC, I encourage not responding, or responding off-list. Thanks. Ian
Re: Remove RMS from the GCC Steering Committee
On 3/30/21 7:10 PM, Christopher Dimech via Gcc wrote: Sent: Wednesday, March 31, 2021 at 4:50 AM From: "Martin Jambor" To: "Giacomo Tesio" Cc: "GCC Development" Subject: Re: Remove RMS from the GCC Steering Committee Dear Giacomo, On Tue, Mar 30 2021, Giacomo Tesio wrote: Hi Nathan and hello everybody, On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote: The USA is not the world and the SC is not the US government. For those in the USA, the (inapplicable) first amendment provides 5 rights, including showing an unwelcome guest the door. [...] If we fail to do so, it will continue to be harder and harder to attract new talent to GCC development. I do not know if I qualify to speak here because I'm Italian and I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the pandemic I wasn't able to align it with the new developments and contribute the port upstream. Also, I have no idea if you would be interested in running GCC on a Plan 9 fork and thus accept my contribution. Yet, after a careful read of this thread I realized that I might be considered the kind of "new talent" Nathan is talking about. So here is my perspective on this topic, "in the hope it helps but without any warranty". :-D I do not share many of Stallman's opinions (we are VERY different), but when I write free software and contribute to a free software community, what I want is long term assurances about one and only one topic: that the software will stay free as in freedom, as a common good for the whole humanity. As of today, GPLv3 is the legal tool that best suit this goal. I don't think it's perfect in this regards, but that's another story. Nobody suggested that GCC would be relicensed and certainly not to a non-free license. If you decide to contribute your port upstream, it will be safe with us, regardless of who will or will not be on the steering committee or running the FSF. Just read the copyright assignment text that you have singed or would need to sign to contribute and look for FSF obligations as the license holder there. As an Italian I'm having a hard time trying to follow your reasoning about Stallman being a problem to attract new talents. I do not believe that being European or Italian has anything to do with it. I am European, I understand and agree with everything Nathan wrote and apparently I am not the only one. The ability to see and stand up to consistent wrongdoing is universal and every human of every nationality posses it. Unfortunately, all people are also able to close their eyes and ears and ignore mistreatment when they are not the victims and when their friend or their favorite public figure is the perpetrator. There is absolutely nothing American or European about either. Young socialists have been getting organized on colleges campuses with these extreme ideas not only in the United States. France, for instance has been harbouring a socialist model we should all dread. France was once a role model for what big government can do for its people. But it has become an embarrassing example since “The Gilets Jaunes” took to the streets to demonstrate against the insane amount of taxes they pay. These guys aren’t upper class. They are the people who had supported the policies that are inevitable when you have the government providing so many services and involved so deeply in so much of the economy. All those people in America who currently fall for the socialism soup that that Ocasio-Cortez and Sanders are selling need to realize that if their dream came to pass, they, not the rich – not the bankers and politicians – will be ones suffering the most from the high taxes, high unemployment, and slow growth that go hand in hand with the level of public spending they want. I fail to see how this has anything to do with the message you're answering. Is this what the right-wingers in America are resorting to ? Randomly making speeches about the "socialist soup" whenever they encounter something they can't find a good answer to ? Sincerely, Martin
[Bug target/99836] New: aarch64: -fpatchable-function-entry=N[,0] should place .cfi_startproc before NOPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99836
Bug ID: 99836
Summary: aarch64: -fpatchable-function-entry=N[,0] should place
.cfi_startproc before NOPs
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424#c8
% echo 'int main() {}' > a.c
% clang --target=aarch64 -fpatchable-function-entry=2
-mbranch-protection=standard -S a.c -o -
...
main: // @main
.Lfunc_begin0:
.cfi_startproc
// %bb.0: // %entry
hint#34
.Lpatch0:
nop
nop
%
/tmp/glibc-many/install/compilers/aarch64-linux-gnu/bin/aarch64-glibc-linux-gnu-g++
-fpatchable-function-entry=2 -mbranch-protection=standard -S a.c -o -
.arch armv8-a
.file "a.c"
.text
.align 2
.global main
.type main, %function
main:
hint34 // bti c
.section__patchable_function_entries,"aw",@progbits
.align 3
.8byte .LPFE1
.text
.LPFE1:
nop
nop
.LFB0:
.cfi_startproc
For -fpatchable-function-entry=N[,0], placing .cfi_startproc before NOPs makes
more sense and can make unwinding work in that region.
For N[,M] where M>0, that is a very narrow use case by the Linux kernel. I
prefer not to place .cfi_startproc above the function label.
Re: Remove RMS from the GCC Steering Committee
> Sent: Wednesday, March 31, 2021 at 5:45 AM > From: "Joseph Myers" > To: "JeanHeyd Meneide" > Cc: "GCC Development" , "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote: > > > So, it boils down to this for me: either GCC is a place where all > > contributions are welcome, or GCC is a place of hypocrisy, where > > contributions are welcome except when Stallman (or someone else in a > > position of power) lobbies a non-technical, non-factual argument > > against you and jumps from their high tower to slam down on > > rank-and-file contributors and participants. You cannot have it both > > ways. > > All contributions are welcome. One of the key functions of the SC is > actually saying no to RMS. > > Central FSF or GNU project infrastructure is not used in developing GCC; > gcc.gnu.org is entirely independent of central FSF or GNU infrastructure > such as savannah. So RMS has no control over policies applied to GCC > mailing lists, and any influence he might apply to the moderation of lists > hosted on lists.gnu.org does not apply here. (Although GCC releases are > uploaded to ftp.gnu.org, which is central GNU infrastructure, they are > also available at https://gcc.gnu.org/pub/gcc/releases/ .) He has an > ordinary restricted user account on gcc.gnu.org giving the same access to > push commits as most committers; he does not have shell or administrative > access. People are inflating the power or control he actually has. I have to say that at no time has Stallman dictated on any of my work. Unlike the animosity that has been demonstrated by Ludovic Courtès in October 2019, by sending a message disguised to look like an official Gnu Directive to Gnu Maintainers. A fashionable tool for excommunicating those he find problematic due to their pesky different points of view. > -- > Joseph S. Myers > jos...@codesourcery.com >
Re: Remove RMS from the GCC Steering Committee
Dear Giacomo, Apologies, a correction here. I should have more carefully read it, but this paragraph: > My problem is Dr. Richard M. Stallman stands credibly and > factually accused of Doxxing and GCC contributor/participant and > knowingly manipulating the project for his own personal reasons. This should be "RMS explicitly sanctioned, encouraged, and blessed the Doxxing of an individual". Apologies, he did not do the doxxing himself; this was a fat finger on my part. Please take that into account; the rest is accurate. Sincerely, JeanHeyd
Re: Remove RMS from the GCC Steering Committee
On Tue, 30 Mar 2021, JeanHeyd Meneide via Gcc wrote: > So, it boils down to this for me: either GCC is a place where all > contributions are welcome, or GCC is a place of hypocrisy, where > contributions are welcome except when Stallman (or someone else in a > position of power) lobbies a non-technical, non-factual argument > against you and jumps from their high tower to slam down on > rank-and-file contributors and participants. You cannot have it both > ways. All contributions are welcome. One of the key functions of the SC is actually saying no to RMS. Central FSF or GNU project infrastructure is not used in developing GCC; gcc.gnu.org is entirely independent of central FSF or GNU infrastructure such as savannah. So RMS has no control over policies applied to GCC mailing lists, and any influence he might apply to the moderation of lists hosted on lists.gnu.org does not apply here. (Although GCC releases are uploaded to ftp.gnu.org, which is central GNU infrastructure, they are also available at https://gcc.gnu.org/pub/gcc/releases/ .) He has an ordinary restricted user account on gcc.gnu.org giving the same access to push commits as most committers; he does not have shell or administrative access. -- Joseph S. Myers jos...@codesourcery.com
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 --- Comment #3 from Andi Kleen --- So what do you want to fix in the kernel? Use a wrapper for taking the address of the memcpy? (I hope nothing in gcc would remove such a wrapper)
[Bug c++/99831] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #4 from 康桓瑋 ---
When the array subscript is outside the bounds of array, gcc seems to fall into
infinite recursion due to the default operator==.
Here is the reduced with no header:
struct A {
constexpr A(const char*) {}
char value[1] = {};
};
template
struct B {
constexpr bool operator==(const B&) const = default;
};
constexpr auto foo(auto) {
constexpr auto a = [] {
char value[1];
value[2] = 0; // this line
return A{value};
}();
return B{};
}
constexpr auto b = foo(B<"">{});
: In instantiation of 'struct B< >':
:8:18: recursively required from 'struct B< >'
:8:18: required from 'struct B< >'
:17:15: required from 'constexpr auto foo(auto:1) [with auto:1 =
B]'
:20:23: required from here
:8:18: fatal error: template instantiation depth exceeds maximum of 900
(use '-ftemplate-depth=' to increase the maximum)
8 | constexpr bool operator==(const B&) const = default;
| ^~~~
compilation terminated.
[Bug tree-optimization/99835] New: missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835
Bug ID: 99835
Summary: missed optimization for dead code elimination at -O3
(vs. -O1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[558] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210330 (experimental) [master revision
8aac913adfc:ff4ebc2f17c:65374af219f9c5c594951a07e766fe70c1136a1f] (GCC)
[559] %
[559] % gcctk -O1 -S -o O1.s small.c
[560] % gcctk -O3 -S -o O3.s small.c
[561] %
[561] % wc O1.s O3.s
23 45 420 O1.s
35 66 615 O3.s
58 111 1035 total
[562] %
[562] % grep foo O1.s
[563] % grep foo O3.s
jmp foo
[564] %
[564] % cat small.c
extern void foo(void);
static int a, d;
void b();
static int c() {
foo();
b();
}
void b() {
while (d) {
if (!a)
break;
c();
}
}
int main() {
b();
return 0;
}
[Bug ipa/99834] New: missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99834
Bug ID: 99834
Summary: missed optimization for dead code elimination at -O3
(vs. -O2)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[590] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210330 (experimental) [master revision
8aac913adfc:ff4ebc2f17c:65374af219f9c5c594951a07e766fe70c1136a1f] (GCC)
[591] %
[591] % gcctk -O2 -S -o O2.s small.c
[592] % gcctk -O3 -S -o O3.s small.c
[593] %
[593] % wc O2.s O3.s
43 90 704 O2.s
61 126 950 O3.s
104 216 1654 total
[594] %
[594] % grep foo O2.s
[595] % grep foo O3.s
callfoo
callfoo
[596] %
[596] % cat small.c
extern void foo(void);
static int a, b, c;
static int d() {
for (a = 0; a < 1; a++)
b = 1;
for (; b; b--)
for (; c; c--)
;
return 0;
}
static void e() {
if (d())
foo();
}
int main() {
e();
e();
return 0;
}
[Bug c++/99833] New: structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833
Bug ID: 99833
Summary: structured binding + if init + generic lambda =
internal compiler error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickgray0 at brown dot edu
Target Milestone: ---
Build: -std=c++20
as the title suggests, the following code triggers an internal compiler error:
#include
auto f(auto&& x) {
[&](auto...) {
auto y = std::tuple{ "what's happening here?", x };
if constexpr (auto [_, z] = y; requires { z; })
return;
}();
}
auto main()->int {
f(42);
}
error message: :6:36: internal compiler error: in tsubst_decomp_names,
at cp/pt.c:18034
6 | if constexpr (auto [_, z] = y; requires { z; })
|^~
0x1cfb6a9 internal_error(char const*, ...)
???:0
0x6ba871 fancy_abort(char const*, int, char const*)
???:0
0x91c84f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c6c0e maybe_instantiate_decl(tree_node*)
???:0
0x7c8370 mark_used(tree_node*, int)
???:0
0x6e2835 build_op_call(tree_node*, vec**, int)
???:0
0x980ae5 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x91c84f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c6c0e maybe_instantiate_decl(tree_node*)
???:0
0x7c8370 mark_used(tree_node*, int)
???:0
0x6de097 build_new_function_call(tree_node*, vec**, int)
???:0
0x980c6c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x8e12ad c_parse_file()
???:0
0xa600a2 c_common_parse_file()
???:0
either moving the structured binding outside of if statement or making the
lambda non-generic seems to solve the problem.
[Bug tree-optimization/98268] [10/11 Regression] ICE: verify_gimple failed with LTO and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98268 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #7 from rsandifo at gcc dot gnu.org --- Mine. Seems that maybe_canonicalize_mem_ref_addr should call recompute_tree_invariant_for_addr_expr when replacing _MEM_REF (which is never treated as invariant) with _REF (which can be invariant).
Re: Remove RMS from the GCC Steering Committee
> Sent: Wednesday, March 31, 2021 at 4:50 AM > From: "Martin Jambor" > To: "Giacomo Tesio" > Cc: "GCC Development" > Subject: Re: Remove RMS from the GCC Steering Committee > > Dear Giacomo, > > On Tue, Mar 30 2021, Giacomo Tesio wrote: > > Hi Nathan and hello everybody, > > > > On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote: > > > >> The USA is not the world and the SC is not the US government. For > >> those in the USA, the (inapplicable) first amendment provides 5 > >> rights, including showing an unwelcome guest the door. [...] > >> > >> If we fail to do so, it will continue to be harder and harder to > >> attract new talent to GCC development. > > > > I do not know if I qualify to speak here because I'm Italian and > > I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see > > http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the > > pandemic I wasn't able to align it with the new developments and > > contribute the port upstream. Also, I have no idea if you would be > > interested in running GCC on a Plan 9 fork and thus accept my > > contribution. > > > > > > Yet, after a careful read of this thread I realized that I might > > be considered the kind of "new talent" Nathan is talking about. > > > > So here is my perspective on this topic, "in the hope it helps but > > without any warranty". :-D > > > > > > I do not share many of Stallman's opinions (we are VERY different), but > > when I write free software and contribute to a free software community, > > what I want is long term assurances about one and only one topic: that > > the software will stay free as in freedom, as a common good for the > > whole humanity. > > > > As of today, GPLv3 is the legal tool that best suit this goal. > > I don't think it's perfect in this regards, but that's another story. > > Nobody suggested that GCC would be relicensed and certainly not to a > non-free license. If you decide to contribute your port upstream, it > will be safe with us, regardless of who will or will not be on the > steering committee or running the FSF. Just read the copyright > assignment text that you have singed or would need to sign to contribute > and look for FSF obligations as the license holder there. > > > As an Italian I'm having a hard time trying to follow your reasoning > > about Stallman being a problem to attract new talents. > > I do not believe that being European or Italian has anything to do with > it. I am European, I understand and agree with everything Nathan wrote > and apparently I am not the only one. > > The ability to see and stand up to consistent wrongdoing is universal > and every human of every nationality posses it. Unfortunately, all > people are also able to close their eyes and ears and ignore mistreatment > when they are not the victims and when their friend or their favorite > public figure is the perpetrator. There is absolutely nothing American > or European about either. Young socialists have been getting organized on colleges campuses with these extreme ideas not only in the United States. France, for instance has been harbouring a socialist model we should all dread. France was once a role model for what big government can do for its people. But it has become an embarrassing example since “The Gilets Jaunes” took to the streets to demonstrate against the insane amount of taxes they pay. These guys aren’t upper class. They are the people who had supported the policies that are inevitable when you have the government providing so many services and involved so deeply in so much of the economy. All those people in America who currently fall for the socialism soup that that Ocasio-Cortez and Sanders are selling need to realize that if their dream came to pass, they, not the rich – not the bankers and politicians – will be ones suffering the most from the high taxes, high unemployment, and slow growth that go hand in hand with the level of public spending they want. > Sincerely, > > Martin >
Re: Remove RMS from the GCC Steering Committee
Dear Giacomo,
I want to reply specifically to you because you, like me, are a
new contributor, and I have a few questions and a few points that I
think are salient in this discussion.
> As an Italian I'm having a hard time trying to follow your reasoning
> about Stallman being a problem to attract new talents.
>
> I could understand such statement if he had committed actual crimes,
> was legally persecuted, processed and condemned like Reiser.
>
> But while I try, I cannot really understand why you think that his name
> in the Steering Committee would drive away people from contributing GCC
The first is that I don't want to get into the conversation about
how the FSF handles Stallman. Other than them having my Copyright
assignment (something I also need to take a look at), the FSF does not
write the code. GCC's contributors, like you and me, do. My biggest
problem with Stallman right now is not about whether or not he likes
US-ians or if he's a good person:
My problem is Dr. Richard M. Stallman stands credibly and
factually accused of Doxxing and GCC contributor/participant and
knowingly manipulating the project for his own personal reasons.
When I say this, I want to be clear: when Mark sent his e-mail I
followed up with multiple GCC contributors to determine how factual
his claim actually was. Multiple people have independently
corroborated that Stallman did what Mark said, and worse, and their
quotes of Stallman's words line up word-for-word. In fact, what
Stallman did was worse than what Mark described, and has happened
multiple times before. Stallman is willing to attack and engage in
cancel culture of his own contributors. What his reasons are, I don't
know and I do not want to know: my bottom line here is that Stallman
is a danger to GCC contributors and is harmful to them.
I make no argument based on my ethnicity, skin color, which side
of the globe I come from. Dr. Stallman's demonstrated behavior is that
he can - and WILL, and HAS - shown up into places where he has very
little to offer technically and utterly derailed or otherwise harmed
individuals or peoples **and their code contributions**.
So, it boils down to this for me: either GCC is a place where all
contributions are welcome, or GCC is a place of hypocrisy, where
contributions are welcome except when Stallman (or someone else in a
position of power) lobbies a non-technical, non-factual argument
against you and jumps from their high tower to slam down on
rank-and-file contributors and participants. You cannot have it both
ways.
That is why I switched from "wait and see" to "absolutely not".
I am not going to wait for the day somebody high up enough on the GCC
ladder doesn't like me enough to decide that he's going to
shoulder-slam my contributions with non-technical claptrap, nor am I
going to recommend other people to this project if anyone can do that
to them. Which brings me to another important point...
> I do not really know if the removing Stallman from the Steering
> Committee would attract more US people in GCC development. Or if it
> would attract more US people that now prefer to work in LLVM only
> because of they feel somehow bad working with Stallman in the SC.
>
>
> But I can assure you that, as Pankaj Jangid said before me, many many
> people are attracted to GCC, as users and developers, BECAUSE of
> Stallman presence, because they know that something like this
> https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696
> will not happen to them.
>
>
> World wide, people do not LIKE Stallman, but we TRUST him on this.
> Just like the GPLv3, RMS is not perfect, but it does ONE THING well.
You state it here and many others say it throughout the thread
that Stallman is the only reason they contribute to GCC, or similar
Free Software projects. This deeply concerns me, because the
underlying implication is if that Stallman were to disappear, right
this second, all of you would be gone. Yet, on the other hand, we say
that this is the "Free Software MOVEMENT". A movement cannot be
destroyed because one person disappears; if that is the case, it is
not a movement, but a ring of personality around an individual. Either
this is a Free Software Movement, or this is Stallman's Free Software
Shindig. I contribute to GCC because I expect that when Stallman is
gone and I am Stallman's age, there will still be a Free Software
Movement. Stewarded by the FSF or the CNCF or the {insert gathering of
like-minded OSS contributors and enthusiasts and hard workers here}.
Is this not the case for you and others?
If Stallman is the only thing holding this movement together, I
would like to know this now so I can invest my time in an actual
movement elsewhere, independently of whether or not he remains on the
Steering Committee. (I still believe he has no place to have a
position of power on the Steering Committee, and instead should just
be a
Re: Remove RMS from the GCC Steering Committee
Hello Giacomo and everyone else! As a neighbour to your north (Austria), and another potential newcomer, I would also like to point out that I do not believe the views given by Nathan and others in support of him are very US-centric. At least I would hope that most countries are in pursuit or see value in having an inclusive environment where no one has to feel treated unfairly due to either their gender, race or other things. For what it's worth, Nathan may have simply picked the USA as an example due familiarity. We don't know that. As far as I am aware many of the people who have been participating in this thread are also not from the USA. I am also of the opinion that legally wrong does not equal morally wrong. RMS does not have to have committed a crime for the developers of GCC, the SC or whoever, to feel like he is not representing their values as a member of the SC well. Best regards Markus On Tue, Mar 30, 2021 at 3:20 PM Giacomo Tesio wrote: > > Hi Nathan and hello everybody, > > On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote: > > > The USA is not the world and the SC is not the US government. For > > those in the USA, the (inapplicable) first amendment provides 5 > > rights, including showing an unwelcome guest the door. [...] > > > > If we fail to do so, it will continue to be harder and harder to > > attract new talent to GCC development. > > I do not know if I qualify to speak here because I'm Italian and > I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see > http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the > pandemic I wasn't able to align it with the new developments and > contribute the port upstream. Also, I have no idea if you would be > interested in running GCC on a Plan 9 fork and thus accept my > contribution. > > > Yet, after a careful read of this thread I realized that I might > be considered the kind of "new talent" Nathan is talking about. > > So here is my perspective on this topic, "in the hope it helps but > without any warranty". :-D > > > I do not share many of Stallman's opinions (we are VERY different), but > when I write free software and contribute to a free software community, > what I want is long term assurances about one and only one topic: that > the software will stay free as in freedom, as a common good for the > whole humanity. > > As of today, GPLv3 is the legal tool that best suit this goal. > I don't think it's perfect in this regards, but that's another story. > > > As an Italian I'm having a hard time trying to follow your reasoning > about Stallman being a problem to attract new talents. > > I could understand such statement if he had committed actual crimes, > was legally persecuted, processed and condemned like Reiser. > > But while I try, I cannot really understand why you think that his name > in the Steering Committee would drive away people from contributing GCC > > > I ported GCC to Plan 9 because I want a free compiler suite for my OS. > > Porting CLANG would have been easier (to some extent) BUT my choice was > political and Stallman in the Steering Committee is a long term > warranty that GCC development will not steer away from the Free > Software conception that I know, betraying my trust. > > > My impression is that you are, in absolute good faith, projecting your > own culture (quite US-centric, as far as I can deduce by this thread) > to the whole world. > > > I do not really know if the removing Stallman from the Steering > Committee would attract more US people in GCC development. Or if it > would attract more US people that now prefer to work in LLVM only > because of they feel somehow bad working with Stallman in the SC. > > > But I can assure you that, as Pankaj Jangid said before me, many many > people are attracted to GCC, as users and developers, BECAUSE of > Stallman presence, because they know that something like this > https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696 > will not happen to them. > > > World wide, people do not LIKE Stallman, but we TRUST him on this. > Just like the GPLv3, RMS is not perfect, but it does ONE THING well. > > > So, since you care about demographics, please consider that. > > Removing RMS you might attract more of certain US demographics, > but you will certainly alienate a lot of people world wide that > do not align your political values (despite respecting them a lot!) > and do not think that a compiler suite can fix US systemic issues > anyway. > > > As for me, I would NOT trust GCC (or FSF) in the long term, had > you to distance Stallman, because I've already seen with my eyes > what happen when people do not have anything to loose to betray your > trust, and Stallman has all to lose by betraying Free Software. > > > Maybe I'm not the "new talent" you are looking for. > > But please, do not turn GCC into a US-centric project. > > > > Giacomo
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #15 from Nathan Sidwell --- another one encountered on the way ... * 5f3c6027257 2021-03-30 | c++: duplicate const static members [PR 99283]
