Bug 29639 - [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
Summary: [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Eric Botcazou
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-29 23:54 UTC by Paolo Carlini
Modified: 2006-12-21 22:13 UTC (History)
4 users (show)

See Also:
Host:
Target: sh4-unknown-linux, i686-pc-linux
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-10-30 14:50:31


Attachments
auto-host.h file from FC6 gcc build directory (5.64 KB, text/plain)
2006-11-06 22:03 UTC, Benjamin Kosnik
Details
Linker fix for !HAVE_COMDAT_GROUP breakage (997 bytes, patch)
2006-11-09 12:34 UTC, Eric Botcazou
Details | Diff
Revised linker fix. (1.00 KB, patch)
2006-11-12 22:08 UTC, Eric Botcazou
Details | Diff
File. (281 bytes, patch)
2006-12-09 19:34 UTC, John David Anglin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paolo Carlini 2006-10-29 23:54:52 UTC
Between 2006-10-28 and 2006-10-29 a regression appeared on at least some targets:

   http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01448.html
   http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg01450.html

On i686-pc-linux-gnu, I'm seeing it only at -O1 or above, and goes like this:

#0  parse_lsda_header (context=0xbf80ae54, p=0x90 <Address 0x90 out of bounds>, info=0xbf80ad30)
    at ../../../../trunk/libstdc++-v3/libsupc++/eh_personality.cc:65
#1  0xb7ebf1e2 in __gxx_personality_v0 (version=1, actions=1, exception_class=5138137972254386944,
    ue_header=0x804a038, context=0xbf80ae54)
    at ../../../../trunk/libstdc++-v3/libsupc++/eh_personality.cc:435
#2  0xb7dd18d1 in _Unwind_RaiseException (exc=0x804a038) at ../../trunk/gcc/unwind.inc:117
#3  0xb7ebf71d in __cxa_throw (obj=0x804a058, tinfo=0xb7eec494, dest=0xb7ebfb70 <~bad_alloc>)
    at ../../../../trunk/libstdc++-v3/libsupc++/eh_throw.cc:71
#4  0xb7e53fb5 in std::__throw_bad_alloc () at ../../../../trunk/libstdc++-v3/src/functexcept.cc:52
#5  0x0804897c in __gnu_test::check_allocate_max_size<__gnu_cxx::bitmap_allocator<int> > ()
    at /home/paolo/Gcc/svn-dirs/trunk-build/i686-pc-linux-gnu/libstdc++-v3/include/ext/bitmap_allocator.h:1050
#6  0x080489cc in main ()
    at /home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/ext/bitmap_allocator/check_allocate_max_size.cc:30
Comment 1 Andrew Pinski 2006-10-30 00:02:40 UTC
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

Hmm, I bet this is really a binutils bug.
Comment 2 Paolo Carlini 2006-10-30 00:08:44 UTC
(In reply to comment #1)
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html

Are you sure this *2004* patch is relevant?
 
> Hmm, I bet this is really a binutils bug.

I'm seeing the problem with a stock 2.17, if nobody beats me I will try something else...

Comment 3 Andrew Pinski 2006-10-30 00:21:49 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01768.html
> 
> Are you sure this *2004* patch is relevant?
> 

Yes since it just went in during the time frame you mentioned:
2006-10-28  Eric Botcazou  <ebotcazou@adacore.com>

        * except.h (output_function_exception_table): Add 'const char*' param.
        * except.c (switch_to_exception_section): Add 'const char*' param.
        If named sections are supported and HAVE_LD_EH_GC_SECTIONS is defined
        and flag_function_sections is set, use a function-specific section.
        (output_function_exception_table): Add 'const char*' param.
        Adjust call to switch_to_exception_section.
        * final.c (rest_of_handle_final): Adjust calls to
        output_function_exception_table.
        * configure.ac (HAVE_LD_EH_GC_SECTIONS): New check.
        * config.in: Regenerate.
        * configure: Likewise.

Comment 4 Paolo Carlini 2006-10-30 00:27:01 UTC
(In reply to comment #3)
> > Are you sure this *2004* patch is relevant?
> > 
> 
> Yes since it just went in during the time frame you mentioned:
> 2006-10-28  Eric Botcazou  <ebotcazou@adacore.com>

Crazy. Ok, thanks, let's add Eric in CC, then.
Comment 5 Eric Botcazou 2006-10-30 09:57:01 UTC
What is the command line to run only one test in the libstdc++ testsuite?
Comment 6 Paolo Carlini 2006-10-30 11:48:26 UTC
(In reply to comment #5)
> What is the command line to run only one test in the libstdc++ testsuite?

I'm reluctant to tell you in public, because certainly there are *far* better ways, but was I usually do when I'm in a hurry, I simply go inside the libstdc++-v3/testsuite directory, set the LD_LIBRARY_PATH and then copy & paste the complete command line from the ChangeLog.
Comment 7 Paolo Carlini 2006-10-30 11:52:56 UTC
(In reply to comment #6)
> ... the complete command line from the ChangeLog.

Of course read it 'libstdc++.log', sorry.

Comment 8 Eric Botcazou 2006-10-30 12:02:02 UTC
> I'm reluctant to tell you in public, because certainly there are *far* better
> ways, but was I usually do when I'm in a hurry, I simply go inside the
> libstdc++-v3/testsuite directory, set the LD_LIBRARY_PATH and then copy & paste
> the complete command line from the ChangeLog.

The idea was precisely to avoid running the whole testsuite. :-)
Comment 9 Paolo Carlini 2006-10-30 12:05:08 UTC
(In reply to comment #8)
> The idea was precisely to avoid running the whole testsuite. :-)

Oh, well, once in a while you *must* di that, right? ;) Just save somewhere libstdc++.log...

Comment 10 Eric Botcazou 2006-10-30 14:49:59 UTC
> Oh, well, once in a while you *must* di that, right? ;)

Only under duress. :-)  Bug confirmed with Binutils 2.17 20061003 on x86.
Comment 11 Eric Botcazou 2006-10-30 14:50:31 UTC
Investigating.
Comment 12 Paolo Carlini 2006-10-30 14:53:34 UTC
Thanks Eric.
Comment 13 Benjamin Kosnik 2006-11-01 12:11:18 UTC
Eric, what I usually do is:

cd $build/libstdc++-v3/testsuite;
make testsuite_files

Then, edit out the file "testsuite_files" to the actual file or files that you want to test.

Then, just type 'make check."

This will run the testsuite as per usual, just on a select group of files. Once you've got that, then you can just cut and paste from the generated libstdc++.log file if you are trying to compile just one testsuite.

-benjamin
Comment 14 Eric Botcazou 2006-11-01 12:14:13 UTC
> cd $build/libstdc++-v3/testsuite;
> make testsuite_files
> 
> Then, edit out the file "testsuite_files" to the actual file or files that you
> want to test.
> 
> Then, just type 'make check."

Neat.  Thanks!
Comment 15 Eric Botcazou 2006-11-02 10:25:42 UTC
> Yes since it just went in during the time frame you mentioned:
> 2006-10-28  Eric Botcazou  <ebotcazou@adacore.com>

My bad.  Patch crossing with Richard S. section anchor stuff.  Testing fix.
Comment 16 Eric Botcazou 2006-11-02 18:41:05 UTC
Subject: Bug 29639

Author: ebotcazou
Date: Thu Nov  2 18:40:54 2006
New Revision: 118422

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118422
Log:
	PR other/29639
	* except.c (switch_to_exception_section): Do not cache the section
	if named sections are supported and HAVE_LD_EH_GC_SECTIONS is defined
	and flag_function_sections is set.


Added:
    trunk/gcc/testsuite/g++.dg/eh/gcsec1.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/except.c
    trunk/gcc/testsuite/ChangeLog

Comment 17 Eric Botcazou 2006-11-02 18:44:16 UTC
Should work now.
Comment 18 Paolo Carlini 2006-11-03 00:29:13 UTC
Thanks again for the quick fix.
Comment 19 Benjamin Kosnik 2006-11-03 10:46:29 UTC
Is this actually fixed?

Here are my current testresults:
http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00094.html

Still shows breakage on FC6. Sorry, hardware constrained at the moment and don't have other linuxes around as per usual. Backtraces now of the form:

Program received signal SIGABRT, Aborted.
0x007e8402 in __kernel_vsyscall ()
(gdb) where
#0  0x007e8402 in __kernel_vsyscall ()
#1  0x00befd40 in raise () from /lib/libc.so.6
#2  0x00bf1591 in abort () from /lib/libc.so.6
#3  0x001c2d57 in base_of_encoded_value (encoding=<value optimized out>, 
    context=0x6) at /mnt/share/src/gcc/libstdc++-v3/../gcc/unwind-pe.h:122
#4  0x001c2ded in parse_lsda_header (context=0xbfa272f4, 
    p=0x110001 "ELF\001\001\001", info=0xbfa271d0)
    at /mnt/share/src/gcc/libstdc++-v3/../gcc/unwind-pe.h:286
#5  0x001c30f2 in __gxx_personality_v0 (version=1, actions=1, 
    exception_class=5138137972254386944, ue_header=0x8504038, 
    context=0xbfa272f4)
    at /mnt/share/src/gcc/libstdc++-v3/libsupc++/eh_personality.cc:435
#6  0x00d90b51 in _Unwind_RaiseException (exc=0x8504038)
    at /mnt/share/src/gcc/gcc/unwind.inc:117
#7  0x001c362d in __cxa_throw (obj=0x8504058, tinfo=0x804a990, dest=0)
    at /mnt/share/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:71
#8  0x08049186 in Buf::overflow (this=0xbfa2756c)
    at /mnt/share/src/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/write/char/1.cc:40
#9  0x0019cfdb in std::basic_streambuf<char, std::char_traits<char> >::xsputn
    (this=0xbfa2756c, __s=0x804957c "a", __n=1)
    at /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/bits/streambuf.tcc:102
#10 0x00193ad1 in std::ostream::write (this=0xbfa274e0, __s=0x804957c "a", 
    __n=1)
    at /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/streambuf:447
#11 0x08049272 in test01 ()
    at /mnt/share/src/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/write/char/1.cc:52
#12 0x08049426 in main ()
    at /mnt/share/src/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/write/char/1.cc:72
Comment 20 Paolo Carlini 2006-11-03 11:28:07 UTC
I can confirm that this specific regression disappeared for me. But I suspect something also depends on the binutils version and other details, I'm using a stock 2.17 on this machine...
Comment 21 Eric Botcazou 2006-11-03 11:58:21 UTC
> Is this actually fixed?

It is on my system, either x86_64-suse-linux -m64/-m32 or i586-suse-linux,
with binutils 2.17.

> Here are my current testresults:
> http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00094.html

Ouch!

> Still shows breakage on FC6.

Which version of binutils?
Comment 22 Benjamin Kosnik 2006-11-04 09:29:29 UTC
ld --version
GNU ld version 2.17.50.0.3-6 20060715


But, I also tried this with --hash-style=sysv, and got the same results. I'll try to figure out what's going on.
Comment 23 Eric Botcazou 2006-11-04 20:16:55 UTC
> ld --version
> GNU ld version 2.17.50.0.3-6 20060715

I cannot reproduce with binutils mainline:
eric@linux:~/build/binutils/native32> ld/ld-new --version
GNU ld version 2.17.50 20061104

How are binutils configured?  Does FC6 use local patches?
Comment 24 John David Anglin 2006-11-05 19:34:02 UTC
I'm seeing similar problems on hppa-linux.  See PR 29661 for mor details.
There are some others as well that are probably dups.
Comment 25 Eric Botcazou 2006-11-05 20:03:48 UTC
> I'm seeing similar problems on hppa-linux.  See PR 29661 for mor details.
> There are some others as well that are probably dups.

With some exotic version of binutils too? :-)
Comment 26 dave 2006-11-05 20:15:00 UTC
Subject: Re:  [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

> With some exotic version of binutils too? :-)

When I first hit the problem, I was using a build from last June.
I updated when it was suggested that this might be a binutils
problem.  I'm now using:

dave@hiauly6:~/gnu/gcc-4.3/objdir/gcc/testsuite/g++$ ld --version
GNU ld version 2.17.50 20061031

It's stock.

Dave
Comment 27 Eric Botcazou 2006-11-05 21:32:10 UTC
> dave@hiauly6:~/gnu/gcc-4.3/objdir/gcc/testsuite/g++$ ld --version
> GNU ld version 2.17.50 20061031

OK, thanks.  I'll try harder to reproduce on x86/Linux.
Comment 28 Eric Botcazou 2006-11-06 12:25:52 UTC
> OK, thanks.  I'll try harder to reproduce on x86/Linux.

This is getting annoying.  I've built a first C++ compiler --with-as --with-ld
set to the new binutils, installed it, then built a second C++ compiler using
the first one to factor out configure quirks, but to no avail.

Benjamin, could you attach your gcc/auto-host.h file from FC6?
Comment 29 Benjamin Kosnik 2006-11-06 22:03:15 UTC
Created attachment 12555 [details]
auto-host.h file from FC6 gcc build directory


Here you go Eric.
Comment 30 Benjamin Kosnik 2006-11-06 22:05:52 UTC
Since this is also new hardware for me, I'll try a couple of other things to try and isolate. Note that gcc-4_2-branch is working perfectly for me, so I have switched over to that for work as a temporary measure so I can get things done. This makes me think that it's not a distro-specific issue, or a hardware specific issue, or a binutils specific issue, but most likely a gcc-specific issue.

Things I'll try tomorrow:
1) disabling PCH
2) the usual PIE/SELinux disabling switcheroos

-benjamin
Comment 31 Eric Botcazou 2006-11-06 22:14:53 UTC
> Here you go Eric.

Thanks.  Why are COMDAT groups disabled in your compiler?

 /* Define 0/1 if your assembler and linker support COMDAT groups. */
 #ifndef USED_FOR_TARGET
-#define HAVE_COMDAT_GROUP 0
+#define HAVE_COMDAT_GROUP 1
 #endif
Comment 32 Benjamin Kosnik 2006-11-06 23:50:25 UTC
Dunno. However, this bit is the same for gcc and gcc-4_2-branch on my system.

There are, however, other differences between the gcc and gcc-4_2-branch files:

%diff gcc/auto-host.h ../gcc-4_2-branch/gcc/auto-host.h
*** gcc/auto-host.h     2006-11-06 09:23:47.000000000 +0100
--- ../gcc-4_2-branch/gcc/auto-host.h   2006-11-05 12:00:38.000000000 +0100
***************
*** 204,216 ****
  #endif
  
  
- /* Define if your assembler supports the subtraction of symbols in different
-    sections. */
- #ifndef USED_FOR_TARGET
- #define HAVE_AS_IX86_DIFF_SECT_DELTA 1
- #endif
- 
- 
  /* Define if your assembler supports the ffreep mnemonic. */
  #ifndef USED_FOR_TARGET
  #define HAVE_AS_IX86_FFREEP 1
--- 204,209 ----
***************
*** 241,264 ****
  #endif
  
  
- /* Define if your assembler supports mffgpr and mftgpr. */
- #ifndef USED_FOR_TARGET
- /* #undef HAVE_AS_MFPGPR */
- #endif
- 
- 
  /* Define if your assembler supports the -no-mul-bug-abort option. */
  #ifndef USED_FOR_TARGET
  /* #undef HAVE_AS_NO_MUL_BUG_ABORT_OPTION */
  #endif
  
  
- /* Define if the assembler understands -mno-shared. */
- #ifndef USED_FOR_TARGET
- /* #undef HAVE_AS_NO_SHARED */
- #endif
- 
- 
  /* Define if your assembler supports offsetable %lo(). */
  #ifndef USED_FOR_TARGET
  /* #undef HAVE_AS_OFFSETABLE_LO10 */
--- 234,245 ----
***************
*** 903,915 ****
  /* Define if your linker supports --eh-frame-hdr option. */
  #define HAVE_LD_EH_FRAME_HDR 1
  
- /* Define if your linker supports garbage collection of sections in presence
-    of EH frames. */
- #ifndef USED_FOR_TARGET
- #define HAVE_LD_EH_GC_SECTIONS 1
- #endif
- 
- 
  /* Define if your PowerPC64 linker only needs function descriptor syms. */
  #ifndef USED_FOR_TARGET
  /* #undef HAVE_LD_NO_DOT_SYMS */
--- 884,889 ----
***************
*** 1280,1286 ****
  
  /* Define to PREFIX/include if cpp should also search that directory. */
  #ifndef USED_FOR_TARGET
! #define PREFIX_INCLUDE_DIR "/mnt/share/bld/H-x86-gcc/include"
  #endif
  
  
--- 1254,1260 ----
  
  /* Define to PREFIX/include if cpp should also search that directory. */
  #ifndef USED_FOR_TARGET
! #define PREFIX_INCLUDE_DIR "/mnt/share/bld/H-x86-gcc-4_2-branch/include"
  #endif
  
  
Comment 33 Eric Botcazou 2006-11-07 00:04:34 UTC
> Dunno. However, this bit is the same for gcc and gcc-4_2-branch on my system.

Weird.  COMDAT groups are not supposed to be disabled on Linux I think.

Dave, are they also disabled on yours?  If so, what compiler do you use to
compile your binutils?

> There are, however, other differences between the gcc and gcc-4_2-branch files:

Right, but the only significant difference with my compiler is the disabling
of COMDAT groups on yours.
Comment 34 dave 2006-11-07 02:08:38 UTC
Subject: Re:  [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

> Weird.  COMDAT groups are not supposed to be disabled on Linux I think.
> 
> Dave, are they also disabled on yours?  If so, what compiler do you use to

No.

> compile your binutils?

In on case I used 4.1.1 and the other 3.3.4.  Both exhibit the same
behavior.

From the debugging that I did, it looked as if there's a problem with
the LSDA data.  This causes the encoding error.

Dave
Comment 35 Benjamin Kosnik 2006-11-07 10:03:28 UTC
PCH makes no difference. Same bugs with and without.
Comment 36 Jakub Jelinek 2006-11-07 13:10:35 UTC
HAVE_COMDAT_GROUP is 0 because the ld version parser is too strict for Fedora Core 6 ld --version, see
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00398.html
Comment 37 Benjamin Kosnik 2006-11-07 15:27:29 UTC
A ha! With Jakub's patch in everything is now ok with me.

thanks.

-benjamin
Comment 38 Eric Botcazou 2006-11-07 17:17:44 UTC
> A ha! With Jakub's patch in everything is now ok with me.

Do you mean that the C++ EH failures are gone?  If so, it looks like my patch
badly interacts with some C++ idioms.  Investigating...
Comment 39 Eric Botcazou 2006-11-07 17:42:31 UTC
> Do you mean that the C++ EH failures are gone?  If so, it looks like my patch
> badly interacts with some C++ idioms.  Investigating...

Ok, that's it, if I disable COMDAT groups, I get the failures on x86/Linux.

Dave, do you have the latest sources of the compiler?  I've already installed
a first fix for this PR.
Comment 40 dave 2006-11-07 18:26:57 UTC
Subject: Re:  [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

> > Do you mean that the C++ EH failures are gone?  If so, it looks like my patch
> > badly interacts with some C++ idioms.  Investigating...
> 
> Ok, that's it, if I disable COMDAT groups, I get the failures on x86/Linux.
> 
> Dave, do you have the latest sources of the compiler?  I've already installed
> a first fix for this PR.

I started two builds yesterday.  I'll start another set this evenings.

From the above, it sounds as if COMDAT groups are broken on hppa/Linux.
That's not totally surprising given that the handling of some relocations
is tricky.

Dave
Comment 41 Benjamin Kosnik 2006-11-08 11:34:17 UTC
Hey Eric. Yes, it looks like I'm all ok (test results are perfect) as long as HAVE_COMDAT_GROUP is defined, but screwed if it isn't. Although I'm ok now, it does seem as if something may be wrong in one of the code paths, as things should still work without comdat groups, no?

It looks like you are able to reproduce now, so that's good.

Thanks for your help!
Comment 42 Eric Botcazou 2006-11-08 11:41:15 UTC
> Hey Eric. Yes, it looks like I'm all ok (test results are perfect) as long
> as HAVE_COMDAT_GROUP is defined, but screwed if it isn't. Although I'm ok
> now, it does seem as if something may be wrong in one of the code paths, as
> things should still work without comdat groups, no?

Yes, I'm investigating.  Ultimately I could always resort to conditionalizing
my change on HAVE_COMDAT_GROUP, but that would be more of a kludge.

> Thanks for your help!

Thanks for your patience. :-)
Comment 43 dave 2006-11-08 22:16:31 UTC
Subject: Re:  [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

> Yes, I'm investigating.  Ultimately I could always resort to conditionalizing
> my change on HAVE_COMDAT_GROUP, but that would be more of a kludge.

Things are still broken on hppa-linux.

Dave
Comment 44 Eric Botcazou 2006-11-09 12:33:04 UTC
> Things are still broken on hppa-linux.

I have a fix (in the linker) for the !HAVE_COMDAT_GROUP breakage on x86 but
it is probably not sufficient on hppa.  Could you try it anyway?  Just relink
the libstdc++.so shared object with the patched linker.  Thanks in advance.
Comment 45 Eric Botcazou 2006-11-09 12:34:47 UTC
Created attachment 12575 [details]
Linker fix for !HAVE_COMDAT_GROUP breakage

Successfully tested on x86.
Comment 46 Christian Joensson 2006-11-10 09:08:19 UTC
(In reply to comment #45)
> Created an attachment (id=12575) [edit]
> Linker fix for !HAVE_COMDAT_GROUP breakage
> 
> Successfully tested on x86.
> 

hmm, this could be brought into binutils' dev repo, right?
Comment 47 dave 2006-11-10 15:23:20 UTC
Subject: Re:  [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

> > Things are still broken on hppa-linux.
> 
> I have a fix (in the linker) for the !HAVE_COMDAT_GROUP breakage on x86 but
> it is probably not sufficient on hppa.  Could you try it anyway?  Just relink
> the libstdc++.so shared object with the patched linker.  Thanks in advance.

Still broken.  I should turn off HAVE_COMDAT_GROUP and see if that
helps.

Dave
Comment 48 Eric Botcazou 2006-11-12 22:06:04 UTC
> Still broken.  I should turn off HAVE_COMDAT_GROUP and see if that helps.

Does hppa-linux use non-standard text sections?  Revised patch to be attached.
Comment 49 Eric Botcazou 2006-11-12 22:08:06 UTC
Created attachment 12600 [details]
Revised linker fix.

Lightly tested on x86.
Comment 50 dave 2006-11-13 02:01:19 UTC
Subject: Re:  [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

> > Still broken.  I should turn off HAVE_COMDAT_GROUP and see if that helps.
> 
> Does hppa-linux use non-standard text sections?  Revised patch to be attached.

I'm not sure what you mean by "non-standard".  There's nothing non
standard about the names.  However, there are some special issues.

I don't believe that it's possible to switch out of the text for any
given function and back in.  This is definitely not possible under hpux.
For this reason, we don't support hot and cold text.  Switching out
of the text section would affect the calculation of branch distances
and possibly affect the placement of the stub tables used to convert
short pc-relative branches to long branches.

The EH tables use an indirect pc-relative encoding for global and
function pointers.  This avoids having any dynamic relocations in
the EH data, but there has to be a fixed relationship between text
and data in dynamic objects for this to work.

The PA handling of function pointers is also somewhat unique and
based on the original hpux implementation.

Thanks for the patch update.  I'll give it a try.  Unfortunately,
I didn't have time this weekend to work on this.

Dave
Comment 51 John David Anglin 2006-12-09 19:34:06 UTC
Created attachment 12775 [details]
File.

The errors go away if I disable HAVE_LD_EH_GC_SECTIONS.

I think this feature exposes a binutils in handling pc-relative
relocations when this feature is enabled.  In particulary, it
appears the offset to the lsda data is wrong.
Comment 52 Eric Botcazou 2006-12-09 19:48:52 UTC
> The errors go away if I disable HAVE_LD_EH_GC_SECTIONS.

Sure, see comment #3.

> I think this feature exposes a binutils in handling pc-relative
> relocations when this feature is enabled.  In particulary, it
> appears the offset to the lsda data is wrong.

OK.  Then I'll submit the binutils patch for !HAVE_COMDAT_GROUP and tweak the
configury so as to enable the feature only with a fixed linker and not on PA.

Thanks for the patch and your help.
Comment 53 Eric Botcazou 2006-12-21 22:10:42 UTC
Subject: Bug 29639

Author: ebotcazou
Date: Thu Dec 21 22:10:30 2006
New Revision: 120121

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120121
Log:
	PR other/29639
	* configure.ac (HAVE_LD_EH_GC_SECTIONS): Check that exception tables
	are kept for .gnu.linkonce.t sections if COMDAT groups are disabled.
	* configure: Regenerate.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/configure
    trunk/gcc/configure.ac

Comment 54 Eric Botcazou 2006-12-21 22:13:54 UTC
Hopefully everywhere.