[Bug target/89606] Extra mov after structure load instructions on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2021-04-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||ra Host|x86_64-pc-linux-gnu | Build|x86_64-pc-linux-gnu | --- Comment #2 from Andrew Pinski --- Confirmed. Note GCC 7 was even worse.
[Bug target/84547] Suboptimal code for int128 masked shifts (ARM64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84547 Andrew Pinski changed: What|Removed |Added Summary|Suboptimal code for masked |Suboptimal code for int128 |shifts (ARM64) |masked shifts (ARM64) Last reconfirmed||2021-04-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Yes int128 (or rather double wide register) shifts are not optimized that well. They are not used by many people even. I wonder if there is a way to use vector instructions to do them.
Re: removing toxic emailers
On 4/16/2021 10:08 PM, Frosku wrote: On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote: On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: When I refer to a 'California cultural standard', that's not prescriptive. It's just a reference to the fact that a *lot* of the SC live in California, and any culture prescribed by the steering committee will be overly influenced by that commonality. To the best of my knowledge, 2 of the 13 members of the GCC steering committee live in California. Ian And the rest of the west coast United States / New England? I'm not aware of anywhere in the US that is a monoculture in the way you seem to be implying. And if you really believe there are those kinds of monocultures , then you're showing a high degree of ignorance. FTR, I've never resided on the west coast of the US or in the traditionally defined New England states. Jeff
Re: removing toxic emailers
On Fri, Apr 16, 2021 at 9:56 PM Frosku wrote:
>
> On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote:
> > On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote:
> > >
> > > When I refer to a 'California cultural standard', that's not
> > > prescriptive. It's
> > > just a reference to the fact that a *lot* of the SC live in California,
> > > and any
> > > culture prescribed by the steering committee will be overly influenced by
> > > that
> > > commonality.
> >
> > To the best of my knowledge, 2 of the 13 members of the GCC steering
> > committee live in California.
> >
> > Ian
>
> And the rest of the west coast United States / New England?
I count 5 which are not in the United States or Canada.
Thanks,
Andrew Pinski
>
> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote:
> On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote:
> >
> > When I refer to a 'California cultural standard', that's not prescriptive.
> > It's
> > just a reference to the fact that a *lot* of the SC live in California, and
> > any
> > culture prescribed by the steering committee will be overly influenced by
> > that
> > commonality.
>
> To the best of my knowledge, 2 of the 13 members of the GCC steering
> committee live in California.
>
> Ian
And the rest of the west coast United States / New England?
>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
Re: removing toxic emailers
On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: > > When I refer to a 'California cultural standard', that's not prescriptive. > It's > just a reference to the fact that a *lot* of the SC live in California, and > any > culture prescribed by the steering committee will be overly influenced by that > commonality. To the best of my knowledge, 2 of the 13 members of the GCC steering committee live in California. Ian
[Bug c++/99926] Parameter packs and variadic arguments: Clang, gcc, and msvc differ on this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99926 --- Comment #2 from Matt Hurd --- FWIW, MSVC claims to have fixed their bug in version 16.10 Preview 2, leaving just gcc generating incorrect code. https://developercommunity.visualstudio.com/t/parameter-packs-and-variadic-arguments-clang-gcc-a/1390988 --Matt.
[Bug c++/100111] [10 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||11.0 Summary|[10/11 Regression] |[10 Regression] |`-fno-elide-constructors` |`-fno-elide-constructors` |with `constexpr` ctors |with `constexpr` ctors |causes ICE in GCC 10.3 |causes ICE in GCC 10.3
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to John Northall from comment #4) > O dear - that makes gfortran unusable on many existing codes - not really > satisfactory is it? > John > gfortran is fairly good at finding bugs in a user's program if one asks gfortran to do so. Add -fcheck=all to your options. At line 21 of file setmid.f Fortran runtime error: Index '155' of dimension 1 of array 'xym' above upper bound of 1 Now, you have an opportunity to fix your code.
[Bug c++/100124] Why is "flexible array member '...' in an otherwise empty '...'" an issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124 --- Comment #4 from Andrew Pinski --- (In reply to Martin Sebor from comment #3) > The reason why G++ rejects structs with a flexible array as the sole member > is because GCC (in C mode) doesn't accept them. Git log indicates that GCC > started rejecting such code in r38705 Note this change was done long before clang was around so it would be interesting to know why clang chose differently.
Re: removing toxic emailers
> Sent: Saturday, April 17, 2021 at 11:15 AM > From: "Frosku" > To: "Ian Lance Taylor" > Cc: "GCC Development" > Subject: Re: removing toxic emailers > > On Fri Apr 16, 2021 at 5:28 PM BST, Ian Lance Taylor wrote: > > On Thu, Apr 15, 2021 at 9:08 PM Frosku wrote: > > > > > > On the other hand, I also think that a project which goes too far in > > > policing speech, especially speech unrelated to the project, will drive > > > away > > > talented people who are more than willing to comply with the project's > > > norms > > > within the project's spaces. Trying to enforce the 'California cultural > > > standard' on not only someone's interactions with the project but their > > > entire life (which may be lived in a very different cultural setting) > > > seems > > > very invasive and culturally exclusionary. > > > > I do live in California, but I don't know what the "California > > cultural standard" is. It's a big place, and it's full of people who > > behave in all kinds of different ways. Harvey Weinstein and > > brogrammer culture are California cultures. You presumably have > > something in mind, but I'm not sure it's a real thing. > > There isn't a real name for any given culture because culture is such an > organic > thing. When I think of codes of conduct I come back to i.e. Linus giving > people > a hard time in code reviews, or Coraline Ada Ehmke's critiques of meritocracy. > Neither of these beliefs about what culture should be (Linus' or Coraline's) > are > objectively right or objectively wrong, but both are likely to attract > different > people, and result in different outcomes. We will certainly have to adapt to the recognition that the human race is in great danger because of our politics going crazy and nationalism being a serious treat. Our world must turn itself into a new set of people that is unlike the generation that brought us in free software - just one corner of the western world. In 2016, Cosmologist Stephen Hawking warned us to stop reaching out to aliens before it's too late. His assessment was that distant alien civilisations might view us as inferior, weak, and perfect to conquer. We barely averted nuclear annihilation in the later half of last century. The problem is that we have not adapted ourselves to control all the power we already have. Science and technology has empowered us too much. After destroying much of the vegetal and animal species on Earth, we have started destroying ourselves, like other civilisations have destroyed themselves in the past. But this time, the collapse may be global. Good luck with death! > When I refer to a 'California cultural standard', that's not prescriptive. > It's > just a reference to the fact that a *lot* of the SC live in California, and > any > culture prescribed by the steering committee will be overly influenced by that > commonality. You will have ideas about what is welcoming, what is polite, etc > which are shaped by your upbringing just as I or anyone else does. These are > not objective truths, or internationally accepted as such. > > > > I'd be interested to know where you draw the line as to what behavior is > > > related to the project, or if you don't draw a line, why volunteers in > > > China, > > > Russia, Poland etc should be expected to accept an entire political > > > doctrine > > > over their life to contribute to a compiler toolchain. > > > > How did we get to accepting an entire political doctrine? > > > > What I have in mind is treating people with respect. For example, I'm > > involved with the Go programming language. The Go community has a > > code of conduct: https://golang.org/conduct. The key elements are: > > > > - Be friendly and welcoming > > - Be patient > > Remember that people have varying communication styles and that not > > everyone is using their native language. (Meaning and tone can be lost > > in translation.) > > - Be thoughtful > > Productive communication requires effort. Think about how your words > > will be interpreted. > > Remember that sometimes it is best to refrain entirely from commenting. > > - Be respectful > > In particular, respect differences of opinion. > > - Be charitable > > Interpret the arguments of others in good faith, do not seek to > > disagree. > > When we do disagree, try to understand why. > > > > Avoid destructive behavior: > > > > Derailing: stay on topic; if you want to talk about something else, > > start a new conversation. > > Unconstructive criticism: don't merely decry the current state of > > affairs; offer—or at least solicit—suggestions as to how things may > > be > > improved. > > Snarking (pithy, unproductive, sniping comments) > > Discussing potentially offensive or sensitive issues; this all too > > often leads to unnecessary conflict. > > Microaggressions: brief and commonplace verbal, behavioral and > > environmental indignities that communicate hostile, derogatory or > > negative slights and insults to a
[Bug libstdc++/100128] New: Behavior and performance depends on order of ctype.h and stdlib.h include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128 Bug ID: 100128 Summary: Behavior and performance depends on order of ctype.h and stdlib.h include Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: travis.downs at gmail dot com Target Milestone: --- When ctype.h is included as the first header in a file, it will be processed without __NO_CTYPE being defined. This results in several differences versus the case where __NO_CTYPE is defined. For example, toupper() is defined as extern inline or as a macro if __NO_CTYPE is undefed, but is not defined (only declared), otherwise. As another example, is_alnum_l and many similar methods will be defined as macros if __NO_CTYPE is undefined, but otherwise will not. On the other hand, if you include stdlib.h (or many other files such as ) in a C++ compile, the C++ "override" file include/c++/10.3.0/stdlib.h gets included, which ultimately ends up including x86_64-linux-gnu/bits/os_defines.h which defines __NO_CTYPE. If is subsequently included, its effect is different as described above. I suppose this is an ODR violation in one way or another (e.g., if two files are included in the same program with and without __NO_CTYPE), and it can also have a significant impact on performance as described here: https://travisdowns.github.io/blog/2019/11/19/toupper.html Evidently, the behavior and definitions exposed by these headers should not depend on the order of include. I suspect there are other cases besides the __NO_CTYPE as long as files that don't trigger the C++ header include chain like ctype.h exist. You can play with this example on godbolt: https://godbolt.org/z/vY4EnE51z Try swapping the order of ctype and stdlib includes to see the effect. The int variables are canaries so you can see which macros were defined in the preprocessed output. This is the same as glibc bug #25214, but I was advised over there than this should be filed against libstdc++ instead. https://sourceware.org/bugzilla/show_bug.cgi?id=25214
[Bug c++/100124] Why is "flexible array member '...' in an otherwise empty '...'" an issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- The reason why G++ rejects structs with a flexible array as the sole member is because GCC (in C mode) doesn't accept them. Git log indicates that GCC started rejecting such code in r38705, which was committed as part of array member initialization cleanup. I don't know why the author of the change chose to reject such structs rather than accepting them with a warning, just like empty structs are accepted. If he had, C++ might have followed suit. At this point, I don't see GCC (in either mode) making a change unless C itself were to change first. That seems highly unlikely to me (the last proposal to relax the rules for flexible array members didn't go anywhere).
[Bug fortran/100120] associated intrinsic failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100120 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055942.html
[Bug fortran/100098] Polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
[Bug fortran/100097] Unlimited polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100097 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
[Bug fortran/100094] Undefined pointers have incorrect rank when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100094 --- Comment #3 from José Rui Faustino de Sousa --- (In reply to kargl from comment #1) > Isn't the code invalid Fortran because it references an undefined pointer? > If yes, the compiler is allows to do whatever it wants with the code. AFAIK that is correct off all the "associate-like" constructs, the only exception is select rank. 11.1.10.3 Attributes of a SELECT RANK associate name, paragraph 3: "The associating entity has the ALLOCATABLE, POINTER, or TARGET attribute if the selector has that attribute. The other attributes of the associating entity are described in 11.1.3.3." Best regards, José Rui
Re: removing toxic emailers
On Fri Apr 16, 2021 at 5:28 PM BST, Ian Lance Taylor wrote:
> On Thu, Apr 15, 2021 at 9:08 PM Frosku wrote:
> >
> > On the other hand, I also think that a project which goes too far in
> > policing speech, especially speech unrelated to the project, will drive away
> > talented people who are more than willing to comply with the project's norms
> > within the project's spaces. Trying to enforce the 'California cultural
> > standard' on not only someone's interactions with the project but their
> > entire life (which may be lived in a very different cultural setting) seems
> > very invasive and culturally exclusionary.
>
> I do live in California, but I don't know what the "California
> cultural standard" is. It's a big place, and it's full of people who
> behave in all kinds of different ways. Harvey Weinstein and
> brogrammer culture are California cultures. You presumably have
> something in mind, but I'm not sure it's a real thing.
There isn't a real name for any given culture because culture is such an organic
thing. When I think of codes of conduct I come back to i.e. Linus giving people
a hard time in code reviews, or Coraline Ada Ehmke's critiques of meritocracy.
Neither of these beliefs about what culture should be (Linus' or Coraline's) are
objectively right or objectively wrong, but both are likely to attract different
people, and result in different outcomes.
When I refer to a 'California cultural standard', that's not prescriptive. It's
just a reference to the fact that a *lot* of the SC live in California, and any
culture prescribed by the steering committee will be overly influenced by that
commonality. You will have ideas about what is welcoming, what is polite, etc
which are shaped by your upbringing just as I or anyone else does. These are
not objective truths, or internationally accepted as such.
> > I'd be interested to know where you draw the line as to what behavior is
> > related to the project, or if you don't draw a line, why volunteers in
> > China,
> > Russia, Poland etc should be expected to accept an entire political doctrine
> > over their life to contribute to a compiler toolchain.
>
> How did we get to accepting an entire political doctrine?
>
> What I have in mind is treating people with respect. For example, I'm
> involved with the Go programming language. The Go community has a
> code of conduct: https://golang.org/conduct. The key elements are:
>
> - Be friendly and welcoming
> - Be patient
> Remember that people have varying communication styles and that not
> everyone is using their native language. (Meaning and tone can be lost
> in translation.)
> - Be thoughtful
> Productive communication requires effort. Think about how your words
> will be interpreted.
> Remember that sometimes it is best to refrain entirely from commenting.
> - Be respectful
> In particular, respect differences of opinion.
> - Be charitable
> Interpret the arguments of others in good faith, do not seek to
> disagree.
> When we do disagree, try to understand why.
>
> Avoid destructive behavior:
>
> Derailing: stay on topic; if you want to talk about something else,
> start a new conversation.
> Unconstructive criticism: don't merely decry the current state of
> affairs; offer—or at least solicit—suggestions as to how things may
> be
> improved.
> Snarking (pithy, unproductive, sniping comments)
> Discussing potentially offensive or sensitive issues; this all too
> often leads to unnecessary conflict.
> Microaggressions: brief and commonplace verbal, behavioral and
> environmental indignities that communicate hostile, derogatory or
> negative slights and insults to a person or group.
I certainly prefer it to the Contributor Covenant, however the last
point ('microaggressions') is an example of 'California culture'. In
most of the world, we do not have any such concept. The examples I've
seen online for what counts as a microaggression include asking questions
like "where are you from?"
I'm assuming this is considered offensive because there's a trend of using
it to imply that someone "isn't welcome" in the local area, but in most of
the world this isn't considered an offensive question. As someone who
spends the vast majority of my time in countries that aren't my birthplace,
it's one of the questions I hear the most.
I'm not sure that most of us who live outside of cultures where "micro-
-aggressions" are a commonly referenced 'thing' would know if we're making
one or just being friendly. As an aside, would this be applied to
communication in GCC spaces or to all off-list communications i.e. Twitter
/ Weibo postings, e-mails, things said at unrelated conferences?
> And I have to note that I have seen very few people here saying "RMS
> must never participate in GCC in any way." What I see most people
> saying is "RMS should not be in a position of leading the GCC project
> and telling people what to do."
My concern here is that if not RMS/GNU -- an institution which most free
software
[Bug fortran/100040] Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted. https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
[PATCH] c++: Fix pretty printing of function pointer type [PR98767]
When pretty printing a function pointer type via
pp_cxx_parameter_declaration_clause, we end up always printing an empty
parameter list because the loop that's supposed to print the parameter
list iterates over 'args' instead of 'types', and 'args' is empty in
this case when a FUNCTION_TYPE is passed to this routine (as opposed
to a FUNCTION_DECL).
This patch fixes this by making the loop iterator over 'types' instead.
This patch also moves the retrofitted PARM_DECL printing from this
routine to pp_cxx_requires_expr, the only caller that uses it. This
simplification lets us easily output the trailing '...' in the parameter
list of a variadic function, which this patch also implements.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/98767
* cxx-pretty-print.c (pp_cxx_parameter_declaration_clause): Fix
loop over parameter list to iterate over 'types' instead of
'args'. Output the trailing '...' for a variadic function.
Remove PARM_DECL support.
(pp_cxx_requires_expr): Pretty print the parameter list directly
instead of going through pp_cxx_parameter_declaration_clause.
gcc/testsuite/ChangeLog:
PR c++/98767
* g++.dg/concepts/diagnostic16.C: New test.
---
gcc/cp/cxx-pretty-print.c| 48
gcc/testsuite/g++.dg/concepts/diagnostic16.C | 17 +++
2 files changed, 46 insertions(+), 19 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic16.C
diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index a22eea5239c..894472e26e0 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -1537,34 +1537,27 @@ pp_cxx_parameter_declaration (cxx_pretty_printer *pp,
tree t)
static void
pp_cxx_parameter_declaration_clause (cxx_pretty_printer *pp, tree t)
{
- tree args;
- tree types;
- bool abstract;
-
- // For a requires clause or the explicit printing of a parameter list
- // we expect T to be a chain of PARM_DECLs. Otherwise, the list of
- // args and types are taken from the function decl T.
- if (TREE_CODE (t) == PARM_DECL)
+ gcc_assert (FUNC_OR_METHOD_TYPE_P (t) || TREE_CODE (t) == FUNCTION_DECL);
+ tree types, args;
+ if (TYPE_P (t))
{
- args = t;
- types = t;
- abstract = false;
+ types = TYPE_ARG_TYPES (t);
+ args = NULL_TREE;
}
else
{
- bool type_p = TYPE_P (t);
- args = type_p ? NULL : FUNCTION_FIRST_USER_PARM (t);
- types = type_p ? TYPE_ARG_TYPES (t) : FUNCTION_FIRST_USER_PARMTYPE (t);
- abstract = args == NULL || pp->flags & pp_c_flag_abstract;
+ types = FUNCTION_FIRST_USER_PARMTYPE (t);
+ args = FUNCTION_FIRST_USER_PARM (t);
}
- bool first = true;
+ bool abstract = !args || (pp->flags & pp_c_flag_abstract);
/* Skip artificial parameter for non-static member functions. */
if (TREE_CODE (t) == METHOD_TYPE)
types = TREE_CHAIN (types);
+ bool first = true;
pp_cxx_left_paren (pp);
- for (; args; args = TREE_CHAIN (args), types = TREE_CHAIN (types))
+ for (; types && types != void_list_node; types = TREE_CHAIN (types))
{
if (!first)
pp_cxx_separate_with (pp, ',');
@@ -1577,6 +1570,14 @@ pp_cxx_parameter_declaration_clause (cxx_pretty_printer
*pp, tree t)
pp_cxx_whitespace (pp);
pp->assignment_expression (TREE_PURPOSE (types));
}
+ if (!abstract)
+ args = TREE_CHAIN (args);
+}
+ if (!types)
+{
+ if (!first)
+ pp_cxx_separate_with (pp, ',');
+ pp_cxx_ws_string (pp, "...");
}
pp_cxx_right_paren (pp);
}
@@ -2775,9 +2776,18 @@ void
pp_cxx_requires_expr (cxx_pretty_printer *pp, tree t)
{
pp_string (pp, "requires");
- if (tree parms = TREE_OPERAND (t, 0))
+ if (tree parms = REQUIRES_EXPR_PARMS (t))
{
- pp_cxx_parameter_declaration_clause (pp, parms);
+ bool first = true;
+ pp_cxx_left_paren (pp);
+ for (; parms; parms = TREE_CHAIN (parms))
+ {
+ if (!first)
+ pp_cxx_separate_with (pp, ',' );
+ first = false;
+ pp_cxx_parameter_declaration (pp, parms);
+ }
+ pp_cxx_right_paren (pp);
pp_cxx_whitespace (pp);
}
pp_cxx_requirement_body (pp, TREE_OPERAND (t, 1));
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic16.C
b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
new file mode 100644
index 000..49d5733faea
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
@@ -0,0 +1,17 @@
+// PR c++/98767
+// { dg-do compile { target c++20 } }
+
+template
+concept Callable = requires(Function func, Args... args) { func(args...); };
+
+static_assert(Callable); // { dg-error "failed" }
+// { dg-message {Function = int \(\*\)\(\)} "" { target *-*-* } 5 }
+
+static_assert(Callable); // { dg-error "failed" }
+// { dg-message {Function = char \(\*\)\(int\*\)} "" { target *-*-* } 5 }
+
[Bug c++/98767] Function signature lost in concept diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98767 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
gcc-9-20210416 is now available
Snapshot gcc-9-20210416 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210416/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision c09606e71d71320e4a0663fe5f825359ba92ce16 You'll find: gcc-9-20210416.tar.xzComplete GCC SHA256=433bf39412d078f0679219cf4441c407ef836ad03e36831a12188f8d269984d8 SHA1=fbba58c17ec5591a93ff474bb8a574cb943e6ce6 Diffs from 9-20210409 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 --- Comment #4 from John Northall --- O dear - that makes gfortran unusable on many existing codes - not really satisfactory is it? John On Fri, Apr 16, 2021 at 11:08 PM pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 > > Andrew Pinski changed: > >What|Removed |Added > > > CC||johnnorthall263 at gmail > dot com > > --- Comment #3 from Andrew Pinski --- > *** Bug 100123 has been marked as a duplicate of this bug. *** > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/93100] gcc -fsanitize=address inhibits -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93100 Bug 93100 depends on bug 98508, which changed state. Bug 98508 Summary: Sanitizer disable -Wall and -Wextra https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98508 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/93100] gcc -fsanitize=address inhibits -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93100 Martin Sebor changed: What|Removed |Added CC||awdawdawdawq123123 at gmx dot de --- Comment #3 from Martin Sebor --- *** Bug 98508 has been marked as a duplicate of this bug. ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 98508, which changed state. Bug 98508 Summary: Sanitizer disable -Wall and -Wextra https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98508 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/98508] Sanitizer disable -Wall and -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98508 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Martin Sebor --- Resolving as a duplicate of pr93100. *** This bug has been marked as a duplicate of bug 93100 ***
[Bug middle-end/93100] gcc -fsanitize=address inhibits -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93100
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.1, 11.0, 9.3.0
CC||msebor at gcc dot gnu.org
Component|sanitizer |middle-end
Last reconfirmed|2020-01-09 00:00:00 |2021-4-16
Status|NEW |ASSIGNED
Depends on||98508
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #2 from Martin Sebor ---
Reconfirming with GCC 11. The reason for the false negative is that
instrumentation functions injected by the sanitizers look to the warning like
they might initialize the variables. That's simply because the warning hasn't
been taught they're special and don't write to the variables. The patch in
pr98508 comment 5 enables the warning. Let me submit it for GCC 12.
void f ()
{
struct A b;
struct A a;
int _1;
:
# .MEM_4 = VDEF <.MEM_3(D)>
.ASAN_MARK (UNPOISON, , 8); <<< assumed to write to a
# VUSE <.MEM_4>
_1 = a.i; <<< missing warning
if (_1 != 0)
goto ; [INV]
else
goto ; [INV]
:
# .MEM_5 = VDEF <.MEM_4>
b = a;
:
# .MEM_2 = PHI <.MEM_4(2), .MEM_5(3)>
# .MEM_6 = VDEF <.MEM_2>
.ASAN_MARK (POISON, , 8);
# VUSE <.MEM_6>
return;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98508
[Bug 98508] Sanitizer disable -Wall and -Wextra
[Bug c++/100127] New: [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
Bug ID: 100127
Summary: [coroutines] internal compiler error compiling promise
with custom awaiter
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: riki--b at hotmail dot it
Target Milestone: ---
Created attachment 50621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50621=edit
Preprocessed source
The following code (preprocessed source in attachments) does not compile and
causes a compiler segfault:
```
#include
#include
struct future
{
using value_type = int;
struct promise_type;
using handle_type = std::coroutine_handle;
handle_type _coroutine;
future(handle_type h) : _coroutine{h} {}
~future() noexcept{
if (_coroutine) {
_coroutine.destroy();
}
}
value_type get() {
auto ptr = _coroutine.promise()._value;
return *ptr;
}
struct promise_type {
std::optional _value = std::nullopt;
future get_return_object() {
return future{handle_type::from_promise(*this)};
}
void return_value(value_type val) {
_value = static_cast(val);
}
auto initial_suspend() noexcept {
class awaiter {
std::optional & value;
public:
explicit awaiter(std::optional & val) noexcept :
value{val} {}
bool await_ready() noexcept { return value.has_value(); }
void await_suspend(handle_type) noexcept { }
value_type & await_resume() noexcept { return *value; }
};
return awaiter{_value};
}
std::suspend_always final_suspend() noexcept {
return {};
}
void return_void() {}
void unhandled_exception() {}
};
};
future create_future()
{ co_return 2021; }
int main()
{ auto f = create_future(); }
```
Returning `std::suspend_never{}` instead of the awaiter compiles correctly.
Output of g++ -v -save-temps -std=c++20 -fcoroutines ${source}.cpp:
```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --ma
ndir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/ --enable-languag
es=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --
enable-__cxa_atexit --enable-cet=auto --enable-checking=release
--enable-clocale=gnu --enable-default-pi
e --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libibe
rty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-thr
eads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror gdc_
include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-m
arch=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test_bug.cpp -mtune=generic
-march=x86-64 -std=c++2a -fcoroutines -fpch-preprocess -o test_bug.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/
include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-m
arch=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -fpreprocessed test_bug.ii
-quiet -dumpbase test_bug.cp
p -mtune=generic -march=x86-64 -auxbase test_bug -std=c++2a -version
-fcoroutines -o test_bug.s
GNU C++17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl
version isl-0.21-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl
version isl-0.21-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum:
[Bug target/63545] ICE when building GCC for ia64-hp-hpux11.23 in hash_table::find_slot_with_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63545 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed|2014-10-16 00:00:00 |2021-04-16 --- Comment #10 from Andrew Pinski --- Does this still happen with GCC 8 and above?
[Bug tree-optimization/89976] [9/10/11 Regression] missing -Wuninitialized for struct member due to sra and TREE_NO_WARNING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
Martin Sebor changed:
What|Removed |Added
Component|c++ |tree-optimization
Summary|missing uninitialized |[9/10/11 Regression]
|warning for uninitialized |missing -Wuninitialized for
|struct member (VOPs)|struct member due to sra
||and TREE_NO_WARNING
Last reconfirmed|2019-11-02 00:00:00 |2021-4-16
CC||msebor at gcc dot gnu.org
Known to fail||10.2.0, 11.0, 4.5.3, 4.6.4,
||4.9.4, 5.5.0, 6.4.0, 7.2.0,
||8.3.0, 9.1.0
--- Comment #4 from Martin Sebor ---
In all cases and with -O1 and above, the uninitialized read is clearly visible
in the IL but it's suppressed because the variable (such as x$x in case 1) has
the TREE_NO_WARNING bit set. This appears to be regression introduced in GCC
4.5 in r147980.
gcc -O1 -S -Wall -std=c++14 -fdump-tree-uninit=/dev/stdout pr89976.C
;; Function foo (_Z3foov, funcdef_no=3, decl_uid=2098, cgraph_uid=4,
symbol_order=3)
struct X foo ()
{
int x$x; <<< TREE_NO_WARNING == 1
struct X D.2133;
[local count: 1073741824]:
D.2133.x = x$x_2(D); <<< uninitialized read
D.2133.y = 0;
return D.2133;
}
;; Function main (main, funcdef_no=4, decl_uid=2129, cgraph_uid=5,
symbol_order=4) (executed once)
int main ()
{
int x$x; <<< TREE_NO_WARNING == 1
struct X D.2156;
struct X x;
[local count: 1073741824]:
x ={v} {CLOBBER};
return x$x_5(D); <<< uninitialized read
}
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #213 from Andrew Pinski --- Does this still happen with GCC 8 or above?
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #38 from Andrew Pinski --- It has been 2 years, does this still happen?
[Bug tree-optimization/89697] [9/10/11 Regression] SRA prevents -Wuninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89697 Martin Sebor changed: What|Removed |Added Known to fail|9.2.0 |4.3.0, 4.8.4, 4.9.4, 5.5.0, ||6.4.0, 7.2.0, 8.3.0, 9.1.0 Summary|SRA prevents|[9/10/11 Regression] SRA |-Wuninitialized warning |prevents -Wuninitialized ||warning --- Comment #3 from Martin Sebor --- Bisection points to r128908 as the first revision when GCC failed to warn.
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 Andrew Pinski changed: What|Removed |Added CC||johnnorthall263 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 100123 has been marked as a duplicate of this bug. ***
[Bug fortran/100123] -ftree-fre gives incorrect result in subroutine with array declared as length 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100123 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This code is undefined. See PR 69360 and why. *** This bug has been marked as a duplicate of bug 69360 ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 89733, which changed state. Bug 89733 Summary: [8/9/10/11 Regression] -Wuninitialized false positive with unclear message pointing to a class name https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug regression/89733] [8/9/10/11 Regression] -Wuninitialized false positive with unclear message pointing to a class name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||msebor at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #12 from Martin Sebor ---
Confirming the unconditional uninitialized read in the IL for the test case in
attachment 4599 and GCC correctly diagnoses it:
;; Function
boost::spirit::lex::lexertl::iterator >, boost::spirit::lex::lexertl::detail::data,
const char*, mpl_::bool_, mpl_::bool_ >
>::iterator >, const char*,
boost::spirit::lex::lexertl::functor >, boost::spirit::lex::lexertl::detail::data,
const char*, mpl_::bool_, mpl_::bool_ > >::iterator_data_type>
(_ZN5boost6spirit3lex7lexertl8iteratorINS2_7functorINS2_5tokenIPKcNS_3mpl6vectorIiN4mpl_2naESB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_SB_EENSA_5bool_ILb1EEEmEENS2_6detail4dataES7_SE_SE_EEEC2INS2_5lexerISF_S7_SI_E18iterator_data_typeEEERKT_RS7_RKS7_S7_,
funcdef_no=13218, decl_uid=464032, cgraph_uid=4528, symbol_order=4816)
void
boost::spirit::lex::lexertl::iterator >, boost::spirit::lex::lexertl::detail::data,
const char*, mpl_::bool_, mpl_::bool_ >
>::iterator >, const char*,
boost::spirit::lex::lexertl::functor >, boost::spirit::lex::lexertl::detail::data,
const char*, mpl_::bool_, mpl_::bool_ > >::iterator_data_type>
(struct iterator * const this, const struct iterator_data_type & iterdata_,
const char * & first, const char * const & last, const char_type * state)
{
...
[local count: 1073741824]:
MEM[(struct __as_base &)] ={v} {CLOBBER};
MEM[(struct data *)] ={v} {CLOBBER};
MEM[(struct __as_base &)] ={v} {CLOBBER};
MEM[(struct data *)].first_ = first_6(D);
_16 = MEM[(const char * const &)last_7(D)];
MEM[(struct data *)].last_ = _16;
_17 = *iterdata__5(D).state_machine_;
MEM[(struct data *)].state_machine_ = _17;
_18 = *iterdata__5(D).rules_;
MEM[(struct data *)].rules_ = _18;
_19 = MEM[(const struct internals &)_17]._seen_BOL_assertion;
MEM[(struct data *)].bol_ = _19;
MEM[(struct data *)].state_ = 0;
_20 = *iterdata__5(D).actions_;
MEM[(struct data *)].actions_ = _20;
MEM[(struct data *)].hold_ = 0B;
MEM[(struct variant *) + 72B] ={v} {CLOBBER};
MEM[(struct aligned_storage *) + 80B] ={v} {CLOBBER};
MEM [(struct value_T *) + 80B] = _16;
MEM [(struct value_T *) + 88B] = _16;
MEM[(struct variant *) + 72B].which_ = 0;
MEM[(struct data *)].has_value_ = 0;
MEM[(struct data *)].has_hold_ = 0;
MEM[(struct pair *)] ={v} {CLOBBER};
MEM[(struct __as_base &) + 8] ={v} {CLOBBER};
MEM[(struct data *) + 8B].D.426958 = MEM[(const struct data
&)].D.426958;
MEM[(struct data *) + 8B].actions_ = _20;
MEM[(struct data *) + 8B].hold_ = 0B;
_57 = MEM[(const struct data &)].end_; <<< -Wuninitialized
MEM[(struct data *) + 8B].end_ = _57;
Likewise, the uninitialized read in the small test case in comment #7 is
diagnosed:
In copy constructor ‘X::X(const X&)’,
inlined from ‘Y::Y(T) [with T = X]’ at pr89733-c7.C:4:12,
inlined from ‘void foo()’ at pr89733-c7.C:18:3:
pr89733-c7.C:11:7: warning: ‘.X::end_’ is used uninitialized
[-Wuninitialized]
11 | class X {
| ^
pr89733-c7.C: In function ‘void foo()’:
pr89733-c7.C:18:11: note: ‘’ declared here
18 | Y(X(0));
| ^
So resolving as invalid as per comment 6.
[Bug c++/100124] Why is "flexible array member '...' in an otherwise empty '...'" an issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- ISO C99 clearly says so: 6.7.2.1/16: "As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member."
[Bug c++/100124] Why is "flexible array member '...' in an otherwise empty '...'" an issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124 --- Comment #1 from Andrew Pinski --- I will let someone comment on the flexible array extension. But I will note GCC treats (all) arrays at the end of a POD struct as a flexible one so the question I have is more about the ubsan issue you are running into, is that with GCC or with clang/LLVM?
[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804 Andrew Pinski changed: What|Removed |Added Known to work||10.0, 11.0 Summary|[8/9/10/11 |[8/9 Regression][AArch64] |Regression][AArch64]|Mis-compilation of loop |Mis-compilation of loop |with strided array access |with strided array access |and xor reduction |and xor reduction | Status|WAITING |NEW --- Comment #14 from Andrew Pinski --- I tested it on both GCC 10.1 and the trunk with "-O3 -fno-vect-cost-model" Both compilers work.
[Bug tree-optimization/100126] missing -Wuninitialized using a trivial member of class with another nontrivial member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100126 Martin Sebor changed: What|Removed |Added Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88175 Blocks||24639 --- Comment #1 from Martin Sebor --- The test case was derived from the one in pr88175 comment 16. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug tree-optimization/100126] New: missing -Wuninitialized using a trivial member of class with another nontrivial member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100126
Bug ID: 100126
Summary: missing -Wuninitialized using a trivial member of
class with another nontrivial member
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Reading an uninitialized trivial member of a struct that contains a member of a
type with a user-defined (or similar) ctor is not diagnosed. The reason is
that the call to the ctor is (exceedingly) conservatively assumed to store into
the other members of the enclosing struct.
$ gcc -O1 -S -Wall -fdump-tree-uninit=/dev/stdout t.C
struct A
{
char *p;
A ();
};
struct B
{
int i;
A a;
};
void f ()
{
B b;
__builtin_printf ("%d\n", b.i); // missing -Wuninitialized
}
;; Function f (_Z1fv, funcdef_no=0, decl_uid=2365, cgraph_uid=4,
symbol_order=3)
void f ()
{
struct B b;
int _1;
[local count: 1073741824]:
A::A (); <<< assumed to set b.i
_1 = b.i;
__builtin_printf ("%d\n", _1);<<< missing -Wuninitialized
b ={v} {CLOBBER};
return;
}
This isn't C++ specific. The same limitation affects C:
struct A
{
char *p;
};
void init (struct A *);
struct B
{
int i;
struct A a;
};
void f ()
{
struct B b;
init ();
__builtin_printf ("%d\n", b.i);
}
[Bug preprocessor/100125] New: -Wunused-macros generated while should be ignored; if undef is seen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100125 Bug ID: 100125 Summary: -Wunused-macros generated while should be ignored; if undef is seen? Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: gcc at behdad dot org Target Milestone: --- We're facing this in HarfBuzz. I narrowed down the bug to this: Works: ```c++ #pragma GCC diagnostic ignored "-Wunused-macros" #define A B ``` $ g++ a.cc -c -Wunused-macros (fine; no warning) But if I add an `undef` to that file: ```c++ #pragma GCC diagnostic ignored "-Wunused-macros" #define A B #undef A ``` $ g++ a.cc -c -Wunused-macros a.cc:3: warning: macros "A" is not used [-Wunused-macros] 3 | #define A B Am I missing something?
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #4 from Steven Munroe ---
I am seeing this a similar problem with union transfers from __float128 to
__int128.
static inline unsigned __int128
vec_xfer_bin128_2_int128t (__binary128 f128)
{
__VF_128 vunion;
vunion.vf1 = f128;
return (vunion.ui1);
}
and
unsigned __int128
test_xfer_bin128_2_int128 (__binary128 f128)
{
return vec_xfer_bin128_2_int128t (f128);
}
generates:
0030 :
30: 57 12 42 f0 xxswapd vs34,vs34
34: 20 00 20 39 li r9,32
38: d0 ff 41 39 addir10,r1,-48
3c: 99 4f 4a 7c stxvd2x vs34,r10,r9
40: f0 ff 61 e8 ld r3,-16(r1)
44: f8 ff 81 e8 ld r4,-8(r1)
48: 20 00 80 4e blr
For POWER8 should use mfvsrd/xxpermdi/mfvsrd.
This looks like the root cause of poor performance for __float128 soft-float on
POWER8. A simple benchmark using __float128 in C code calling libgcc for
-mcpu=power8 and then hardware instructions for -mcpu=power9.
P8 target P8AT14, Uses libgcc __addkf3_sw and __mulkf3_sw:
test_time_f128 f128 CC tb delta = 52589, sec = 0.000102713
P9 Target P8AT14, Uses libgcc __addkf3_hw and __mulkf3_hw:
test_time_f128 f128 CC tb delta = 18762, sec = 3.66445e-05
P9 Target P9AT14, inline hardware binary128 float:
test_time_f128 f128 CC tb delta = 3809, sec = 7.43945e-06
I used Valgrind Itrace and Sim-ppc and perfstat analysis. Every call to libgcc
__add/sub/mul/divkf3 takes a load-hit-store flush every call. This explains why
__float128 is so 13.8 X slower on P8 then P9.
[Bug c/100124] New: Why is "flexible array member '...' in an otherwise empty '...'" an issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124
Bug ID: 100124
Summary: Why is "flexible array member '...' in an otherwise
empty '...'" an issue?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at behdad dot org
Target Milestone: ---
Hi,
In HarfBuzz we extensively use the Struct Hack [0]. Up until now we've used
"array[1]" for that. This upsets ubsan [1]. So I'm looking to replace it with
flexible arrays on compilers that support it.
However, trying to do that I get error if the flexible-array is the only
member. Clang has no issues with it, but gcc gives me: "flexible array member
'...' in an otherwise empty '...'".
```
struct UnsignedArray {
int array[];
};
```
I've seen:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71742
which suggests that disallowing flexible arrays in structs that have no other
named member is intentional. But I cannot find the reason. Can someone please
help me understand, and suggest a solution here?
Note that if I use `int array[0]` instead, then gcc warns everytime in code we
access that array with a constexpr value, like `array[0]` when we know it's
safe to do. That is, gcc seems to treat `int array[0]` literally, not as a
flexible array.
Thank you.
[0] http://c-faq.com/struct/structhack.html
[1] https://github.com/harfbuzz/harfbuzz/issues/2953
[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #17 from Martin Sebor --- For the test case in attachment 45096 GCC 11 emits a nicer message: In file included from header.cpp:5: In member function ‘info& info::operator=(const info&)’, inlined from ‘void test(info_t)’ at header.cpp:10:12: header.h:8:16: warning: ‘copy.info::registered’ is used uninitialized [-Wuninitialized] header.cpp: In function ‘void test(info_t)’: header.cpp:9:12: note: ‘copy’ declared here In file included from header.cpp:5: In copy constructor ‘info::info(const info&)’, inlined from ‘int main()’ at header.cpp:21:9: header.h:8:16: warning: ‘temp.info::registered’ is used uninitialized [-Wuninitialized] header.cpp: In function ‘int main()’: header.cpp:19:12: note: ‘temp’ declared here This looks pretty close to optimal to me. The caret location for the implicitly generated copy assignment is not ideal though. It points to the class definition like so: In member function ‘info& info::operator=(const info&)’, inlined from ‘void test(info_t)’ at pr88175-c0.C.C:12044:12: pr88175-c0.C.C:12036:16: warning: ‘copy.info::registered’ is used uninitialized [-Wuninitialized] 12036 | typedef struct info |^~~~ pr88175-c0.C.C: In function ‘void test(info_t)’: pr88175-c0.C.C:12043:12: note: ‘copy’ declared here 12043 | info_t copy; |^~~~ In copy constructor ‘info::info(const info&)’, inlined from ‘int main()’ at pr88175-c0.C.C:12051:9: pr88175-c0.C.C:12036:16: warning: ‘temp.info::registered’ is used uninitialized [-Wuninitialized] 12036 | typedef struct info |^~~~ pr88175-c0.C.C: In function ‘int main()’: pr88175-c0.C.C:12050:12: note: ‘temp’ declared here 12050 | info_t temp; |^~~~ Pointing to the invocation of the special function might be a better choice. That should be doable by testing the DECL_ARTIFICIAL bit and using the other location instead. The test case in comment #16 isn't diagnosed by GCC 11 at any optimization level anymore (a regression caused by r158271). I think that's something to handle separately.
[Bug fortran/100123] New: -ftree-fre gives incorrect result in subroutine with array declared as length 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100123 Bug ID: 100123 Summary: -ftree-fre gives incorrect result in subroutine with array declared as length 1 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: johnnorthall263 at gmail dot com Target Milestone: --- Created attachment 50620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50620=edit source makefile and output from -save-temps When compiling a program I found it works fine on -O0 but has problems with -Og in a number of subroutines. By trial and error I found that adding -fno-tree-fre with -Og restores correct execution. Further investigation of one subroutine enabled the following simple example to demonstrate the problem. The subroutine setmid is designed to set a mid-point grid with option for repeat boundary condition. The correct mid-point y-coords are:- -1.00 1.00 3.00 5.00 7.00 9.00 11.00 13.00 but -Og gives:- -1.00 1.00 3.00 5.00 7.00 9.00 11.00 11.00 Swapping the order in which the repeat is applied simply shifts the error to the other side of the grid. Bizarrely simply changing the declared dimension of XYM to 2 make it work! First output from "gfortran -c -v -Wall -Wextra -Og -save-temps setmid.f" is:- Using built-in specs. COLLECT_GCC=gfortran OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d --enable-offload-targets=nvptx-none=/usr/nvptx-none,amdgcn-amdhsa=/usr/amdgcn-amdhsa, --without-cuda-driver --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/10 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-10 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] (SUSE Linux) COLLECT_GCC_OPTIONS='-c' '-v' '-Wall' '-Wextra' '-Og' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib64/gcc/x86_64-suse-linux/10/f951 setmid.f -ffixed-form -quiet -dumpbase setmid.f -mtune=generic -march=x86-64 -auxbase setmid -Og -Wall -Wextra -version -fintrinsic-modules-path /usr/lib64/gcc/x86_64-suse-linux/10/finclude -o setmid.s GNU Fortran (SUSE Linux) version 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] (x86_64-suse-linux) compiled by GNU C version 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c], GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (SUSE Linux) version 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c] (x86_64-suse-linux) compiled by GNU C version 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c], GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-c' '-v' '-Wall' '-Wextra' '-Og' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/as -v --64 -o setmid.o setmid.s GNU assembler version 2.35.1 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE Leap 15.2) 2.35.1.20201123-lp152.4.6 COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/10/:/usr/lib64/gcc/x86_64-suse-linux/10/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/10/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ LIBRARY_PATH=/usr/lib64/gcc/x86_64-suse-linux/10/:/usr/lib64/gcc/x86_64-suse-linux/10/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/10/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-c' '-v' '-Wall' '-Wextra' '-Og' '-save-temps' '-mtune=generic' '-march=x86-64' I will attach the source file, plus a short main to call it and a print to display the result. Also, I believe the output of
[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #33 from Vladimir Fuka --- GCC 11 was released and the problem is still present.
[Bug target/96770] -mpure-code produces suboptimal code for relocations with small offset for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770 --- Comment #5 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:0754a104bed7c8a937f0623ad15ca03387131210 commit r11-8227-g0754a104bed7c8a937f0623ad15ca03387131210 Author: Christophe Lyon Date: Fri Apr 16 19:58:25 2021 + testsuite/arm: Fix scan-assembler-times in pr96770.c with movt/movw The previous change to this testcase missed the fact that the data may be accessed via an anchor, depending on the optimization level, leading to false failures. This patch restricts matching to upper16:lower16 followed by non-spaces, followed by +4 (in f4) or +320 (in f5). Using '.*' instead of '[^ \]' would match accross the whole assembly file, which is not what we want, hence the limitation with spaces. 2021-04-16 Christophe Lyon gcc/testsuite/ PR target/96770 * gcc.target/arm/pure-code/pr96770.c: Fix scan-assembler-times with movt/movw.
[Bug c++/74762] [8/9/10/11 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0, ||9.2.0 Last reconfirmed|2016-08-12 00:00:00 |2021-4-16 --- Comment #15 from Martin Sebor --- No change in GCC 11.
[Bug c/100121] RFE: plugin support for -Wformat via __attribute__((format()))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100121 --- Comment #1 from Andrew Pinski --- Related to PR 8294. Also I think this project is referenced in PR 47781 even.
Re: [PATCH] libstdc++: Update ppc32 baseline_symbols.txt
On 16/04/21 20:48 +0200, Jakub Jelinek wrote:
On Fri, Apr 16, 2021 at 05:14:58PM +0200, Jakub Jelinek via Gcc-patches wrote:
As we have only one P1 left right now, I think it is the right time
to update abi list files in libstdc++.
Attached are two patches, one is update for x86_64/i?86/s390x/ppc64
linux (aarch64 seems to be correct already), the other one is the
ppc64 -> ppc64le diff. I have yet to test what exactly it will do
on ppc64, whether we can share the same baseline_symbols.txt and it
will ignore the IEEE128 symbols like it should be ignoring LDBL symbols
when double double is not configured in, or whether we need
to have separate powerpc64le-linux-gnu directory.
2021-04-16 Jakub Jelinek
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
Tested on powerpc64{,le}-linux now (-m32/-m64 on be) and while the first
patch works fine, the second one unfortunately doesn't on either be or le,
so more work is needed there. Thus, I'm withdrawing the second
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
only patch.
On the other side, when I was on powerpc64-linux, I've created a patch
for 32-bit powerpc.
Ok for trunk (this one and the x86_64/i?86/s390x/non-IEEE128 powerpc64 one)?
OK
Re: A suggestion for going forward from the RMS/FSF debate
> On Apr 16, 2021, at 2:41 PM, NightStrike via Gcc wrote: > >> ... > > I was under the (likely incorrect, please enlighten me) impression > that the meteoric rise of LLVM had more to do with the license > allowing corporate contributors to ship derived works in binary form > without sharing proprietary code. My impression is a variation on this: that LLVM is in substantial part motivated by a desire to avoid GPL V3. And that there wasn't such a push when GPL V2 was the version in general use. paul
[Bug libstdc++/100117] FAIL testsuite/17_intro/headers/c++1998/49745.cc with trunk glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100117 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=5 --- Comment #4 from Jonathan Wakely --- includes all standard headers, including . Maybe for the purposes of that test, what we should really check is that none of the C++ headers (i.e. all except and ) includes .
[Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99479 --- Comment #10 from Alexander Lelyakin --- However adding parameter: --param=hash-table-verification-limit=1000 turns this error to PR99861 ICE in hashtab_chk_error /usr/local/bin/g++ --param=hash-table-verification-limit=$N -std=c++20 -fmodules-ts -x c++-system-header condition_variable /usr/local/bin/g++ --param=hash-table-verification-limit=$N -std=c++20 -fmodules-ts -x c++-system-header iosfwd /usr/local/bin/g++ --param=hash-table-verification-limit=$N -std=c++20 -fmodules-ts -x c++-system-header future In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:156:74: error: wrong number of template arguments (1, should be 2) 156 | template > | ^ In file included from /usr/local/include/c++/11.0.1/array:40, from /usr/local/include/c++/11.0.1/tuple:39, from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:451:11: note: provided for ‘template class std::istreambuf_iterator’ 451 | class istreambuf_iterator; | ^~~ In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:158:75: error: wrong number of template arguments (1, should be 2) 158 | template > | ^ In file included from /usr/local/include/c++/11.0.1/array:40, from /usr/local/include/c++/11.0.1/tuple:39, from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:454:11: note: provided for ‘template class std::ostreambuf_iterator’ 454 | class ostreambuf_iterator; | ^~~ In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:177:75: error: wrong number of template arguments (1, should be 2) 177 | template > | ^ In file included from /usr/local/include/c++/11.0.1/array:40, from /usr/local/include/c++/11.0.1/tuple:39, from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:451:11: note: provided for ‘template class std::istreambuf_iterator’ 451 | class istreambuf_iterator; | ^~~ In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:179:75: error: wrong number of template arguments (1, should be 2) 179 | template > | ^ In file included from /usr/local/include/c++/11.0.1/array:40, from /usr/local/include/c++/11.0.1/tuple:39, from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:451:11: note: provided for ‘template class std::istreambuf_iterator’ 451 | class istreambuf_iterator; | ^~~ In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:182:75: error: wrong number of template arguments (1, should be 2) 182 | template > |
[Bug c++/100122] template substitution triggers a segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100122 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Already fixed by r11-3738.
[Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus
from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:454:11: note: provided for ‘template class std::ostreambuf_iterator’ 454 | class ostreambuf_iterator; | ^~~ In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:184:75: error: wrong number of template arguments (1, should be 2) 184 | template > | ^ In file included from /usr/local/include/c++/11.0.1/array:40, from /usr/local/include/c++/11.0.1/tuple:39, from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:454:11: note: provided for ‘template class std::ostreambuf_iterator’ 454 | class ostreambuf_iterator; | ^~~ In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:190:75: error: wrong number of template arguments (1, should be 2) 190 | template > | ^ In file included from /usr/local/include/c++/11.0.1/array:40, from /usr/local/include/c++/11.0.1/tuple:39, from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:451:11: note: provided for ‘template class std::istreambuf_iterator’ 451 | class istreambuf_iterator; | ^~~ In file included from /usr/local/include/c++/11.0.1/string:43, from /usr/local/include/c++/11.0.1/stdexcept:39, from /usr/local/include/c++/11.0.1/system_error:41, from /usr/local/include/c++/11.0.1/mutex:42, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/localefwd.h:192:75: error: wrong number of template arguments (1, should be 2) 192 | template > | ^ In file included from /usr/local/include/c++/11.0.1/array:40, from /usr/local/include/c++/11.0.1/tuple:39, from /usr/local/include/c++/11.0.1/mutex:38, from /usr/local/include/c++/11.0.1/future:38: /usr/local/include/c++/11.0.1/bits/stl_algobase.h:454:11: note: provided for ‘template class std::ostreambuf_iterator’ 454 | class ostreambuf_iterator; | ^~~ corrupted double-linked list corrupted double-linked list g++: internal compiler error: Aborted signal terminated program cc1plus Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210416 (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 target/91710] [9/10 Regression] unexpected ABI change note since r9-5650
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91710 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] |unexpected ABI change note |unexpected ABI change note |since r9-5650 |since r9-5650 --- Comment #9 from Jakub Jelinek --- Fixed on the trunk.
[Bug target/91710] [9/10/11 Regression] unexpected ABI change note since r9-5650
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91710 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:49813aad3292f7f2bef69206274da78a9a7116ed commit r11-8226-g49813aad3292f7f2bef69206274da78a9a7116ed Author: Jakub Jelinek Date: Fri Apr 16 20:49:33 2021 +0200 aarch64: Don't emit -Wpsabi note when ABI was never affected [PR91710] As the following testcase shows, we emit a -Wpsabi note about argument passing change since GCC 9, but in reality the ABI didn't change. The alignment is 8 bits in GCC < 9 and 32 bits in GCC >= 9 and the aarch64_function_arg_alignment returns in that case: return MIN (MAX (alignment, PARM_BOUNDARY), STACK_BOUNDARY); so when both the old and new alignment are smaller or equal to PARM_BOUNDARY (or both are larger than STACK_BOUNDARY, just in theory), even when the new one is bigger, it doesn't change the argument passing. So, the following patch changes aarch64_function_arg_alignment to tell the callers the exact old alignmentm so that they can test it if needed. The other aarch64_function_arg_alignment callers either check the alignment for equality against 16-byte alignment (when old alignment was smaller than that and the new one is 16-byte, we want to emit -Wpsabi in all the cases) or the va_arg case which I think is ok now too. 2021-04-16 Jakub Jelinek PR target/91710 * config/aarch64/aarch64.c (aarch64_function_arg_alignment): Change abi_break argument from bool * to unsigned *, store there the pre-GCC 9 alignment. (aarch64_layout_arg, aarch64_gimplify_va_arg_expr): Adjust callers. (aarch64_function_arg_regno_p): Likewise. Only emit -Wpsabi note if the old and new alignment after applying MIN/MAX to it is different. * gcc.target/aarch64/pr91710.c: New test.
[PATCH] libstdc++: Update ppc32 baseline_symbols.txt
On Fri, Apr 16, 2021 at 05:14:58PM +0200, Jakub Jelinek via Gcc-patches wrote:
> As we have only one P1 left right now, I think it is the right time
> to update abi list files in libstdc++.
>
> Attached are two patches, one is update for x86_64/i?86/s390x/ppc64
> linux (aarch64 seems to be correct already), the other one is the
> ppc64 -> ppc64le diff. I have yet to test what exactly it will do
> on ppc64, whether we can share the same baseline_symbols.txt and it
> will ignore the IEEE128 symbols like it should be ignoring LDBL symbols
> when double double is not configured in, or whether we need
> to have separate powerpc64le-linux-gnu directory.
> 2021-04-16 Jakub Jelinek
>
> * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
> * config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
Tested on powerpc64{,le}-linux now (-m32/-m64 on be) and while the first
patch works fine, the second one unfortunately doesn't on either be or le,
so more work is needed there. Thus, I'm withdrawing the second
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
only patch.
On the other side, when I was on powerpc64-linux, I've created a patch
for 32-bit powerpc.
Ok for trunk (this one and the x86_64/i?86/s390x/non-IEEE128 powerpc64 one)?
2021-04-16 Jakub Jelinek
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update.
--- libstdc++-v3/config/abi/post/powerpc-linux-gnu/baseline_symbols.txt.jj
2020-12-03 20:32:34.311497207 +0100
+++ libstdc++-v3/config/abi/post/powerpc-linux-gnu/baseline_symbols.txt
2021-04-16 20:04:54.894440717 +0200
@@ -199,6 +199,14 @@ FUNC:_ZNK11__gnu_debug16_Error_formatter
FUNC:_ZNK11__gnu_debug16_Error_formatter8_M_errorEv@@GLIBCXX_3.4
FUNC:_ZNK11__gnu_debug19_Safe_iterator_base11_M_singularEv@@GLIBCXX_3.4
FUNC:_ZNK11__gnu_debug19_Safe_iterator_base14_M_can_compareERKS0_@@GLIBCXX_3.4
+FUNC:_ZNKRSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_istringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.29
+FUNC:_ZNKRSt7__cxx1119basic_ostringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.29
FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4.5
FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@GLIBCXX_3.4
FUNC:_ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofEPKwj@@GLIBCXX_3.4
@@ -998,19 +1006,29 @@ FUNC:_ZNKSt7__cxx1112basic_stringIwSt11c
FUNC:_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE8max_sizeEv@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEcvSt17basic_string_viewIwS2_EEv@@GLIBCXX_3.4.26
FUNC:_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEEixEj@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE13get_allocatorEv@@GLIBCXX_3.4.29
FUNC:_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE4viewEv@@GLIBCXX_3.4.29
+FUNC:_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE13get_allocatorEv@@GLIBCXX_3.4.29
FUNC:_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEE4viewEv@@GLIBCXX_3.4.29
FUNC:_ZNKSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE4viewEv@@GLIBCXX_3.4.29
FUNC:_ZNKSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEE5rdbufEv@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE4viewEv@@GLIBCXX_3.4.29
FUNC:_ZNKSt7__cxx1118basic_stringstreamIwSt11char_traitsIwESaIwEE5rdbufEv@@GLIBCXX_3.4.21
FUNC:_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4.21
+FUNC:_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE4viewEv@@GLIBCXX_3.4.29
FUNC:_ZNKSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEE5rdbufEv@@GLIBCXX_3.4.21
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, Apr 16, 2021 at 7:23 AM Ville Voutilainen via Gcc wrote: > On the first part, other people have touched on it already, > but the fear of a dreaded non-free software vendor co-opting > GCC as a library to a non-free project has resulted in GCC > being unsuitable to be used as a library in free software > projects. This approach alone made sure that the meteoric > rise of LLVM happened; there are recorded statements > from LLVM developers trying to talk about this to RMS, > and the answer, as they phrased it, "wasn't useful", because > RMS decided that GCC shouldn't be a library to make it > harder to use it in conjunction with non-free programs. > > Congratulations, it remains hard to use in conjunction > with free programs, and everybody who wants to do something > like that looks at LLVM first. RMS made a lofty attempt to > promote copyleft software for such purposes, and failed > miserably, leading us into a situation where such problems > are not solved with copyleft software, but with LLVM instead. I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. Intel, IBM, nVidia, etc. are migrating towards LLVM for this purpose. To do so using GCC would (I believe; again, please correct me) require that they share more source code than they would have to under LLVM. This licensing model makes working on LLVM more attractive to companies that wish to keep proprietary code hidden, and thus LLVM garners a lot of corporate backing. It seems to me that technical differences (easier porting, or early claims of better diagnostics, for instance) and culture differences (let's just say that LLVM developers are more friendly, although I've never encountered a mean GCC developer) are not the driving force behind such strong support. As usual in the world, follow the money. If the idea is that GCC-as-a-Library would enable Intel, for example, to use GCC for their ICX OneAPI compiler the way they are now using LLVM, with significant portions of it hidden from the user, it seems to me that not supporting this is a very consistent GNU view. Allowing derived works that don't publish the full source code seems to be against the very spirit of GNU. If the GCC project opts to distance itself from various three letter acronyms, as a user, I have to wonder what that means in the future regarding the strict adherence to software freedoms that GCC has had for a long time now. I don't think I would suggest that there would be an immediate knee jerk reaction to change everything. Instead, it seems that https://en.wikipedia.org/wiki/Creeping_normality would take place to slowly change the "Freedom first" ideology over time. Maybe I'm jaded by the recent changes to CentOS, where RedHat applied a Microsoft tactic to embrace, extend, and extinguish it (at least in the form we previously knew). That took about ten years, but I can easily see how the same thing could happen over a long period of time to GCC (note that often when this has happened in history, including outside of the computing world, it was difficult or impossible to predict how it could end poorly. Padme's "thunderous applause" cheats, in that we saw the sequels first :) ) It would be good, therefore, to address upfront how the software freedoms of GCC users would be as consistently guaranteed in the future as they are now. Would a future GCC be committed to universally blocking any hypothetical positive technical improvement that also reduced user freedom?
[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081 Andrew Macleod changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com --- Comment #9 from Andrew Macleod --- Created attachment 50619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50619=edit proposed fix I've added a depth limited for logical combinations. In this patch its set to 6.. I'm going to try running it against various scenarios to make sure it doesn't miss anything we do want... and of course I'll bootstrap and regtest it. If you want to try it, this should resolve the issue.
[Patch, fortran v2] PR fortran/84006, PR fortran/100027 - ICE on storage_size with polymorphic argument
Hi All!
Proposed patch to:
PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS entity
PR100027 - ICE on storage_size with polymorphic argument
Patch tested only on x86_64-pc-linux-gnu.
Add branch to if clause to handle polymorphic objects, not sure if I got
all possible variations...
Now with a new and extended test.
Thank you very much.
Best regards,
José Rui
Fortran: Fix ICE using storage_size intrinsic [PR84006, PR100027]
gcc/fortran/ChangeLog:
PR fortran/84006
PR fortran/100027
* trans-intrinsic.c (gfc_conv_intrinsic_storage_size): add if
clause branch to handle polymorphic objects.
gcc/testsuite/ChangeLog:
PR fortran/84006
* gfortran.dg/PR84006.f90: New test.
PR fortran/100027
* gfortran.dg/PR100027.f90: New test.
diff --git a/configure b/configure
index 504f6410274..1be51708c03 100755
--- a/configure
+++ b/configure
@@ -756,6 +756,7 @@ infodir
docdir
oldincludedir
includedir
+runstatedir
localstatedir
sharedstatedir
sysconfdir
@@ -922,6 +923,7 @@ datadir='${datarootdir}'
sysconfdir='${prefix}/etc'
sharedstatedir='${prefix}/com'
localstatedir='${prefix}/var'
+runstatedir='${localstatedir}/run'
includedir='${prefix}/include'
oldincludedir='/usr/include'
docdir='${datarootdir}/doc/${PACKAGE}'
@@ -1174,6 +1176,15 @@ do
| -silent | --silent | --silen | --sile | --sil)
silent=yes ;;
+ -runstatedir | --runstatedir | --runstatedi | --runstated \
+ | --runstate | --runstat | --runsta | --runst | --runs \
+ | --run | --ru | --r)
+ac_prev=runstatedir ;;
+ -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
+ | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
+ | --run=* | --ru=* | --r=*)
+runstatedir=$ac_optarg ;;
+
-sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
ac_prev=sbindir ;;
-sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1311,7 +1322,7 @@ fi
for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
- libdir localedir mandir
+ libdir localedir mandir runstatedir
do
eval ac_val=\$$ac_var
# Remove trailing slashes.
@@ -1471,6 +1482,7 @@ Fine tuning of the installation directories:
--sysconfdir=DIRread-only single-machine data [PREFIX/etc]
--sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
+ --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]
--libdir=DIRobject code libraries [EPREFIX/lib]
--includedir=DIRC header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 5e53d1162fa..6536c121f2b 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -8353,10 +8353,16 @@ gfc_conv_intrinsic_storage_size (gfc_se *se, gfc_expr *expr)
if (arg->ts.type == BT_CLASS)
{
if (arg->rank > 0)
- tmp = gfc_class_vtab_size_get (
- GFC_DECL_SAVED_DESCRIPTOR (arg->symtree->n.sym->backend_decl));
+ {
+ if (TREE_CODE (argse.expr) == COMPONENT_REF)
+ tmp = TREE_OPERAND (argse.expr, 0);
+ else
+ tmp = GFC_DECL_SAVED_DESCRIPTOR (
+ arg->symtree->n.sym->backend_decl);
+ }
else
- tmp = gfc_class_vtab_size_get (TREE_OPERAND (argse.expr, 0));
+ tmp = TREE_OPERAND (argse.expr, 0);
+ tmp = gfc_class_vtab_size_get (tmp);
tmp = fold_convert (result_type, tmp);
goto done;
}
diff --git a/gcc/testsuite/gfortran.dg/PR100027.f90 b/gcc/testsuite/gfortran.dg/PR100027.f90
new file mode 100644
index 000..4cee549d055
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100027.f90
@@ -0,0 +1,425 @@
+! { dg-do run }
+!
+! Test fix for PR100027
+!
+! in colaboration with Tobias Burnus.
+!
+
+program main_p
+
+ implicit none
+
+ integer, parameter :: n = 111
+
+ integer, parameter :: ikind = kind(n)
+ integer, parameter :: bsize = 8
+ integer, parameter :: isize = bit_size(n)
+ integer, parameter :: dsize = (n+1)*isize
+
+ type :: foo_t
+integer :: i
+ end type foo_t
+
+ type, extends(foo_t) :: bar_t
+integer :: j(n)
+ end type bar_t
+
+ type :: box_t
+class(foo_t), allocatable :: x, y(:)
+ end type box_t
+
+ integer, target :: ain(n)
+ type(foo_t), target :: afd(n)
+ type(bar_t), target :: abd(n)
+ type(box_t), target :: afx(n)
+ type(box_t), target :: abx(n)
+ !
+ class(*), pointer :: spu
+ class(*), pointer :: apu(:)
+ !
+ class(foo_t), pointer :: spf
+ class(foo_t), pointer :: apf(:)
+ !
+ class(bar_t), pointer :: spb
+ class(bar_t), pointer :: apb(:)
+ !
+ class(box_t), pointer :: spx
+ class(box_t), pointer :: apx(:)
+ !
+ integer :: i, j, so, ss
+
+ ain = [(i, i=1,n)]
+
[Bug c++/99948] [modules] ICE in add_mergeable_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99948 --- Comment #1 from Alexander Lelyakin --- Adding parameter: --param=hash-table-verification-limit=1000 turns this error to PR99861 ICE in hashtab_chk_error
Re: [committed] Make SVE tests work with --with-cpu
Christophe Lyon writes: > On Thu, 15 Apr 2021 at 17:19, Richard Sandiford via Gcc-patches > wrote: >> >> A lot of the SVE assembly tests are for generic-tuned SVE codegen >> and so can fail when run on a toolchain configured with --with-cpu. >> >> This could easily be solved by forcing -mtune=generic, like we already >> do for -moverride=tune=none. However, the testsuite also has some >> useful execution tests that it would be better to run with as >> few flag changes as possible. Also, the flags in $sve_flags are >> printed as part of the test results, so each change to $sve_flags >> results in a change to the test summaries. >> >> This patch instead intercepts dg-options and tailors the list >> of additional options based on what the test is trying to do. >> It also gets rid of DEFAULT_CFLAGS, which are never useful >> for these tests. >> >> Tested on an aarch64-linux-gnu toolchain configured with >> --with-cpu=a64fx, pushed to trunk. >> >> Richard > > This looks nice, I'm wondering whether something similar would help clean up > the > arm side of the testsuite where it has become a nightmare to deal with all the > cpu/fpu/float-abi combinations? Yeah, it probably could. I wondered about trying to make it more general than just aarch64, but in the end the small size of the code and the number of AArch64-specific bits made it seem like it wouldn't be a good idea. If more targets add something similar, that might give an idea of where the common ground is. I imagine things will be more complex for arm though. FWIW, for mips.exp I used a complicated scheme to automatically infer a sequence of options based on the (usually single) feature that the test specifically needed. It ended up being way too elaborate though. I don't think any other target should replicate that. I guess arm would need something in between the two in terms of complexity. Thanks, Richard
Re: [PATCH] IBM Z: Add alternative to *movdi_{31, 64} in order to load a DFP zero
On 4/12/21 3:40 PM, Stefan Schulze Frielinghaus wrote:
> Bootstraped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
> alternative in order to load a DFP zero.
Ok, thanks!
Andreas
> ---
> gcc/config/s390/s390.md | 25 ++---
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
> index c10f25b2472..7faf775fbf2 100644
> --- a/gcc/config/s390/s390.md
> +++ b/gcc/config/s390/s390.md
> @@ -1868,9 +1868,9 @@
>
> (define_insn "*movdi_64"
>[(set (match_operand:DI 0 "nonimmediate_operand"
> - "=d,d,d,d,d, d,d,
> d,f,d,d,d,d,d,T,!*f,!*f,!*f,!R,!T,b,Q,d,t,Q,t,v,v,v,d,v,R,d")
> + "=d,d,d,d,d, d,d,
> d,f,d,!*f,d,d,d,d,T,!*f,!*f,!*f,!R,!T,b,Q,d,t,Q,t,v,v,v,d,v,R,d")
> (match_operand:DI 1 "general_operand"
> - " K,N0HD0,N1HD0,N2HD0,N3HD0,Os,N0SD0,N1SD0,d,f,L,b,d,T,d, *f, R,
> T,*f,*f,d,K,t,d,t,Q,K,v,d,v,R,v,ZL"))]
> + " K,N0HD0,N1HD0,N2HD0,N3HD0,Os,N0SD0,N1SD0,d,f,j00,L,b,d,T,d, *f,
> R, T,*f,*f,d,K,t,d,t,Q,K,v,d,v,R,v,ZL"))]
>"TARGET_ZARCH"
>"@
> lghi\t%0,%h1
> @@ -1883,6 +1883,7 @@
> llilf\t%0,%k1
> ldgr\t%0,%1
> lgdr\t%0,%1
> + lzdr\t%0
> lay\t%0,%a1
> lgrl\t%0,%1
> lgr\t%0,%1
> @@ -1906,13 +1907,13 @@
> vleg\t%v0,%1,0
> vsteg\t%v1,%0,0
> larl\t%0,%1"
> - [(set_attr "op_type" "RI,RI,RI,RI,RI,RIL,RIL,RIL,RRE,RRE,RXY,RIL,RRE,RXY,
> + [(set_attr "op_type"
> "RI,RI,RI,RI,RI,RIL,RIL,RIL,RRE,RRE,RRE,RXY,RIL,RRE,RXY,
>
> RXY,RR,RX,RXY,RX,RXY,RIL,SIL,*,*,RS,RS,VRI,VRR,VRS,VRS,
> VRX,VRX,RIL")
> - (set_attr "type" "*,*,*,*,*,*,*,*,floaddf,floaddf,la,larl,lr,load,store,
> + (set_attr "type"
> "*,*,*,*,*,*,*,*,floaddf,floaddf,fsimpdf,la,larl,lr,load,store,
> floaddf,floaddf,floaddf,fstoredf,fstoredf,larl,*,*,*,*,
> *,*,*,*,*,*,*,larl")
> - (set_attr "cpu_facility" "*,*,*,*,*,extimm,extimm,extimm,dfp,dfp,longdisp,
> + (set_attr "cpu_facility"
> "*,*,*,*,*,extimm,extimm,extimm,dfp,dfp,*,longdisp,
> z10,*,*,*,*,*,longdisp,*,longdisp,
> z10,z10,*,*,*,*,vx,vx,vx,vx,vx,vx,*")
> (set_attr "z10prop" "z10_fwd_A1,
> @@ -1925,6 +1926,7 @@
> z10_fwd_E1,
> *,
> *,
> + *,
> z10_fwd_A1,
> z10_fwd_A3,
> z10_fr_E1,
> @@ -1942,7 +1944,7 @@
> *,
> *,*,*,*,*,*,*,
> z10_super_A1")
> - (set_attr "relative_long" "*,*,*,*,*,*,*,*,*,*,
> + (set_attr "relative_long" "*,*,*,*,*,*,*,*,*,*,*,
>*,yes,*,*,*,*,*,*,*,*,
>yes,*,*,*,*,*,*,*,*,*,
>*,*,yes")
> @@ -2002,9 +2004,9 @@
>
> (define_insn "*movdi_31"
>[(set (match_operand:DI 0 "nonimmediate_operand"
> -"=d,d,Q,S,d ,o,!*f,!*f,!*f,!R,!T,d")
> +"=d,d,Q,S,d ,o,!*f,!*f,!*f,!*f,!R,!T,d")
> (match_operand:DI 1 "general_operand"
> -" Q,S,d,d,dPT,d, *f, R, T,*f,*f,b"))]
> +" Q,S,d,d,dPT,d, *f, R, T,j00,*f,*f,b"))]
>"!TARGET_ZARCH"
>"@
> lm\t%0,%N0,%S1
> @@ -2016,12 +2018,13 @@
> ldr\t%0,%1
> ld\t%0,%1
> ldy\t%0,%1
> + lzdr\t%0
> std\t%1,%0
> stdy\t%1,%0
> #"
> - [(set_attr "op_type" "RS,RSY,RS,RSY,*,*,RR,RX,RXY,RX,RXY,*")
> - (set_attr "type"
> "lm,lm,stm,stm,*,*,floaddf,floaddf,floaddf,fstoredf,fstoredf,*")
> - (set_attr "cpu_facility"
> "*,longdisp,*,longdisp,*,*,*,*,longdisp,*,longdisp,z10")])
> + [(set_attr "op_type" "RS,RSY,RS,RSY,*,*,RR,RX,RXY,RRE,RX,RXY,*")
> + (set_attr "type"
> "lm,lm,stm,stm,*,*,floaddf,floaddf,floaddf,fsimpdf,fstoredf,fstoredf,*")
> + (set_attr "cpu_facility"
> "*,longdisp,*,longdisp,*,*,*,*,longdisp,*,*,longdisp,z10")])
>
> ; For a load from a symbol ref we can use one of the target registers
> ; together with larl to load the address.
>
[Bug c++/100122] New: template substitution triggers a segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100122
Bug ID: 100122
Summary: template substitution triggers a segfault
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 60rntogo at gmail dot com
Target Milestone: ---
Created attachment 50618
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50618=edit
preprocessed file
This code:
template struct A
{
struct B
{
template using C = T;
using D = C;
};
};
compiled with:
g++-10 -std=c++2a test.cpp
triggers:
test.cpp: In substitution of ‘template template using C = T
[with T = A< >; =
]’:
test.cpp:6:18: required from here
test.cpp:6:18: internal compiler error: Segmentation fault
6 | using D = C;
GCC version:
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.2.0-13ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-JvwpWM/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-JvwpWM/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (Ubuntu 10.2.0-13ubuntu1)
[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081 --- Comment #8 from Andrew Macleod --- OMG. Don't bother reducing. I can see the problem. EVRP is fine, but when wrestrict runs, its quite late, and the CFG has [local count: 28382607]: <...> _571 = _61 >= _593; _3583 = _724 + _3992; _2220 = _831 <= _3583; _47 = _571 | _2220; _2935 = _376 * 2; _3966 = _725 + _2935; _3024 = _61 >= _3966; _4219 = _3992 * 2; _4218 = _725 + _4219; _1836 = _831 <= _4218; _3080 = _1836 | _3024; <...> _5348 = _5347 & _32080; _5349 = _5348 & _32151; _5350 = _5349 & _32176; _5351 = _5350 & _32488; _5352 = _5351 & _33691; _5353 = _5352 & _33762; _5354 = _5353 & _34753; _35662 = _5354 & _34824; if (_35662 != 0) goto ; [90.00%] else goto ; [10.00%] Its a 7200 stmt basic block, made up of calculations and 2614 ORs and 1480 ANDs. A request is made for a range which can be exported from this block, and ranger is dutifully trying everything it can to process those blocks. Each AND/OR is a logical expression which evaluates a TRUE and FALSE range for each operands, so it calculates up to 4 ranges for each pair of operands. I knew this could get out of hand in pathological cases, so we introduced a logical cache to help resolve this and avoid extra work. Its actually making this one worse I think. Regardless, I know what the issue is. I have 2 things to try. 1) We have a patch in our branch that gives up early.. once it finds the result is going to be varying... I'll give that a shot first, it may stop this lookup quickly. Its possible it won't. if not, then 2) we've also discussed that in ridiculously large combinations of &&/|| we are unlikely to be able to haul a useful range out of it, so limit the depth of logical processing to something in a reasonable range. 4000 logicals operations is not reasonable to look thru. something more akin to 10 maybe at most.. Anyway, I know what the issue is and will have it resolved early next week at the latest.
Re: Aarch64 patch ping^3
Jakub Jelinek via Gcc-patches writes: > On Wed, Apr 07, 2021 at 03:53:26PM +0200, Jakub Jelinek via Gcc-patches wrote: >> On Mon, Mar 29, 2021 at 11:16:55AM +0200, Jakub Jelinek wrote: >> > > Looks good to me. Richard E knows this code better than I do though, >> > > so I think he should have the final say. He's currently on holiday >> > > but will be back next week. >> > >> > I'd like to ping this patch. >> >> Ping. > > Ping. Let's go for it. I still think the patch looks good, and if a problem crops up then we still have time to fix it before the release. Applying it now seems better than applying it closer to the release. Thanks, Richard > >> > > > 2021-03-18 Jakub Jelinek >> > > > >> > > >PR target/91710 >> > > >* config/aarch64/aarch64.c (aarch64_function_arg_alignment): >> > > > Change >> > > >abi_break argument from bool * to unsigned *, store there the >> > > > pre-GCC 9 >> > > >alignment. >> > > >(aarch64_layout_arg, aarch64_gimplify_va_arg_expr): Adjust >> > > > callers. >> > > >(aarch64_function_arg_regno_p): Likewise. Only emit -Wpsabi >> > > > note if >> > > >the old and new alignment after applying MIN/MAX to it is >> > > > different. >> > > > >> > > >* gcc.target/aarch64/pr91710.c: New test. > > Thanks > > Jakub
Re: [PATCH] testsuite/arm: Fix scan-assembler-times in pr96770.c with movt/movw
Sorry the slow reply. I'm not well versed on the all AArch32 combinations
but it looks good to me.
Christophe Lyon via Gcc-patches writes:
> The previous change to this testcase missed the fact that the data may
> be accessed via an anchor, depending on the optimization level,
> leading to false failures.
>
> This patch restricts matching to upper16:lower16 followed by
> non-spaces, followed by +4 (in f4) or +320 (in f5).
>
> Using '.*' instead of '[^ \]' would match accross the whole assembly
> file, which is not what we want, hence the limitation with spaces.
>
> 2021-03-29 Christophe Lyon
>
> gcc/testsuite/
> PR target/96770
> * gcc.target/arm/pure-code/pr96770.c: Fix scan-assembler-times
> with movt/movw.
OK, thanks.
Richard
> ---
> gcc/testsuite/gcc.target/arm/pure-code/pr96770.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> index ae1bd10..3c69614 100644
> --- a/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> +++ b/gcc/testsuite/gcc.target/arm/pure-code/pr96770.c
> @@ -4,12 +4,13 @@
> int arr[1000];
> int *f4 (void) { return [1]; }
>
> -/* For cortex-m0 (thumb-1/v6m), we generate 4 movs with upper/lower:#arr+4.
> */
> +/* For cortex-m0 (thumb-1/v6m), we generate 2 pairs of movs/adds with
> upper/lower:#arr+4. */
> /* { dg-final { scan-assembler-times "arr\\+4" 4 { target { { !
> arm_thumb1_movt_ok } && { ! arm_thumb2_ok } } } } } */
>
> /* For cortex-m with movt/movw (thumb-1/v8m.base or thumb-2), we
> - generate a movt/movw pair with upper/lower:#arr+4. */
> -/* { dg-final { scan-assembler-times "arr\\+4" 2 { target {
> arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> + generate a movt/movw pair with upper/lower:#arr+4 possibly via an anchor.
> */
> +/* { dg-final { scan-assembler-times "upper16:\[^ \]+.\\+4" 1 { target {
> arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> +/* { dg-final { scan-assembler-times "lower16:\[^ \]+\\+4" 1 { target {
> arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
>
> int *f5 (void) { return [80]; }
>
> @@ -17,5 +18,6 @@ int *f5 (void) { return [80]; }
> /* { dg-final { scan-assembler-times "arr\\+320" 1 { target { { !
> arm_thumb1_movt_ok } && { ! arm_thumb2_ok } } } } } */
>
> /* For cortex-m with movt/movw (thumb-1/v8m.base or thumb-2), we
> - generate a movt/movw pair with upper/lower:arr+320. */
> -/* { dg-final { scan-assembler-times "arr\\+320" 2 { target {
> arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> + generate a movt/movw pair with upper/lower:arr+320 possibly via an
> anchor. */
> +/* { dg-final { scan-assembler-times "upper16:\[^ \]+\\+320" 1 { target {
> arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
> +/* { dg-final { scan-assembler-times "lower16:\[^ \]+\\+320" 1 { target {
> arm_thumb1_movt_ok || arm_thumb2_ok } } } } */
Re: A suggestion for going forward from the RMS/FSF debate
> On Apr 16, 2021, at 6:13 AM, Ville Voutilainen via Gcc-patches > wrote: > > The actual suggestion is at the end; skip straight to it if you wish. Could you shift this discussion to the gcc list where it fits better? gcc-patches is for discussion patches to the code. paul
Re: removing toxic emailers
On Thu, Apr 15, 2021, 23:42 Iain Sandoe via Gcc wrote: > it is essential (IMO) that review of code is carried out on a fair and > technical basis without personal attack or harrassment (or > unwelcome unrelated attention). > Is this not the case on gcc-patches? >
Re: [PATCH 1/3] openacc: Add support for gang local storage allocation in shared memory
Hi!
On 2021-04-16T17:05:24+0100, Andrew Stubbs wrote:
> On 15/04/2021 18:26, Thomas Schwinge wrote:
>>> and optimisation, since shared memory might be faster than
>>> the main memory on a GPU.
>>
>> Do we potentially have a problem that making more use of (scarce)
>> gang-private memory may negatively affect peformance, because potentially
>> fewer OpenACC gangs may then be launched to the GPU hardware in parallel?
>> (Of course, OpenACC semantics conformance firstly is more important than
>> performance, but there may be ways to be conformant and performant;
>> "quality of implementation".) Have you run any such performance testing
>> with the benchmarking codes that we've got set up?
>>
>> (As I'm more familiar with that, I'm using nvptx offloading examples in
>> the following, whilst assuming that similar discussion may apply for GCN
>> offloading, which uses similar hardware concepts, as far as I remember.)
>
> Yes, that could happen.
Thanks for sharing the GCN perspective.
> However, there's space for quite a lot of
> scalars before performance is affected: 64KB of LDS memory shared by a
> hardware-defined maximum of 40 threads
(Instead of threads, something like thread blocks, I suppose?)
> gives about 1.5KB of space for
> worker-reduction variables and gang-private variables.
PTX, as I understand this, may generally have a lot of Thread Blocks in
flight: all for the same GPU kernel as well as any GPU kernels running
asynchronously/generally concurrently (system-wide), and libgomp does try
launching a high number of Thread Blocks ('num_gangs') (for purposes of
hiding memory access latency?). Random example:
nvptx_exec: kernel t0_r$_omp_fn$0: launch gangs=1920, workers=32, vectors=32
With that, PTX's 48 KiB of '.shared' memory per SM (processor) are then
not so much anymore: just '48 * 1024 / 1920 = 25' bytes of gang-private
memory available for each of the 1920 gangs: 'double x, y, z'? (... for
the simple case where just one GPU kernel is executing.)
(I suppose that calculation is valid for a GPU hardware variant where
there is just one SM. If there are several (typically in the order of a
few dozens?), I suppose the Thread Blocks launched will be distributed
over all these, thus improving the situation correspondingly.)
(And of course, there are certainly other factors that also limit the
number of Thread Blocks that are actually executing in parallel.)
> We might have a
> problem if there are large private arrays.
Yes, that's understood.
Also, directly related, the problem that comes with supporting
worker-private memory, which basically calculates to the amount necessary
for gang-private memory multiplied by the number of workers? (Out of
scope at present.)
> I believe we have a "good enough" solution for the usual case
So you believe that. ;-)
It's certainly what I'd hope, too! But we don't know yet whether there's
any noticeable performance impact if we run with (potentially) lesser
parallelism, hence my question whether this patch has been run through
performance testing.
> and a
> v2.0 full solution is going to be big and hairy enough for a whole patch
> of it's own (requiring per-gang dynamic allocation, a different memory
> address space and possibly different instruction selection too).
Agree that a fully dynamic allocation scheme likely is going to be ugly,
so I'd certainly like to avoid that.
Before attempting that, we'd first try to optimize gang-private memory
allocation: so that it's function-local (and thus GPU kernel-local)
instead of device-global (assuming that's indeed possible), and try not
using gang-private memory in cases where it's not actually necessary
(semantically not observable, and not necessary for performance reasons).
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
[Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446 Martin Sebor changed: What|Removed |Added Last reconfirmed|2014-10-03 00:00:00 |2021-4-16 Known to fail||10.2.0, 11.0, 4.6.4, 4.9.4, ||5.5.0, 6.4.0, 7.2.0, 8.3.0, ||9.1.0 CC||msebor at gcc dot gnu.org Severity|normal |enhancement Blocks||49974 --- Comment #9 from Martin Sebor --- GCC 11 improves the message by including a note that mentions the uninitialized variable. In this case it doesn't completely solve the problem because the variable it points to is initialized but it should help. pr63446.C: In function ‘int func()’: pr63446.C:15:14: warning: ‘x’ is used uninitialized [-Wuninitialized] 15 | return f.ref; | ^~~ pr63446.C:8:9: note: ‘x’ was declared here 8 | int x = 42; | ^ But the underlying bug here is returning a reference to a local variable, so the warning to improve is -Wreturn-local-addr. That will diagnose the return statement in make_foo(). Bug 49974 tracks that enhancement. With that, the additional -Wuninitialized issued in func() would just help clarify the consequences of the bug but not otherwise be essential. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974 [Bug 49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary
Re: A suggestion for going forward from the RMS/FSF debate
On 4/16/2021 9:57 AM, Thomas Koenig via Gcc wrote: Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. I don't think your emails have done any harm. I find them quite valuable, so I'm sad to see you dropping yourself from the gcc@ list. jeff
Re: A suggestion for going forward from the RMS/FSF debate
> The authority of the FSF, GNU and RMS over GCC is and has been a > fiction for decades, For the most part, I agree. > It would be usefull to clarify with the FSF and GNU what the > actual relations are, Why? What would that gain? I go back to my analogy of the British Queen. What would be gained by "clarifying" that if she actually intervenes non-trivially in the government of any Commonwealth nation, she'd lose that power?
[Bug tree-optimization/100115] Bogus -Wmaybe-uninitialized warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100115 Martin Sebor changed: What|Removed |Added Component|c++ |tree-optimization CC||msebor at gcc dot gnu.org Keywords||diagnostic Blocks||24639 --- Comment #1 from Martin Sebor --- I can confirm the warning but the test case is far too big for me to say whether or not it's valid. As it turns out, the test case is also too big for GCC as it exceeds at least one internal limit named MAX_CHAIN_LEN. The limit is hardcoded to an exceedingly low value of 5 but with the test case reaches 77. Exceeding this limit can lead to either false positives or negatives. But bumping it way up doesn't avoid the warning so something else is going on. I'm trying to reduce the test case to something manageable but that can take many hours, even days. It would be really helpful if you could trim it down a bit, e.g., by removing the biggest non-essentials like . That being said, the context of the warning mentions std::optional which has been known to be challenging for analysis and has led to false positives (see pr80635 and related) as well as less than optimal code in the past, so I expect this is going to caused by a similar limitation. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug c++/100109] [8/9/10/11 Regression] ICE: unexpected expression 'E' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109 --- Comment #1 from Marek Polacek --- Started with r251433.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #24 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4a1493f0603262a7dc1114d9827353e9810e63dc commit r11-8225-g4a1493f0603262a7dc1114d9827353e9810e63dc Author: Jakub Jelinek Date: Fri Apr 16 18:32:27 2021 +0200 intl: Add --enable-host-shared support [PR100096] As mentioned in the PR, building gcc with jit enabled and --enable-host-shared doesn't work on NetBSD/i?86, as libgccjit.so.0 has text relocations. The r0-125846-g459260ecf8b420b029601a664cdb21c185268ecb changes added --enable-host-shared support to various libraries, but didn't add it to intl/ subdirectory; on Linux it isn't really needed, because all: all-no all-no: #nothing but on other OSes intl/libintl.a is built. The following patch makes sure it is built with -fPIC when --enable-host-shared is used. 2021-04-16 Jakub Jelinek PR jit/100096 * configure.ac: Add --enable-host-shared support. * Makefile.in: Update copyright. Add @PICFLAG@ to CFLAGS. * configure: Regenerated.
[Bug c++/100109] [8/9/10/11 Regression] ICE: unexpected expression 'E' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-04-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |8.5 Summary|ICE: unexpected expression |[8/9/10/11 Regression] ICE: |'E' of kind |unexpected expression 'E' |template_parm_index |of kind template_parm_index CC||mpolacek at gcc dot gnu.org Priority|P3 |P2 Keywords||ice-on-invalid-code
Re: removing toxic emailers
On Thu, Apr 15, 2021 at 9:08 PM Frosku wrote: > > On the other hand, I also think that a project which goes too far in > policing speech, especially speech unrelated to the project, will drive away > talented people who are more than willing to comply with the project's norms > within the project's spaces. Trying to enforce the 'California cultural > standard' on not only someone's interactions with the project but their > entire life (which may be lived in a very different cultural setting) seems > very invasive and culturally exclusionary. I do live in California, but I don't know what the "California cultural standard" is. It's a big place, and it's full of people who behave in all kinds of different ways. Harvey Weinstein and brogrammer culture are California cultures. You presumably have something in mind, but I'm not sure it's a real thing. > I'd be interested to know where you draw the line as to what behavior is > related to the project, or if you don't draw a line, why volunteers in China, > Russia, Poland etc should be expected to accept an entire political doctrine > over their life to contribute to a compiler toolchain. How did we get to accepting an entire political doctrine? What I have in mind is treating people with respect. For example, I'm involved with the Go programming language. The Go community has a code of conduct: https://golang.org/conduct. The key elements are: - Be friendly and welcoming - Be patient Remember that people have varying communication styles and that not everyone is using their native language. (Meaning and tone can be lost in translation.) - Be thoughtful Productive communication requires effort. Think about how your words will be interpreted. Remember that sometimes it is best to refrain entirely from commenting. - Be respectful In particular, respect differences of opinion. - Be charitable Interpret the arguments of others in good faith, do not seek to disagree. When we do disagree, try to understand why. Avoid destructive behavior: Derailing: stay on topic; if you want to talk about something else, start a new conversation. Unconstructive criticism: don't merely decry the current state of affairs; offer—or at least solicit—suggestions as to how things may be improved. Snarking (pithy, unproductive, sniping comments) Discussing potentially offensive or sensitive issues; this all too often leads to unnecessary conflict. Microaggressions: brief and commonplace verbal, behavioral and environmental indignities that communicate hostile, derogatory or negative slights and insults to a person or group. That is what I would aim for. And in general that is how the GCC community behaves. I don't know whether that is "California culture" or not. And I have to note that I have seen very few people here saying "RMS must never participate in GCC in any way." What I see most people saying is "RMS should not be in a position of leading the GCC project and telling people what to do." Ian
Re: A suggestion for going forward from the RMS/FSF debate
From reading most of this thread, it is clear to me that - The authority of the FSF, GNU and RMS over GCC is and has been a fiction for decades, - This fiction has been erased from the official web page of the project, - It would be usefull to clarify with the FSF and GNU what the actual relations are, - This can certainly be done in a polite way without all sorts of rant, and arguments with no relation with Free Software, in particular attacks ad persona. The power is and has always been in the hands of the people doing the job (the developpers/maintainers). But those who have the power would be wise to pay attention to the opinions of the many afficionados of GCC, GNU and Free Software in general, even those who aren't contributors. These people aren't trolls; they speak up because they are concerned about the project. -- Didier
[Bug c++/99803] [9/10/11 Regression] ICE: in make_typename_type, at cp/decl.c:4057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99803 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug fortran/68289] Missing diagnostic pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68289 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|REOPENED|NEW
[Bug libfortran/95101] Optimize libgfortran library handling of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug fortran/90536] Spurious (?) warning when using -Wconversion with -fno-range-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug fortran/67202] Fortran FE should load scalar pass-by-reference intent-in arguments at the beginning of a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67202 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug fortran/83927] Type-Bound Procedure on element of Derived Type PARAMETER Array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug fortran/97454] Decls for Fortran library procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97454 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug fortran/96216] Gap in interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96216 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug fortran/30609] Calculating masks twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug fortran/93114] Use span passing components of derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93114 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug fortran/97345] FE passes do_subscript leaks gmp memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug fortran/82215] Feature request to better support two pass compiling with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82215 Thomas Koenig changed: What|Removed |Added Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
