Re: subversion status on gcc.gnu.org

[Andrew Pinski via Gcc]

On Mon, Apr 6, 2020 at 2:15 AM Andreas Schwab via Overseers
 wrote:
>
> On Apr 06 2020, Jakub Jelinek via Gcc wrote:
>
> > On Mon, Apr 06, 2020 at 10:46:34AM +0200, Martin Liška wrote:
> >> On 4/6/20 10:37 AM, Jakub Jelinek wrote:
> >> > On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote:
> >> > > On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:
> >> > > > Hi -
> >> > > >
> >> > > > Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, 
> >> > > > we
> >> > > > have all the svn r# redirects working, and faster than before.
> >> > >
> >> > > Great. Thank you application of the RewriteMap!
> >> >
> >> > E.g. https://gcc.gnu.org/r105377 or https://gcc.gnu.org/r12345
> >> > don't work.
> >>
> >> These look not valid by svn-rev:
> >>
> >> $ git svn-rev 105377 | wc -l
> >> 0
> >> $ git svn-rev 12345 | wc -l
> >> 0
> >
> > Dunno about the latter, but the former then looks like a repo conversion
> > bug:
> > https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01053.html
> > (that is the first commit to svn after cvs conversion).
>
> This is strange.  Accoding to "svn diff -c 105377
> svn://gcc.gnu.org/svn/gcc" this is a revision on
> branches/libstdcxx_so_7-branch.  There is also a gap between r105390 and
> r105927 on the gcc-cvs archive, where the latter is the first revision
> that agrees with the online repository.

>From what I can tell is
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01053.html to
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01066.html was done a
testing SVN repo.  The first real commit to the final SVN conversion
was done at https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01067.html
BUT the hooks were not converted over by the repo conversion so
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01068.html was the
first real commit; that is

That is r105377 till r105390 was only ever done on a test SVN repo and
r105927 (hooks) was the first commit to SVN after the conversion from
CVS and r105928 was the first commit to SVN  that is visable in GIT
(SVN hooks history did not copy over).

Thanks,
Andrew Pinski
.

>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

scalar_storage_order question

[Andrew Pinski via Gcc]

Hi all (and Eric),
  I have a question about scalar_storage_order and support of type
punning between types that have different byte order.
Take:
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;

#define __big_endian__ scalar_storage_order("big-endian")
#define __little_endian__ scalar_storage_order("little-endian")

typedef union {
uint32_t val;
uint8_t v[4];
} __attribute__((__big_endian__)) upal_u32be_t;

typedef union {
uint32_t val;
uint8_t v[4];
} __attribute__((__little_endian__)) upal_u32le_t;

static inline uint32_t native_to_big_endian(uint32_t t)
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
return t;
#else
return __builtin_bswap32(t);
#endif
}
static inline uint32_t native_to_little_endian(uint32_t t)
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
return __builtin_bswap32(t);
#else
return t;
#endif
}
void link_error(void);

#ifndef __OPTIMIZE__
void link_error(void)
{
  __builtin_abort ();
}
#endif

#define test(p, p1, i) do { if (p[i] != p1[i]) link_error (); } while (0)

#define tests(p, p1) do { test(p, p1, 0); test(p, p1, 1); \
  test(p, p1, 2); test(p, p1, 3); } while (0)

int main(void)
{
uint8_t *p, *p1;
uint32_t u = 0x12345678;
uint32_t bu = ((upal_u32be_t*)&u)->val;
uint32_t b1u = native_to_big_endian(u);
p = (uint8_t*)&bu;
p1 = (uint8_t*)&b1u;
tests(p, p1);

u = 0x12345678;
uint32_t lu = ((upal_u32le_t*)&u)->val;
uint32_t l1u = native_to_little_endian(u);
p = (uint8_t*)&lu;
p1 = (uint8_t*)&l1u;

tests(p, p1);

return 0;
}
 CUT ---
Should this be allowed/working everywhere (I mean without considering
PDP byte order)?
Right now this works at -O0, we don't abort but at -O1 and above FRE
and CCP both misbehave in doing a constant prop of 0x12345678 through
the upal_u32le_t/upal_u32be_t access.
I notice this statement in the documentation:
Moreover, the use of type punning or aliasing to toggle the storage
order is not supported; that is to say, a given scalar object cannot
be accessed through distinct types that assign a different storage
order to it.
--- CUT ---
But I am not 100% sure that is the case here but I hope I am wrong in
saying this is not supported.

Thanks,
Andrew

Re: scalar_storage_order question

[Andrew Pinski via Gcc]

On Wed, Apr 22, 2020 at 1:14 PM Eric Botcazou  wrote:
>
> > I notice this statement in the documentation:
> > Moreover, the use of type punning or aliasing to toggle the storage
> > order is not supported; that is to say, a given scalar object cannot
> > be accessed through distinct types that assign a different storage
> > order to it.
> > --- CUT ---
> > But I am not 100% sure that is the case here but I hope I am wrong in
> > saying this is not supported.
>
> This seems to me a fairly standard example of type punning:
>
> uint32_t u = 0x12345678;
> uint32_t bu = ((upal_u32be_t*)&u)->val;
>
> u = 0x12345678;
> uint32_t lu = ((upal_u32le_t*)&u)->val;
>
> u is accessed through upal_u32be_t and upal_u32le_t, i.e. BE and LE.

What if we had this:
uint32_t u = 0x12345678;
upal_u32be_t tempb;
memcpy (&tempb, &u, sizeof(uint32_t));
uint32_t bu = tempb.val;

Is that valid?  We still run into the wrong code with the above case.
memcpy here should be considered a byte-by-byte copy and therefor
should not have any type punning except for to bytes.

Thanks,
Andrew Pinski

>
> --
> Eric Botcazou

Re: scalar_storage_order question

[Andrew Pinski via Gcc]

On Wed, Apr 22, 2020 at 11:41 PM Eric Botcazou  wrote:
>
> > What if we had this:
> > uint32_t u = 0x12345678;
> > upal_u32be_t tempb;
> > memcpy (&tempb, &u, sizeof(uint32_t));
> > uint32_t bu = tempb.val;
> >
> > Is that valid?  We still run into the wrong code with the above case.
> > memcpy here should be considered a byte-by-byte copy and therefor
> > should not have any type punning except for to bytes.
>
> The usual trick of people doing type punning and pretending they don't. ;-)
> No, this cannot work as-is, although it's probably fixable by blocking the
> propagation through the memcpy in case the scalar order is flipped, unlike the
> previous example.

Yes the following is a decent workaround:
upal_u32be_t tempb;
memcpy (&tempb, &u, sizeof(uint32_t));
asm("":"+m"(tempb));
uint32_t bu = tempb.val;
But I wish this customer would not do this but they want it for some reason.

Thanks,
Andrew Pinski

>
> --
> Eric Botcazou

Re: Should ARMv8-A generic tuning default to -moutline-atomics

[Andrew Pinski via Gcc]

On Wed, Apr 29, 2020 at 6:25 AM Florian Weimer via Gcc  wrote:
>
> Distributions are receiving requests to build things with
> -moutline-atomics:
>
>   
>
> Should this be reflected in the GCC upstream defaults for ARMv8-A
> generic tuning?  It does not make much sense to me if every distribution
> has to overide these flags, either in their build system or by patching
> GCC.

At least we should make it a configure option.
I do want the ability to default it for our (Marvell) toolchain for
Linux (our bare metal toolchain will be defaulting to ARMv8.2-a
anyways).

Thanks,
Andrew

>
> Thanks,
> Florian
>

Re: Multilibs in stage-1

[Andrew Pinski via Gcc]

On Wed, May 6, 2020 at 11:29 PM Uros Bizjak via Gcc  wrote:
>
> On Thu, May 7, 2020 at 8:16 AM Richard Biener
>  wrote:
> >
> > On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc  
> > wrote:
> > >Hello!
> > >
> > >I wonder, if the build process really needs to build all multilibs in
> > >stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build
> > >stage-1 gcc, so there is no need for multilibs, apart from library
> > >that will be used by stage-1 gcc during compilation of stage-2
> > >compiler.
> >
> > Correct. Only stage3 needs those. But IIRC we already avoid building them? 
> > Likewise we avoid building libsanitizer and friends in stage 1/2 unless 
> > ubsan bootstrap is enabled.
>
> Looking at:
>
> [gcc-build]$ ls stage1-x86_64-pc-linux-gnu/32/
> libgcc  libgomp  libstdc++-v3
>
> it seems that 32bit multilibs are built anyway, also in stage2:
>
> [gcc-build]$ ls prev-x86_64-pc-linux-gnu/32/
> libgcc  libgomp  libstdc++-v3

How does the build infrastructure know which multi-lib is being used
to compile GCC here?
I can think of an example where the normal multi-libs are ilp32/lp64
but GCC defaults to ilp32.
So it is hard to tell that from the normal build infastructure really.

Thanks,
Andrew Pinski


>
> Uros.

Re: dejagnu version update?

[Andrew Pinski via Gcc]

On Sat, May 16, 2020 at 9:02 PM Rob Savoye  wrote:
>
> On 5/16/20 5:45 PM, Maciej W. Rozycki wrote:
>
> >  Overall perhaps a patch management system might be good having to make
> > chasing patches easier, such as patchwork, and we already use Git, so we
>
>  As an old GNU project, we're required to use what the FSF prefers,
> which is on savannah. https://savannah.gnu.org/patch/?group=dejagnu, Our
> bug tracker is there their too. We've used that for a long time. Yes,
> patches in email are harder to track.
>
> > fresh patchwork?  The patch traffic is surely much lower with DejaGnu than
> > it is with glibc, and there would be no data to migrate (but we might want
> > to feed a couple of months' back worth of mailing list traffic).
>
>   I'm now building up the infrastructure to properly test patches, but
> it's not enough to do the next release. All I have these days is my
> laptop and a PI B3+. I'd need access to more hardware as some of the
> patches effect cross testing, or get others to test the release candidates.

You should be able to use the gcc compilefarm too for this purpose
(https://gcc.gnu.org/wiki/CompileFarm).

Thanks,
Andrew

>
>   Much of the problems with cross testing are often obscure timing
> problems. It's amazing how sometimes a minor unrelated change changes
> the timing and things break... To do a release properly requires
> duplicating that level of infrastructure for at least several targets
> and several toolchain release, and built on more than one GNU/Linux distro.
>
>  It'll take most of the week to really get a good base setup with
> baseline test results, but some of the patches like the DejaGnu
> testsuite ones will go in first since they don't effect the toolchain.
>
>   Jacob already added 9 patches to our site. I'm still building cross
> compilers since some of his patches effect cross testing. I did add ADA
> to my builds, which isn't a normal build default, since I thought some
> of the patches for ADA.
>
> - rob -
> ---
> https://www.senecass.com

Re: Support for named address spaces in C++

[Andrew Pinski via Gcc]

On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc  wrote:
>
> Hi all,
>
> I’ve added a named address space to our backend and I noticed that it is only 
> support in C.
> Has anyone had experience porting this feature to C++? Is there any technical 
> reason why it’s not supported?

The main issue is how it is interacts with templates and then
mangling.  There was a few other issues that have been posted about
before every time it is raised.

Thanks,
Andrew

>
> Thank you,
> Max

Re: Is it very hard to implement Zero-overhead deterministic exceptions: Throwing values??

[Andrew Pinski via Gcc]

On Sun, Jun 14, 2020 at 2:27 PM Andi Kleen via Gcc  wrote:
>
> sotrdg sotrdg via Gcc  writes:
>
> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0709r0.pdf
> >
> > I really want this feature. How, it looks like this requires changes
> > on RTL, gimple and C++ front-end. Is that very hard to implement it?
>
> If you're asking about setjmp/longjmp exceptions, you can already
> configure with --enable-sjlj-exceptions and then use -fsjlj-exceptions
> to enable them.
>
> It would be a new ABI and likely break some existing libraries.

NOTE Setjmp/longjump is much much slower if exceptions are not used at
all.  Because there will be many many setjump locations.

Thanks,
Andrew Pinski

>
> -Andi

Re: TLS Implementation Across Architectures

[Andrew Pinski via Gcc]

On Thu, Jun 25, 2020 at 1:34 PM Joel Sherrill  wrote:
>
> On Thu, Jun 25, 2020 at 2:54 PM Nathan Sidwell  wrote:
>
> > On 6/25/20 2:34 PM, Joel Sherrill wrote:
> > > Hi
> > >
> > > RTEMS supports over 15 processor architectures and we would like to
> > ensure
> > > that TLS is supported on all  rather than just a handful of popular ones
> > > (arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document (
> > > https://www.akkadia.org/drepper/tls.pdf) but it is a few years old and
> > > covers only a subset of architectures.
> > >
> > > Is TLS supported on all architectures in GCC?
> > >
> > > Is there some documentation on how it is implemented on architectures not
> > > in Ulrich's paper? Or some guidance on how to extract this information
> > from
> > > the GCC source?
> >
> > The ARM (32) abi has some extensions to that, which originally came from
> > Alex Oliva and then I implemented (The GNU2 TLS stuff).  I think the
> > smarts is in the linker for that though.
> >
> > IMHO bfd might be a better source of information than gcc.
> >
>
> BFD would know the section and attribute part but isn't gcc responsible for
> generating the code to dereference into it?  It could be a specific base
> register
> or an invalid instruction fault (MIPS) or something else. I'm wondering how
> one knows what that magic to look up the base is for a specific
> architecture.
>
> Or if there is an easy way for a target to change say the MIPS bad
> instruction
> to a subroutine call? It would seem that GCC would have an architecture
> independent base lookup alternative.

NOTE MIPS32/64r3 says that system register is implemented.  I know of
a few implementations that implement that register as a register
(Octeon 2 and Octeon3 for an example).

Thanks,
Andrew


>
> --joel
>
> --joel
>
> >
> > natan
> > --
> > Nathan Sidwell
> >

Re: Loading plugins with arm-none-eabi-gcc

[Andrew Pinski via Gcc]

On Tue, Jul 21, 2020 at 11:25 PM Shuai Wang via Gcc  wrote:
>
> Hello,
>
> I am currently trying to migrate a gcc plugin that has been well developed
> for x86 code to ARM platform (for arm-none-eabi-gcc).
>
> Currently I did the following steps:
>
> 1. write a hello world program t.c
>
> 2. compile with the following commands:
>
> ➜  arm-none-eabi-gcc -v
>  ..
>  gcc version 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain
> 9-2020-q2-update)
>
> ➜  arm-none-eabi-gcc -S -mcpu=cortex-m3 -mthumb -fdump-tree-all t.c
>
> It works fine, and can smoothly print out all gimple code at different
> stages.
>
> 3. Load my plugin (the plugin is compiled by x64 gcc version 10.0):
>
> ➜  file instrument_san_cov.so
> instrument_san_cov.so: ELF 64-bit LSB shared object, x86-64, version 1
> (SYSV), dynamically linked, with debug_info, not stripped
> ➜  file arm-none-eabi-gcc
> arm-none-eabi-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
> 2.6.24, BuildID[sha1]=fbadd6adc8607f595caeccae919f3bab9df2d7a6, stripped
>
> ➜  arm-none-eabi-gcc -fplugin=./instrument_cov.so -S -mcpu=cortex-m3
> -mthumb -fdump-tree-all t.c
> cc1: error: cannot load plugin ./instrument_cov.so
>./instrument_cov.so: undefined symbol:
> _Z20build_string_literaliPKcP9tree_nodem
>
> ➜  c++filt -n _Z20build_string_literaliPKcP9tree_nodem
> build_string_literal(int, char const*, tree_node*, unsigned long)
>
>
> It seems that somewhat a function named `build_string_literal` cannot be
> found. Why is that? I have no idea how to proceed on this matter and cannot
> find some proper documents. Any suggestion would be appreciated. Thank you!

Did you compile your plugin with the headers from the GCC that you are
using to load the plugin into?
If not, then it won't work.  Note build_string_literal changed between
GCC 9 and GCC 10 in the source and GCC plugin ABI is not stable
between releases at all.

Thanks,
Andrew

>
> Best,
> Shuai

Re: Loading plugins with arm-none-eabi-gcc

[Andrew Pinski via Gcc]

On Wed, Jul 22, 2020 at 12:45 AM Shuai Wang  wrote:
>
> Hey Andrew,
>
> Thanks a lot for getting back to me. No I am not. Let me clarify the context 
> here:
>
> 1. On my Ubuntu (x86-64 version), I use x86 gcc (version 10.0) to compile 
> this plugin, and test this plugin on various programs' GIMPLE code during its 
> compilation with x86 gcc (version 10.0).
>
> 2. Then, I switched to use arm-none-eabi-gcc to load this plugin, and 
> encountered the above issue.

Right because you did not recompile the plugin to use the headers of
arm-none-eabi-gcc compiler.  You need to recompile the plugin for that
compiler using the native GCC you compiled the compiler with; that is
you might need to recompile the compiler too.
There is no stable plugin API/ABI here and that is what you are running into.

Thanks,
Andrew

>
> 3. Since I am doing a cross-platform compilation (on Ubuntu x86), I am 
> anticipating to NOT directly compile my plugin (as a typical .so shared 
> library) into an ARM library, right? Otherwise it cannot be loaded and 
> executed on x86 Ubuntu, right?
>
> 4. Then it seems to me that still, the proper way is to compile a x86 plugin, 
> and then somewhat use the arm-none-eabi-gcc to load the plugin during cross 
> architecture compilation?
>
> Best,
> Shuai
>
>
>
> On Wed, Jul 22, 2020 at 3:20 PM Andrew Pinski  wrote:
>>
>> On Tue, Jul 21, 2020 at 11:25 PM Shuai Wang via Gcc  wrote:
>> >
>> > Hello,
>> >
>> > I am currently trying to migrate a gcc plugin that has been well developed
>> > for x86 code to ARM platform (for arm-none-eabi-gcc).
>> >
>> > Currently I did the following steps:
>> >
>> > 1. write a hello world program t.c
>> >
>> > 2. compile with the following commands:
>> >
>> > ➜  arm-none-eabi-gcc -v
>> >  ..
>> >  gcc version 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain
>> > 9-2020-q2-update)
>> >
>> > ➜  arm-none-eabi-gcc -S -mcpu=cortex-m3 -mthumb -fdump-tree-all t.c
>> >
>> > It works fine, and can smoothly print out all gimple code at different
>> > stages.
>> >
>> > 3. Load my plugin (the plugin is compiled by x64 gcc version 10.0):
>> >
>> > ➜  file instrument_san_cov.so
>> > instrument_san_cov.so: ELF 64-bit LSB shared object, x86-64, version 1
>> > (SYSV), dynamically linked, with debug_info, not stripped
>> > ➜  file arm-none-eabi-gcc
>> > arm-none-eabi-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
>> > dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
>> > 2.6.24, BuildID[sha1]=fbadd6adc8607f595caeccae919f3bab9df2d7a6, stripped
>> >
>> > ➜  arm-none-eabi-gcc -fplugin=./instrument_cov.so -S -mcpu=cortex-m3
>> > -mthumb -fdump-tree-all t.c
>> > cc1: error: cannot load plugin ./instrument_cov.so
>> >./instrument_cov.so: undefined symbol:
>> > _Z20build_string_literaliPKcP9tree_nodem
>> >
>> > ➜  c++filt -n _Z20build_string_literaliPKcP9tree_nodem
>> > build_string_literal(int, char const*, tree_node*, unsigned long)
>> >
>> >
>> > It seems that somewhat a function named `build_string_literal` cannot be
>> > found. Why is that? I have no idea how to proceed on this matter and cannot
>> > find some proper documents. Any suggestion would be appreciated. Thank you!
>>
>> Did you compile your plugin with the headers from the GCC that you are
>> using to load the plugin into?
>> If not, then it won't work.  Note build_string_literal changed between
>> GCC 9 and GCC 10 in the source and GCC plugin ABI is not stable
>> between releases at all.
>>
>> Thanks,
>> Andrew
>>
>> >
>> > Best,
>> > Shuai

Re: Built-in Specs ignored... unless -specs=dump is specified

[Andrew Pinski via Gcc]

On Mon, Aug 31, 2020 at 4:34 PM Giacomo Tesio  wrote:
>
> Hello everybody!
>
> To cleanup my port of GCC (9.2.0) to Jehanne OS (http://jehanne.io)
> I'd like to add a `--posixly` command line options to the gcc driver
> that should be expanded to a couple of -isystem and -L options
> to ease the compilation of POSIX programs (Jehanne is a Plan 9
> derivative so it's not a POSIX system).
>
> So I defined in the gcc/config/jehanne.h (see attachment) the macros
> LINK_SPEC, LIB_SPEC and CPP_SPEC that substitute such command line
> options as required.

You might need to add it to a .opt file like it is done in darwin.opt:
; Driver options.

all_load
Driver RejectNegative Alias(Zall_load)
Load all members of archive libraries, rather than only those that
satisfy undefined symbols.

Thanks,
Andrew Pinski

>
> What's weird is that, if I dump the specs file with `gcc -dumpspecs`
> and then load it with `gcc -specs=dump` it works like a charm,
> properly translating the --posixly option.
>
> However without the -specs option, it can't recognise such option.
>
> I have no idea of what I'm missing.
> I tried to put the dump into PREFIX/lib/gcc/x86_64-jehanne/9.2.0/specs
> (also in the attachments) but it doesn't change anything.
> Yet, by using the -specs= option it works.
>
>
> Am I missing something obvious?
>
> Thanks for your help and sorry if the issue is dumb: I tried my best to
> understand the Gcc Internals but I was unable to fix this.
>
>
> Giacomo

Re: How to check reachable between blocks

[Andrew Pinski via Gcc]

On Fri, Oct 9, 2020 at 8:01 PM Jojo R  wrote:
>
> Hi,
>
> Is there any API or common codes to check any two blocks is reachable 
> ?

Yes the API in dominance.h.
Depending on where you use it, you might need to have it created.
Using calculate_dominance_info function.
The function to do the check is dominated_by_p.

Thanks,
Andrew Pinski


>
> Thanks.
>
> Jojo

Re: Potential bug in GCC when compiling C to a flat binary

[Andrew Pinski via Gcc]

On Sat, Dec 26, 2020 at 5:41 PM Rhys Rustad-Elliott  wrote:
>
> Hi all,
>
> I've encountered a strange issue when compiling C to a flat binary with GCC.
> It's questionably a bug, but I hesitate to strongly say that due to my lack of
> familiarity with the GCC codebase and the rather obscure nature of what I'm
> trying to do. Posting this here in the hopes that someone can either a) 
> confirm
> this is in fact a GCC bug (in which case I'll file a bug report) or b) tell me
> what I'm doing wrong.
>
> First off, system information:
>
> $ head -1 /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 10 (buster)"
>
> $ uname -a
> Linux desktop 5.9.0-0.bpo.2-amd64 #1 SMP Debian 5.9.6-1~bpo10+1 (2020-11-19) 
> x86_64 GNU/Linux
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' 
> --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
> --with-gcc-major-version-only --program-suffix=-8 
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
> --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
> --enable-offload-targets=nvptx-none --without-cuda-driver 
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 8.3.0 (Debian 8.3.0-6)
>
> I'm currently in the process of writing a packer for ELF binaries (similar to
> UPX). To do this, I compile my loader code into a position-independent flat
> binary with no dependency on glibc using a custom linker script and then 
> inject
> it into an ELF binary, where it as well as the packed binary get loaded on
> exec. The loader code is passed initial control, decrypts/decompresses the
> packed binary, and hands control to the unpacked binary.
>
> The problem comes when I try to take the address of a function that resides
> outside the current translation unit in the loader code. Instead of &func
> evaluating to the address of the function func, it evaluates to the first
> sizeof(void *) bytes of the _code_ of the function func. I've created a 
> minimal
> reproduction here:
>
> $ ls
> func.c  link.lds  Makefile  prog.c
>
> $ cat prog.c
> extern void func();
>
> void _start()
> {
>   void *ptr = (void *) func;
> }
>
> $ cat func.c
> void func()
> {
>
> }
>
> $ cat link.lds
> OUTPUT_FORMAT("binary")
> OUTPUT_ARCH(i386:x86-64)
> ENTRY(_start)
>
> SECTIONS
> {
>   . = 0x0100;
>   .text : {
> *(.text)
>   }
>   .data : {
> *(.data)
>   }
> }
>
> rhys@desktop:~/repro$ cat Makefile
> CFLAGS = -fpie -nostdlib -nostartfiles -nodefaultlibs -fno-builtin -c -I ..
> LDFLAGS = -pie
>
> OBJS = prog.o func.o
> BIN = prog
>
> all: $(OBJS)
> $(LD) $(LDFLAGS) $(OBJS) -T link.lds -o $(BIN)
>
> %.o: %.c
> $(CC) $(CFLAGS) $< -o $@
>
> %.o: %.S
> $(AS) $< -o $@
>
> clean:
> rm -f $(OBJS) $(BIN)
>
> As can be seen, this setup is pretty simple, _start gets control, and does
> nothing other than load the address of func (which is located in another
> translation unit) into ptr. Disassembling the output binary with radare2, I 
> see
> the following:
>
> ┌ 18: fcn. ();
> │   ; var int64_t var_8h @ rbp-0x8
> │   0x  55 push rbp
> │   0x0001  4889e5 mov rbp, rsp
> │   0x0004  488b0507.  mov rax, qword [0x0012] ; 
> fcn.0012
> │  ; 
> [0x12:8]=0xc35d90e5894855
> │   0x000b  488945f8   mov qword [var_8h], rax
> │   0x000f  90 nop
> │   0x0010  5d pop rbp
> └   0x0011  c3 ret
>
> ┌ 7: fcn.0012 ();
> │   0x0012  55 push rbp
> │   0x0013  4889e5 mov rbp, rsp
> │   0x0016  90 nop
> │   0x0017  5d pop rbp
> └   0x0018  c3 ret
>
> Note how fcn. corresponds to _start and fcn.0012 corresponds to
> func. Now note the instructions at address 0x0004 and 0x000b. They
> should be loading the _address_ 0x0012 into rax and then loadin

Re: GCC generates non-compliant MIPS relocation data? Obscure GNU extension?

[Andrew Pinski via Gcc]

On Thu, Feb 18, 2021 at 12:15 PM Project Revolution via Gcc
 wrote:
>
> Hi GCC folks,
>
> We were working on a decompilation project for a Nintendo 64 title and 
> attempting to enable support for using GCC instead of the emulated IRIX 
> compiler and we ran into a big problem with how GCC generates relocations for 
> the MIPS target which appears to show that GCC is generating non-compliant 
> relocation data for MIPS target.

Try compiling with -fno-section-anchors .
https://gcc.gnu.org/legacy-ml/gcc-help/2009-07/msg00455.html

Thanks,
Andrew

>
> In summary: the Nintendo 64 title has a limited amount of RAM (4MB, 8MB if 
> you add Expansion Pak, which our ROM target uses for debug reasons); in order 
> to accomplish this, the codebase packs actors/objects into overlays which the 
> game determines need to be loaded per room/system transition. Once loaded 
> into RAM, the game applies the overlay's relocations generated at compile 
> time to the code to move the data and code correctly and make sure the jumps 
> and loads get recalculated correctly.
>
> Unfortunately.. there's a problem. Here's the function that applies the 
> relocs to MIPS: 
> https://github.com/zeldaret/oot/blob/master/src/code/relocation.c
>
> While enabling overlays to be recompiled with GCC instead of the IDO 
> compiler, we have found the relocs generated did not guarantee 0x45/0x46 
> (Hi/lo pairs) pairs to be 1:1, and GCC would share any possible hi/lo in O2 
> mode. While O0 and O1 gcc overlays will work, or even Og, this is not a 
> solution for an N64 ROM due to limited RAM and space will quickly run out 
> since memory is so tight. While investigating why gcc will optimize relocs, 
> we have found the following:
>
> The MIPS ABI specified at 
> https://refspecs.linuxfoundation.org/elf/mipsabi.pdf on pages 79-80 (page 82 
> regarding the GP caveat) demands that hi/los be in pairs). Thus, we have 
> found that the reloc data generated erroneously applies the relocation twice. 
> Several LOs following a HI seems to be in a spec, but several HIs following a 
> LO does not. This is causing issues for our relocation due to the relocs 
> being applied incorrectly as a result of non-compliant relocation data. It 
> turned out this reloc optimization is caused by an unmentioned, undocumented 
> GNU extension.
>
> We have found the GNU extension was ONLY ever mentioned here: 
> https://people.freebsd.org/~adrian/mips/20160819-mips-elf-reloc-gcc-5.3-3.diff
>
> Here is the file we compiled: 
> https://github.com/zeldaret/oot/blob/master/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c
>
> This is the line we used to compile it:
>
> mips-linux-gnu-gcc -c -O2 -c -G 0 -nostdinc -Iinclude -Isrc -Iassets -Ibuild 
> -I. -DNON_MATCHING=1 -DNON_EQUIVALENT=1 -DAVOID_UB=1 -mno-shared 
> -march=vr4300 -mfix4300 -mabi=32 -mhard-float -mdivide-breaks 
> -fno-stack-protector -fno-common -fno-zero-initialized-in-bss -mno-abicalls 
> -fno-strict-aliasing -fno-inline-functions -fno-inline-small-functions 
> -fno-toplevel-reorder -ffreestanding -fwrapv -Wall -Wextra -g -fno-gcse 
> -fno-cse-follow-jumps -mno-load-store-pairs -mno-explicit-relocs 
> -fno-peephole2 -mips3 -o 
> build/src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.o 
> src/overlays/actors/ovl_En_Heishi4/z_en_heishi4.c
>
> To note, we have tried with and without explicit relocs and with and without 
> peephole2 and with and without mips2/3 and it didnt make a difference: the 
> relocs were still noncompliant per the PDF posted earlier. We need a way to 
> turn this undocumented GNU extension off because it is causing relocs when 
> optimized to not be processed correctly. To note, our use case is attempting 
> to compile this repo with GCC (this file is a test case) but if you were to 
> compile the ROM with the Heishi4 file being compiled as GCC using the above 
> call (make any Makefile alterations to force the object to be GCC), spawn on 
> the SPOT00 map at the start of the game and go inside the castle town area 
> and observe the crash which takes like 60 seconds. This is ultimately what 
> we're trying to fix which following this rabbit hole leads us to this GNU 
> extension in a haystack hunt. Can you guys help us resolve this?
>
> v/r,
> Revo
>

Re: problems with memory allocation and the alignment check

[Andrew Pinski via Gcc]

On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
 wrote:
>
> Hi,
>
> I just wrote this little program to demonstrate a possible flaw in both 
> malloc and calloc.
>
> If I allocate a the simplest memory region from main(), one out of three 
> optimization flags fail.
> If I allocate the same region from a function, three out of three 
> optimization flags fail.
>
> Does someone know if this really is a flaw, and if so, is it a gcc or a 
> kernel flaw?

There is no flaw.  GCC (kernel, glibc) all assume unaligned accesses
on x86 will not cause an exception.

Thanks,
Andrew

>
> Regards,
> Mischa.

Re: problems with memory allocation and the alignment check

[Andrew Pinski via Gcc]

On Mon, Feb 22, 2021 at 1:37 AM Michael J. Baars
 wrote:
>
> On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote:
> > On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
> >  wrote:
> > > Hi,
> > >
> > > I just wrote this little program to demonstrate a possible flaw in both 
> > > malloc and calloc.
> > >
> > > If I allocate a the simplest memory region from main(), one out of three 
> > > optimization flags fail.
> > > If I allocate the same region from a function, three out of three 
> > > optimization flags fail.
> > >
> > > Does someone know if this really is a flaw, and if so, is it a gcc or a 
> > > kernel flaw?
> >
> > There is no flaw.  GCC (kernel, glibc) all assume unaligned accesses
> > on x86 will not cause an exception.
>
> Is this just an assumption or more like a fact? I agree with you that byte 
> aligned is more or less the same as unaligned.

It is an assumption that is even made inside GCC.  You can modify GCC
not to assume that but you need to recompile all libraries and even
check the assembly code that is included with most programs.
Why are you enabling the alignment access check anyways?  What are you
trying to do?
If you are looking into a performance issue with unaligned accesses,
may I suggest you look into perf to see if you can see unaligned
accesses?

Thanks,
Andrew

>
> >
> > Thanks,
> > Andrew
> >
> > > Regards,
> > > Mischa.
>

Re: A weird bug

[Andrew Pinski via Gcc]

On Thu, Mar 4, 2021 at 3:19 PM Gary Oblock via Gcc  wrote:
>
> Guys,
>
> I've been trying to debug a linker error (which I thought was a bug in
> my optimization.) Well it turns out it occurs in a brand new virgin
> version of the compiler running with binutils 2.36 which is the latest
> version. I'm posting this on both the binutils list and gcc list
> because people of either list are just as likely to have an idea about
> what's going on. Note, I tried to walk though the ld code in gdb but
> it's nontrivial trying figure out why an error occured. I can't just
> set a watch point on a flag because, at least in some places it seems
> like the default state of the flag is failure and the code then
> proceeds to try various things to see if they'll work.


I will give you a hint, pre GCC 10, defaulted to -fcommon, GCC 10+
defaults to -fno-common.

Thanks,
Andrew

>
> Regarding the compiler that I built:
>
>  $ git status
> On branch master
> Your branch is up to date with 'origin/master'.
>
> nothing to commit, working tree clean
>
> Now here is how I built it:
>
> ./my_dual_build_script gcc_virgin_build 2>build_log_virgin 1>&2
>
> where my_dual_build_script is:
>
> cd $1
> BASE=`pwd`
> echo BASE = $BASE
> touch BU_objdir objdir install
> rm -rf BU_objdir objdir install
> mkdir BU_objdir objdir install
>
> cd BU_objdir
> echo BUILDING BINUTILS IN `pwd`
> ../binutils-2.36/configure --prefix=$BASE/install
> make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
> ##make CFLAGS='-O0 -g' CXXFLAGS='-O2 -g' -j 12
> make install
>
> cd ../objdir
> echo BUILDING GCC IN `pwd`
> ../sources/configure --prefix=$BASE/install --disable-bootstrap 
> -enable-language=c,c++,lto --disable-multilib --enable-valgrind-annotations
> ##make CFLAGS='-O0 -g' CXXFLAGS='-O0 -g' -j 12
> make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
> make install
>
> My installed gcc is:
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
> 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
> --with-gcc-major-version-only --program-suffix=-7 
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
> --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
> --enable-offload-targets=nvptx-none --without-cuda-driver 
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
>
> My istalled binutils are:
>
> $ ld -v
> GNU ld (GNU Binutils for Ubuntu) 2.30
>
> Now the application that failing during testing is 505.x264_5 which is
> from SPEC17. Note, please don't try to duplicate this bug unless you
> have access to SPEC17 and are running an identical system because
> Martin Liska tried to do this on a different system but but he
> couldn't get it to duplicate.
>
> Now for any SPEC heads out there here's the germane parts
> from its confige file.
>
>define  gcc_dir/home/gary/gcc_virgin_build/install
>
>preENV_LD_LIBRARY_PATH  = %{gcc_dir}/lib64/:%{gcc_dir}/lib/:/lib64
>SPECLANG= %{gcc_dir}/bin/
>CC  = $(SPECLANG)gcc --verbose  -std=c99   %{model}
>CXX = $(SPECLANG)g++ -std=c++03 %{model}
>FC  = $(SPECLANG)gfortran   %{model}
>
>OPTIMIZE   = -O2 -v -Wl,--verbose=1  -Wl,-debug
>COPTIMIZE  = -save-temps
>
> Finally here linker's part of the x264 build output:
>
> /home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/bin/ld
>  -plugin 
> /home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/liblto_plugin.so
>  
> -plugin-opt=/home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
>  -plugin-opt=-fresolution=ldecod_r.res -plugin-opt=-pass-through=-lgcc 
> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
> -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s 
> --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o 
> ldecod_r /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o 
> /home/gary/gcc_virgin_build/in

Re: Failing in generated file options.c

[Andrew Pinski via Gcc]

On Mon, Mar 15, 2021 at 7:41 PM Gary Oblock via Gcc  wrote:
>
> Guys,
>
> I checked out a fresh copy of the GCC sources today, applied somebodies
> patch to it and voila!
>
> options.c:13591:2: error: #error Report option property is dropped #error 
> Report option property is dropped
>
> I built this the same minimally convoluted way that I always do.
>
> cd $1
> BASE=`pwd`
> echo BASE = $BASE
> touch objdir install
> rm -rf objdir install
> mkdir objdir install
> cd objdir
> echo BUILDING IN `pwd`
> ../sources/configure --prefix=$BASE/install --disable-bootstrap 
> -enable-language=c,c++,lto --disable-multilib --enable-valgrind-annotations
> make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
> make install
>
> The file option.c is generated in objdir/gcc by an awk script:
>
> mawk -f ../../sources/gcc/opt-functions.awk -f ../../sources/gcc/opt-read.awk 
> \
>-f ../../sources/gcc/optc-gen.awk \
>-v header_name="config.h system.h coretypes.h options.h tm.h" < 
> optionlist > options.c
>
> Does anyone  have any idea what's going to here?


# If FLAGS contains a "NAME(...argument...)" flag, return the value
# of the argument.  Print error message otherwise.

It could be any of the following:
Name/Type inside Enum
Enum/String/Value instead EnumValue

Thanks,
Andrew

>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: removing toxic emailers

[Andrew Pinski via Gcc]

On Fri, Apr 16, 2021 at 9:56 PM Frosku  wrote:
>
> On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote:
> > On Fri, Apr 16, 2021 at 4:16 PM Frosku  wrote:
> > >
> > > When I refer to a 'California cultural standard', that's not 
> > > prescriptive. It's
> > > just a reference to the fact that a *lot* of the SC live in California, 
> > > and any
> > > culture prescribed by the steering committee will be overly influenced by 
> > > that
> > > commonality.
> >
> > To the best of my knowledge, 2 of the 13 members of the GCC steering
> > committee live in California.
> >
> > Ian
>
> And the rest of the west coast United States / New England?

I count 5 which are not in the United States or Canada.

Thanks,
Andrew Pinski

>
> >>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<

Re: "musttail" statement attribute for GCC?

[Andrew Pinski via Gcc]

On Fri, Apr 23, 2021 at 2:45 PM Josh Haberman via Gcc  wrote:
>
> Would it be feasible to implement a "musttail" statement attribute in
> GCC to get a guarantee that tail call optimization will be performed?
>
> Such an attribute has just landed in the trunk of Clang
> (https://reviews.llvm.org/D99517). It makes it possible to write
> algorithms that use arbitrarily long chains of tail calls without risk
> of blowing the stack. I would love to see something like this land in
> GCC also (ultimately I'd love to see it standardized).
>
> I wrote more about some motivation for guaranteed tail calls here:
> https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html

So I was looking into the use case presented in that web page, it is
the same reason why GCC has the computed gotos extension already.
Is there a reason why you can't just use that instead?

Thanks,
Andrew Pinski

>
> GCC successfully optimizes tail calls in many cases already. What
> would it take to provide an actual guarantee, and make it apply to
> non-optimized builds also?
>
> The Clang implementation enforces several rules that must hold for the
> attribute to be correct, including:
>
> - It must be on a function call that is tail position.
> - Caller and callee must have compatible function signatures
> (including the implicit "this", if any), differing only in cv
> qualifiers.
> - Caller and callee must use the same calling convention.
> - Caller and callee may not be constructors or destructors.
> - All arguments, the return type, and any temporaries created must be
> trivially destructible.
> - All variables currently in scope must be trivially destructible.
> - The caller cannot be in a try block, an Objective-C block, or a
> statement expression.
>
> Some of these restrictions may be overly strict for some calling
> conventions, but they are useful as the "least common denominator"
> that should be safe in all cases. When implementing this in Clang, we
> found that we were able to reuse some of the checks around goto and
> asm goto, since a tail call is sort of like a goto out of the
> function's scope.
>
> Thanks,
> Josh

Re: Some really strange GIMPLE

[Andrew Pinski via Gcc]

On Tue, Apr 27, 2021 at 3:51 PM Gary Oblock via Gcc  wrote:
>
> I'm chasing a bug and I used Creduce to produce a
> reduced test case. However, that's really beside to
> point.
>
> I this file:
> 
> typedef struct basket {
> } a;
> long b;
> a *basket;
> int d, c, e;
> a *flake[2];
> void primal_bea_mpp();
> void primal_net_simplex() {
>   flake[1] = &basket[1];
>   primal_bea_mpp(d, d, d, b, flake, 0, e, c, c, d);
> }
> 
> Produces this GIMPLE:
> -
> ;; Function primal_net_simplex (primal_net_simplex, funcdef_no=3, 
> decl_uid=4447, cgraph_uid=16, symbol_order=41) (executed once)
>
> primal_net_simplex ()
> {
>[local count: 1073741824]:
>   _1 = basket;
>   static struct a * flake[2];
> struct a *[2]
>   flake[1] = _1;
>   _2 = d;
>   _3 = c;
>   _4 = e;
>   _5 = b;
>   primal_bea_mpp (_2, _2, _2, _5, &flake, 0, _4, _3, _3, _2);
>   return;
>
> }
> --
> These standard calls were used to dump this:
>
>   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
>   {
> struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
> dump_function_header ( file, func->decl, (dump_flags_t)0);
> dump_function_to_file ( func->decl, file, (dump_flags_t)0);
>   }
>
> The GIMPLE above looks malformed to me. Is that the case
> or am I not grasping what's going on here?

The above gimple looks correct.
_1 should be of type a*. _2, _3, _4, and _5 are of type int.
Reading from globals (non-local) requires an assignment which is why
you get _1, _2, _3, _4, and _5.
There have already been optimizations going on before your pass so the
loads from d and c have been only done once.
&flake is considered a constant during the execution of the function
is it is propagated into the function call.

What is the exact thing you think is incorrect about the gimple here?

Thanks,
Andrew


>
> Note, I wouldn't be asking this question if this wasn't at the start of
> my pass and looking at stuff I hadn't modified.
>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Speed of compiling gimple-match.c

[Andrew Pinski via Gcc]

Hi all,
  I noticed my (highly, -j24) parallel build of GCC is serialized on
compiling gimple-match.c.  Has anyone looked into splitting this
generated file into multiple files?

Thanks,
Andrew Pinski

Re: Speed of compiling gimple-match.c

[Andrew Pinski via Gcc]

On Wed, May 12, 2021 at 1:19 AM Richard Biener
 wrote:
>
> On Tue, May 11, 2021 at 5:01 PM Segher Boessenkool
>  wrote:
> >
> > On Tue, May 04, 2021 at 10:40:38AM +0200, Richard Biener via Gcc wrote:
> > > On Mon, May 3, 2021 at 11:10 PM Andrew Pinski via Gcc  
> > > wrote:
> > > >   I noticed my (highly, -j24) parallel build of GCC is serialized on
> > > > compiling gimple-match.c.  Has anyone looked into splitting this
> > > > generated file into multiple files?
> > >
> > > There were threads about this in the past, yes.  There's the
> > > possibility to use LTO for this as well (also mentioned in those
> > > threads).  Note it's not easy to split in a meaningful way in
> > > genmatch.c
> >
> > But it will have to be handled at least somewhat soon: on not huge
> > parallelism (-j120 for example) building *-match.c takes longer than
> > building everything else in gcc/ together (wallclock time), and it is a
> > huge part of regstrap time (bigger than running all of the testsuite!)
>
> I would classify -j120 as "huge parallelism" ;)  Testing time still
> dominates my builds (with -j24) where bootstrap takes ~20 mins
> but testing another 40.

For me, it is around 1 hour bootstrapping and 1 hour testing.

> Is it building stage2 gimple-match.c that you are worried about?
> (it's built using the -O0 compiled stage1 compiler - but we at
> least should end up using -fno-checking for this build)

Yes.  It takes on the machine I was using 15 minutes to compile
gimple-match.c, dominating the whole time for bootstrapping.
Everything else was done in 1-3 minutes max even.
This is on an aarch64 machine with 24 cores (not threads).

Thanks,
Andrew Pinski

>
> Maybe you can do some experiments - like add
> -fno-inline-functions-called-once and change
> genmatch.c:3766 to split out single uses as well
> (should decrease function sizes).
>
> There's the option to make all functions external in
> gimple-match.c so splitting the file at arbitrary points
> will be possible (directly from genmatch), we'll need
> some internal header with all declarations then
> as well or alternatively some clever logic in
> genmatch to only externalize functions needed from
> mutliple split files.
>
> That said - ideas to reduce the size of the generated
> code are welcome as well.
>
> There's also pattern ordering in match.pd that can
> make a difference because we're honoring
> first-match and thus have to re-start matching from
> outermost on conflicts (most of the time the actual
> oder in match.pd is just random).  If you add -v
> to genmatch then you'll see
>
> /home/rguenther/src/gcc3/gcc/match.pd:6092:10 warning: failed to merge
> decision tree node
>(cmp (op@3 @0 INTEGER_CST@1) INTEGER_CST@2)
>  ^
> /home/rguenther/src/gcc3/gcc/match.pd:4263:11 warning: with the following
> (cmp (op @0 REAL_CST@1) REAL_CST@2)
>   ^
> /home/rguenther/src/gcc3/gcc/match.pd:5164:6 warning: because of the
> following which serves as ordering barrier
>  (eq @0 integer_onep)
>  ^
>
> that means that the simple (eq @0 integer_onep) should match after
> 4263 but before 6092
> (only the latter will actually match the same - the former has
> REAL_CST@2 but 5164
> uses a predicate integer_onep).  This causes us to emit three switch
> (code){ case EQ_EXPR: }
> instead of one.
>
> There might be legitimate cases of such order constraints but most of them
> are spurious.  "Fixing" them will also make the matching process faster, but
> it's quite some legwork where moving a pattern can fix one occurance but
> result in new others.
>
> For me building stage3 gimple-match.o (on a fully loaded system.. :/) is
>
> 95.05user 0.42system 1:35.51elapsed 99%CPU (0avgtext+0avgdata
> 929400maxresident)k
> 0inputs+0outputs (0major+393349minor)pagefaults 0swaps
>
> and when I use -Wno-error -flto=24 -flinker-output=nolto-rel -r
>
> 139.95user 1.79system 0:25.92elapsed 546%CPU (0avgtext+0avgdata
> 538852maxresident)k
> 0inputs+0outputs (0major+1139679minor)pagefaults 0swaps
>
> the issue of course is that we can't use this for the stage1 build
> (unless we detect working
> GCC LTO in the host compiler setup).  I suppose those measures show the lower
> bound of what should be possible with splitting up the file (LTO
> splits to 128 pieces),
> so for me it's a 4x speedup in wallclock time despite the overhead of
> LTO which is
> quite noticable.  -fno-checking also makes a dramatic difference for me.
>
> Richard.
>
> >
> > Segher

Re: gcc 11.1.0 mpfr

[Andrew Pinski via Gcc]

On Fri, May 14, 2021 at 3:27 AM Richard Biener via Gcc  wrote:
>
> On May 14, 2021 10:53:21 AM GMT+02:00, "Martin Liška"  wrote:
> >On 5/12/21 10:51 AM, Richard Biener via Gcc wrote:
> >> On Tue, May 11, 2021 at 6:34 PM Serge Belyshev via Gcc
> > wrote:
> >>>
> >>>
>  $ egrep "mpfr\.h" log/cfg/cfg.gcc-11.1.0.log
>  checking for the correct version of mpfr.h... buggy but acceptable
> 
>  It appears "gcc-11.1.0/contrib/download_prerequisites"
>  specifies "mpfr-3.1.4.tar.bz2" whereas top level 'configure'
>  has "MPFR_VERSION_NUM(3,1,6)".
> 
>  Is there a reason mpfr 3.1.6 isn't being used?
> >>>
> >>> No good reason: that script was not updated with new versions.
> >GCC-11 is
> >>> also known to work fine with the most recent mpfr version 4.1.0.
> >>
> >> Yes, the update of the minimum version and the buggy check was
> >> done by Janne w/o adjusting the download script.
> >>
> >> Richard.
> >>
> >
> >Should I adjust download_prerequisites accordingly?
>
> Yes.

It looks like the adjustment was made but the file was not added uploaded:
[apinski@xeond2 gcc]$ ./contrib/download_prerequisites
2021-05-14 13:18:41
URL:http://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2
[2383840/2383840] -> "gmp-6.1.0.tar.bz2" [1]
http://gcc.gnu.org/pub/gcc/infrastructure/mpfr-4.1.0.tar.bz2:
2021-05-14 13:18:42 ERROR 404: Not Found.
error: Cannot download mpfr-4.1.0.tar.bz2 from
http://gcc.gnu.org/pub/gcc/infrastructure/


Thanks,
Andrew Pinski


>
> Richard.
>
> >Martin
>

Signedness of boolean types (and Ada)

[Andrew Pinski via Gcc]

I noticed while debugging why my "A?CST1:CST0" patch was broken for
Ada, I noticed the following ranges for boolean types:
  # RANGE [0, 1] NONZERO 1
  _14 = checks__saved_checks_tos.482_2 > 0;
  # RANGE [0, 255] NONZERO 1
  _18 = _14 == 0;
  _19 = ~_18;
  # RANGE [0, 1] NONZERO 1
  _15 = _19;
  if (_15 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

Seems like there is a misunderstanding of TYPE_UNSIGNED for boolean
types and that is what is causing the problem in the end. As the above
gets optimized to be always true. My patch just happens to cause the
~_18 to be produced which is later on miscompiled.

Should TYPE_UNSIGNED be always set for boolean types?

I am testing the below patch to see if it fixes the problem, if we
should assume TYPE_UNSIGNED is true for boolean types.  If we should
not assume that, then there is a problem with conversion between
boolean types that have TYPE_UNSIGNED mismatched.

Thanks,
Andrew Pinski

diff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
index 232b552a60c..4e839f3b8ab 100644
--- a/gcc/ada/gcc-interface/decl.c
+++ b/gcc/ada/gcc-interface/decl.c
@@ -1687,7 +1687,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree
gnu_expr, bool definition)

  gnu_type = make_node (is_boolean ? BOOLEAN_TYPE : ENUMERAL_TYPE);
  TYPE_PRECISION (gnu_type) = esize;
- TYPE_UNSIGNED (gnu_type) = is_unsigned;
+ TYPE_UNSIGNED (gnu_type) = is_boolean ? true : is_unsigned;
  set_min_and_max_values_for_integral_type (gnu_type, esize,
TYPE_SIGN (gnu_type));
  process_attributes (&gnu_type, &attr_list, true, gnat_entity);

Re: Signedness of boolean types (and Ada)

[Andrew Pinski via Gcc]

On Mon, May 17, 2021 at 6:52 PM Andrew Pinski  wrote:
>
> I noticed while debugging why my "A?CST1:CST0" patch was broken for
> Ada, I noticed the following ranges for boolean types:
>   # RANGE [0, 1] NONZERO 1
>   _14 = checks__saved_checks_tos.482_2 > 0;
>   # RANGE [0, 255] NONZERO 1
>   _18 = _14 == 0;
>   _19 = ~_18;
>   # RANGE [0, 1] NONZERO 1
>   _15 = _19;
>   if (_15 != 0)
> goto ; [50.00%]
>   else
> goto ; [50.00%]
>
> Seems like there is a misunderstanding of TYPE_UNSIGNED for boolean
> types and that is what is causing the problem in the end. As the above
> gets optimized to be always true. My patch just happens to cause the
> ~_18 to be produced which is later on miscompiled.
>
> Should TYPE_UNSIGNED be always set for boolean types?
>
> I am testing the below patch to see if it fixes the problem, if we
> should assume TYPE_UNSIGNED is true for boolean types.  If we should
> not assume that, then there is a problem with conversion between
> boolean types that have TYPE_UNSIGNED mismatched.

I went back and noticed this has been discussed before but it does
look like the middle-end/gimple is still broken and even worse I have
done:
(bit_not:boolean_type_node (convert:boolean_type_node @0))
Which means I have done the conversions correctly but they are removed still.
So I am still thinking we need to have a discussion about what boolean
type node should be and even how boolean types should act during the
gimple phase.

Thanks,
Andrew Pinski

>
> Thanks,
> Andrew Pinski
>
> diff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
> index 232b552a60c..4e839f3b8ab 100644
> --- a/gcc/ada/gcc-interface/decl.c
> +++ b/gcc/ada/gcc-interface/decl.c
> @@ -1687,7 +1687,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree
> gnu_expr, bool definition)
>
>   gnu_type = make_node (is_boolean ? BOOLEAN_TYPE : ENUMERAL_TYPE);
>   TYPE_PRECISION (gnu_type) = esize;
> - TYPE_UNSIGNED (gnu_type) = is_unsigned;
> + TYPE_UNSIGNED (gnu_type) = is_boolean ? true : is_unsigned;
>   set_min_and_max_values_for_integral_type (gnu_type, esize,
> TYPE_SIGN (gnu_type));
>   process_attributes (&gnu_type, &attr_list, true, gnat_entity);

Is NEGATE_EXPR gimple valid for pointer (and offset) types

[Andrew Pinski via Gcc]

While debugging PR 100925, I found that after my match.pd (for
A?CST0:CST1) and phiopt patch to use match-and-simplify, gcc will
produce an negate assignment gimple which has a pointer type (and
offset type).  Before we would produce "cond ? -1B : 0B" in this case
but now we produce:
  _4 = a_2(D) == 0;
  _5 = (void *) _4;
  _6 = -_5;
Which I think would be invalid gimple but the verifiers don't say it is.
Should the verifier reject this gimple and similar ones?  I am going
to do some simple testing to see what code hits it too.

Thanks,
Andrew Pinski

genmatch and cond vs "for (cnd cond vec_cond)" for gimple

[Andrew Pinski via Gcc]

Hi all,
  While moving the simple A CMP 0 ? A : -A patterns from
fold_cond_expr_with_comparison to match, I ran into an issue where
using cond directly in the patterns work while "for cnd (cond
vec_cond)" don't work.
It looks like in the first case we are able to correctly handle the
cond first operand being a comparison while with the for loop we are
not.

That is the following additional pattern works:
/* A == 0? A : -Asame as -A */
(simplify
 (cond (eq @0 zerop) @0 (negate@1 @0))
  (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
   @1))
(simplify
 (cond (eq @0 zerop) zerop (negate@1 @0))
  (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
   @1)))

While this one does not work:
(for cnd (cond vec_cond)
/* A == 0? A : -Asame as -A */
(simplify
 (cnd (eq @0 zerop) @0 (negate@1 @0))
  (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
   @1))
(simplify
 (cnd (eq @0 zerop) zerop (negate@1 @0))
  (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
   @1)))

 CUT ---
I will try to debug genmatch some but I wanted to get this email out
to record what will need to be fixed to continue the movement of
phiopt over to match.

Thanks,
Andrew Pinski

Re: genmatch and cond vs "for (cnd cond vec_cond)" for gimple

[Andrew Pinski via Gcc]

On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski  wrote:
>
> Hi all,
>   While moving the simple A CMP 0 ? A : -A patterns from
> fold_cond_expr_with_comparison to match, I ran into an issue where
> using cond directly in the patterns work while "for cnd (cond
> vec_cond)" don't work.
> It looks like in the first case we are able to correctly handle the
> cond first operand being a comparison while with the for loop we are
> not.
>
> That is the following additional pattern works:
> /* A == 0? A : -Asame as -A */
> (simplify
>  (cond (eq @0 zerop) @0 (negate@1 @0))
>   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
>@1))
> (simplify
>  (cond (eq @0 zerop) zerop (negate@1 @0))
>   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
>@1)))
>
> While this one does not work:
> (for cnd (cond vec_cond)
> /* A == 0? A : -Asame as -A */
> (simplify
>  (cnd (eq @0 zerop) @0 (negate@1 @0))
>   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
>@1))
> (simplify
>  (cnd (eq @0 zerop) zerop (negate@1 @0))
>   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
>@1)))
>
>  CUT ---
> I will try to debug genmatch some but I wanted to get this email out
> to record what will need to be fixed to continue the movement of
> phiopt over to match.

So the problem is we lower for loops first and then cond.  Though
swapping the order in genmatch's lower function causes invalid C++
code to be generated :(.
Still trying to figure out why though.

Thanks,
Andrew

>
> Thanks,
> Andrew Pinski

Re: genmatch and cond vs "for (cnd cond vec_cond)" for gimple

[Andrew Pinski via Gcc]

On Sat, Jun 12, 2021 at 5:21 PM Andrew Pinski  wrote:
>
> On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski  wrote:
> >
> > Hi all,
> >   While moving the simple A CMP 0 ? A : -A patterns from
> > fold_cond_expr_with_comparison to match, I ran into an issue where
> > using cond directly in the patterns work while "for cnd (cond
> > vec_cond)" don't work.
> > It looks like in the first case we are able to correctly handle the
> > cond first operand being a comparison while with the for loop we are
> > not.
> >
> > That is the following additional pattern works:
> > /* A == 0? A : -Asame as -A */
> > (simplify
> >  (cond (eq @0 zerop) @0 (negate@1 @0))
> >   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
> >@1))
> > (simplify
> >  (cond (eq @0 zerop) zerop (negate@1 @0))
> >   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
> >@1)))
> >
> > While this one does not work:
> > (for cnd (cond vec_cond)
> > /* A == 0? A : -Asame as -A */
> > (simplify
> >  (cnd (eq @0 zerop) @0 (negate@1 @0))
> >   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
> >@1))
> > (simplify
> >  (cnd (eq @0 zerop) zerop (negate@1 @0))
> >   (if (!HONOR_SIGNED_ZEROS (element_mode (type)))
> >@1)))
> >
> >  CUT ---
> > I will try to debug genmatch some but I wanted to get this email out
> > to record what will need to be fixed to continue the movement of
> > phiopt over to match.
>
> So the problem is we lower for loops first and then cond.  Though
> swapping the order in genmatch's lower function causes invalid C++
> code to be generated :(.
> Still trying to figure out why though.

I figured out why; lower_cond does not copy for_subst_vec for the new
simplifier.  Fixing that allows the switching of the order of the two
lower functions which is needed in this case.
I will submit the patch for this when I submit the patch set for
converting the simple "A CMP 0 ? A : - A" of
fold_cond_expr_with_comparison.

Thanks,
Andrew Pinski

>
> Thanks,
> Andrew
>
> >
> > Thanks,
> > Andrew Pinski

Re: Some libgcc headers are missing the runtime exception

[Andrew Pinski via Gcc]

On Fri, Jul 9, 2021 at 10:40 AM David Edelsohn via Gcc  wrote:
>
> On Fri, Jul 9, 2021 at 1:31 PM Richard Sandiford
>  wrote:
> >
> > David Edelsohn  writes:
> > > On Fri, Jul 9, 2021 at 12:53 PM Richard Sandiford via Gcc
> > >  wrote:
> > >>
> > >> Hi,
> > >>
> > >> It was pointed out to me off-list that config/aarch64/value-unwind.h
> > >> is missing the runtime exception.  It looks like a few other files
> > >> are too; a fuller list is:
> > >>
> > >> libgcc/config/aarch64/value-unwind.h
> > >> libgcc/config/frv/frv-abi.h
> > >> libgcc/config/i386/value-unwind.h
> > >> libgcc/config/pa/pa64-hpux-lib.h
> > >>
> > >> Certainly for the aarch64 file this was simply a mistake;
> > >> it seems to have been copied from the i386 version, both of which
> > >> reference the runtime exception but don't actually include it.
> > >>
> > >> What's the procedure for fixing this?  Can we treat it as a textual
> > >> error or do the files need to be formally relicensed?
> > >
> > > I'm unsure what you mean by "formally relicensed".
> >
> > It seemed like there were two possibilities: the licence of the files
> > is actually GPL + exception despite what the text says (the textual
> > error case), or the licence of the files is plain GPL because the text
> > has said so since the introduction of the files.  In the latter case
> > I'd have imagined that someone would need to relicense the code so
> > that it is GPL + exception.
> >
> > > It generally is considered a textual omission.  The runtime library
> > > components of GCC are intended to be licensed under the runtime
> > > exception, which was granted and approved at the time of introduction.
> >
> > OK, thanks.  So would a patch to fix at least the i386 and aarch64 header
> > files be acceptable?  (I'm happy to fix the other two as well if that's
> > definitely the right thing to do.  It's just that there's more history
> > involved there…)
>
> Please correct the text in the files. The files in libgcc used in the
> GCC runtime are intended to be licensed with the runtime exception and
> GCC previously was granted approval for that licensing and purpose.
>
> As you are asking the question, I sincerely doubt that ARM and Cavium
> intended to apply a license without the exception to those files.  And
> similarly for Intel and FRV.

Yes I did not intend to apply without the exception.

Thanks,
Andrew Pinski

>
> The runtime exception explicitly was intended for this purpose and
> usage at the time that GCC received approval to apply the exception.
>
> Thanks, David

Re: gcc plugin on MacOS failure

[Andrew Pinski via Gcc]

On Thu, Jul 22, 2021 at 7:37 AM Marc  wrote:
>
> Hi,
>
> I have a gcc plugin (for afl++,
> https://github.com/AFLplusplus/AFLplusplus) that works fine when
> compiled on Linux but when compiled on MacOS (brew install gcc) it fails:
>
> ~/afl++ $ g++-11 -g -fPIC -std=c++11
> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin/include
> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin
> -I/usr/local//Cellar/gmp/6.2.1/include -shared
> instrumentation/afl-gcc-pass.so.cc -o afl-gcc-pass.so

A few things, You are not building the plugin with the correct options
for darwin.
Basically you need to allow undefined references and then also use
dylib as the extension.
A few other things too.  I always forgot the exact options to use on
Darwin really.  GNU libtool can help with that.

Thanks,
Andrew


> Undefined symbols for architecture x86_64:
>   "__Z10build_declj9tree_codeP9tree_nodeS1_", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass21get_afl_prev_loc_declEv in ccHhkWiv.o
>   __ZN12_GLOBAL__N_18afl_pass21get_afl_area_ptr_declEv in ccHhkWiv.o
>   "__Z12unshare_exprP9tree_node", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z13build_fn_declPKcP9tree_node", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass18get_afl_trace_declEv in ccHhkWiv.o
>   "__Z13build_int_cstP9tree_node8poly_intILj1ExE", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z13build_one_cstP9tree_node", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z14build_zero_cstP9tree_node", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z14create_tmp_varP9tree_nodePKc", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z15expand_locationj", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass13getSourceNameEP8function in ccHhkWiv.o
>   "__Z15get_random_seedb", referenced from:
>   _plugin_init in ccHhkWiv.o
>   "__Z16fold_convert_locjP9tree_nodeS0_", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z17gimple_build_callP9tree_nodejz", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z18build_complex_typeP9tree_nodeb", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z18build_pointer_typeP9tree_node", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass21get_afl_area_ptr_declEv in ccHhkWiv.o
>   "__Z18set_decl_tls_modelP9tree_node9tls_model", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass21get_afl_prev_loc_declEv in ccHhkWiv.o
>   "__Z19gimple_build_assignP9tree_node9tree_codeS0_S0_", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z19gimple_build_assignP9tree_nodeS0_", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z19gimple_seq_add_stmtPP6gimpleS0_", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>
> "__Z21gsi_insert_seq_beforeP20gimple_stmt_iteratorP6gimple19gsi_iterator_update",
> referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z24build_function_type_listP9tree_nodez", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass18get_afl_trace_declEv in ccHhkWiv.o
>   "__Z26get_identifier_with_lengthPKcm", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass21get_afl_prev_loc_declEv in ccHhkWiv.o
>   __ZN12_GLOBAL__N_18afl_pass21get_afl_area_ptr_declEv in ccHhkWiv.o
>
> "__Z30gimple_build_call_internal_vec11internal_fn3vecIP9tree_node7va_heap6vl_ptrE",
> referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z32gsi_insert_seq_on_edge_immediateP8edge_defP6gimple", referenced
> from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z6build19tree_codeP9tree_nodeS1_", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__Z6build29tree_codeP9tree_nodeS1_S1_", referenced from:
>   __ZN12_GLOBAL__N_18afl_pass7executeEP8function in ccHhkWiv.o
>   "__ZN10vec_prefix22calculate_allocation_1Ejj", referenced from:
>   __ZN10vec_prefix20calculate_allocationEPS_jb in ccHhkWiv.o
>   "__ZN8opt_pass14set_pass_paramEjb", referenced from:
>   __ZTVN12_GLOBAL__N_18afl_passE in ccHhkWiv.o
>   __ZTV15gimple_opt_pass in ccHhkWiv.o
>   "__ZN8opt_pass4gateEP8function", referenced from:
>   __ZTVN12_GLOBAL__N_18afl_passE in ccHhkWiv.o
>   __ZTV15gimple_opt_pass in ccHhkWiv.o
>   "__ZN8opt_pass5cloneEv", referenced from:
>   __ZTVN12_GLOBAL__N_18afl_passE in ccHhkWiv.o
>   __ZTV15gimple_opt_pass in ccHhkWiv.o
>   "__ZN8opt_pass7executeEP8function", referenced from:
>   __ZTV15gimple_opt_pass in ccHhkWiv.o
>   "__ZN8opt_passC2ERK9pass_dataPN

Re: [RFC] Adding a new attribute to function param to mark it as constant

[Andrew Pinski via Gcc]

On Fri, Jul 23, 2021 at 3:55 AM Prathamesh Kulkarni via Gcc
 wrote:
>
> Hi,
> Continuing from this thread,
> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575920.html
> The proposal is to provide a mechanism to mark a parameter in a
> function as a literal constant.
>
> Motivation:
> Consider the following intrinsic vshl_n_s32 from arrm/arm_neon.h:
>
> __extension__ extern __inline int32x2_t
> __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> vshl_n_s32 (int32x2_t __a, const int __b)
> {
>   return (int32x2_t)__builtin_neon_vshl_nv2si (__a, __b);
> }
>
> and it's caller:
>
> int32x2_t f (int32x2_t x)
> {
>return vshl_n_s32 (x, 1);
> }

Can't you do similar to what is done already in the aarch64 back-end:
#define __AARCH64_NUM_LANES(__v) (sizeof (__v) / sizeof (__v[0]))
#define __AARCH64_LANE_CHECK(__vec, __idx)  \
__builtin_aarch64_im_lane_boundsi (sizeof(__vec),
sizeof(__vec[0]), __idx)

?
Yes this is about lanes but you could even add one for min/max which
is generic and such; add an argument to say the intrinsics name even.
You could do this as a non-target builtin if you want and reuse it
also for the aarch64 backend.

Thanks,
Andrew Pinski

>
> The constraint here is that, vshl_n intrinsics require that the
> second arg (__b),
> should be an immediate value.
> Currently, this check is performed by arm_expand_builtin_args, and if
> a non-constant
> value gets passed, it emits the following diagnostic:
>
> ../armhf-build/gcc/include/arm_neon.h:4904:10: error: argument 2 must
> be a constant immediate
>  4904 |   return (int32x2_t)__builtin_neon_vshl_nv2si (__a, __b);
>   |  ^~~
>
> However, we're trying to replace builtin calls with gcc's C vector
> extensions where
> possible (PR66791), because the builtins are opaque to the optimizers.
>
> Unfortunately, we lose type checking of immediate value if we replace
> the builtin
> with << operator:
>
> __extension__ extern __inline int32x2_t
> __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> vshl_n_s32 (int32x2_t __a, const int __b)
> {
>   return __a << __b;
> }
>
> So, I was wondering if we should have an attribute for a parameter to
> specifically
> mark it as a constant value with optional range value info ?
> As Richard suggested, sth like:
> void foo(int x __attribute__((literal_constant (min_val, max_val)));
>
> Thanks,
> Prathamesh

Re: How to detect user uses -masm=intel?

[Andrew Pinski via Gcc]

On Wed, Jul 28, 2021 at 6:41 PM unlvsur unlvsur via Gcc  wrote:
>
> Any GCC macro that can tell the code it is using the intel format’s assembly 
> instead of at&t??

Inside the inline-asm you can use the alternative.
Like this:
cmp{b}\t{%1, %h0|%h0, %1}

This is how GCC implements this inside too.

Thanks,
Andrew

>
> Sent from Mail for Windows 10
>

Re: Porting to gcc 11 / intrinsics

[Andrew Pinski via Gcc]

On Tue, Aug 24, 2021 at 6:39 PM NightStrike via Gcc  wrote:
>
> Should I make this a bugzilla? I guess I figured that wouldn't be
> appropriate.

I don't see a reason why this should go into porting as there was no
change needed from previous versions of GCC.
Supporting -mno-sse is a new feature even.

Thanks,
Andrew


>
> On Mon, Aug 9, 2021, 07:16 NightStrike  wrote:
>
> > When porting to GCC 11, care must be taken to adjust includes of GCC
> > intrinsic headers due to this change:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148
> >
> > That should be reflected in:
> >
> > https://gcc.gnu.org/gcc-11/porting_to.html
> >

[FYI] bugzilla cleanup

[Andrew Pinski via Gcc]

Hi all,
  I am doing some bugzilla cleanup.  This includes disabling some
components and some versions for new bugs.
So far I have disabled versions before GCC 4 because we have not had a
report from someone for those versions in over 7 years.  I disabled
some versions which are about developmental branches which are
inactive too.
I also disabled the java, libgcj, fastjar, libmudflap, treelang and
libf2c components.

I am in the process of moving away from having an inline-asm component
to an inline-asm keyword instead; this was suggested on IRC and I
agree.  After the current open bugs have moved away from the
inline-asm component, I will disable it also.

If anyone else has any other suggestions that should be done, please
let me know and I will look into doing it.

Thanks,
Andrew

Re: Can gcc.dg/torture/pr67828.c be an infinite loop?

[Andrew Pinski via Gcc]

On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc  wrote:
>
> Hi folks.
>
> My upcoming threading improvements turn the test below into an infinite
> runtime loop:
>
> int a, b;
> short c;
>
> int
> main ()
> {
>int j, d = 1;
>for (; c >= 0; c++)
>  {
> BODY:
>a = d;
>d = 0;
>if (b)
> {
>   xprintf (0);
>   if (j)
> xprintf (0);
> }
>  }
>xprintf (d);
>exit (0);
> }
>
> On the false edge out of if(b) we thread directly to BODY, eliding the
> loop conditional, because we know that c>=0 because it could never overflow.

Huh about c>=0 being always true? the expression, "c++" is really c=
(short)(((int)c)+1).  So it will definitely wrap over when c is
SHRT_MAX.

Thanks,
Andrew Pinski

>
> Since B is globally initialized to 0, this has the effect of turning the
> test into an infinite loop.
>
> Is this correct, or did I miss something?
> Aldy
>

Re: Can gcc.dg/torture/pr67828.c be an infinite loop?

[Andrew Pinski via Gcc]

On Fri, Sep 24, 2021 at 2:35 AM Aldy Hernandez  wrote:
>
>
>
> On 9/24/21 11:29 AM, Andrew Pinski wrote:
> > On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc  
> > wrote:
> >>
> >> Hi folks.
> >>
> >> My upcoming threading improvements turn the test below into an infinite
> >> runtime loop:
> >>
> >> int a, b;
> >> short c;
> >>
> >> int
> >> main ()
> >> {
> >> int j, d = 1;
> >> for (; c >= 0; c++)
> >>   {
> >> BODY:
> >> a = d;
> >> d = 0;
> >> if (b)
> >>  {
> >>xprintf (0);
> >>if (j)
> >>  xprintf (0);
> >>  }
> >>   }
> >> xprintf (d);
> >> exit (0);
> >> }
> >>
> >> On the false edge out of if(b) we thread directly to BODY, eliding the
> >> loop conditional, because we know that c>=0 because it could never 
> >> overflow.
> >
> > Huh about c>=0 being always true? the expression, "c++" is really c=
> > (short)(((int)c)+1).  So it will definitely wrap over when c is
> > SHRT_MAX.
>
> I see.
>
> Is this only for C++ or does it affect C as well?

This is standard C code; promotion rules; that is if a type is less
than int, it will be promoted to int if all of the values fit into
int; otherwise it will be promoted to unsigned int.

Thanks,
Andrew Pinski

>
> Aldy
>

Re: assembler errors when bootstrapping with #pragma optimize "0"

[Andrew Pinski via Gcc]

On Thu, Oct 21, 2021 at 5:07 PM Martin Sebor via Gcc  wrote:
>
> I put #pragma GCC optimize "0" at the top of gimplify.c to help
> me debug something in a bootstrapped compiler.  The file failed
> to compile with many assembler errors like this:
>
> /tmp/ccL9zcXD.s: Assembler messages:
> /tmp/ccL9zcXD.s:9: Error: CFI instruction used without previous
> .cfi_startproc
>
> I've done this before and had no problems.  Is this supposed to
> work or was I just lucky when it did before?

I see that dwarf2out_do_cfi_asm is sticky, once true or false, it will
always return true or false.
So it might be an issue there.

Thanks,
Andrew Pinski


>
> Thanks
> Martin
>
> PS The top of gimplify.s is below (this is with no other code
> changes to any files except the #pragma).
>
> .file   "gimplify.c"
> .text
> .local  _ZZ20gimplify_va_arg_exprPP9tree_nodePP6gimpleS4_E9gave_help
> .comm   
> _ZZ20gimplify_va_arg_exprPP9tree_nodePP6gimpleS4_E9gave_help,1,1
> .p2align 4
> .type   _ZL19handled_component_pPK9tree_node, @function
> _ZL19handled_component_pPK9tree_node:
> pushq   %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq%rsp, %rbp
> .cfi_def_cfa_register 6
> movq%rdi, -8(%rbp)
> movq-8(%rbp), %rax
> movzwl  (%rax), %eax
> movzwl  %ax, %eax
> subl$47, %eax
> cmpl$6, %eax
> ja  .L2
> movl$1, %eax
> jmp .L3
> .L2:
> movl$0, %eax
> .L3:
> popq%rbp
> .cfi_def_cfa 7, 8
> ret

Re: Query regarding unusual behaviour for tail padding with different c++ standards

[Andrew Pinski via Gcc]

On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc  wrote:
> #include 
> #include 
> #include 
> struct A {
>   int a;
>   uint64_t b;
>   int c = -1;
> };

The question becomes is the above a standard layout class or not. I
Noticed clang does not change the rules for layout between C++11 and
C++14 but GCC does.
I don't know the exact rules in the ABI to help you there but I do
think you should file a bug because it definitely looks unexpected
really.

Thanks,
Andrew Pinski

Re: Inconsistent segmentation fault in GCC

[Andrew Pinski via Gcc]

On Wed, Dec 22, 2021 at 5:07 PM Alessandro Baretta via Gcc
 wrote:
>
> Hello GCC hackers, and thank you very much for your precious work here.
>
> I've been observing somewhat random GCC segfaults in my C++ 20
> codebase for a while. By "random" I mean that if I rerun the cmake
> build after a failure, 75% out of the time it will succeed, and it
> might fail again the next time I try running the build. I have every
> reason to believe that the issue is not with my code because:
> 1) At the second (or more rarely third) attempt at running the build,
> it succeeds.
> 2) Clang does not segfault on the same codebase, and indeed produces
> correct code.

Maybe https://gcc.gnu.org/PR99831 Which was fixed in GCC 10.4 but was
broken in GCC 10.2.x.
This is a garbage collector related Internal compiler error which can
seem to randomly appear and disappear even.

Thanks,
Andrew Pinski

>
> The codebase is fairly large and heavily templatized, so I know that
> the the compiler allocates a seemingly inordinate amount of memory
> (using top, I've seen it reach a RES size of 1.6GB and a VIRT size of
> 4GB), so I initially attributed the segfaults to lack of enough memory
> on my computer (16GB, with chrome running...). Now I turned on swap
> (32GB), and I see that even when gcc is running, there is plenty of
> available memory, so this is not a plausible cause.
>
> The possibility of a hardware glitch in my system also does not hold
> much water, as neither clang nor any other piece of software seems to
> exhibit any instability.
>
> It'd be great if I could get some guidance on how to investigate this
> issue further. If it were of value to the developers, I'd be happy to
> file a bug report, but given the randomness of the issue, I doubt that
> they'd be able to reproduce the problem even with a preprocessed file.
> What then is my path forward?
>
> Here's some information that might be relevant:
>
> $ cat /etc/debian_version
> 11.1
> $ gcc --version
> gcc (Debian 10.2.1-6) 10.2.1 20210110
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Thanks for any help!
>
> --
> Alex Baretta
> t: 650-383-0227

Re: _Float16-related failures on x86_64-apple-darwin

[Andrew Pinski via Gcc]

On Thu, Dec 23, 2021, 14:24 FX via Gcc  wrote:

> Hi,
>
> Some recently introduced tests have been failing for several weeks on
> x86_64-apple-darwin.
>
> FAIL: gcc.target/i386/cond_op_maxmin__Float16-1.c
> FAIL: gcc.target/i386/pr102464-copysign-1.c
> FAIL: gcc.target/i386/pr102464-fma.c
> FAIL: gcc.target/i386/pr102464-maxmin.c
> FAIL: gcc.target/i386/pr102464-sqrtph.c
> FAIL: gcc.target/i386/pr102464-sqrtsh.c
> FAIL: gcc.target/i386/pr102464-vrndscaleph.c
>
> In all cases the symptom is the same: the include of  errors out
> with “Unsupported value of __FLT_EVAL_METHOD__”. It appears that the
> compile option -mavx512fp16 defines __FLT_EVAL_METHOD__ to have value 16,
> which is not understood by darwin:
>
> > /*  Define float_t and double_t per C standard, ISO/IEC 9899:2011 7.12 2,
> > taking advantage of GCC's __FLT_EVAL_METHOD__ (which a compiler may
> > define anytime and GCC does) that shadows FLT_EVAL_METHOD (which a
> > compiler must define only in float.h).
>   */
> > #if __FLT_EVAL_METHOD__ == 0
> > typedef float float_t;
> > typedef double double_t;
> > #elif __FLT_EVAL_METHOD__ == 1
> > typedef double float_t;
> > typedef double double_t;
> > #elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1
> > typedef long double float_t;
> > typedef long double double_t;
> > #else /* __FLT_EVAL_METHOD__ */
> > #   error "Unsupported value of __FLT_EVAL_METHOD__."
> > #endif /* __FLT_EVAL_METHOD__ */
>
>
> Is the use of __FLT_EVAL_METHOD__ set to 16 supposed to be portable across
> all targets? Or is it linux-only, and should marked as such?
>

See  https://gcc.gnu.org/bugzilla//show_bug.cgi?id=100854 .


> Thanks for any help you can give.
>
> FX

Re: Why doesn't this pattern match?

[Andrew Pinski via Gcc]

On Thu, Jan 6, 2022 at 8:13 PM Andras Tantos  wrote:
>
> Hello!
>
> My name is Andras Tantos and I just joined this list, so if I'm asking
> something off-topic or not following the rules of the community, please
> let me know.
>
> What I'm working on is to port GCC (and Binutils) to a new CPU ISA, I
> call 'brew'. During developing for this target, I got the following
> error:

How are the following constraints defined:
W,A,B

Does one include the pc register?
Otherwise you have a mismatch between the predicate
brew_general_mov_src_operand (which accepts the pc register) and the
constraint which does not.

Thanks,
Andrew Pinski


>
> >
> first.c: In function ‘test_call’:
> first.c:61:52: error: insn does not satisfy its constraints:
>61 | int test_call(int a, int b) { return test_qm(a,b); }
>   |^
> (insn 25 8 9 (set (reg:SI 6 $r6)
> (reg:SI 0 $pc)) "first.c":61:38 17 {*movsi}
>  (nil))
> during RTL pass: final
> first.c:61:52: internal compiler error: in final_scan_insn_1, at
> final.c:2811
> 0x6c4c23 _fatal_insn(char const*, rtx_def const*, char const*, int,
> char const*)
> ../../brew-gcc/gcc/rtl-error.c:108
> 0x6c4c4f _fatal_insn_not_found(rtx_def const*, char const*, int, char
> const*)
> ../../brew-gcc/gcc/rtl-error.c:118
> 0x643585 final_scan_insn_1
> ../../brew-gcc/gcc/final.c:2811
> 0xb1ef3f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
> ../../brew-gcc/gcc/final.c:2940
> 0xb1f207 final_1
> ../../brew-gcc/gcc/final.c:1997
> 0xb1fbe6 rest_of_handle_final
> ../../brew-gcc/gcc/final.c:4285
> 0xb1fbe6 execute
> ../../brew-gcc/gcc/final.c:4363
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
>
> Clearly, the compiler couldn't find a rule that works for this register
> move. The relevant section of the .md file is:
>
> 
> (define_expand "movsi"
>[(set (match_operand:SI 0 "general_operand" "")
>  (match_operand:SI 1 "general_operand" ""))]
>""
>   "
> {
>   /* If this is a store, force the value into a register.  */
>   if (! (reload_in_progress || reload_completed))
>   {
> if (MEM_P (operands[0]))
> {
>   operands[1] = force_reg (SImode, operands[1]);
>   if (MEM_P (XEXP (operands[0], 0)))
> operands[0] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP
> (operands[0], 0)));
> }
> else
>   if (MEM_P (operands[1])
>   && MEM_P (XEXP (operands[1], 0)))
> operands[1] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP
> (operands[1], 0)));
>   }
> }")
>
> (define_insn "*movsi"
>   [(set (match_operand:SI 0
> "nonimmediate_operand""=r,r,r,W,A,B,r,r,r")
> (match_operand:SI 1 "brew_general_mov_src_operand"
> "O,r,i,r,r,r,W,A,B"))]
>   "register_operand (operands[0], SImode)
>|| register_operand (operands[1], SImode)"
>   "@
>%0 <- %0 - %0
>%0 <- %1
>%0 <- %1
>mem[%0] <- %1
>mem[%0] <- %1
>mem[%0] <- %1
>%0 <- mem[%1]
>%0 <- mem[%1]
>%0 <- mem[%1]"
> )
> 
>
> As you can imagine, I'm fairly new to GCC development, so I must be
> making some rookie mistake here, but I would have thought that the
> second alternative in the "*movsi" rule above would match the pattern.
>
> brew_general_mov_src_operand is defined as follows:
>
> 
> (define_predicate "brew_general_mov_src_operand"
>   (match_code "mem,const_int,reg,subreg,symbol_ref,label_ref,const")
> {
>   /* Any (MEM LABEL_REF) is OK.  That is a pc-relative load.  */
>   if (MEM_P (op) && GET_CODE (XEXP (op, 0)) == LABEL_REF)
> return 1;
>
>   if (MEM_P (op)
>   && GET_CODE (XEXP (op, 0)) == PLUS
>   && GET_CODE (XEXP (XEXP (op, 0), 0)) == REG
>   && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT
>   )
> return 1;
>   /* Any register is good too */
>   if (REG_P(op))
> return 1;
>   /* PC as source is also acceptable */
>   if (op == pc_rtx)
> return 1;
>   return general_operand (op, mode);
> })
> 
>
> Thanks for all the help,
> Andras
>
>

Re: Mass rename of C++ .c files to .cc suffix?

[Andrew Pinski via Gcc]

On Fri, Jan 7, 2022 at 2:35 AM Richard Sandiford via Gcc
 wrote:
>
> Martin Jambor  writes:
> > Hi,
> >
> > Would anyone be terribly against mass renaming all *.c files (that are
> > actually C++ files) within the gcc subdirectory to ones with .cc suffix?
> >
> > We already have 47 files with suffix .cc directly in the gcc
> > subdirectory and 160 if we also count those in (non-testsuite)
> > subdirectories, while the majority of our non-header C++ files still has
> > the .c suffix.
> >
> > I have already missed stuff when grepping because I did not include *.cc
> > files and the inconsistency is also just ugly and must be very confusing
> > to anyone who encounters it for the first time.
> >
> > Since we have switched to git, this should have quite small effect on
> > anyone who does their development on branches.  With Martin Liška we did
> > a few experiments and git blame, git rebase and even git gcc-backport
> > worked seamlessly across a rename.
> >
> > I would be fine waiting with it until GCC 12 gets released but see
> > little value in doing so.
> >
> > What do others think?  (Any important caveats I might have missed?)
>
> +1 in favour FWIW.  And I agree we might as well do it now.  It seems
> likely to be less disruptive than waiting to GCC 12, since at that point
> there's going to be more bug fixes that need to be applied to both trunk
> and the new branch, as well as the unleashed stage 1 patches.

+1 in favor. (I don't mind it either time really).
I also think the generated files that get built in the build directory
should also be moved but that is more depth patch.

Thanks,
Andrew Pinski


>
> Thanks,
> Richard

Re: reordering of trapping operations and volatile

[Andrew Pinski via Gcc]

On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc  wrote:
>
>
> Hi Richard,
>
> I have a question regarding reodering of volatile
> accesses and trapping operations. My initial
> assumption (and  hope) was that compilers take
> care to avoid creating traps that are incorrectly
> ordered relative to observable behavior.
>
> I had trouble finding examples, and my cursory
> glace at the code seemed to confirm that GCC
> carefully avoids this.  But then someone showed
> me this example, where this can happen in GCC:
>
>
> volatile int x;
>
> int foo(int a, int b, _Bool store_to_x)
> {
>   if (!store_to_x)
> return a / b;
>   x = b;
>   return a / b;
> }
>
>
> https://godbolt.org/z/vq3r8vjxr

The question becomes what is a trapping instruction vs an undefined instruction?
For floating point types, it is well defined what is a trapping
instruction while for integer types it is not well defined.
On some (many?) targets dividing by 0 is just undefined and does not
trap (powerpc, aarch64, arm and many others; MIPS it depends on the
options passed to GCC if the conditional trap should be inserted or
not).
The other side is if there is undefined code on the path, should
observable results happen first (stores to volatile/atomics, etc.)?

GCC assumes by default that divide is trappable but stores not are not
observable. This is where -fnon-call-exceptions come into play.

In the second case, GCC assumes reducing trappable instructions are
fine. Note I thought -fno-delete-dead-exceptions would fix the sink
but it didn't.

Thanks,
Andrew Pinski

>
> In this example a division is hoisted
> before the volatile store. (the division
> by zero which could trap is UB, of course).
>
> As Martin Sebor pointed out this is done
> as part of redundancy elimination
> in tree-ssa-pre.c and that this might
> simply be an oversight (and could then be
> fixed with a small change).
>
> Could you clarify whether such reordering
> is intentional and could be exploited in
> general also in other optimizations or
> confirm that this is an oversight that
> affects only this specific case?
>
> If this is intentional, are there examples
> where this is important for optimization?
>
>
> Martin
>
>
>
>
>
>

Re: What's wrong with this RTL?

[Andrew Pinski via Gcc]

On Sun, Jan 9, 2022 at 8:49 PM Andras Tantos  wrote:
>
> All!
>
> I'm trying to port GCC to a new target, I call 'brew'. I've based it on
> the Moxie target mostly because of it's simplicity.
>
> I must be doing something horribly wrong as the following C code crokes
> in the LRA path:
>
>long long foo (long long a, long long *w)
>{
>  return __builtin_add_overflow (a, a, w);
>}
>
> The error message I get is the following:
>
>during RTL pass: reload
>../brew-gcc-build/second.c: In function ‘foo’:
>../brew-gcc-build/second.c:5:1: internal compiler error: maximum
>number of generated reload insns per insn achieved (90)
>5 | }
>  | ^
>0xd23854 lra_constraints(bool)
> ../../brew-gcc/gcc/lra-constraints.c:5095
>0xd10322 lra(_IO_FILE*)
> ../../brew-gcc/gcc/lra.c:2336
>0xcc86d9 do_reload
> ../../brew-gcc/gcc/ira.c:5932
>0xcc86d9 execute
> ../../brew-gcc/gcc/ira.c:6118
>Please submit a full bug report,
>with preprocessed source if appropriate.
>Please include the complete backtrace with any bug report.
>See  for instructions.

This usually means the move instruction is being reloaded over and
over again as you describe below.
I think you should have one merged movsi instruction which handles all
of the constraints together. mov is "special" in that it needs to be
done that way otherwise this happens.
But really there seems to be another issue where (subreg:SI (reg:DI))
is not being accepted for the xor set too.
What regclasses are being chosen for the reg DI mode? Etc.

Thanks,
Andrew Pinski


>
>The repro seems to go away, if:
>
>1. If I don't use the return value from __builtin_add_overflow
>2. If I don't return a long long value
>3. If I use some other function, which is not inlined
>4. If I write and call some other (somewhat non-trivial) force-inline
>function myself
>
>In other words, this is pretty much the minimal repro, I've found so
>far.
>
>The initial RTL passed in to LRA appears to be:
>
>(insn 2 4 3 2 (set (mem/f/c:SI (plus:SI (reg/f:SI 16 ?ap)
>(const_int 12 [0xc])) [2 w+0 S4 A32])
>(reg:SI 4 $r4)) "../brew-gcc-build/second.c":2:1 23
>{*movsi_store}
> (expr_list:REG_DEAD (reg:SI 4 $r4)
>(nil)))
>
>(note 3 2 8 2 NOTE_INSN_FUNCTION_BEG)
>
>(insn 8 3 6 2 (clobber (reg:DI 27 [ _5+8 ])) "../brew-gcc-
>build/second.c":3:10 -1
> (nil))
>
>(insn 6 8 7 2 (set (subreg:SI (reg:DI 27 [ _5+8 ]) 0)
>(const_int 0 [0])) "../brew-gcc-build/second.c":3:10 20
>{*movsi_immed}
> (nil))
>
>(insn 7 6 13 2 (set (subreg:SI (reg:DI 27 [ _5+8 ]) 4)
>(const_int 0 [0])) "../brew-gcc-build/second.c":3:10 20
>{*movsi_immed}
> (nil))
>
>(insn 13 7 18 2 (clobber (reg:DI 30)) "../brew-gcc-
>build/second.c":3:10 -1
> (nil))
>
>(insn 18 13 19 2 (clobber (reg:DI 33)) "../brew-gcc-
>build/second.c":3:10 -1
> (nil))
>
>(insn 19 18 20 2 (clobber (reg:DI 36)) "../brew-gcc-
>build/second.c":3:10 -1
> (nil))
>
>(insn 20 19 21 2 (set (subreg:SI (reg:DI 36) 4)
>(plus:SI (subreg:SI (reg:DI 30) 4)
>(subreg:SI (reg:DI 33) 4))) "../brew-gcc-
>build/second.c":3:10 2 {addsi3}
> (nil))
>
>(insn 21 20 22 2 (set (reg:SI 37)
>(const_int 1 [0x1])) "../brew-gcc-build/second.c":3:10 20
>{*movsi_immed}
> (nil))
>
>(jump_insn 22 21 83 2 (set (pc)
>(if_then_else (ltu (subreg:SI (reg:DI 36) 4)
>(subreg:SI (reg:DI 30) 4))
>(label_ref 24)
>(pc))) "../brew-gcc-build/second.c":3:10 38 {cbranchsi4}
> (nil)
> -> 24)
>
>(note 83 22 23 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
>
>(insn 23 83 24 3 (set (reg:SI 37)
>(const_int 0 [0])) "../brew-gcc-build/second.c":3:10 20
>{*movsi_immed}
> (nil))
>
>(code_label 24 23 84 4 4 (nil) [1 uses])
>
>(note 84 24 25 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
>
>(insn 25 84 26 4 (set (subreg:SI (reg:DI 36) 0)
>(plus:SI (subreg:SI (reg:DI 30) 0)
>(subreg:SI (reg:DI 33) 0))) "../brew-gcc-
>build/second.c":3:10 2 {addsi3}
> (expr_list:REG_DEAD (reg:DI 33)
>(expr_list:REG_DEAD (reg:DI 30)
>(nil
>
>(insn 26 25 27 4 (set (reg:SI 38)
>(plus:SI (reg:SI 37)
>(subreg:SI (reg:DI 36) 0))) "../brew-gcc-
>build/second.c":3:10 2 {addsi3}
> (expr_list:REG_DEAD (reg:SI 37)
>(nil)))
>
>(insn 27 26 28 4 (set (subreg:SI (reg:DI 36) 0)
>(reg:SI 38)) "../brew-gcc-build/second.c":3:10 21
>{*movsi_move}
> (expr_list:REG_DEAD (reg:SI 38)
>(nil)))
>
>(insn 28 27 29 4 (set (reg:SI 40)
>(mem/c:SI (plus:SI (reg/f:SI 16 ?ap)
>(const_in

Re: Prerequisites page lists http://multiprecision.org but it supports https too/instead

[Andrew Pinski via Gcc]

On Tue, Feb 1, 2022 at 12:20 PM Jonathan Leffler via Gcc
 wrote:
>
> The prerequisites page https://gcc.gnu.org/install/prerequisites.html lists
> (for MPC):
>
> It can be downloaded from http://www.multiprecision.org/mpc/.
>
>
> The website actually supports https now: https://www.multiprecision.org/mpc/

Thanks for the report,
I committed the fix
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589628.html
(r12-6983) and it will appear the next time the documentation is
regenerated (I don't know the schedule sorry).

Thanks,
Andrew

>
> --
> Jonathan Leffler   #include 
> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org
> "Blessed are we who can laugh at ourselves, for we shall never cease to be
> amused."

Re: [Intel SPR] Progress of GCC support for Intel SPR features

[Andrew Pinski via Gcc]

On Sun, Feb 6, 2022 at 5:59 PM LiYancheng via Gcc  wrote:
>
> Hello everyone!
>
> I have some questions to ask:
>
> 1. How does GCC support Sapphrie Rapids CPU now?
>
> 2. Does GCC 11 fully support all the features of SPR?
>  From the release note, it seems that 5g ISA (fp16)/hfni is
> not supported yet.

It will be included in GCC 12 which should be released in less than 4 months.

>
> 3. What is the simulation tool used by GCC to verify SPR characteristics?
> Is it open source?

Intel is doing the patching to GCC and binutils so I suspect they
verify using their internal tools and I highly doubt it is free
source.


Thanks,
Andrew Pinski


>
> Thanks for all the help,
>
> yancheng
>

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

[Andrew Pinski via Gcc]

On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc
 wrote:
>
> Hello,
>
> I want to know whether it is correct to add left shift instruction to
> a constant expression statement like "_3 + 4"?
>
> I am trying to add a left shift instruction in between below GIMPLE
> instructions -
>
>:
>   instrn_buffer.0_1 = instrn_buffer;
>   _2 = tree.cnt;
>   _3 = (int) _2;
>   _4 = _3 + 4;
>   _5 = (unsigned int) _4;// I want to add left shift here
>   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5);
> //this is "stmt"
>
> I am using this snippet in custom gcc plugin -
>
>   tree lshift_tmp = make_temp_ssa_name (integer_type_node,
> NULL, "slli");

A couple of things.
I Noticed you use integer_type_node here. Why not the type of what is
being replaced?
That is the main thing I see right now.

Also you shouldn't need to do:
update_ssa (TODO_update_ssa);

As make_temp_ssa_name is a new SSA name already and such.

Thanks,
Andrew Pinski

>   gimple *lshift = gimple_build_assign (lshift_tmp, LSHIFT_EXPR, parm,
>   build_int_cst
> (integer_type_node, 8));
>   gsi_insert_before(&gsi, lshift, GSI_NEW_STMT);
>   //Update function call
>   gimple_call_set_arg (stmt, idx, lshift_tmp);
>   update_stmt (stmt);
>   update_ssa (TODO_update_ssa);
>
> from which above GIMPLE IR is modified to -
>
>:
>   instrn_buffer.0_1 = instrn_buffer;
>   _2 = tree.cnt;
>   _3 = (int) _2;
>   _4 = _3 + 4;
>   _5 = (unsigned int) _4;
>   slli_24 = _5 << 8;
>   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, slli_24);
>
>
> 1. When I run above code, either dominator tree validation or tree cfg
> fixup is failing which suggests to me it is either incorrect to apply
> such left shift or some more work is missing?
>
> 2. I followed how a left shift gimple assignment is generated but
> still feels there is something wrong with the above generation. Can
> someone please point me out?
>
> Thanks in advance! As always, the GCC community and its members are
> very supportive, responsive and helpful!
>
> Regards,
> Shubham

Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]

[Andrew Pinski via Gcc]

On Sun, Feb 20, 2022 at 10:45 AM Shubham Narlawar  wrote:
>
> On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski  wrote:
> >
> > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc
> >  wrote:
> > >
> > > Hello,
> > >
> > > I want to know whether it is correct to add left shift instruction to
> > > a constant expression statement like "_3 + 4"?
> > >
> > > I am trying to add a left shift instruction in between below GIMPLE
> > > instructions -
> > >
> > >:
> > >   instrn_buffer.0_1 = instrn_buffer;
> > >   _2 = tree.cnt;
> > >   _3 = (int) _2;
> > >   _4 = _3 + 4;
> > >   _5 = (unsigned int) _4;// I want to add left shift here
> > >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5);
> > > //this is "stmt"
> > >
> > > I am using this snippet in custom gcc plugin -
> > >
> > >   tree lshift_tmp = make_temp_ssa_name (integer_type_node,
> > > NULL, "slli");
> >
> > A couple of things.
> > I Noticed you use integer_type_node here. Why not the type of what is
> > being replaced?
> > That is the main thing I see right now.
>
> I want to apply left shift to a constant expression with 8 which is an
> integer. Since I am not replacing a statement, I am creating new
> GIMPLE statement -
>
> tree shift_amt = build_int_cst (integer_type_node, 8);
>
> Here, I am not replacing any GIMPLE statement. Is this the correct way
> to do this?
>
> My goal is to left shift constant expression and update its usage as below -
>
>   _19 = (unsigned int) _18;
>   D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19);
>
> into
>
>   _19 = (unsigned int) _18;
> temp = _19 << 8
>   D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp);
>
> I am storing the left shift result to the new ssa variable name "temp"
> and updating sfploadi parameters as expected.
>
> On doing the above, dom_walker_eliminate is prohibiting me to do the
> above gimple transformation. Is the above transformation complete and
> correct?

I think you misunderstood me. I was saying for a left shift gimple,
the result type and the first operand type must be compatible (signed
and unsigned types are not compatible). In the above case, you have:
integer_type_node = unsigned_int << integer_type_name .

Does that make sense now?

Thanks,
Andrew

>
> >
> > Also you shouldn't need to do:
> > update_ssa (TODO_update_ssa);
> >
> > As make_temp_ssa_name is a new SSA name already and such.
>
> Understood.
>
> Thanks and Regards,
> Shubham
>
>
> >
> > Thanks,
> > Andrew Pinski
> >
> > >   gimple *lshift = gimple_build_assign (lshift_tmp, LSHIFT_EXPR, 
> > > parm,
> > >   build_int_cst
> > > (integer_type_node, 8));
> > >   gsi_insert_before(&gsi, lshift, GSI_NEW_STMT);
> > >   //Update function call
> > >   gimple_call_set_arg (stmt, idx, lshift_tmp);
> > >   update_stmt (stmt);
> > >   update_ssa (TODO_update_ssa);
> > >
> > > from which above GIMPLE IR is modified to -
> > >
> > >:
> > >   instrn_buffer.0_1 = instrn_buffer;
> > >   _2 = tree.cnt;
> > >   _3 = (int) _2;
> > >   _4 = _3 + 4;
> > >   _5 = (unsigned int) _4;
> > >   slli_24 = _5 << 8;
> > >   D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, slli_24);
> > >
> > >
> > > 1. When I run above code, either dominator tree validation or tree cfg
> > > fixup is failing which suggests to me it is either incorrect to apply
> > > such left shift or some more work is missing?
> > >
> > > 2. I followed how a left shift gimple assignment is generated but
> > > still feels there is something wrong with the above generation. Can
> > > someone please point me out?
> > >
> > > Thanks in advance! As always, the GCC community and its members are
> > > very supportive, responsive and helpful!
> > >
> > > Regards,
> > > Shubham

Re: What replaces FOR_EACH_LOOP_FN

[Andrew Pinski via Gcc]

On Wed, Mar 2, 2022 at 2:05 PM Gary Oblock via Gcc  wrote:
>
> Guys,
>
> I've been working on an optimization for quite a bit of time and
> in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN
> no longer exists. I poked around in the archives and tried a Google
> search but found nothing on it.
>
> It suited my needs and I'd hate to have to rewrite a bunch of stuff.
> What replaces it and how do I use?

This changed with r12-2605-ge41ba804ba5f5c. The replacement is just simply:

for (auto loop : loops_list (function, 0))

Thanks,
Andrew Pinski


>
> Thanks,
>
> Gary
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: __attribute__ ((access, ...)) vs __attribute__ ((nonnull))

[Andrew Pinski via Gcc]

On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc  wrote:
>
> We gained __attribute__ ((access, ...)) in GCC 10:
>   https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
> which identifies one of the pointer/reference arguments of a function
> as being accessed according to an access-mode: read_only, read_write,
> write_only, or none.
>
> We also have __attribute__ ((nonnull)) to indicate that a function
> argument (or all of them) must be non-NULL.
>
> There doesn't seem to be a relationship between these in the
> implementation, but it strikes me that almost anywhere that a user
> might use the "access" attribute, that parameter is probably going to
> be required to be nonnull - though perhaps there are cases where APIs
> check for NULL and reject them gracefully?

No, I think they are separate. The access just says these access
attributes are read only, write only, read-write or don't access what
the pointer points to; it does not say they have to be read or written
to.
I think it is a bad idea to connect the two ideas because you could
have some cases where an argument is optional but is only read from;
or is only written to (there are many in GCC sources even).

Thanks,
Andrew Pinski

>
> Might we want to somehow make __attribute__ ((access, ...)) imply
> __attribute__ ((nonnull))?  (for non "none" access modes, perhaps?)
>
> If so, one place to implement this might be in tree.cc's
> get_nonnull_args, and have it add to the bitmap any arguments that
> have an appropriate access attribute.
>
> get_nonnull_args is used in various places:
> - validating builtins
> - in ranger_cache::block_apply_nonnull
> - by -Wnonnull (in pass_post_ipa_warn::execute)
> - by -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument;
> I'm tracking the failure of these last two to make use of __attribute__
> ((access)) in PR analyzer/104860.
>
> So do we:
>
> (a) leave it up to the user, requiring them to specify __attribute__
> ((nonnull)) in addition to  __attribute__ ((access, ...))
>
> (b) leave it up to the individual sites in GCC that currently make use
> of get_nonnull_args to add logic for handling   __attribute__ ((access,
> ...))
>
> (c) extend get_nonnull_args
>
> ?
>
> Thoughts?
> Dave
>

Re: Is this a possible wrong-code issue?

[Andrew Pinski via Gcc]

On Fri, Mar 11, 2022 at 8:21 PM Haoxin Tu via Gcc  wrote:
>
> Dear developers,
>
> May I seek your confirmation to check whether the following program
> triggers a true wrong-code issue or not? I don't want to make noise to the
> bug repository so I'd like to seek your confirmation here first.
>
> The following case makes GCC outputs differ under  -O1 below vs -O1 above
> optimization levels. Here is the program (s.c):
> ```
> #include 
> union {
> int32_t a;
> uint16_t b;
> } c;
> static uint16_t *d = &c.b;
> int32_t *e = &c.a;
> int32_t **f = &e;
> int32_t ***g = &f;
> int32_t *h = &c.a;
> int64_t i() {
> int8_t j = 5;
> *h = j;
> ***g = *d;
> return 0;
> }
> int main() {
> c.a = 1;
> c.b = 1;
> i();
> printf("%d\n", c.a);
> }
> ```
>
> ```
> $gcc-trunk -O0 -w s.c ; ./a.out
> 5
> $gcc-trunk -O1 -w s.c ; ./a.out
> 5
> $gcc-trunk -O2 -w s.c ; ./a.out
> 1
> $gcc-trunk -O3 -w s.c ; ./a.out
> 1
> $gcc-trunk -Os -w s.c ; ./a.out
> 1
> ```
>
> What surprised me was that almost all GCC versions produce different
> results (please check more details here: https://godbolt.org/z/vTzhhvnGE).
> Besides, clang also has the same issue with -O0 vs the above versions. So,
> does this program have any UB? If not, I would like to file new bug reports
> then. Thank you so much!

Yes it looks like a strict aliasing issue though GCC does not
implement some aliasing rules sometimes with unions, see PR 82224.

Thanks,
Adnrew Pinski

>
>
> Best regards,
> Haoxin

Re: -Wstringop-overflow complains about pointers holding explicitly set addresses

[Andrew Pinski via Gcc]

On Wed, Mar 16, 2022 at 1:42 AM Guy Benyei via Gcc  wrote:
>
> Hello all,
> Compiling for RISC-V, I've ran into an error like this:
>
> tmp.c:15:3: error: 'memcpy' writing 4 bytes into a region of size 0 overflows 
> the destination [-Werror=stringop-overflow=]
>15 |   memcpy(&str2->c, &str1->c, sizeof(str2->c));
>   |   ^~~
>
> The error can be triggered by a pretty simple function:
>
> void foo(m_struct_t *str1) {
>   m_struct_t *str2 = (m_struct_t *)0x123400;
>   memcpy(&str2->c, &str1->c, sizeof(str2->c));
> }
>
> Debugging the case, I've found the following remark in gcc/pointer-query.cc:
>
> /* Pointer constants other than null are most likely the result
>of erroneous null pointer addition/subtraction.  Unless zero
>is a valid address set size to zero.  For null pointers, set
>size to the maximum for now since those may be the result of
>jump threading.  */
>
> I'd prefer not to disable this warning, as it seems very helpful, but in 
> embedded SW we have just too many cases we have to set an address explicitly. 
> I understand the concern about erroneous null pointer addition/subtraction, 
> but I think these could be detected in other analysis, while stringop 
> overflow would still work for other cases.
> I see that the warning can be silenced by zero_address_valid, which is only 
> set for x86 non-generic address space for now. I'm not sure if this enabling 
> zero addresses all over the place is right for RISC-V or other potentially 
> embedded targets.
>
> What do you think?

This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 .

Thanks,
Andrew Pinski

>
> Thanks
> Guy

Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect

[Andrew Pinski via Gcc]

On Fri, Apr 1, 2022 at 10:24 AM Mark Rutland via Gcc  wrote:
>
> Hi Jeremy,
>
> Thanks for raising this.
>
> On Fri, Apr 01, 2022 at 11:44:06AM -0500, Jeremy Linton wrote:
> > The relaxed variants of read/write macros are only declared
> > as `asm volatile()` which forces the compiler to generate the
> > instruction in the code path as intended. The only problem
> > is that it doesn't also tell the compiler that there may
> > be memory side effects. Meaning that if a function is comprised
> > entirely of relaxed io operations, the compiler may think that
> > it only has register side effects and doesn't need to be called.
>
> As I mentioned on a private mail, I don't think that reasoning above is
> correct, and I think this is a miscompilation (i.e. a compiler bug).
>
> The important thing is that any `asm volatile` may have a side effects
> generally outside of memory or GPRs, and whether the assembly contains a 
> memory
> load/store is immaterial. We should not need to add a memory clobber in order
> to retain the volatile semantic.
>
> See:
>
>   https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile
>
> ... and consider the x86 example that reads rdtsc, or an arm64 sequence like:
>
> | void do_sysreg_thing(void)
> | {
> |   unsigned long tmp;
> |
> |   tmp = read_sysreg(some_reg);
> |   tmp |= SOME_BIT;
> |   write_sysreg(some_reg);
> | }
>
> ... where there's no memory that we should need to hazard against.
>
> This patch might workaround the issue, but I don't believe it is a correct 
> fix.

It might not be the most restricted fix but it is a fix.
The best fix is to tell that you are writing to that location of memory.
volatile asm does not do what you think it does.
You didn't read further down about memory clobbers:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers
Specifically this part:
The "memory" clobber tells the compiler that the assembly code
performs memory reads or writes to items other than those listed in
the input and output operands




>
> > For an example function look at bcmgenet_enable_dma(), before the
> > relaxed variants were removed. When built with gcc12 the code
> > contains the asm blocks as expected, but then the function is
> > never called.
>
> So it sounds like this is a regression in GCC 12, which IIUC isn't released 
> yet
> per:

It is NOT a bug in GCC 12. Just you depended on behavior which
accidently worked in the cases you were looking at. GCC 12 did not
change in this area at all even.

Thanks,
Andrew Pinski

>
>   https://gcc.gnu.org/gcc-12/changes.html
>
> ... which says:
>
> | Note: GCC 12 has not been released yet
>
> Surely we can fix it prior to release?
>
> Thanks,
> Mark.
>
> >
> > Signed-off-by: Jeremy Linton 
> > ---
> >  arch/arm64/include/asm/io.h | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> > index 7fd836bea7eb..3cceda7948a0 100644
> > --- a/arch/arm64/include/asm/io.h
> > +++ b/arch/arm64/include/asm/io.h
> > @@ -24,25 +24,25 @@
> >  #define __raw_writeb __raw_writeb
> >  static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> >  {
> > - asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
> > + asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
> >  }
> >
> >  #define __raw_writew __raw_writew
> >  static inline void __raw_writew(u16 val, volatile void __iomem *addr)
> >  {
> > - asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr));
> > + asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
> >  }
> >
> >  #define __raw_writel __raw_writel
> >  static __always_inline void __raw_writel(u32 val, volatile void __iomem 
> > *addr)
> >  {
> > - asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
> > + asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
> >  }
> >
> >  #define __raw_writeq __raw_writeq
> >  static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> >  {
> > - asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr));
> > + asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr) : "memory");
> >  }
> >
> >  #define __raw_readb __raw_readb
> > --
> > 2.35.1
> >

Re: config/dfp.m4 license?

[Andrew Pinski via Gcc]

On Fri, Apr 29, 2022 at 1:45 AM Christophe Lyon via Gcc  wrote:
>
> Hi!
>
> The config/dfp.m4 file does not have a license header. Several other .m4
> files in the same directory have a GPL header, many others do not.
>
> Can someone confirm the license of dfp.m4 and add the missing header if
> applicable?

The history is that the code was taken from gcc/configure.ac so yes it
should be the same as that.


>
> Thanks!
>
> Christophe

Re: syntax errors

[Andrew Pinski via Gcc]

On Tue, May 10, 2022 at 3:19 PM André Coelho via Gcc  wrote:
>
> Hey...if the compiler can check syntax errors...why can't it fixed them?

In some cases it does recommend ways of fixing it. But not all syntax
errors are fixable.
Also not all syntax errors might be the wrong behavior vs what the user wanted.

Thanks,
Andrew Pinski



>
>
> thanks
>
>
> andre coelho
>

Re: GCC 9.5 Release Candidate available

[Andrew Pinski via Gcc]

On Fri, May 20, 2022 at 1:03 AM Richard Biener via Gcc  wrote:
>
>
> The first release candidate for GCC 9.5 is available from
>
> https://sourceware.org/pub/gcc/snapshots/9.5.0-RC-20220520/
>
> and shortly its mirrors.  It has been generated from git commit
> 1bc79c506205b6a5db82897340bdebaaf7ada934.
>
> I have so far bootstrapped and tested the release candidate
> on x86_64-suse-linux.
>
> Please test it and report any issues to bugzilla.
>
> If all goes well I'd like to release 9.5 on Friday, May 27th,
> which will then close the branch.

A brand new regression was just filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

This is a regression from 9.4.0 even.

Thanks,
Andrew

Re: [MRISC32] Not getting scaled index addressing in loops

[Andrew Pinski via Gcc]

On Fri, May 27, 2022 at 11:52 PM m  wrote:
>
> Hello!
>
> I maintain a fork of GCC which adds support for my custom CPU ISA,
> MRISC32 (the machine description can be found here:
> https://github.com/mrisc32/gcc-mrisc32/tree/mbitsnbites/mrisc32/gcc/config/mrisc32
> ).
>
> I recently discovered that scaled index addressing (i.e. MEM[base +
> index * scale]) does not work inside loops, but I have not been able to
> figure out why.
>
> I believe that I have all the plumbing in the MD that's required
> (MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_INDEX_P, etc),
> and I have verified that scaled index addressing is used in trivial
> cases like this:
>
> charcarray[100];
> shortsarray[100];
> intiarray[100];
> voidsingle_element(intidx, intvalue) {
> carray[idx] = value; // OK
> sarray[idx] = value; // OK
> iarray[idx] = value; // OK
> }
>
> ...which produces the expected machine code similar to this:
>
> stbr2, [r3, r1] // OK
> sthr2, [r3, r1*2] // OK
> stwr2, [r3, r1*4] // OK
>
> However, when the array assignment happens inside a loop, only the char
> version uses index addressing. The other sizes (short and int) will be
> transformed into code where the addresses are stored in registers that
> are incremented by +2 and +4 respectively.
>
> voidloop(void) {
> for(intidx = 0; idx < 100; ++idx) {
> carray[idx] = idx; // OK
> sarray[idx] = idx; // BAD
> iarray[idx] = idx; // BAD
> }
> } ...which produces:
> .L4:
> sthr1, [r3] // BAD
> stwr1, [r2] // BAD
> stbr1, [r5, r1] // OK
> addr1, r1, #1
> sner4, r1, #100
> addr3, r3, #2 // (BAD)
> addr2, r2, #4 // (BAD)
> bsr4, .L4
>
> I would expect scaled index addressing to be used in loops too, just as
> is done for AArch64 for instance. I have dug around in the machine
> description, but I can't really figure out what's wrong.
>
> For reference, here is the same code in Compiler Explorer, including the
> code generated for AArch64 for comparison: https://godbolt.org/z/drzfjsxf7
>
> Passing -da (dump RTL all) to gcc, I can see that the decision to not
> use index addressing has been made already in *.253r.expand.

The problem is your cost model for the indexing is incorrect; IV-OPTs
uses TARGET_ADDRESS_COST to figure out the cost of each case.
So if you don't have that implemented, then the default one is used
and that will be incorrect in many cases.
You can find IV-OPTs costs and such by using the ivopts dump:
-fdump-tree-ivopts-details .

Thanks,
Andrew Pinski


>
> Does anyone have any hints about what could be wrong and where I should
> start looking?
>
> Regards,
>
>Marcus
>

Re: Gcc Digest, Vol 29, Issue 7

[Andrew Pinski via Gcc]

On Tue, Jul 5, 2022 at 12:21 AM Yair Lenga via Gcc  wrote:
>
> Hi,
>
> Wanted to get some feedback on an idea that I have - trying to address the
> age long issue with type check on VA list function - like 'scanf' and
> friends. In my specific case, I'm trying to build code that will parse a
> list of values from SELECT statement into list of C variables. The type of
> the values is known (by inspecting the result set meta-data). My ideal
> solution will be to implement something like:
>
> int result_set_read(struct result_set *p_result_set, ...);
>
> Which can be called with
>
> int int_var ; float float_var ; char c[20] ;
> result_set_read(rs1, &int_var, &float_var, c) ;
>
> The tricky part is to verify argument type - make sure . One possible path
> I thought was - why not leverage the ability to describe scanf like
> functions (
> result_set_read(rs1, const char *format, ...) __attribute((format (scanf,
> 2, 3)) ;
>
> And then the above call will be
> result_set-read(rs1, "%d %f %s", &int_var, &float_var, c) ;
>
> With the added benefit that GCC will flag as error, if there is mismatch
> between the variable and the type. My function parses the scanf format to
> decide on conversions (just the basic formatting '%f', '%d', '%*s', ...).
> So far big improvement, and the only missing item is the ability to enforce
> check on string sizes - to support better checks against buffer overflow
> (side note: wish there was ability to force inclusion of the max string
> size, similar to the sscanf_s).
>
> My question: does anyone know how much effort it will be to add a new GCC
> built-in (or extension), that will automatically generate a descriptive
> format string, consistent with scanf formatting, avoiding the need to
> manually enter the formatting string. This can be thought of as "poor man
> introspection". Simple macro can then be used to generate it
>
> #define RESULT_SET_READ(rs, ...) result_set_read(rs,
> __builtin_format(__VA_ARGS__),  __VA_ARGS__)
>
> Practically, making the function "safe" (with respect to buffer overflow,
> type conversions) for most use cases.
>
> Any feedback, pointers, ... to how to implement will be appreciated

This is all recorded as https://gcc.gnu.org/PR47781 . You could do a
plugin to handle the attribute maybe.

Thanks,
Andrew Pinski

>
> Yair

Re: Possible C++ method signature warning feature?

[Andrew Pinski via Gcc]

On Wed, Aug 10, 2022 at 6:20 PM Paul Koning via Gcc  wrote:
>
> There's a C++ problem I keep running into, in a very large body of software 
> with lots of subclassing.
>
> There's a base class that defines a set of interface methods, not all pure 
> virtual (some define the default behavior).  A number of subclasses override 
> some but not all of these.
>
> Now I find myself changing the argument list of some of these methods, so I 
> have to change the base class definitions and also track down all the 
> subclass redefinitions.  If I miss one of the latter, that subclass method is 
> no longer called (it now just looks like an unrelated method with a different 
> argument list that isn't used anywhere).  Finding these things can be hard 
> and time consuming.
>
> It would be helpful to have some way to mark a method as "this is supposed to 
> be an override of a base class method", in other words "warn me if this 
> method doesn't override some method in a base class".

C++11's overload keyword sounds exactly what you want.
https://en.cppreference.com/w/cpp/language/override

Thanks,
Andrew Pinski

>
> Does that sound like a possible thing to do, perhaps with some __attribute__ 
> magic?  Would it be interesting?
>
> paul
>

Re: [PATCH 0/3] picolibc: Add picolibc linking help

[Andrew Pinski via Gcc]

On Wed, Aug 24, 2022 at 11:12 AM Keith Packard via Gcc-patches
 wrote:
>
> Picolibc is a C library for embedded systems based on code from newlib
> and avr libc. To connect some system-dependent picolibc functions
> (like stdio) to an underlying platform, the platform may provide an OS
> library.
>
> This OS library must follow the C library in the link command line. In
> current picolibc, that is done by providing an alternate .specs file
> which can rewrite the *lib spec to insert the OS library in the right
> spot.

Why do you need to change the specs to support picolibc? Why not have
the library supply the specs file instead, like what is done for
newlib and libgloss?

>
> This patch series adds the ability to specify the OS library on the
> gcc command line when GCC is configured to us picolibc as the default
> C library, and then hooks that up for arm, nds32, riscv and sh targets.


What OS libraries are not included in libc? I trying to figure out why
this needs to be special cased here.

Thanks,
Andrew Pinski

>
> Keith Packard (3):
>   Allow default libc to be specified to configure
>   Add newlib and picolibc as default C library choices
>   Add '--oslib=' option when default C library is picolibc
>
>  gcc/config.gcc| 56 ---
>  gcc/config/arm/elf.h  |  5 
>  gcc/config/nds32/elf.h|  4 +++
>  gcc/config/picolibc.opt   | 26 ++
>  gcc/config/riscv/elf.h|  4 +++
>  gcc/config/sh/embed-elf.h |  5 
>  gcc/configure.ac  |  4 +++
>  7 files changed, 95 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/config/picolibc.opt
>
> --
> 2.36.1
>

Re: gcc-bug in gcc-11

[Andrew Pinski via Gcc]

On Tue, Oct 4, 2022 at 9:18 AM Shivam Rajput via Gcc  wrote:
>
> Hey, I was trying to build clang's libcxx on my ubuntu 22.04 and it has
> gcc-11.2 by default most prolly, but while building libcxx there was an
> error about using the deleted function but it seems that overloaded
> resolution in gcc-11 has a bug https://godbolt.org/z/GPTPYaobb , it
> consider wrong overloaded function , although i build libcxx using gcc-12 .

Looks like it has always been a bug in GCC (tried GCC 4.4.7 and up)
and was only fixed in GCC 12.1.0.
I have not looked into which patch fixed this though but you could do
a "git bisect" to find the patch or ask a few people who have
pre-built binaries to find the patch which fixed it.
I doubt we are going to backport the fix to a GCC 11 release either
since it is NOT a regression from an earlier version.

Thanks,
Andrew Pinski

>
> Thanks and regards
> Shivam

Re: How do I create a GCC source code tarball?

[Andrew Pinski via Gcc]

On Mon, Oct 3, 2022 at 4:32 PM Robert Dubner  wrote:
>
> I have modified the source code of GCC, and I need a tarball for that
> modified source.
>
> My code is based on the trunk branch of the repository at
> git://gcc.gnu.org/git/gcc.git
>
> I attempted to execute "make dist", and have encountered the response
>
>   Building a full distribution of this tree isn't done
>   via 'make dist'.  Check out the etc/ subdirectory
>
> I have been unable to locate a subdirectory name "etc/".
>
> With that as background, my question is:
>
> How do I create a source code tarball for GCC?

You just tar up the source.
You could use maintainer-scripts/gcc_release to make a snapshot but in
the end it just does `tar xcfj file.tar.bz2 gcc` .

Thanks,
Andrew

>
> Thanks very much for any help.
>
>

Re: [RFC] c++: parser - Support for target address spaces in C++

[Andrew Pinski via Gcc]

On Thu, Oct 6, 2022 at 7:15 AM Paul Iannetta via Gcc  wrote:
>
> Hi,
>
> Presently, GCC supports target address spaces as a GNU extension (cf.
> `info -n "(gcc)Named Address Spaces"`).  This is however supported
> only by the C frontend, which is a bit sad, since all the GIMPLE
> machinery is readily available and, moreover, LLVM supports this GNU
> extension both for C and C++.
>
> Here is a first attempt at a patch to enable the support for target
> address spaces in C++.  The basic idea is only to make the parser
> recognize address spaces, and lower them into GIMPLE, in the same
> fashion as the C parser.  This also makes it possible to merge the
> function `c_register_addr_space` in one place which is better than
> before.
>
> The patch still has some drawbacks compared to its C counterpart.
> Namely, much like the `__restrict__` keyword, it is always enabled and
> -std=c++11 won't disable it (whereas -std=c11) would reject address
> spaces.  Not also that the mangler ignores address spaces, much like
> it ignores __restrict__.

Without the mangler support or overloading support, there would will
be wrong code emitted as some named address spaces don't overlap with
the unnamed ones.
E.g. on SPU (which has been since removed), the name address support
was added to support automatically DMAing from the PPU memory on the
cell. So two address spaces are disjoint.
This is also true on other targets too.
This is biggest reason why this was not added to the C++ front-end.
If clang supports it, does it do overload/template mangling support. I
think we don't want a partial support added which will just break
under simple usage.

Also note named address support is not exactly a GNU specific
extension either;
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf has the
definition of it for C and GCC tries to follow that.
Fixed types support in GCC also follows that draft.

Thanks,
Andrew Pinski


>
> Depending on the reception, I'll add further testcases and will update
> the relevant part of the documentation.
>
> Cheers,
> Paul
>
> Author: Paul Iannetta 
> Date:   Wed Oct 5 16:44:36 2022 +0200
>
> Add support for custom address spaces in C++
>
> gcc/
> * tree.h (ENCODE_QUAL_ADDR_SPACE): Missing parentheses.
>
> gcc/c/
> * c-decl.c: Remove c_register_addr_space.
>
> gcc/c-family/
> * c-common.c (c_register_addr_space): Imported from c-decl.c
> * c-common.h: Remove the FIXME.
>
> gcc/cp/
> * cp-tree.h (enum cp_decl_spec): Add addr_space support.
> (struct cp_decl_specifier_seq): Likewise.
> * decl.c (get_type_quals): Likewise.
> * parser.c (cp_parser_type_specifier): Likewise.
> (cp_parser_cv_qualifier_seq_opt): Likewise
> * tree.c: Remove c_register_addr_space stub.
>
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index 064c2f263f0..282ba54ab70 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -2615,6 +2615,25 @@ c_build_bitfield_integer_type (unsigned HOST_WIDE_INT 
> width, int unsignedp)
>return build_nonstandard_integer_type (width, unsignedp);
>  }
>
> +/* Register reserved keyword WORD as qualifier for address space AS.  */
> +
> +void
> +c_register_addr_space (const char *word, addr_space_t as)
> +{
> +  int rid = RID_FIRST_ADDR_SPACE + as;
> +  tree id;
> +
> +  /* Address space qualifiers are only supported
> + in C with GNU extensions enabled.  */
> +  if (c_dialect_objc () || flag_no_asm)
> +return;
> +
> +  id = get_identifier (word);
> +  C_SET_RID_CODE (id, rid);
> +  TREE_LANG_FLAG_0 (id) = 1;
> +  ridpointers[rid] = id;
> +}
> +
>  /* The C version of the register_builtin_type langhook.  */
>
>  void
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index ed39b7764bf..f2c1df0c8de 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -808,9 +808,6 @@ extern const struct attribute_spec 
> c_common_format_attribute_table[];
>
>  extern tree (*make_fname_decl) (location_t, tree, int);
>
> -/* In c-decl.c and cp/tree.c.  FIXME.  */
> -extern void c_register_addr_space (const char *str, addr_space_t as);
> -
>  /* In c-common.c.  */
>  extern bool in_late_binary_op;
>  extern const char *c_addr_space_name (addr_space_t as);
> @@ -926,6 +923,7 @@ extern void c_common_finish (void);
>  extern void c_common_parse_file (void);
>  extern FILE *get_dump_info (int, dump_flags_t *);
>  extern alias_set_type c_common_get_alias_set (tree);
> +extern void c_register_addr_space (const char *, addr_space_t);
>  extern void c_register_builtin_type (tree, const char*);
>  extern bool c_promoting_integer_type_p (const_tree);
>  extern bool self_promoting_args_p (const_tree);
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index 8e24b522ee4..278d1248d1c 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -11927,25 +11927,6 @@ c_parse_final_cleanups (void)
>ext_block = NULL;
>  }
>
> -/* Register reserved keyword WOR

Re: Need help with match.pd crash

[Andrew Pinski via Gcc]

On Thu, Oct 6, 2022 at 4:00 PM Michael Collison  wrote:
>
> I am trying to improve code generation for coremark to match a recent
> improvement that was made in LLVM.
>
> I added the following transformation to match.pd which attempts to
> replace a branch with straight line code:
>
> /* (cond (and (x , 0x1) == 0), y, (z ^ y) ) -> (-(and (x , 0x1)) & z ) ^
> y */
> (simplify
>  (cond (eq (bit_and @0 integer_onep@1)
>   integer_zerop)
>   @2
>   (bit_xor:c @3 @2))
>  (bit_xor (bit_and (negate (bit_and @0 @1)) @3) @2))
>

I suspect you are missing a convert as @0/@1 might be a different type
from type (@2/@3's type).
Try:
(simplify
 (cond (eq (bit_and @0 integer_onep@1)
  integer_zerop)
  @2
  (bit_xor:c @3 @2))
 (bit_xor (bit_and (negate (convert:type (bit_and @0 @1))) @3) @2))

But I am not 100% sure that match.pd (phiopt since that is where the
transformation is really happening) is the right place for this. I
suspect a better place is rtl level inside either simplify-rtl.cc
and/or inside ifcvt.cc.
Because on some targets has conditional moves which might be better
than doing an and/neg/and/xor.
AARCH64 and MIPS are good examples of that (I know because I spent
time making sure GCC produces the conditional moves for coremarks for
those targets inside crc8).

Thanks,
Andrew Pinski

> I get a internal error, but in stepping through the debugger I can see
> the pattern matches, but fails when when it tries to further simplify
> and match another pattern in match.pd:
>
> /* x & C -> x if we know that x & ~C == 0.  */
> #if GIMPLE
> (simplify
>   (bit_and SSA_NAME@0 INTEGER_CST@1)
>   (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
>&& wi::bit_and_not (get_nonzero_bits (@0), wi::to_wide (@1)) == 0)
>@0))
> #endif
>
> The crash occurs in wi::bit_and_not. Before digging further I want to
> ask if there is a problem with the way I wrote the transformation?
>
>
>

Re: why does gccgit require pthread?

[Andrew Pinski via Gcc]

On Sun, Nov 6, 2022 at 7:59 PM LIU Hao via Gcc  wrote:
>
> Greetings,
>
> At the moment, there are references to pthread mutexes in 
> 'gcc/jit/libgccjit.cc' and
> 'gcc/git/jit-playback.cc'. The former was introduced by 
> 63b2923dc6f57e74d964a9cf14f4ba595ab14ed9 in
> 2020, while the latter was introduced by 
> 38771e4e1fdacfbdac5a14e50fcc0538577b1bdb in 2014.
>
> Does this mean, GCC can't be built with JIT enabled, for some thread model 
> other than `posix` (e.g.
> `win32`), where pthread isn't available?
>
> Can those references to mutexes be replaced with `__gthread_mutex_*` instead? 
> However I see no other
> references to  inside the 'gcc' subdirectory, so I suspect it isn't 
> an option there?

The original code which used pthread was added in GCC 5 way before GCC
moved to being written in C++11 which was only in the last 3 years.
pthread_* functions were the best choice at the time (2014) but now
GCC is written in C++11, I don't see any reason not to move them over
to using C++11 threading code.

Thanks,
Andrew


Thanks,
Andrew Pinski

>
>
> --
> Best regards,
> LIU Hao

Re: why does gccgit require pthread?

[Andrew Pinski via Gcc]

On Sun, Nov 6, 2022 at 10:51 PM LIU Hao  wrote:
>
> 在 2022-11-07 12:37, Andrew Pinski 写道:
> >
> > The original code which used pthread was added in GCC 5 way before GCC
> > moved to being written in C++11 which was only in the last 3 years.
> > pthread_* functions were the best choice at the time (2014) but now
> > GCC is written in C++11, I don't see any reason not to move them over
> > to using C++11 threading code.
> >
> >
>
> Attached is the proposed patch.
>
> The win32 thread model does not have `std::mutex`; but there is no 
> `pthread_mutex_t` either, so it
> does not build either way.
Oh, but I would assume it will later on right?

Also I think you might need to change some more than you did.
That is:
-#define INCLUDE_PTHREAD_H
 #include "system.h"

You must likely have a macro, INCLUDE_MUTEX, and define that and
include mutex in system.h like it was done for pthread.h.
GCC loves to poison identifiers while lexing to make sure those
identifiers are not used inside GCC and the include of mutex should be
done early.

Thanks,
Andrew

>
> Tested bootstrapping GCC on `{i686,x86_64}-w64-mingw32` with languages
> `c,lto,c++,fortran,objc,obj-c++` and with the `mcf` thread model; no errors 
> observed. The built
> `libgccjit-0.dll` does not have imports from winpthread any more.
>
> Please review.
>
>
> --
> Best regards,
> LIU Hao
>

Issues with Sphinx

[Andrew Pinski via Gcc]

Can we just revert back to texinfo?
Sphinx requires manual page splitting which is a downgrade from texinfo.
Stable URLs and links was something which we pushed for fixes for texinfo too.
And many other issues with sphinx which makes it better if we revert
back to texinfo until those are fixed including compile time is a
problem now.

Thanks,
Andrew

Re: Different outputs in Gimple pass dump generated by two different architectures

[Andrew Pinski via Gcc]

On Fri, Nov 11, 2022 at 12:57 AM Marc Glisse via Gcc  wrote:
>
> On Thu, 10 Nov 2022, Kevin Lee wrote:
>
> > While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that
> > x86-64 and risc-v has a different output for the gimple pass since
> > r12-4790-g4b3a325f07acebf4
> > .
>
> Probably since earlier.
>
> > What would be causing the difference? Is this intended? Link
> >  for details. Thank you!
>
> See LOGICAL_OP_NON_SHORT_CIRCUIT in fold-const.cc (and various discussions
> on the topic in mailing lists and bugzilla).

I filed https://gcc.gnu.org/PR107642 to cover the issues around
LOGICAL_OP_NON_SHORT_CIRCUIT and BRANCH_COST.
I hope to get some time in the GCC 14 timeframe to flush out some of
these target macro/hooks issue where the
definitions are not so clear.

Thanks,
Andrew

>
> --
> Marc Glisse

Re: [BUG] -Wuninitialized: initialize variable with itself

[Andrew Pinski via Gcc]

On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
 wrote:
>
> Hi,
>
> While discussing some idea for a new feature, I tested the following example
> program:
>
>
>  int main(void)
>  {
>  int i = i;
>  return i;
>  }

This is NOT a bug but a documented way of having the warning not being there.
See 
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized
"If you want to warn about code that uses the uninitialized value of
the variable in its own initializer, use the -Winit-self option."

Thanks,
Andrew Pinski

>
>
> It seems obvious that it should give a warning, and in Clang it does:
>
>
>  $ clang --version | head -n1
>  Debian clang version 14.0.6
>
>  $ clang -Wall -Wextra foo.c
>  foo.c:3:10: warning: variable 'i' is uninitialized when used within its 
> own
> initialization [-Wuninitialized]
>  int i = i;
>  ~   ^
>  1 warning generated.
>
>
> But for GCC it looks fine:
>
>  $ gcc --version | head -n1
>  gcc (Debian 12.2.0-9) 12.2.0
>
>  $ gcc -Wall -Wextra foo.c
>  $
>
>
> Until you enable the analyzer, which catches the uninitialized use:
>
>
>  $ gcc -fanalyzer foo.c
>  foo.c: In function ‘main’:
>  foo.c:3:13: warning: use of uninitialized value ‘i’ [CWE-457]
> [-Wanalyzer-use-of-uninitialized-value]
>  3 | int i = i;
>| ^
>‘main’: events 1-2
>  |
>  |3 | int i = i;
>  |  | ^
>  |  | |
>  |  | (1) region created on stack here
>  |  | (2) use of uninitialized value ‘i’ here
>  |
>
>
>
> I expect that GCC should be able to detect this bug with a simple warning.  
> The
> analyzer is quite unreadable compared to normal warnings.
>
> Cheers,
> Alex
>
> --
> 

Re: [BUG] -Wuninitialized: initialize variable with itself

[Andrew Pinski via Gcc]

On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski  wrote:
>
> On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
>  wrote:
> >
> > Hi,
> >
> > While discussing some idea for a new feature, I tested the following example
> > program:
> >
> >
> >  int main(void)
> >  {
> >  int i = i;
> >  return i;
> >  }
>
> This is NOT a bug but a documented way of having the warning not being there.
> See 
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized
> "If you want to warn about code that uses the uninitialized value of
> the variable in its own initializer, use the -Winit-self option."

I should note the main reason why I Know about this is because I fixed
this feature years ago (at least for C front-end)
and added the option to disable the feature.

>
> Thanks,
> Andrew Pinski
>
> >
> >
> > It seems obvious that it should give a warning, and in Clang it does:
> >
> >
> >  $ clang --version | head -n1
> >  Debian clang version 14.0.6
> >
> >  $ clang -Wall -Wextra foo.c
> >  foo.c:3:10: warning: variable 'i' is uninitialized when used within 
> > its own
> > initialization [-Wuninitialized]
> >  int i = i;
> >  ~   ^
> >  1 warning generated.
> >
> >
> > But for GCC it looks fine:
> >
> >  $ gcc --version | head -n1
> >  gcc (Debian 12.2.0-9) 12.2.0
> >
> >  $ gcc -Wall -Wextra foo.c
> >  $
> >
> >
> > Until you enable the analyzer, which catches the uninitialized use:
> >
> >
> >  $ gcc -fanalyzer foo.c
> >  foo.c: In function ‘main’:
> >  foo.c:3:13: warning: use of uninitialized value ‘i’ [CWE-457]
> > [-Wanalyzer-use-of-uninitialized-value]
> >  3 | int i = i;
> >| ^
> >‘main’: events 1-2
> >  |
> >  |3 | int i = i;
> >  |  | ^
> >  |  | |
> >  |  | (1) region created on stack here
> >  |  | (2) use of uninitialized value ‘i’ here
> >  |
> >
> >
> >
> > I expect that GCC should be able to detect this bug with a simple warning.  
> > The
> > analyzer is quite unreadable compared to normal warnings.
> >
> > Cheers,
> > Alex
> >
> > --
> > 

Re: [BUG] -Wuninitialized: initialize variable with itself

[Andrew Pinski via Gcc]

On Sun, Nov 13, 2022 at 10:41 AM Andrew Pinski  wrote:
>
> On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski  wrote:
> >
> > On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
> >  wrote:
> > >
> > > Hi,
> > >
> > > While discussing some idea for a new feature, I tested the following 
> > > example
> > > program:
> > >
> > >
> > >  int main(void)
> > >  {
> > >  int i = i;
> > >  return i;
> > >  }
> >
> > This is NOT a bug but a documented way of having the warning not being 
> > there.
> > See 
> > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self
> > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized
> > "If you want to warn about code that uses the uninitialized value of
> > the variable in its own initializer, use the -Winit-self option."
>
> I should note the main reason why I Know about this is because I fixed
> this feature years ago (at least for C front-end)
> and added the option to disable the feature.

When I says years, it was 19 years ago even, see
https://gcc.gnu.org/PR5582
and
https://gcc.gnu.org/PR10538
and
https://gcc.gnu.org/r0-52301-g3390f9c9bef0be

Thanks,


>
> >
> > Thanks,
> > Andrew Pinski
> >
> > >
> > >
> > > It seems obvious that it should give a warning, and in Clang it does:
> > >
> > >
> > >  $ clang --version | head -n1
> > >  Debian clang version 14.0.6
> > >
> > >  $ clang -Wall -Wextra foo.c
> > >  foo.c:3:10: warning: variable 'i' is uninitialized when used within 
> > > its own
> > > initialization [-Wuninitialized]
> > >  int i = i;
> > >  ~   ^
> > >  1 warning generated.
> > >
> > >
> > > But for GCC it looks fine:
> > >
> > >  $ gcc --version | head -n1
> > >  gcc (Debian 12.2.0-9) 12.2.0
> > >
> > >  $ gcc -Wall -Wextra foo.c
> > >  $
> > >
> > >
> > > Until you enable the analyzer, which catches the uninitialized use:
> > >
> > >
> > >  $ gcc -fanalyzer foo.c
> > >  foo.c: In function ‘main’:
> > >  foo.c:3:13: warning: use of uninitialized value ‘i’ [CWE-457]
> > > [-Wanalyzer-use-of-uninitialized-value]
> > >  3 | int i = i;
> > >| ^
> > >‘main’: events 1-2
> > >  |
> > >  |3 | int i = i;
> > >  |  | ^
> > >  |  | |
> > >  |  | (1) region created on stack here
> > >  |  | (2) use of uninitialized value ‘i’ here
> > >  |
> > >
> > >
> > >
> > > I expect that GCC should be able to detect this bug with a simple 
> > > warning.  The
> > > analyzer is quite unreadable compared to normal warnings.
> > >
> > > Cheers,
> > > Alex
> > >
> > > --
> > > 

Re: [whish] -Wunterminated-string-initialization: new warning

[Andrew Pinski via Gcc]

On Sun, Nov 13, 2022 at 1:57 PM Alejandro Colomar via Gcc
 wrote:
>
> Hi!
>
> I'd like to get warnings if I write the following code:
>
> char foo[3] = "foo";

This should be easy to add as it is already part of the -Wc++-compat
option as for C++ it is invalid code.

:2:19: warning: initializer-string for array of 'char' is too long
2 | char two[2] = "foo";   // 'f' 'o'
  |   ^
:3:19: warning: initializer-string for array of 'char' is too
long for C++ [-Wc++-compat]
3 | char   three[3] = "foo";   // 'f' 'o' 'o'
  |   ^


... (for your more complex case [though I needed to modify one of the
strings to exactly 8]

:5:7: warning: initializer-string for array of 'char' is too
long for C++ [-Wc++-compat]
5 |   "01234567",
  |   ^~

  else if (warn_cxx_compat
   && compare_tree_int (TYPE_SIZE_UNIT (type), len) < 0)
warning_at (init_loc, OPT_Wc___compat,
("initializer-string for array of %qT "
 "is too long for C++"), typ1);

That is the current code which does this warning even so it is just a
matter of adding an option to c-family/c.opt and then having
c++-compat enable it and using that new option here.

Thanks,
Andrew Pinski

>
> It's hard to keep track of sizes to make sure that the string literals always
> initialize to terminated strings.  It seems something that should be easy to
> implement in the compiler.
>
> A morecomplex case where it's harder to keep track of sizes is:
>
> static const char  log_levels[][8] = {
>  "alert",
>  "error",
>  "warn",
>  "notice",
>  "info",
>  "debug",
> };
>
> Here, 8 works now (and 7 too, but for aligmnent reasons I chose 8).  If 
> tomorrow
> we add or change an entry, It'll be hard to keep it safe.  Such a warning 
> would
> help a lot.
>
>
> An example program is:
>
> $ cat str.c
> char two[2] = "foo";   // 'f' 'o'
> char   three[3] = "foo";   // 'f' 'o' 'o'
> charfour[4] = "foo";   // 'f' 'o' 'o' '\0'
> charfive[5] = "foo";   // 'f' 'o' 'o' '\0' '\0'
> char implicit[] = "foo";   // 'f' 'o' 'o' '\0'
>
> $ cc -Wall -Wextra str.c
> str.c:1:19: warning: initializer-string for array of ‘char’ is too long
>  1 | char two[2] = "foo";   // 'f' 'o'
>|   ^
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/Scrt1.o:
> in function `_start':
> (.text+0x17): undefined reference to `main'
> collect2: error: ld returned 1 exit status
>
>
> Here, I'd like that with the new warning, 'three' would also get warned.
>
> Cheers,
>
> Alex
> --
> 

Re: -Warray-bounds interprets int *var as int var[0] ?

[Andrew Pinski via Gcc]

On Wed, Nov 23, 2022 at 9:15 AM Georg-Johann Lay  wrote:
>
> The following code throws a warning which I do not understand.
>
> Purpose is to save and restore SREG, which is a special function
> register (SFR) defined by its hardware address as:
>
> #define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__))
>
> which is the common C idiom to define such an SFR. The C code is:
>
> 
> typedef __UINT8_TYPE__ uint8_t;
>
> #define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__))
>
> static __inline__ uint8_t __iCliRetVal (void)
> {
>  __asm__ __volatile__ ("cli" ::: "memory");
>  return 1;
> }
>
> static __inline__ void __iRestore (const uint8_t *__s)
> {
>  SREG = *__s;
>  __asm__ volatile ("" ::: "memory");
> }
>
> void foo (void)
> {
>
> for (uint8_t sreg_save __attribute__((__cleanup__(__iRestore))) = SREG,
>  __ToDo = __iCliRetVal();
>   __ToDo ;
>   __ToDo = 0 )
> {
> __asm ("nop");
> }
> }
> 
>
> The documentation of attribute cleanup says that the function provided
> to cleanup (__iRestore) must take a pointer type that is compatible with
> the attributed variable, which is the case.  The warning is:
>
>   avr-gcc-13 -c foo-i.c -mmcu=atmega8 -Os -Wall -save-temps -dumpbase ""
> foo-i.c: In function 'foo':
> foo-i.c:20:71: warning: array subscript 0 is outside array bounds of
> 'volatile uint8_t[0]' {aka 'volatile unsigned char[]'} [-Warray-bounds]
> 20 |for (uint8_t sreg_save
> __attribute__((__cleanup__(__iRestore))) = SREG,
>|
>   ~^~~~
> In function '__iRestore',
>  inlined from 'foo' at foo-i.c:20:17:
> foo-i.c:13:42: warning: array subscript 0 is outside array bounds of
> 'volatile uint8_t[0]' {aka 'volatile unsigned char[]'} [-Warray-bounds]
> 13 | SREG = *__s;
>|  ^
>
> To me this looks like a GCC problem, and older versions of the compiler
> don't complain.  Or is there actually an issue with that code? Purpose
> of the code is to save / restore SREG around a block of code, "nop" in
> the example.
>
> The warning complains about the places that are using SREG, so it that
> macro definition wrong?

Either you need to use --param=min-pagesize=0 as an option or you need
to modify the avr backend to set that by default.

Thanks,
Andrew Pinski

>
> Thanks in advance,
>
> Johann
>
>
>  > avr-gcc-13 -v
> Using built-in specs.
> Reading specs from
> /home/DATA/gnu/install/gcc-master-avr/bin/../lib/gcc/avr/13.0.0/device-specs/specs-avr2
> COLLECT_GCC=avr-gcc-13
> COLLECT_LTO_WRAPPER=/home/DATA/gnu/install/gcc-master-avr/bin/../libexec/gcc/avr/13.0.0/lto-wrapper
> Target: avr
> Configured with: ../../source/gcc-master/configure --target=avr
> --disable-nls --with-dwarf2 --enable-languages=c,c++ --with-gnu-as
> --with-gnu-ld --disable-shared --with-fixed-point=no
> --prefix=/home/john/gnu/install/gcc-master-avr --enable-checking=release
> Thread model: single
> Supported LTO compression algorithms: zlib
> gcc version 13.0.0 20221103 (experimental) (GCC)
>

Re: Can't build Ada

[Andrew Pinski via Gcc]

On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  wrote:
>
> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
> precise) to build Ada, starting with the latest (2020) release of Gnat from 
> Adacore.

Are you building a cross compiler or a native compiler?
If you are building a cross, you need to bootstrap a native compiler first.

Thanks,
Andrew Pinski

>
> It fails for several reasons.  One is that two source files use [ ] for array 
> initializer brackets when ( ) is apparently supposed to be used instead.  
> Once I fix that, I get a pile of messages I don't know what to do about:
>
> s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
> s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
> s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
> s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
> s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
> s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
> s-widthu.ads:93:11: run-time library configuration error
> s-widthu.ads:93:11: file s-imgint.ads had parser errors
> s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
> compilation abandoned
> make[2]: *** [ada/contracts.o] Error 1
>
> Given that the current open source Gnat is from 2020, so (apparently) it 
> doesn't support Ada 2020 features, how is someone supposed to build the 
> current GCC?  I looked in the prerequisites listing on the webpage, but it 
> says that the Gnat that is built on GCC 5.1 is sufficient.  That seems to be 
> wrong; the GCC in Gnat 2020 is 8.4.1 and it is apparently too old to work.
>
> paul
>

Re: Can't build Ada

[Andrew Pinski via Gcc]

On Fri, Nov 25, 2022 at 12:08 PM Paul Koning  wrote:
>
>
>
> > On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
> >
> > On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  
> > wrote:
> >>
> >> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
> >> precise) to build Ada, starting with the latest (2020) release of Gnat 
> >> from Adacore.
> >
> > Are you building a cross compiler or a native compiler?
> > If you are building a cross, you need to bootstrap a native compiler first.
>
> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
> aarch64-darwin.

You have to build a x86_64-darwin compiler first with the same sources
as you are building for aarch64-darwin.

>
> But in any case, how does that relate to the error messages I got?  They 
> don't seem to have anything to do with missing compilers, but rather with the 
> use of language features too new for the available (downloadable) Gnat.

>From https://gcc.gnu.org/install/prerequisites.html:
"In order to build a cross compiler, it is strongly recommended to
install the new compiler as native first, and then use it to build the
cross compiler. Other native compiler versions may work but this is
not guaranteed and *will typically fail with hard to understand
compilation errors during the build."

I added the emphasis but yes this is all documented correctly.

Thanks,
Andrew Pinski

>
> paul
>
>

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Andrew Pinski via Gcc]

On Sat, Dec 3, 2022 at 1:05 PM Alejandro Colomar via Gcc
 wrote:
>
> Hi!
>
> I'll probably have to release again before the Debian freeze of Bookworm.
> That's something I didn't want to do, but there's some important bug that
> affects downstream projects (translation pages), and I need to release.  It's 
> a
> bit weird that the bug has been reported now, because it has always been there
> (it's not a regression), but still, I want to address it before the next 
> Debian.
>
> And I don't want to start with stable releases, so I won't be releasing
> man-pages-6.01.1.  That means that all changes that I have in the project 
> that I
> didn't plan to release until 2024 will be released in a few weeks, notably
> including the VLA syntax.
>
> This means that while this syntax is still an invent, not something real that
> can be used, I need to be careful about the future if I plan to make it public
> so soon.
>
> Since we've seen that using a '.' prefix seems to be problematic because of
> lookahead, and recently Michael Matz proposed using a different punctuator (he
> proposed '@') for differentiating parameters from struct members, I think 
> going
> in that direction may be a good idea.
>
> How about '$'?

$ is a GNU extension for identifiers already.
See https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Dollar-Signs.html#Dollar-Signs

Thanks,
Andrew

>
> It's been used for function parameters since... forever? in sh(1).  And it's
> being added to the source character set in C23, so it seems to be a good 
> choice.
>   It should also be intuitive what it means.
>
> What do you think about it?  I'm not asking for your opinion about adding it 
> to
> GCC, but rather for replacing the current '.' in the man-pages before I 
> release
> later this month.  Do you think I should apply that change?
>
> Cheers,
>
> Alex
>
>
> --
> 

Re: RFC: Make builtin types only valid for some target features

[Andrew Pinski via Gcc]

On Sun, Dec 4, 2022 at 11:33 PM Richard Sandiford via Gcc
 wrote:
>
> "Kewen.Lin"  writes:
> > Hi,
> >
> > I'm working to find one solution for PR106736, which requires us to
> > make some built-in types only valid for some target features, and
> > emit error messages for the types when the condition isn't satisfied.
> > A straightforward idea is to guard the registry of built-in type under
> > the corresponding target feature.  But as Peter pointed out in the
> > PR, it doesn't work, as these built-in types are used by some built-in
> > functions which are required to be initialized always regardless of
> > target features, in order to support target pragma/attribute.  For
> > the validity checking on the built-in functions, it happens during
> > expanding the built-in functions calls, since till then we already
> > know the exact information on specific target feature.
> >
> > One idea is to support built-in type checking in a similar way, to
> > check if all used type_decl (built-in type) are valid or not somewhere.
> > I hacked to simply check currently expanding gimple stmt is gassign
> > and further check the types of its operands, it did work but checking
> > gassign isn't enough.  Maybe I missed something, there seems not an
> > efficient way for a full check IMHO.
> >
> > So I tried another direction, which was inspired by the existing
> > attribute altivec, to introduce an artificial type attribute and the
> > corresponding macro definition, during attribute handling it can check
> > target option node about target feature for validity.  The advantage
> > is that the checking happens in FE, so it reports error early, and it
> > doesn't need a later full checking on types.  But with some prototyping
> > work, I found one issue that it doesn't support param decl well, since
> > the handling on attributes of function decl happens after that on
> > attributes of param decl, so we aren't able to get exact target feature
> > information when handling the attributes on param decl.  It requires
> > front-end needs to change the parsing order, I guess it's not acceptable?
> > So I planed to give up and return to the previous direction.
> >
> > Does the former idea sound good?  Any comments/suggestions, and other
> > ideas?
> >
> > Thanks a lot in advance!
>
> FWIW, the aarch64 fp move patterns emit the error directly.  They then
> expand an integer-mode move, to provide some error recovery.  (The
> alternative would be to make the error fatal.)
>
> (define_expand "mov"
>   [(set (match_operand:GPF_TF_F16_MOV 0 "nonimmediate_operand")
> (match_operand:GPF_TF_F16_MOV 1 "general_operand"))]
>   ""
>   {
> if (!TARGET_FLOAT)
>   {
> aarch64_err_no_fpadvsimd (mode);
> machine_mode intmode
>   = int_mode_for_size (GET_MODE_BITSIZE (mode), 0).require ();
> emit_move_insn (gen_lowpart (intmode, operands[0]),
> gen_lowpart (intmode, operands[1]));
> DONE;
>   }
>
> This isn't as user-friendly as catching the error directly in the FE,
> but I think in practice it's going to be very hard to trap all invalid
> uses of a type there.  Also, the user error in these situations is likely
> to be forgetting to enable the right architecture feature, rather than
> accidentally using the wrong type.  So an error about missing architecture
> features is probably good enough in most cases.

I did have a patch which improved the situation for the SVE types to
provide an error message at compile time when SVE is not enabled
but I didn't get any feedback from either the C or C++ front-end folks.
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583786.html

I suspect if that patch gets reviewed by the front-end folks, Kewen
could use the same infrastructure to error out on the types for rs6000
backend.


Thanks,
Andrew Pinski

>
> Thanks,
> Richard

Re: A problem of weak & weakref function attribute

[Andrew Pinski via Gcc]

On Fri, Dec 9, 2022 at 7:17 PM 刘畅 via Gcc  wrote:
>
> Hi all,
>
> I met a problem when I was testing the weak attribute and the weakref
> attribute of GCC. I've read the documentation and in the 6.33.1 Common
> Function Attributes - weakref part I found:
>
> Without a target given as an argument to weakref or to alias,
> weakref is equivalent to weak (in that case the declaration may be
> extern).
>
> To verify this statement, I wrote the following two C programs:
>
> a.c
> #include 
>
> void func(void) __attribute__((weak));
>
> int main() {
> if (func)
> printf("1\n");
> else
> printf("0\n");
>
> return 0;
> }
>
> b.c
> #include 
>
> extern void func(void) __attribute__((weakref));
>
> int main() {
> if (func)
> printf("1\n");
> else
> printf("0\n");
>
> return 0;
> }
>
> The only difference is a.c uses __attribute__((weak)) while b.c uses
> __attribute__((weakref)). According to the statement I referred above,
> I expect the two programs have the smae behavior. However, after I
> compiled the two programs with:
>
> $ gcc a.c -o a.out; gcc b.c -o b.out
>
> I got a warning:
>
> b.c:3:13: warning: ‘weakref’ attribute should be accompanied with an
> ‘alias’ attribute [-Wattributes]
> 3 | extern void func(void) __attribute__((weakref));
>   |
>
> then I found they have different output:
>
> $ ./a.out; ./b.out
> 0
> 1
>
> Then I disassembled the main function of a.out and b.out, and found
> the func symbol didn't even appear in the assemble code of b.c (I
> recompiled the 2 programs with -g option):
>
> assemble code of a.c:
> 5   int main() {
>0x1149 <+0>: f3 0f 1e fa endbr64
>0x114d <+4>: 55  push   %rbp
>0x114e <+5>: 48 89 e5mov%rsp,%rbp
>
> 6   if (func)
>0x1151 <+8>: 48 8b 05 90 2e 00 00mov
> 0x2e90(%rip),%rax# 0x3fe8
>0x1158 <+15>:48 85 c0test   %rax,%rax
>0x115b <+18>:74 0e   je 0x116b 
>
> 7   printf("1\n");
>0x115d <+20>:48 8d 3d a0 0e 00 00lea
> 0xea0(%rip),%rdi# 0x2004
>0x1164 <+27>:e8 e7 fe ff ff  callq  0x1050 
>0x1169 <+32>:eb 0c   jmp0x1177 
>
> 8   else
> 9   printf("0\n");
>0x116b <+34>:48 8d 3d 94 0e 00 00lea
> 0xe94(%rip),%rdi# 0x2006
>0x1172 <+41>:e8 d9 fe ff ff  callq  0x1050 
>
> 10
> 11  return 0;
>0x1177 <+46>:b8 00 00 00 00  mov$0x0,%eax
>
> 12  }
>0x117c <+51>:5d  pop%rbp
>0x117d <+52>:c3  retq
>
> assemble code of b.c:
> 5   int main() {
>0x1149 <+0>: f3 0f 1e fa endbr64
>0x114d <+4>: 55  push   %rbp
>0x114e <+5>: 48 89 e5mov%rsp,%rbp
>
> 6   if (func)
> 7   printf("1\n");
>0x1151 <+8>: 48 8d 3d ac 0e 00 00lea
> 0xeac(%rip),%rdi# 0x2004
>0x1158 <+15>:e8 f3 fe ff ff  callq  0x1050 
>
> 8   else
> 9   printf("0\n");
> 10
> 11  return 0;
>0x115d <+20>:b8 00 00 00 00  mov$0x0,%eax
>
> 12  }
>0x1162 <+25>:5d  pop%rbp
>0x1163 <+26>:c3  retq
>
> In my test, the weak attribute and the weakref attribute without a
> target given as an argument to weakref or to alias have different
> behavior, which is different from the documentation. I don't know if
> it's because I misunderstood the documentation. I would be appreciate
> if anyone can help me :)

No it is a bug, at least the documentation no longer matches the implementation.
I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042 and even
pointed out the (old) revision which changed the behavior to no longer
match the documentation.

Thanks,
Andrew

>
> Best regards,
>
> Chang Liu

Re: Bug with GCC's handling of lifetimes of implicit-lifetime types

[Andrew Pinski via Gcc]

On Sat, Dec 10, 2022 at 10:36 AM Jonathan Wakely via Gcc
 wrote:
>
> On Sat, 10 Dec 2022 at 17:42, Gavin Ray via Gcc  wrote:
> >
> > This came up when I was asking around about what the proper way was to:
> >
> > - Allocate aligned storage for a buffer pool/page cache
> > - Then create pointers to "Page" structs inside of the storage memory area
> >
> > I thought something like this might do:
> >
> > struct buffer_pool
> > {
> >   alignas(PAGE_SIZE) std::byte storage[NUM_PAGES * PAGE_SIZE];
> >   page* pages = new (storage) page[NUM_PAGES];
> > }
> >
> > Someone told me that this was a valid solution but not to do it, because it
> > wouldn't function properly on GCC
> > They gave this as a reproduction:
> >
> > https://godbolt.org/z/EhzM37Gzh
> >
> > I'm not experienced enough with C++ to grok the connection between this
> > repro and my code,
>
> Me neither. I don't think there is any connection, because I don't
> think the repro shows what they think it shows.
>
> > but I figured
> > I'd post it on the mailing list in case it was useful for others/might get
> > fixed in the future =)
> >
> > They said it had to do with "handling of lifetimes of implicit-lifetime
> > types"
>
> I don't think that code is a valid implementation of
> start_lifetime_as. Without a proper implementation of
> start_lifetime_as (which GCC doesn't provide yet), GCC does not allow
> you to read the bytes of a float as an int, and doesn't give you the
> bytes of 1.0f, it gives you 0.
>
> https://godbolt.org/z/dvncY9Pea works for GCC. But this has nothing to
> do your code above, as far as I can see.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115#c10 for what
is going wrong.
Basically GCC does not have a way to express this in the IR currently
and there are proposals there on how to do it.

Thanks,
Andrew Pinski

Re: [BUG] missing warning for pointer arithmetic out of bounds

[Andrew Pinski via Gcc]

On Tue, Dec 13, 2022 at 11:16 AM Alejandro Colomar via Gcc
 wrote:
>
>
>
> On 12/13/22 20:08, Alejandro Colomar wrote:
> > Hi!
> >
> > For the following program:
> >
> >
> >  $ cat buf.c
> >  #include 
> >
> >  int main(void)
> >  {
> >  char *p, buf[5];
> >
> >  p = buf + 6;
> >  printf("%p\n", p);
> >  }
> >
> >
> > There are no warnings in gcc, as I would expect:
>
> I just re-read my text, and it is ambiguous.  I meant that I expect warnings.

GCC only warns during VRP which is only enabled at -O2:

:8:12: warning: array subscript 6 is outside array bounds of
'char[5]' [-Warray-bounds=]
8 |  p = buf + 6;
  |  ~~^
:6:19: note: at offset 6 into object 'buf' of size 5
6 |  char *p, buf[5];
  |   ^~~

Thanks,
Andrew


>
>
> >
> >  $ gcc -Wall -Wextra buf.c -O0
> >
> > Clang does warn, however:
> >
> >  $ clang -Weverything -Wall -Wextra buf.c -O0
> >  buf.c:8:17: warning: format specifies type 'void *' but the argument 
> > has
> > type 'char *' [-Wformat-pedantic]
> >  printf("%p\n", p);
> >  ~~ ^
> >  %s
> >  buf.c:7:6: warning: the pointer incremented by 6 refers past the end 
> > of the
> > array (that contains 5 elements) [-Warray-bounds-pointer-arithmetic]
> >  p = buf + 6;
> >  ^ ~
> >  buf.c:5:2: note: array 'buf' declared here
> >  char *p, buf[5];
> >  ^
> >  2 warnings generated.
> >
> > Cheers,
> >
> > Alex
> >
> >
>
> --
> 

Re: [-Wstringop-overflow=] strncat(3)

[Andrew Pinski via Gcc]

On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha
 wrote:
>
> Hi,
>
> I was rewriting the strncat(3) manual page, and when I tried to compile the
> example program, I got a surprise from the compiler.
>
> Here goes the page:
>
>
>strncat(3)   Library Functions Manual  strncat(3)
>
>NAME
>   strncat  -  concatenate  a  null‐padded  character sequence into a
>   string
>
>LIBRARY
>   Standard C library (libc, -lc)
>
>SYNOPSIS
>   #include 
>
>   char *strncat(char *restrict dst, const char src[restrict .sz],
>  size_t sz);
>
>DESCRIPTION
>   This function catenates the input character sequence contained  in
>   a  null‐padded  fixed‐width  buffer,  into  a string at the buffer
>   pointed to by dst.  The programmer is responsible for allocating a
>   buffer large enough, that is, strlen(dst) + strnlen(src, sz) + 1.
>
>   An implementation of this function might be:
>
>   char *
>   strncat(char *restrict dst, const char *restrict src, size_t sz)
>   {
>   int   len;
>   char  *end;
>
>   len = strnlen(src, sz);
>   end = dst + strlen(dst);
>   end = mempcpy(end, src, len);
>   *end = '\0';
>
>   return dst;
>   }
>
>RETURN VALUE
>   strncat() returns dest.
>
>ATTRIBUTES
>   [...]
>
>STANDARDS
>   POSIX.1‐2001, POSIX.1‐2008, C89, C99, SVr4, 4.3BSD.
>
>CAVEATS
>   The  name of this function is confusing.  This function has no re‐
>   lation with strncpy(3).
>
>   If the destination buffer is not large enough, the behavior is un‐
>   defined.  See _FORTIFY_SOURCE in feature_test_macros(7).
>
>BUGS
>   This function  can  be  very  inefficient.   Read  about  Shlemiel
>   the   painter  ⟨https://www.joelonsoftware.com/2001/12/11/
>   back-to-basics/⟩.
>
>EXAMPLES
>   #include 
>   #include 
>   #include 
>
>   int
>   main(void)
>   {
>   charbuf[BUFSIZ];
>   size_t  len;
>
>   buf[0] = '\0';  // There’s no ’cpy’ function to this ’cat’.
>   strncat(buf, "Hello ", 6);
>   strncat(buf, "world", 42);  // Padding null bytes ignored.
>   strncat(buf, "!", 1);
>   len = strlen(buf);
>   printf("[len = %zu]: <%s>\n", len, buf);
>
>   exit(EXIT_SUCCESS);
>   }
>
>SEE ALSO
>   string(3), string_copy(3)
>
>Linux man‐pages (unreleased)  (date)   strncat(3)
>
>
> And when you compile that, you get:
>
> $ cc -Wall -Wextra ./strncat.c
> ./strncat.c: In function ‘main’:
> ./strncat.c:12:12: warning: ‘strncat’ specified bound 6 equals source length
> [-Wstringop-overflow=]
> 12 |strncat(buf, "Hello ", 6);
>|^
> ./strncat.c:14:12: warning: ‘strncat’ specified bound 1 equals source length
> [-Wstringop-overflow=]
> 14 |strncat(buf, "!", 1);
>|^~~~
>
>
> So, what?  Where's the problem?  This function does exactly that: "take an
> unterminated character sequence and catenate it to an existing string".  Clang
> seems to be fine with the code.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83404 and the
background of why the warning was added here:

https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat.

Thanks,
Andrew Pinski

>
> Cheers,
>
> Alex
>
>
> --
> 

Re: Document how to build PGO-optimized GCC version

[Andrew Pinski via Gcc]

On Tue, Dec 27, 2022 at 9:38 PM Alexander Zaitsev  wrote:
>
> Hello.
>
> We are using GCC for our C++ projects. Our projects are huge, commit
> rate is quite huge, so our CI workers are always busy (so as any other
> CI workers, honestly). Since we want to increase build speed, one of the
> option is to optimize the compiler itself. Sounds like a good case for PGO.
>
> Clang has the infrastructure for building the Clang itself with PGO:
> https://llvm.org/docs/HowToBuildWithPGO.html . I have tried to find
> something like that for GCC but with no success.
>
> My proposal is:
>
>   * add support for building PGO-optimized GCC into the GCC build
> infrastructure
>   * add documentation to the GCC site, how to build GCC with PGO
> optimizations

It is already there, see the last section of
https://gcc.gnu.org/install/build.html (Building with profile
feedback).  It has been included in GCC and documented since June
2003.
https://gcc.gnu.org/r0-50361-g8f231b5d874dcb .

>   * (if GCC community provides prebuilt gcc binaries) use PGO for the
> prebuilt binaries. E.g. Clang and rustc already uses this approach.

GCC community does not provide prebuilt gcc binaries for a few
different reasons.
But distros do provide more recent prebuilt binaries, you could ask
them to build using PGO (some do already I think).

Thanks,
Andrew Pinski

>
> Any feedback is appreciated.
>
> Thanks in advance!
>
> --
> Best regards,
> Alexander Zaitsev

Re: B^HDEAD code generation (AMD64)

[Andrew Pinski via Gcc]

On Mon, Jan 9, 2023 at 4:42 PM Stefan Kanthak  wrote:
>
> "Thomas Koenig"  wrote:
>
> > On 09.01.23 12:35, Stefan Kanthak wrote:
> >> 20 superfluous instructions of the total 102 instructions!
> >
> > The proper place for bug reports is https://gcc.gnu.org/bugzilla/ .
>
> OUCH: there's NO proper place for bugs at all!

HUH? soon people will ignore emails that are demeaning/ableist like
what you have been recently (saying things like braindead, etc.). And
yes bugzilla is where GCC tracks bug reports.

>
> > Feel free to submit these cases there.
>
> I feel free to do whatever I like to do where I do it, for example:
>
> --- bug.cpp ---
> int main() {
> __uint128_t long long bug = 0;
> }
> --- EOF ---

With -pedantic-errors we get:

: In function 'int main()':
:2:22: error: 'long long' specified with '__int128 unsigned'
[-Wpedantic]
2 | __uint128_t long long bug = 0;
  |  ^~~~

And also run into https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099 .

This is a known extension but maybe it is not documented ...
Anyways read that bug report.


>
> See 
>
> regards
> Stefan

Re: [PATCH v5 0/5] P1689R5 support

[Andrew Pinski via Gcc]

On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
 wrote:
>
> Hi,
>
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> not embarrassingly parallel and need to be ordered to ensure that
> `import some_module;` can be satisfied in time by making sure that any
> TU with `export import some_module;` is compiled first.


I like how folks are complaining that GCC outputs POSIX makefile
syntax from GCC's dependency files which are supposed to be in POSIX
Makefile syntax.
It seems like rather the build tools are people like to use are not
understanding POSIX makefile syntax any more rather.
Also I am not a fan of json, it is too verbose for no use. Maybe it is
time to go back to standardizing a new POSIX makefile syntax rather
than changing C++ here.

Thanks,
Andrew Pinski

>
> [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
>
> I've also added patches to include imported module CMI files and the
> module mapper file as dependencies of the compilation. I briefly looked
> into adding dependencies on response files as well, but that appeared to
> need some code contortions to have a `class mkdeps` available before
> parsing the command line or to keep the information around until one was
> made.
>
> I'd like feedback on the approach taken here with respect to the
> user-visible flags. I'll also note that header units are not supported
> at this time because the current `-E` behavior with respect to `import
> ;` is to search for an appropriate `.gcm` file which is not
> something such a "scan" can support. A new mode will likely need to be
> created (e.g., replacing `-E` with `-fc++-module-scanning` or something)
> where headers are looked up "normally" and processed only as much as
> scanning requires.
>
> FWIW, Clang as taken an alternate approach with its `clang-scan-deps`
> tool rather than using the compiler directly.
>
> Thanks,
>
> --Ben
>
> ---
> v4 -> v5:
>
> - add dependency tracking for imported modules to `-MF`
> - add dependency tracking for static module mapper files given to
>   `-fmodule-mapper=`
>
> v3 -> v4:
>
> - add missing spaces between function names and arguments
>
> v2 -> v3:
>
> - changelog entries moved to commit messages
> - documentation updated/added in the UTF-8 routine editing
>
> v1 -> v2:
>
> - removal of the `deps_write(extra)` parameter to option-checking where
>   ndeeded
> - default parameter of `cpp_finish(fdeps_stream = NULL)`
> - unification of libcpp UTF-8 validity functions from v1
> - test cases for flag parsing states (depflags-*) and p1689 output
>   (p1689-*)
>
> Ben Boeckel (5):
>   libcpp: reject codepoints above 0x10
>   libcpp: add a function to determine UTF-8 validity of a C string
>   p1689r5: initial support
>   c++modules: report imported CMI files as dependencies
>   c++modules: report module mapper files as a dependency
>
>  gcc/c-family/c-opts.cc|  40 +++-
>  gcc/c-family/c.opt|  12 +
>  gcc/cp/mapper-client.cc   |   4 +
>  gcc/cp/mapper-client.h|   1 +
>  gcc/cp/module.cc  |  23 +-
>  gcc/doc/invoke.texi   |  15 ++
>  gcc/testsuite/g++.dg/modules/depflags-f-MD.C  |   2 +
>  gcc/testsuite/g++.dg/modules/depflags-f.C |   1 +
>  gcc/testsuite/g++.dg/modules/depflags-fi.C|   3 +
>  gcc/testsuite/g++.dg/modules/depflags-fj-MD.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-fj.C|   4 +
>  .../g++.dg/modules/depflags-fjo-MD.C  |   4 +
>  gcc/testsuite/g++.dg/modules/depflags-fjo.C   |   5 +
>  gcc/testsuite/g++.dg/modules/depflags-fo-MD.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-fo.C|   4 +
>  gcc/testsuite/g++.dg/modules/depflags-j-MD.C  |   2 +
>  gcc/testsuite/g++.dg/modules/depflags-j.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-jo-MD.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-jo.C|   4 +
>  gcc/testsuite/g++.dg/modules/depflags-o-MD.C  |   2 +
>  gcc/testsuite/g++.dg/modules/depflags-o.C |   3 +
>  gcc/testsuite/g++.dg/modules/modules.exp  |   1 +
>  gcc/testsuite/g++.dg/modules/p1689-1.C|  18 ++
>  gcc/testsuite/g++.dg/modules/p1689-1.exp.json |  27 +++
>  gcc/testsuite/g++.dg/modules/p1689-2.C|  16 ++
>  gcc/testsuite/g++.dg/modules/p1689-2.exp.json |  16 ++
>  gcc/testsuite/g++.dg/modules/p1689-3.C|  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-3.exp.json |  16 ++
>  gcc/testsuite/g++.dg/modules/p1689-4.C|  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-4.exp.json |  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-5.C|  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-5.exp.json |  14 ++
>  gcc/testsuite/g++.dg/modules/test-p1689.py| 222 ++
>  gcc/testsuite/lib/modules.exp |  71 ++
>  libcpp/charset.c

get_range_query vs NULL argument

[Andrew Pinski via Gcc]

Hi,
  While fixing PR 108354, I came across that
ssa_name_has_boolean_range calls get_range_query with cfun as the
argument but sometimes while in IPA passes cfun is currently nullptr.
The question should we check the argument before calling
get_range_query or is it a valid thing to call it with a nullptr (and
have it return global_ranges in that case)?

I committed the patch (for PR 108354) with the workaround around the
issue via having the match.pd pattern which was calling
ssa_name_has_boolean_range only be invoked from the gimple
simplifiers.

Below is the patch which undones the workaround:
```
diff --git a/gcc/match.pd b/gcc/match.pd
index e7b700349a6..e352bd422f5 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1732,7 +1732,6 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (!FIXED_POINT_TYPE_P (type))
  (plus @0 (negate @1

-#if GIMPLE
 /* 1 - a is a ^ 1 if a had a bool range. */
 /* This is only enabled for gimple as sometimes
cfun is not set for the function which contains
@@ -1743,7 +1742,6 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (if (INTEGRAL_TYPE_P (type)
&& ssa_name_has_boolean_range (@1))
(bit_xor @1 @0)))
-#endif

 /* Other simplifications of negation (c.f. fold_negate_expr_1).  */
 (simplify
```
Note I can only so far reproduce the call to
ssa_name_has_boolean_range that causes an issue while building Ada
tools (while bootstrapping) because the code that needs to hit this is
related to variable sized type accesses.

Thanks,
Andrew Pinski

Re: get_range_query vs NULL argument

[Andrew Pinski via Gcc]

On Wed, Feb 15, 2023 at 2:30 PM Andrew MacLeod  wrote:
>
>
> On 2/15/23 14:50, Andrew Pinski wrote:
> > Hi,
> >While fixing PR 108354, I came across that
> > ssa_name_has_boolean_range calls get_range_query with cfun as the
> > argument but sometimes while in IPA passes cfun is currently nullptr.
> > The question should we check the argument before calling
> > get_range_query or is it a valid thing to call it with a nullptr (and
> > have it return global_ranges in that case)?
>
> That might be ok...  personally I see nothing wrong with:
>
> diff --git a/gcc/value-query.h b/gcc/value-query.h
> index 63878968118..2d7bf8fcf33 100644
> --- a/gcc/value-query.h
> +++ b/gcc/value-query.h
> @@ -140,7 +140,7 @@ get_global_range_query ()
>   ATTRIBUTE_RETURNS_NONNULL inline range_query *
>   get_range_query (const struct function *fun)
>   {
> -  return fun->x_range_query ? fun->x_range_query : &global_ranges;
> +  return (fun && fun->x_range_query) ? fun->x_range_query : &global_ranges;
>   }
>
>   // Query the global range of NAME in function F.  Default to cfun.
>
>
> The client is probably going to do that anyway.

Ok. I will submit a patch which does the above; I had that patch
already when I wrote the email and wanted to double check before
submitting it.

Thanks,
Andrew Pinski

>
> Aldy?
>
>

Re: PROBLEM !!! __ OS: ANY LINUX __ COMPILERS: gcc & g++ __ OUTPUT: BAD!!!

[Andrew Pinski via Gcc]

On Thu, Mar 16, 2023 at 10:46 AM oszibarack korte via Gcc
 wrote:
>
> *An unsolved problem for more than a decade!*
> *Dear GNU Compiler Collection development team!*
>
> *There is a problem with the gcc and g++ compilers for Linux operating
> systems!*
> *Here are 3 pieces of C and 3 pieces of C++ source code.*

There is no bug here. stdout is line buffered.

Thanks,
Andrew

>
>
>
>
>
> *- Please compile them on any LINUX!- Run it!- Compare the output with the
> corresponding source code!Summary:   THE OUTPUTS ARE BAD !!!*
>
> *>>> C*
>
> *1.*
>
> // c0.c
> // ENVIRONMENT: LINUX COMPILER: gcc OUTPUT: BAD !!!
>
> #include 
>
> void main (void)
> {
>printf ("GNU Compiler Collection");
>
>while (1)
>{
>;
>}
> }
>
>
> *2.*
>
> // c1.c
> // ENVIRONMENT: LINUX COMPILER: gcc OUTPUT: BAD !!!
>
> #include 
> #include 
>
> void main (void)
> {
>printf ("Hello!");
>
>system ("sleep 10");
>
>system ("clear");
>
>printf ("Goodbye!");
> }
>
>
> *3.*
>
> // c2.c
> // ENVIRONMENT: LINUX COMPILER: gcc OUTPUT: BAD !!!
>
> #include 
> #include 
>
> void main (void)
> {
>unsigned int   i;
>
>printf ("Now count up to 4.000.000.000. ST\nART! Wait...");
>
>for (i = 0; i < 40; i++)
>{
>   ;
>}
>
>printf ("READY!");
>
>system ("gcc --version");
>
>printf ("i = %u", i);
>
>system ("uname -a");
> }
>
>
> *>>> C++*
>
> *1.*
>
> // cpp0.cpp
> // ENVIRONMENT: LINUX COMPILER: g++ OUTPUT: BAD !!!
>
> #include 
>
> int main (void)
> {
>std::cout << "GNU Compiler Collection";
>
>while (1)
>{
>   ;
>}
>
>return 0;
> }
>
>
> *2.*
>
> // cpp1.cpp
> // ENVIRONMENT: LINUX COMPILER: g++ OUTPUT: BAD !!!
>
> #include 
>
> int main (void)
> {
>std::cout << "Hello!";
>
>system ("sleep 10");
>
>system ("clear");
>
>std::cout << "Goodbye!";
>
>return 0;
> }
>
>
> *3.*
>
> // cpp2.cpp
> // ENVIRONMENT: LINUX COMPILER: g++ OUTPUT: BAD !!!
>
> #include 
>
> int main (void)
> {
>unsigned int   i;
>
>std::cout << "Now count up to 4.000.000.000. ST\nART! Wait...";
>
>for (i = 0; i < 40; i++)
>{
>   ;
>}
>
>std::cout << "READY!";
>
>system ("g++ --version");
>
>std::cout << "i = " << i;
>
>system ("uname -a");
>
>return 0;
> }
>
>
>
> *Thank you,Best regards,*
> korte.oszibarack
> *March 16th, 2023*

Re: GCC ASAN breaks glob()?

[Andrew Pinski via Gcc]

On Sun, Mar 26, 2023 at 12:01 PM Paul Smith  wrote:
>
> OK here's something super-strange I discovered:
>
> Enabling -faddress=sanitize in GCC, causes the glob(3) function to
> misbehave.
>
> I'm using GCC 11.3 / glibc 2.35 (x86_64 native).  I have this simple
> program:

Maybe https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88054 .

Thanks,
Andrew

>
> $ cat /tmp/tstglob.c
> #include 
> #include 
>
> int main(int argc, char *argv[])
> {
> glob_t gl = {0};
> int res = glob(argv[1], 0, NULL, &gl);
>
> switch (res)
> {
> case 0: printf("success\n"); break;
> case GLOB_NOMATCH: printf("no match\n"); break;
> default: printf("unknown: %d\n", res); break;
> }
>
> return 0;
> }
>
> Now I create a symlink that doesn't point to anything:
>
>   $ ln -s nosuchfile /tmp/badlink
>   $ ls -al /tmp/badlink
>   lrwxrwxrwx 1 pds pds 10 Mar 26 14:52 /tmp/badlink -> nosuchfile
>
> Now I compile the above program normally and run it:
>
>   $ gcc -o /tmp/tstglob /tmp/tstglob.c
>   $ /tmp/tstglob /tmp/badlink
>   success
>
> This is what I expect: the symlink does exist even though it doesn't
> point to anything so glob() should return it.
>
> But now if I compile with ASAN:
>
>   $ gcc -fsanitize=address -o /tmp/tstglob /tmp/tstglob.c
>   $ /tmp/tstglob /tmp/badlink
>   no match
>
> ...?!?!?!
>
> Is there something in the ASAN library that takes over glob(3) and
> installs a different version (there have been plenty of versions of
> glob(3) over the years in glibc which behave incorrectly when faced
> with broken symlinks, heavens knows...) that overrides the glibc
> version?
>
> Or...??

MIN/MAX and trapping math and NANs

[Andrew Pinski via Gcc]

Hi,
  I noticed while working on phi-opt, that MIN/MAX EXPR (and the
corresponding RTL codes) both can return true for trapping even if
NANs are not honored (that is -ffinite-math-only). Is this true? I
would have assumed when -ffinite-math-only -fno-signed-zeros is used,
then MIN/MAX would be the same as a > b ? a : b which would not cause
a trap.

If we think they should not trap, then I will create a patch and test
it for GCC 14.

Thanks,
Andrew Pinski

Re: gcc with the new WIN32 threads fails to compile libstdc++

[Andrew Pinski via Gcc]

On Mon, Apr 10, 2023 at 12:16 AM Julian Waters via Gcc  wrote:
>
> Hi all,
>
> When trying to compile gcc with the revamped WIN32 threading model which
> supports C++11 threads, libstdc++ always fails to link with the following
> error:

those functions should have been included in newly built libgcc.
Since you didn't show the link line it is hard to tell what is going wrong.

Thanks,
Andrew Pinski

>
> C:\msys64\ucrt64\x86_64-w64-mingw32\bin\ld.exe:
> ../src/c++11/.libs/libc++11convenience.a(thread.o):
> in function `__gthread_join':
> D:/Eclipse/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/x86_64-w64-mingw32/libstdc++-v3/include/x86
> _64-w64-mingw32/bits/gthr-default.h:451: undefined reference to
> `__gthr_win32_join'
> C:\msys64\ucrt64\x86_64-w64-mingw32\bin\ld.exe:
> ../src/c++11/.libs/libc++11convenience.a(thread.o):
> in function `__gthread_create':
> D:/Eclipse/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/x86_64-w64-mingw32/libstdc++-v3/include/x86
> _64-w64-mingw32/bits/gthr-default.h:445: undefined reference to
> `__gthr_win32_create'
> C:\msys64\ucrt64\x86_64-w64-mingw32\bin\ld.exe:
> D:/Eclipse/MINGW-packages/mingw-w64-gcc/src/build-UC
> RT64/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32/bits/gthr-default.h:445:
> undefined r
> eference to `__gthr_win32_create'
>
> I'm assuming the problem also extends to the other __gthr_win32 routines as
> well, __gthr_win32_create just happens to be the first symbol it cannot
> find.
>
> Is there a way to fix this issue?
>
> best regards,
> Julian

Re: Hosting our gfortran MatterMost workspace

[Andrew Pinski via Gcc]

On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran  wrote:
>
> Hello all and gcc overseers,
>
> I received a notice that the MasterMost server providers decided to drop
> their free service. Unfortunate and understandable.
>
> I plan to contact the Open Software Lab folks at Oregon State University
> to see if they can host for us.
>
> If anyone else has any suggestions of possible places we can host an
> instance, please let me know.  The software for the platform is open
> source many folks self host, so we can do this.
>
> I am not sure where gcc.gnu.org is hosted, but that might be a logical
> place.

Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 .
gcc.gnu.org is currently hosted as part of sourceware so ...

Thanks,
Andrew

>
> Best regards,
>
> Jerry

Re: libsanitizer: sync from master

[Andrew Pinski via Gcc]

On Tue, Nov 15, 2022 at 7:47 AM Martin Liška  wrote:
>
> Hi.
>
> I've just pushed libsanitizer update that was tested on x86_64-linux and 
> ppc64le-linux systems.
> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
> abidiff.

This broke hwasan on aarch64. See https://gcc.gnu.org/PR109674 .

Thanks,
Andrew

>
> Pushed as r13-4068-g3037f11fb86eda.
>
> Cheers,
> Martin

Re: Will GCC eventually support SSE2 or SSE4.1?

[Andrew Pinski via Gcc]

On Thu, May 25, 2023 at 11:56 PM Stefan Kanthak  wrote:
>
> Hi,
>
> compile the following function on a system with Core2 processor
> (released January 2008) for the 32-bit execution environment:
>
> --- demo.c ---
> int ispowerof2(unsigned long long argument)
> {
> return (argument & argument - 1) == 0;
> }
> --- EOF ---
>
> GCC 13.3: gcc -m32 -O3 demo.c
>
> NOTE: -mtune=native is the default!

You need to use -march=native and not -mtune=native  to turn on
the architecture features.

Thanks,
Andrew

>
> # https://godbolt.org/z/b43cjGdY9
> ispowerof2(unsigned long long):
> movqxmm1, [esp+4]
> pcmpeqd xmm0, xmm0
> paddq   xmm0, xmm1
> pandxmm0, xmm1
> movdedx, xmm0  #pxorxmm1, xmm1
> psrlq   xmm0, 32   #pcmpeqb xmm0, xmm1
> movdeax, xmm0  #pmovmskb eax, xmm0
> or  edx, eax   #cmp al, 255
> seteal #seteal
> movzx   eax, al#
> ret
>
> 11 instructions in 40 bytes# 10 instructions in 36 bytes
>
> OOPS: why does GCC (ab)use the SSE2 alias "Willamette New Instruction Set"
>   here instead of the native SSE4.1 alias "Penryn New Instruction Set"
>   of the Core2 (and all later processors)?
>
> OUCH: why does it FAIL to REALLY use SSE2, as shown in the comments on the
>   right side?
>
>
> Now add the -mtune=core2 option to EXPLICITLY enable the NATIVE SSE4.1
> alias "Penryn New Instruction Set" of the Core2 processor:
>
> GCC 13.3: gcc -m32 -mtune=core2 -O3 demo.c
>
> # https://godbolt.org/z/svhEoYT11
> ispowerof2(unsigned long long):
>#xor  eax, eax
> movqxmm1, [esp+4]  #movq xmm1, [esp+4]
> pcmpeqd xmm0, xmm0 #pcmpeqq  xmm0, xmm0
> paddq   xmm0, xmm1 #paddqxmm0, xmm1
> pandxmm0, xmm1 #ptestxmm0, xmm1
> movdedx, xmm0  #
> psrlq   xmm0, 32   #
> movdeax, xmm0  #
> or  edx, eax   #
> seteal #sete al
> movzx   eax, al#
> ret#ret
>
> 11 instructions in 40 bytes# 7 instructions in 26 bytes
>
> OUCH: GCC FAILS to use SSE4.1 as shown in the comments on the right side.
>   ~~~
>
> Last compile with -mtune=i386 for the i386 processor:
>
> GCC 13.3: gcc -m32 -mtune=i386 -O3 demo.c
>
> # https://godbolt.org/z/e76W6dsMj
> ispowerof2(unsigned long long):
> pushebx#
> mov ecx, [esp+8]   #moveax, [esp+4]
> mov ebx, [esp+12]  #movedx, [esp+8]
> mov eax, ecx   #
> mov edx, ebx   #
> add eax, -1#addeax, -1
> adc edx, -1#adcedx, -1
> and eax, ecx   #andeax, [esp+4]
> and edx, ebx   #andedx, [esp+8]
> or  eax, edx   #or eax, edx
> seteal #negeax
> movzx   eax, al#sbbeax, eax
> pop ebx#inceax
> ret#ret
>
> 14 instructions in 33 bytes# 11 instructions in 32 bytes
>
> OUCH: why does GCC abuse EBX (and ECX too) and performs a superfluous
>   memory write?
>
>
> Stefan Kanthak

Re: Another epic optimiser failure

[Andrew Pinski via Gcc]

On Sat, May 27, 2023 at 2:38 PM Stefan Kanthak  wrote:
>
> "Jakub Jelinek"  wrote, completely clueless:
>
> > On Sat, May 27, 2023 at 11:04:11PM +0200, Stefan Kanthak wrote:
> >> OUCH: popcnt writes the WHOLE result register, there is ABSOLUTELY
> >>   no need to clear it beforehand nor to clear the higher 24 bits
> >>   afterwards!
> >
> > Except that there is.  See https://gcc.gnu.org/PR62011 for details.
>
> GUESS WHY I EXPLICITLY WROTE
>
> | JFTR: before GCC zealots write nonsense: see -march= or -mtune=
>
> NOT AMUSED ABOUT YOUR CRYING INCOMPETENCE!

So you want to complain about GCC knowing about an Intel performance errata
If you read that bug report, you would have learned why the zeroing is
done. I am sorry you hate GCC for actually following advice from the
processor maker after all.

> Stefan

Re: Who cares about performance (or Intel's CPU errata)?

[Andrew Pinski via Gcc]

On Sat, May 27, 2023 at 2:25 PM Stefan Kanthak  wrote:
>
> Just to show how SLOPPY, INCONSEQUENTIAL and INCOMPETENT GCC's developers are:
>
> --- dontcare.c ---
> int ispowerof2(unsigned __int128 argument) {
> return __builtin_popcountll(argument) + __builtin_popcountll(argument >> 
> 64) == 1;
> }
> --- EOF ---
>
> GCC 13.3gcc -march=haswell -O3
>
> https://gcc.godbolt.org/z/PPzYsPzMc
> ispowerof2(unsigned __int128):
> popcnt  rdi, rdi
> popcnt  rsi, rsi
> add esi, edi
> xor eax, eax
> cmp esi, 1
> seteal
> ret
>
> OOPS: what about Intel's CPU errata regarding the false dependency on POPCNTs 
> output?

Because the popcount is going to the same register, there is no false
dependency 
The false dependency errata only applies if the result of the popcnt
is going to a different register, the processor thinks it depends on
the result in that register from a previous instruction but it does
not (which is why it is called a false dependency). In this case it
actually does depend on the previous result since the input is the
same as the input.

Thanks,
Andrew

>
> See https://gcc.godbolt.org/z/jdjTc3EET for comparison!
>
> FIX YOUR BUGS, KIDS!
>
> Stefan

Re: Who cares about performance (or Intel's CPU errata)?

[Andrew Pinski via Gcc]

On Sat, May 27, 2023 at 3:54 PM Stefan Kanthak  wrote:
>
> "Andrew Pinski"  wrote:
>
> > On Sat, May 27, 2023 at 2:25 PM Stefan Kanthak  
> > wrote:
> >>
> >> Just to show how SLOPPY, INCONSEQUENTIAL and INCOMPETENT GCC's developers 
> >> are:
> >>
> >> --- dontcare.c ---
> >> int ispowerof2(unsigned __int128 argument) {
> >> return __builtin_popcountll(argument) + __builtin_popcountll(argument 
> >> >> 64) == 1;
> >> }
> >> --- EOF ---
> >>
> >> GCC 13.3gcc -march=haswell -O3
> >>
> >> https://gcc.godbolt.org/z/PPzYsPzMc
> >> ispowerof2(unsigned __int128):
> >> popcnt  rdi, rdi
> >> popcnt  rsi, rsi
> >> add esi, edi
> >> xor eax, eax
> >> cmp esi, 1
> >> seteal
> >> ret
> >>
> >> OOPS: what about Intel's CPU errata regarding the false dependency on 
> >> POPCNTs output?
> >
> > Because the popcount is going to the same register, there is no false
> > dependency 
> > The false dependency errata only applies if the result of the popcnt
> > is going to a different register, the processor thinks it depends on
> > the result in that register from a previous instruction but it does
> > not (which is why it is called a false dependency). In this case it
> > actually does depend on the previous result since the input is the
> > same as the input.
>
> OUCH, my fault; sorry for the confusion and the wrong accusation.
>
> Nevertheless GCC fails to optimise code properly:
>
> --- .c ---
> int ispowerof2(unsigned long long argument) {
> return __builtin_popcountll(argument) == 1;
> }
> --- EOF ---
>
> GCC 13.3gcc -m32 -mpopcnt -O3
>
> https://godbolt.org/z/fT7a7jP4e
> ispowerof2(unsigned long long):
> xor eax, eax
> xor edx, edx
> popcnt  eax, [esp+4]
> popcnt  edx, [esp+8]
> add eax, edx # eax is less than 64!
> cmp eax, 1->dec eax  # 2 bytes shorter

dec eax is done for -Os already. -O2 means performance, it does not
mean decrease size. dec can be slower as it can create a false
dependency and it requires eax register to be not alive at the end of
the statement. and IIRC for x86 decode, it could cause 2 (not 1)
micro-ops.

> seteal
> movzx   eax, al  # superfluous

No it is not superfluous, well ok it is because of the context of eax
(besides the lower 8 bits) are already zero'd but keeping that track
is a hard problem and is turning problem really. And I suspect it
would cause another false dependency later on too.

For -Os -march=skylake (and -Oz instead of -Os) we get:
popcnt  rdi, rdi
popcnt  rsi, rsi
add esi, edi
xor eax, eax
dec esi
seteal

Which is exactly what you want right?

Thanks,
Andrew

> ret
>
> 5 bytes and 1 instruction saved; 5 bytes here and there accumulate to
> kilo- or even megabytes, and they can extend code to cross a cache line
> or a 16-byte alignment boundary.
>
> JFTR: same for "__builtin_popcount(argument) == 1;" and 32-bit argument
>
> JFTR: GCC is notorious for generating superfluous MOVZX instructions
>   where its optimiser SHOULD be able see that the value is already
>   less than 256!
>
> Stefan