Re: Any very recent inlining changes (libstdc++' ABI check fails in mainline) ?

[Paolo Carlini]

Richard, Jan,

I'm confused. Consider this symbol:

 W
_ZN9__gnu_cxx8__detail9__find_ifIPSt4pairIPNS_16bitmap_allocatorIcE12_Alloc_blockES6_ENS0_12_Functor_RefINS0_12_Ffit_finderIS6_EET_SD_SD_T0_
version status: incompatible
GLIBCXX_3.4
type: function
status: added

I went multiple times through the linker script and didn't find any
pattern matching it! Can you? What can be possibly going on?

Paolo.

Re: GCC's switch table code generation

[Edd Barrett]

On Wed, Oct 07, 2009 at 09:05:48PM -0700, Ian Lance Taylor wrote:
> Edd Barrett  writes:
> 
> > I would be really interested to know how GCC:
> >  * Decides whether or not to embed tables in the data segment of the binary.
> >  * Selects the comparisons in the above tree.
> 
> The relevant code is expand_case and friends in gcc/stmt.c.  Where a
> jump table should go is decided on a target by target basis by the
> backend macro JUMP_TABLES_IN_TEXT_SECTION.

Many thanks for the pointer
> 
> > Perhaps someone knows of a good paper/book on this topic which could
> > be of use, or a relevant section of code in the GCC sources (at the
> > moment I am overwhelmed by the source tree).
> 
> You may be interested in reading Roger Sayle's paper in the 2008 gcc
> summit, linked from http://ols.fedoraproject.org/GCC/Reprints-2008/ .

Excellent paper. Again many thanks!

-- 
Best Regards
Edd Barrett

http://students.dec.bmth.ac.uk/ebarrett

Re: [RFA] dwarf2out.c:eliminate_regs() bug

[Maxim Kuvyrkov]

Richard Guenther wrote:
...

Yes, though we should probably try to catch the DECL_ABSTRACT case
further up the call chain - there shouldn't be any location lists for abstract
function.  Thus, see why

static dw_die_ref
gen_formal_parameter_die (tree node, tree origin, dw_die_ref context_die)
...
  if (! DECL_ABSTRACT (node_or_origin))
add_location_or_const_value_attribute (parm_die, node_or_origin,
   DW_AT_location);

the node_or_origin of the param isn't DECL_ABSTRACT.  In the end the
above check should have avoided the situation you run into.


The origin_or_origin (== origin) turned out to be 'this' pointer.  It 
came from BLOCK_NONLOCALIZED_VARs in decls_for_scope():


static void
decls_for_scope (tree stmt, dw_die_ref context_die, int depth)
{
...
   for (i = 0; i < BLOCK_NUM_NONLOCALIZED_VARS (stmt); i++)
 process_scope_var (stmt, NULL, BLOCK_NONLOCALIZED_VAR (stmt, i),
context_die);
...
}

set_decl_abstract_flags() doesn't seem to process 
BLOCK_NONLOCALIZED_VARs.  From what I gather, this is correct behavior.


At this point I got the feeling that something is clobbering the 
information.  There is this patch by Honza 
(http://gcc.gnu.org/viewcvs/trunk/gcc/dwarf2out.c?r1=151901&r2=151917) 
that fixes a clobbering issue with abstract functions.  Backporting it 
to my sources fixed the problem, yay!


Honza, does the bug you've fixed with the above patch resemble the 
problem I've stumbled into?


Regards,

--
Maxim K.

Re: Any very recent inlining changes (libstdc++' ABI check fails in mainline) ?

[Jan Hubicka]

> Richard, Jan,
> 
> I'm confused. Consider this symbol:
> 
>  W
> _ZN9__gnu_cxx8__detail9__find_ifIPSt4pairIPNS_16bitmap_allocatorIcE12_Alloc_blockES6_ENS0_12_Functor_RefINS0_12_Ffit_finderIS6_EET_SD_SD_T0_
> version status: incompatible
> GLIBCXX_3.4
> type: function
> status: added
> 
> I went multiple times through the linker script and didn't find any
> pattern matching it! Can you? What can be possibly going on?

There was bug causing some of abstract (unspecialized) methods to be
mistakely output.  I fixed it this morning, perhaps this is occurence of
this problem?

Honza
> 
> Paolo.

Re: Any very recent inlining changes (libstdc++' ABI check fails in mainline) ?

[Paolo Carlini]

Hi Honza,
> There was bug causing some of abstract (unspecialized) methods to be
> mistakely output.  I fixed it this morning, perhaps this is occurence of
> this problem?
>   
Thanks for the hint, but I don't think it's that. The regression tester
results are just out for Revision: 152556 and the abi fail is there :(

Really, I have no idea what the heck is going on with those 4 symbols
(probably the other are simpler), I cannot find where the first linker
script part, for baseline (GLIBCXX_3.4), lets them through... This issue
is making me crazy, it even persists if I change that free function to
be a member of bitmap_allocator...

Paolo.

Re: Any very recent inlining changes (libstdc++' ABI check fails in mainline) ?

[Paolo Carlini]

Paolo Carlini wrote:
> Really, I have no idea what the heck is going on with those 4 symbols
> (probably the other are simpler), I cannot find where the first linker
> script part, for baseline (GLIBCXX_3.4), lets them through... This issue
> is making me crazy, it even persists if I change that free function to
> be a member of bitmap_allocator...
>   
Ok, I got it, it's this line:

  std::[p-q]*;

it's because the function *returns* a std::pair... g

Paolo.

libjava and ada broken on x86_64

[Diego Novillo]

Happens while building 32 bit libjava on x86_64

libtool: compile:  [ ... ] -g -O2 -D_GNU_SOURCE -m32 -MT posix.lo -MD
-MP -MF .deps/posix.Tpo -c .../libjava/posix.cc  -fPIC -DPIC -o
.libs/posix.o

/tmp/cc60L3lJ.s: Assembler messages:
/tmp/cc60L3lJ.s:943: Error: junk at end of line, first unrecognized
character is `*'
/tmp/cc60L3lJ.s:944: Error: junk at end of line, first unrecognized
character is `*'
/tmp/cc60L3lJ.s:945: Error: expected comma after "_ZGAN8__JArrayC1Ev"
make[5]: *** [posix.lo] Error 1


Ada also seems to be in bad shape.  Yesterday's build failed
with:

bld/./gcc/xgcc [...]   -c -g -O2 -m32 -fPIC  -W -Wall -gnatpg -m32
a-strunb.adb -o a-strunb.o

+===GNAT BUG DETECTED==+
| 4.5.0 20091007 (experimental) (x86_64-unknown-linux-gnu) GCC error:  |
| in decompose_multiword_subregs, at lower-subreg.c:1262   |
| Error detected around a-strunb.adb:360:8 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
a-strunb.adb
a-strunb.ads
a-string.ads
ada.ads
a-strmap.ads
a-charac.ads
a-chlat1.ads
a-finali.ads
s-finroo.ads
a-stream.ads
a-unccon.ads
a-strfix.ads
a-strsea.ads
a-uncdea.ads
s-stalib.ads
s-exctab.ads
s-unstyp.ads
a-tags.ads
s-stoele.ads
s-stoele.adb
a-except.ads
s-parame.ads
s-traent.ads
s-soflin.ads
s-stache.ads
s-secsta.ads
s-finimp.ads
s-stratt.ads
s-carun8.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
make[9]: *** [a-strunb.o] Error 1
make[9]: *** Waiting for unfinished jobs

These are the commits that were used for these builds (I pruned
those that seemed obviously unrelated):


--- trunk.prev/gcc/ChangeLog2009-10-06 02:41:20.0 -0400
+++ trunk/gcc/ChangeLog 2009-10-07 00:05:15.0 -0400
@@ -1,5 +1,109 @@
 2009-10-06  Jerry Quinn  

+   * Makefile.in (lto-wrapper): Use COMPILER and ALL_COMPILERFLAGS.
+   (lto-compress.o): Likewise.
+
+2009-10-07  Danny Smith  
+
+   PR target/41512
+   * config/i386/winnt.c (i386_pe_determine_dllexport_p): Don't propagate
+   dllexport to class members here.
+   (i386_pe_determine_dllimport_p): Only check static class data for
+   definition.
+   (i386_pe_encode_section_info): Don't recheck DECL_DLLIMPORT_P.
+   * config/i386/winnt-cxx.c (i386_pe_type_dllimport_p): Only check
+   functions for vague linkage.
+   (i386_pe_type_dllexport_p): Fix formatting.
+   (maybe_add_dllexport) New function.
+   (i386_pe_adjust_class_at_definition): Use it to propagate dllexport
+   to class members.
+   
+   2009-10-07  Ben Elliston  
+
+   * config/rs6000/a2.md: Remove duplicated lines.
+
+2009-10-06  Uros Bizjak  
+
+   * config/i386/i386.md (float2):
+   Use explicit gen_truncxfsf2 and gen_truncxfdf2 references to avoid
+   reference to nonexistent gen_truncxfxf2 function.
+
+2009-10-06  Uros Bizjak  
+
+   * config/i386/i386.md (SWI48, SDWIM, DWI): New mode iterators.
+   (DWIH, g, di, doubleint_general_operand): New mode attributes.
+   (general_operand): Handle TI mode.
+   (add3): Macroize expander from add{qi,hi,si,di,ti}3 patterns
+   using SDWIM mode iterator.
+   (*add3_doubleword): New insn_and_split pattern.  Macroize
+   pattern from *add{di,ti}3_1 patterns and corresponding splitters
+   using DWI mode iterator.
+   (add3_carry): Macroize insn from add{qi,hi,si,di}3_carry
+   patterns using SWI mode iterator.
+   (*add3_cc): Macroize insn from add{si,di}3_cc patterns
+   using SWI48 mode iterator.
+   (*add_1): Ditto from add{si,di}_1 patterns.
+   (*add_2): Ditto from add{si,di}_2 patterns.
+   (*add_3): Ditto from add{si,di}_3 patterns.
+   (*add_5): Ditto from add{si,di}_5 patterns.
+   (sub3): Macroize expander from sub{qi,hi,si,di,ti}3 patterns
+   using SDWIM mode iterator.
+   (*sub3_doubleword): New insn_and_split pattern.  Macroize
+   pattern from *sub{di,ti}3_1 patterns and corresponding splitters
+   using DWI mode iterator.
+   (sub3_carry): Macroize insn from sub{qi,hi,si,di}3_carry
+   patterns using SWI mode iterator.
+   (*sub_1): Ditto from from sub{qi,hi,si,di}_1 patterns.
+   (*sub_2): Ditto fro

Re: libjava and ada broken on x86_64

[H.J. Lu]

On Thu, Oct 8, 2009 at 6:08 AM, Diego Novillo  wrote:
> Happens while building 32 bit libjava on x86_64
>
> libtool: compile:  [ ... ] -g -O2 -D_GNU_SOURCE -m32 -MT posix.lo -MD
> -MP -MF .deps/posix.Tpo -c .../libjava/posix.cc  -fPIC -DPIC -o
> .libs/posix.o
>
> /tmp/cc60L3lJ.s: Assembler messages:
> /tmp/cc60L3lJ.s:943: Error: junk at end of line, first unrecognized
> character is `*'
> /tmp/cc60L3lJ.s:944: Error: junk at end of line, first unrecognized
> character is `*'
> /tmp/cc60L3lJ.s:945: Error: expected comma after "_ZGAN8__JArrayC1Ev"
> make[5]: *** [posix.lo] Error 1
>

It is fixed now.

> Ada also seems to be in bad shape.  Yesterday's build failed
> with:
>
> bld/./gcc/xgcc [...]   -c -g -O2 -m32 -fPIC  -W -Wall -gnatpg -m32
> a-strunb.adb -o a-strunb.o
>
> +===GNAT BUG DETECTED==+
> | 4.5.0 20091007 (experimental) (x86_64-unknown-linux-gnu) GCC error:      |
> | in decompose_multiword_subregs, at lower-subreg.c:1262                   |
> | Error detected around a-strunb.adb:360:8                                 |
> | Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
> | Use a subject line meaningful to you and us to track the bug.            |
> | Include the entire contents of this bug box in the report.               |
> | Include the exact gcc or gnatmake command that you entered.              |
> | Also include sources listed below in gnatchop format                     |
> | (concatenated together with no headers between files).                   |
> +==+
>
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).
>

This should be fixed also.


-- 
H.J.

Re: Turning off unrolling to certain loops

[Jean Christophe Beyler]

Dear all,

I've been working on a loop unrolling scheme and I have a few questions:

1) Is there an interest in having a loop unrolling scheme for GCC? I'm
working on the 4.3.2 version but can port it afterwards to the 4.5
version or any version you think is appropriate.

2) I was using a simple example:

#pragma unroll 2
for (i=0;i<6;i++)
{
printf ("Hello world\n");
}

If I do this, instead of transforming the code into :
for (i=0;i<3;i++)
{
printf ("Hello world\n");
printf ("Hello world\n");
}

as we could expect, it is transformed into:
for (i=0;i<2;i++)
{
printf ("Hello world\n");
printf ("Hello world\n");
}
for (i=0;i<2;i++)
{
printf ("Hello world\n");
}


(I am using 4.3.2 currently)

I am using the tree_unroll_loop function to perform the unrolling and
it seems to always want to keep that epilogue. Is there a reason for
this? Or is this a bug of some sorts?

It seems that because the unrolling function wants always have this epilogue.

I've moved forwards (debugging wise) on this also but will wait to
know a bit of your input. I'll be looking at how to remove this
epilogue when it is not needed.

Thanks in advance,
Jc

Re: Turning off unrolling to certain loops

[Zdenek Dvorak]

Hi,

> 2) I was using a simple example:
> 
> #pragma unroll 2
> for (i=0;i<6;i++)
> {
> printf ("Hello world\n");
> }
> 
> If I do this, instead of transforming the code into :
> for (i=0;i<3;i++)
> {
> printf ("Hello world\n");
> printf ("Hello world\n");
> }
> 
> as we could expect, it is transformed into:
> for (i=0;i<2;i++)
> {
> printf ("Hello world\n");
> printf ("Hello world\n");
> }
> for (i=0;i<2;i++)
> {
> printf ("Hello world\n");
> }
> 
> 
> (I am using 4.3.2 currently)
> 
> I am using the tree_unroll_loop function to perform the unrolling and
> it seems to always want to keep that epilogue. Is there a reason for
> this? Or is this a bug of some sorts?

such an epilogue is needed when the # of iterations is not known in the
compile time; it should be fairly easy to modify the unrolling not to
emit it when it is not necessary,

Zdenek

Re: Turning off unrolling to certain loops

[Jean Christophe Beyler]

Hi,

> such an epilogue is needed when the # of iterations is not known in the
> compile time; it should be fairly easy to modify the unrolling not to
> emit it when it is not necessary,

Agreed, that is why I was surprised to see this in my simple example.
It seems to me that the whole unrolling process has been made to, on
purpose, have this epilogue in place.

In the case where the unrolling would be perfect (ie. there would be
no epilogue), the calculation of the max bound of the unrolled version
is always done to have this epilogue (if you have 4 iterations and ask
to unroll twice, it will actually change the max bound to 3,
therefore, having one iteration of the unrolled version and 2
iterations of the original...). I am currently looking at the code of
tree_transform_and_unroll_loop to figure out how to change this and
not have an epilogue in my cases.

Jc

GCC 4.4.2 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

The first release candidate for GCC 4.4.2 is available from

  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.2-RC-20091008

and shortly its mirrors.  It has been generated from SVN revision 152546.

I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux.  Please test it and report any issues to
bugzilla.

The branch is now frozen and all checkins until after the final release
of GCC 4.4.2 require explicit RM approval.

If all goes well, I'd like to release 4.4.2 next week.

--enable-build-with-cxx bootstrap failure

[Theodore Papadopoulo]

I just tried to build gcc configuring it on x86_64-unknown-linux-gnu 
(Fedora 10) with:


configure --enable-build-with-cxx --with-arch=core2 --with-tune=core2 
--prefix=/usr/local/gcc-svn/ --enable-languages="c,c++" 
--enable-__cxa_atexit --disable-multilib --enable-libssp


and ran into a bootstrap comparison failure...
Same code without --enable-build-with-cxx seems fine.

This is from trunk, rev 145701. Is this known, or should I file a bug 
report...


By the way, it seems that libelf in fedora 10 seems to be good enough 
for lto (test are tried and passing with the non-cxx bootstrap).


 Theo.

Here is the relevant part of the bootstrap failure:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/vec.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/debug.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/debug.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/system_error.o differs
make[2]: *** [compare] Error 1

Re: --enable-build-with-cxx bootstrap failure

[Dmitry Gorbachev]

> Is this known, or should I file a bug report...

It looks like .

gcc-4.5-20091008 is now available

[gccadmin]

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

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

You'll find:

gcc-4.5-20091008.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20091008.tar.bz2 C front end and core compiler

gcc-ada-4.5-20091008.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20091008.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20091008.tar.bz2  C++ front end and runtime

gcc-java-4.5-20091008.tar.bz2 Java front end and runtime

gcc-objc-4.5-20091008.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20091008.tar.bz2The GCC testsuite

Diffs from 4.5-20091001 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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.