How to add an additional option to dg-compile and dg-run

[Thomas Koenig via Gcc]

Hi,

for the fortran-unsigned branch, I would like to be able to run all
existing Fortran tests also with -funsigned, to make sure the option
does not break anything on existing code.

Question is: How?

I came as far as

$ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"

but that causes testsuite failures because C does not recognize
the option.

Any other possibilites?

Best regards

Thomas

Re: GCC 14.2 Release Candidate available from gcc.gnu.org

[Richard Biener via Gcc]

On Sun, Jul 28, 2024 at 11:46 PM Jason Merrill via Gcc  wrote:
>
> Since the RC I've fixed a few 14/15 C++ regressions with extremely safe
> patches, and wonder what you think about pushing them to the branch at this
> point:
>
> 115583, 115986, 115561
>
> Sorry these came so late.

Those are all for C++20 or later (non-default, experimental?).

If we pick a few extra fixes we might want to do RC2 today and delay
14.2 a few days.

Richard.

> Jason
>
> On Tue, Jul 23, 2024 at 8:51 AM Jakub Jelinek via Gcc 
> wrote:
>
> > The first release candidate for GCC 14.2 is available from
> >
> >  https://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/
> >  ftp://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/
> >
> > and shortly its mirrors.  It has been generated from git commit
> > r14-10504-ga544898f6dd6a16.
> >
> > I have so far bootstrapped and tested the release candidate on
> > x86_64-linux.
> > Please test it and report any issues to bugzilla.
> >
> > If all goes well, we'd like to release 14.2 on Tuesday, Jul 30th.
> >
> >

Re: How to add an additional option to dg-compile and dg-run

[Jonathan Wakely via Gcc]

On Mon, 29 Jul 2024 at 09:20, Thomas Koenig via Gcc  wrote:
>
> Hi,
>
> for the fortran-unsigned branch, I would like to be able to run all
> existing Fortran tests also with -funsigned, to make sure the option
> does not break anything on existing code.
>
> Question is: How?
>
> I came as far as
>
> $ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
>
> but that causes testsuite failures because C does not recognize
> the option.
>
> Any other possibilites?

I haven't tested it, but based on testsuite/gfortran.dg/dg.exp it
looks like you could add this in ~/.dejagnurc

set DEFAULT_FFLAGS "-funsigned -pedantic-errors"

(The -pedantic-errors is what dg.exp uses if the variable doesn't
already exist, so this preserves that.)

If you're using a site.exp you could add this there instead of ~/.dejagnurc

Re: How to add an additional option to dg-compile and dg-run

[Jonathan Wakely via Gcc]

On Mon, 29 Jul 2024 at 10:20, Jonathan Wakely  wrote:
>
> On Mon, 29 Jul 2024 at 09:20, Thomas Koenig via Gcc  wrote:
> >
> > Hi,
> >
> > for the fortran-unsigned branch, I would like to be able to run all
> > existing Fortran tests also with -funsigned, to make sure the option
> > does not break anything on existing code.
> >
> > Question is: How?
> >
> > I came as far as
> >
> > $ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
> >
> > but that causes testsuite failures because C does not recognize
> > the option.
> >
> > Any other possibilites?
>
> I haven't tested it, but based on testsuite/gfortran.dg/dg.exp it
> looks like you could add this in ~/.dejagnurc
>
> set DEFAULT_FFLAGS "-funsigned -pedantic-errors"
>
> (The -pedantic-errors is what dg.exp uses if the variable doesn't
> already exist, so this preserves that.)
>
> If you're using a site.exp you could add this there instead of ~/.dejagnurc

Oh but the comment suggests that will only be used for tests that
don't use dg-options:

# If a testcase doesn't have special options, use these.
global DEFAULT_FFLAGS
if ![info exists DEFAULT_FFLAGS] then {
set DEFAULT_FFLAGS " -pedantic-errors"
}

I don't know if that's correct, or if the dg-options flags get
appended to these default flags.

You might also need a leading space in the string, like dg.exp uses
(or maybe that's not needed in dg.exp anyway).

RE: [RFC] Summary of libgomp failures for offloading to nvptx from AArch64

[Prathamesh Kulkarni via Gcc]

> -Original Message-
> From: Richard Biener 
> Sent: Friday, July 26, 2024 6:51 PM
> To: Prathamesh Kulkarni 
> Cc: gcc@gcc.gnu.org
> Subject: Re: [RFC] Summary of libgomp failures for offloading to nvptx
> from AArch64
> 
> External email: Use caution opening links or attachments
> 
> 
> On Thu, Jul 25, 2024 at 3:36 PM Prathamesh Kulkarni via Gcc
>  wrote:
> >
> > Hi,
> > I am working on enabling offloading to nvptx from AAarch64 host. As
> > mentioned on wiki
> > (https://gcc.gnu.org/wiki/Offloading#Running_.27make_check.27),
> > I ran make check-target-libgomp on AAarch64 host (and no GPU) with
> following results:
> >
> > === libgomp Summary ===
> >
> > # of expected passes14568
> > # of unexpected failures1023
> > # of expected failures  309
> > # of untested testcases 54
> > # of unresolved testcases   992
> > # of unsupported tests  644
> >
> > It seems majority of the tests fail due to the following 4 issues:
> >
> > * Compiling a minimal test-case:
> >
> > int main()
> > {
> >   int x;
> >   #pragma omp target map (to: x)
> >   {
> > x = 0;
> >   }
> >   return x;
> > }
> >
> > Compiling with -fopenmp -foffload=nvptx-none results in following
> issues:
> >
> > (1) Differing values of NUM_POLY_INT_COEFFS between host and
> accelerator, which results in following ICE:
> >
> > 0x1a6e0a7 pp_quoted_string
> > ../../gcc/gcc/pretty-print.cc:2277
> >  0x1a6ffb3 pp_format(pretty_printer*, text_info*, urlifier const*)
> > ../../gcc/gcc/pretty-print.cc:1634
> >  0x1a4a3f3 diagnostic_context::report_diagnostic(diagnostic_info*)
> > ../../gcc/gcc/diagnostic.cc:1612
> >  0x1a4a727 diagnostic_impl
> > ../../gcc/gcc/diagnostic.cc:1775  0x1a4e20b
> > fatal_error(unsigned int, char const*, ...)
> > ../../gcc/gcc/diagnostic.cc:2218  0xb3088f
> > lto_input_mode_table(lto_file_decl_data*)
> >  ../../gcc/gcc/lto-streamer-in.cc:2121
> >  0x6f5cdf lto_file_finalize
> > ../../gcc/gcc/lto/lto-common.cc:2285
> >  0x6f5cdf lto_create_files_from_ids
> > ../../gcc/gcc/lto/lto-common.cc:2309
> >  0x6f5cdf lto_file_read
> > ../../gcc/gcc/lto/lto-common.cc:2364
> >  0x6f5cdf read_cgraph_and_symbols(unsigned int, char const**)
> > ../../gcc/gcc/lto/lto-common.cc:2812
> >  0x6cfb93 lto_main()
> > ../../gcc/gcc/lto/lto.cc:658
> >
> > This is already tracked in https://gcc.gnu.org/PR96265 (and related
> > PR's)
> >
> > Streaming out mode_table:
> > mode = SI, mclass = 2, size = 4, prec = 32 mode = DI, mclass = 2,
> size
> > = 8, prec = 64
> >
> > Streaming in mode_table (in lto_input_mode_table):
> > mclass = 2, size = 4, prec = 0
> > (and then calculates the correct mode value by iterating over all
> > modes of mclass starting from narrowest mode)
> >
> > The issue is that the value for prec is not getting streamed-in
> > correctly for SImode as seen above. While streaming out from AArch64
> host, it is 32, but while streaming in for nvptx, it is 0. This
> happens because of differing values of NUM_POLY_INT_COEFFS between
> AArch64 and nvptx backend.
> >
> > Since NUM_POLY_INT_COEFFS is 2 for aarch64, the streamed-out values
> > for mode, precision would be <4, 0> and <32, 0> respectively
> > (streamed-out in bp_pack_poly_value). Both zeros come from coeffs[1]
> > of size and prec. While streaming in however, NUM_POLY_INT_COEFFS is
> 1 for nvptx, and thus it incorrectly treats <4, 0> as size and
> precision respectively, which is why precision gets streamed in as 0,
> and thus it encounters the above ICE.
> >
> > Supporting non VLA code with offloading:
> >
> > In the general case, it's hard to support offloading for arbitrary
> poly_ints when NUM_POLY_INT_COEFFS differs for host and accelerator.
> > For example, it's not possible to represent a degree-2 poly_int like
> 4 + 4x (as-is) on an accelerator with NUM_POLY_INT_COEFFS == 1.
> >
> > However, IIUC, we can support offloading for restricted set of
> > poly_ints whose degree <= accel's NUM_POLY_INT_COEFFS, since they
> can
> > be represented on accelerator ? For a hypothetical example, if host
> NUM_POLY_INT_COEFFS == 3 and accel NUM_POLY_INT_COEFFS == 2, then I
> suppose we could represent a degree 2 poly_int on accelerator, but not
> a degree 3 poly_int like 3+4x+5x^2 ?
> >
> > Based on that, I have come up with following approach in attached
> "quick-and-dirty" patch (p-163-2.diff):
> > Stream-out host NUM_POLY_INT_COEFFS, and while streaming-in during
> lto1, compare it with accelerator's NUM_POLY_INT_COEFFS as follows:
> >
> > Stream in host_num_poly_int_coeffs;
> > if (host_num_poly_int_coeffs == NUM_POLY_INT_COEFFS) //
> NUM_POLY_INT_COEFFS represents accelerator's value here.
> > {
> > /* Both are equal, proceed to unpacking NUM_POLY_INT_COEFFS
> words
> > from bitstream.  */ } else if (host_num_poly_int_coeffs <
> > NUM_POLY_INT_COEFFS) {
> > /* Unpack host_num_poly_int_coeffs words and zero out rem

Re: GCC 14.2 Release Candidate available from gcc.gnu.org

[Jason Merrill via Gcc]

On Mon, Jul 29, 2024 at 4:34 AM Richard Biener 
wrote:

> On Sun, Jul 28, 2024 at 11:46 PM Jason Merrill via Gcc 
> wrote:
> >
> > Since the RC I've fixed a few 14/15 C++ regressions with extremely safe
> > patches, and wonder what you think about pushing them to the branch at
> this
> > point:
> >
> > 115583, 115986, 115561
> >
> > Sorry these came so late.
>
> Those are all for C++20 or later (non-default, experimental?).
>

Correct.


> If we pick a few extra fixes we might want to do RC2 today and delay
> 14.2 a few days.
>
> Richard.
>
> > Jason
> >
> > On Tue, Jul 23, 2024 at 8:51 AM Jakub Jelinek via Gcc 
> > wrote:
> >
> > > The first release candidate for GCC 14.2 is available from
> > >
> > >  https://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/
> > >  ftp://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240723/
> > >
> > > and shortly its mirrors.  It has been generated from git commit
> > > r14-10504-ga544898f6dd6a16.
> > >
> > > I have so far bootstrapped and tested the release candidate on
> > > x86_64-linux.
> > > Please test it and report any issues to bugzilla.
> > >
> > > If all goes well, we'd like to release 14.2 on Tuesday, Jul 30th.
> > >
> > >
>
>

Re: [RFC] Summary of libgomp failures for offloading to nvptx from AArch64

[Richard Biener via Gcc]

On Mon, Jul 29, 2024 at 1:35 PM Prathamesh Kulkarni
 wrote:
>
>
>
> > -Original Message-
> > From: Richard Biener 
> > Sent: Friday, July 26, 2024 6:51 PM
> > To: Prathamesh Kulkarni 
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: [RFC] Summary of libgomp failures for offloading to nvptx
> > from AArch64
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Thu, Jul 25, 2024 at 3:36 PM Prathamesh Kulkarni via Gcc
> >  wrote:
> > >
> > > Hi,
> > > I am working on enabling offloading to nvptx from AAarch64 host. As
> > > mentioned on wiki
> > > (https://gcc.gnu.org/wiki/Offloading#Running_.27make_check.27),
> > > I ran make check-target-libgomp on AAarch64 host (and no GPU) with
> > following results:
> > >
> > > === libgomp Summary ===
> > >
> > > # of expected passes14568
> > > # of unexpected failures1023
> > > # of expected failures  309
> > > # of untested testcases 54
> > > # of unresolved testcases   992
> > > # of unsupported tests  644
> > >
> > > It seems majority of the tests fail due to the following 4 issues:
> > >
> > > * Compiling a minimal test-case:
> > >
> > > int main()
> > > {
> > >   int x;
> > >   #pragma omp target map (to: x)
> > >   {
> > > x = 0;
> > >   }
> > >   return x;
> > > }
> > >
> > > Compiling with -fopenmp -foffload=nvptx-none results in following
> > issues:
> > >
> > > (1) Differing values of NUM_POLY_INT_COEFFS between host and
> > accelerator, which results in following ICE:
> > >
> > > 0x1a6e0a7 pp_quoted_string
> > > ../../gcc/gcc/pretty-print.cc:2277
> > >  0x1a6ffb3 pp_format(pretty_printer*, text_info*, urlifier const*)
> > > ../../gcc/gcc/pretty-print.cc:1634
> > >  0x1a4a3f3 diagnostic_context::report_diagnostic(diagnostic_info*)
> > > ../../gcc/gcc/diagnostic.cc:1612
> > >  0x1a4a727 diagnostic_impl
> > > ../../gcc/gcc/diagnostic.cc:1775  0x1a4e20b
> > > fatal_error(unsigned int, char const*, ...)
> > > ../../gcc/gcc/diagnostic.cc:2218  0xb3088f
> > > lto_input_mode_table(lto_file_decl_data*)
> > >  ../../gcc/gcc/lto-streamer-in.cc:2121
> > >  0x6f5cdf lto_file_finalize
> > > ../../gcc/gcc/lto/lto-common.cc:2285
> > >  0x6f5cdf lto_create_files_from_ids
> > > ../../gcc/gcc/lto/lto-common.cc:2309
> > >  0x6f5cdf lto_file_read
> > > ../../gcc/gcc/lto/lto-common.cc:2364
> > >  0x6f5cdf read_cgraph_and_symbols(unsigned int, char const**)
> > > ../../gcc/gcc/lto/lto-common.cc:2812
> > >  0x6cfb93 lto_main()
> > > ../../gcc/gcc/lto/lto.cc:658
> > >
> > > This is already tracked in https://gcc.gnu.org/PR96265 (and related
> > > PR's)
> > >
> > > Streaming out mode_table:
> > > mode = SI, mclass = 2, size = 4, prec = 32 mode = DI, mclass = 2,
> > size
> > > = 8, prec = 64
> > >
> > > Streaming in mode_table (in lto_input_mode_table):
> > > mclass = 2, size = 4, prec = 0
> > > (and then calculates the correct mode value by iterating over all
> > > modes of mclass starting from narrowest mode)
> > >
> > > The issue is that the value for prec is not getting streamed-in
> > > correctly for SImode as seen above. While streaming out from AArch64
> > host, it is 32, but while streaming in for nvptx, it is 0. This
> > happens because of differing values of NUM_POLY_INT_COEFFS between
> > AArch64 and nvptx backend.
> > >
> > > Since NUM_POLY_INT_COEFFS is 2 for aarch64, the streamed-out values
> > > for mode, precision would be <4, 0> and <32, 0> respectively
> > > (streamed-out in bp_pack_poly_value). Both zeros come from coeffs[1]
> > > of size and prec. While streaming in however, NUM_POLY_INT_COEFFS is
> > 1 for nvptx, and thus it incorrectly treats <4, 0> as size and
> > precision respectively, which is why precision gets streamed in as 0,
> > and thus it encounters the above ICE.
> > >
> > > Supporting non VLA code with offloading:
> > >
> > > In the general case, it's hard to support offloading for arbitrary
> > poly_ints when NUM_POLY_INT_COEFFS differs for host and accelerator.
> > > For example, it's not possible to represent a degree-2 poly_int like
> > 4 + 4x (as-is) on an accelerator with NUM_POLY_INT_COEFFS == 1.
> > >
> > > However, IIUC, we can support offloading for restricted set of
> > > poly_ints whose degree <= accel's NUM_POLY_INT_COEFFS, since they
> > can
> > > be represented on accelerator ? For a hypothetical example, if host
> > NUM_POLY_INT_COEFFS == 3 and accel NUM_POLY_INT_COEFFS == 2, then I
> > suppose we could represent a degree 2 poly_int on accelerator, but not
> > a degree 3 poly_int like 3+4x+5x^2 ?
> > >
> > > Based on that, I have come up with following approach in attached
> > "quick-and-dirty" patch (p-163-2.diff):
> > > Stream-out host NUM_POLY_INT_COEFFS, and while streaming-in during
> > lto1, compare it with accelerator's NUM_POLY_INT_COEFFS as follows:
> > >
> > > Stream in host_num_poly_int_coeffs;
> > > if (host_num_poly_int_coeffs == NUM_POLY_INT_C

Second GCC 14.2 Release Candidate available from gcc.gnu.org

[Jakub Jelinek via Gcc]

The second release candidate for GCC 14.2 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240729/
 ftp://gcc.gnu.org/pub/gcc/snapshots/14.2.0-RC-20240729/

and shortly its mirrors.  It has been generated from git commit
r14-10521-gda7f0be91e2ae15.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 14.2 on Thursday, Aug 1st.

Re: How to add an additional option to dg-compile and dg-run

[Andrew Pinski via Gcc]

On Mon, Jul 29, 2024 at 1:20 AM Thomas Koenig  wrote:
>
> Hi,
>
> for the fortran-unsigned branch, I would like to be able to run all
> existing Fortran tests also with -funsigned, to make sure the option
> does not break anything on existing code.
>
> Question is: How?
>
> I came as far as
>
> $ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
>
> but that causes testsuite failures because C does not recognize
> the option.
>
> Any other possibilites?

Yes you could add it into the list of Torture options that
gfortran-dg-runtest uses.
Something like:
```
diff --git a/gcc/testsuite/lib/gfortran-dg.exp
b/gcc/testsuite/lib/gfortran-dg.exp
index fcba95dc396..0589d507382 100644
--- a/gcc/testsuite/lib/gfortran-dg.exp
+++ b/gcc/testsuite/lib/gfortran-dg.exp
@@ -153,6 +153,12 @@ proc gfortran-dg-runtest { testcases flags
default-extra-flags } {
} else {
set option_list [list { -O } ]
}
+   set old_option_list  $option_list
+   set option_list {}
+   foreach option $option_list {
+ lappend option_list $option
+ lappend option_list "$option -funsigned"
+   }

set nshort [file tail [file dirname $test]]/[file tail $test]
list-module-names $test
```
should work but I am not 100% I got the TCL syntax correct.

Thanks,
Andrew Pinski

>
> Best regards
>
> Thomas

Re: How to add an additional option to dg-compile and dg-run

[Thomas Koenig via Gcc]

Am 29.07.24 um 11:22 schrieb Jonathan Wakely via Gcc:
> # If a testcase doesn't have special options, use these.
> global DEFAULT_FFLAGS
> if ![info exists DEFAULT_FFLAGS] then {
> set DEFAULT_FFLAGS " -pedantic-errors"
> }
I tried using that, still saw a lot of errors when compiling
C files.  I also tried

--- a/gcc/testsuite/gfortran.dg/dg.exp
+++ b/gcc/testsuite/gfortran.dg/dg.exp
@@ -32,7 +32,7 @@ dg-init
global gfortran_test_path
global gfortran_aux_module_flags
set gfortran_test_path $srcdir/$subdir
-set gfortran_aux_module_flags $DEFAULT_FFLAGS
+set gfortran_aux_module_flags "-O0"
proc dg-compile-aux-modules { args } {
global gfortran_test_path
global gfortran_aux_module_flags

but that also seems to have been the wrong button to press,
that also didn't do anything.

Anything else to try?  I'd really like to set up some sort of regression
test to make sure that -funsigned does not break anything else, but
right now I'm out of ideas.

Best regards

Thomas

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

[Ian Lance Taylor via Gcc]

On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers  wrote:
>
> Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> >> Cc: i...@google.com, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> >> From: Björn Schäpers 
> >>
> >> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
> >>> In that case, you an call either GetModuleHandeExA or
> >>> GetModuleHandeExW, the difference is minor.
> >>
> >> Here an updated version without relying on TEXT or TCHAR, directly calling
> >> GetModuleHandleExW.
> >
> > Thanks, this LGTM (but I couldn't test it, I just looked at the
> > sour ce code).
>
> Here an updated version. It is rebased on the combined approach of getting the
> loaded DLLs and two minor changes to suppress warnings.

This bug report was filed about this patch:

https://github.com/ianlancetaylor/libbacktrace/issues/131

> src\pecoff.c(86): error C2059: syntax error: '('
> src\pecoff.c(89): error C2059: syntax error: '('
>
> It works fine if deleting CALLBACK and NTAPI.

Any ideas?

Thanks.

Ian

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

[Eli Zaretskii via Gcc]

> From: Ian Lance Taylor 
> Date: Mon, 29 Jul 2024 09:46:46 -0700
> Cc: Eli Zaretskii , gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> 
> On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers  wrote:
> >
> > Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> > >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> > >> Cc: i...@google.com, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
> > >> From: Björn Schäpers 
> > >>
> > >> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
> > >>> In that case, you an call either GetModuleHandeExA or
> > >>> GetModuleHandeExW, the difference is minor.
> > >>
> > >> Here an updated version without relying on TEXT or TCHAR, directly 
> > >> calling
> > >> GetModuleHandleExW.
> > >
> > > Thanks, this LGTM (but I couldn't test it, I just looked at the
> > > sour ce code).
> >
> > Here an updated version. It is rebased on the combined approach of getting 
> > the
> > loaded DLLs and two minor changes to suppress warnings.
> 
> This bug report was filed about this patch:
> 
> https://github.com/ianlancetaylor/libbacktrace/issues/131
> 
> > src\pecoff.c(86): error C2059: syntax error: '('
> > src\pecoff.c(89): error C2059: syntax error: '('
> >
> > It works fine if deleting CALLBACK and NTAPI.
> 
> Any ideas?

Instead of deleting those, move them inside the parentheses:

typedef VOID (CALLBACK *LDR_DLL_NOTIFICATION)(ULONG,
  struct dll_notification_data*,
  PVOID);
typedef NTSTATUS (NTAPI *LDR_REGISTER_FUNCTION)(ULONG,
LDR_DLL_NOTIFICATION, PVOID,
PVOID*);

and also I think you need to include , for the definition
of the NTSTATUS type.

Caveat: I don't have MSVC, so I couldn't verify that these measures
fix the problem, sorry.

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

[Björn Schäpers]

Am 29.07.2024 um 19:58 schrieb Eli Zaretskii:

From: Ian Lance Taylor 
Date: Mon, 29 Jul 2024 09:46:46 -0700
Cc: Eli Zaretskii , gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org

On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers  wrote:


Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:

Date: Tue, 9 Jan 2024 21:02:44 +0100
Cc: i...@google.com, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
From: Björn Schäpers 

Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:

In that case, you an call either GetModuleHandeExA or
GetModuleHandeExW, the difference is minor.


Here an updated version without relying on TEXT or TCHAR, directly calling
GetModuleHandleExW.


Thanks, this LGTM (but I couldn't test it, I just looked at the
sour ce code).


Here an updated version. It is rebased on the combined approach of getting the
loaded DLLs and two minor changes to suppress warnings.


This bug report was filed about this patch:

https://github.com/ianlancetaylor/libbacktrace/issues/131


src\pecoff.c(86): error C2059: syntax error: '('
src\pecoff.c(89): error C2059: syntax error: '('

It works fine if deleting CALLBACK and NTAPI.


Any ideas?


Instead of deleting those, move them inside the parentheses:

typedef VOID (CALLBACK *LDR_DLL_NOTIFICATION)(ULONG,
  struct dll_notification_data*,
  PVOID);
typedef NTSTATUS (NTAPI *LDR_REGISTER_FUNCTION)(ULONG,
LDR_DLL_NOTIFICATION, PVOID,
PVOID*);

and also I think you need to include , for the definition
of the NTSTATUS type.

Caveat: I don't have MSVC, so I couldn't verify that these measures
fix the problem, sorry.


Moving into the parentheses does fix the issue: https://godbolt.org/z/Pe558ofYz

NTSTATUS is typedefed directly before, so that no additional include is needed.

Re: How to add an additional option to dg-compile and dg-run

[Thomas Schwinge]

Hi Thomas!

On 2024-07-29T10:18:49+0200, Thomas Koenig via Gcc  wrote:
> for the fortran-unsigned branch

By the way: I did see your recent announcement; wow -- Fortran finally
getting an UNSIGNED type!  :-)

> I would like to be able to run all
> existing Fortran tests also with -funsigned, to make sure the option
> does not break anything on existing code.
>
> Question is: How?
>
> I came as far as
>
> $ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
>
> but that causes testsuite failures because C does not recognize
> the option.
>
> Any other possibilites?

Hard-code it to enabled in 'gcc/fortran/lang.opt'...  ;-)

Or: '-Wno-complain-wrong-lang' ought to help your case:

$ make check-fortran 
RUNTESTFLAGS="--target_board=unix/-funsigned/-Wno-complain-wrong-lang"

..., which I added for a very similar scenario, a while ago.  (See

"[PING, v2] Add '-Wno-complain-wrong-lang', and use it in 
'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere".)


However, be prepared that the baseline:

$ make check-fortran 
RUNTESTFLAGS="--target_board=unix/-Wno-complain-wrong-lang"

... may have a number of "false FAILs".  For example (random),
'gfortran.dg/c-interop/allocate-errors.f90':

! { dg-additional-sources "allocate-errors-c.c dump-descriptors.c" }
! { dg-additional-options "-Wno-error -fcheck=all" }
! { dg-warning "command-line option '-fcheck=all' is valid for Fortran but 
not for C" "" { target *-*-* } 0 }

That 'dg-warning' will turn FAIL with '-Wno-complain-wrong-lang'.
Maybe there's a point to be made to clean all these up; replace such
'-Wno-error's and 'dg-warning's with '-Wno-complain-wrong-lang'?
Exception would be a few test cases that are meant to check
"command-line option '[...]' is valid for [...] but not for [...]"
diagnostic, which should thus get '-Wcomplain-wrong-lang' added via
'dg-additional-sources'.


Grüße
 Thomas