Re: debug-early branch merged into mainline

[Richard Biener]

On June 5, 2015 9:06:01 PM GMT+02:00, Aldy Hernandez  wrote:
>The debug-early work has been merged into mainline.
>
>There is a known Ada failure which Eric B. knows about and approved,
>and 
>for which there is an appropriate FIXME note in the Ada sources:
>
>+FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial
>17
>
>There is also a known regression in the testsuite that we've discussed 
>before and will be fixed shortly.  It is an optimization issue:
>
>+FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c 
>scan-assembler-times DIE \\([^\n]*\\) 
>DW_TAG_(?:const|volatile|atomic|restrict)_type 8
>
>Finally, as previously discussed there can be substantial increases in 
>the size of the .debug_info sections for a minimum of cases.  This is 
>immediately on my plate as of right now.  It is expected.  Please don't
>
>report this, or any of the above 2 failures.
>
>Thanks to everyone involved in the design and review, particularly
>Jason 
>and Richi who were there at each step of the way, and Michael Matz
>whose 
>original patch this work is based off of.

Yay!  And thanks to you for being patient enough to get this to trunk!

We've discussed some followup work that should now be possible, amongst it 
enabling (parts of) free-lang-data even if we are not writing LTO bytecode. 
Then refactoring dwarf2out to separate early/late dwarf generation better.  And 
finally bring the LTO bits I was working on to a mergeable state.  And after 
that fix how we deal with abstract instances (for in lining).

Richard.

>Aldy

Re: debug-early branch merged into mainline

[Andreas Schwab]

Aldy Hernandez  writes:

> The debug-early work has been merged into mainline.
>
> There is a known Ada failure which Eric B. knows about and approved, and
> for which there is an appropriate FIXME note in the Ada sources:
>
> +FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 17
>
> There is also a known regression in the testsuite that we've discussed
> before and will be fixed shortly.  It is an optimization issue:
>
> +FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c
> scan-assembler-times DIE \\([^\n]*\\)
> DW_TAG_(?:const|volatile|atomic|restrict)_type 8

I'm also seeing this:

FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
Excess errors:
xgcc: error: 
/daten/aranym/gcc/gcc-20150606/gcc/testsuite/gcc.dg/autopar/pr46885.c: 
-fcompare-debug failure

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: debug-early branch merged into mainline

[Andreas Schwab]

Bootstrap fails on aarch64:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/ira-costs.o differs
gcc/tree-sra.o differs
gcc/tree-parloops.o differs
gcc/tree-vect-data-refs.o differs
gcc/java/jcf-io.o differs
gcc/ipa-inline-analysis.o differs

and on ia64:

../../gcc/dwarf2out.c: In function 'void gen_block_die(tree, dw_die_ref)':
../../gcc/dwarf2out.c:19868:42: error: 'stmt_die' may be used uninitialized in \
this function [-Werror=maybe-uninitialized]
  add_high_low_attributes (stmt, stmt_die);
  ^
../../gcc/dwarf2out.c:19821:14: note: 'stmt_die' was declared here
   dw_die_ref stmt_die;
  ^

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: debug-early branch merged into mainline

[Aldy Hernandez]

On 06/06/2015 05:49 AM, Andreas Schwab wrote:

Bootstrap fails on aarch64:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/ira-costs.o differs
gcc/tree-sra.o differs
gcc/tree-parloops.o differs
gcc/tree-vect-data-refs.o differs
gcc/java/jcf-io.o differs
gcc/ipa-inline-analysis.o differs

and on ia64:

../../gcc/dwarf2out.c: In function 'void gen_block_die(tree, dw_die_ref)':
../../gcc/dwarf2out.c:19868:42: error: 'stmt_die' may be used uninitialized in \
this function [-Werror=maybe-uninitialized]
   add_high_low_attributes (stmt, stmt_die);
   ^
../../gcc/dwarf2out.c:19821:14: note: 'stmt_die' was declared here
dw_die_ref stmt_die;


Does the attached fix the ia64 failure?

commit 6c40c8f011bbd09ea92749f3925db83f249baf74
Author: Aldy Hernandez 
Date:   Sat Jun 6 06:48:40 2015 -0400

* dwarf2out.c (gen_lexical_block_die): Initialize stmt_die.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 2e3bee3..23cf120 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19818,7 +19818,7 @@ static void
 gen_lexical_block_die (tree stmt, dw_die_ref context_die)
 {
   dw_die_ref old_die = BLOCK_DIE (stmt);
-  dw_die_ref stmt_die;
+  dw_die_ref stmt_die = NULL;
   if (!old_die)
 {
   stmt_die = new_die (DW_TAG_lexical_block, context_die, stmt);
@@ -19859,13 +19859,13 @@ gen_lexical_block_die (tree stmt, dw_die_ref 
context_die)
   if (old_die)
 stmt_die = old_die;
 
-  if (!early_dwarf)
+  /* A non abstract block whose blocks have already been reordered
+ should have the instruction range for this block.  If so, set the
+ high/low attributes.  */
+  if (!early_dwarf && !BLOCK_ABSTRACT (stmt) && TREE_ASM_WRITTEN (stmt))
 {
-  /* A non abstract block whose blocks have already been reordered
-should have the instruction range for this block.  If so, set the
-high/low attributes.  */
-  if (! BLOCK_ABSTRACT (stmt) && TREE_ASM_WRITTEN (stmt))
-   add_high_low_attributes (stmt, stmt_die);
+  gcc_assert (stmt_die);
+  add_high_low_attributes (stmt, stmt_die);
 }
 
   decls_for_scope (stmt, stmt_die);

Re: Builtin expansion versus headers optimization: Reductions

[Ondřej Bílka]

On Fri, Jun 05, 2015 at 12:55:04PM +0400, Mikhail Maltsev wrote:
> 05.06.2015 13:02, Ondřej Bílka writes:
> > Also as I mentioned bugs before gcc now doesn't handle alignment well so
> > it doesn't optimize following to zero for aligned code.
> > 
> >  align = ((uintptr_t) x) % 16;
> > 
> That is because GCC is conservative and supports some non-ABI-compliant
> memory allocators which only guarantee 8-byte alignment, but
> 
Then adding these annotations wouldn't help much as one could interpose
malloc and violate that, unless we rule out that it shouldn't be
replaced by noncompilant one.

Re: debug-early branch merged into mainline

[Andreas Schwab]

Aldy Hernandez  writes:

> Does the attached fix the ia64 failure?
>
> commit 6c40c8f011bbd09ea92749f3925db83f249baf74
> Author: Aldy Hernandez 
> Date:   Sat Jun 6 06:48:40 2015 -0400
>
>   * dwarf2out.c (gen_lexical_block_die): Initialize stmt_die.

Yes, it does.

Thanks, Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Static Chain Register on iOS AArch64

[Richard Earnshaw]

On 05/06/15 16:55, Richard Henderson wrote:
> On 06/04/2015 03:40 AM, Richard Earnshaw wrote:
>> The static chain register is pretty much private to a translation unit...
> 
> That was true when the static chain was restricted to trampolines. 
> Since Go has started using it for cross-translation-unit closures, that
> makes it part of the ABI.
> 
> I did raise this issue at the start of the year, when I submitted the
> patches.  At the time, folks seemed ok with the additional restriction.
> 
> 
> r~

That's going to make it impossible to implement Go closures on AArch32,
then, since the only call-clobbered register not used for parameter
passing is r12 (ip) and that can be clobbered by function calls.

R.

Re: debug-early branch merged into mainline

[Andreas Schwab]

Andreas Schwab  writes:

> FAIL: gcc.dg/autopar/pr46885.c (test for excess errors)
> Excess errors:
> xgcc: error: 
> /daten/aranym/gcc/gcc-20150606/gcc/testsuite/gcc.dg/autopar/pr46885.c: 
> -fcompare-debug failure

As it turned out, this is a fallout from a different commit.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: debug-early branch merged into mainline

[Aldy Hernandez]

On 06/06/2015 09:20 AM, Andreas Schwab wrote:

Aldy Hernandez  writes:


Does the attached fix the ia64 failure?

commit 6c40c8f011bbd09ea92749f3925db83f249baf74
Author: Aldy Hernandez 
Date:   Sat Jun 6 06:48:40 2015 -0400

* dwarf2out.c (gen_lexical_block_die): Initialize stmt_die.


Yes, it does.



Committed as obvious.

Re: debug-early branch merged into mainline

[Jan Hubicka]

Aldy,
also at PPC64le LTO bootstrap (at gcc112) dies with:
^
0x104ae8f7 check_die
../../gcc/dwarf2out.c:5715
0x104e4e1b dwarf2out_decl
../../gcc/dwarf2out.c:21886
0x104d8a87 dwarf2out_abstract_function
../../gcc/dwarf2out.c:18457
0x104dd3e7 gen_inlined_subroutine_die
../../gcc/dwarf2out.c:19891
0x104e11f7 gen_block_die
../../gcc/dwarf2out.c:20933
0x104e17b3 decls_for_scope
../../gcc/dwarf2out.c:21006
0x104da907 gen_subprogram_die
../../gcc/dwarf2out.c:19167
0x104e343b gen_decl_die
../../gcc/dwarf2out.c:21409
0x104e4dfb dwarf2out_decl
../../gcc/dwarf2out.c:21882
0x104e4e6f dwarf2out_function_decl
../../gcc/dwarf2out.c:21894
0x105ab99f rest_of_handle_final
../../gcc/final.c:4505
0x105abd27 execute
../../gcc/final.c:4547
Please submit a full bug report,
with preprocessed source if appropriate.

gcc@gcc.gnu.org

[stevenyhw]

Dear GCC developers,

I have successfully compiled & installed GCC 4.9.2. Could you comment on the 
results of 'make check' (see below). Here is the relevant information:

1. config.guess
  x86_64-unknown-linux-gnu
2. gcc -v
Using built-in specs.
COLLECT_GCC=/Scr/scr-test-steven/install/gcc/4.9.2/bin/gcc

COLLECT_LTO_WRAPPER=/Scr/scr-test-steven/install/gcc/4.9.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure 
--prefix=/Scr/scr-test-steven/install/install/gcc/4.9.2 --disable-multilib 
--with-gmp=/Scr/scr-test-steven/install/libgmp/4.3.2 
--with-mpfr=/Scr/scr-test-steven/install/libmpfr/2.4.2 
--with-mpc=/Scr/scr-test-steven/install/libmpc/0.8.1 
--with-cloog=/Scr/scr-test-steven/install/libcloog/0.18.1 
--with-isl=/Scr/scr-test-steven/install/libisl/0.12.2 
CC=/Scr/scr-test-steven/install/gcc/4.7.4/bin/gcc 
CXX=/Scr/scr-test-steven/install/gcc/4.7.4/bin/g++ 
CPPFLAGS=-I/Scr/scr-test-steven/install/gcc/4.7.4/include 
LDFLAGS=-L/Scr/scr-test-steven/install/gcc/4.7.4/lib64
Thread model: posix
gcc version 4.9.2 (GCC)

3. uname --version
uname (GNU coreutils) 8.4
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

4. rpm -q glibc
glibc-2.12-1.149.el6_6.9.x86_64
glibc-2.12-1.149.el6_6.9.i686

5. * CentOS 6.6
* x86_64 architecture (Intel(R) Xeon(R) CPU W3550  @ 3.07GHz)
* The following programs are used for compiling gcc-4.7.4
  1) gcc/4.7.4
  2) autoconf/2.64
  3) cloog/0.18.1
  4) gmp/4.3.2
  5) isl/0.12.2
  6) mpc/0.8.1
  7) mpfr/2.4.2
  8) dejagnu/1.5.3

6. summary of 'make check'

LAST_UPDATED: Obtained from SVN: tags/gcc_4_9_2_release revision 216910

Native configuration is x86_64-unknown-linux-gnu

=== gcc tests ===


Running target unix

=== gcc Summary ===

# of expected passes105540
# of expected failures  256
# of unsupported tests  2028
/Scr/scr-test-steven/Programs/GCC/build_gcc-4.9.2/gcc/xgcc  version 4.9.2 (GCC) 

=== gfortran tests ===


Running target unix
FAIL: gfortran.dg/guality/pr41558.f90  -O2  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer  line 7 s == 
'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer -funroll-loops  
line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer 
-funroll-all-loops -finline-functions  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -g  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -Os  line 7 s == 'foo'

=== gfortran Summary ===

# of expected passes46057
# of unexpected failures6
# of expected failures  52
# of unsupported tests  75
/Scr/scr-test-steven/Programs/GCC/build_gcc-4.9.2/gcc/testsuite/gfortran/../../gfortran
  version 4.9.2 (GCC) 

=== g++ tests ===


Running target unix

=== g++ Summary ===

# of expected passes88567
# of expected failures  445
# of unsupported tests  3072
/Scr/scr-test-steven/Programs/GCC/build_gcc-4.9.2/gcc/testsuite/g++/../../xg++  
version 4.9.2 (GCC) 

=== objc tests ===


Running target unix

=== objc Summary ===

# of expected passes2988
# of expected failures  6
# of unsupported tests  74
/Scr/scr-test-steven/Programs/GCC/build_gcc-4.9.2/gcc/xgcc  version 4.9.2 (GCC) 

=== boehm-gc tests ===


Running target unix

=== boehm-gc Summary ===

# of expected passes12
# of unsupported tests  1
=== libatomic tests ===


Running target unix

=== libatomic Summary ===

# of expected passes54
=== libffi tests ===


Running target unix

=== libffi Summary ===

# of expected passes1819
# of unsupported tests  55
=== libgomp tests ===


Running target unix

=== libgomp Summary ===

# of expected passes3247
# of unsupported tests  35
=== libitm tests ===


Running target unix

=== libitm Summary ===

# of expected passes26
# of expected failures  3
# of unsupported tests  1
=== libjava tests ===


Running target unix
XPASS: sourcelocation -O3 -findirect-dispatch output - source compiled test

=== libjava Summary ===

# of expected passes2582
# of unexpected successes   1
# of expect

Re: debug-early branch merged into mainline

[Aldy Hernandez]

On 06/06/2015 03:33 PM, Jan Hubicka wrote:

Aldy,
also at PPC64le LTO bootstrap (at gcc112) dies with:
^
0x104ae8f7 check_die
 ../../gcc/dwarf2out.c:5715


Hmmm... this is in the LTO/ltrans stage?  If so, that's weird.  The LTO 
path does not do the early DIE dance.  Since check_die() is a new sanity 
check for DIEs, I wonder if this is a latent bug that was already there.


How do I reproduce/do the LTO bootstrap thing?

Aldy


0x104e4e1b dwarf2out_decl
 ../../gcc/dwarf2out.c:21886
0x104d8a87 dwarf2out_abstract_function
 ../../gcc/dwarf2out.c:18457
0x104dd3e7 gen_inlined_subroutine_die
 ../../gcc/dwarf2out.c:19891
0x104e11f7 gen_block_die
 ../../gcc/dwarf2out.c:20933
0x104e17b3 decls_for_scope
 ../../gcc/dwarf2out.c:21006
0x104da907 gen_subprogram_die
 ../../gcc/dwarf2out.c:19167
0x104e343b gen_decl_die
 ../../gcc/dwarf2out.c:21409
0x104e4dfb dwarf2out_decl
 ../../gcc/dwarf2out.c:21882
0x104e4e6f dwarf2out_function_decl
 ../../gcc/dwarf2out.c:21894
0x105ab99f rest_of_handle_final
 ../../gcc/final.c:4505
0x105abd27 execute
 ../../gcc/final.c:4547
Please submit a full bug report,
with preprocessed source if appropriate.

Re: debug-early branch merged into mainline

[Aldy Hernandez]

On 06/06/2015 05:47 PM, Aldy Hernandez wrote:

On 06/06/2015 03:33 PM, Jan Hubicka wrote:

Aldy,
also at PPC64le LTO bootstrap (at gcc112) dies with:
^
0x104ae8f7 check_die
 ../../gcc/dwarf2out.c:5715


Hmmm... this is in the LTO/ltrans stage?  If so, that's weird.  The LTO
path does not do the early DIE dance.  Since check_die() is a new sanity
check for DIEs, I wonder if this is a latent bug that was already there.


It looks like ppc64le fails to bootstrap with the same comparison 
failure aarch64 fails with, so I need to take a look at ppc64le regardless.


However, for your particular problem, I wonder if this was a preexisting 
condition.  Would you mind reproducing your problem without my 
debug-early patchset, but with the attached patch?


The commit prior to debug-early is:

git commit d51560f9afc5c8a826bcfa6fc90a96156b623559
trunk@224160

The attached patch adds the sanity check, but without the debug-early 
work.  If you still get a failure, this is a pre-existing bug.


Thanks.
Aldy
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 55364a2..c35399a 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -21271,6 +21271,34 @@ gen_namelist_decl (tree name, dw_die_ref scope_die, 
tree item_decls)
 }
 
 
+/* Sanity checks on DIEs.  */
+
+static void
+check_die (dw_die_ref die)
+{
+  /* A debugging information entry that is a member of an abstract
+ instance tree [that has DW_AT_inline] should not contain any
+ attributes which describe aspects of the subroutine which vary
+ between distinct inlined expansions or distinct out-of-line
+ expansions.  */
+  unsigned ix;
+  dw_attr_ref a;
+  bool inline_found = false;
+  FOR_EACH_VEC_SAFE_ELT (die->die_attr, ix, a)
+if (a->dw_attr == DW_AT_inline && a->dw_attr_val.v.val_unsigned)
+  inline_found = true;
+  if (inline_found)
+{
+  /* Catch the most common mistakes.  */
+  FOR_EACH_VEC_SAFE_ELT (die->die_attr, ix, a)
+   gcc_assert (a->dw_attr != DW_AT_low_pc
+   && a->dw_attr != DW_AT_high_pc
+   && a->dw_attr != DW_AT_location
+   && a->dw_attr != DW_AT_frame_base
+   && a->dw_attr != DW_AT_GNU_all_call_sites);
+}
+}
+
 /* Write the debugging output for DECL.  */
 
 static void
@@ -21398,6 +21426,9 @@ dwarf2out_decl (tree decl)
   return;
 }
 
+ dw_die_ref die = lookup_decl_die (decl);
+  if (die)
+check_die (die);
   gen_decl_die (decl, NULL, context_die);
 }
 

Re: debug-early branch merged into mainline

[Jan Hubicka]

> On 06/06/2015 03:33 PM, Jan Hubicka wrote:
> >Aldy,
> >also at PPC64le LTO bootstrap (at gcc112) dies with:
> >^
> >0x104ae8f7 check_die
> > ../../gcc/dwarf2out.c:5715
> 
> Hmmm... this is in the LTO/ltrans stage?  If so, that's weird.  The
> LTO path does not do the early DIE dance.  Since check_die() is a
> new sanity check for DIEs, I wonder if this is a latent bug that was
> already there.
> 
> How do I reproduce/do the LTO bootstrap thing?

I simply bootstrap with 

configure --enable-languages=all,obj-c++,go --disable-werror 
--with-build-config=bootstrap-lt

It is during ltrans stage.

Honza
> 
> Aldy
> 
> >0x104e4e1b dwarf2out_decl
> > ../../gcc/dwarf2out.c:21886
> >0x104d8a87 dwarf2out_abstract_function
> > ../../gcc/dwarf2out.c:18457
> >0x104dd3e7 gen_inlined_subroutine_die
> > ../../gcc/dwarf2out.c:19891
> >0x104e11f7 gen_block_die
> > ../../gcc/dwarf2out.c:20933
> >0x104e17b3 decls_for_scope
> > ../../gcc/dwarf2out.c:21006
> >0x104da907 gen_subprogram_die
> > ../../gcc/dwarf2out.c:19167
> >0x104e343b gen_decl_die
> > ../../gcc/dwarf2out.c:21409
> >0x104e4dfb dwarf2out_decl
> > ../../gcc/dwarf2out.c:21882
> >0x104e4e6f dwarf2out_function_decl
> > ../../gcc/dwarf2out.c:21894
> >0x105ab99f rest_of_handle_final
> > ../../gcc/final.c:4505
> >0x105abd27 execute
> > ../../gcc/final.c:4547
> >Please submit a full bug report,
> >with preprocessed source if appropriate.
> >

Re: debug-early branch merged into mainline

[Jan Hubicka]

> > On 06/06/2015 03:33 PM, Jan Hubicka wrote:
> > >Aldy,
> > >also at PPC64le LTO bootstrap (at gcc112) dies with:
> > >^
> > >0x104ae8f7 check_die
> > > ../../gcc/dwarf2out.c:5715
> > 
> > Hmmm... this is in the LTO/ltrans stage?  If so, that's weird.  The
> > LTO path does not do the early DIE dance.  Since check_die() is a
> > new sanity check for DIEs, I wonder if this is a latent bug that was
> > already there.
> > 
> > How do I reproduce/do the LTO bootstrap thing?
> 
> I simply bootstrap with 
> 
> configure --enable-languages=all,obj-c++,go --disable-werror 
> --with-build-config=bootstrap-lt
Ah, not full command line:
configure --enable-languages=all,obj-c++,go --disable-werror 
--with-build-config=bootstrap-lto

I will try your check die patch but probably not until Monday afternoon - have 
real life deadlines
till then.

Honza

gcc@gcc.gnu.org

[Mikhail Maltsev]

On 07.06.2015 0:15, steven...@gmail.com wrote:
> Dear GCC developers,
> 
> I have successfully compiled & installed GCC 4.9.2. Could you comment on the 
> results of 'make check' (see below). Here is the relevant information:
> 
You can verify it against published test results:
https://www.gnu.org/software/gcc/gcc-4.9/buildstat.html
>   === gfortran tests ===
> 
> 
> Running target unix
> FAIL: gfortran.dg/guality/pr41558.f90  -O2  line 7 s == 'foo'
> FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer  line 7 s == 
> 'foo'
> FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer 
> -funroll-loops  line 7 s == 'foo'
> FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer 
> -funroll-all-loops -finline-functions  line 7 s == 'foo'
> FAIL: gfortran.dg/guality/pr41558.f90  -O3 -g  line 7 s == 'foo'
> FAIL: gfortran.dg/guality/pr41558.f90  -Os  line 7 s == 'foo'
> 
guality testsuite checks generated debug information. It's a functional
test, i.e. it performs real GDB invocation, so the result might also
depend on your version of GDB, it's settings, etc.

There are similar issues on CentOS 6 in this test report
https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03335.html (though
it's i686).

BTW, this failure also reproduces for me on current trunk.

-- 
Regards,
Mikhail Maltsev

gcc@gcc.gnu.org

[Steven]

Hi Mikhail,

Thanks for the comments. I haven't updated my GDB yet and I will test it 
again once I have a newer version GDB.



Yuhang

On 06/06/2015 09:31 PM, Mikhail Maltsev wrote:

On 07.06.2015 0:15, steven...@gmail.com wrote:

Dear GCC developers,

I have successfully compiled & installed GCC 4.9.2. Could you comment on the 
results of 'make check' (see below). Here is the relevant information:


You can verify it against published test results:
https://www.gnu.org/software/gcc/gcc-4.9/buildstat.html

=== gfortran tests ===


Running target unix
FAIL: gfortran.dg/guality/pr41558.f90  -O2  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer  line 7 s == 
'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer -funroll-loops  
line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer 
-funroll-all-loops -finline-functions  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -g  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -Os  line 7 s == 'foo'


guality testsuite checks generated debug information. It's a functional
test, i.e. it performs real GDB invocation, so the result might also
depend on your version of GDB, it's settings, etc.

There are similar issues on CentOS 6 in this test report
https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03335.html (though
it's i686).

BTW, this failure also reproduces for me on current trunk.