Enable top-level recursive 'autoreconf' (was: Hints on reconfiguring GCC)
Hi!
On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> I guess I can ask, why there is not a recursive approach for configuring
> GCC. e.g. AC_SUBDIRS in the top level?
('AC_CONFIG_SUBDIRS' you mean.) You know, often it just takes someone to
ask the right questions... ;-)
What do people think about the attached
"Enable top-level recursive 'autoreconf'"? Only lightly tested, so far.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From 43127e5643337ca407071ad93bccbc716024352e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 19 Oct 2023 10:28:30 +0200
Subject: [PATCH] Enable top-level recursive 'autoreconf'
* configure.ac: At end of file, instantiate 'AC_CONFIG_SUBDIRS'
for all relevant directories.
* configure: Regenerate.
---
configure| 102 ++-
configure.ac | 36 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 8fc163d36bd..fcb4d591334 100755
--- a/configure
+++ b/configure
@@ -584,7 +584,8 @@ PACKAGE_URL=
ac_unique_file="move-if-change"
enable_option_checking=no
-ac_subst_vars='LTLIBOBJS
+ac_subst_vars='subdirs
+LTLIBOBJS
LIBOBJS
compare_exclusions
stage2_werror_flag
@@ -909,7 +910,37 @@ READELF_FOR_TARGET
STRIP_FOR_TARGET
WINDRES_FOR_TARGET
WINDMC_FOR_TARGET'
-
+ac_subdirs_all='c++tools
+fixincludes
+gcc
+gcc/m2
+gnattools
+gotools
+intl
+libada
+libatomic
+libbacktrace
+libcc1
+libcody
+libcpp
+libdecnumber
+libffi
+libgcc
+libgfortran
+libgm2
+libgo
+libgomp
+libiberty
+libitm
+libobjc
+libphobos
+libquadmath
+libsanitizer
+libssp
+libstdc++-v3
+libvtv
+lto-plugin
+zlib'
# Initialize some variables set by options.
ac_init_help=
@@ -20081,3 +20112,70 @@ if test -n "$ac_unrecognized_opts" && test "$enable_option_checking" != no; then
$as_echo "$as_me: WARNING: unrecognized options: $ac_unrecognized_opts" >&2;}
fi
+
+# Enable top-level recursive 'autoreconf' by enumerating all relevant
+# directories here. This is intentionally done at end of 'configure.ac',
+# *after* 'AC_OUTPUT', so that we don't attempt to prematurely 'configure'
+# these directories when the top-level 'configure' is invoked.
+subdirs="$subdirs c++tools"
+
+subdirs="$subdirs fixincludes"
+
+subdirs="$subdirs gcc"
+
+subdirs="$subdirs gcc/m2"
+
+subdirs="$subdirs gnattools"
+
+subdirs="$subdirs gotools"
+
+subdirs="$subdirs intl"
+
+subdirs="$subdirs libada"
+
+subdirs="$subdirs libatomic"
+
+subdirs="$subdirs libbacktrace"
+
+subdirs="$subdirs libcc1"
+
+subdirs="$subdirs libcody"
+
+subdirs="$subdirs libcpp"
+
+subdirs="$subdirs libdecnumber"
+
+subdirs="$subdirs libffi"
+
+subdirs="$subdirs libgcc"
+
+subdirs="$subdirs libgfortran"
+
+subdirs="$subdirs libgm2"
+
+subdirs="$subdirs libgo"
+
+subdirs="$subdirs libgomp"
+
+subdirs="$subdirs libiberty"
+
+subdirs="$subdirs libitm"
+
+subdirs="$subdirs libobjc"
+
+subdirs="$subdirs libphobos"
+
+subdirs="$subdirs libquadmath"
+
+subdirs="$subdirs libsanitizer"
+
+subdirs="$subdirs libssp"
+
+subdirs="$subdirs libstdc++-v3"
+
+subdirs="$subdirs libvtv"
+
+subdirs="$subdirs lto-plugin"
+
+subdirs="$subdirs zlib"
+
diff --git a/configure.ac b/configure.ac
index 1d16530140a..0d37d30196e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3944,3 +3944,39 @@ AC_CONFIG_FILES([Makefile],
extrasub_host="$extrasub_host"
extrasub_target="$extrasub_target"])
AC_OUTPUT
+
+# Enable top-level recursive 'autoreconf' by enumerating all relevant
+# directories here. This is intentionally done at end of 'configure.ac',
+# *after* 'AC_OUTPUT', so that we don't attempt to prematurely 'configure'
+# these directories when the top-level 'configure' is invoked.
+AC_CONFIG_SUBDIRS([c++tools])
+AC_CONFIG_SUBDIRS([fixincludes])
+AC_CONFIG_SUBDIRS([gcc])
+AC_CONFIG_SUBDIRS([gcc/m2])
+AC_CONFIG_SUBDIRS([gnattools])
+AC_CONFIG_SUBDIRS([gotools])
+AC_CONFIG_SUBDIRS([intl])
+AC_CONFIG_SUBDIRS([libada])
+AC_CONFIG_SUBDIRS([libatomic])
+AC_CONFIG_SUBDIRS([libbacktrace])
+AC_CONFIG_SUBDIRS([libcc1])
+AC_CONFIG_SUBDIRS([libcody])
+AC_CONFIG_SUBDIRS([libcpp])
+AC_CONFIG_SUBDIRS([libdecnumber])
+AC_CONFIG_SUBDIRS([libffi])
+AC_CONFIG_SUBDIRS([libgcc])
+AC_CONFIG_SUBDIRS([libgfortran])
+AC_CONFIG_SUBDIRS([libgm2])
+AC_CONFIG_SUBDIRS([libgo])
+AC_CONFIG_SUBDIRS([libgomp])
+AC_CONFIG_SUBDIRS([libiberty])
+AC_CONFIG_SUBDIRS([libitm])
+AC_CONFIG_SUBDIRS([libobjc])
+AC_CONFIG_SUBDIRS([libphobos])
+AC_CONFIG_SUBDIRS([libquadmath])
+AC_CONFIG_SUBDIRS([libsanitizer])
+AC_CONFIG_SUBDIRS([libssp])
+AC_CONFIG_SUBDIRS([libstdc++-v3])
+AC_CONFIG_SUBDIRS([libvtv])
+AC_CONFIG_SUBDIRS([lto-plugin])
+AC_CONFIG_SUBDIRS([zlib])
--
2.34.1
Re: Enable top-level recursive 'autoreconf'
On Okt 19 2023, Thomas Schwinge wrote:
> Hi!
>
> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
>> I guess I can ask, why there is not a recursive approach for configuring
>> GCC. e.g. AC_SUBDIRS in the top level?
>
> ('AC_CONFIG_SUBDIRS' you mean.) You know, often it just takes someone to
> ask the right questions... ;-)
>
> What do people think about the attached
> "Enable top-level recursive 'autoreconf'"? Only lightly tested, so far.
The top-level files are shared with binutils-gdb, which has a different
set of subdirs.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: Enable top-level recursive 'autoreconf'
Hi!
On 2023-10-19T11:57:33+0200, Andreas Schwab wrote:
> On Okt 19 2023, Thomas Schwinge wrote:
>> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
>>> I guess I can ask, why there is not a recursive approach for configuring
>>> GCC. e.g. AC_SUBDIRS in the top level?
>>
>> ('AC_CONFIG_SUBDIRS' you mean.) You know, often it just takes someone to
>> ask the right questions... ;-)
>>
>> What do people think about the attached
>> "Enable top-level recursive 'autoreconf'"? Only lightly tested, so far.
>
> The top-level files are shared with binutils-gdb, which has a different
> set of subdirs.
Good point, thanks! Fortunately, the failure mode for non-existing
directories is non-fatal (skipped with 'subdirectory [...] not present'
diagnostic); with my original "Enable top-level recursive 'autoreconf'"
(also re-attached) applied to Binutils/GDB Git master branch, we get:
$ PATH=[...] autoreconf -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: subdirectory c++tools not present
autoreconf: configure.ac: subdirectory fixincludes not present
autoreconf: configure.ac: subdirectory gcc not present
autoreconf: configure.ac: subdirectory gcc/m2 not present
autoreconf: configure.ac: subdirectory gnattools not present
autoreconf: configure.ac: subdirectory gotools not present
autoreconf: configure.ac: adding subdirectory intl to autoreconf
autoreconf: Entering directory `intl'
[...]
autoreconf: Leaving directory `intl'
autoreconf: configure.ac: subdirectory libada not present
autoreconf: configure.ac: subdirectory libatomic not present
autoreconf: configure.ac: adding subdirectory libbacktrace to autoreconf
autoreconf: Entering directory `libbacktrace'
[...]
So we could (a) simply list *all* directories in the shared top-level
'configure.ac', or (b) configure GCC vs. other projrcts via a non-shared
file ('m4_include([config/AC_CONFIG_SUBDIRS.m4])' or similar -- is there
an established procedure for non-shared top-level files)? (I don't have
a strong preference either way.)
It's just GCC and Binutils/GDB, or are the top-level files also shared
with additional projects?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From 43127e5643337ca407071ad93bccbc716024352e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 19 Oct 2023 10:28:30 +0200
Subject: [PATCH] Enable top-level recursive 'autoreconf'
* configure.ac: At end of file, instantiate 'AC_CONFIG_SUBDIRS'
for all relevant directories.
* configure: Regenerate.
---
configure| 102 ++-
configure.ac | 36 ++
2 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 8fc163d36bd..fcb4d591334 100755
--- a/configure
+++ b/configure
@@ -584,7 +584,8 @@ PACKAGE_URL=
ac_unique_file="move-if-change"
enable_option_checking=no
-ac_subst_vars='LTLIBOBJS
+ac_subst_vars='subdirs
+LTLIBOBJS
LIBOBJS
compare_exclusions
stage2_werror_flag
@@ -909,7 +910,37 @@ READELF_FOR_TARGET
STRIP_FOR_TARGET
WINDRES_FOR_TARGET
WINDMC_FOR_TARGET'
-
+ac_subdirs_all='c++tools
+fixincludes
+gcc
+gcc/m2
+gnattools
+gotools
+intl
+libada
+libatomic
+libbacktrace
+libcc1
+libcody
+libcpp
+libdecnumber
+libffi
+libgcc
+libgfortran
+libgm2
+libgo
+libgomp
+libiberty
+libitm
+libobjc
+libphobos
+libquadmath
+libsanitizer
+libssp
+libstdc++-v3
+libvtv
+lto-plugin
+zlib'
# Initialize some variables set by options.
ac_init_help=
@@ -20081,3 +20112,70 @@ if test -n "$ac_unrecognized_opts" && test "$enable_option_checking" != no; then
$as_echo "$as_me: WARNING: unrecognized options: $ac_unrecognized_opts" >&2;}
fi
+
+# Enable top-level recursive 'autoreconf' by enumerating all relevant
+# directories here. This is intentionally done at end of 'configure.ac',
+# *after* 'AC_OUTPUT', so that we don't attempt to prematurely 'configure'
+# these directories when the top-level 'configure' is invoked.
+subdirs="$subdirs c++tools"
+
+subdirs="$subdirs fixincludes"
+
+subdirs="$subdirs gcc"
+
+subdirs="$subdirs gcc/m2"
+
+subdirs="$subdirs gnattools"
+
+subdirs="$subdirs gotools"
+
+subdirs="$subdirs intl"
+
+subdirs="$subdirs libada"
+
+subdirs="$subdirs libatomic"
+
+subdirs="$subdirs libbacktrace"
+
+subdirs="$subdirs libcc1"
+
+subdirs="$subdirs libcody"
+
+subdirs="$subdirs libcpp"
+
+subdirs="$subdirs libdecnumber"
+
+subdirs="$subdirs libffi"
+
+subdirs="$subdirs libgcc"
+
+subdirs="$subdirs libgfortran"
+
+subdirs="$subdirs libgm2"
+
+subdirs="$subdirs libgo"
+
+subdirs="$subdirs libgomp"
+
+subdirs="$subdirs libiberty"
+
+subdirs=
gcc 13.2 is missing warnings?
I am using gcc 13.2 on Fedora 38. Consider the following program.
#include
int main(int argc, char **argv)
{
printf("Enter a number: ");
int num = 0;
scanf("%d", &num);
switch (num)
{
case 1:
int a = num + 3;
printf("The new number is %d.\n", a);
break;
case 2:
int b = num - 4;
printf("The new number is %d.\n", b);
break;
default:
int c = num * 3;
printf("The new number is %d.\n", c);
break;
}
}
I would expect that gcc would complain about the declaration of
variables (a, b, and c) within the case statements. When I run "gcc
-Wall t.c" I get no warnings. When I run "g++ -Wall t.c" I get
warnings and errors as expected. I do get warnings when using MinGW on
Windows (gcc version 6.3 specifically). Did something change in 13.2?
Eric
Re: gcc 13.2 is missing warnings?
GCC supports this as an extension.
Mixing declarations and code is allowed in C99 and C23
will also allow placing labels before declarations and at
the end of a compound statement. GCC supports all this
also in earlier language modes.
See:
https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-Declarations.html
You will get the warnings with -pedantic.
Martin
Am Donnerstag, dem 19.10.2023 um 07:39 -0400 schrieb Eric Sokolowsky via Gcc:
> I am using gcc 13.2 on Fedora 38. Consider the following program.
>
> #include
> int main(int argc, char **argv)
> {
> printf("Enter a number: ");
> int num = 0;
> scanf("%d", &num);
>
> switch (num)
> {
> case 1:
> int a = num + 3;
> printf("The new number is %d.\n", a);
> break;
> case 2:
> int b = num - 4;
> printf("The new number is %d.\n", b);
> break;
> default:
> int c = num * 3;
> printf("The new number is %d.\n", c);
> break;
> }
> }
>
> I would expect that gcc would complain about the declaration of
> variables (a, b, and c) within the case statements. When I run "gcc
> -Wall t.c" I get no warnings. When I run "g++ -Wall t.c" I get
> warnings and errors as expected. I do get warnings when using MinGW on
> Windows (gcc version 6.3 specifically). Did something change in 13.2?
>
> Eric
Re: gcc 13.2 is missing warnings?
Note that the C++ warning is for jumping over a declaration,
which is generally allowed in C but not in C++.
Martin
Am Donnerstag, dem 19.10.2023 um 13:49 +0200 schrieb Martin Uecker:
>
>
> GCC supports this as an extension.
>
> Mixing declarations and code is allowed in C99 and C23
> will also allow placing labels before declarations and at
> the end of a compound statement. GCC supports all this
> also in earlier language modes.
>
> See:
> https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-Declarations.html
>
> You will get the warnings with -pedantic.
>
> Martin
>
> Am Donnerstag, dem 19.10.2023 um 07:39 -0400 schrieb Eric Sokolowsky via Gcc:
> > I am using gcc 13.2 on Fedora 38. Consider the following program.
> >
> > #include
> > int main(int argc, char **argv)
> > {
> > printf("Enter a number: ");
> > int num = 0;
> > scanf("%d", &num);
> >
> > switch (num)
> > {
> > case 1:
> > int a = num + 3;
> > printf("The new number is %d.\n", a);
> > break;
> > case 2:
> > int b = num - 4;
> > printf("The new number is %d.\n", b);
> > break;
> > default:
> > int c = num * 3;
> > printf("The new number is %d.\n", c);
> > break;
> > }
> > }
> >
> > I would expect that gcc would complain about the declaration of
> > variables (a, b, and c) within the case statements. When I run "gcc
> > -Wall t.c" I get no warnings. When I run "g++ -Wall t.c" I get
> > warnings and errors as expected. I do get warnings when using MinGW on
> > Windows (gcc version 6.3 specifically). Did something change in 13.2?
> >
> > Eric
>
Re: gcc 13.2 is missing warnings?
On 19/10/2023 12:39, Eric Sokolowsky via Gcc wrote:
I am using gcc 13.2 on Fedora 38. Consider the following program.
#include
int main(int argc, char **argv)
{
printf("Enter a number: ");
int num = 0;
scanf("%d", &num);
switch (num)
{
case 1:
int a = num + 3;
printf("The new number is %d.\n", a);
break;
case 2:
int b = num - 4;
printf("The new number is %d.\n", b);
break;
default:
int c = num * 3;
printf("The new number is %d.\n", c);
break;
}
}
I would expect that gcc would complain about the declaration of
variables (a, b, and c) within the case statements. When I run "gcc
-Wall t.c" I get no warnings. When I run "g++ -Wall t.c" I get
warnings and errors as expected. I do get warnings when using MinGW on
Windows (gcc version 6.3 specifically). Did something change in 13.2?
Eric
The analysis needed to generate useful warnings is often not run unless
the optimizers are enabled. Try adding -O, or even higher. -O0 is
generally only recommended for syntax checking.
R.
Re: the elimination of if blocks in GCC during if-conversion and vectorization
On Tue, Oct 17, 2023 at 2:39 PM Hanke Zhang wrote:
>
> Hi Richard
> I get it, thank you again.
>
> And I got another problem, so I'd like ask it by the way. Can the left
> shift of the induction variable in a loop be optimized as a constant?
> Like the code below:
>
> int ans = 0;
> int width = rand() % 16;
> for (int j = 0; j < width; j++)
> ans += 1 << (j + width)
>
> into:
>
> int width = rand() % 16;
> ans = (1 << (2 * width) - (1 << width));
>
> I came across a more complex version of that and found that gcc
> doesn't seem to handle it, so wanted to write a pass myself to
> optimize it.
>
> I got two questions here. Does GCC have such optimizations? If I want
> to do my own optimization, where should I put it? Put it behind the
> pass_iv_optimize?
GCC has the final value replacement pass (pass_scev_cprop) doing these
kind of transforms. Since 'ans' does not have an affine evolution this
case would need to be pattern matched (there are some existing pattern
matchings in the pass).
> Thanks
> Hanke Zhang
>
> Richard Biener 于2023年10月17日周二 20:00写道：
> >
> > On Tue, Oct 17, 2023 at 1:54 PM Hanke Zhang wrote:
> > >
> > > Richard Biener 于2023年10月17日周二 17:26写道：
> > > >
> > > > On Thu, Oct 12, 2023 at 2:18 PM Hanke Zhang via Gcc
> > > > wrote:
> > > > >
> > > > > Hi, I'm recently working on vectorization of GCC. I'm stuck in a small
> > > > > problem and would like to ask for advice.
> > > > >
> > > > > For example, for the following code:
> > > > >
> > > > > int main() {
> > > > > int size = 1000;
> > > > > int *foo = malloc(sizeof(int) * size);
> > > > > int c1 = rand(), t1 = rand();
> > > > >
> > > > > for (int i = 0; i < size; i++) {
> > > > > if (foo[i] & c1) {
> > > > > foo[i] = t1;
> > > > > }
> > > > > }
> > > > >
> > > > > // prevents the loop above from being optimized
> > > > > for (int i = 0; i < size; i++) {
> > > > > printf("%d", foo[i]);
> > > > > }
> > > > > }
> > > > >
> > > > > First of all, the if statement block in the loop will be converted to
> > > > > a MASK_STORE through if-conversion optimization. But after
> > > > > tree-vector, it will still become a branched form. The part of the
> > > > > final disassembly structure probably looks like below(Using IDA to do
> > > > > this), and you can see that there is still such a branch 'if ( !_ZF )'
> > > > > in it, which will lead to low efficiency.
> > > > >
> > > > > do
> > > > > {
> > > > > while ( 1 )
> > > > > {
> > > > > __asm
> > > > > {
> > > > > vpand ymm0, ymm2, ymmword ptr [rax]
> > > > > vpcmpeqd ymm0, ymm0, ymm1
> > > > > vpcmpeqd ymm0, ymm0, ymm1
> > > > > vptest ymm0, ymm0
> > > > > }
> > > > > if ( !_ZF )
> > > > > break;
> > > > > _RAX += 8;
> > > > > if ( _RAX == v9 )
> > > > > goto LABEL_5;
> > > > > }
> > > > > __asm { vpmaskmovd ymmword ptr [rax], ymm0, ymm3 }
> > > > > _RAX += 8;
> > > > > }
> > > > > while ( _RAX != v9 );
> > > > >
> > > > > Why can't we just replace the vptest and if statement with some other
> > > > > instructions like vpblendvb so that it can be faster? Or is there a
> > > > > good way to do that?
> > > >
> > > > The branch is added by optimize_mask_stores after vectorization because
> > > > fully masked (disabled) masked stores can incur a quite heavy penalty on
> > > > some architectures when fault assists (read-only pages, but also COW
> > > > pages)
> > > > are ran into. All the microcode handling needs to possibly be carried
> > > > out
> > > > multiple times, for each such access to the same page. That can cause
> > > > a 1000x slowdown when you hit this case. Thus every masked store
> > > > is replaced by
> > > >
> > > > if (mask != 0)
> > > >masked_store ();
> > > >
> > > > and this is an optimization (which itself has a small cost).
> > > >
> > > > Richard.
> > >
> > > Yeah, I know that and I have seen the code of optimize_mask_store().
> > > And the main problem here is that when multiple MASK_STORE appear in
> > > the same loop, many branches will appear, resulting in a decrease in
> > > overall efficiency.
> > >
> > > And my original idea is that why can't we replace MASK_STORE with more
> > > effective SIMD instructions because icc can do much better in this
> > > case.
> >
> > ICC probably doesn't care for the case where foo[] isn't writable. In
> > fact for the case at hand we see it comes from malloc() which we
> > can assume to return writable memory I guess. That means if-conversion
> > can treat the unconditional read as a way to also allow to speculate
> > the write (with -fallow-store-data-races).
> >
> > Note there's currently no pointer analysis that tracks writability.
> >
> > > Then I give it up, because the ability to analyze vectorization
> > > of gcc is not as good as icc and my ability does not support me
> > > modifying this part of the code.
> > >
> > > Thanks very much for your reply.
> >
> > You're welc
Re: gcc 13.2 is missing warnings?
Thank you for your message. Indeed, the -pedantic flag gives me the
warning I expect. -O (as suggested in another response) does not.
Eric
On Thu, Oct 19, 2023 at 7:49 AM Martin Uecker wrote:
>
>
>
>
> GCC supports this as an extension.
>
> Mixing declarations and code is allowed in C99 and C23
> will also allow placing labels before declarations and at
> the end of a compound statement. GCC supports all this
> also in earlier language modes.
>
> See:
> https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-Declarations.html
>
> You will get the warnings with -pedantic.
>
> Martin
>
> Am Donnerstag, dem 19.10.2023 um 07:39 -0400 schrieb Eric Sokolowsky via Gcc:
> > I am using gcc 13.2 on Fedora 38. Consider the following program.
> >
> > #include
> > int main(int argc, char **argv)
> > {
> > printf("Enter a number: ");
> > int num = 0;
> > scanf("%d", &num);
> >
> > switch (num)
> > {
> > case 1:
> > int a = num + 3;
> > printf("The new number is %d.\n", a);
> > break;
> > case 2:
> > int b = num - 4;
> > printf("The new number is %d.\n", b);
> > break;
> > default:
> > int c = num * 3;
> > printf("The new number is %d.\n", c);
> > break;
> > }
> > }
> >
> > I would expect that gcc would complain about the declaration of
> > variables (a, b, and c) within the case statements. When I run "gcc
> > -Wall t.c" I get no warnings. When I run "g++ -Wall t.c" I get
> > warnings and errors as expected. I do get warnings when using MinGW on
> > Windows (gcc version 6.3 specifically). Did something change in 13.2?
> >
> > Eric
>
Arm assembler crc issue
Hi Richard, I am being bitten by a problem that falls out from the code that emits .arch Armv8.n-a+crc when the arch is less than Armv8-r. The code that does this, in gcc/common/config/aarch64 is quite recent (2022-09). -- (I admit the permutations are complex and I might have miss-analyzed) - but it appears that llvm assembler (for mach-o, at least) sees an explict mention of an attribute for a feature which is mandatory at a specified arch level as demoting that arch to the minimum that made the explicit feature mandatory. Of course, it could just be a bug in the handling of transitive feature enables... the problem is that, for example: .arch Armv8.4-a+crc no longer recognises fp16 insns. (and appending +fp16 does not fix this). Even if upstream LLVM is deemed to be buggy (it does not do what I would expect, at least), and fixed - I will still have a bunch of assembler versions that are broken (before the fix percolates through to downstream xcode) - and the LLVM assembler is the only current option for Darwin. So, it seems that this ought to be a reasonable configure test: .arch armv8.2-a .text m: crc32b w0, w1, w2 and then emit HAS_GAS_AARCH64_CRC_BUG (for example) if that fails to assemble which can be used to make the +crc emit conditional on a broken assembler. - I am asking here before constructing the patch, in case there’s some reason that doing this at configure time is not acceptable. thanks Iain
Re: Arm assembler crc issue
correction ... > On 19 Oct 2023, at 17:41, Iain Sandoe wrote: > > Hi Richard, > > > I am being bitten by a problem that falls out from the code that emits > > .arch Armv8.n-a+crc > > when the arch is less than Armv8-r. > The code that does this, in gcc/common/config/aarch64 is quite recent > (2022-09). > > -- > > (I admit the permutations are complex and I might have miss-analyzed) - but > it appears that llvm assembler (for mach-o, at least) sees an explict mention > of an attribute for a feature which is mandatory at a specified arch level as > demoting that arch to the minimum that made the explicit feature mandatory. > Of course, it could just be a bug in the handling of transitive feature > enables... > > the problem is that, for example: > > .arch Armv8.4-a+crc We are trying to set suitable arch values for apple-a12, apple-m1 and apple-m2; apple-m1 (as far as i can determine) is armv8.4-a+fp16+sb+ssbs. However, the code mentioned emits this as: armv8.4-a+crc+fp16+sb+ssbs. and the LLVM assembler no longer recognises fp16 insns. (the appended +fp16 does not work). > > > Even if upstream LLVM is deemed to be buggy (it does not do what I would > expect, at least), and fixed - I will still have a bunch of assembler > versions that are broken (before the fix percolates through to downstream > xcode) - and the LLVM assembler is the only current option for Darwin. > > So, it seems that this ought to be a reasonable configure test: > > .arch armv8.2-a > .text > m: > crc32b w0, w1, w2 > > and then emit HAS_GAS_AARCH64_CRC_BUG (for example) if that fails to assemble > which can be used to make the +crc emit conditional on a broken assembler. > > - I am asking here before constructing the patch, in case there’s some reason > that doing this at configure time is not acceptable. > > thanks > Iain >
Re: Arm assembler crc issue
Iain Sandoe writes: > Hi Richard, > > > I am being bitten by a problem that falls out from the code that emits > > .arch Armv8.n-a+crc > > when the arch is less than Armv8-r. > The code that does this, in gcc/common/config/aarch64 is quite recent > (2022-09). Heh. A workaround for one assembler bug triggers another assembler bug. The special treatment of CRC is much older than 2022-09 though. I think it dates back to 04a99ebecee885e42e56b6e0c832570e2a91c196 (2016-04), with 4ca82fc9f86fc1187ee112e3a637cb3ca5d2ef2a providing the more complete explanation. > > -- > > (I admit the permutations are complex and I might have miss-analyzed) - but > it appears that llvm assembler (for mach-o, at least) sees an explict mention > of an attribute for a feature which is mandatory at a specified arch level as > demoting that arch to the minimum that made the explicit feature mandatory. > Of course, it could just be a bug in the handling of transitive feature > enables... > > the problem is that, for example: > > .arch Armv8.4-a+crc > > no longer recognises fp16 insns. (and appending +fp16 does not fix this). > > > > Even if upstream LLVM is deemed to be buggy (it does not do what I would > expect, at least), and fixed - I will still have a bunch of assembler > versions that are broken (before the fix percolates through to downstream > xcode) - and the LLVM assembler is the only current option for Darwin. > > So, it seems that this ought to be a reasonable configure test: > > .arch armv8.2-a > .text > m: > crc32b w0, w1, w2 > > and then emit HAS_GAS_AARCH64_CRC_BUG (for example) if that fails to assemble > which can be used to make the +crc emit conditional on a broken assembler. AIUI the problem was in the CPU descriptions, so I don't think this would test for the old gas bug that is being worked around. Perhaps instead we could have a configure test for the bug that you've found, and disable the crc workaround if so? Thanks, Richard > > - I am asking here before constructing the patch, in case there’s some reason > that doing this at configure time is not acceptable. > > thanks > Iain
Re: Arm assembler crc issue
Hi Richard, > On 19 Oct 2023, at 22:49, Richard Sandiford wrote: > Iain Sandoe writes: >> I am being bitten by a problem that falls out from the code that emits >> >> .arch Armv8.n-a+crc >> >> when the arch is less than Armv8-r. >> The code that does this, in gcc/common/config/aarch64 is quite recent >> (2022-09). > > Heh. A workaround for one assembler bug triggers another assembler bug. Indeed … the good news is that the LLVM bug seems fixed on current release (17) and main. The bad news is that it will likely take some to percolate through (and it won’t help released toolsets anyway). >> So, it seems that this ought to be a reasonable configure test: >> >> .arch armv8.2-a >> .text >> m: >> crc32b w0, w1, w2 >> >> and then emit HAS_GAS_AARCH64_CRC_BUG (for example) if that fails to >> assemble which can be used to make the +crc emit conditional on a broken >> assembler. > > AIUI the problem was in the CPU descriptions, so I don't think this > would test for the old gas bug that is being worked around. I see, > Perhaps instead we could have a configure test for the bug that you've > found, and disable the crc workaround if so? OK - I’ll work in that direction, thanks Iain > > Thanks, > Richard > >> >> - I am asking here before constructing the patch, in case there’s some >> reason that doing this at configure time is not acceptable. >> >> thanks >> Iain
gcc-11-20231019 is now available
Snapshot gcc-11-20231019 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20231019/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 71f2b05f8f494b34d2db4b90683ef76ec338bb19 You'll find: gcc-11-20231019.tar.xz Complete GCC SHA256=5139731854dda6797c76b9b1c1b7ccde080fae1e2d99ba962beb078638db2ab0 SHA1=a8398f30ec58dca73ced1a985907835fcb8a Diffs from 11-20231012 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: gcc 13.2 is missing warnings?
On Thu, Oct 19, 2023 at 7:52 AM Martin Uecker wrote:
>
>
>
> Note that the C++ warning is for jumping over a declaration,
> which is generally allowed in C but not in C++.
>
> Martin
(Also note that in C, there's -Wjump-misses-init for this, which is
enabled by -Wc++-compat, which isn't enabled by anything else, and has
to be requested manually)
>
> Am Donnerstag, dem 19.10.2023 um 13:49 +0200 schrieb Martin Uecker:
> >
> >
> > GCC supports this as an extension.
> >
> > Mixing declarations and code is allowed in C99 and C23
> > will also allow placing labels before declarations and at
> > the end of a compound statement. GCC supports all this
> > also in earlier language modes.
> >
> > See:
> > https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-Declarations.html
> >
> > You will get the warnings with -pedantic.
> >
> > Martin
> >
> > Am Donnerstag, dem 19.10.2023 um 07:39 -0400 schrieb Eric Sokolowsky via
> > Gcc:
> > > I am using gcc 13.2 on Fedora 38. Consider the following program.
> > >
> > > #include
> > > int main(int argc, char **argv)
> > > {
> > > printf("Enter a number: ");
> > > int num = 0;
> > > scanf("%d", &num);
> > >
> > > switch (num)
> > > {
> > > case 1:
> > > int a = num + 3;
> > > printf("The new number is %d.\n", a);
> > > break;
> > > case 2:
> > > int b = num - 4;
> > > printf("The new number is %d.\n", b);
> > > break;
> > > default:
> > > int c = num * 3;
> > > printf("The new number is %d.\n", c);
> > > break;
> > > }
> > > }
> > >
> > > I would expect that gcc would complain about the declaration of
> > > variables (a, b, and c) within the case statements. When I run "gcc
> > > -Wall t.c" I get no warnings. When I run "g++ -Wall t.c" I get
> > > warnings and errors as expected. I do get warnings when using MinGW on
> > > Windows (gcc version 6.3 specifically). Did something change in 13.2?
> > >
> > > Eric
> >
>
Re: Enable top-level recursive 'autoreconf'
On Thu, Oct 19, 2023 at 6:43 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2023-10-19T11:57:33+0200, Andreas Schwab wrote:
> > On Okt 19 2023, Thomas Schwinge wrote:
> >> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> >>> I guess I can ask, why there is not a recursive approach for configuring
> >>> GCC. e.g. AC_SUBDIRS in the top level?
> >>
> >> ('AC_CONFIG_SUBDIRS' you mean.) You know, often it just takes someone to
> >> ask the right questions... ;-)
> >>
> >> What do people think about the attached
> >> "Enable top-level recursive 'autoreconf'"? Only lightly tested, so far.
> >
> > The top-level files are shared with binutils-gdb, which has a different
> > set of subdirs.
>
> Good point, thanks! Fortunately, the failure mode for non-existing
> directories is non-fatal (skipped with 'subdirectory [...] not present'
> diagnostic); with my original "Enable top-level recursive 'autoreconf'"
> (also re-attached) applied to Binutils/GDB Git master branch, we get:
>
> $ PATH=[...] autoreconf -v
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: subdirectory c++tools not present
> autoreconf: configure.ac: subdirectory fixincludes not present
> autoreconf: configure.ac: subdirectory gcc not present
> autoreconf: configure.ac: subdirectory gcc/m2 not present
> autoreconf: configure.ac: subdirectory gnattools not present
> autoreconf: configure.ac: subdirectory gotools not present
> autoreconf: configure.ac: adding subdirectory intl to autoreconf
> autoreconf: Entering directory `intl'
> [...]
> autoreconf: Leaving directory `intl'
> autoreconf: configure.ac: subdirectory libada not present
> autoreconf: configure.ac: subdirectory libatomic not present
> autoreconf: configure.ac: adding subdirectory libbacktrace to autoreconf
> autoreconf: Entering directory `libbacktrace'
> [...]
>
> So we could (a) simply list *all* directories in the shared top-level
> 'configure.ac', or (b) configure GCC vs. other projrcts via a non-shared
> file ('m4_include([config/AC_CONFIG_SUBDIRS.m4])' or similar -- is there
> an established procedure for non-shared top-level files)? (I don't have
> a strong preference either way.)
>
I'd just like to note that I have GCC bug 103459 open about silencing
warnings from autoreconf:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103459
Although I guess in this case, they're just notices, and not warnings,
so it's probably okay. (-Werror doesn't turn them into errors, does
it?)
> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
>
>
> Grüße
> Thomas
>
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
> München, HRB 106955
Re: Enable top-level recursive 'autoreconf'
On Oct 19, 2023, Thomas Schwinge wrote:
> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
>> I guess I can ask, why there is not a recursive approach for configuring
>> GCC. e.g. AC_SUBDIRS in the top level?
> ('AC_CONFIG_SUBDIRS' you mean.) You know, often it just takes someone to
> ask the right questions... ;-)
> What do people think about the attached
> "Enable top-level recursive 'autoreconf'"? Only lightly tested, so far.
Interesting idea!
It is a little hackish, in that it seems to exploit an implementation
detail in AC_CONFIG_SUBDIRS rather than a documented feature.
I like it!
The autoconf documentation suggests that optional directories can be
tested for:
if test -d "$srcdir/foo"; then
AC_CONFIG_SUBDIRS([foo])
fi
We could use a macro that takes a list and iterates over the list (untested):
dnl Handle a list of optional subdirs.
dnl After AC_OUTPUT, affects autoreconf runs, but not configure runs.
AC_DEFUN([AC_CONFIG_SUBDIRS_OPT], [
m4_foreach_w([dir], [$1], [
if test -d "$srcdir/dir"; then
AC_CONFIG_SUBDIRS(dir)
fi
])
])
Thanks,
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
