Re: Question about merging if-else blocks

[Richard Biener via Gcc]

On Wed, Sep 27, 2023 at 7:21 AM Hanke Zhang via Gcc  wrote:
>
> Thanks! I understand what you mean, then can I think that if the
> function here is not an external function, but a function visible to
> the compiler and the function doesn't modify `a`, then these two
> blocks can be merged?

Yes.  The key transform you'd see before any of the merging is
CSE of the loads from 'a', then the rest is equivalent to the local
variable case.

Richard.

> Marc Glisse  于2023年9月27日周三 12:51写道：
> >
> > On Wed, 27 Sep 2023, Hanke Zhang via Gcc wrote:
> >
> > > Hi, I have recently been working on merging if-else statement blocks,
> > > and I found a rather bizarre phenomenon that I would like to ask
> > > about.
> > > A rough explanation is that for two consecutive if-else blocks, if
> > > their if statements are exactly the same, they should be merged, like
> > > the following program:
> > >
> > > int a = atoi(argv[1]);
> > > if (a) {
> > >  printf("if 1");
> > > } else {
> > >  printf("else 1");
> > > }
> > > if (a) {
> > >  printf("if 2");
> > > } else {
> > >  printf("else 2");
> > > }
> > >
> > > After using the -O3 -flto optimization option, it can be optimized as 
> > > follows:
> > >
> > > int a = atoi(argv[1]);
> > > if (a) {
> > >  printf("if 1");
> > >  printf("if 2");
> > > } else {
> > >  printf("else 1");
> > >  printf("else 2");
> > > }
> > >
> > > But `a` here is a local variable. If I declare a as a global variable,
> > > it cannot be optimized as above. I would like to ask why this is? And
> > > is there any solution?
> >
> > If 'a' is a global variable, how do you know 'printf' doesn't modify its
> > value? (you could know it for printf, but it really depends on the
> > function that is called)
> >
> > --
> > Marc Glisse

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Anaya Shah via Gcc]

Hello,

I apologise for this problem, but I've been recieving emails regarding the
project you are working on.
However, I'm unable to understand the context of this project.
But it looks exciting!

I would be thankful if you can help me through the project framework, and
share the exact details, so that I can understand it and start working
today itself. I would also highly appreciate if you could guide me thorugh
the steps and instruct me on what I'm expected to do.
I'm currently a 3rd year B.Tech-Computer Science student.
Good day!

Thank-you,
Anaya Shah


On Wed, 27 Sept, 2023, 10:16 Florian Weimer via Gcc, 
wrote:

> * Arsen Arsenović via Gcc:
>
> > Sam James via Gcc  writes:
> >
> >> Florian Weimer via Gcc  writes:
> >>
> >>> My understanding of the consensus goes as follows:
> >>>
> >>> * We want to make some changes in this area for GCC 14.
> >>> * We should do the same thing that Clang does: default to the relevant
> >>>   -Werror= options.
> >>> * Unlike regular warnings, these warnings-as-errors should also apply
> >>>   to system headers.
> >>> * At least implict-int and implicit-function-declaration should be
> >>>   upgraded to errors in this way.
> >>> * It's too early to make the () changes and bool-as-keyword from C2X
> >>>   for GCC 14.
> >>> * We should fix the missing scope of the int-conversion warnings
> >>>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
> >>>
> >>> Is this summary accurate?
> >>>
> >>
> >> I wasn't there, but this reflects my understanding & what I would've
> >> said if I could've attended.
> >>
> >>> I think the open issues are:
> >>>
> >>> * Do we want to implement something else beside implicit-int and
> >>>   implicit-function-declaration?  (Candidates are int-conversion and
> >>>   incompatible-pointer-types, and the void vs non-void part of
> >>>   return-type, maybe others as previously discussed on the list.)
> >>
> >> Ideally, I'd like both int-conversion + incompatible-pointer-types in
> >> this cycle, but if we have to defer one, I'd say to keep int-conversion.
> >
> > +1, this seems reasonable.  I'm not sure I can imagine any even
> > half-legitimate use for falling off the end of functions and similar, so
> > perhaps we should also take return-type?  Is that part of C23?
>
> Falling of the end of the function is legitimate if a no-return function
> is called and not annotated as such, among other things.  I don't think
> we should warn or error for that by default.
>
> The issue I'm concerned about is about “return;” in a function not
> returning void, or “return expr;” in a function returning void.  This
> looks like related to implict int return types for functions.  It's not
> part of C99.  There is no separate -W switch to control this warning.
> It is on by default (as required by C99), unlike other aspects of
> -Wreturn-type.
>
> Thanks,
> Florian
>
>

After Cauldron - online mini BoFs and Fosdem

[Mark Wielaard]

Hi all,

Cauldron was really great. Seeing everybody in person again.
One item that came up was about meeting more frequently and/or in
smaller (virtual) groups.

If people want to have online mini BoFs to follow up on some discussion
they had at Cauldron, or for some periodic meetup, then please remember
that The Software Freedom Conservancy is extending the use of their Big
Blue Button instance https://bbb.sfconservancy.org/ to Sourceware
projects that want to host video meetings.

Please create an account at https://bbb.sfconservancy.org/b/signup then
contact admin-reque...@sourceware.org with the name and email you used
and the kind of project/BoF/meeting you want to run to activate the
account.

Note: Anyone is able to join a meeting, accounts are only required to
create new meetings.

Also Doji, Jose and Gwen (on CC) are trying to coordinate a Fosdem
devroom for the various projects. Please contact them if you want to
help out with that.

Cheers,

Mark

https://sfconservancy.org/news/2023/aug/15/exit-zoom/
https://fosdem.org/2024/

Re: School District Contact - 2023

[Susan Miller via Gcc]

Hi there,
We are excited to offer you a comprehensive email list of school districts that 
includes key contact information such as phone numbers, email addresses, 
mailing addresses, company revenue, size, and web addresses. Our databases also 
cover related industries such as:

  *   K-12 schools
  *   Universities
  *   Vocational schools and training programs
  *   Performing arts schools
  *   Fitness centers and gyms
  *   Child care services and providers
  *   Educational publishers and suppliers
If you're interested, we would be happy to provide you with relevant counts and 
a test file based on your specific requirements.
Thank you for your time and consideration, and please let us know if you have 
any questions or concerns.

Best regards,

Susan Miller



To remove from this mailing reply with the subject line " LEAVE US".

Re: seek advice about GCC learning

[David Brown]

On 26/09/2023 08:48, weizhe wang via Gcc wrote:

Thanks for your reply. Is there some guide for building rv32 cross compiler gcc 
? I encounter some error in the building progress.




You might find useful information here:








I can recommend google.  It took me perhaps 10 seconds to find these sites.

Test with an lto-build of libgfortran.

[Toon Moene]

Hi all,

During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the 
possibility (and hazards) of building the run time libraries for various 
compilers with -flto, enabling an -flto -static linking of programs with 
the run time library available during link time optimizations.


Today I tried that on my (AMD Ryzen 7 5800U) laptop with

gcc version 14.0.0 20230926 (experimental) [master 
r14-4282-g53daf67fd55] (GCC)


with the following "quick hack":

diff --git a/libgfortran/configure b/libgfortran/configure
index cd176b04a14..69a2b4a8881 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -5959,11 +5959,11 @@ fi
 # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC.
 have_real_17=no
 if test "x$GCC" = "xyes"; then
-  AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays 
-fno-underscoring"
+  AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays 
-fno-underscoring -flto"

   ## We like to use C11 and C99 routines when available.  This makes
   ## sure that
   ## __STDC_VERSION__ is set such that libc includes make them available.
-  AM_CFLAGS="-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition -Wextra -Wwrite-strings 
-Werror=implicit-function-declaration -Werror=vla"
+  AM_CFLAGS="-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition -Wextra -Wwrite-strings 
-Werror=implicit-function-declaration -Werror=vla -flto"

   ## Compile the following tests with the same system header contents
   ## that we'll encounter when compiling our own source files.
   CFLAGS="-std=gnu11 $CFLAGS"

The build of this compiler (languages=fortran) completed without 
problems (no test results - not enough time).


I then proceeded to build LAPACK with the following build options:

CFLAGS = -O3 -flto -flto-partition=none -static
and
FFLAGS = -O3 -flto -flto-partition=none -static

This gave the same test results of the LAPACK test suite as the build 
with the same compiler, but without an lto'd libgfortran.


The lto-ing of libgfortran did succeed, because I did get a new warning:

gfortran -O3 -flto -flto-partition=none -static  -o xlintstrfz zchkrfp.o 
zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o 
zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o 
xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a 
../../liblapack.a ../../librefblas.a

In function 'xtoa_big',
inlined from 'write_z' at 
/home/toon/compilers/gcc/libgfortran/io/write.c:1296:11,
inlined from 'formatted_transfer_scalar_write' at 
/home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4:
/home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing 
1 byte into a region of size 0 [-Wstringop-overflow=]

 1222 |   *q = '\0';
  |  ^
/home/toon/compilers/gcc/libgfortran/io/write.c: In function 
'formatted_transfer_scalar_write':
/home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset 
[34, 4294967294] into destination object 'itoa_buf' of size 33

 1291 |   char itoa_buf[GFC_XTOA_BUF_SIZE];
  |^

which was (of course) not given with a non-lto libgfortran.

The full question of "lto-ing" run time libraries is more complicated 
than just "whether it works" as those who attended the BoF will recall.


Hope this helps,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

GCC workshop at university

[Benjamin Priour via Gcc]

Hi everyone,

I'm in my final MSc year and figured after this weekend's Q&A
that I could replicate David's workshop on a smaller scale within my
university.

Would that be doable/acceptable ?
Is there any need for special licensing ? What about uploading the
session's recording afterwards ?

To Dave:
If the above is alright could I reuse some of your slides ?
I won't necessarily follow what you did, but some of them would be useful.

Cheers to you all,
Benjamin.

Re: Test with an lto-build of libgfortran.

[Jeff Law via Gcc]

On 9/27/23 12:21, Toon Moene wrote:



The lto-ing of libgfortran did succeed, because I did get a new warning:

gfortran -O3 -flto -flto-partition=none -static  -o xlintstrfz zchkrfp.o 
zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o 
zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o 
xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a 
../../liblapack.a ../../librefblas.a

In function 'xtoa_big',
     inlined from 'write_z' at 
/home/toon/compilers/gcc/libgfortran/io/write.c:1296:11,
     inlined from 'formatted_transfer_scalar_write' at 
/home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4:
/home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing 
1 byte into a region of size 0 [-Wstringop-overflow=]

  1222 |   *q = '\0';
   |  ^
/home/toon/compilers/gcc/libgfortran/io/write.c: In function 
'formatted_transfer_scalar_write':
/home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset 
[34, 4294967294] into destination object 'itoa_buf' of size 33

  1291 |   char itoa_buf[GFC_XTOA_BUF_SIZE];
   |    ^

which was (of course) not given with a non-lto libgfortran.
Yea.  This certainly can happen with LTO.  These warnings would 
definitely be something worth investigating.


Essentially the inlining enabled by LTO can expose a different set of 
diagnostics.


Jeff

Re: Test with an lto-build of libgfortran.

[Thomas Koenig via Gcc]

Hi Toon,

During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the 
possibility (and hazards) of building the run time libraries for various 
compilers with -flto, enabling an -flto -static linking of programs with 
the run time library available during link time optimizations.


This would be a big win for libgfortran, especially the array functions,
knowing that stride==1 can be a _big_ win for optimization.  This is
why LTO is such an excellent idea for Fortran in general, and for the
library in particular.

There is a PR on this with quite some discussion already,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 .

I've put you in CC of that bug, maybe we can discuss there more
in detail.

One point about the array functions: In the library, we use sort of a
ripple carry algorithm to step through the arrays.  This saves space
an is general, but the performance (esp for the most common one-and
two-dimensional arrays) can suffer.

[...]

The full question of "lto-ing" run time libraries is more complicated 
than just "whether it works" as those who attended the BoF will recall.


I didn't attend the Cauldron (but that discussion would have been
very interesting).  I think for libgfortran, a first step would be
additional work to get declarations on both sides to agree (which is
worth doing anyway).

Best regards

Thomas

Re: Test with an lto-build of libgfortran.

[Richard Biener via Gcc]

On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran
 wrote:
>
>
>
> On 9/27/23 12:21, Toon Moene wrote:
>
> >
> > The lto-ing of libgfortran did succeed, because I did get a new warning:
> >
> > gfortran -O3 -flto -flto-partition=none -static  -o xlintstrfz zchkrfp.o
> > zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o
> > zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o
> > xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a
> > ../../liblapack.a ../../librefblas.a
> > In function 'xtoa_big',
> >  inlined from 'write_z' at
> > /home/toon/compilers/gcc/libgfortran/io/write.c:1296:11,
> >  inlined from 'formatted_transfer_scalar_write' at
> > /home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4:
> > /home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing
> > 1 byte into a region of size 0 [-Wstringop-overflow=]
> >   1222 |   *q = '\0';
> >|  ^
> > /home/toon/compilers/gcc/libgfortran/io/write.c: In function
> > 'formatted_transfer_scalar_write':
> > /home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset
> > [34, 4294967294] into destination object 'itoa_buf' of size 33
> >   1291 |   char itoa_buf[GFC_XTOA_BUF_SIZE];
> >|^
> >
> > which was (of course) not given with a non-lto libgfortran.
> Yea.  This certainly can happen with LTO.  These warnings would
> definitely be something worth investigating.
>
> Essentially the inlining enabled by LTO can expose a different set of
> diagnostics.

This particular place in libgfortran has

  /* write_z, which calls xtoa_big, is called from transfer.c,
 formatted_transfer_scalar_write.  There it is passed the kind as
 argument, which means a maximum of 16.  The buffer is large
 enough, but the compiler does not know that, so shut up the
 warning here.  */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-overflow"
  *q = '\0';
#pragma GCC diagnostic pop

so obviously the #pragma doesn't survive through LTO.  Somehow I think
this is a known bug, but maybe I misremember (I think we are not streaming
any of the ad-hoc location parts).

Richard.

>
> Jeff

Re: Test with an lto-build of libgfortran.

[Andrew Pinski via Gcc]

On Wed, Sep 27, 2023 at 11:28 PM Richard Biener via Fortran
 wrote:
>
> On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran
>  wrote:
> >
> >
> >
> > On 9/27/23 12:21, Toon Moene wrote:
> >
> > >
> > > The lto-ing of libgfortran did succeed, because I did get a new warning:
> > >
> > > gfortran -O3 -flto -flto-partition=none -static  -o xlintstrfz zchkrfp.o
> > > zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o
> > > zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o
> > > xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a
> > > ../../liblapack.a ../../librefblas.a
> > > In function 'xtoa_big',
> > >  inlined from 'write_z' at
> > > /home/toon/compilers/gcc/libgfortran/io/write.c:1296:11,
> > >  inlined from 'formatted_transfer_scalar_write' at
> > > /home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4:
> > > /home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing
> > > 1 byte into a region of size 0 [-Wstringop-overflow=]
> > >   1222 |   *q = '\0';
> > >|  ^
> > > /home/toon/compilers/gcc/libgfortran/io/write.c: In function
> > > 'formatted_transfer_scalar_write':
> > > /home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset
> > > [34, 4294967294] into destination object 'itoa_buf' of size 33
> > >   1291 |   char itoa_buf[GFC_XTOA_BUF_SIZE];
> > >|^
> > >
> > > which was (of course) not given with a non-lto libgfortran.
> > Yea.  This certainly can happen with LTO.  These warnings would
> > definitely be something worth investigating.
> >
> > Essentially the inlining enabled by LTO can expose a different set of
> > diagnostics.
>
> This particular place in libgfortran has
>
>   /* write_z, which calls xtoa_big, is called from transfer.c,
>  formatted_transfer_scalar_write.  There it is passed the kind as
>  argument, which means a maximum of 16.  The buffer is large
>  enough, but the compiler does not know that, so shut up the
>  warning here.  */
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wstringop-overflow"
>   *q = '\0';
> #pragma GCC diagnostic pop
>
> so obviously the #pragma doesn't survive through LTO.  Somehow I think
> this is a known bug, but maybe I misremember (I think we are not streaming
> any of the ad-hoc location parts).

Yes it is a known bug.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 .

Thanks,
Andrew


>
> Richard.
>
> >
> > Jeff