Hi Tobias,
> LGTM – I am fine with either variant, but I am slightly inclined to
> removing the gcc_assert*
> – as I believe that the existing checks come early enough and do seem to
> work well.
I played some more and found additional cases that we hadn't discussed
before. (At least I hadn't th
The following is about interoperability (BIND(C)) only.
* The patch adds a missing check for pointer + contiguous.
(Rejected to avoid copy-in issues? Or checking issues?)
* And it corrects an issue regarding len > 1 characters. While
subroutine foo(x)
character(len=2) :: x(*)
is valid F
Hi Harald,
On 20.08.21 14:17, Harald Anlauf wrote:
I can confirm this. – I think in order to reduce the clutter, the
diagnostic probably should be removed.
I am unable to prove that we will never that check. So how about:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index eaabb
On Fri, Aug 20, 2021 at 03:47:54PM +0200, Tobias Burnus wrote:
> On 20.08.21 13:56, Jakub Jelinek wrote:
>
> > On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote:
> > > Comments? OK?
> > LGTM (except that the last hunk won't apply anymore).
>
> Now applied as r12-3044; I have now chang
On 20.08.21 13:56, Jakub Jelinek wrote:
On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote:
Comments? OK?
LGTM (except that the last hunk won't apply anymore).
Now applied as r12-3044; I have now changed it to %wd ...
... but as discussed in another email in the thread, I think t
Ah, thanks, I restarted the build with _GNU_SOURCE instead.
Regards,
Arjen
Op vr 20 aug. 2021 om 15:11 schreef Jonathan Wakely :
> On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote:
> >
> > On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
> > >
> > > Going the WSL2 route (I am not all that f
On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote:
>
> On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
> >
> > Going the WSL2 route (I am not all that familiar with WSL) or a Linux
> > emulation may be the way to go, indeed, but your remark triggered me to do
> > a bit of searching: there is
On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote:
>
> Going the WSL2 route (I am not all that familiar with WSL) or a Linux
> emulation may be the way to go, indeed, but your remark triggered me to do a
> bit of searching: there is some discussion about the secure_getenv() function
> wrt Cygwin
Going the WSL2 route (I am not all that familiar with WSL) or a Linux
emulation may be the way to go, indeed, but your remark triggered me to do
a bit of searching: there is some discussion about the secure_getenv()
function wrt Cygwin but there actually is a prototype for it in Cygwin's
stdlib.h.
On Fri, Aug 20, 2021 at 12:55 PM Arjen Markus wrote:
>
> Okay, that solved that error, now I get:
>
> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
> -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
> -frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
> ../../..
> Gesendet: Freitag, 20. August 2021 um 14:01 Uhr
> Von: "Tobias Burnus"
> On 20.08.21 12:53, Harald Anlauf wrote:
>
> > I played with variations of the testcase by specifying illegal
> > substring bounds, but all these cases were caught in a different
> > spot with similar error messages.
>
> I
On 20.08.21 12:53, Harald Anlauf wrote:
I have verified it fixes i686-linux bootstrap.
But the new testcase doesn't trigger any of those new errors, is something
else in the testsuite covering those or do you have some short snippet that
could verify the errors work properly?
The testcase was d
On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote:
> On 20.08.21 11:16, Jakub Jelinek wrote:
>
> > Now, the non-Fortran FE diagnostic code actually has %wd for this (w
> > modifier like l modifier), which takes HOST_WIDE_INT/unsigned HOST_WIDE_INT
> > argument and prints it.
> >
> > S
On 20.08.21 11:16, Jakub Jelinek wrote:
Now, the non-Fortran FE diagnostic code actually has %wd for this (w
modifier like l modifier), which takes HOST_WIDE_INT/unsigned HOST_WIDE_INT
argument and prints it.
So, either you get through the hops to support that, unfortunately it isn't
just addin
Dear all,
I've just pushed the fix for the bootstrap breakage as confirmed by Jakub.
commit r12-3043-g12f22906d3c025e7edb60e3264dc9cd27a49e3e1
Author: Harald Anlauf
Date: Fri Aug 20 13:38:00 2021 +0200
Fortran - use temporary char buffer for passing HOST_WIDE_INT to gfc_error
gcc/fo
On Fri, Aug 20, 2021 at 12:53:33PM +0200, Harald Anlauf wrote:
> > Gesendet: Freitag, 20. August 2021 um 12:12 Uhr
> > Von: "Jakub Jelinek"
>
> > I have verified it fixes i686-linux bootstrap.
> > But the new testcase doesn't trigger any of those new errors, is something
> > else in the testsuite
Okay, that solved that error, now I get:
-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
In file include
> Gesendet: Freitag, 20. August 2021 um 12:12 Uhr
> Von: "Jakub Jelinek"
> I have verified it fixes i686-linux bootstrap.
> But the new testcase doesn't trigger any of those new errors, is something
> else in the testsuite covering those or do you have some short snippet that
> could verify the e
On Fri, Aug 20, 2021 at 11:45:33AM +0200, Harald Anlauf wrote:
> Hi Jakob,
>
> thanks for the detailed explanation!
>
> > The other much easier but uglier option is to use a temporary buffer:
> > char buffer[21];
> > sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
> > gfc_error ("...
Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>
>
> The easiest is probably to build them in-tree by means of
> executing ./contrib/download_prerequesites which will download
> and unpack them into your source tree.
>
>
Well, I do have the libraries (source and all) and I copied the built
li
On Fri, Aug 20, 2021 at 12:00:10PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> * dump-parse-tree.c (show_omp_clauses): Handle 'at', 'severity'
> and 'message' clauses.
> (show_omp_node, show_code_node): Handle EXEC_OMP_ERROR.
> * gfortran.h (gfc_statement): Add
Hi Jakub, hi all,
On 20.08.21 11:45, Jakub Jelinek wrote:
This patch implements the error directive. Depending on clauses it is either
a compile time diagnostics (in that case diagnosed right away) or runtime
diagnostics (libgomp API call that diagnoses at runtime),
The attached patch does li
On Fri, Aug 20, 2021 at 9:59 AM Arjen Markus via Fortran
wrote:
>
> I am trying to build the compiler suite to test the two patches Steve Kargl
> posted. But I run into a problem with the mpfr and mpc libraries: the
> linker claims it cannot find them.
>
> I checked this, in fist instance they wer
Hi Jakob,
thanks for the detailed explanation!
> The other much easier but uglier option is to use a temporary buffer:
> char buffer[21];
> sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
> gfc_error ("... %s ...", ... buffer ...);
> This works, as it uses the host sprintf i.e. *print
On 20.08.21 02:21, H.J. Lu wrote:
This may have broken bootstrap on 32-bit hosts:
https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
The latter has:
../../src-master/gcc/fortran/simplify.c:4557:22: error: unknown conversion type
character ‘l’ in format [-Werror=format=]
455
On Fri, Aug 20, 2021 at 08:48:57AM +0200, Harald Anlauf via Gcc-patches wrote:
> Hi!
>
> > Gesendet: Freitag, 20. August 2021 um 02:21 Uhr
> > Von: "H.J. Lu"
>
> > This may have broken bootstrap on 32-bit hosts:
> >
> > https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
>
> I
> On 20 Aug 2021, at 08:52, Tobias Burnus wrote:
>
> On 20.08.21 09:34, Richard Biener via Fortran wrote:
>
>> On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote:
>>> libm is not needed on Darwin, and should not be added unconditionally
>>> even if that is (mostly) harmless since it is a sym
I am trying to build the compiler suite to test the two patches Steve Kargl
posted. But I run into a problem with the mpfr and mpc libraries: the
linker claims it cannot find them.
I checked this, in fist instance they were not present in the location they
were assumed to be, but I had copies from
On 20.08.21 09:34, Richard Biener via Fortran wrote:
On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote:
libm is not needed on Darwin, and should not be added unconditionally
even if that is (mostly) harmless since it is a symlink to libc.
tested on x86_64, i686-darwin, x86_64-linux,
OK for m
On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote:
>
> Hi,
>
> A while ago had a report of build failure against a Darwin branch on
> the latest OS release. This was because (temporarily) the symlink
> from libm.dylib => libSystem.dylib had been removed/omitted.
>
> libm is not needed on Darwin,
30 matches
Mail list logo
