gcc-8-20180713 is now available

[gccadmin]

Snapshot gcc-8-20180713 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180713/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 262654

You'll find:

 gcc-8-20180713.tar.xzComplete GCC

  SHA256=f6ea235302162e3aa6095c76eefbdcc2a85a83ae92fe301451907116d886c801
  SHA1=981c4d2945545bdbcd86cac935effb17133becd6

Diffs from 8-20180706 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: ICE building a libsupc++ file, pdp11 target

[Paul Koning]

> On Jul 13, 2018, at 2:52 PM, U.Mutlu  wrote:
> 
> Paul Koning wrote on 07/13/2018 08:27 PM:
>> I'm trying to see if I can build the pdp11 target for languages other than 
>> just C, and the answer is for the most part yes.  But I' running into an ICE 
>> I can't figure out.  It's way before the back end comes into the picture as 
>> far as I can see, and there's nothing particularly strange looking in the 
>> input file that suggests anything.
>> 
>> Any suggestions on where to look?  The failure is:
>> 
>> libtool: compile:  /Users/pkoning/Documents/svn/buildpdp+/./gcc/xgcc 
>> -shared-libgcc -B/Users/pkoning/Documents/svn/buildpdp+/./gcc -nostdinc++ 
>> -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src 
>> -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src/.libs 
>> -L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/libsupc++/.libs
>>  -B/usr/local/pdp11-aout/pdp11-aout/bin/ 
>> -B/usr/local/pdp11-aout/pdp11-aout/lib/ -isystem 
>> /usr/local/pdp11-aout/pdp11-aout/include -isystem 
>> /usr/local/pdp11-aout/pdp11-aout/sys-include 
>> -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/../libgcc 
>> -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include/pdp11-aout
>>  -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include 
>> -I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/libsupc++ 
>> -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
>> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 
>> -std=gnu++1z -c ../../../../gcc/lib
> stdc++-v3/libsupc++/new_opa.cc -o new_opa.o
>> cc1plus: warning: -Wabi won't warn about anything [-Wabi]
>> cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
>> which is also used by default
>> cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
>> ../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc:112:1: internal compiler 
>> error: in import_export_decl, at cp/decl2.c:2877
>>  }
>>  ^
>> libbacktrace could not find executable to open
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> make[3]: *** [new_opa.lo] Error 1
> 
> 
> It's failing at the last gcc_assert() below (file 
> ../gcc_src/gcc/cp/decl2.c:2877 ):

Sorry, I should have been more explicit.  I saw that, but my question is: what 
is the underlying problem that triggers the assert?  The comment is not much 
help to me.  And more specifically: what could a target be doing wrong that 
would make an early stage of the compiler fail like this on what seems like a 
pretty straightforward source file?

Many of the other libstdc++ bits compile just fine, as do plenty of testsuite 
cases and some test files of my own.

paul

ICE building a libsupc++ file, pdp11 target

[Paul Koning]

I'm trying to see if I can build the pdp11 target for languages other than just 
C, and the answer is for the most part yes.  But I' running into an ICE I can't 
figure out.  It's way before the back end comes into the picture as far as I 
can see, and there's nothing particularly strange looking in the input file 
that suggests anything.

Any suggestions on where to look?  The failure is:

libtool: compile:  /Users/pkoning/Documents/svn/buildpdp+/./gcc/xgcc 
-shared-libgcc -B/Users/pkoning/Documents/svn/buildpdp+/./gcc -nostdinc++ 
-L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src 
-L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/src/.libs 
-L/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/libsupc++/.libs
 -B/usr/local/pdp11-aout/pdp11-aout/bin/ 
-B/usr/local/pdp11-aout/pdp11-aout/lib/ -isystem 
/usr/local/pdp11-aout/pdp11-aout/include -isystem 
/usr/local/pdp11-aout/pdp11-aout/sys-include 
-I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/../libgcc 
-I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include/pdp11-aout
 -I/Users/pkoning/Documents/svn/buildpdp+/pdp11-aout/libstdc++-v3/include 
-I/Users/pkoning/Documents/svn/gcc/libstdc++-v3/libsupc++ 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
-fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z 
-c ../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc -o new_opa.o
cc1plus: warning: -Wabi won't warn about anything [-Wabi]
cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
which is also used by default
cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
../../../../gcc/libstdc++-v3/libsupc++/new_opa.cc:112:1: internal compiler 
error: in import_export_decl, at cp/decl2.c:2877
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [new_opa.lo] Error 1

paul

Re: How does a target make Fortran work?

[Paul Koning]

> On Jul 13, 2018, at 9:36 AM, Janus Weil  wrote:
> 
> Hi Paul,
> 
> Fortran problems are best discussed on fort...@gcc.gnu.org 
>  (in CC) ...
> 
> 2018-07-12 21:22 GMT+02:00 Paul Koning  >:
>> I tried to rebuild for target pdp11 with fortran enabled (in the past I've 
>> just enabled C).  It builds fine but the resulting compiler crashes at 
>> startup:
>> 
>> Paul-Konings-MacBook-Pro:gcc pkoning$ ./xgcc -B. -O2 -S ../../hello.f
>> f951: internal compiler error: gfc_validate_kind(): Got bad kind
>> libbacktrace could not find executable to open
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> 
>> "hello.f" is the typical "hello world" program.  Some debugging got me to 
>> here:
>> 
>> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
>>frame #0: 0x0001001c1c93 f951`gfc_init_kinds() [inlined] 
>> gfc_validate_kind(type=BT_REAL, kind=, may_fail=false) at 
>> trans-types.c:814 [opt]
>>   811  }
>>   812
>>   813if (rc < 0 && !may_fail)
>> -> 814  gfc_internal_error ("gfc_validate_kind(): Got bad kind");
>>   815
>>   816return rc;
>>   817  }
>> Target 0: (f951) stopped.
>> 
>> So it's unhappy about some "kind", for BT_REAL.  I'm not sure what that 
>> means.  Is it mapping the available data types to Fortran "KIND" values?  If 
>> so, is there something the target has to do for this to work?  Note that 
>> this isn't an IEEE target, so if the initialization is expecting IEEE float 
>> then that may account for it.  But I have no idea what to do here, and the 
>> manual offers no clue.
> 
> A "kind" in Fortran is the size of the data type in bytes. E.g.
> "real(kind=4)" would be a 'single-precision' 32-bit float number,
> while "real(kind=8)" would be a 'double-precision' 64-bit float
> number. The default kind for REAL variables is 4 in gfortran, see:
> 
> https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gfortran/KIND-Type-Parameters.html 
> 
> 
> Since pdp-11 seems to be a 16-bit platform, such a 32-bit
> floating-point type might not be available there? Possibly it makes
> sense to set the default REAL kind to 2 for such a target?

No, because there isn't a 16 bit float type on that machine.  But your answer 
pointed me straight to the problem.

The pdp11 back end has a command line option to choose whether the C "float" 
type is SFmode or DFmode (32 bit or 64 bit).  For various reasons, it defaults 
to 64, which of course means that "float" and "double" are the same machine 
type -- the only float is "real(kind=8)".  If I override the default with 
-mfloat32, Fortran is happy.  Maybe the right answer is to change the default, 
at least once I take away the historic reason for it.

Thanks!

paul

Re: How does a target make Fortran work?

[Janus Weil]

Hi Paul,

Fortran problems are best discussed on fort...@gcc.gnu.org (in CC) ...

2018-07-12 21:22 GMT+02:00 Paul Koning :
> I tried to rebuild for target pdp11 with fortran enabled (in the past I've 
> just enabled C).  It builds fine but the resulting compiler crashes at 
> startup:
>
> Paul-Konings-MacBook-Pro:gcc pkoning$ ./xgcc -B. -O2 -S ../../hello.f
> f951: internal compiler error: gfc_validate_kind(): Got bad kind
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
>
> "hello.f" is the typical "hello world" program.  Some debugging got me to 
> here:
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
> frame #0: 0x0001001c1c93 f951`gfc_init_kinds() [inlined] 
> gfc_validate_kind(type=BT_REAL, kind=, may_fail=false) at 
> trans-types.c:814 [opt]
>811  }
>812
>813if (rc < 0 && !may_fail)
> -> 814  gfc_internal_error ("gfc_validate_kind(): Got bad kind");
>815
>816return rc;
>817  }
> Target 0: (f951) stopped.
>
> So it's unhappy about some "kind", for BT_REAL.  I'm not sure what that 
> means.  Is it mapping the available data types to Fortran "KIND" values?  If 
> so, is there something the target has to do for this to work?  Note that this 
> isn't an IEEE target, so if the initialization is expecting IEEE float then 
> that may account for it.  But I have no idea what to do here, and the manual 
> offers no clue.

A "kind" in Fortran is the size of the data type in bytes. E.g.
"real(kind=4)" would be a 'single-precision' 32-bit float number,
while "real(kind=8)" would be a 'double-precision' 64-bit float
number. The default kind for REAL variables is 4 in gfortran, see:

https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gfortran/KIND-Type-Parameters.html

Since pdp-11 seems to be a 16-bit platform, such a 32-bit
floating-point type might not be available there? Possibly it makes
sense to set the default REAL kind to 2 for such a target?

Cheers,
Janus

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 07/12/2018 08:05 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> I have added command line options:
> 
> -body=
> To dump gimple body (TDF_NONE) of specific function.
> 
> -optimized-blocks=
> To dump gimple body (TDF_BLOCKS) of specific function.
> 
> -optimized-stats=
> To dump gimple body (TDF_STATS) of specific function.
> 
> -optimized-vops=
> To dump gimple body (TDF_VOPS) of specific function.

Hi.

Thanks for it. However I would expect something more smart:
-optimized=[vops,stats,block]. Note that you should do similar
what's done in: gcc/dumpfile.c

int
gcc::dump_manager::
dump_switch_p_1 (const char *arg, struct dump_file_info *dfi, bool doglob)

that will automatically parse   dump_flags_t flags;

Then the copy&parse will not be needed.

> 
> for example:
> 
> -body=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   return _3;
> 
> }
> 
> 
> -optimized-blocks=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _3 = a_1(D) + b_2(D);
>   return _3;
> ;;succ:   EXIT
> 
> }
> 
> 
> -optimized-stats=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   return _3;
> 
> }
> 
> 
> -optimized-vops=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   # VUSE <.MEM_4(D)>
>   return _3;
> 
> }
> 
> I have pushed the changes to the current branch. Please find the diff
> file attached herewith.
> 
> I have tried to follow the coding conventions as far as possible in
> this patch. Please let me know if I am missing out something so that I
> can improve the same while refactoring and clean up as suggested in
> the previous mail.

As mentioned in the previous email, indentation level is 2. And every 8 spaces
are replaced with a tabular. In our patch, you use indentation level equal to
one tab, which results in indentation level 8.

Martin

> 
> Regards,
> 
> Hrishikesh
> 
> On Wed, Jul 11, 2018 at 12:10 AM, Hrishikesh Kulkarni
>  wrote:
>> Hi,
>>
>> Thanks for suggestions. I would start working on these points and will
>> try to complete as early as possible.
>>
>> Regards,
>>
>> Hrishikesh
>>
>> On Mon, Jul 9, 2018 at 2:04 PM, Martin Liška  wrote:
>>> On 07/09/2018 09:50 AM, Hrishikesh Kulkarni wrote:
 Hi,

 The command line option -gimple-stats will dump the statistics of
 gimple statements.

 For example:

 $ ../stage1-build/gcc/lto-dump test_hello.o -gimple-stats

 will dump:

 GIMPLE statements
 Kind   Stmts  Bytes
 ---
 assignments3264
 phi nodes  1248
 conditionals   1 80
 everything else   12704
 ---
 Total 17   1296
 ---

 I have pushed the changes to the repo. Please find the diff file
 attached herewith.

 Regards,

 Hrishikesh
>>>
>>> Hi.
>>>
>>> Thanks for the work. I briefly took a look at the code and I would
>>> focus now directly on refactoring:
>>>
>>> - please make a new branch, first copy lto-dump.c file and all the
>>> Makefile needed stuff and commit that.
>>> - next please rebase (squash) all your patches which you have on top
>>> of it; you did some formatting corrections and it's very hard to read
>>> - please fix coding style, it's mentioned here: 
>>> https://gcc.gnu.org/codingconventions.html
>>> the most problematic is usage of horizontal white spaces. We use 2 spaces
>>> for indentation level, and 8 spaces are replaced with a tabular; without 
>>> that reading your
>>> code is very hard for me
>>> - then please start refactoring functionality that is copied from lto.c and 
>>> put shared
>>> stuff into a header file that will be used by lto.c and lto-dump.c.
>>>
>>> Other observations:
>>> - you use "\t\t%s\t\t%s\t\t%s" formats for prints; I think it would be 
>>> better to
>>> use fixed strings with spaces, try %20s. It's probably also used by tools 
>>> like nm or objdump
>>> - come up with more specific name for 'entry' and 'compare'
>>> - 'entry' should have functions that will print names, ... according to 
>>> options
>>> (flag_lto_dump_demangle, ...); you can have overrides for functions and 
>>> variables
>>> - I would first put all symbols into the vector and then I would print it 
>>> on a single place
>>> - consider using vec from vec.h, hash_map from hash-map.h instead of std:: 
>>> variants
>>> - exit after functions like dump_list, dump_symbol,...
>>> - remove dummy 'dump' function
>>>
>>> Martin
>>>

 On Thu, Jul 5, 2018 at 10:41 PM, Hrishikesh Kulkarni
  wrote:
> Hi,
>
>>

Re: Subnormal float support in armv7(with -msoft-float) for intrinsics

[Umesh Kalappa]

Thank you and issue  raised at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512

~Umesh

On Thu, Jul 12, 2018 at 9:33 PM, Szabolcs Nagy  wrote:
> On 12/07/18 16:20, Umesh Kalappa wrote:
>>
>> Hi everyone,
>>
>> we have our source base ,that was compiled for armv7 on gcc8.1 with
>> soft-float and for following input
>>
>> a=0x0010
>> b=0x0001
>>
>>   result = a - b ;
>>
>> we are getting the result as "0x000e" and with
>> -mhard-float (disabled the flush to zero mode ) we are getting the
>> result as ""0x000f" as expected.
>>
>
> please submit it as a bug report to bugzilla
>
>
>> while debugging the soft-float code,we see that ,the compiler calls
>> the intrinsic "__aeabi_dsub" with arm calling conventions i.e passing
>> "a" in r0 and r1 registers and respectively for "b".
>>
>> we are investigating the routine "__aeabi_dsub" that comes from libgcc
>> for incorrect result  and meanwhile we would like to know that
>>
>> a)do libgcc routines/intrinsic for float operations support or
>> consider the subnormal values ? ,if so how we can enable the same.
>>
>> Thank you
>> ~Umesh
>>
>