Re: removing toxic emailers

[Christopher Dimech via Gcc]

> Sent: Tuesday, April 20, 2021 at 3:47 PM
> From: "Frosku" 
> To: "Thomas Rodgers" , "Jonathan Wakely" 
> 
> Cc: "Jonathan Wakely via Gcc" 
> Subject: Re: removing toxic emailers
>
> On Mon Apr 19, 2021 at 4:06 PM BST, Thomas Rodgers wrote:
> > Google doesn't pay anybody to work on GCC all day. You know nothing
> > about
> > GCC or the "problems" you're complaining about. Your input to this
> > conversation is not constructive.
>
> This feels like that moment in 8Mile, "pay attention, you're saying the
> same shit that he said." The personal insults and technical semantic
> arguments are testament to the fact that you're not willing or not able
> to argue the points. It's quite incredible that two people have replied
> to the same multiple-hundred word e-mail about a broad issue of trying
> to gatekeep discussion and both have focused on semantics ("it's not
> *all* day"). I will remember not to use hyperbole in future for fear of
> it being taken literally and used as an excuse to dodge the point.
>
> > > Once upon a time, free software developers understood that users'
> > > opinions
> > > were as valid as contributor's opinions.
> >
> > That depends on the user.
> >
> > Once upon a time, free software's developers *were* it's primary users,
> > i.e. they built the technology for themselves and made it freely
> > available in the hope that it would be useful to others. It's also the
> > case that the vast majority of GCC *current* users are not here making
> > proclamations about what GCC's project governance should be. Rather it's
> > a vocal and vanishingly small minority, who have contributed nothing of
> > value, code or insights, and continue to vocally do so. Many of GCC's
> > users are, however, watching in horror at the absolutely amateurish way
> > in which this is playing out and wondering if their long term commitment
> > should be to using this piece of software to build their
> > products/businesses.
>
> It's obvious that the majority of current users aren't here, the majority of
> current users don't use the mailing lists. What have you done to try to
> consult their opinions on the matter? It's amazing how much effort is being
> expended to silence opposition, whilst not even one argument has been made
> as to how breaking from FSF/GNU will result in a better technical outcome.

Is that right!!!  Users want to build their products and businesses?
Sounds very corporate to me, with wording that suggests the provision
of resources working on other projects for personal profit.  The users
watching in horror are most likely developers who see Richard Stallman
as an obstacle.

GCC can never break from Gnu.  They can only break from gnu, clone gcc and call
it something else such as gcc-fuckup, gcc-screw and the like.  Then, if they
manage to fuckup the licensing or the compatibility with Gcc, we shall wait for
a new generation of forward thinking hackers to join us.  The success of Gcc was
achieved to large extent due to the personal efforts of Rms.

These people never learned from the Cygnus EGCS Saga, because they cannot get
beyond the short-sighted viewpoint of "always disobey every authority".
The U.S.S. Cygnus was a "Death Ship".  Reinhardt had planned to fly her
through the black hole but suffered sever damage and was torn apart.

> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<
>

[Bug c++/100109] [8/9/10/11 Regression] ICE: unexpected expression 'E' of kind template_parm_index

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

[Bug c++/91706] [8/9/10/11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91706

--- Comment #7 from Jason Merrill  ---
Created attachment 50632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50632=edit
near fix

This seemed like a fix, but it breaks the modules/merge-8 testcase, and
debugging that is being slow.

[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Patrick Palka  ---
P2259R1 (wg21.link/p2259r1) fixes this issue and similar ones.

Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568272.html

Re: removing toxic emailers

[Frosku]

On Mon Apr 19, 2021 at 4:06 PM BST, Thomas Rodgers wrote:
> Google doesn't pay anybody to work on GCC all day. You know nothing
> about
> GCC or the "problems" you're complaining about. Your input to this
> conversation is not constructive.

This feels like that moment in 8Mile, "pay attention, you're saying the
same shit that he said." The personal insults and technical semantic
arguments are testament to the fact that you're not willing or not able
to argue the points. It's quite incredible that two people have replied
to the same multiple-hundred word e-mail about a broad issue of trying
to gatekeep discussion and both have focused on semantics ("it's not
*all* day"). I will remember not to use hyperbole in future for fear of
it being taken literally and used as an excuse to dodge the point.

> > Once upon a time, free software developers understood that users'
> > opinions
> > were as valid as contributor's opinions.
>
> That depends on the user.
>
> Once upon a time, free software's developers *were* it's primary users,
> i.e. they built the technology for themselves and made it freely
> available in the hope that it would be useful to others. It's also the
> case that the vast majority of GCC *current* users are not here making
> proclamations about what GCC's project governance should be. Rather it's
> a vocal and vanishingly small minority, who have contributed nothing of
> value, code or insights, and continue to vocally do so. Many of GCC's
> users are, however, watching in horror at the absolutely amateurish way
> in which this is playing out and wondering if their long term commitment
> should be to using this piece of software to build their
> products/businesses.

It's obvious that the majority of current users aren't here, the majority of
current users don't use the mailing lists. What have you done to try to
consult their opinions on the matter? It's amazing how much effort is being
expended to silence opposition, whilst not even one argument has been made
as to how breaking from FSF/GNU will result in a better technical outcome.

>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<

[PATCH] libstdc++: Implement P2259R1 changes [PR95983]

[Patrick Palka via Gcc-patches]

This implements the wording changes of P2259R1 "Repairing input range
adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408.

The wording changes are relatively straightforward, but they require
some boilerplate to implement: the changes to make a type alias
"conditionally present" in some iterator class are realized by defining
a base class template and an appropriately constrained partial
specialization thereof that contains the type alias, and having the
iterator class derive from this base class.  Sometimes the relevant
condition depend on members from the iterator class, but because a
class is incomplete when instantiating its bases, the constraints on
the partial specialization can't use anything from the iterator class.
This patch works around this by hoisting these members out to the
enclosing scope (e.g. transform_view::_Iterator::_Base is hoisted out
to transform_view::_Base so that transform_view::__iter_cat can use it).

This patch also implements the proposed resolution of LWG 3291 to rename
iota_view::iterator_category to iota_view::iterator_concept, which was
previously problematic due to LWG 3408.

Tested on x86_64-pc-linux-gnu.

libstdc++-v3/ChangeLog:

PR libstdc++/95983
* include/bits/stl_iterator.h (__detail::__move_iter_cat):
Define.
(move_iterator): Derive from the above in C++20 in order to
conditionally define iterator_category as per P2259.
(move_iterator::__base_cat): No longer used, so remove.
(move_iterator::iterator_category): Remove in C++20.
(__detail::__common_iter_use_postfix_proxy): Define.
(common_iterator::_Proxy): Rename to ...
(common_iterator:__arrow_proxy): ... this.
(common_iterator::__postfix_proxy): Define as per P2259.
(common_iterator::operator->): Adjust.
(common_iterator::operator++): Adjust as per P2259.
(iterator_traits::_S_iter_cat): Define.
(iterator_traits::iterator_category): Change as
per P2259.
(__detail::__counted_iter_value_type): Define.
(__detail::__counted_iter_concept): Define.
(__detail::__counted_iter_cat): Define.
(counted_iterator): Derive from the above three classes in order
to conditionally define value_type, iterator_concept and
iterator category respectively as per P2259.
(counted_iterator::operator->): Define as per P2259.
(incrementable_traits): Remove as per P2259.
(iterator_traits): Adjust as per P2259.
* include/std/ranges (__detail::__iota_view_iter_cat): Define.
(iota_view::_Iterator): Derive from the above in order to
conditionally define iterator_category as per P2259.
(iota_view::_S_iter_cat): Rename to ...
(iota_view::_S_iter_concept): ... this.
(iota_view::iterator_concept): Use it to apply LWG 3291 changes.
(iota_view::iterator_category): Remove.
(__detail::__filter_view_iter_cat): Define.
(filter_view::_Iterator): Derive from the above in order to
conditionally define iterator_category as per P2259.
(filter_view::_Iterator): Move to struct __filter_view_iter_cat.
(filter_view::_Iterator::iterator_category): Remove.
(transform_view::_Base): Define.
(transform_view::__iter_cat): Define.
(transform_view::_Iterator): Derive from the above in order to
conditionally define iterator_category as per P2259.
(transform_view::_Iterator::_Base): Just alias
transform_view::_Base.
(transform_view::_Iterator::_S_iter_cat): Move to struct
transform_view::__iter_cat.
(transform_view::_Iterator::iterator_category): Remove.
(transform_view::_Sentinel::_Base): Just alias
transform_view::_Base.
(join_view::_Base): Define.
(join_view::_Outer_iter): Define.
(join_view::_Inner_iter): Define.
(join_view::_S_ref_is_glvalue): Define.
(join_view::__iter_cat): Define.
(join_view::_Iterator): Derive from it in order to conditionally
define iterator_category as per P2259.
(join_view::_Iterator::_Base): Just alias join_view::_Base.
(join_view::_Iterator::_S_ref_is_glvalue): Just alias
join_view::_S_ref_is_glvalue.
(join_view::_Iterator::_S_iter_cat): Move to struct
transform_view::__iter_cat.
(join_view::_Iterator::_Outer_iter): Just alias
join_view::_Outer_iter.
(join_view::_Iterator::_Inner_iter): Just alias
join_view::_Inner_iter.
(join_view::_Iterator::iterator_category): Remove.
(join_view::_Sentinel::_Base): Just alias join_view::_Base.
(__detail::__split_view_outer_iter_cat): Define.
(__detail::__split_view_inner_iter_cat): Define.
(split_view::_Base): Define.
(split_view::_Outer_iter): Derive from __split_view_outer_iter_cat
in order to conditionally define 

[Bug c/51971] unclear/unverified restrictions on attribute((const|pure))

[davidfromonline at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971

--- Comment #5 from David Stone  ---
After compiling this code

```
struct s {
s();
};

s::s() {}

s g() {
return s();
}
```

with `-O3 -Wsuggest-attribute=pure -Wsuggest-attribute=const`

I get the output

```
: In function 's g()':
:7:3: warning: function might be candidate for attribute 'const'
[-Wsuggest-attribute=const]
7 | s g() {
  |   ^
Compiler returned: 0
```

[Bug fortran/100149] Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL

[kargl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Update 11 when it is available.  I get

% gfcx -o z -O a.f90
% ./z
 Zone_t  
 Zone_t
 Zone_t

[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[rin at NetBSD dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

--- Comment #7 from Rin Okuyama  ---
Thank you for discussion. The proposed patch works fine for me (except for
missing ``;'' at the end of the line).

[Bug d/98584] Many D tests FAIL with SIGBUS in read_encoded_value_with_base

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98584

--- Comment #2 from Iain Buclaw  ---
Running all D torture tests on sparc-sun-solaris2.11 with the RUNTESTFLAGS
--target_board=unix\{,-m64\}", I don't see any failures that arise in any f the
supported tests now.
---
=== gdc Summary for unix ===

# of expected passes1520
# of unsupported tests  300

=== gdc Summary for unix/-m64 ===

# of expected passes1520
# of unsupported tests  300

=== gdc Summary ===

# of expected passes3040
# of unsupported tests  600
---

A variant of this patch can be backported to the gcc-10 branch as well if it is
useful.

[committed] libphobos: Fix SIGBUS in read_encoded_value_with_base on sparc-sun-solaris (PR98584)

[Iain Buclaw via Gcc-patches]

Hi,

This patch adjusts the `read_encoded_value_with_base' function in
libphobos to correctly handle unaligned loads.  Instead of unsafe
pointer dereferencing, use memcpy() to read encoded values from memory.
The function `read_encoded_value' has been updated to accept a ref
parameter, this simplifies handling of the pointer to memory needing to
be read.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, with
further testing done on sparc-sun-solaris2.11 to verify the target
platform the PR was raised against has been fixed.

Committed to mainline.

Regards,
Iain.

---
libphobos/ChangeLog:

PR d/98584
* libdruntime/gcc/deh.d (scanLSDA): Update calls to read_uleb128 and
read_encoded_value.
(actionTableLookup): Update calls to read_sleb128 and
read_encoded_value_with_base.
* libdruntime/gcc/unwind/pe.d (read_uleb128): Update signature.
(read_sleb128): Update signature.
(read_unaligned): New function.
(read_encoded_value_with_base): Update signature.  Call read_unaligned
instead of unsafe pointer dereferencing.
(read_encoded_value): Update signature.
---
 libphobos/libdruntime/gcc/deh.d   | 24 
 libphobos/libdruntime/gcc/unwind/pe.d | 81 +++
 2 files changed, 57 insertions(+), 48 deletions(-)

diff --git a/libphobos/libdruntime/gcc/deh.d b/libphobos/libdruntime/gcc/deh.d
index 712f5d7bc9d..eb83751c59d 100644
--- a/libphobos/libdruntime/gcc/deh.d
+++ b/libphobos/libdruntime/gcc/deh.d
@@ -547,7 +547,7 @@ _Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, 
_Unwind_Exception_Class excepti
 _Unwind_Ptr LPStart = 0;
 
 if (LPStartEncoding != DW_EH_PE_omit)
-LPStart = read_encoded_value(context, LPStartEncoding, );
+LPStart = read_encoded_value(context, LPStartEncoding, p);
 else
 LPStart = Start;
 
@@ -563,14 +563,14 @@ _Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, 
_Unwind_Exception_Class excepti
 // hardcoded OS-specific format.
 TTypeEncoding = _TTYPE_ENCODING;
 }
-auto TTbase = read_uleb128();
+auto TTbase = read_uleb128(p);
 TType = p + TTbase;
 }
 
 // The encoding and length of the call-site table; the action table
 // immediately follows.
 ubyte CSEncoding = *p++;
-auto CSTableSize = read_uleb128();
+auto CSTableSize = read_uleb128(p);
 const(ubyte)* actionTable = p + CSTableSize;
 
 auto TTypeBase = base_of_encoded_value(TTypeEncoding, context);
@@ -608,8 +608,8 @@ _Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, 
_Unwind_Exception_Class excepti
 _uleb128_t CSLandingPad, CSAction;
 do
 {
-CSLandingPad = read_uleb128();
-CSAction = read_uleb128();
+CSLandingPad = read_uleb128(p);
+CSAction = read_uleb128(p);
 }
 while (--ip);
 
@@ -626,10 +626,10 @@ _Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, 
_Unwind_Exception_Class excepti
 while (p < actionTable)
 {
 // Note that all call-site encodings are "absolute" displacements.
-auto CSStart = read_encoded_value(null, CSEncoding, );
-auto CSLen = read_encoded_value(null, CSEncoding, );
-auto CSLandingPad = read_encoded_value(null, CSEncoding, );
-auto CSAction = read_uleb128();
+auto CSStart = read_encoded_value(null, CSEncoding, p);
+auto CSLen = read_encoded_value(null, CSEncoding, p);
+auto CSLandingPad = read_encoded_value(null, CSEncoding, p);
+auto CSAction = read_uleb128(p);
 
 // The table is sorted, so if we've passed the ip, stop.
 if (ip < Start + CSStart)
@@ -703,9 +703,9 @@ int actionTableLookup(_Unwind_Action actions, 
_Unwind_Exception* unwindHeader,
 while (1)
 {
 auto ap = actionRecord;
-auto ARFilter = read_sleb128();
+auto ARFilter = read_sleb128(ap);
 auto apn = ap;
-auto ARDisp = read_sleb128();
+auto ARDisp = read_sleb128(ap);
 
 if (ARFilter == 0)
 {
@@ -725,7 +725,7 @@ int actionTableLookup(_Unwind_Action actions, 
_Unwind_Exception* unwindHeader,
 // the ClassInfo is stored.
 const(ubyte)* tp = TType - ARFilter * encodedSize;
 
-auto entry = read_encoded_value_with_base(TTypeEncoding, 
TTypeBase, );
+auto entry = read_encoded_value_with_base(TTypeEncoding, 
TTypeBase, tp);
 ClassInfo ci = cast(ClassInfo)cast(void*)(entry);
 
 // D does not have catch-all handlers, and so the following
diff --git a/libphobos/libdruntime/gcc/unwind/pe.d 
b/libphobos/libdruntime/gcc/unwind/pe.d
index 361ec12490f..b9b05cbc8f6 100644
--- a/libphobos/libdruntime/gcc/unwind/pe.d
+++ b/libphobos/libdruntime/gcc/unwind/pe.d
@@ -103,40 +103,37 @@ _Unwind_Ptr base_of_encoded_value(ubyte 

[Bug d/98584] Many D tests FAIL with SIGBUS in read_encoded_value_with_base

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98584

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:30b11d8d1be9c683f1517472c47a3cb69df02c4f

commit r11-8254-g30b11d8d1be9c683f1517472c47a3cb69df02c4f
Author: Iain Buclaw 
Date:   Tue Apr 20 02:09:51 2021 +0200

libphobos: Fix SIGBUS in read_encoded_value_with_base on sparc-sun-solaris
(PR98584)

Instead of unsafe pointer dereferencing, use memcpy() to read encoded
values from memory.  The function `read_encoded_value' has been updated
to accept a ref parameter, this simplifies handling of the pointer to
memory needing to be read.

libphobos/ChangeLog:

PR d/98584
* libdruntime/gcc/deh.d (scanLSDA): Update calls to read_uleb128
and
read_encoded_value.
(actionTableLookup): Update calls to read_sleb128 and
read_encoded_value_with_base.
* libdruntime/gcc/unwind/pe.d (read_uleb128): Update signature.
(read_sleb128): Update signature.
(read_unaligned): New function.
(read_encoded_value_with_base): Update signature.  Call
read_unaligned
instead of unsafe pointer dereferencing.
(read_encoded_value): Update signature.

Re: move selftests into their own files?

[Koning, Paul via Gcc-patches]

> On Apr 19, 2021, at 7:26 PM, Martin Sebor via Gcc-patches 
>  wrote:
> 
> On 4/19/21 3:13 PM, Koning, Paul wrote:
>>> On Apr 19, 2021, at 4:50 PM, Martin Sebor via Gcc-patches 
>>>  wrote:
>>> 
>>> ...
>>> I was actually thinking of just #including each foo-tests.c file
>>> to bring in the code right where it is now, so this shouldn't be
>>> a problem.  Would that work for you?
>>> 
>>> Martin
>> How does that help the problem you said need to be solved?  If having self 
>> test code be part of the compilation unit makes modifying things more 
>> difficult, it doesn't matter whether that code is in the compilation unit 
>> due to being in the main source file, or due to being a #include.
> 
> The self tests make the sources bigger and so harder to move around
> in and difficult to find just the calls to tested functions made
> from elsewhere in the file or from other parts of the compiler (i.e.,
> not tests).  They are only rarely relevant when reading or changing
> the file.
> 
> Keeping them separate from the code they exercise will be helpful
> to me and I assumed to others as well.  But I wouldn't want to make
> some common tasks difficult, so if you or someone else has one that
> would be made so by it, I won't pursue it.  Do you?

No, I don't have objections.  For one thing, I don't work on files that have 
selftest in them at the moment.  I was just trying to understand better why 
using #include would help.  I understand your point; I'm not sure I'd feel the 
same way but I don't see any reason to object to your proposed approach.

paul

Re: move selftests into their own files?

[Martin Sebor via Gcc-patches]

On 4/19/21 3:13 PM, Koning, Paul wrote:




On Apr 19, 2021, at 4:50 PM, Martin Sebor via Gcc-patches 
 wrote:

On 4/19/21 2:03 PM, David Malcolm wrote:

On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote:

The selftests at the end of many source files are only rarely read
or modified, but they contribute to the size/complexity of the files
and make moving within the rest of the code more difficult.


FWIW I prefer having the tests in the same file as the code they test.

Would anyone be opposed to moving any of them into new files of their
own? E.g., those in tree.c to tree-tests.c, etc.?  I would be happy
to do this for a subset of these, with the goal of eventually moving
all of them and adding new ones accordingly.

Having the selftests in the same source file as the thing they test
allows for the selftest to use "static" declarations and anonymous
namespaces from that file.  For example, the selftests in diagnostic-
show-locus.c make use of various things declared in an anonymous
namespace in that file.  If I had to move the selftests to a different
file, I'd have to expose these interfaces, which I don't want to do.


I was actually thinking of just #including each foo-tests.c file
to bring in the code right where it is now, so this shouldn't be
a problem.  Would that work for you?

Martin


How does that help the problem you said need to be solved?  If having self test 
code be part of the compilation unit makes modifying things more difficult, it 
doesn't matter whether that code is in the compilation unit due to being in the 
main source file, or due to being a #include.


The self tests make the sources bigger and so harder to move around
in and difficult to find just the calls to tested functions made
from elsewhere in the file or from other parts of the compiler (i.e.,
not tests).  They are only rarely relevant when reading or changing
the file.

Keeping them separate from the code they exercise will be helpful
to me and I assumed to others as well.  But I wouldn't want to make
some common tasks difficult, so if you or someone else has one that
would be made so by it, I won't pursue it.  Do you?

Martin

[Bug fortran/100149] New: Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL

[brtnfld at hdfgroup dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100149

Bug ID: 100149
   Summary: Seg fault passing to CHARACTER(*), DIMENSION(*),
INTENT(IN), OPTIONAL
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brtnfld at hdfgroup dot org
  Target Milestone: ---

Created attachment 50631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50631=edit
The program has two lines of doing that same thing,  the lines are marked which
fail.

The attached program fails with:

Program received signal SIGSEGV, Segmentation fault.
0x143c783f in __memmove_sse2_unaligned_erms () from /lib64/libc.so.6

The program worked with 10.1.0 (and 9.3.1, 7.5.0) and fails with 10.2.0

[Bug c++/67491] [meta-bug] concepts issues

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 97536, which changed state.

Bug 97536 Summary: [concepts] parser segfault for concept defined in function 
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/97536] [concepts] parser segfault for concept defined in function template

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Marek Polacek  ---
Fixed in GCC 11.

[Bug c++/97536] [concepts] parser segfault for concept defined in function template

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97536

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:29d8838c5ecaf70ce552fea7639ec1f34adb2e04

commit r11-8252-g29d8838c5ecaf70ce552fea7639ec1f34adb2e04
Author: Marek Polacek 
Date:   Mon Apr 19 16:21:46 2021 -0400

c++: ICE with concept defined in function [PR97536]

This is an ICE-on-invalid, but I keep seeing it when reducing code so
I'd like to fix it.  We crash on

  template  void forward() {
concept C = true;
  }

which breaks two requirements:
[temp.concept]/1: A concept is a template ...
[temp.concept]/3: A concept-definition shall inhabit a namespace scope.

This patch adds a test that exercises broken code and fixes the ICE
by checking that a concept-definition is defined at namespace scope.

gcc/cp/ChangeLog:

PR c++/97536
* decl.c (grokvardecl): Given an error when a concept is not
defined
at namespace scope.

gcc/testsuite/ChangeLog:

PR c++/97536
* g++.dg/concepts/diagnostic16.C: New test.

Re: [PATCH] c++: ICE with concept defined in function [PR97536]

[Jason Merrill via Gcc-patches]

On 4/19/21 5:17 PM, Marek Polacek wrote:

This is an ICE-on-invalid, but I keep seeing it when reducing code so
I'd like to fix it.  We crash on

   template  void forward() {
 concept C = true;
   }

which breaks two requirements:
[temp.concept]/1: A concept is a template ...
[temp.concept]/3: A concept-definition shall inhabit a namespace scope.

This patch adds a test that exercises broken code and fixes the ICE
by checking that a concept-definition is defined at namespace scope.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


gcc/cp/ChangeLog:

PR c++/97536
* decl.c (grokvardecl): Given an error when a concept is not defined
at namespace scope.

gcc/testsuite/ChangeLog:

PR c++/97536
* g++.dg/concepts/diagnostic16.C: New test.
---
  gcc/cp/decl.c|  6 +++
  gcc/testsuite/g++.dg/concepts/diagnostic16.C | 45 
  2 files changed, 51 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic16.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 942eb318f2c..b81de8ef934 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10365,6 +10365,12 @@ grokvardecl (tree type,
"a non-template variable cannot be %");
return NULL_TREE;
  }
+  else if (!at_namespace_scope_p ())
+   {
+ error_at (declspecs->locations[ds_concept],
+   "concept must be defined at namespace scope");
+ return NULL_TREE;
+   }
else
  DECL_DECLARED_CONCEPT_P (decl) = true;
if (!same_type_ignoring_top_level_qualifiers_p (type, 
boolean_type_node))
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic16.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
new file mode 100644
index 000..fcba535a876
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
@@ -0,0 +1,45 @@
+// PR c++/97536
+// { dg-do compile { target concepts } }
+
+template
+concept C1 = true;
+
+concept C2 = true; // { dg-error "non-template variable cannot be .concept." }
+// { dg-error "concept definition syntax is" "" { target *-*-* } .-1 }
+
+template
+void fn1 ()
+{
+  concept bar = true; // { dg-error "concept must be defined at namespace 
scope" }
+// { dg-error "concept definition syntax is" "" { target *-*-* } .-1 }
+}
+
+void fn2 ()
+{
+  concept bar = true; // { dg-error "non-template variable cannot be 
.concept." }
+// { dg-error "concept definition syntax is" "" { target *-*-* } .-1 }
+}
+
+template
+void fn3 ()
+{
+  template // { dg-error "template declaration cannot appear at block 
scope" }
+  concept bar = true;
+}
+
+void fn4 ()
+{
+  template // { dg-error "template declaration cannot appear at block 
scope" }
+  concept bar = true;
+}
+
+void fn5 ()
+{
+  C1 auto x = 42;
+}
+
+template
+void fn6 ()
+{
+  C1 auto x = 42;
+}

base-commit: 329d2f0df7d6d22c87ab3338b94caef68139cd58

Re: [PATCH] c++: Fix pretty printing of function pointer type [PR98767]

[Jason Merrill via Gcc-patches]

On 4/16/21 6:58 PM, Patrick Palka wrote:

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?


OK.


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" }
+// { 

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org
 Target|i386-pc-solaris2.11,|i386-pc-solaris2.11,
   |x86_64-pc-solaris2.11,  |x86_64-pc-solaris2.11,
   |arm-none-linux-gnueabi, |arm-none-linux-gnueabi,
   |hppa-unknown-linux-gnu, |hppa-unknown-linux-gnu,
   |x86_64-pc-linux-gnu |x86_64-pc-linux-gnu,
   ||powerpc64-linux-gnu

--- Comment #2 from seurer at gcc dot gnu.org ---
FYI I am seeing this every so often on powerpc64 BE on an older power 7
machine, too.

[PATCH] c++: ICE with concept defined in function [PR97536]

[Marek Polacek via Gcc-patches]

This is an ICE-on-invalid, but I keep seeing it when reducing code so
I'd like to fix it.  We crash on

  template  void forward() {
concept C = true;
  }

which breaks two requirements:
[temp.concept]/1: A concept is a template ...
[temp.concept]/3: A concept-definition shall inhabit a namespace scope.

This patch adds a test that exercises broken code and fixes the ICE
by checking that a concept-definition is defined at namespace scope.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

gcc/cp/ChangeLog:

PR c++/97536
* decl.c (grokvardecl): Given an error when a concept is not defined
at namespace scope.

gcc/testsuite/ChangeLog:

PR c++/97536
* g++.dg/concepts/diagnostic16.C: New test.
---
 gcc/cp/decl.c|  6 +++
 gcc/testsuite/g++.dg/concepts/diagnostic16.C | 45 
 2 files changed, 51 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic16.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 942eb318f2c..b81de8ef934 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10365,6 +10365,12 @@ grokvardecl (tree type,
"a non-template variable cannot be %");
   return NULL_TREE;
 }
+  else if (!at_namespace_scope_p ())
+   {
+ error_at (declspecs->locations[ds_concept],
+   "concept must be defined at namespace scope");
+ return NULL_TREE;
+   }
   else
 DECL_DECLARED_CONCEPT_P (decl) = true;
   if (!same_type_ignoring_top_level_qualifiers_p (type, boolean_type_node))
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic16.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
new file mode 100644
index 000..fcba535a876
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic16.C
@@ -0,0 +1,45 @@
+// PR c++/97536
+// { dg-do compile { target concepts } }
+
+template
+concept C1 = true;
+
+concept C2 = true; // { dg-error "non-template variable cannot be .concept." }
+// { dg-error "concept definition syntax is" "" { target *-*-* } .-1 }
+
+template
+void fn1 ()
+{
+  concept bar = true; // { dg-error "concept must be defined at namespace 
scope" }
+// { dg-error "concept definition syntax is" "" { target *-*-* } .-1 }
+}
+
+void fn2 ()
+{
+  concept bar = true; // { dg-error "non-template variable cannot be 
.concept." }
+// { dg-error "concept definition syntax is" "" { target *-*-* } .-1 }
+}
+
+template
+void fn3 ()
+{
+  template // { dg-error "template declaration cannot appear at 
block scope" }
+  concept bar = true;
+}
+
+void fn4 ()
+{
+  template // { dg-error "template declaration cannot appear at 
block scope" }
+  concept bar = true;
+}
+
+void fn5 ()
+{
+  C1 auto x = 42;
+}
+
+template
+void fn6 ()
+{
+  C1 auto x = 42;
+}

base-commit: 329d2f0df7d6d22c87ab3338b94caef68139cd58
-- 
2.30.2

Re: move selftests into their own files?

[Koning, Paul via Gcc-patches]

> On Apr 19, 2021, at 4:50 PM, Martin Sebor via Gcc-patches 
>  wrote:
> 
> On 4/19/21 2:03 PM, David Malcolm wrote:
>> On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote:
>>> The selftests at the end of many source files are only rarely read
>>> or modified, but they contribute to the size/complexity of the files
>>> and make moving within the rest of the code more difficult.
>>> 
>> FWIW I prefer having the tests in the same file as the code they test.
>>> Would anyone be opposed to moving any of them into new files of their
>>> own? E.g., those in tree.c to tree-tests.c, etc.?  I would be happy
>>> to do this for a subset of these, with the goal of eventually moving
>>> all of them and adding new ones accordingly.
>> Having the selftests in the same source file as the thing they test
>> allows for the selftest to use "static" declarations and anonymous
>> namespaces from that file.  For example, the selftests in diagnostic-
>> show-locus.c make use of various things declared in an anonymous
>> namespace in that file.  If I had to move the selftests to a different
>> file, I'd have to expose these interfaces, which I don't want to do.
> 
> I was actually thinking of just #including each foo-tests.c file
> to bring in the code right where it is now, so this shouldn't be
> a problem.  Would that work for you?
> 
> Martin

How does that help the problem you said need to be solved?  If having self test 
code be part of the compilation unit makes modifying things more difficult, it 
doesn't matter whether that code is in the compilation unit due to being in the 
main source file, or due to being a #include.

paul

Re: move selftests into their own files?

[Martin Sebor via Gcc-patches]

On 4/19/21 2:03 PM, David Malcolm wrote:

On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote:

The selftests at the end of many source files are only rarely read
or modified, but they contribute to the size/complexity of the files
and make moving within the rest of the code more difficult.



FWIW I prefer having the tests in the same file as the code they test.


Would anyone be opposed to moving any of them into new files of their
own? E.g., those in tree.c to tree-tests.c, etc.?  I would be happy
to do this for a subset of these, with the goal of eventually moving
all of them and adding new ones accordingly.


Having the selftests in the same source file as the thing they test
allows for the selftest to use "static" declarations and anonymous
namespaces from that file.  For example, the selftests in diagnostic-
show-locus.c make use of various things declared in an anonymous
namespace in that file.  If I had to move the selftests to a different
file, I'd have to expose these interfaces, which I don't want to do.


I was actually thinking of just #including each foo-tests.c file
to bring in the code right where it is now, so this shouldn't be
a problem.  Would that work for you?

Martin

[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Iain Buclaw  ---
ICE has been fixed.  The library related errors are more to do with the version
of the D compiler in tree, rather than an issue with gdc itself.

Re: [committed] d: Fix ICE in when formating a string with '%' or '`' characters (PR98457)

[ibuclaw--- via Gcc-patches]

> On 19/04/2021 19:50 Iain Buclaw  wrote:
> 
>  
> Hi,
> 
> This patch fixes an ICE that occurred in the D front-end diagnostic
> handlers.  The percentage character was being confused for a format
> specifier in pp_format(), whilst the backtick character was confused for
> the beginning of a quoted string in expand_d_format().
> 
> Both are now properly escaped to avoid the ICE.
> 
> Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
> committed to mainline.
> 
> Will also be preparing a backport to the gcc-10 and gcc-9 release
> branches, as the bug is reproducible there as well.

Attached backport, regression tested and applied to both releases/gcc-9
and releases/gcc-10 branches.

Regards,
Iain.

---
gcc/d/ChangeLog:

PR d/98457
* d-diagnostic.cc (expand_d_format): Handle escaped backticks.
(escape_d_format): New funtion.
(verror): Call escape_d_format on prefixing strings.
(vdeprecation): Likewise.

gcc/testsuite/ChangeLog:

PR d/98457
* gdc.dg/pr98457.d: New test.

(cherry picked from commit dc7d1c74ffb1cc85e67984632f581d526c783770)
---
 gcc/d/d-diagnostic.cc  | 64 +++---
 gcc/testsuite/gdc.dg/pr98457.d |  9 +
 2 files changed, 68 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr98457.d

diff --git a/gcc/d/d-diagnostic.cc b/gcc/d/d-diagnostic.cc
index 95a008d1b6f..47c7323aa0b 100644
--- a/gcc/d/d-diagnostic.cc
+++ b/gcc/d/d-diagnostic.cc
@@ -48,7 +48,7 @@ expand_d_format (const char *format)
 
   for (const char *p = format; *p;)
 {
-  while (*p != '\0' && *p != '%' && *p != '`')
+  while (*p != '\0' && *p != '\\' && *p != '%' && *p != '`')
{
  buf.writeByte (*p);
  p++;
@@ -57,6 +57,21 @@ expand_d_format (const char *format)
   if (*p == '\0')
break;
 
+  if (*p == '\\')
+   {
+ if (p[1] == '`')
+   {
+ /* Escaped backtick, don't expand it as a quoted string.  */
+ buf.writeByte ('`');
+ p++;;
+   }
+ else
+   buf.writeByte (*p);
+
+ p++;
+ continue;
+   }
+
   if (*p == '`')
{
  /* Text enclosed by `...` are translated as a quoted string.  */
@@ -113,6 +128,43 @@ expand_d_format (const char *format)
   return buf.extractString ();
 }
 
+/* Rewrite the format string FORMAT to deal with any characters that require
+   escaping before expand_d_format expands it.  */
+
+static char *
+escape_d_format (const char *format)
+{
+  obstack buf;
+
+  gcc_obstack_init ();
+
+  for (const char *p = format; *p; p++)
+{
+  switch (*p)
+   {
+   case '%':
+ /* Escape `%' characters so that pp_format does not confuse them
+for actual format specifiers.  */
+ obstack_1grow (, '%');
+ break;
+
+   case '`':
+ /* Escape '`' characters so that expand_d_format does not confuse them
+for a quoted string.  */
+ obstack_1grow (, '\\');
+ break;
+
+   default:
+ break;
+   }
+
+  obstack_1grow (, *p);
+}
+
+  obstack_1grow (, '\0');
+  return (char *) obstack_finish ();
+}
+
 /* Helper routine for all error routines.  Reports a diagnostic specified by
KIND at the explicit location LOC.  The message FORMAT comes from the dmd
front-end, which does not get translated by the gcc diagnostic routines.  */
@@ -177,9 +229,10 @@ verror (const Loc& loc, const char *format, va_list ap,
 
   /* Build string and emit.  */
   if (prefix2 != NULL)
-   xformat = xasprintf ("%s %s %s", prefix1, prefix2, format);
+   xformat = xasprintf ("%s %s %s", escape_d_format (prefix1),
+escape_d_format (prefix2), format);
   else if (prefix1 != NULL)
-   xformat = xasprintf ("%s %s", prefix1, format);
+   xformat = xasprintf ("%s %s", escape_d_format (prefix1), format);
   else
xformat = xasprintf ("%s", format);
 
@@ -287,9 +340,10 @@ vdeprecation (const Loc& loc, const char *format, va_list 
ap,
 
   /* Build string and emit.  */
   if (prefix2 != NULL)
-   xformat = xasprintf ("%s %s %s", prefix1, prefix2, format);
+   xformat = xasprintf ("%s %s %s", escape_d_format (prefix1),
+escape_d_format (prefix2), format);
   else if (prefix1 != NULL)
-   xformat = xasprintf ("%s %s", prefix1, format);
+   xformat = xasprintf ("%s %s", escape_d_format (prefix1), format);
   else
xformat = xasprintf ("%s", format);
 
diff --git a/gcc/testsuite/gdc.dg/pr98457.d b/gcc/testsuite/gdc.dg/pr98457.d
new file mode 100644
index 000..bc0d8af5d4a
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr98457.d
@@ -0,0 +1,9 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457
+// { dg-do compile }
+
+void main()
+{
+writef!"%s";// { dg-error "template instance writef!\"%s\" template 
.writef. is not 

[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:fda5b17a89e5066e19371ea138253bbb9cad262a

commit r9-9364-gfda5b17a89e5066e19371ea138253bbb9cad262a
Author: Iain Buclaw 
Date:   Mon Apr 19 18:45:32 2021 +0200

d: Fix ICE in when formating a string with '%' or '`' characters (PR98457)

The percentage character was being confused for a format specifier in
pp_format(), whilst the backtick character was confused for the
beginning of a quoted string in expand_d_format().

Both are now properly escaped to avoid the ICE.

gcc/d/ChangeLog:

PR d/98457
* d-diagnostic.cc (expand_d_format): Handle escaped backticks.
(escape_d_format): New funtion.
(verror): Call escape_d_format on prefixing strings.
(vdeprecation): Likewise.

gcc/testsuite/ChangeLog:

PR d/98457
* gdc.dg/pr98457.d: New test.

(cherry picked from commit dc7d1c74ffb1cc85e67984632f581d526c783770)

[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:19fc127321c7fe3962bd8b6c0064b224ab14aec7

commit r10-9718-g19fc127321c7fe3962bd8b6c0064b224ab14aec7
Author: Iain Buclaw 
Date:   Mon Apr 19 18:45:32 2021 +0200

d: Fix ICE in when formating a string with '%' or '`' characters (PR98457)

The percentage character was being confused for a format specifier in
pp_format(), whilst the backtick character was confused for the
beginning of a quoted string in expand_d_format().

Both are now properly escaped to avoid the ICE.

gcc/d/ChangeLog:

PR d/98457
* d-diagnostic.cc (expand_d_format): Handle escaped backticks.
(escape_d_format): New funtion.
(verror): Call escape_d_format on prefixing strings.
(vdeprecation): Likewise.

gcc/testsuite/ChangeLog:

PR d/98457
* gdc.dg/pr98457.d: New test.

(cherry picked from commit dc7d1c74ffb1cc85e67984632f581d526c783770)

Re: [PATCH] wwwdocs: Do not rewrite the page titles

[Jonathan Wakely via Gcc-patches]

On 19/04/21 20:55 +0100, Jonathan Wakely wrote:

On 19/04/21 12:33 -0400, Richard Kenner wrote:

I don't see why we should have to "comply with the GNU style" if we're
truly an independent project run by the GCC developers and aided by
the steering committee.


I think it critical than any code have *some* style guidelines.  If you
don't like the GNU coding convention, which do you propose instead and
how do you propose to convert the existing code to that style?


I'm not suggesting any changes to coding conventions. As you say, some
style is needed, and the current one is fine and it would be pointless
churn to change it.

The patch is for the website stylesheet, and simply removes the rule
that rewrites the HTML  element to "comply with the GNU style".
If that rule is removed then the page titles will be simply the
original content of the  element as it appears in the HTML
source, without rewriting e.g.
https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=blob;f=htdocs/index.html;h=5598df7851048f510b4a70744a1d4c9861157c19;hb=HEAD#l7


The relevant style guideline is the last bullet at:
https://www.gnu.org/server/standards/gnu-website-guidelines.en.html#html-required

But it's only a "should", and I note that these other GNU projects do
not do it:

https://www.gnu.org/software/gdb/
https://www.gnu.org/software/libc/
https://www.gnu.org/software/guile/
https://www.gnu.org/software/emacs/
https://www.gnu.org/software/guix/

Of the ones I checked, only GCC and Binutils do it.

Since GCC isn't on GNU or FSF hardware and isn't supported financially
by the FSF, and operates independently since the EGCS merger, I don't
see why GCC needs to rewrite the page titles.

Re: move selftests into their own files?

[David Malcolm via Gcc-patches]

On Mon, 2021-04-19 at 13:47 -0600, Martin Sebor via Gcc-patches wrote:
> The selftests at the end of many source files are only rarely read
> or modified, but they contribute to the size/complexity of the files
> and make moving within the rest of the code more difficult.
> 

FWIW I prefer having the tests in the same file as the code they test.

> Would anyone be opposed to moving any of them into new files of their
> own? E.g., those in tree.c to tree-tests.c, etc.?  I would be happy
> to do this for a subset of these, with the goal of eventually moving
> all of them and adding new ones accordingly.

Having the selftests in the same source file as the thing they test
allows for the selftest to use "static" declarations and anonymous
namespaces from that file.  For example, the selftests in diagnostic-
show-locus.c make use of various things declared in an anonymous
namespace in that file.  If I had to move the selftests to a different
file, I'd have to expose these interfaces, which I don't want to do.

Hope this is constructive
Dave

Re: [PATCH] wwwdocs: Do not rewrite the page titles

[Jonathan Wakely via Gcc-patches]

On 19/04/21 12:33 -0400, Richard Kenner wrote:

I don't see why we should have to "comply with the GNU style" if we're
truly an independent project run by the GCC developers and aided by
the steering committee.


I think it critical than any code have *some* style guidelines.  If you
don't like the GNU coding convention, which do you propose instead and
how do you propose to convert the existing code to that style?


I'm not suggesting any changes to coding conventions. As you say, some
style is needed, and the current one is fine and it would be pointless
churn to change it.

The patch is for the website stylesheet, and simply removes the rule
that rewrites the HTML  element to "comply with the GNU style".
If that rule is removed then the page titles will be simply the
original content of the  element as it appears in the HTML
source, without rewriting e.g.
https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=blob;f=htdocs/index.html;h=5598df7851048f510b4a70744a1d4c9861157c19;hb=HEAD#l7

Ping: [PATCH] Fix logic error in 32-bit trampolines, PR target/98952

[Michael Meissner via Gcc-patches]

Ping the patch for a logic error in setting up 32-bit trampolines.

| Subject: [PATCH] Fix logic error in 32-bit trampolines, PR target/98952
| Message-ID: <20210409210907.ga5...@ibm-toto.the-meissners.org>
| User-Agent: Mutt/1.5.21 (2010-09-15)
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567849.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:329d2f0df7d6d22c87ab3338b94caef68139cd58

commit r11-8251-g329d2f0df7d6d22c87ab3338b94caef68139cd58
Author: Andrew MacLeod 
Date:   Fri Apr 16 17:08:51 2021 -0400

tree-optimization/100081 - Limit depth of logical expression windback.

Limit how many logical expressions GORI will look back through when
evaluating outgoing edge range.

PR tree-optimization/100081
* gimple-range-cache.h (ranger_cache): Inherit from gori_compute
rather than gori_compute_cache.
* gimple-range-gori.cc (is_gimple_logical_p): Move to top of file.
(range_def_chain::m_logical_depth): New member.
(range_def_chain::range_def_chain): Initialize m_logical_depth.
(range_def_chain::get_def_chain): Don't build defchains through
more
than LOGICAL_LIMIT logical expressions.
* params.opt (param_ranger_logical_depth): New.

move selftests into their own files?

[Martin Sebor via Gcc-patches]

The selftests at the end of many source files are only rarely read
or modified, but they contribute to the size/complexity of the files
and make moving within the rest of the code more difficult.

Would anyone be opposed to moving any of them into new files of their
own? E.g., those in tree.c to tree-tests.c, etc.?  I would be happy
to do this for a subset of these, with the goal of eventually moving
all of them and adding new ones accordingly.

Martin

[PATCH] Adjust guality xfails for aarch64*-*-*

[Richard Sandiford via Gcc-patches]

This patch gives clean guality.exp test results for aarch64-linux-gnu
with modern (top-of-tree) gdb.

For people using older gdbs, it will trade one set of noisy results for
another set.  I still think it's better to have the xfails based on
one “clean” and “modern” run rather than have FAILs and XPASSes for
all runs.

It's hard to tell which of these results are aarch64-specific and
which aren't.  If other target maintainers want to do something similar,
and are prepared to assume the same gdb version, then it should become
clearer over time which ones are target-specific and which aren't.

There are no new skips here, so changes in test results will still
show up as XPASSes.

I've not analysed the failures or filed PRs for them.  In some
ways the guality directory itself seems like the best place to
start looking for xfails, if someone's interested in working
in this area.

Tested on aarch64-linux-gnu.  I'd like to install this once the
earlier no-opts/any-opts patch is in, but please let me know
if you think it's a bad idea.

Richard


gcc/testsuite/
* gcc.dg/guality/example.c: Update aarch64*-*-* xfails.
* gcc.dg/guality/guality.c: Likewise.
* gcc.dg/guality/inline-params.c: Likewise.
* gcc.dg/guality/loop-1.c: Likewise.
* gcc.dg/guality/pr36728-1.c: Likewise.
* gcc.dg/guality/pr36728-2.c: Likewise.
* gcc.dg/guality/pr36728-3.c: Likewise.
* gcc.dg/guality/pr41447-1.c: Likewise.
* gcc.dg/guality/pr54200.c:  Likewise.
* gcc.dg/guality/pr54519-1.c: Likewise.
* gcc.dg/guality/pr54519-2.c: Likewise.
* gcc.dg/guality/pr54519-3.c: Likewise.
* gcc.dg/guality/pr54519-4.c: Likewise.
* gcc.dg/guality/pr54519-5.c: Likewise.
* gcc.dg/guality/pr54519-6.c: Likewise.
* gcc.dg/guality/pr54693-2.c: Likewise.
* gcc.dg/guality/pr56154-1.c: Likewise.
* gcc.dg/guality/pr59776.c: Likewise.
* gcc.dg/guality/pr68860-1.c: Likewise.
* gcc.dg/guality/pr68860-2.c: Likewise.
* gcc.dg/guality/pr90074.c: Likewise.
* gcc.dg/guality/pr90716.c: Likewise.
* gcc.dg/guality/sra-1.c: Likewise.
---
 gcc/testsuite/gcc.dg/guality/example.c   |  3 +-
 gcc/testsuite/gcc.dg/guality/guality.c   |  2 +-
 gcc/testsuite/gcc.dg/guality/inline-params.c |  2 +-
 gcc/testsuite/gcc.dg/guality/loop-1.c|  2 +-
 gcc/testsuite/gcc.dg/guality/pr36728-1.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr36728-2.c | 30 ++--
 gcc/testsuite/gcc.dg/guality/pr36728-3.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr41447-1.c |  1 +
 gcc/testsuite/gcc.dg/guality/pr54200.c   |  2 +-
 gcc/testsuite/gcc.dg/guality/pr54519-1.c |  8 +++---
 gcc/testsuite/gcc.dg/guality/pr54519-2.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr54519-3.c |  8 +++---
 gcc/testsuite/gcc.dg/guality/pr54519-4.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr54519-5.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr54519-6.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr54693-2.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr56154-1.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr59776.c   | 12 
 gcc/testsuite/gcc.dg/guality/pr68860-1.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr68860-2.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr90074.c   |  4 +--
 gcc/testsuite/gcc.dg/guality/pr90716.c   |  2 +-
 gcc/testsuite/gcc.dg/guality/sra-1.c |  8 +++---
 23 files changed, 53 insertions(+), 51 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/guality/example.c 
b/gcc/testsuite/gcc.dg/guality/example.c
index 26d25c28590..6f1c017a253 100644
--- a/gcc/testsuite/gcc.dg/guality/example.c
+++ b/gcc/testsuite/gcc.dg/guality/example.c
@@ -1,5 +1,6 @@
-/* { dg-do run { xfail *-*-* } } */
+/* { dg-do run { xfail { ! aarch64*-*-* } } } */
 /* { dg-options "-g" } */
+/* { dg-xfail-run-if "" aarch64*-*-* "*" { "-O[01g]" } } */
 
 #define GUALITY_DONT_FORCE_LIVE_AFTER -1
 
diff --git a/gcc/testsuite/gcc.dg/guality/guality.c 
b/gcc/testsuite/gcc.dg/guality/guality.c
index db015e6a558..a4de5646fc7 100644
--- a/gcc/testsuite/gcc.dg/guality/guality.c
+++ b/gcc/testsuite/gcc.dg/guality/guality.c
@@ -1,4 +1,4 @@
-/* { dg-do run { xfail *-*-* } } */
+/* { dg-do run { xfail { ! aarch64*-*-* } } } */
 /* { dg-options "-g" } */
 /* { dg-require-effective-target alloca } */
 
diff --git a/gcc/testsuite/gcc.dg/guality/inline-params.c 
b/gcc/testsuite/gcc.dg/guality/inline-params.c
index f4c5f15094c..6be240a28d2 100644
--- a/gcc/testsuite/gcc.dg/guality/inline-params.c
+++ b/gcc/testsuite/gcc.dg/guality/inline-params.c
@@ -3,7 +3,7 @@
inlining inlines the functions too early to test the real IPA passes (such
as IPA-CP).  */
 /* { dg-options "-g -fno-early-inlining -fno-ipa-sra" } */
-/* { dg-xfail-run-if "" { "*-*-*" } { "-O2" "-O3" "-Os" } } */
+/* { dg-xfail-run-if "" { ! aarch64*-*-* } { "-O2" "-O3" "-Os" } } */
 
 #define GUALITY_DONT_FORCE_LIVE_AFTER -1
 
diff --git 

[PATCH] Add dg-final option-based target selectors

[Richard Sandiford via Gcc-patches]

This patch adds target selectors of the form:

  { any-opts "opt1" ... "optn" }
  { no-opts "opt1" ... "optn" }

for skipping or xfailing tests based on compiler options.  It only
works for dg-final selectors.

The patch then uses no-opts to exclude -O0 and (sometimes) -Og from
some guality.exp xfails.  AFAICT (based on gcc-testresults) these
tests pass for those options for all targets.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
If so, OK now, or should it wait for GCC 12?

Richard


gcc/
* doc/sourcebuild.texi: Document no-opts and any-opts target
selectors.

gcc/testsuite/
* lib/target-supports-dg.exp (selector_expression): Handle any-opts
and no-opts.
* gcc.dg/guality/pr41353-1.c: Exclude -O0 from xfail.
* gcc.dg/guality/pr59776.c: Likewise.
* gcc.dg/guality/pr54970.c: Likewise -O0 and -Og.
---
 gcc/doc/sourcebuild.texi | 90 +++-
 gcc/testsuite/gcc.dg/guality/pr41353-1.c |  2 +-
 gcc/testsuite/gcc.dg/guality/pr54970.c   | 16 ++---
 gcc/testsuite/gcc.dg/guality/pr59776.c   |  4 +-
 gcc/testsuite/lib/target-supports-dg.exp | 10 ++-
 5 files changed, 107 insertions(+), 15 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index b0001247795..d3200a42e44 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1301,6 +1301,8 @@ A selector is:
 @item one or more target triplets, possibly including wildcard characters;
 use @samp{*-*-*} to match any target
 @item a single effective-target keyword (@pxref{Effective-Target Keywords})
+@item a list of compiler options that should be included or excluded
+(as described in more detail below)
 @item a logical expression
 @end itemize
 
@@ -1313,14 +1315,96 @@ test to fail for targets that match @var{selector2}.
 
 A selector expression appears within curly braces and uses a single
 logical operator: one of @samp{!}, @samp{&&}, or @samp{||}.  An
-operand is another selector expression, an effective-target keyword,
-a single target triplet, or a list of target triplets within quotes or
-curly braces.  For example:
+operand is one of the following:
+
+@itemize @bullet
+@item
+another selector expression, in curly braces
+
+@item
+an effective-target keyword, such as @code{lp64}
+
+@item
+a single target triplet
+
+@item
+a list of target triplets within quotes or curly braces
+
+@item
+one of the following:
+
+@table @samp
+@item @{ any-opts @var{opt1} @dots{} @var{optn} @}
+Each of @var{opt1} to @var{optn} is a space-separated list of option globs.
+The selector expression evaluates to true if, for one of these strings,
+every glob in the string matches an option that was passed to the compiler.
+For example:
+
+@smallexample
+@{ any-opts "-O3 -flto" "-O[2g]" @}
+@end smallexample
+
+is true if any of the following are true:
+
+@itemize @bullet
+@item
+@option{-O2} was passed to the compiler
+
+@item
+@option{-Og} was passed to the compiler
+
+@item
+both @option{-O3} and @option{-flto} were passed to the compiler
+@end itemize
+
+This kind of selector can only be used within @code{dg-final} directives.
+Use @code{dg-skip-if}, @code{dg-xfail-if} or @code{dg-xfail-run-if} to
+skip whole tests based on options, or to mark them as expected to fail
+with certain options.
+
+@item @{ no-opts @var{opt1} @dots{} @var{optn} @}
+As for @code{any-opts} above, each of @var{opt1} to @var{optn} is a
+space-separated list of option globs.  The selector expression
+evaluates to true if, for all of these strings, there is at least
+one glob that does not match an option that was passed to the compiler.
+It is shorthand for:
+
+@smallexample
+@{ ! @{ any-opts @var{opt1} @dots{} @var{optn} @} @}
+@end smallexample
+
+For example:
+
+@smallexample
+@{ no-opts "-O3 -flto" "-O[2g]" @}
+@end smallexample
+
+is true if all of the following are true:
+
+@itemize @bullet
+@item
+@option{-O2} was not passed to the compiler
+
+@item
+@option{-Og} was not passed to the compiler
+
+@item
+at least one of @option{-O3} or @option{-flto} was not passed to the compiler
+@end itemize
+
+Like @code{any-opts}, this kind of selector can only be used within
+@code{dg-final} directives.
+
+@end table
+@end itemize
+
+Here are some examples of full target selectors:
 
 @smallexample
 @{ target @{ ! "hppa*-*-* ia64*-*-*" @} @}
 @{ target @{ powerpc*-*-* && lp64 @} @}
 @{ xfail @{ lp64 || vect_no_align @} @}
+@{ xfail @{ aarch64*-*-* && @{ any-opts "-O2" @} @} @}
 @end smallexample
 
 @node Effective-Target Keywords
diff --git a/gcc/testsuite/lib/target-supports-dg.exp 
b/gcc/testsuite/lib/target-supports-dg.exp
index c014abce4f5..94ba79eb4ae 100644
--- a/gcc/testsuite/lib/target-supports-dg.exp
+++ b/gcc/testsuite/lib/target-supports-dg.exp
@@ -570,7 +570,15 @@ if { [info procs saved-dg-process-target] == [list] } {
 
 # Evaluate a selector expression.
 proc selector_expression { exp } {
-   if { [llength $exp] == 2 } {
+   if { 

[PATCH] [libstdc++] Refactor/cleanup of atomic wait implementation

[Thomas Rodgers]

From: Thomas Rodgers 

This patch address jwakely's feedback from 2021-04-15.

This is a substantial rewrite of the atomic wait/notify (and timed wait
counterparts) implementation.

The previous __platform_wait looped on EINTR however this behavior is
not required by the standard. A new _GLIBCXX_HAVE_PLATFORM_WAIT macro
now controls whether wait/notify are implemented using a platform
specific primitive or with a platform agnostic mutex/condvar. This
patch only supplies a definition for linux futexes. A future update
could add support __ulock_wait/wake on Darwin, for instance.

The members of __waiters were lifted to a new base class. The members
are now arranged such that overall sizeof(__waiters_base) fits in two
cache lines (on platforms with at least 64 byte cache lines). The
definition will also use destructive_interference_size for this if it
is available.

The __waiters type is now specific to untimed waits. Timed waits have a
corresponding __timed_waiters type. Much of the code has been moved from
the previous __atomic_wait() free function to the __waiter_base template
and a __waiter derived type is provided to implement the un-timed wait
operations. A similar change has been made to the timed wait
implementation.

The __atomic_spin code has been extended to take a spin policy which is
invoked after the initial busy wait loop. The default policy is to
return from the spin. The timed wait code adds a timed backoff spinning
policy. The code from  which implements this_thread::sleep_for,
sleep_until has been moved to a new  header
which allows the thread sleep code to be consumed without pulling in the
whole of .

The entry points into the wait/notify code have been restructured to
support either -
   * Testing the current value of the atomic stored at the given address
 and waiting on a notification.
   * Applying a predicate to determine if the wait was satisfied.
The entry points were renamed to make it clear that the wait and wake
operations operate on addresses. The first variant takes the expected
value and a function which returns the current value that should be used
in comparison operations, these operations are named with a _v suffix
(e.g. 'value'). All atomic<_Tp> wait/notify operations use the first
variant. Barriers, latches and semaphores use the predicate variant.

This change also centralizes what it means to compare values for the
purposes of atomic::wait rather than scattering through individual
predicates.

This change also centralizes the repetitive code which adjusts for
different user supplied clocks (this should be moved elsewhere
and all such adjustments should use a common implementation).

This change also removes the hashing of the pointer and uses
the pointer value directly for indexing into the waiters table.

libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new  header.
* include/Makefile.in: Regenerate.
* include/bits/atomic_base.h: Adjust all calls
to __atomic_wait/__atomic_notify for new call signatures.
* include/bits/atomic_wait.h: Extensive rewrite.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/semaphore_base.h: Adjust all calls
to __atomic_wait/__atomic_notify for new call signatures.
* include/bits/this_thread_sleep.h: New file.
* include/std/atomic: Likewise.
* include/std/barrier: Likewise.
* include/std/latch: Likewise.
* testsuite/29_atomics/atomic/wait_notify/bool.cc: Simplify
test.
* testsuite/29_atomics/atomic/wait_notify/generic.cc: Likewise.
* testsuite/29_atomics/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomics/atomic_flag/wait_notify.cc: Likewise.
* testsuite/29_atomics/atomic_float/wait_notify.cc: Likewise.
* testsuite/29_atomics/atomic_integral/wait_notify.cc: Likewise.
* testsuite/29_atomics/atomic_ref/wait_notify.cc: Likewise.
---
 libstdc++-v3/include/Makefile.am  |   1 +
 libstdc++-v3/include/Makefile.in  |   1 +
 libstdc++-v3/include/bits/atomic_base.h   |  36 +-
 libstdc++-v3/include/bits/atomic_timed_wait.h | 457 +++--
 libstdc++-v3/include/bits/atomic_wait.h   | 471 --
 libstdc++-v3/include/bits/semaphore_base.h| 193 +++
 libstdc++-v3/include/bits/this_thread_sleep.h | 119 +
 libstdc++-v3/include/std/atomic   |  15 +-
 libstdc++-v3/include/std/barrier  |  13 +-
 libstdc++-v3/include/std/latch|   8 +-
 libstdc++-v3/include/std/semaphore|   9 +-
 libstdc++-v3/include/std/thread   |  68 +--
 .../29_atomics/atomic/wait_notify/bool.cc |  37 +-
 .../29_atomics/atomic/wait_notify/generic.cc  |  19 +-
 .../29_atomics/atomic/wait_notify/pointers.cc |  36 +-
 .../29_atomics/atomic_flag/wait_notify/1.cc   |  37 +-
 .../29_atomics/atomic_float/wait_notify.cc|  26 +-
 .../29_atomics/atomic_integral/wait_notify.cc |  73 

[Bug middle-end/99797] accessing uninitialized automatic variables

[muecker at gwdg dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797

--- Comment #11 from Martin Uecker  ---
(In reply to Ivan Sorokin from comment #10)

...
> > is a bug if this choice is unreasonable and does not serve its users well.
> 
> Do you have some specific proposal in mind?
> 
> Currently a user has these 5 options:
> 1. Using -O0 suppressing optimizations.
> 2. Using -fno-tree-ccp suppressing this specific optimization.

Optimizations are important, so this is not really an option.

> 3. Using -Wall and relying on warnings.

It is not clear to me that this fully addresses the problem. GCC does not warn
about all possible accesses to uninitialized variables.

> 4. (in theory) Using static analyzer -fanalyzer. It doesn't detect this error
>at the moment, but I believe can be taught detecting this.

This may be helpful.

> 5. Using dynamic analyzer like valgrind.

This is too expensive for production and also only useful for limited testing.

> It seems that you find existing options insufficient and want another one.

I want the optimizer to assume that uninitialized variables have an unknown but
fixed value. Then one could still optimize almost as well *and* get analyzable
and more benign behavior even when uninitialized variables are accessed.
Optimizers already know how to deal with variables of unknown content, so this
should be fairly easy to implement (maybe I will try).

I would also like something such as -fsanitize=undefined which detects for
uninitialized variables at run-time.

Best,
Martin

Fix Fortran rounding issues, PR fortran/96983.

[Michael Meissner via Gcc-patches]

Fix Fortran rounding issues, PR fortran/96983.

I was looking at Fortran PR 96983, which fails on the PowerPC when trying to
run the test PR96711.F90.  The compiler ICEs because the PowerPC does not have
a floating point type with a type precision of 128.  The reason is that the
PowerPC has 3 different 128 bit floating point types (__float128/_Float128,
__ibm128, and long double).  Currently long double uses the IBM extended double
type, but we would like to switch to using IEEE 128-bit long doubles in the
future.

In order to prevent the compiler from converting explicit __ibm128 types to
long double when long double uses the IEEE 128-bit representation, we have set
up the precision for __ibm128 to be 128, long double to be 127, and
__float128/_Float128 to be 126.

Originally, I was trying to see if for Fortran, I could change the precision of
long double to be 128 (Fortran doesn't access __ibm128), but it quickly became
hard to get the changes to work.

I looked at the Fortran code in build_round_expr, and I came to the conclusion
that there is no reason to promote the floating point type.  If you just do a
normal round of the value using the current floating point format and then
convert it to the integer type.  We don't have an appropriate built-in function
that provides the equivalent of llround for 128-bit integer types.

This patch fixes the compiler crash.

However, while with this patch, the PowerPC compiler will not crash when
building the test case, it will not run on the current default installation.
The failure is because the test is explicitly expecting 128-bit floating point
to handle 10384593717069655257060992658440192_16 (i.e. 2**113).

By default, the PowerPC uses IBM extended double used for 128-bit floating
point.  The IBM extended double format is a pair of doubles that provides more
mantissa bits but does not grow the expoenent range.  The value in the test is
fine for IEEE 128-bit floating point, but it is too large for the PowerPC
extended double setup.

I have built the following tests with this patch:

   * I have built a bootstrap compiler on a little endian power9 Linux system
 with the default long double format (IBM extended double).  The
 pr96711.f90 test builds, but it does not run due to the range of the
 real*16 exponent.  There were no other regressions in the C/C++/Fortran
 tests.

   * I have built a bootstrap compiler on a little endian power9 Linux system
 with the default long double format set to IEEE 128-bit. I used the
 Advance Toolchain 14.0-2 to provide the IEEE 128-bits.  The compiler was
 configured to build power9 code by default, so the test generated native
 power9 IEEE 128-bit instructions.  The pr96711.f90 test builds and runs
 correctly in this setup.

   * I have built a bootstrap compiler on a big endian power8 Linux system with
 the default long double format (IBM extended double).  Like the first
 case, the pr96711.f90 test does not crash the compiler, but the test fails
 due to the range of the real*16 exponent.There were no other
 regressions in the C/C++/Fortran tests.

   * I built a bootstrap compiler on my x86_64 laptop.  There were no
 regressions in the tests.


Can I check this change into the GCC trunk?

I've not contributed to the Fortran front end before.  If the maintainers like
the patch, can somebody point out if I need to do additional things to commit
the patch?

gcc/fortran/
2021-04-19  Michael Meissner  

PR gfortran/96983
* trans-intrinsic.c (build_round_expr): If int type is larger than
long long, do the round and convert to the integer type.  Do not
try to find a floating point type the exact size of the integer
type.
---
 gcc/fortran/trans-intrinsic.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 5e53d1162fa..cceef8f34ac 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -386,30 +386,20 @@ build_round_expr (tree arg, tree restype)
   argprec = TYPE_PRECISION (argtype);
   resprec = TYPE_PRECISION (restype);
 
-  /* Depending on the type of the result, choose the int intrinsic
- (iround, available only as a builtin, therefore cannot use it for
- __float128), long int intrinsic (lround family) or long long
- intrinsic (llround).  We might also need to convert the result
- afterwards.  */
+  /* Depending on the type of the result, choose the int intrinsic (iround,
+ available only as a builtin, therefore cannot use it for __float128), long
+ int intrinsic (lround family) or long long intrinsic (llround).  If we
+ don't have an appropriate function that converts directly to the integer
+ type (such as kind == 16), just use ROUND, and then convert the result to
+ an integer.  We might also need to convert the result afterwards.  */
   if (resprec <= 

[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter

[riki--b at hotmail dot it via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127

--- Comment #2 from Riccardo Brugo  ---
(In reply to Iain Sandoe from comment #1)
> I think that this issue is already fixed in the released 10.3 branch and in
> master (will shortly become GCC11).  Please could you try one of those?
> 
> $ ./gcc-10/gcc-10/bin/g++ -std=c++20 -fcoroutines pr100127.C -S -save-temps
> pr100127.C: In function ‘future create_future()’:
> pr100127.C:54:8: error: the coroutine promise type
> ‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
> ‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
>54 | future create_future()
>   |^
> pr100127.C:49:14: note: ‘return_void’ declared here
>49 | void return_void() {}
>   |  ^~~
> pr100127.C:31:14: note: ‘return_value’ declared here
>31 | void return_value(value_type val) {
>   |  ^~~~
> 
> === 
> 
> $ ./gcc-master/gcc-11-0-1/bin/g++ -std=c++20 -fcoroutines pr100127.C -S
> -save-temps
> pr100127.C: In function ‘future create_future()’:
> pr100127.C:54:8: error: the coroutine promise type
> ‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
> ‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
>54 | future create_future()
>   |^
> pr100127.C:49:14: note: ‘return_void’ declared here
>49 | void return_void() {}
>   |  ^~~
> pr100127.C:31:14: note: ‘return_value’ declared here
>31 | void return_value(value_type val) {
>   |  ^~~~

Removing the `return_void` member function will trigger a compilation error in
trunk (https://godbolt.org/z/7vfT89KEx) and a segmentation fault in 10.3
(https://godbolt.org/z/7b37sPbfo)

[Bug fortran/100136] [11 Regression] ICE, regression, using flag -fcheck=pointer

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136

--- Comment #2 from anlauf at gcc dot gnu.org ---
We do not properly handle the VALUE attribute.

Reduced testcase:

program p
  implicit none
  class(*), allocatable :: d
  call add_class (d)
contains
  subroutine add_class (d)
class(*), value :: d
  end subroutine
end program

Re: [Patch] PR tree-optimization/100081 - Limit depth of logical expression windback.

[Andrew MacLeod via Gcc-patches]

On 4/19/21 4:18 AM, Richard Biener wrote:

On Sun, Apr 18, 2021 at 4:40 AM Andrew MacLeod via Gcc-patches
 wrote:



I also disable the logical cache since it isn't really doing anything
any more.

   OK for trunk?

Please make

+#define LOGICAL_LIMIT  6

a --param (params.opt, documented in invoke.texi)

OK with that change.

Thanks,
Richard.

I presume this is still OK?   This is based off the second variant of 
the patch which simply doesn't build the dependency chains thru too many 
logicals, along with:


a) the removal of the logical cache like in the first patch,

b) the suggested addition of the --param option for the constant, and

c) Jakubs suggestion to use is_gimple-assign ().

I'll check it in once it finishes the build/regression tests.

Andrew




commit 09b8f25e6e32534a904ce7bfe94ae97bf93d77c3
Author: Andrew MacLeod 
Date:   Fri Apr 16 17:08:51 2021 -0400

Limit depth of logical expression windback.

Limit how many logical expressions GORI will look back through when
evaluating outgoing edge range.

PR tree-optimization/100081
* gimple_range_cache.h (ranger_cache): Inherit from gori_compute
rather than gori_compute_cache.
* gimple_range_gori.cc (is_gimple_logical_p): Move to top of file.
(range_def_chain::m_logical_depth): New member.
(range_def_chain::range_def_chain): Initialize m_logical_depth.
(range_def_chain::get_def_chain): Don't build defchains through more
than LOGICAL_LIMIT logical expressions.
* params.opt (param_ranger_logical_depth): New.

diff --git a/gcc/gimple-range-cache.h b/gcc/gimple-range-cache.h
index c98e9871734..2b36a02654b 100644
--- a/gcc/gimple-range-cache.h
+++ b/gcc/gimple-range-cache.h
@@ -87,7 +87,7 @@ private:
 // them available for gori-computes to query so outgoing edges can be
 // properly calculated.
 
-class ranger_cache : public gori_compute_cache
+class ranger_cache : public gori_compute
 {
 public:
   ranger_cache (class gimple_ranger );
diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 7f7f3dc0d69..420282deb2d 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -29,6 +29,32 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-pretty-print.h"
 #include "gimple-range.h"
 
+// Return TRUE if GS is a logical && or || expression.
+
+static inline bool
+is_gimple_logical_p (const gimple *gs)
+{
+  // Look for boolean and/or condition.
+  if (is_gimple_assign (gs))
+switch (gimple_expr_code (gs))
+  {
+	case TRUTH_AND_EXPR:
+	case TRUTH_OR_EXPR:
+	  return true;
+
+	case BIT_AND_EXPR:
+	case BIT_IOR_EXPR:
+	  // Bitwise operations on single bits are logical too.
+	  if (types_compatible_p (TREE_TYPE (gimple_assign_rhs1 (gs)),
+  boolean_type_node))
+	return true;
+	  break;
+
+	default:
+	  break;
+  }
+  return false;
+}
 
 /* RANGE_DEF_CHAIN is used to determine what SSA names in a block can
have range information calculated for them, and what the
@@ -76,6 +102,7 @@ public:
 private:
   vec m_def_chain;	// SSA_NAME : def chain components.
   void build_def_chain (tree name, bitmap result, basic_block bb);
+  int m_logical_depth;
 };
 
 
@@ -85,6 +112,7 @@ range_def_chain::range_def_chain ()
 {
   m_def_chain.create (0);
   m_def_chain.safe_grow_cleared (num_ssa_names);
+  m_logical_depth = 0;
 }
 
 // Destruct a range_def_chain.
@@ -157,6 +185,7 @@ range_def_chain::get_def_chain (tree name)
 {
   tree ssa1, ssa2, ssa3;
   unsigned v = SSA_NAME_VERSION (name);
+  bool is_logical = false;
 
   // If it has already been processed, just return the cached value.
   if (has_def_chain (name))
@@ -169,6 +198,15 @@ range_def_chain::get_def_chain (tree name)
   gimple *stmt = SSA_NAME_DEF_STMT (name);
   if (gimple_range_handler (stmt))
 {
+  is_logical = is_gimple_logical_p (stmt);
+  // Terminate the def chains if we see too many cascading logical stmts.
+  if (is_logical)
+	{
+	  if (m_logical_depth == param_ranger_logical_depth)
+	return NULL;
+	  m_logical_depth++;
+	}
+
   ssa1 = gimple_range_ssa_p (gimple_range_operand1 (stmt));
   ssa2 = gimple_range_ssa_p (gimple_range_operand2 (stmt));
   ssa3 = NULL_TREE;
@@ -195,6 +233,9 @@ range_def_chain::get_def_chain (tree name)
   if (ssa3)
 build_def_chain (ssa3, m_def_chain[v], bb);
 
+  if (is_logical)
+m_logical_depth--;
+
   // If we run into pathological cases where the defintion chains are
   // huge (ie  huge basic block fully unrolled) we might be able to limit
   // this by deciding here that if some criteria is satisfied, we change the
@@ -562,32 +603,6 @@ gori_compute::compute_operand_range_switch (irange , gswitch *s,
   return false;
 }
 
-// Return TRUE if GS is a logical && or || expression.
-
-static inline bool
-is_gimple_logical_p (const gimple *gs)
-{
-  // Look for boolean and/or condition.
-  if (gimple_code (gs) == GIMPLE_ASSIGN)
-switch 

[Bug debug/100148] [10/11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148

--- Comment #2 from Jakub Jelinek  ---
I bet it goes wrong during cprop1, at least fwprop1 dumps with --param
min-nondebug-insn-uid=1 look good to me and cprop1 contains
-rescanning insn with uid = 10033.
-GLOBAL CONST-PROP: Replacing reg 82 in jump_insn 10033 with constant
(const_int 0 [0])
-Purged edges from bb 8
-deleting insn with uid = 10033.
-GLOBAL CONST-PROP: Replacing reg 82 in insn 10029 with constant (const_int 0
[0])
-CPROP of foo, 14 basic blocks, 592 bytes needed, 0 local const props, 0 local
copy props, 2 global const props, 0 global copy props
+CPROP of foo, 14 basic blocks, 592 bytes needed, 0 local const props, 0 local
copy props, 0 global const props, 0 global copy props

as the first major difference.

Re: [PATCH] combine: Don't create REG_UNUSED notes if the reg already died (PR99927)

[Segher Boessenkool]

On Sun, Apr 18, 2021 at 12:03:39PM -0500, Segher Boessenkool wrote:
> On Sun, Apr 18, 2021 at 05:24:50PM +0200, Jakub Jelinek wrote:
> > On Sun, Apr 18, 2021 at 03:03:07PM +, Segher Boessenkool wrote:
> > > If the register named in an existing REG_UNUSED note dies somewhere
> > > between where the note used to be and I3, we should just drop it.

> > And, shouldn't the
> >   record_value_for_reg (XEXP (note, 0), NULL, NULL_RTX);
> > be called in some cases?
> 
> I don't see why?  We don't remove any clobber or set, just the REG_UNUSED
> note?
> 
> > To me it would make more sense to add the if (reg_set_between_p (...)) 
> > break;
> > to the individual cases later, so before
> >   if (! (REG_P (XEXP (note, 0))
> >  ? find_regno_note (i3, REG_UNUSED, REGNO (XEXP (note, 
> > 0)))
> >  : find_reg_note (i3, REG_UNUSED, XEXP (note, 0
> > place = i3;
> > and before
> >   PUT_REG_NOTE_KIND (note, REG_DEAD);
> >   place = i3;
> > and into the
> >   if (from_insn != i3 && i2 && INSN_P (i2)
> >   && reg_referenced_p (XEXP (note, 0), PATTERN (i2)))
> > but there just checking if it isn't set in between from_insn and i2
> 
> But the REG_UNUSED note should just be dropped in all these cases, so it
> is much simpler code to do it like this.  Or am I missing something?

I have now tested this on kernel builds on all supported archs (and
variations; 31 builds, mostly defconfigs, some bigger).  The patch
changed generated code in no single place, so we're good probably :-)


Segher

[Bug d/98494] libphobos: std.process Config.stderrPassThrough missing

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98494

Iain Buclaw  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Iain Buclaw  ---
Added to phobos.

[committed] d: Fix ICE in when formating a string with '%' or '`' characters (PR98457)

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes an ICE that occurred in the D front-end diagnostic
handlers.  The percentage character was being confused for a format
specifier in pp_format(), whilst the backtick character was confused for
the beginning of a quoted string in expand_d_format().

Both are now properly escaped to avoid the ICE.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Will also be preparing a backport to the gcc-10 and gcc-9 release
branches, as the bug is reproducible there as well.

Regards,
Iain.

---
gcc/d/ChangeLog:

PR d/98457
* d-diagnostic.cc (expand_d_format): Handle escaped backticks.
(escape_d_format): New funtion.
(verror): Call escape_d_format on prefixing strings.
(vdeprecation): Likewise.

gcc/testsuite/ChangeLog:

PR d/98457
* gdc.dg/pr98457.d: New test.
---
 gcc/d/d-diagnostic.cc  | 64 +++---
 gcc/testsuite/gdc.dg/pr98457.d |  9 +
 2 files changed, 68 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr98457.d

diff --git a/gcc/d/d-diagnostic.cc b/gcc/d/d-diagnostic.cc
index 3bf5a535edd..7043abe10bd 100644
--- a/gcc/d/d-diagnostic.cc
+++ b/gcc/d/d-diagnostic.cc
@@ -48,7 +48,7 @@ expand_d_format (const char *format)
 
   for (const char *p = format; *p;)
 {
-  while (*p != '\0' && *p != '%' && *p != '`')
+  while (*p != '\0' && *p != '\\' && *p != '%' && *p != '`')
{
  obstack_1grow (, *p);
  p++;
@@ -57,6 +57,21 @@ expand_d_format (const char *format)
   if (*p == '\0')
break;
 
+  if (*p == '\\')
+   {
+ if (p[1] == '`')
+   {
+ /* Escaped backtick, don't expand it as a quoted string.  */
+ obstack_1grow (, '`');
+ p++;;
+   }
+ else
+   obstack_1grow (, *p);
+
+ p++;
+ continue;
+   }
+
   if (*p == '`')
{
  /* Text enclosed by `...` are translated as a quoted string.  */
@@ -114,6 +129,43 @@ expand_d_format (const char *format)
   return (char *) obstack_finish ();
 }
 
+/* Rewrite the format string FORMAT to deal with any characters that require
+   escaping before expand_d_format expands it.  */
+
+static char *
+escape_d_format (const char *format)
+{
+  obstack buf;
+
+  gcc_obstack_init ();
+
+  for (const char *p = format; *p; p++)
+{
+  switch (*p)
+   {
+   case '%':
+ /* Escape `%' characters so that pp_format does not confuse them
+for actual format specifiers.  */
+ obstack_1grow (, '%');
+ break;
+
+   case '`':
+ /* Escape '`' characters so that expand_d_format does not confuse them
+for a quoted string.  */
+ obstack_1grow (, '\\');
+ break;
+
+   default:
+ break;
+   }
+
+  obstack_1grow (, *p);
+}
+
+  obstack_1grow (, '\0');
+  return (char *) obstack_finish ();
+}
+
 /* Helper routine for all error routines.  Reports a diagnostic specified by
KIND at the explicit location LOC.  The message FORMAT comes from the dmd
front-end, which does not get translated by the gcc diagnostic routines.  */
@@ -177,9 +229,10 @@ verror (const Loc , const char *format, va_list ap,
 
   /* Build string and emit.  */
   if (prefix2 != NULL)
-   xformat = xasprintf ("%s %s %s", prefix1, prefix2, format);
+   xformat = xasprintf ("%s %s %s", escape_d_format (prefix1),
+escape_d_format (prefix2), format);
   else if (prefix1 != NULL)
-   xformat = xasprintf ("%s %s", prefix1, format);
+   xformat = xasprintf ("%s %s", escape_d_format (prefix1), format);
   else
xformat = xasprintf ("%s", format);
 
@@ -289,9 +342,10 @@ vdeprecation (const Loc , const char *format, va_list 
ap,
 
   /* Build string and emit.  */
   if (prefix2 != NULL)
-   xformat = xasprintf ("%s %s %s", prefix1, prefix2, format);
+   xformat = xasprintf ("%s %s %s", escape_d_format (prefix1),
+escape_d_format (prefix2), format);
   else if (prefix1 != NULL)
-   xformat = xasprintf ("%s %s", prefix1, format);
+   xformat = xasprintf ("%s %s", escape_d_format (prefix1), format);
   else
xformat = xasprintf ("%s", format);
 
diff --git a/gcc/testsuite/gdc.dg/pr98457.d b/gcc/testsuite/gdc.dg/pr98457.d
new file mode 100644
index 000..bc0d8af5d4a
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr98457.d
@@ -0,0 +1,9 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457
+// { dg-do compile }
+
+void main()
+{
+writef!"%s";// { dg-error "template instance writef!\"%s\" template 
.writef. is not defined" }
+writef!"`%s";   // { dg-error "template instance writef!\"`%s\" template 
.writef. is not defined" }
+writef!"%%s`";  // { dg-error "template instance writef!\"%%s`\" template 
.writef. is not defined" }
+}
-- 
2.27.0

[committed] libphobos: Add section support code for OpenBSD (PR99691)

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes the section support code for libphobos on OpenBSD, this
is enough to get the library built, and most tests will pass now.

Testsuite hasn't been confirmed to pass cleanly just yet, so support for
libphobos on OpenBSD is still considered experimental.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, as
well as x86_64-openbsd6.8 for testing the initial port, and committed to
mainline.

Regards,
Iain.

---
libphobos/ChangeLog:

PR d/99691
* configure: Regenerate.
* libdruntime/config/common/threadasm.S: Add __OpenBSD__.
* libdruntime/gcc/backtrace.d: Import core.sys.openbsd.dlfcn on
OpenBSD platforms.
* libdruntime/gcc/sections/elf.d (SharedElf): Define on OpenBSD.
(linkMapForHandle): Implement for OpenBSD.
(exeLinkMap): Remove.
(getDependencies): Adjust dlpi_addr on OpenBSD.
(handleForName): Implement for OpenBSD.
(IterateManually): Define on OpenBSD.
* libdruntime/gcc/sections/package.d (SectionsElf): Define on OpenBSD.
* m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_ATOMIC): Test for
enable_libatomic.
(DRUNTIME_LIBRARIES_BACKTRACE): Test for enable_libbacktrace.
---
 libphobos/configure   |  4 +-
 .../libdruntime/config/common/threadasm.S |  2 +-
 libphobos/libdruntime/gcc/backtrace.d |  4 +-
 libphobos/libdruntime/gcc/sections/elf.d  | 54 +--
 libphobos/libdruntime/gcc/sections/package.d  |  1 +
 libphobos/m4/druntime/libraries.m4|  4 +-
 6 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index fe7cd9c11ff..2c0f57cef03 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -14917,7 +14917,7 @@ fi
 
   DCFG_HAVE_LIBATOMIC=false
   LIBATOMIC=
-  if test "x$with_libatomic" != "xno"; then :
+  if test "x$enable_libatomic" != "xno" && test "x$with_libatomic" != "xno"; 
then :
 
 DCFG_HAVE_LIBATOMIC=true
 LIBATOMIC=../../libatomic/libatomic_convenience.la
@@ -14953,7 +14953,7 @@ if test "${with_libbacktrace+set}" = set; then :
 fi
 
 
-  if test "x$with_libbacktrace" != "xno"; then :
+  if test "x$enable_libbacktrace" != "xno" && test "x$with_libbacktrace" != 
"xno"; then :
 
 LIBBACKTRACE=../../libbacktrace/libbacktrace.la
 
diff --git a/libphobos/libdruntime/config/common/threadasm.S 
b/libphobos/libdruntime/config/common/threadasm.S
index 1e9bc760527..35462170e58 100644
--- a/libphobos/libdruntime/config/common/threadasm.S
+++ b/libphobos/libdruntime/config/common/threadasm.S
@@ -22,7 +22,7 @@ a copy of the GCC Runtime Library Exception along with this 
program;
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
-#if (__linux__ || __FreeBSD__ || __NetBSD__ || __DragonFly__) && __ELF__
+#if (__linux__ || __FreeBSD__ || __NetBSD__ || __OpenBSD__ || __DragonFly__) 
&& __ELF__
 /*
  * Mark the resulting object file as not requiring execution permissions on
  * stack memory. The absence of this section would mark the whole resulting
diff --git a/libphobos/libdruntime/gcc/backtrace.d 
b/libphobos/libdruntime/gcc/backtrace.d
index 45dd011dc63..8f5582d7469 100644
--- a/libphobos/libdruntime/gcc/backtrace.d
+++ b/libphobos/libdruntime/gcc/backtrace.d
@@ -424,8 +424,10 @@ private:
 import core.sys.freebsd.dlfcn;
 else version (NetBSD)
 import core.sys.netbsd.dlfcn;
+else version (OpenBSD)
+import core.sys.openbsd.dlfcn;
 else version (Solaris)
-import core.sys.netbsd.dlfcn;
+import core.sys.solaris.dlfcn;
 else version (Posix)
 import core.sys.posix.dlfcn;
 
diff --git a/libphobos/libdruntime/gcc/sections/elf.d 
b/libphobos/libdruntime/gcc/sections/elf.d
index 8450aecb239..3480fb9474c 100644
--- a/libphobos/libdruntime/gcc/sections/elf.d
+++ b/libphobos/libdruntime/gcc/sections/elf.d
@@ -33,6 +33,7 @@ version (CRuntime_Glibc) enum SharedELF = true;
 else version (CRuntime_Musl) enum SharedELF = true;
 else version (FreeBSD) enum SharedELF = true;
 else version (NetBSD) enum SharedELF = true;
+else version (OpenBSD) enum SharedELF = true;
 else version (DragonFlyBSD) enum SharedELF = true;
 else version (CRuntime_UClibc) enum SharedELF = true;
 else version (Solaris) enum SharedELF = true;
@@ -62,6 +63,12 @@ else version (NetBSD)
 import core.sys.netbsd.sys.elf;
 import core.sys.netbsd.sys.link_elf;
 }
+else version (OpenBSD)
+{
+import core.sys.openbsd.dlfcn;
+import core.sys.openbsd.sys.elf;
+import core.sys.openbsd.sys.link_elf;
+}
 else version (DragonFlyBSD)
 {
 import core.sys.dragonflybsd.dlfcn;
@@ -688,20 +695,22 @@ version (Shared)
 @nogc nothrow:
 link_map* linkMapForHandle(void* handle)
 {
-link_map* map;
-const success = dlinfo(handle, RTLD_DI_LINKMAP, ) == 0;
-safeAssert(success, "Failed to get DSO info.");
-return map;
+

[committed] libphobos: Add Thread/Fiber support code for Darwin (PR98058)

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes the thread support when building libphobos on Darwin,
this is enough to get the library built, and most tests to pass on a
fairly modern platform.

Testsuite hasn't been confirmed to pass cleanly on as broad a targets as
I'd like, so support is still very much experimental.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, as
well as x86_64-apple-darwin for testing the initial port, and committed
to mainline.

Regards,
Iain.

---
libphobos/ChangeLog:

PR d/98058
* configure: Regenerate.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES_DARWIN): Add
core/sys/darwin/config.d
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/powerpc/switchcontext.S: Implement
fiber_switchContext for __MACH__.
* libdruntime/config/x86/switchcontext.S: Likewise.
* libdruntime/core/sys/darwin/config.d: New file.
* libdruntime/core/thread/fiber.d (Fiber.getThis): Mark noinline.
(UnsafeFiberMigration): Define for OSX/X86 and OSX/X86_64.
* libdruntime/core/thread/osthread.d (callWithStackShell): Add inline
assembler implementation for X86, X86_64, PPC, and PPC64.
* libdruntime/core/thread/threadbase.d (ThreadBase.getThis): Mark
noinline.
* libdruntime/gcc/deh.d (FuncTable): Remove definition.
* m4/druntime/os.m4 (DRUNTIME_OS_MINFO_BRACKETING): Check for right
bracket symbol on darwin* targets.
* testsuite/libphobos.thread/fiber_guard_page.d: Update test to
support ucontext-based Fibers.
---
 libphobos/configure   |  22 +-
 libphobos/libdruntime/Makefile.am |  26 +-
 libphobos/libdruntime/Makefile.in |  37 +--
 .../config/powerpc/switchcontext.S| 278 +-
 .../libdruntime/config/x86/switchcontext.S| 159 +-
 .../libdruntime/core/sys/darwin/config.d  |  53 
 libphobos/libdruntime/core/thread/fiber.d |   6 +
 libphobos/libdruntime/core/thread/osthread.d  |  94 +-
 .../libdruntime/core/thread/threadbase.d  |   1 +
 libphobos/libdruntime/gcc/deh.d   |   5 -
 libphobos/m4/druntime/os.m4   |  22 +-
 .../libphobos.thread/fiber_guard_page.d   |   6 +-
 12 files changed, 656 insertions(+), 53 deletions(-)
 create mode 100644 libphobos/libdruntime/core/sys/darwin/config.d

diff --git a/libphobos/configure b/libphobos/configure
index 2c0f57cef03..b1c8ecb5673 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -14422,6 +14422,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
 
+
+
   ac_ext=c
 ac_cpp='$CPP $CPPFLAGS'
 ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
@@ -14430,17 +14432,29 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for minfo section 
bracketing" >&5
 $as_echo_n "checking for minfo section bracketing... " >&6; }
+  case "$druntime_cv_target_os" in
+  darwin*)
+   section="__DATA,__minfodata"
+   start="section\$start\$__DATA\$__minfodata"
+   stop="section\$end\$__DATA\$__minfodata"
+   ;;
+  *)
+   section="minfo"
+   start="__start_minfo"
+   stop="__stop_minfo"
+   ;;
+  esac
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
-void* module_info_ptr __attribute__((section ("minfo")));
-extern void* __start_minfo __attribute__((visibility ("hidden")));
-extern void* __stop_minfo __attribute__((visibility ("hidden")));
+void* module_info_ptr __attribute__((section ("$section")));
+extern void* start_minfo __asm__("$start") __attribute__((visibility 
("hidden")));
+extern void* stop_minfo __asm__("$stop") __attribute__((visibility 
("hidden")));
 
 int main()
 {
 // Never run, just to prevent compiler from optimizing access
-return &__start_minfo == &__stop_minfo;
+return (int)(_minfo - _minfo);
 }
 
 _ACEOF
diff --git a/libphobos/libdruntime/Makefile.am 
b/libphobos/libdruntime/Makefile.am
index fdac627364d..a2e2bff9e44 100644
--- a/libphobos/libdruntime/Makefile.am
+++ b/libphobos/libdruntime/Makefile.am
@@ -206,19 +206,19 @@ DRUNTIME_DSOURCES_BIONIC = core/sys/bionic/err.d \
core/sys/bionic/fcntl.d core/sys/bionic/stdlib.d \
core/sys/bionic/string.d core/sys/bionic/unistd.d
 
-DRUNTIME_DSOURCES_DARWIN = core/sys/darwin/crt_externs.d \
-   core/sys/darwin/dlfcn.d core/sys/darwin/err.d \
-   core/sys/darwin/execinfo.d core/sys/darwin/fcntl.d \
-   core/sys/darwin/ifaddrs.d core/sys/darwin/mach/dyld.d \
-   core/sys/darwin/mach/getsect.d core/sys/darwin/mach/kern_return.d \
-   core/sys/darwin/mach/loader.d core/sys/darwin/mach/nlist.d \
-   core/sys/darwin/mach/port.d core/sys/darwin/mach/semaphore.d \
-   core/sys/darwin/mach/stab.d core/sys/darwin/mach/thread_act.d \
-   core/sys/darwin/netinet/in_.d core/sys/darwin/pthread.d \
-   

[committed] libphobos: Add D runtime support code for MinGW (PR99794)

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes libphobos support when building on MinGW, this is
enough to get the library built, and most tests to pass.

Testsuite haven't been confirmed to pass cleanly, so support is still
very much experimental.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, as
well as x86_64-w64-mingw32 for testing the initial port, and committed
to mainline.

Regards,
Iain.

---
libphobos/ChangeLog:

PR d/99794
* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Add
config/mingw/msvc.c on DRUNTIME_OS_MINGW.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/mingw/msvc.c: New file.
* libdruntime/config/mingw/switchcontext.S (fiber_switchContext): Fix
function definition.
* libdruntime/gcc/deh.d (__gdc_personality_seh0): Fix call to
_GCC_specific_handler.
* libdruntime/gcc/gthread.d (__gthread_once_t): Fix definition.
* libdruntime/gcc/unwind/generic.d (_GCC_specific_handler): Fix
declaration.
* libdruntime/rt/dmain2.d (rt_loadLibrary): Remove function.
(rt_loadLibraryW): Remove function.
(initLibrary): Remove function.
(rt_unloadLibrary): Remove function.
---
 libphobos/libdruntime/Makefile.am |   3 +-
 libphobos/libdruntime/Makefile.in |  56 +++---
 libphobos/libdruntime/config/mingw/msvc.c | 169 ++
 .../libdruntime/config/mingw/switchcontext.S  |  12 +-
 libphobos/libdruntime/gcc/deh.d   |   2 +-
 libphobos/libdruntime/gcc/gthread.d   |   6 +-
 libphobos/libdruntime/gcc/unwind/generic.d|   2 +-
 libphobos/libdruntime/rt/dmain2.d |  67 +--
 8 files changed, 223 insertions(+), 94 deletions(-)
 create mode 100644 libphobos/libdruntime/config/mingw/msvc.c

diff --git a/libphobos/libdruntime/Makefile.am 
b/libphobos/libdruntime/Makefile.am
index 02a68b10424..fdac627364d 100644
--- a/libphobos/libdruntime/Makefile.am
+++ b/libphobos/libdruntime/Makefile.am
@@ -69,7 +69,8 @@ if DRUNTIME_OS_LINUX
 DRUNTIME_SOURCES_CONFIGURED += $(DRUNTIME_DSOURCES_LINUX)
 endif
 if DRUNTIME_OS_MINGW
-DRUNTIME_SOURCES_CONFIGURED += $(DRUNTIME_DSOURCES_WINDOWS)
+DRUNTIME_SOURCES_CONFIGURED += $(DRUNTIME_DSOURCES_WINDOWS) \
+  config/mingw/msvc.c
 endif
 if DRUNTIME_OS_SOLARIS
 DRUNTIME_SOURCES_CONFIGURED += $(DRUNTIME_DSOURCES_SOLARIS)
diff --git a/libphobos/libdruntime/Makefile.in 
b/libphobos/libdruntime/Makefile.in
index 853a7fc1981..1ff2ac665ee 100644
--- a/libphobos/libdruntime/Makefile.in
+++ b/libphobos/libdruntime/Makefile.in
@@ -117,7 +117,9 @@ target_triplet = @target@
 @DRUNTIME_OS_NETBSD_TRUE@am__append_6 = $(DRUNTIME_DSOURCES_NETBSD)
 @DRUNTIME_OS_OPENBSD_TRUE@am__append_7 = $(DRUNTIME_DSOURCES_OPENBSD)
 @DRUNTIME_OS_LINUX_TRUE@am__append_8 = $(DRUNTIME_DSOURCES_LINUX)
-@DRUNTIME_OS_MINGW_TRUE@am__append_9 = $(DRUNTIME_DSOURCES_WINDOWS)
+@DRUNTIME_OS_MINGW_TRUE@am__append_9 = $(DRUNTIME_DSOURCES_WINDOWS) \
+@DRUNTIME_OS_MINGW_TRUE@  config/mingw/msvc.c
+
 @DRUNTIME_OS_SOLARIS_TRUE@am__append_10 = $(DRUNTIME_DSOURCES_SOLARIS)
 # CPU specific sources
 @DRUNTIME_CPU_AARCH64_TRUE@am__append_11 = config/aarch64/switchcontext.S
@@ -428,7 +430,8 @@ am__objects_19 = core/sys/windows/accctrl.lo \
core/sys/windows/winsvc.lo core/sys/windows/winuser.lo \
core/sys/windows/winver.lo core/sys/windows/wtsapi32.lo \
core/sys/windows/wtypes.lo
-@DRUNTIME_OS_MINGW_TRUE@am__objects_20 = $(am__objects_19)
+@DRUNTIME_OS_MINGW_TRUE@am__objects_20 = $(am__objects_19) \
+@DRUNTIME_OS_MINGW_TRUE@   config/mingw/libgdruntime_la-msvc.lo
 am__objects_21 = core/sys/solaris/dlfcn.lo core/sys/solaris/elf.lo \
core/sys/solaris/err.lo core/sys/solaris/execinfo.lo \
core/sys/solaris/libelf.lo core/sys/solaris/link.lo \
@@ -463,24 +466,26 @@ am_libgdruntime_la_OBJECTS = $(am__objects_33)
 libgdruntime_la_OBJECTS = $(am_libgdruntime_la_OBJECTS)
 am__DEPENDENCIES_2 = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
 am__objects_34 = core/stdc/libgdruntime_convenience_la-errno_.lo
-@DRUNTIME_CPU_AARCH64_TRUE@am__objects_35 = 
config/aarch64/libgdruntime_convenience_la-switchcontext.lo
-@DRUNTIME_CPU_ARM_TRUE@am__objects_36 = 
config/arm/libgdruntime_convenience_la-switchcontext.lo
-@DRUNTIME_CPU_MIPS_TRUE@am__objects_37 = 
config/mips/libgdruntime_convenience_la-switchcontext.lo
-@DRUNTIME_CPU_POWERPC_TRUE@am__objects_38 = 
config/powerpc/libgdruntime_convenience_la-switchcontext.lo
-@DRUNTIME_CPU_X86_TRUE@@DRUNTIME_OS_MINGW_TRUE@am__objects_39 = 
config/mingw/libgdruntime_convenience_la-switchcontext.lo
-@DRUNTIME_CPU_X86_TRUE@@DRUNTIME_OS_MINGW_FALSE@am__objects_40 = 
config/x86/libgdruntime_convenience_la-switchcontext.lo
-@DRUNTIME_CPU_SYSTEMZ_TRUE@am__objects_41 = 
config/systemz/libgdruntime_convenience_la-get_tls_offset.lo
-@DRUNTIME_CPU_S390_TRUE@am__objects_42 = 

[committed] libphobos: Merge upstream druntime 89f870b7, phobos e6907ff3e

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D runtime library with upstream druntime 89f870b7,
and phobos e6907ff3e.  Synchronizes the C bindings with the latest port
fixes in upstream druntime, and adds a Config.stderrPassThrough enum
member to std.process (fixing PR98494).

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

---
libphobos/ChangeLog:

PR d/98494
* libdruntime/MERGE: Merge upstream druntime 89f870b7.
* src/MERGE: Merge upstream phobos e6907ff3e.
---
 libphobos/libdruntime/MERGE   |   2 +-
 libphobos/libdruntime/core/stdc/config.d  |  39 +--
 libphobos/libdruntime/core/stdc/math.d| 295 +-
 libphobos/libdruntime/core/stdc/stdio.d   |  82 -
 libphobos/libdruntime/core/stdc/stdlib.d  |  27 +-
 libphobos/libdruntime/core/stdc/tgmath.d  |   7 +
 .../core/sys/darwin/mach/thread_act.d |  66 
 .../core/sys/openbsd/sys/link_elf.d   |   5 +
 libphobos/libdruntime/core/sys/posix/stdio.d  |  50 +++
 libphobos/libdruntime/core/sys/windows/com.d  |   4 +-
 .../libdruntime/core/sys/windows/dbghelp.d|   2 +-
 libphobos/libdruntime/core/sys/windows/dll.d  |   4 +-
 .../libdruntime/core/sys/windows/threadaux.d  |   4 +-
 libphobos/libdruntime/core/thread/fiber.d |  42 ++-
 libphobos/libdruntime/core/thread/osthread.d  |  44 ++-
 .../libdruntime/core/thread/threadbase.d  |   3 +
 libphobos/src/MERGE   |   2 +-
 libphobos/src/std/process.d   |  51 ++-
 18 files changed, 520 insertions(+), 209 deletions(-)

diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
index d839a08c19b..25cbb955ba2 100644
--- a/libphobos/libdruntime/MERGE
+++ b/libphobos/libdruntime/MERGE
@@ -1,4 +1,4 @@
-1134b71039881464e9bf021836d82796b3a1fcfc
+89f870b76710a4cfa96f711bb5b14a7439c5c2a7
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/druntime repository.
diff --git a/libphobos/libdruntime/core/stdc/config.d 
b/libphobos/libdruntime/core/stdc/config.d
index 802f5b6fb21..44bb7077b59 100644
--- a/libphobos/libdruntime/core/stdc/config.d
+++ b/libphobos/libdruntime/core/stdc/config.d
@@ -186,7 +186,18 @@ else version (Posix)
   }
 }
 
-version (CRuntime_Microsoft)
+version (GNU)
+alias c_long_double = real;
+else version (LDC)
+alias c_long_double = real; // 64-bit real for MSVC targets
+else version (SDC)
+{
+version (X86)
+alias c_long_double = real;
+else version (X86_64)
+alias c_long_double = real;
+}
+else version (CRuntime_Microsoft)
 {
 /* long double is 64 bits, not 80 bits, but is mangled differently
  * than double. To distinguish double from long double, create a wrapper 
to represent
@@ -222,17 +233,6 @@ else version (DigitalMars)
 alias real c_long_double;
 }
 }
-else version (GNU)
-alias real c_long_double;
-else version (LDC)
-alias real c_long_double;
-else version (SDC)
-{
-version (X86)
-alias real c_long_double;
-else version (X86_64)
-alias real c_long_double;
-}
 
 static assert(is(c_long_double), "c_long_double needs to be declared for this 
platform/architecture.");
 
@@ -257,18 +257,9 @@ private struct _Complex(T)
 T im;
 }
 
-version (Posix)
-{
-align(float.alignof)  enum __c_complex_float : _Complex!float;
-align(double.alignof) enum __c_complex_double : _Complex!double;
-align(real.alignof)   enum __c_complex_real : _Complex!real;
-}
-else
-{
-align(float.sizeof * 2)  enum __c_complex_float : _Complex!float;
-align(double.sizeof * 2) enum __c_complex_double : _Complex!double;
-align(real.alignof)  enum __c_complex_real : _Complex!real;
-}
+enum __c_complex_float  : _Complex!float;
+enum __c_complex_double : _Complex!double;
+enum __c_complex_real   : _Complex!c_long_double;
 
 alias c_complex_float = __c_complex_float;
 alias c_complex_double = __c_complex_double;
diff --git a/libphobos/libdruntime/core/stdc/math.d 
b/libphobos/libdruntime/core/stdc/math.d
index fba78ee233a..2de6e579575 100644
--- a/libphobos/libdruntime/core/stdc/math.d
+++ b/libphobos/libdruntime/core/stdc/math.d
@@ -424,92 +424,177 @@ else version (CRuntime_Microsoft) // fully supported 
since MSVCRT 12 (VS 2013) o
 pure int _fpclass(double x);
   }
 
+  version (MinGW)
+  {
 enum
 {
 ///
-FP_SUBNORMAL = -2,
+FP_NAN = 0x0100,
 ///
-FP_NORMAL= -1,
+FP_NORMAL = 0x0400,
 ///
-FP_ZERO  =  0,
+FP_INFINITE = FP_NAN | FP_NORMAL,
 ///
-FP_INFINITE  =  1,
+FP_ZERO = 0x0400,
 ///
-FP_NAN   =  2,
+FP_SUBNORMAL = FP_NORMAL | FP_ZERO
 }
 
-  extern(D)
-  {
-//int fpclassify(real-floating x);
-///
-extern(C) pragma(mangle, "_fdclass") pure int fpclassify(float x);
-///
-extern(C) pragma(mangle, "_dclass")  pure int 

[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:dc7d1c74ffb1cc85e67984632f581d526c783770

commit r11-8250-gdc7d1c74ffb1cc85e67984632f581d526c783770
Author: Iain Buclaw 
Date:   Mon Apr 19 18:45:32 2021 +0200

d: Fix ICE in when formating a string with '%' or '`' characters (PR98457)

The percentage character was being confused for a format specifier in
pp_format(), whilst the backtick character was confused for the
beginning of a quoted string in expand_d_format().

Both are now properly escaped to avoid the ICE.

gcc/d/ChangeLog:

PR d/98457
* d-diagnostic.cc (expand_d_format): Handle escaped backticks.
(escape_d_format): New funtion.
(verror): Call escape_d_format on prefixing strings.
(vdeprecation): Likewise.

gcc/testsuite/ChangeLog:

PR d/98457
* gdc.dg/pr98457.d: New test.

[Bug d/98494] libphobos: std.process Config.stderrPassThrough missing

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98494

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:e19c6389966216af5925d2917a206cedc40540e8

commit r11-8249-ge19c6389966216af5925d2917a206cedc40540e8
Author: Iain Buclaw 
Date:   Mon Apr 19 13:51:02 2021 +0200

libphobos: Merge upstream druntime 89f870b7, phobos e6907ff3e

Phobos changes:

 - Synchronize C bindings with the latest port fixes in upstream
   druntime.

 - Add Config.stderrPassThrough to std.process (PR98494).

Reviewed-on: https://github.com/dlang/druntime/pull/3448
 https://github.com/dlang/phobos/pull/7984

libphobos/ChangeLog:

PR d/98494
* libdruntime/MERGE: Merge upstream druntime 89f870b7.
* src/MERGE: Merge upstream phobos e6907ff3e.

[Bug d/98058] libphobos: Support building on *-*-darwin*

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:6eae7549b8a350b92435be904efed195bd190bae

commit r11-8248-g6eae7549b8a350b92435be904efed195bd190bae
Author: Iain Buclaw 
Date:   Mon Apr 19 14:48:32 2021 +0200

libphobos: Add Thread/Fiber support code for Darwin (PR98058)

libphobos/ChangeLog:

PR d/98058
* configure: Regenerate.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES_DARWIN): Add
core/sys/darwin/config.d
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/powerpc/switchcontext.S: Implement
fiber_switchContext for __MACH__.
* libdruntime/config/x86/switchcontext.S: Likewise.
* libdruntime/core/sys/darwin/config.d: New file.
* libdruntime/core/thread/fiber.d (Fiber.getThis): Mark noinline.
(UnsafeFiberMigration): Define for OSX/X86 and OSX/X86_64.
* libdruntime/core/thread/osthread.d (callWithStackShell): Add
inline
assembler implementation for X86, X86_64, PPC, and PPC64.
* libdruntime/core/thread/threadbase.d (ThreadBase.getThis): Mark
noinline.
* libdruntime/gcc/deh.d (FuncTable): Remove definition.
* m4/druntime/os.m4 (DRUNTIME_OS_MINFO_BRACKETING): Check for right
bracket symbol on darwin* targets.
* testsuite/libphobos.thread/fiber_guard_page.d: Update test to
support ucontext-based Fibers.

[Bug d/99794] libphobos: Support building on *-*mingw*

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:b66e72b43e1e8f402dc958ce3cca35f7c273340d

commit r11-8247-gb66e72b43e1e8f402dc958ce3cca35f7c273340d
Author: Iain Buclaw 
Date:   Mon Apr 19 14:36:14 2021 +0200

libphobos: Add D runtime support code for MinGW (PR99794)

libphobos/ChangeLog:

PR d/99794
* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Add
config/mingw/msvc.c on DRUNTIME_OS_MINGW.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/mingw/msvc.c: New file.
* libdruntime/config/mingw/switchcontext.S (fiber_switchContext):
Fix
function definition.
* libdruntime/gcc/deh.d (__gdc_personality_seh0): Fix call to
_GCC_specific_handler.
* libdruntime/gcc/gthread.d (__gthread_once_t): Fix definition.
* libdruntime/gcc/unwind/generic.d (_GCC_specific_handler): Fix
declaration.
* libdruntime/rt/dmain2.d (rt_loadLibrary): Remove function.
(rt_loadLibraryW): Remove function.
(initLibrary): Remove function.
(rt_unloadLibrary): Remove function.

[Bug d/99691] OpenBSD support for GDC

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99691

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:d86e60855f05a0e493f8362c12bfd40d5432d337

commit r11-8246-gd86e60855f05a0e493f8362c12bfd40d5432d337
Author: Iain Buclaw 
Date:   Mon Apr 19 14:23:00 2021 +0200

libphobos: Add section support code for OpenBSD (PR99691)

libphobos/ChangeLog:

PR d/99691
* configure: Regenerate.
* libdruntime/config/common/threadasm.S: Add __OpenBSD__.
* libdruntime/gcc/backtrace.d: Import core.sys.openbsd.dlfcn on
OpenBSD platforms.
* libdruntime/gcc/sections/elf.d (SharedElf): Define on OpenBSD.
(linkMapForHandle): Implement for OpenBSD.
(exeLinkMap): Remove.
(getDependencies): Adjust dlpi_addr on OpenBSD.
(handleForName): Implement for OpenBSD.
(IterateManually): Define on OpenBSD.
* libdruntime/gcc/sections/package.d (SectionsElf): Define on
OpenBSD.
* m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_ATOMIC): Test for
enable_libatomic.
(DRUNTIME_LIBRARIES_BACKTRACE): Test for enable_libbacktrace.

[Bug debug/100148] [10/11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.4
   Last reconfirmed||2021-04-19
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r10-7268-g529ea7d9596b26ba103578eeab448e9862a2d2c5

[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

https://gcc.gnu.org/g:3bffc4b37e85c7f6092dfb0fbe4067d268e97b46

commit r11-8245-g3bffc4b37e85c7f6092dfb0fbe4067d268e97b46
Author: Richard Earnshaw 
Date:   Mon Apr 19 16:56:31 2021 +0100

arm: partial revert of r11-8168 [PR100067]

This is a partial revert of r11-8168.  The overall purpose of the
commit is retained (to fix a bogus warning when -mfpu= is
used in combination with eg -mcpu=neoverse-v1), but it removes the
hunk that changed the subsequent feature bits for features of a
simd/fp unit that cannot be described by -mfpu.  While I still think
that is the correct direction of travel, it's somewhat disruptive and
not appropriate for late stage4.  I'll revisit for gcc-12.

gcc:
PR target/100067
* config/arm/arm.c (arm_configure_build_target): Do not strip
extended FPU/SIMD feature bits from the target ISA when -mfpu
is specified (partial revert of r11-8168).

Re: removing toxic emailers

[Christopher Dimech via Gcc]

> Sent: Tuesday, April 20, 2021 at 3:06 AM
> From: "Thomas Rodgers" 
> To: "Jonathan Wakely" 
> Cc: "Jonathan Wakely via Gcc" 
> Subject: Re: removing toxic emailers
>
> On 2021-04-18 23:29, Jonathan Wakely via Gcc wrote:
> 
> > On Mon, 19 Apr 2021, 02:41 Frosku, wrote:
> > 
> > On Sun Apr 18, 2021 at 9:22 PM BST, Alexandre Oliva via Gcc wrote: 
> > That's why it's best to dissent politely, lest they incorrectly 
> > conclude
> > their opinions are consensual, or majoritary, just because they've
> > driven dissenters into silence.
> > The problem is, Alex, that the trolls mostly haven't been on the 
> > dissenting
> > side. All of the childish namecalling -- "jerks", "trolls", "crazies" 
> > --
> > and the insinuations that our voices aren't worth listening to because 
> > we
> > don't get paid $250,000 a year by Google to contribute to GCC all day 
> > are
> > coming from the pro-forking side.
> 
> Google doesn't pay anybody to work on GCC all day. You know nothing 
> about
> GCC or the "problems" you're complaining about. Your input to this
> conversation is not constructive.
> 
> > Once upon a time, free software developers understood that users' 
> > opinions
> > were as valid as contributor's opinions.
> 
> That depends on the user.
> 
> Once upon a time, free software's developers *were* it's primary users, 
> i.e. they built the technology for themselves and made it freely 
> available in the hope that it would be useful to others. It's also the 
> case that the vast majority of GCC *current* users are not here making 
> proclamations about what GCC's project governance should be. Rather it's 
> a vocal and vanishingly small minority, who have contributed nothing of 
> value, code or insights, and continue to vocally do so. Many of GCC's 
> users are, however, watching in horror at the absolutely amateurish way 
> in which this is playing out and wondering if their long term commitment 
> should be to using this piece of software to build their 
> products/businesses.

Completely false.  Free software's developers were people who were disgusted
with the communities of software developers that started restricting users.
The Free Software Community wanted software that they could use and modify
code for any purpose, notwithstanding any prohibition other developers 
wanted to impose on them.

The hackers of the 70s and 80s who transformed computing and the early 
internet were known for their wit.  This included using a playboy photo
of Lena Söderberg for image processing.  They had got tired of the 
usually dull test images used at conferences.  She rapidly became 
the First Lady of Computing.  Many were very happy to meet her in person
and ask her an autograph.  n 1997, Forsén worked for a government agency
supervising  disabled employees who archived data using computers and
scanners.  In 2015, she was guest of honor at the banquet of IEEE, 
delivering a speech, and chairing the best paper award ceremony.

Those were exciting times, but by now government-sepported and
corporation-supported organizations have caught up; what was once
a liberating technology has become a conduit for surveillance and
manipulation.  

Even a chimp can write code.  So I give the reply attributed to 
Eric Raymond, after Microsoft offerred him a job.

I'd thank you for your offer of employment at Microsoft, except
that it indicates that either you or your research team (or both)
couldn't get a clue if it were pounded into you with baseball bats.
What were you going to do with the rest of your afternoon, offer jobs
to Richard Stallman and Linus Torvalds?  Or were you going to stick to
something easier, like talking Pope Benedict into presiding at a
Satanist orgy? - Eric Raymond

There was a time when I felt too much at odds with Eric, but today
he has became a friend.

[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative

[spamandnoise at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137

--- Comment #4 from Moritz Beutel  ---
Interesting. I had figured that the test case could probably be reduced
further, but I didn't try because the bug appeared so brittle. Slightly
changing seemingly unrelated details made it vanish:

-
// line 10:
if ( _size != 0 && _data == nullptr ) throw 42;  // bug
//if ( _size != 0 && _data == nullptr ) throw 42;  // no bug

// line 23:
size_t string_length( char const * ptr, size_t max = (size_t) -1 )  // bug
size_t string_length( char const * ptr, size_t max = (size_t) -2 )  // no bug

// line 26:
while ( len < max && ptr[len] )  // bug
while ( ptr[len] )  // no bug

-

Link for experimentation: https://gcc.godbolt.org/z/af8P7v64T

[PATCH V7 5/7] CTF/BTF testsuites

[Jose E. Marchesi via Gcc-patches]

This commit adds a new testsuite for the CTF debug format.

2021-04-14  Indu Bhagat  
David Faust  

gcc/testsuite/

* lib/gcc-dg.exp (gcc-dg-frontend-supports-ctf): New procedure.
(gcc-dg-debug-runtest): Add -gctf support.
* gcc.dg/debug/btf/btf-1.c: New test.
* gcc.dg/debug/btf/btf-2.c: Likewise.
* gcc.dg/debug/btf/btf-anonymous-struct-1.c: Likewise.
* gcc.dg/debug/btf/btf-anonymous-union-1.c: Likewise.
* gcc.dg/debug/btf/btf-array-1.c: Likewise.
* gcc.dg/debug/btf/btf-bitfields-1.c: Likewise.
* gcc.dg/debug/btf/btf-bitfields-2.c: Likewise.
* gcc.dg/debug/btf/btf-bitfields-3.c: Likewise.
* gcc.dg/debug/btf/btf-cvr-quals-1.c: Likewise.
* gcc.dg/debug/btf/btf-enum-1.c: Likewise.
* gcc.dg/debug/btf/btf-forward-1.c: Likewise.
* gcc.dg/debug/btf/btf-function-1.c: Likewise.
* gcc.dg/debug/btf/btf-function-2.c: Likewise.
* gcc.dg/debug/btf/btf-int-1.c: Likewise.
* gcc.dg/debug/btf/btf-pointers-1.c: Likewise.
* gcc.dg/debug/btf/btf-struct-1.c: Likewise.
* gcc.dg/debug/btf/btf-typedef-1.c: Likewise.
* gcc.dg/debug/btf/btf-union-1.c: Likewise.
* gcc.dg/debug/btf/btf-variables-1.c: Likewise.
* gcc.dg/debug/btf/btf.exp: Likewise.
* gcc.dg/debug/ctf/ctf-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-anonymous-struct-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-anonymous-union-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-array-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-array-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-array-3.c: Likewise.
* gcc.dg/debug/ctf/ctf-array-4.c: Likewise.
* gcc.dg/debug/ctf/ctf-attr-mode-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-attr-used-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-bitfields-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-bitfields-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-bitfields-3.c: Likewise.
* gcc.dg/debug/ctf/ctf-bitfields-4.c: Likewise.
* gcc.dg/debug/ctf/ctf-complex-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-cvr-quals-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-cvr-quals-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-cvr-quals-3.c: Likewise.
* gcc.dg/debug/ctf/ctf-cvr-quals-4.c: Likewise.
* gcc.dg/debug/ctf/ctf-enum-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-enum-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-file-scope-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-float-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-forward-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-forward-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-func-index-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-function-pointers-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-function-pointers-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-function-pointers-3.c: Likewise.
* gcc.dg/debug/ctf/ctf-functions-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-int-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-objt-index-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-pointers-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-pointers-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-preamble-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-skip-types-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-skip-types-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-skip-types-3.c: Likewise.
* gcc.dg/debug/ctf/ctf-skip-types-4.c: Likewise.
* gcc.dg/debug/ctf/ctf-skip-types-5.c: Likewise.
* gcc.dg/debug/ctf/ctf-skip-types-6.c: Likewise.
* gcc.dg/debug/ctf/ctf-str-table-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-struct-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-struct-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-struct-array-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-struct-pointer-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-struct-pointer-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-typedef-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-typedef-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-typedef-3.c: Likewise.
* gcc.dg/debug/ctf/ctf-typedef-struct-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-typedef-struct-2.c: Likewise.
* gcc.dg/debug/ctf/ctf-typedef-struct-3.c: Likewise.
* gcc.dg/debug/ctf/ctf-union-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-variables-1.c: Likewise.
* gcc.dg/debug/ctf/ctf-variables-2.c: Likewise.
* gcc.dg/debug/ctf/ctf.exp: Likewise.
---
 gcc/testsuite/gcc.dg/debug/btf/btf-1.c|  6 ++
 gcc/testsuite/gcc.dg/debug/btf/btf-2.c| 10 +++
 .../gcc.dg/debug/btf/btf-anonymous-struct-1.c | 23 ++
 .../gcc.dg/debug/btf/btf-anonymous-union-1.c  | 23 ++
 gcc/testsuite/gcc.dg/debug/btf/btf-array-1.c  | 31 +++
 .../gcc.dg/debug/btf/btf-bitfields-1.c| 34 
 .../gcc.dg/debug/btf/btf-bitfields-2.c| 26 ++
 .../gcc.dg/debug/btf/btf-bitfields-3.c| 43 ++
 

[PATCH V7 6/7] CTF/BTF documentation

[Jose E. Marchesi via Gcc-patches]

This commit documents the new command line options introduced by the
CTF and BTF debug formats.

2021-04-14  Indu Bhagat  

* doc/invoke.texi: Document the CTF and BTF debug info options.
---
 gcc/doc/invoke.texi | 20 
 1 file changed, 20 insertions(+)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8b70fdf580d..67e9956f0bf 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -462,6 +462,7 @@ Objective-C and Objective-C++ Dialects}.
 @item Debugging Options
 @xref{Debugging Options,,Options for Debugging Your Program}.
 @gccoptlist{-g  -g@var{level}  -gdwarf  -gdwarf-@var{version} @gol
+-gbtf -gctf  -gctf@var{level} @gol
 -ggdb  -grecord-gcc-switches  -gno-record-gcc-switches @gol
 -gstabs  -gstabs+  -gstrict-dwarf  -gno-strict-dwarf @gol
 -gas-loc-support  -gno-as-loc-support @gol
@@ -9654,6 +9655,25 @@ other DWARF-related options such as
 @option{-fno-dwarf2-cfi-asm}) retain a reference to DWARF Version 2
 in their names, but apply to all currently-supported versions of DWARF.
 
+@item -gbtf
+@opindex gbtf
+Request BTF debug information.
+
+@item -gctf
+@itemx -gctf@var{level}
+@opindex gctf
+Request CTF debug information and use level to specify how much CTF debug
+information should be produced.  If -gctf is specified without a value for
+level, the default level of CTF debug information is 2.
+
+Level 0 produces no CTF debug information at all.  Thus, -gctf0 negates -gctf.
+
+Level 1 produces CTF information for tracebacks only.  This includes callsite
+information, but does not include type information.
+
+Level 2 produces type information for entities (functions, data objects etc.)
+at file-scope or global-scope only.
+
 @item -gstabs
 @opindex gstabs
 Produce debugging information in stabs format (if that is supported),
-- 
2.25.0.2.g232378479e

[PATCH V7 7/7] Enable BTF generation in the BPF backend

[Jose E. Marchesi via Gcc-patches]

This patch changes the BPF GCC backend in order to use the DWARF debug
hooks and therefore enables the user to generate BTF debugging
information with -gbtf.  Generating BTF is crucial when compiling BPF
programs, since the CO-RE (compile-once, run-everwhere) mechanism
used by the kernel BPF loader relies on it.

Note that since in eBPF it is not possible to unwind frames due to the
restrictive nature of the target architecture, we are disabling the
generation of CFA in this target.

2021-04-14  David Faust 

* config/bpf/bpf.c (bpf_expand_prologue): Do not mark insns as
frame related.
(bpf_expand_epilogue): Likewise.
* config/bpf/bpf.h (DWARF2_FRAME_INFO): Define to 0.
Do not define DBX_DEBUGGING_INFO.
---
 gcc/config/bpf/bpf.c |  4 
 gcc/config/bpf/bpf.h | 12 ++--
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index 126d4a2798d..e635f9edb40 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -349,7 +349,6 @@ bpf_expand_prologue (void)
  hard_frame_pointer_rtx,
  fp_offset - 8));
  insn = emit_move_insn (mem, gen_rtx_REG (DImode, regno));
- RTX_FRAME_RELATED_P (insn) = 1;
  fp_offset -= 8;
}
}
@@ -364,7 +363,6 @@ bpf_expand_prologue (void)
 {
   insn = emit_move_insn (stack_pointer_rtx,
 hard_frame_pointer_rtx);
-  RTX_FRAME_RELATED_P (insn) = 1;
 
   if (size > 0)
{
@@ -372,7 +370,6 @@ bpf_expand_prologue (void)
 gen_rtx_PLUS (Pmode,
   stack_pointer_rtx,
   GEN_INT (-size;
- RTX_FRAME_RELATED_P (insn) = 1;
}
 }
 }
@@ -412,7 +409,6 @@ bpf_expand_epilogue (void)
  hard_frame_pointer_rtx,
  fp_offset - 8));
  insn = emit_move_insn (gen_rtx_REG (DImode, regno), mem);
- RTX_FRAME_RELATED_P (insn) = 1;
  fp_offset -= 8;
}
}
diff --git a/gcc/config/bpf/bpf.h b/gcc/config/bpf/bpf.h
index 9e2f5260900..ef0123b56a6 100644
--- a/gcc/config/bpf/bpf.h
+++ b/gcc/config/bpf/bpf.h
@@ -235,17 +235,9 @@ enum reg_class
 
 / Debugging Info /
 
-/* We cannot support DWARF2 because of the limitations of eBPF.  */
+/* In eBPF it is not possible to unwind frames. Disable CFA.  */
 
-/* elfos.h insists in using DWARF.  Undo that here.  */
-#ifdef DWARF2_DEBUGGING_INFO
-# undef DWARF2_DEBUGGING_INFO
-#endif
-#ifdef PREFERRED_DEBUGGING_TYPE
-# undef PREFERRED_DEBUGGING_TYPE
-#endif
-
-#define DBX_DEBUGGING_INFO
+#define DWARF2_FRAME_INFO 0
 
 / Stack Layout and Calling Conventions.  */
 
-- 
2.25.0.2.g232378479e

[PATCH V7 3/7] dejagnu: modularize gcc-dg-debug-runtest a bit

[Jose E. Marchesi via Gcc-patches]

Move some functionality into a procedure of its own. This is only so that when
the patch for ctf comes along, the gcc-dg-debug-runtest procedure looks bit
more uniform.

gcc/testsuite/ChangeLog:

* lib/gcc-dg.exp (gcc-dg-target-supports-debug-format): New procedure.
---
 gcc/testsuite/lib/gcc-dg.exp | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index e48a184f991..a2b1c6436ab 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -621,18 +621,27 @@ proc gcc-dg-runtest { testcases flags default-extra-flags 
} {
 }
 }
 
-proc gcc-dg-debug-runtest { target_compile trivial opt_opts testcases } {
+# Check if the target system supports the debug format
+proc gcc-dg-target-supports-debug-format { target_compile trivial type } {
 global srcdir subdir
 
+set comp_output [$target_compile \
+   "$srcdir/$subdir/$trivial" "trivial.S" assembly \
+   "additional_flags=$type"]
+if { ! [string match "*: target system does not support the * debug 
format*" \
+   $comp_output] } {
+   remove-build-file "trivial.S"
+   return 1
+}
+return 0
+}
+
+proc gcc-dg-debug-runtest { target_compile trivial opt_opts testcases } {
 if ![info exists DEBUG_TORTURE_OPTIONS] {
set DEBUG_TORTURE_OPTIONS ""
foreach type {-gdwarf-2 -gstabs -gstabs+ -gxcoff -gxcoff+} {
-   set comp_output [$target_compile \
-   "$srcdir/$subdir/$trivial" "trivial.S" assembly \
-   "additional_flags=$type"]
-   if { ! [string match "*: target system does not support the * debug 
format*" \
-   $comp_output] } {
-   remove-build-file "trivial.S"
+   if [expr [gcc-dg-target-supports-debug-format \
+ $target_compile $trivial $type]] {
foreach level {1 "" 3} {
if { ($type == "-gdwarf-2") && ($level != "") } {
lappend DEBUG_TORTURE_OPTIONS [list "${type}" 
"-g${level}"]
-- 
2.25.0.2.g232378479e

[PATCH V7 2/7] dwarf: new dwarf_debuginfo_p predicate

[Jose E. Marchesi via Gcc-patches]

This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.

2021-04-14  Indu Bhagat  

gcc/ChangeLog

* flags.h (dwarf_debuginfo_p): New function declaration.
* opts.c (dwarf_debuginfo_p): New function definition.
* config/c6x/c6x.c (c6x_output_file_unwind): Likewise.
* dwarf2cfi.c (cfi_label_required_p): Likewise.
(dwarf2out_do_frame): Likewise.
* final.c (dwarf2_debug_info_emitted_p): Likewise.
(final_scan_insn_1): Likewise.
* targhooks.c (default_debug_unwind_info): Likewise.
* toplev.c (process_options): Likewise.

gcc/c-family/ChangeLog

* c-lex.c (init_c_lex): Use dwarf_debuginfo_p.
---
 gcc/c-family/c-lex.c |  4 ++--
 gcc/config/c6x/c6x.c |  3 +--
 gcc/dwarf2cfi.c  |  9 -
 gcc/final.c  | 15 ++-
 gcc/flags.h  |  3 +++
 gcc/opts.c   |  8 
 gcc/targhooks.c  |  2 +-
 gcc/toplev.c |  6 ++
 8 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index 6374b72ed2d..5174b22c303 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "stor-layout.h"
 #include "c-pragma.h"
 #include "debug.h"
+#include "flags.h"
 #include "file-prefix-map.h" /* remap_macro_filename()  */
 #include "langhooks.h"
 #include "attribs.h"
@@ -87,8 +88,7 @@ init_c_lex (void)
 
   /* Set the debug callbacks if we can use them.  */
   if ((debug_info_level == DINFO_LEVEL_VERBOSE
-   && (write_symbols == DWARF2_DEBUG
-  || write_symbols == VMS_AND_DWARF2_DEBUG))
+   && dwarf_debuginfo_p ())
   || flag_dump_go_spec != NULL)
 {
   cb->define = cb_define;
diff --git a/gcc/config/c6x/c6x.c b/gcc/config/c6x/c6x.c
index f9ad1e5f6c5..a10e2f8d662 100644
--- a/gcc/config/c6x/c6x.c
+++ b/gcc/config/c6x/c6x.c
@@ -439,8 +439,7 @@ c6x_output_file_unwind (FILE * f)
 {
   if (flag_unwind_tables || flag_exceptions)
{
- if (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG)
+ if (dwarf_debuginfo_p ())
asm_fprintf (f, "\t.cfi_sections .debug_frame, .c6xabi.exidx\n");
  else
asm_fprintf (f, "\t.cfi_sections .c6xabi.exidx\n");
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 362ff3fdac2..c27ac1960b0 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -39,7 +39,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "expr.h"  /* init_return_column_size */
 #include "output.h"/* asm_out_file */
 #include "debug.h" /* dwarf2out_do_frame, dwarf2out_do_cfi_asm */
-
+#include "flags.h" /* dwarf_debuginfo_p */
 
 /* ??? Poison these here until it can be done generically.  They've been
totally replaced in this file; make sure it stays that way.  */
@@ -2289,8 +2289,7 @@ cfi_label_required_p (dw_cfi_ref cfi)
 
   if (dwarf_version == 2
   && debug_info_level > DINFO_LEVEL_TERSE
-  && (write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG))
+  && dwarf_debuginfo_p ())
 {
   switch (cfi->dw_cfi_opc)
{
@@ -3557,9 +3556,9 @@ bool
 dwarf2out_do_frame (void)
 {
   /* We want to emit correct CFA location expressions or lists, so we
- have to return true if we're going to output debug info, even if
+ have to return true if we're going to generate debug info, even if
  we're not going to output frame or unwind info.  */
-  if (write_symbols == DWARF2_DEBUG || write_symbols == VMS_AND_DWARF2_DEBUG)
+  if (dwarf_debuginfo_p ())
 return true;
 
   if (saved_do_cfi_asm > 0)
diff --git a/gcc/final.c b/gcc/final.c
index daae115fef5..cae692062b4 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1442,7 +1442,8 @@ asm_str_count (const char *templ)
 static bool
 dwarf2_debug_info_emitted_p (tree decl)
 {
-  if (write_symbols != DWARF2_DEBUG && write_symbols != VMS_AND_DWARF2_DEBUG)
+  /* When DWARF2 debug info is not generated internally.  */
+  if (!dwarf_debuginfo_p ())
 return false;
 
   if (DECL_IGNORED_P (decl))
@@ -2330,10 +2331,8 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int 
optimize_p ATTRIBUTE_UNUSED,
  break;
 
case NOTE_INSN_BLOCK_BEG:
- if (debug_info_level == DINFO_LEVEL_NORMAL
- || debug_info_level == DINFO_LEVEL_VERBOSE
- || write_symbols == DWARF2_DEBUG
- || write_symbols == VMS_AND_DWARF2_DEBUG
+ if (debug_info_level >= DINFO_LEVEL_NORMAL
+ || dwarf_debuginfo_p ()
  || write_symbols == VMS_DEBUG)
{
  int n = BLOCK_NUMBER (NOTE_BLOCK (insn));
@@ -2368,10 +2367,8 @@ final_scan_insn_1 (rtx_insn *insn, FILE *file, int 
optimize_p ATTRIBUTE_UNUSED,
case NOTE_INSN_BLOCK_END:
  maybe_output_next_view (seen);
 
- if 

[PATCH V7 1/7] dwarf: add a dwarf2int.h internal interface

[Jose E. Marchesi via Gcc-patches]

This patch introduces a dwarf2int.h header, to be used by code that
needs access to the internal DIE structures and their attributes.

The following functions which were previously defined as static in
dwarf2out.c are now non-static, and extern prototypes for them have
been added to dwarf2int.h:

- get_AT
- AT_int
- get_AT_ref
- get_AT_string
- get_AT_class
- AT_unsigned
- get_AT_unsigned
- get_AT_flag
- add_name_attribute
- new_die_raw
- base_type_die
- lookup_decl_die
- get_AT_file

Note how this patch doens't change the names of these functions to
avoid a massive renaming in dwarf2out.c, but n the future we probably
want these functions to sport a dw_* prefix.

Also, some type definitions have been moved from dwarf2out.c to
dwarf2int.h:

- dw_attr_node
- struct dwarf_file_data

Finally, three new accessor functions have been added to dwarf2out.c
with prototypes in dwarf2int.h:

- dw_get_die_child
- dw_get_die_sib
- dw_get_die_tag

2021-04-14  Jose E. Marchesi  

* dwarf2int.h: New file.
* dwarf2out.c (get_AT): Function is no longer static.
(get_AT_string): Likewise.
(get_AT_flag): Likewise.
(get_AT_unsigned): Likewise.
(get_AT_ref): Likewise.
(new_die_raw): Likewise.
(lookup_decl_die): Likewise.
(base_type_die): Likewise.
(add_name_attribute): Likewise.
(dw_get_die_tag): New function.
(dw_get_die_child): Likewise.
(dw_get_die_sib): Likewise.
Include dwarf2int.h.
* gengtype.c: add dwarf2int.h to open_base_files.
* Makefile.in (GTFILES): Add dwarf2int.h.
---
 gcc/Makefile.in |  1 +
 gcc/dwarf2int.h | 67 +
 gcc/dwarf2out.c | 79 -
 gcc/gengtype.c  |  6 ++--
 4 files changed, 109 insertions(+), 44 deletions(-)
 create mode 100644 gcc/dwarf2int.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 8a5fb3fd99c..e464e8c65c5 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2653,6 +2653,7 @@ GTFILES = $(CPPLIB_H) $(srcdir)/input.h 
$(srcdir)/coretypes.h \
   $(srcdir)/ipa-modref.h $(srcdir)/ipa-modref.c \
   $(srcdir)/ipa-modref-tree.h \
   $(srcdir)/signop.h \
+  $(srcdir)/dwarf2int.h \
   $(srcdir)/dwarf2out.h \
   $(srcdir)/dwarf2asm.c \
   $(srcdir)/dwarf2cfi.c \
diff --git a/gcc/dwarf2int.h b/gcc/dwarf2int.h
new file mode 100644
index 000..f49f51d957b
--- /dev/null
+++ b/gcc/dwarf2int.h
@@ -0,0 +1,67 @@
+/* Prototypes for functions manipulating DWARF2 DIEs.
+   Copyright (C) 2021 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* This file contains prototypes for functions defined in dwarf2out.c.  It is
+   intended to be included in source files that need some internal knowledge of
+   the GCC dwarf structures.  */
+
+#ifndef GCC_DWARF2INT_H
+#define GCC_DWARF2INT_H 1
+
+/* Each DIE attribute has a field specifying the attribute kind,
+   a link to the next attribute in the chain, and an attribute value.
+   Attributes are typically linked below the DIE they modify.  */
+
+typedef struct GTY(()) dw_attr_struct {
+  enum dwarf_attribute dw_attr;
+  dw_val_node dw_attr_val;
+}
+dw_attr_node;
+
+extern dw_attr_node *get_AT (dw_die_ref, enum dwarf_attribute);
+extern HOST_WIDE_INT AT_int (dw_attr_node *);
+extern unsigned HOST_WIDE_INT AT_unsigned (dw_attr_node *a);
+extern dw_die_ref get_AT_ref (dw_die_ref, enum dwarf_attribute);
+extern const char *get_AT_string (dw_die_ref, enum dwarf_attribute);
+extern enum dw_val_class AT_class (dw_attr_node *);
+extern unsigned HOST_WIDE_INT AT_unsigned (dw_attr_node *);
+extern unsigned get_AT_unsigned (dw_die_ref, enum dwarf_attribute);
+extern int get_AT_flag (dw_die_ref, enum dwarf_attribute);
+
+extern void add_name_attribute (dw_die_ref, const char *);
+
+extern dw_die_ref new_die_raw (enum dwarf_tag);
+extern dw_die_ref base_type_die (tree, bool);
+
+extern dw_die_ref lookup_decl_die (tree);
+
+extern dw_die_ref dw_get_die_child (dw_die_ref);
+extern dw_die_ref dw_get_die_sib (dw_die_ref);
+extern enum dwarf_tag dw_get_die_tag (dw_die_ref);
+
+/* Data about a single source file.  */
+struct GTY((for_user)) dwarf_file_data {
+  const char * filename;
+  int emitted_number;
+};
+
+extern struct dwarf_file_data *get_AT_file (dw_die_ref,
+   enum dwarf_attribute);
+
+#endif /* 

[PATCH V7 0/7] Support for the CTF and BTF debug formats

[Jose E. Marchesi via Gcc-patches]

[Changes from V6:
- Rebased to today's master.
- A GC related regression introduced in V5 has been fixed. This
  regression also uncovered a related bug that has been also fixed in
  this version.  Basically ctfc_types and ctfc_vars were being
  incorrectly collected and this was uncovered by the fact V6 moved
  the call of ctf_finalize from dwarf2out_early_finish to
  dwarf2out_finish.
- The patch `dwarf: new dwarf_debuginfo_p predicate' has been approved,
  but not yet applied upstream.
- This new version of the patch series is available in
  https://github.com/oracle/gcc branch oracle/ctf-v7]

Hi people!

Last year we submitted a first patch series introducing support for
the CTF debugging format in GCC [1].  We got a lot of feedback that
prompted us to change the approach used to generate the debug info,
and this patch series is the result of that.

This series also add support for the BTF debug format, which is needed
by the BPF backend (more on this below.)

This implementation works, but there are several points that need
discussion and agreement with the upstream community, as they impact
the way debugging options work.  We are also proposing a way to add
additional debugging formats in the future.  See below for more
details.

Finally, a patch makes the BPF GCC backend to use the DWARF debug
hooks in order to make -gbtf available to it.

[1] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-05/msg01297.html

About CTF
=

CTF is a debugging format designed in order to express C types in a
very compact way.  The key is compactness and simplicity.  For more
information see:

- CTF specification
  http://www.esperi.org.uk/~oranix/ctf/ctf-spec.pdf

- Compact C-Type support in the GNU toolchain (talk + slides)
  https://linuxplumbersconf.org/event/4/contributions/396/

- On type de-duplication in CTF (talk + slides)
  https://linuxplumbersconf.org/event/7/contributions/725/

About BTF
=

BTF is a debugging format, similar to CTF, that is used in the Linux
kernel as the debugging format for BPF programs.  From the kernel
documentation:

"BTF (BPF Type Format) is the metadata format which encodes the debug
 info related to BPF program/map. The name BTF was used initially to
 describe data types. The BTF was later extended to include function
 info for defined subroutines, and line info for source/line
 information."

Supporting BTF in GCC is important because compiled BPF programs
(which GCC supports as a target) require the type information in order
to be loaded and run in diverse kernel versions.  This mechanism is
known as CO-RE (compile-once, run-everywhere) and is described in the
"Update of the BPF support in the GNU Toolchain" talk mentioned below.

The BTF is documented in the Linux kernel documentation tree:
- linux/Documentation/bpf/btf.rst

CTF in the GNU Toolchain


During the last year we have been working in adding support for CTF to
several components of the GNU toolchain:

- binutils support is already upstream.  It supports linking objects
  with CTF information with full type de-duplication.

- GDB support is to be sent upstream very shortly.  It makes the
  debugger capable to use the CTF information whenever available.
  This is useful in cases where DWARF has been stripped out but CTF is
  kept.

- GCC support is being discussed and submitted in this series.

Overview of the Implementation
==

  dwarf2out.c

The enabled debug formats are hooked in dwarf2out_early_finish.

  dwarf2int.h

Internal interface that exports a few functions and data types
defined in dwarf2out.c.

  dwarf2ctf.c

Code that tranform the internal GCC DWARF DIEs into CTF container
structures.  This file uses the dwarf2int.h interface.

  ctfc.c
  ctfc.h

These two files implement the "CTF container", which is shared
among CTF and BTF, due to the many similarities between both
formats.

  ctfout.c

Code that emits assembler with the .ctf section data, from the CTF
container.

  btfout.c

Code that emits assembler with the .BTF section data, from the CTF
container.

>From debug hooks to debug formats
=

Our first attempt in adding CTF to GCC used the obvious approach of
adding a new set of debug hooks as defined in gcc/debug.h.

During our first interaction with the upstream community we were told
to _not_ use debug hooks, because these are to be obsoleted at some
point.  We were suggested to instead hook our handlers (which
processed type TREE nodes producing CTF types from them) somewhere
else.  So we did.

However at the time we were also facing the need to support BTF, which
is another type-related debug format needed by the BPF GCC backend.
Hooking here and there doesn't sound like such a good idea when it
comes to support several debug formats.

Therefore we thought about how to make GCC support diverse debugging
formats in a better way.  This led to a proposal we 

[Bug debug/100148] New: [10/11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100148

Bug ID: 100148
   Summary: [10/11 Regression] -fcompare-debug failure (length)
with -O2 -fno-dce -fno-tree-dce
-fno-tree-dominator-opts -fno-tree-sink
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 50630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50630=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts
-fno-tree-sink -fcompare-debug testcase.C 
x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure (length)

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-8244-20210419132718-g714bdc31b69-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-8244-20210419132718-g714bdc31b69-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210419 (experimental) (GCC)

Re: [PATCH] wwwdocs: Do not rewrite the page titles

[Richard Kenner via Gcc-patches]

> I don't see why we should have to "comply with the GNU style" if we're
> truly an independent project run by the GCC developers and aided by
> the steering committee.

I think it critical than any code have *some* style guidelines.  If you
don't like the GNU coding convention, which do you propose instead and
how do you propose to convert the existing code to that style?

Re: [PATCH] PR tree-optimization/100081 - Limit depth of logical expression windback.

[Andrew MacLeod via Gcc-patches]

On 4/19/21 3:40 AM, Jakub Jelinek wrote:

On Sun, Apr 18, 2021 at 08:11:21PM -0400, Andrew MacLeod via Gcc-patches wrote:

--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -29,6 +29,36 @@ along with GCC; see the file COPYING3.  If not see
  #include "gimple-pretty-print.h"
  #include "gimple-range.h"
  
+// Limit the nested depth thru logical expressions which GORI will build

+// def chains.
+#define LOGICAL_LIMIT  6

Such limits should be in params.def so that users can override them.


+// Return TRUE if GS is a logical && or || expression.
+
+static inline bool
+is_gimple_logical_p (const gimple *gs)
+{
+  // Look for boolean and/or condition.
+  if (gimple_code (gs) == GIMPLE_ASSIGN)

   if (is_gimple_assign (gs))

is the normal spelling of this check.

But more importantly, isn't 6 too low for logicals, and wouldn't it be
better to put a cap not on the number of seen logicals, but on how many
SSA_NAMEs are handled in a query?  Because it is easy to construct
testcases where the logical limit would not trigger but the operands
of comparisons used in logicals would be thousands of arithmetic/bitwise
statements etc.  And it isn't just artificial, we have various examples
of generated tests in bugzilla that typically can't be compiled in
reasonable time at -O2 and need to use -O1 and have huge basic blocks with
very deep chains.


The chains aren't typically  the issue, its a linear calculation.. I 
gave a small example in the PR of why the logical expressions cause an 
exponential growth.


Most values are only ever calculated once and are cached.  the only time 
we do this backward calculation is when a range is changed by the 
condition at the bottom of a block, and used outside the block and 
therefore the edge will have a different value than the range in the block.


I dont think 6 logicals is too low... in fact 4 is probably plenty 
99.% of the time.  This is not during a forward walk...  we will 
walk thru every logical forward and calculate ranges as appropriate.. 
This is only when trying to determine a refined range on an edge. so for 
example


 [local count: 1073741823]:
  _1 = x_20(D) == 10;
  _2 = y_21(D) == 10;
  _3 = _1 & _2;
  _4 = x_20(D) == 20;
  _5 = y_21(D) == 20;
  _6 = _4 & _5;
  _7 = x_20(D) == 30;
  _8 = y_21(D) == 30;
  _9 = _7 & _8;
  _10 = x_20(D) == 40;
  _11 = y_21(D) == 40;
  _12 = _10 & _11;
  _13 = x_20(D) == 50;
  _14 = y_21(D) == 50;
  _15 = _13 & _14;
  _16 = x_20(D) == 60;
  _17 = y_21(D) == 60;
  _18 = _16 & _17;
  _19 = _3 | _6   // depth 3
  _20 = _9 | _12 // depth 3
  _21 = _15 | _18    // depth 2
  _22 = _19 | _20    // depth 2
  _23 = _21 | _22    // depth 1

  if (_23 != 0)
    goto ; [50.00%]
  else
    goto ; [50.00%]

We can still look back thru these conditions and could find a range for 
x_20 or y_21 of [10,10][20,20][30,30][40,40],[50,50][60,60] because the 
logical nesting depth never exceeds 3 when walking from back from the 
branch to the use of x_20 or y_21.


we still evaluate everything walking forward.. ie we get global ranges 
for everything in the block and evaluate the final condition based on 
the block values.


If we added a whole bunch more logicals, we'd still do that forward 
processing in EVRP.  This change would then say, you know, its not worth 
trying to calculate back thru that many logical expressions, so we'll 
just say x_20 and y_21 are whatever their range on entry to the block 
was  rather than trying to refine it on an outgoing edge. so we would 
get less rpecise ranges for x_20 and y_21 on these edges then.


Sure, a similar argument can be made that if we go through a long list 
of ssa_names in a straight calculation, the odds of getting a refined 
range decrease... but for example:


a_2 = a_1 + 1
a_3 = a_2 + 1
<...>
a_44 = a_43 + 1
if (a_44 > 100)
  goto 

  if (a_1 > 50)

asking for the range of a_1 in bb_7 causes a lookup to say "a_1 is an 
export and can be calculated on the edge 2->7", what is it?  We will 
walk back from a_44 > 100, evaluating those names based on the edge 
value of a_44  [101, +INF]  until we get to  a_2 = a_1 + 1...  a that 
point, a_2 will have an edge range of [58, +INF - 42]  or something to 
that effect, and it will return the evaluated a_2 range on the edge as 
[57, +INF - 43] , and we can fold the stmt.


We only do that once. bb_7 will have the value of a_1 cached since it 
was explicitly requested.    These really long back calculations don't 
really happen that often, so I havent seen the need to throttle them.  
We also don't cache the intervening values (a_3 thru a_44) ... Odds are 
they don't get asked for outside the block, so it would just be a memory 
waste.. we only ever cache whats actually asked for.


So a lot depends on whats actually requested.. most of the time, these 
really long blocks do not have many, if any, uses outside the block.. in 
which case we will never even do a wind back range request.  IF we find 
such cases, then maybe a limit is 

[comitted] arm: partial revert of r11-8168 [PR100067]

[Richard Earnshaw via Gcc-patches]

From: Richard Earnshaw 

This is a partial revert of r11-8168.  The overall purpose of the
commit is retained (to fix a bogus warning when -mfpu= is
used in combination with eg -mcpu=neoverse-v1), but it removes the
hunk that changed the subsequent feature bits for features of a
simd/fp unit that cannot be described by -mfpu.  While I still think
that is the correct direction of travel, it's somewhat disruptive and
not appropriate for late stage4.  I'll revisit for gcc-12.

gcc:
PR target/100067
* config/arm/arm.c (arm_configure_build_target): Do not strip
extended FPU/SIMD feature bits from the target ISA when -mfpu
is specified (partial revert of r11-8168).
---
 gcc/config/arm/arm.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 475fb0d827f..340f7c95d76 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3396,9 +3396,11 @@ arm_configure_build_target (struct arm_build_target *target,
   auto_sbitmap fpu_bits (isa_num_bits);
 
   arm_initialize_isa (fpu_bits, arm_selected_fpu->isa_bits);
-  /* Clear out ALL bits relating to the FPU/simd extensions, to avoid
-	 potentially invalid combinations later on that we can't match.  */
-  bitmap_and_compl (target->isa, target->isa, isa_all_fpbits);
+  /* This should clear out ALL bits relating to the FPU/simd
+	 extensions, to avoid potentially invalid combinations later on
+	 that we can't match.  At present we only clear out those bits
+	 that can be set by -mfpu.  This should be fixed in GCC-12.  */
+  bitmap_and_compl (target->isa, target->isa, isa_all_fpubits_internal);
   bitmap_ior (target->isa, target->isa, fpu_bits);
 }
 

[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #3 from Martin Sebor  ---
The warning bug was introduced in r262893 (GCC 10).  A trivial test case is:

$ cat a.c && gcc -O2 -S -Wall a.c
int f (long i)
{
  const char *p = "123";
  p += i;
  return p[-1];
}
a.c: In function ‘f’:
a.c:5:11: warning: array subscript -1 is outside array bounds of ‘char[4]’
[-Warray-bounds]
5 |   return p[-1];
  |  ~^~~~

This same thing is handled correctly elsewhere (e.h., -Wstringop_overflow) so
the ideal fix is to replace the warning code with the new pointer_query class.

[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100137

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to work||10.2.0
  Component|c++ |tree-optimization
 Status|UNCONFIRMED |NEW
Summary|-Werror=array-bounds false  |[10/11 Regression]
   |positive:"subscript -1 is   |-Warray-bounds false
   |outside array bounds"   |positive on varying offset
   ||plus negative
   Last reconfirmed||2021-04-19
  Known to fail||10.3.0, 11.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  The bug is caused by -Warray-bounds ignoring varying offsets
instead of setting the offset range to that of the referenced object. 
Bisection points to g:e7fd3b783238d034018443e43a58ff87908b4db6 but that just
exposed the underlying bug in the warning.  The test case triggers the false
positive in 10.3.0 and 11.0 but not in 10.2.0 or prior. 

int main ()
{
  ...
   [local count: 114863531]:
  # len_11 = PHI <18446744073709551615(3), len_23(4)>
  s ={v} {CLOBBER};
  s.first_ = 
  iftmp.0_13 =  + len_11;  <<< len_11:
VR_VARYING, iftmp.0_13 taken to point to 
  s.last_ = iftmp.0_13;
  _15 = len_11 != 0;
  MEM[(char &)iftmp.0_13 + 18446744073709551615] = 50;   <<< iftmp.0_13[-1] =
'2'; <<< -Warray-bounds
  hello ={v} {CLOBBER};
  s ={v} {CLOBBER};
  return 0;

}

[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs

[vries at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555

--- Comment #9 from Tom de Vries  ---
(In reply to Tom de Vries from comment #8)
> This fixes the hang:

This is a less intrusive solution, and is easier to transplant into
gomp_team_barrier_wait_cancel_end:
...
diff --git a/libgomp/config/nvptx/bar.c b/libgomp/config/nvptx/bar.c
index c5c2fa8829b..cb7b299c6a8 100644
--- a/libgomp/config/nvptx/bar.c
+++ b/libgomp/config/nvptx/bar.c
@@ -91,6 +91,9 @@ gomp_team_barrier_wait_end (gomp_barrier_t *bar,
gomp_barrier_state_t state)
{
  gomp_barrier_handle_tasks (state);
  state &= ~BAR_WAS_LAST;
+ if (team->task_count != 0)
+   __builtin_abort ();
+ bar->total = 1;
}
   else
{
@@ -157,6 +160,9 @@ gomp_team_barrier_wait_cancel_end (gomp_barrier_t *bar,
{
  gomp_barrier_handle_tasks (state);
  state &= ~BAR_WAS_LAST;
+ if (team->task_count != 0)
+   __builtin_abort ();
+ bar->total = 1;
}
   else
{
...

[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457

--- Comment #2 from Iain Buclaw  ---
Reduced test:
---
void main() { writef!"%s"; }
---

Any error that deals with a symbol that has a formatting string in it will
trigger a segmentation fault.

Re: removing toxic emailers

[Thomas Rodgers]

On 2021-04-18 23:29, Jonathan Wakely via Gcc wrote:


On Mon, 19 Apr 2021, 02:41 Frosku, wrote:

On Sun Apr 18, 2021 at 9:22 PM BST, Alexandre Oliva via Gcc wrote: 
That's why it's best to dissent politely, lest they incorrectly 
conclude

their opinions are consensual, or majoritary, just because they've
driven dissenters into silence.
The problem is, Alex, that the trolls mostly haven't been on the 
dissenting
side. All of the childish namecalling -- "jerks", "trolls", "crazies" 
--
and the insinuations that our voices aren't worth listening to because 
we
don't get paid $250,000 a year by Google to contribute to GCC all day 
are

coming from the pro-forking side.


Google doesn't pay anybody to work on GCC all day. You know nothing 
about

GCC or the "problems" you're complaining about. Your input to this
conversation is not constructive.

Once upon a time, free software developers understood that users' 
opinions

were as valid as contributor's opinions.


That depends on the user.

Once upon a time, free software's developers *were* it's primary users, 
i.e. they built the technology for themselves and made it freely 
available in the hope that it would be useful to others. It's also the 
case that the vast majority of GCC *current* users are not here making 
proclamations about what GCC's project governance should be. Rather it's 
a vocal and vanishingly small minority, who have contributed nothing of 
value, code or insights, and continue to vocally do so. Many of GCC's 
users are, however, watching in horror at the absolutely amateurish way 
in which this is playing out and wondering if their long term commitment 
should be to using this piece of software to build their 
products/businesses.

[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

--- Comment #6 from Jakub Jelinek  ---
LGTM.

[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc--netbsd |powerpc
   Last reconfirmed||2021-04-19
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

--- Comment #5 from Segher Boessenkool  ---
Created attachment 50629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50629=edit
Proposed simpler patch

A simpler patch.  I'll commit this later today (if no one stops me).

[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

--- Comment #4 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #1)
> e500 support had been moved to the powerpcspe target; so assuming power9 for
> -misel is correct.
> 
> e500mc support is still there though.

There never *was* separate e500 support in GCC!

[Bug target/100108] [10/11 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Indeed, several rs6000-cpus.def entries have MASK_ISEL:
RS6000_CPU ("8540", PROCESSOR_PPC8540, MASK_STRICT_ALIGN | MASK_ISEL)
RS6000_CPU ("8548", PROCESSOR_PPC8548, MASK_STRICT_ALIGN | MASK_ISEL)
RS6000_CPU ("e500mc", PROCESSOR_PPCE500MC, MASK_PPC_GFXOPT | MASK_ISEL)
RS6000_CPU ("e500mc64", PROCESSOR_PPCE500MC64,
MASK_POWERPC64 | MASK_PPC_GFXOPT | MASK_ISEL)
RS6000_CPU ("e5500", PROCESSOR_PPCE5500,
MASK_POWERPC64 | MASK_PPC_GFXOPT | MASK_ISEL)
RS6000_CPU ("e6500", PROCESSOR_PPCE6500, POWERPC_7400_MASK | MASK_POWERPC64
| MASK_MFCRF | MASK_ISEL)


So perhaps we should consider MASK_ISEL as power9 thing only for flags which
include power7-ish or later ISAs?
--- rs6000.c.jj42021-04-09 10:18:15.582266372 +0200
+++ rs6000.c2021-04-19 16:30:07.033208577 +0200
@@ -5766,6 +5766,9 @@ rs6000_machine_from_flags (void)

   /* Disable the flags that should never influence the .machine selection.  */
   flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT);
+  if ((flags & (ISA_3_1_MASKS_SERVER
+   & ~(ISA_2_5_MASKS_SERVER | MASK_ISEL))) == 0)
+flags &= ~MASK_ISEL;

   if ((flags & (ISA_3_1_MASKS_SERVER & ~ISA_3_0_MASKS_SERVER)) != 0)
 return "power10";

[Bug c++/92031] [9 Regression] Incorrect "taking address of r-value" error

[chip.kerchner at ibm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92031

Chip Kerchner  changed:

   What|Removed |Added

 CC||chip.kerchner at ibm dot com

--- Comment #5 from Chip Kerchner  ---
Please backport this fix into 9.4 or 9.5.

[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943

--- Comment #7 from Jonathan Wakely  ---
Implemented downstream:
https://gitlab.com/jonathan-wakely/gcc/-/commit/484308ad163862632ae7e710c5d909be385450aa

[Bug tree-optimization/100081] [11 Regression] Compile time hog in irange since r11-4135-ge864d395b4e862ce

[amacleod at redhat dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081

--- Comment #12 from Andrew Macleod  ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Macleod from comment #8)
> > 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.
> 
> Hmm, still the overall work should be linear to produce ranges for all
> of the SSA defs in this BB, no?  As heuristic you might want to avoid
> producing ranges for single-use defs, like those that are just used in
> another & or | combination?  Wrestrict should only be interested in
> ranges for the "tails" of this &| tree (for example _61 in _61 >= _3966).
> 

Since the direction is bottom up, it is no longer linear. This has probably
never been explain very well.  lets make up a simple example:

if (x > 2 && x < 10 || x == 15)
for unsigned x turns into:

_1 = x_8(D) + 4294967293;
_2 = _1 <= 6;
_3 = x_8(D) == 15;
_4 = _2 | _3;
if (_4 != 0)
  goto ; [INV]
else
  goto ; [INV]

and we can calculate the following ranges (note none of them are calculated in
advance, only if asked/required) :

2->3  (T) _4 :  bool [1, 1]
2->3  (T) x_8(D) :  unsigned int [3, 9][15, 15]
2->5  (F) _1 :  unsigned int [7, +INF]
2->5  (F) _2 :  bool [0, 0]
2->5  (F) _3 :  bool [0, 0]
2->5  (F) _4 :  bool [0, 0]
2->5  (F) x_8(D) :  unsigned int [0, 2][10, 14][16, +INF]

When a client asks for the range of x_8 on the true edge, we have to solve
[1,1] = _4 != 0, which in turn feeds back to the def of _4 as:
[1,1] = _2 | _3

There are 3 possible ways this branch can be taken..
a) _2 = [1, 1], _3 = [1, 1]
b) _2 = [0, 0], _3 = [1, 1]
c) _2 = [1, 1], _3 = [0, 0]

In order to calculate a precise range for x_8, we need to calculate the range
of x_8 for both possible values of _2 and _3  and combine them.. 

I wont trace the actual calculation for each one, but it boils down to
_2 = [0, 0] produces x_8 = ~[3, 9]
_2 = [1, 1] produces x_8 = [3, 9]
_3 = [0, 0] produces x_8 = ~[15, 15]
_3 = [1, 1] produces x_8 = [15, 15]

Then we combine them with the 2 possible combinations, and produce the final
range of unsigned int [3, 9][15, 15].

Once upon a time I tried to "simplify" this a couple of different ways, but in
more complex situations, it inevitably fails to produce the correct range.. so
instead, we simply do the calculations exactly as the statement requires and
combine them.

The logical OR spawned 4 requests for the range of x_8.. so when these logical
expressions feed each other, we get the exponential growth of computations.

The logical cache was suppose to resolve this by caching the true and false
values of x_8 for _2 and _3 eliminating the need to recalculate them.   More
complex cases with many ssa_names feeding through a boolean condition cause it
to not function well.


As for single use-use defs.. There is nothing special about them. We never
produce ranges for anything that is not used an an outgoing edge calculation,
regardless of how many uses there are.  Those are tagged and we simply use
their global value.

Furthermore, we never produce ranges for anything that isn't either explicitly
requested, or used in a calculation that affects an explicit request.

In this case for instance, I forget the name that restrict asked for, but lets
say it was  _3992.  we start at the bottom of the block and work back to the
definition of _3992.  During the evaluation, we go through many single-use
cases which we will need the ranges for as they feed the condition at the
bottom and may therefore affect the outcome.  Anything above _3992's def is
never evaluated.

Up until now, I haven't really throttled anything.. 

[Bug libstdc++/94080] -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080

--- Comment #4 from Bill Schmidt  ---
Thanks, Jonathan!

[Bug target/100075] [9/10 Regression] unneeded sign extension

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100075

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:714bdc31b69688ae2eaeb9807a48e0f101fecf4e

commit r11-8244-g714bdc31b69688ae2eaeb9807a48e0f101fecf4e
Author: Christophe Lyon 
Date:   Mon Apr 19 13:24:31 2021 +

aarch64: Fix up 2 other combine opt regressions vs. GCC8 [PR100075]

The testcase is endianness dependent and works only on little-endian.

2021-04-19  Christophe Lyon  

PR target/100075
gcc/testsuite/
* gcc.target/aarch64/pr100075.c: Add aarch64_little_endian
effective target.

Re: [PATCH] [OpenACC] Fix an ICE where a loop with GT condition is collapsed.

[Christophe Lyon via Gcc-patches]

On Mon, 19 Apr 2021 at 12:40, Tobias Burnus  wrote:
>
> On 19.04.21 11:25, Tobias Burnus wrote:
> > On 19.04.21 10:48, Christophe Lyon wrote:
> >> The new test generates an ICE on aarch64-linux-gnu in the gcc-10 branch:
> > Looks as someone (like me) should backport https://gcc.gnu.org/97880 /
> > r11-5489 to GCC 10.
> ("OpenACC: Fix integer-type issue with collapse/tile [PR97880]")
>
> Now backported to GCC 10 as
> r10-9716-gaf408874e3d94492ac08ba17462b3ff8ecb4d791, please confirm that
> it did fix your issue:
>

Yes, that works, thanks

Christophe

> >> /gcc/testsuite/c-c++-common/goacc/collapse-2.c: In function
> >> 'f5._omp_fn.0':
> >> /gcc/testsuite/c-c++-common/goacc/collapse-2.c:56:1: error: type
> >> mismatch in binary expression
> >> signed long
> >>
> >> long int
> >>
> >> int
> >>
> >> D.3972 = .tile.57 * .tile.59;
> >> during IPA pass: *free_lang_data
> Tobias
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
> Thürauf

Re: [PATCH] analyzer: enabling Modula-2 Storage/ALLOCATE/DEALLOCATE

[Gaius Mulley via Gcc-patches]

David Malcolm  writes:

> On Tue, 2021-04-13 at 10:52 +0100, Gaius Mulley wrote:
>>
>> Hello David and fellow GCC developers,
>>
>> [the proposed patches for GCC trunk are at the end of the email]
>>

Firstly many thanks for your excellent feedback.  Initially I thought
I'd post the latest version of patches which have taken on board the
issues and problems you identified - however due to the length of this
reply I think it better to post new patches separately.  Many new
tests, use of dg signatures, improved accuracy of token locations and
different heaps tracked in the new patch (to be emailed later).

> Excellent!  I'm glad you're enjoying it.
>
> Caveat: The last time I did any Modula-2 coding was a MUD I wrote at
> school, which I realize to my horror is now over 30 years ago; I wonder
> if the disks are still readable :)

ah yes oddly I did something rather similar post graduation
(multiplayer morloc tower clone).  I think it was partly inspired by
the elegant SYSTEM PROCESS primitives NEWPROCESS, IOTRANSFER and
TRANSFER which allow for a simple implementation of a multitasking
executive.

I've modified all the Modula-2 analyzer tests to use the dg
signatures as you suggested and added many new tests based on your
comments.  Many were the same test without using NEW to allocate
memory.  Most of which pass!  However I do get some failures in
particular:

Running 
/home/gaius/GM2/graft-combine/gm2-floppsie/gcc/testsuite/gm2/analyzer/fail/gm2-dg.exp
 ...
FAIL: gm2/analyzer/fail/globalnilderef.mod   -O   (test for warnings, line 17)
FAIL: gm2/analyzer/fail/globalnilderef.mod   -O   (test for errors, line 18)
FAIL: gm2/analyzer/fail/globalnilderef.mod   -O  (test for excess errors)

I've also added the ability to track different heaps (which was a
trivial change) but an improvement as it tracks allocation from
Storage and SysStorage.

$ cat globalnilderef.mod
MODULE globalnilderef ;

(* { dg-options "-fanalyzer" }  *)
(* { dg-do compile }  *)

FROM libc IMPORT printf ;

TYPE
   List = POINTER TO RECORD
value: CARDINAL ;
next : List ;
 END ;

VAR
   l: List ;
BEGIN
   l^.value := 1 ;   (* { dg-warning "runtime error will occur, if this pointer 
value 'l' is ever dereferenced it will cause an exception.*" }  *)
   printf ("value is: %d\n", l^.value)   (* { dg-error "runtime error will 
occur, if this pointer value 'l' is ever dereferenced it will cause an 
exception.*" }  *)
END globalnilderef.
$ gm2 -O2 -fanalyzer -c -g globalnilderef.mod
$ gm2 -O2 -fanalyzer -c -g -fdump-ipa-analyzer=stderr globalnilderef.mod

INTEGER _M2_globalnilderef_finish ()
{
   [local count: 1073741824]:
  return;
}


INTEGER _M2_globalnilderef_init ()
{
  struct
{
  CARDINAL value;
} * l.0_1;
  INTEGER _8;

   [local count: 1073741824]:
  l.0_1 = l;
  _T24 = l.0_1;
  l.0_1->value = 1;
  _T26 = l.0_1;
  _T28 = "value is: %d\n";
  _8 = printf ("value is: %d\n", 1);
  _T29 = _8;
  return;
}



>> $ cat badlistfree.mod
>> MODULE badlistfree ;
>>
>> FROM Storage IMPORT ALLOCATE, DEALLOCATE ;
>>
>> TYPE
>>list = POINTER TO RECORD
>> value: CARDINAL ;
>> next : list ;
>>  END ;
>> VAR
>>head: list ;
>>
>> PROCEDURE badfree (l: list) ;
>> BEGIN
>>DISPOSE (l) ;
>>WHILE l^.next # NIL DO
>>   l := l^.next ;
>>   DISPOSE (l)
>>END
>> END badfree ;
>>
>>
>> BEGIN
>>NEW (head) ;
>>badfree (head) ;
>> END badlistfree.
>> $ gm2 -g -c -fanalyzer badlistfree.mod
>> badlistfree.mod: In function ‘badfree’:
>> badlistfree.mod:16:24: warning: use after ‘DISPOSE’ of ‘l’ [CWE-416] [-
...
> Excellent.
>
> Do you actually need the NEW(head); to trigger the warning?

no - you're right it can be triggered without NEW (head).

> so if you're thinking about unit test coverage, it may be an idea to
> have both cases.

thanks for the steer - I've now included both cases for this and
other similar testcases.

> Your patch doesn't seem to have any test cases, but presumably that
> would be part of the gm2 frontend and thus would be merged with that,
> rather than as this patch.  I went poking around in your repo, and see:

> I don't see any DejaGnu directives on the files; should there be
> something like
>
>   (* dg-warning "use after 'DISPOSE' of 'l'" */
>
> on the pertinent line, or do your tests work a different way?

Thanks for the advice - I've now adopted the dg signatures in this
directory.

git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/testsuite/gm2/analyzer/fail

The fail directories for the remainder of the testsuite simply test
for any compiler exit (non zero) or any error message.  But I'll trawl
though these and migrate to the dg- style.

>> $ cat disposenoalloc.mod
>> MODULE disposenoalloc ;
>>
>> FROM Storage IMPORT ALLOCATE, DEALLOCATE ;
>> FROM SYSTEM IMPORT ADR ;
>>
>> TYPE
>>list = POINTER TO RECORD
>> value: CARDINAL ;
>>   

Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable

[Tobias Burnus]

Hi Paul,

On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote:

I was just about to announce that I will only do backports and regressions,
while I finally attack the fundamental problem with the representation of
Parameterized Derived Types. Then this PR came up that was such clear low
hanging fruit that I decided to fix it right away.

Regtests on FC33/x86_64 - OK for mainline?


LGTM.

Thanks,

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf

[PATCH] libstdc++: Update ppc64le baseline_symbols.txt

[Jakub Jelinek via Gcc-patches]

On Fri, Apr 16, 2021 at 08:48:12PM +0200, Jakub Jelinek via Gcc-patches wrote:
> 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.

Here are the needed changes to make it work.
For symbols with _LDBL_ substring in version name we already have code to
ignore those if no such symbols appear (but it is slightly incorrect, see
below).
So, this patch does the same thing for symbol versions with _IEEE128_
substring.
The previously incorrectly handled case is that in addition to
FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
or
OBJECT:12:_ZTSu9__ieee128@@CXXABI_IEEE128_1.3.13
cases we also have the
OBJECT:0:CXXABI_IEEE128_1.3.13
OBJECT:0:GLIBCXX_IEEE128_3.4.29
cases, which have empty version_name and the name is in that case the
symbol version.  Those need to be ignored too.

Tested on {powerpc64le,powerpc64,x86_64}-linux, ok for trunk?

2021-04-19  Jakub Jelinek  

* testsuite/util/testsuite_abi.cc (compare_symbols): If any symbol
versions with _IEEE128_ substring are found, set ieee_version_found
to true.  Ignore missing symbols with _IEEE128_ in version name if
!ieee_version_found.  Use i->first as version_name instead of
i->second.version_name if the latter is empty.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.

--- libstdc++-v3/testsuite/util/testsuite_abi.cc.jj 2021-01-04 
10:25:57.982016994 +0100
+++ libstdc++-v3/testsuite/util/testsuite_abi.cc2021-04-19 
14:34:06.567359978 +0200
@@ -407,6 +402,15 @@ compare_symbols(const char* baseline_fil
   ++li;
 }
 
+  // Similarly for IEEE128 symbols.
+  bool ieee_version_found(false);
+  for (li = test.begin(); li != test.end(); ++li)
+if (li->second.version_name.find("_IEEE128_") != std::string::npos)
+  {
+ieee_version_found = true;
+break;
+  }
+
   // Sort out names.
   // Assuming all baseline names and test names are both unique w/ no
   // duplicates.
@@ -440,9 +444,12 @@ compare_symbols(const char* baseline_fil
{
  // Iff no test long double compatibility symbols at all and the symbol
  // missing is a baseline long double compatibility symbol, skip.
- string version_name(i->second.version_name);
+ string version_name(i->second.version_name.size()
+ ? i->second.version_name : i->first);
  bool base_ld(version_name.find("_LDBL_") != std::string::npos);
- if (!base_ld || base_ld && ld_version_found)
+ bool base_ieee(version_name.find("_IEEE128_") != std::string::npos);
+ if ((!base_ld || (base_ld && ld_version_found))
+ && (!base_ieee || (base_ieee && ieee_version_found)))
missing_names.push_back(name);
}
 }
--- libstdc++-v3/config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt.jj
2021-04-17 11:31:24.925645956 +0200
+++ libstdc++-v3/config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt   
2021-04-19 14:14:41.285233539 +0200
@@ -548,6 +548,124 @@ FUNC:_ZNKSt15basic_streambufIwSt11char_t
 FUNC:_ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4
 FUNC:_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4
 FUNC:_ZNKSt16bad_array_length4whatEv@@CXXABI_1.3.8
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE16_M_extract_floatES4_S4_RSt8ios_baseRSt12_Ios_IostateRSs@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE3getES4_S4_RSt8ios_baseRSt12_Ios_IostateRPv@@GLIBCXX_IEEE128_3.4.29

FW: Payment Transfer Receipt

[gcc via Gcc]

--
thanks

Proof of payment.html
Description: Binary data

[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin

[dominiq at lps dot ens.fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org
 Blocks||99227
 Ever confirmed|0   |1
Summary|FAIL:   |[modules] FAIL:
   |g++.dg/modules/xtreme-heade |g++.dg/modules/xtreme-heade
   |r* on Darwin|r* on Darwin
   Last reconfirmed||2021-04-19
 Status|UNCONFIRMED |NEW

--- Comment #1 from Dominique d'Humieres  ---
See also https://gcc.gnu.org/pipermail/gcc-testresults/2021-April/682945.html
and friends.

It would be nice to have this PR fixed for GCC 11.1!


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
[Bug 99227] [meta] [modules] Bugs relating to header-units of STL header files

[PATCH] Remove pedantic_non_lvalue_loc

[Richard Biener]

This removes pedantic_non_lvalue_loc which doesn't do what it says
since quite some time in favor of what it actually does and where
that's not a duplicate (protected_set_expr_location_unshare).

Bootstrap & regtest running on x86_64-unknown-linux-gnu, queued for stage1

2021-04-19  Richard Biener  

* fold-const.c (pedantic_non_lvalue_loc): Remove.
(fold_binary_loc): Adjust.
(fold_ternary_loc): Likewise.
---
 gcc/fold-const.c | 28 +++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 2834278fd76..5a41524702b 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -2619,15 +2619,6 @@ non_lvalue_loc (location_t loc, tree x)
 return x;
   return build1_loc (loc, NON_LVALUE_EXPR, TREE_TYPE (x), x);
 }
-
-/* When pedantic, return an expr equal to X but certainly not valid as a
-   pedantic lvalue.  Otherwise, return X.  */
-
-static tree
-pedantic_non_lvalue_loc (location_t loc, tree x)
-{
-  return protected_set_expr_location_unshare (x, loc);
-}
 
 /* Given a tree comparison code, return the code that is the logical inverse.
It is generally not safe to do this for floating-point comparisons, except
@@ -12532,9 +12523,9 @@ fold_binary_loc (location_t loc, enum tree_code code, 
tree type,
   if (TREE_SIDE_EFFECTS (arg0) || TREE_CONSTANT (arg1))
return NULL_TREE;
   /* Don't let (0, 0) be null pointer constant.  */
-  tem = integer_zerop (arg1) ? build1 (NOP_EXPR, type, arg1)
+  tem = integer_zerop (arg1) ? build1_loc (loc, NOP_EXPR, type, arg1)
 : fold_convert_loc (loc, type, arg1);
-  return pedantic_non_lvalue_loc (loc, tem);
+  return tem;
 
 case ASSERT_EXPR:
   /* An ASSERT_EXPR should never be passed to fold_binary.  */
@@ -12781,7 +12772,7 @@ fold_ternary_loc (location_t loc, enum tree_code code, 
tree type,
|| !contains_label_p (unused_op))
   && (! VOID_TYPE_P (TREE_TYPE (tem))
   || VOID_TYPE_P (type)))
-   return pedantic_non_lvalue_loc (loc, tem);
+   return protected_set_expr_location_unshare (tem, loc);
  return NULL_TREE;
}
   else if (TREE_CODE (arg0) == VECTOR_CST)
@@ -12864,7 +12855,7 @@ fold_ternary_loc (location_t loc, enum tree_code code, 
tree type,
 a COND, which will recurse.  In that case, the COND_EXPR
 is probably the best choice, so leave it alone.  */
  && type == TREE_TYPE (arg0))
-   return pedantic_non_lvalue_loc (loc, arg0);
+   return protected_set_expr_location_unshare (arg0, loc);
 
   /* Convert A ? 0 : 1 to !A.  This prefers the use of NOT_EXPR
 over COND_EXPR in cases such as floating point comparisons.  */
@@ -12873,10 +12864,8 @@ fold_ternary_loc (location_t loc, enum tree_code code, 
tree type,
  && integer_onep (op2)
  && !VECTOR_TYPE_P (type)
  && truth_value_p (TREE_CODE (arg0)))
-   return pedantic_non_lvalue_loc (loc,
-   fold_convert_loc (loc, type,
- invert_truthvalue_loc (loc,
-arg0)));
+   return fold_convert_loc (loc, type,
+invert_truthvalue_loc (loc, arg0));
 
   /* A < 0 ?  : 0 is simply (A & ).  */
   if (TREE_CODE (arg0) == LT_EXPR
@@ -12982,10 +12971,7 @@ fold_ternary_loc (location_t loc, enum tree_code code, 
tree type,
 second operand 32-bit -128, which is not a power of two (or vice
 versa.  */
  && integer_pow2p (TREE_OPERAND (TREE_OPERAND (arg0, 0), 1)))
-   return pedantic_non_lvalue_loc (loc,
-   fold_convert_loc (loc, type,
- TREE_OPERAND (arg0,
-   0)));
+   return fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));
 
   /* Disable the transformations below for vectors, since
 fold_binary_op_with_conditional_arg may undo them immediately,
-- 
2.26.2

[Bug preprocessor/100142] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1004 since r11-8150-g4acb3af3669db4ca

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100142

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug preprocessor/100142] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1004 since r11-8150-g4acb3af3669db4ca

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100142

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:2f422b550ff6351d312e6c81a00b488d9280bfff

commit r11-8243-g2f422b550ff6351d312e6c81a00b488d9280bfff
Author: Richard Biener 
Date:   Mon Apr 19 10:07:35 2021 +0200

preprocessor/100142  - revert unwanted change in last commit

This reverts a s/column_offset/column/ change in the fix for PR99446.

2021-04-19  Richard Biener  

PR preprocessor/100142
libcpp/
* line-map.c (linemap_position_for_loc_and_offset): Revert
unintended s/column_offset/column/ change.

gcc/testsuite/
* gcc.dg/pr100142.c: New testcase.
* g++.dg/diagnostic/pr72803.C: Revert last change.

[Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable

[Paul Richard Thomas via Gcc-patches]

Hi All,

I was just about to announce that I will only do backports and regressions,
while I finally attack the fundamental problem with the representation of
Parameterized Derived Types. Then this PR came up that was such clear low
hanging fruit that I decided to fix it right away.

Regtests on FC33/x86_64 - OK for mainline?

Note that this is sufficiently safe that it could be applied to 11-branch
right now. However, I am prepared to hold off until 11-branch is released.

Regards

Paul

Fortran: Fix host associated PDT entity initialization [PR99307].

2021-04-19  Paul Thomas  

gcc/fortran
PR fortran/100110
* trans-decl.c (gfc_get_symbol_decl): Replace test for host
association with a check that the current and symbol namespaces
are the same.

gcc/testsuite/
PR fortran/100110
* gfortran.dg/pdt_31.f03: New test.
* gfortran.dg/pdt_26.f03: Reduce 'builtin_malloc' count from 9
to 8.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 34a0d49bae7..cc9d85543ca 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1548,7 +1548,8 @@ gfc_get_symbol_decl (gfc_symbol * sym)
  declaration of the entity and memory allocated/deallocated.  */
   if ((sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS)
   && sym->param_list != NULL
-  && !(sym->attr.host_assoc || sym->attr.use_assoc || sym->attr.dummy))
+  && gfc_current_ns == sym->ns
+  && !(sym->attr.use_assoc || sym->attr.dummy))
 gfc_defer_symbol_init (sym);
 
   /* Dummy PDT 'len' parameters should be checked when they are explicit.  */
diff --git a/gcc/testsuite/gfortran.dg/pdt_26.f03 b/gcc/testsuite/gfortran.dg/pdt_26.f03
index bf1273743d3..59ddcfb6cc4 100644
--- a/gcc/testsuite/gfortran.dg/pdt_26.f03
+++ b/gcc/testsuite/gfortran.dg/pdt_26.f03
@@ -2,7 +2,7 @@
 ! { dg-options "-fdump-tree-original" }
 !
 ! Test the fix for PR83567 in which the parameterized component 'foo' was
-! being deallocated before return from 'addw', with consequent segfault in 
+! being deallocated before return from 'addw', with consequent segfault in
 ! the main program.
 !
 ! Contributed by Berke Durak  
@@ -43,4 +43,4 @@ program test_pdt
   if (any (c(1)%foo .ne. [13,15,17])) STOP 2
 end program test_pdt
 ! { dg-final { scan-tree-dump-times "__builtin_free" 8 "original" } }
-! { dg-final { scan-tree-dump-times "__builtin_malloc" 9 "original" } }
+! { dg-final { scan-tree-dump-times "__builtin_malloc" 8 "original" } }


pdt_31.f03
Description: Binary data

Re: Decompose OpenACC 'kernels' constructs into parts, a sequence of compute constructs

[Thomas Schwinge]

Hi!

On 2021-04-19T10:29:17+0200, Thomas Schwinge  wrote:
> On 2020-11-15T09:14:32+0100, Tobias Burnus  wrote:
>> regarding the new option:
>>
>> +fopenacc-kernels=
>> +C ObjC C++ ObjC++ RejectNegative Joined Enum(openacc_kernels) 
>> Var(flag_openacc_kernels) Init(OPENACC_KERNELS_PARLOOPS)
>> +-fopenacc-kernels=[decompose|parloops]   Specify mode of OpenACC 
>> 'kernels' constructs handling.
>>
>> and
>>
>> On 13.11.20 23:22, Thomas Schwinge wrote:
>>> Not yet enabled by default: for now, the current mode of OpenACC 'kernels'
>>> constructs handling still remains '-fopenacc-kernels=parloops', but that is 
>>> to
>>> change later.
>>
>> Do you intent that users will switch between those two options?
>>
>> Or is this new option only an interim solution until decompose is handled?
>>
>> If the latter, maybe using a --param makes more sense than keeping the later 
>> for ever.
>
> Indeed the latter (had hoped to get more done in this GCC release cycle),
> so thanks for suggesting to use a '--param', "subject to change without
> notice in future releases".  Is that OK like in the attached "[OpenACC
> 'kernels'] '-fopenacc-kernels=[...]' -> '--param=openacc-kernels=[...]'"
> (currently testing)?  (My first patch related to a '--param' -- how
> exciting!)  ;-)

Tested fine, and Tobias approved privately.  As posted, I've pushed
"[OpenACC 'kernels'] '-fopenacc-kernels=[...]' ->
'--param=openacc-kernels=[...]'" to master branch in commit
3395dfc4da8ad1fccd346c62dfc9bd44b2b48c62, see attached.

(Well, no, actually not "as posted": I had forgotten to list one testcase
update in the ChangeLog snippet as "Likewise".  Looking forward to the
day when this strict GNU ChangeLog format is gone...)  %-)


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
>From 3395dfc4da8ad1fccd346c62dfc9bd44b2b48c62 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 19 Apr 2021 10:24:49 +0200
Subject: [PATCH] [OpenACC 'kernels'] '-fopenacc-kernels=[...]' ->
 '--param=openacc-kernels=[...]'

This configuration knob is temporary, and isn't really meant to be exposed to
users.

	gcc/
	* params.opt (-param=openacc-kernels=): Add.
	* omp-oacc-kernels-decompose.cc
	(pass_omp_oacc_kernels_decompose::gate): Use it.
	* doc/invoke.texi (-fopenacc-kernels=@var{mode}): Move...
	(--param): ... here, 'openacc-kernels'.
	gcc/c-family/
	* c.opt (fopenacc-kernels=): Remove.
	gcc/fortran/
	* lang.opt (fopenacc-kernels=): Remove.
	gcc/testsuite/
	* c-c++-common/goacc/if-clause-2.c: '-fopenacc-kernels=[...]' ->
	'--param=openacc-kernels=[...]'.
	* c-c++-common/goacc/kernels-decompose-1.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-2.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-ice-1.c: Likewise.
	* c-c++-common/goacc/kernels-decompose-ice-2.c: Likewise.
	* gfortran.dg/goacc/kernels-decompose-1.f95: Likewise.
	* gfortran.dg/goacc/kernels-decompose-2.f95: Likewise.
	* gfortran.dg/goacc/kernels-tree.f95: Likewise.
	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c:
	'-fopenacc-kernels=[...]' -> '--param=openacc-kernels=[...]'.
	* testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c:
	Likewise.
	* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
	Likewise.
	* testsuite/libgomp.oacc-fortran/pr94358-1.f90: Likewise.
---
 gcc/c-family/c.opt| 13 --
 gcc/doc/invoke.texi   | 24 +--
 gcc/fortran/lang.opt  |  4 
 gcc/omp-oacc-kernels-decompose.cc |  2 +-
 gcc/params.opt| 13 ++
 .../c-c++-common/goacc/if-clause-2.c  |  2 +-
 .../c-c++-common/goacc/kernels-decompose-1.c  |  2 +-
 .../c-c++-common/goacc/kernels-decompose-2.c  |  2 +-
 .../goacc/kernels-decompose-ice-1.c   |  2 +-
 .../goacc/kernels-decompose-ice-2.c   |  2 +-
 .../gfortran.dg/goacc/kernels-decompose-1.f95 |  2 +-
 .../gfortran.dg/goacc/kernels-decompose-2.f95 |  2 +-
 .../gfortran.dg/goacc/kernels-tree.f95|  2 +-
 .../declare-vla-kernels-decompose-ice-1.c |  2 +-
 .../declare-vla-kernels-decompose.c   |  2 +-
 .../kernels-decompose-1.c |  2 +-
 .../libgomp.oacc-fortran/pr94358-1.f90|  2 +-
 17 files changed, 37 insertions(+), 43 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index ed9a82599ef..3f8b72cdc00 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1873,19 +1873,6 @@ fopenacc-dim=
 C ObjC C++ ObjC++ LTO Joined Var(flag_openacc_dims)
 Specify default OpenACC compute dimensions.
 
-fopenacc-kernels=
-C ObjC C++ ObjC++ RejectNegative Joined Enum(openacc_kernels) Var(flag_openacc_kernels) Init(OPENACC_KERNELS_PARLOOPS)
--fopenacc-kernels=[decompose|parloops]	Specify mode of OpenACC 'kernels' constructs handling.
-
-Enum

[Bug fortran/100110] Parameterized Derived Types, problems with global variable

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110

--- Comment #2 from Paul Thomas  ---
Created attachment 50628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50628=edit
Fix for the PR

As I thought, the fix is trivial.

Paul

Re: [PATCH] aarch64, v2: Fix up 2 other combine opt regressions vs. GCC8 [PR100075]

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 19, 2021 at 01:16:13PM +0200, Christophe Lyon via Gcc-patches wrote:
> > > Here is an updated patch that I've also successfully 
> > > bootstrapped/regtested
> > > on aarch64-linux.
> > >
> > > 2021-04-16  Jakub Jelinek  
> > >
> > >   PR target/100075
> > >   * config/aarch64/aarch64.md (*neg_asr_si2_extr, *extrsi5_insn_di): 
> > > New
> > >   define_insn patterns.
> > >
> > >   * gcc.target/aarch64/pr100075.c: New test.
> >
> > OK, thanks.
> >
> 
> Hi,
> 
> The new test fails on aarch64_be, OK to add:
> +/* { dg-require-effective-target aarch64_little_endian } */
> ?
> The testcase looks really endianness dependent.

LGTM, thanks.

Jakub

[Bug c++/99805] [9 Regression] filesystem::path::parent_path got a wrong path

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #11 from Jonathan Wakely  ---
And 9.4 too.

[Bug c++/99805] [9 Regression] filesystem::path::parent_path got a wrong path

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:056563557e5e6e00d467760744c5b8e8525a06ac

commit r9-9362-g056563557e5e6e00d467760744c5b8e8525a06ac
Author: Jonathan Wakely 
Date:   Wed Apr 7 16:05:42 2021 +0100

libstdc++: Fix filesystem::path construction from COW string [PR 99805]

Calling the non-const data() member on a COW string makes it "leaked",
possibly resulting in reallocating the string to ensure a unique owner.

The path::_M_split_cmpts() member parses its _M_pathname string using
string_view objects and then calls _M_pathname.data() to find the offset
of each string_view from the start of the string. However because
_M_pathname is non-const that will cause a COW string to reallocate if
it happens to be shared with another string object. This results in the
offsets calculated for each component being wrong (i.e. undefined)
because the string views no longer refer to substrings of the
_M_pathname member. The fix is to use the parse.offset(c) member which
gets the offset safely.

The bug only happens for the path(string_type&&) constructor and only
for COW strings. When constructed from an lvalue string the string's
contents are copied rather than just incrementing the refcount, so
there's no reallocation when calling the non-const data() member. The
testsuite changes check the lvalue case anyway, because we should
probably change the deep copying to just be a refcount increment (by
adding a path(const string_type&) constructor or an overload for
__effective_range(const string_type&), for COW strings only).

libstdc++-v3/ChangeLog:

PR libstdc++/99805
* src/c++17/fs_path.cc (path::_M_split_cmpts): Do not call
non-const member on _M_pathname, to avoid copy-on-write.
* testsuite/27_io/filesystem/path/decompose/parent_path.cc:
Check construction from strings that might be shared.

(cherry picked from commit e06d3f5dd7d0c6b4a20fe813e6ee5addd097f560)