On Tue, Jan 11, 2022 at 10:30:26PM -0500, David Edelsohn wrote:
> The recent patch to support Power IEEE128 causes a bootstrap failure
> on AIX and possibly all non-GLIBC systems.
>
> +#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
> +&& defined __GLIBC_PREREQ && __G
The recent patch to support Power IEEE128 causes a bootstrap failure
on AIX and possibly all non-GLIBC systems.
+#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
+&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
+#define POWER_IEEE128 1
+#endif
__GLIBC_PREREQ is te
On Tue, Jan 11, 2022 at 10:44:56PM +0100, Thomas Koenig wrote:
> > > So... time to merge the branch into trunk before stage 4
> > > kicks in?
> >
> > IMHO yes. We need to git merge master; git rebase of course
> > before trying to cherry-pick those commits into trunk and pushing there.
>
> I wou
Hi HJ,
> I looked at gcc-testresults and find e.g.
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747935.html
>
> which is x86 (64 and 32 bit) by H.J.; plus some more.
> Maybe H.J. can explain what is differ
Hi FX,
Am 11.01.22 um 23:04 schrieb FX via Fortran:
Hi Harald,
I think this patch breaks the testsuite
On what platform? It regtested fine on x86_64-pc-linux-gnu
I looked at gcc-testresults and find e.g.
https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
https://gcc.gn
Hi Harald,
> I think this patch breaks the testsuite
On what platform? It regtested fine on x86_64-pc-linux-gnu
> since the directive
> ! { dg-additional-sources signaling_1_c.c }
> should rather read
> ! { dg-additional-sources "signaling_1_c.c" }
I find plenty of evidence saying it’s allowed
Hi FX,
Am 02.01.22 um 11:50 schrieb FX via Fortran:
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by
using the issignali
On 11.01.22 14:19, Jakub Jelinek via Fortran wrote:
On Mon, Jan 10, 2022 at 11:44:13PM +0100, Thomas Koenig wrote:
Hello world,
I have just pushed the attched patch to the branch.
Thanks.
Here is a patch to fix up the ppc64be vs. ppc64le byteswapping
of IBM extended real(kind=16) and compl
Dear Fortranners,
when digging into the issue pointed out in the PR by Gerhard it turned
out that there were several issues with the TRANSFER intrinsics in the
case MOLD was CHARACTER(kind=4). Default CHARACTER was fine, though.
- the size of the result was wrongly calculated
- the string length
On Tue, Jan 11, 2022 at 06:23:51PM +, Jonathan Wakely via Gcc-patches wrote:
> > Regarding fortran: can we have a vote on this one?
> >
> > Some developers (including myself) are not really familiar with C++,
> > and in the past preference has been expressed on the fortran ML in
> > favor of no
On Tue, 11 Jan 2022 at 18:02, Harald Anlauf via Gcc wrote:
>
> Am 11.01.22 um 16:50 schrieb Martin Liška:
> > On 1/11/22 16:48, Toon Moene wrote:
> >> On 1/11/22 13:56, Martin Liška wrote:
> >>
> >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>> Plus it survives buil
Am 11.01.22 um 16:50 schrieb Martin Liška:
On 1/11/22 16:48, Toon Moene wrote:
On 1/11/22 13:56, Martin Liška wrote:
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Plus it survives build of all FEs (--enable-languages=all) on
x86_64-linux-gnu
and I've built all cross co
On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote:
> On 1/11/22 16:56, Jakub Jelinek wrote:
> > While e.g. libcpp or gcc are in C++.
>
> Which means I should rename .c files under libcpp, right?
> Is there any other folder from gcc/ and libcpp/ that would need that as well?
>From the d
On 1/11/22 16:56, Jakub Jelinek wrote:
While e.g. libcpp or gcc are in C++.
Which means I should rename .c files under libcpp, right?
Is there any other folder from gcc/ and libcpp/ that would need that as well?
Martin
On Tue, Jan 11, 2022 at 04:50:02PM +0100, Martin Liška wrote:
> On 1/11/22 16:48, Toon Moene wrote:
> > On 1/11/22 13:56, Martin Liška wrote:
> >
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > Plus it survives build of all FEs (--enable-languages=all) on
> > >
On 1/11/22 16:48, Toon Moene wrote:
On 1/11/22 13:56, Martin Liška wrote:
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu
and I've built all cross compilers.
Does this also rename .c files in
On Tue, Jan 11, 2022 at 02:27:57PM +0100, Tobias Burnus wrote:
> Hi Jakub, hi all,
>
> let me quickly comment on 'has_device_addr' with Fortran arrays
> and with an array section (i.e. regarding your comment quoted
> at the very bottom of this email).
>
> Unfortunately, the OpenMP specification i
Hi Jakub, hi all,
let me quickly comment on 'has_device_addr' with Fortran arrays
and with an array section (i.e. regarding your comment quoted
at the very bottom of this email).
Unfortunately, the OpenMP specification is rather unclear
what has_device_addr means for C/C++ array sections and in
On Mon, Jan 10, 2022 at 11:44:13PM +0100, Thomas Koenig wrote:
> Hello world,
>
> I have just pushed the attched patch to the branch.
Thanks.
Here is a patch to fix up the ppc64be vs. ppc64le byteswapping
of IBM extended real(kind=16) and complex(kind=16).
Similarly to the BT_COMPLEX case it hal
On Wed, Nov 24, 2021 at 06:08:02PM +0100, Marcel Vollweiler wrote:
> + case OMP_CLAUSE_HAS_DEVICE_ADDR:
> + t = OMP_CLAUSE_DECL (c);
> + if (TREE_CODE (t) == TREE_LIST)
> + {
> + if (handle_omp_array_sections (c, ort))
> + remove = true;
> + e
20 matches
Mail list logo
