Re: Broken links for 4.9.4 manuals

[Jonathan Wakely]

On 15 January 2017 at 01:23, Jonathan Wakely wrote:
> On 14 January 2017 at 12:21, Unknown wrote:
>> Hi!
>>
>> I found the official GCC page for manuals[1].
>> But unfortunately, the libstdc++ docs for my compiler version (4.9.4)
>> cannot be accessed due to broken links on the webpage.
>>
>> These are the ones that do not work presently:
>>
>> GCC-4.9.4 Manuals
>>  - GCC 4.9.4 Standard C++ Library Manual  (also in PDF or XML or
>> an HTML tarball)
>>  - GCC 4.9.4 Standard C++ Library Reference
>> Manual  (also in PDF or XML GPL or XML GDL or an HTML tarball
>>
>> Please note that none of the PDF/XML/Tarball/others work.
>>
>> Could someone fix them up?
>
> Yes, I can do that. In the meanwhile you can use the (almost
> identical) docs for 4.9.3 instead, by manually changing the URLs from
> 4.9.4 to 4.9.3 e.g.
>
> https://gcc.gnu.org/onlinedocs/gcc-4.9.3/libstdc++/manual/
>
> Thanks for pointing it out.

The Libstdc++ docs for 4.9.4 are online now, all the links should be
working correctly.

Thanks again.

Successful bootstrap and install of gcc (GCC) 6.3.0 on hppa2.0-unknown-linux-gnu

[Aaro Koskinen]

Hi,

Here's a report of a successful build and install of GCC:

$ gcc-6.3.0/config.guess
hppa2.0-unknown-linux-gnu

$ newcompiler/bin/gcc -v
Using built-in specs.
COLLECT_GCC=newcompiler/bin/gcc
COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/hppa-unknown-linux-gnu/6.3.0/lto-wrapper
Target: hppa-unknown-linux-gnu
Configured with: ../gcc-6.3.0/configure --disable-nls 
--prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ 
--host=hppa-unknown-linux-gnu --build=hppa-unknown-linux-gnu 
--target=hppa-unknown-linux-gnu --with-system-zlib --with-sysroot=/
Thread model: posix
gcc version 6.3.0 (GCC) 

-- Build environment --

host: hp-c3700
distro:   los.git rootfs=ef31e1 native=ef31e1
kernel:   Linux 4.9.0-los_ef31e1
binutils: GNU binutils 2.27
make: GNU Make 4.2.1
libc: GNU C Library (GNU libc) stable release version 2.24
zlib: 1.2.8
mpfr: 3.1.3
gmp:  6

-- Time consumed --

configure:  real0m 26.32s
user0m 10.32s
sys 0m 7.93s

bootstrap:  real20h 34m 59s
user19h 28m 16s
sys 53m 31.44s

install:real1m 18.43s
user0m 20.58s
sys 0m 35.82s

-- Hardware details ---

MemTotal: 2070740 kB

processor   : 0
cpu family  : PA-RISC 2.0
cpu : PA8700 (PCX-W2)
cpu MHz : 750.00
capabilities: os32 os64 iopdir_fdc nva_supported (0x07)
model   : 9000/785/C3700
model name  : Allegro W2
hversion: 0x5dc0
sversion: 0x0481
I-cache : 768 KB
D-cache : 1536 KB (WB, direct mapped)
ITLB entries: 240
DTLB entries: 240 - shared with ITLB
bogomips: 1495.85
software id : 2004755634

A.

oddities in the moxie gcc backend

[Mikael Pettersson]

I have a toy backend based on the moxie backend as a template.  During its
development I found some oddities in the moxie backend that may be bugs.

1. The REGNO_OK_FOR_INDEX_P(NUM) macro in moxie.h is:

#define REGNO_OK_FOR_INDEX_P(NUM) MOXIE_FP

Since MOXIE_FP is 0, this returns false for every register.  Should the body
be a literal 0, or some comparison between NUM and MOXIE_FP?

2. I see no actual use of MOXIE_PC or the SPECIAL_REGS register class.  Could 
they
be deleted (with adjustments for decrementing MOXIE_CC)?

3. moxie_compute_frame () doesn't take !fixed_regs[regno] into account, which 
the
related loops in moxie_expand_prologue () and moxie_expand_epilogue () do.  Bug?

There are also some minor nits:

4. The comment above `size_for_adjusting_sp' states it's used in 
expand_epilogue(),
which it isn't.

5. The "Compute this since .." comment in moxie_initial_elimination_offset () 
should
probably refer to callee_saved_reg_size not local_vars_size, to match the code.

6. There are two idential definitions of TRULY_NOOP_TRUNCATION(op,ip) in 
moxie.h.
The first one looks misplaced and should probably be deleted.


/Mikael

Re: Broken links for 4.9.4 manuals

[Ashish Gupta]

Thanks for the quick fix, and also for the 4.9.3 suggestion!

Regards,
Ashish Gupta

On Sun, Jan 15, 2017 at 1:49 PM, Jonathan Wakely  wrote:
> On 15 January 2017 at 01:23, Jonathan Wakely wrote:
>> On 14 January 2017 at 12:21, Unknown wrote:
>>> Hi!
>>>
>>> I found the official GCC page for manuals[1].
>>> But unfortunately, the libstdc++ docs for my compiler version (4.9.4)
>>> cannot be accessed due to broken links on the webpage.
>>>
>>> These are the ones that do not work presently:
>>>
>>> GCC-4.9.4 Manuals
>>>  - GCC 4.9.4 Standard C++ Library Manual  (also in PDF or XML or
>>> an HTML tarball)
>>>  - GCC 4.9.4 Standard C++ Library Reference
>>> Manual  (also in PDF or XML GPL or XML GDL or an HTML tarball
>>>
>>> Please note that none of the PDF/XML/Tarball/others work.
>>>
>>> Could someone fix them up?
>>
>> Yes, I can do that. In the meanwhile you can use the (almost
>> identical) docs for 4.9.3 instead, by manually changing the URLs from
>> 4.9.4 to 4.9.3 e.g.
>>
>> https://gcc.gnu.org/onlinedocs/gcc-4.9.3/libstdc++/manual/
>>
>> Thanks for pointing it out.
>
> The Libstdc++ docs for 4.9.4 are online now, all the links should be
> working correctly.
>
> Thanks again.

gcc-7-20170115 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 244479

You'll find:

 gcc-7-20170115.tar.bz2   Complete GCC

  MD5=76739b63339148024e323a5c3dad7125
  SHA1=97910163fb28edc0d4412ae9d61252aa76629048

Diffs from 7-20170108 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
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: LTO crashes with fortran code in SPEC CPU 2006

[kugan]

On 15/01/17 15:57, Andrew Pinski wrote:

Just this is just an FYI until I reduce the testcases but 5 benchmarks
in SPEC CPU 2006 with fortran code is causing an ICE on
aarch64-linux-gnu with -Ofast -flto -mcpu=thunderx2t99
-fno-aggressive-loop-optimizations -funroll-loops:
lto1: internal compiler error: in ipa_get_type, at ipa-prop.h:448
0x107c58f ipa_get_type
../../gcc/gcc/ipa-prop.h:448
0x107c58f propagate_constants_across_call
../../gcc/gcc/ipa-cp.c:2259
0x1080f4f propagate_constants_topo
../../gcc/gcc/ipa-cp.c:3170
0x1080f4f ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:3267
0x1081fcb ipcp_driver
../../gcc/gcc/ipa-cp.c:4997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gfortran returned 1 exit status

I don't know when this started as I am just starting to run SPEC CPU
2006 fp side with my spec cpu 2006 config.


I am seeing this too for aatch64 with -O3 -flto. It did work few weeks 
back. This must be a new bug.


Thanks,
Kugan




Thanks,
Andrew

Re: LTO crashes with fortran code in SPEC CPU 2006

[Andrew Pinski]

On Sun, Jan 15, 2017 at 4:09 PM, kugan
 wrote:
>
>
> On 15/01/17 15:57, Andrew Pinski wrote:
>>
>> Just this is just an FYI until I reduce the testcases but 5 benchmarks
>> in SPEC CPU 2006 with fortran code is causing an ICE on
>> aarch64-linux-gnu with -Ofast -flto -mcpu=thunderx2t99
>> -fno-aggressive-loop-optimizations -funroll-loops:
>> lto1: internal compiler error: in ipa_get_type, at ipa-prop.h:448
>> 0x107c58f ipa_get_type
>> ../../gcc/gcc/ipa-prop.h:448
>> 0x107c58f propagate_constants_across_call
>> ../../gcc/gcc/ipa-cp.c:2259
>> 0x1080f4f propagate_constants_topo
>> ../../gcc/gcc/ipa-cp.c:3170
>> 0x1080f4f ipcp_propagate_stage
>> ../../gcc/gcc/ipa-cp.c:3267
>> 0x1081fcb ipcp_driver
>> ../../gcc/gcc/ipa-cp.c:4997
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
>> lto-wrapper: fatal error: gfortran returned 1 exit status
>>
>> I don't know when this started as I am just starting to run SPEC CPU
>> 2006 fp side with my spec cpu 2006 config.
>
>
> I am seeing this too for aatch64 with -O3 -flto. It did work few weeks back.
> This must be a new bug.

I am reducing the crash right now with 459.GemsFDTD since that one
seems like the smallest one to reduce.

Thanks,
Andrew

>
> Thanks,
> Kugan
>
>
>>
>> Thanks,
>> Andrew
>>
>