On Fri, Sep 17, 2021 at 2:34 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> Besides the C++ FE changes, I've noticed that the C FE didn't reject
> #pragma omp atomic capture compare
> { v = x; x = y; }
> and other forms of atomic swap, this patch fixes that too. And the
> c-family/
On 10/2/21 2:28 PM, Harald Anlauf wrote:
Hi Tobias,
the corrected attached patch fixes the regression for testcase
default_initialization_3.f90 for me now, and as a bonus matches
the description.
Me too! I'm also seeing clean test results now.
-Sandra
On 10/2/2021 1:50 PM, Aldy Hernandez via Gcc-patches wrote:
Bah. The range was being clobbered half way through the calculation.
Tested on x86-64 Linux.
Pushed.
On Fri, Oct 1, 2021 at 4:52 PM Aldy Hernandez wrote:
Well, after talking with Andrew it seems that X << Y being non-zero
also
There were a couple of typos in r12-4070 and r12-4071 which don't show
up when building for POSIX targets.
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc (create_directory): Fix typo in enum name.
* src/filesystem/ops-common.h (__last_system_error): Add
explicit cast to
Hi Tobias,
the corrected attached patch fixes the regression for testcase
default_initialization_3.f90 for me now, and as a bonus matches
the description.
Am 02.10.21 um 21:56 schrieb Tobias Burnus:
Hi Harald,
unfortunately, your email did not arrive at fort...@gcc.gnu.org – nor at
my private
On Sat, 2 Oct 2021 at 14:08, François Dumont wrote:
>
> On 02/10/21 12:29 am, Jonathan Wakely wrote:
> > On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
> > wrote:
> >> Here is the _Safe_iterator one.
> >>
> >> Doing so I noticed that pointer_traits rebind for __normal_iterator was
On Sat, 2 Oct 2021 at 18:27, François Dumont wrote:
>
> I would like to propose this alternative approach.
>
> In this patch I make __normal_iterator and random iterator
> _Safe_iterator compatible for pointer_traits primary template.
>
> Regarding pointer_traits I wonder if it shouldn't check for
Hi Harald,
unfortunately, your email did not arrive at fort...@gcc.gnu.org – nor at my
private address.
I copied it from
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580794.html
You wrote:
>/I do not see this error. Can you double check that you indeed use the />/posted patch:
Bah. The range was being clobbered half way through the calculation.
Tested on x86-64 Linux.
Pushed.
On Fri, Oct 1, 2021 at 4:52 PM Aldy Hernandez wrote:
>
> Well, after talking with Andrew it seems that X << Y being non-zero
> also implies X is non-zero. So we don't even need relationals
Hi Tobias,
Am 02.10.21 um 20:29 schrieb Tobias Burnus:
On 02.10.21 20:01, Sandra Loosemore wrote:
On 9/29/21 2:53 AM, Tobias Burnus wrote:
There are three issues, this patch solves the first:
* reject-valid issue due to adding the initializer also to a dummy
argument which is in an
Am Donnerstag, den 23.09.2021, 17:37 -0400 schrieb Jason Merrill:
> On 9/23/21 15:49, Uecker, Martin wrote:
> > Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
> > > On 9/5/21 15:14, Uecker, Martin wrote:
> > > > Here is the third version of the patch. This also
> > > > fixes the
On 02.10.21 20:01, Sandra Loosemore wrote:
On 9/29/21 2:53 AM, Tobias Burnus wrote:
There are three issues, this patch solves the first:
* reject-valid issue due to adding the initializer also to a dummy
argument which is in an INTERFACE block. Having initializers in
INTERFACE blocks is
On 9/29/21 2:53 AM, Tobias Burnus wrote:
Found when looking at F2018:C839 / PR54753.
For INTENT(OUT) the dummy variable (might) also be default initialized
or deallocated. However, with assumed rank, that causes issues, which
C839 prevents. In the current GCC implementation, missing C839
I would like to propose this alternative approach.
In this patch I make __normal_iterator and random iterator
_Safe_iterator compatible for pointer_traits primary template.
Regarding pointer_traits I wonder if it shouldn't check for the
to_pointer method availability and use per default:
On 02/10/21 12:29 am, Jonathan Wakely wrote:
On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
wrote:
Here is the _Safe_iterator one.
Doing so I noticed that pointer_traits rebind for __normal_iterator was
wrong and added tests on it.
Oops, thanks!
For _Safe_iterator maybe I
Am Fr., 1. Okt. 2021 um 21:57 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Implement the changes from P2162R2 (as a DR for C++17).
>
> Signed-off-by: Jonathan Wakely
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/90943
> * include/std/variant (__cpp_lib_variant): Update value.
>
Fix an obvious issue when processing save_decoded_options.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
* toplev.c (toplev::main): save_decoded_options[0] is program
name and so it should be skipped.
---
gcc/toplev.c | 2
A recent improvement in Waddress causes a bootstrap failure on
targets that define TARGET_FORMAT_TYPES since it cannot be NULL
if defined to an address.
There is no default for this target macro, and it would seem no
purpose to defining it to NULL, so the warning appears reasonable.
Fixed by
On Sat, Oct 02, 2021 at 09:52:29AM +0200, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/order-reproducible-1.f90
> @@ -0,0 +1,72 @@
> +! { dg-additional-sources my-usleep.c }
> +! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is
> valid for
On 01.10.21 11:45, Jakub Jelinek wrote:
Attached is the Fortran version of the two patches – the Fortran FE
modifications were already in Jakub's patch.
And no my-usleep.c in the patch.
Thou shall not send patches in a hurry when taking off on a day ...
New patch attached.
Tobias
20 matches
Mail list logo
