Re: BITS_PER_UNIT larger than 8 -- word addressing

[Richard Sandiford]

Michael Eager <[EMAIL PROTECTED]> writes:
> Ross Ridge wrote:
>> Miceal Eagar writes:
>>> I'm working with a target that has 32-bit word addressing,
>>> so there is a define of BITS_PER_UNIT = 32.
>> 
>> According to the documentation, this changes the size of a byte to 32
>> bits, instead of the more usual 8 bits.
>> 
>>> This causes a problem:  an error saying that there is
>>> no emulation for 'DI'.  DImode has a precision of 128 bits,
>>> which is clearly incorrect.  (All the other integer modes
>>> were incorrect as well.)
>> 
>> DImode is defined to be 8 bytes long so with a 32-bit byte I'd expect
>> it to be 256 bits.  Trying use QImode and HImode for 32-bit and 64-bit
>> operations respectively.
>
> Well, can't do that.  This is not target dependent.
> DImode gets defined, and used, for long long in unwind-dw2.c.

But like Ross says, DImode is 256 bits, so its unwind-dw2.c that
needs to change.

(FWIW, I remember testing c4x for some pan-target changes after it was
slated for removal, and I just disabled the unwinding stuff.  Most other
things seemed to work fine.)

Richard

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Jie Zhang wrote:
> Bernd Schmidt wrote:
>> Jie Zhang wrote:
>>> Bernd Schmidt wrote:
 Jie Zhang wrote:
> But by design if gcc_no_link = no, link tests should be avoided.

 ??? I would have thought gcc_no_link = yes means link tests are
 avoided.

>>> Oops, I meant gcc_no_link = yes.
>>
>> Stupid double negatives.  Okay, so then your problem is that
>> gcc_no_link=yes.  Find out why it's setting that.
>>
> bfin-elf-gcc -mfdpic failed to link a simple test case because code is
> put into L1 instruction sram and data is put into L1 data sram, but
> Blackfin immediate offset load instruction cannot access GOT since the
> gap between instruction sram and data sram is too large. Using -msim as
> default will pass this test case and build gcc without problem but I
> would like bfin-elf-gcc target hardware board by default. Use -fPIC as
> default is not good, since -fpic is enough for any real applications. So
> I would like to avoid link test for shl_load when GCC_NO_EXECUTABLES.

I've committed the following to take care of this.  Neither -mfdpic nor
-mid-shared-library are actually useful with bfin-elf toolchains, but by
making them imply -msim, we can at least get these kinds of configure
test executables to link.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Index: ChangeLog
===
--- ChangeLog	(revision 130463)
+++ ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2007-11-27  Bernd Schmidt  <[EMAIL PROTECTED]>
+
+	* config/bfin/elf.h (SUBTARGET_DRIVER_SELF_SPECS): New macro.
+	* doc/invoke.texi (Blackfin Options): Document the effects.
+
 2007-11-27  Ben Elliston  <[EMAIL PROTECTED]>
 
 	* config/rs6000/sysv4.opt (m32): Add Negative(m64).
Index: config/bfin/elf.h
===
--- config/bfin/elf.h	(revision 130463)
+++ config/bfin/elf.h	(working copy)
@@ -30,4 +30,8 @@ asm ("P3 = [SP + 20];\n\tcall " USER_LAB
 asm (TEXT_SECTION_ASM_OP);
 #endif
 
+#undef SUBTARGET_DRIVER_SELF_SPECS
+#define SUBTARGET_DRIVER_SELF_SPECS \
+ "%{mfdpic:-msim} %{mid-shared-library:-msim}"
+
 #define NO_IMPLICIT_EXTERN_C
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 130463)
+++ doc/invoke.texi	(working copy)
@@ -8668,6 +8668,8 @@ provided by libgloss to be linked in if 
 Specifies that the program will be run on the simulator.  This causes
 the simulator BSP provided by libgloss to be linked in.  This option
 has effect only for @samp{bfin-elf} toolchain.
+Certain other options, such as @option{-mid-shared-library} and
[EMAIL PROTECTED], imply @option{-msim}.
 
 @item -momit-leaf-frame-pointer
 @opindex momit-leaf-frame-pointer
@@ -8717,6 +8719,7 @@ uClinux kernel.
 Generate code that supports shared libraries via the library ID method.
 This allows for execute in place and shared libraries in an environment
 without virtual memory management.  This option implies @option{-fPIC}.
+With a @samp{bfin-elf} target, this option implies @option{-msim}.
 
 @item -mno-id-shared-library
 @opindex mno-id-shared-library
@@ -9642,6 +9645,7 @@ implies @option{-fPIE}.  With @option{-f
 assumes GOT entries and small data are within a 12-bit range from the
 GOT base address; with @option{-fPIC} or @option{-fPIE}, GOT offsets
 are computed with 32 bits.
+With a @samp{bfin-elf} target, this option implies @option{-msim}.
 
 @item -minline-plt
 @opindex minline-plt

Re: gcc 4.2.2, libgomp under cygwin

[Joerg Frochte]

Hi,

2007/11/27, Brian Dessent <[EMAIL PROTECTED]>:

> Cygwin is not a target where libgomp is enabled by default, though it
> probably should be since it strives for POSIX.  You have to
> --enable-libgomp explicitly if you want to build it.

Thanks. Now it works.
Joerg


-- 
http://www.joerg.frochte.de/en/

Re: [Fwd: performance with gcc -O0/-O2]

[Richard Guenther]

On Nov 27, 2007 2:23 PM, Howard Chu <[EMAIL PROTECTED]> wrote:
> A bit of a minor mystery. Not a problem, just a curiosity. If someone knew off
> the top of their head a reason for it, that'd be cool, but otherwise no sweat.

I'd try -Os, you might run into ICache limitations.

Richard.

>  Original Message 
> Subject: Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h
> syncrepl.c
> Date: Tue, 27 Nov 2007 05:17:04 -0800
> From: Howard Chu <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
> Howard Chu wrote:
> > Howard Chu wrote:
> >> Howard Chu wrote:
> >>> For reference, the peak throughput with back-null on the previous code was
> >>> only 7,800 auths/sec (with 8 client threads). With this patch it's 11,140
> >>> auths/sec.
>
> Those numbers are for Windows Server 2003 x86_64 on a Celestica A8440 with 4
> Opteron 875s, using OpenLDAP compiled with gcc 4.3.0. The following numbers
> are for Linux 2.6.23.1 x86_64, on the same machine, compiled first with gcc
> 4.1.2 and then later with gcc 4.2.2. There's no disk I/O in these tests.
>
> >>> In both cases the throughput declines as more client threads are
> >>> used. (Compare to 35,553 auths/sec for the same machine running Linux, 
> >>> and no
> >>> drop in throughput all the way up to hundreds/thousands of connections.)
>
> > Re-running on Linux with a non-optimized build, peaked at 40,101 auths/sec. 
> > (I
> > guess HEAD has sped up a bit more in the past week or so...)
>
> OK, this is odd. The code compiled without optimization peaks at 40K auths/sec
> at around 124-132 client threads. The code compiled with -O2 peaks at 37K sec
> at around 128 client threads.
>
> The -O2 build is faster from about 4 to 24 client threads. From 28 on up, the
> nonoptimized code is faster at every load level. I was originally using gcc
> 4.1.2 but I'm seeing the same result now using gcc 4.2.2. Also, slapd is only
> configured with 8 worker threads in all of these tests. Strange that whatever
> optimizations the compiler has generated speeds things up for lighter load,
> but works against it under heavier load.
> --
>-- Howard Chu
>Chief Architect, Symas Corp.  http://www.symas.com
>Director, Highland Sunhttp://highlandsun.com/hyc/
>Chief Architect, OpenLDAP http://www.openldap.org/project/
>

[Fwd: performance with gcc -O0/-O2]

[Howard Chu]

A bit of a minor mystery. Not a problem, just a curiosity. If someone knew off 
the top of their head a reason for it, that'd be cool, but otherwise no sweat.


 Original Message 
Subject: Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h 
syncrepl.c

Date: Tue, 27 Nov 2007 05:17:04 -0800
From: Howard Chu <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>	<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>


Howard Chu wrote:

Howard Chu wrote:

Howard Chu wrote:

For reference, the peak throughput with back-null on the previous code was
only 7,800 auths/sec (with 8 client threads). With this patch it's 11,140
auths/sec.


Those numbers are for Windows Server 2003 x86_64 on a Celestica A8440 with 4 
Opteron 875s, using OpenLDAP compiled with gcc 4.3.0. The following numbers 
are for Linux 2.6.23.1 x86_64, on the same machine, compiled first with gcc 
4.1.2 and then later with gcc 4.2.2. There's no disk I/O in these tests.



In both cases the throughput declines as more client threads are
used. (Compare to 35,553 auths/sec for the same machine running Linux, and no
drop in throughput all the way up to hundreds/thousands of connections.)



Re-running on Linux with a non-optimized build, peaked at 40,101 auths/sec. (I
guess HEAD has sped up a bit more in the past week or so...)


OK, this is odd. The code compiled without optimization peaks at 40K auths/sec
at around 124-132 client threads. The code compiled with -O2 peaks at 37K sec
at around 128 client threads.

The -O2 build is faster from about 4 to 24 client threads. From 28 on up, the
nonoptimized code is faster at every load level. I was originally using gcc
4.1.2 but I'm seeing the same result now using gcc 4.2.2. Also, slapd is only
configured with 8 worker threads in all of these tests. Strange that whatever
optimizations the compiler has generated speeds things up for lighter load,
but works against it under heavier load.
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: Scripted pass manager

[Basile STARYNKEVITCH]

Richard Guenther wrote:


With a "scripted pass manager" I of course ment a pass manager that
allows re-configuration of the pass pipeline without re-compiling.  For
example by embeding LUA (or another tiny scripting language).  


Regarding such configurability of the pass manager the GCC ICI project 
might be interesting:

http://gcc-ici.sourceforge.net/


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: [Fwd: performance with gcc -O0/-O2]

[Andrew Haley]

Howard Chu writes:

 > A bit of a minor mystery. Not a problem, just a curiosity. If
 > someone knew off the top of their head a reason for it, that'd be
 > cool, but otherwise no sweat.

It's possible, although unlikley, that the optimized code has worse
cache behaviour.  No way to know better without doing some profiling.

Andrew.


 > 
 >  Original Message 
 > Subject: Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h 
 > syncrepl.c
 > Date: Tue, 27 Nov 2007 05:17:04 -0800
 > From: Howard Chu <[EMAIL PROTECTED]>
 > To: [EMAIL PROTECTED]
 > References: <[EMAIL PROTECTED]> 
 > <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> 
 > <[EMAIL PROTECTED]>
 > 
 > Howard Chu wrote:
 > > Howard Chu wrote:
 > >> Howard Chu wrote:
 > >>> For reference, the peak throughput with back-null on the previous code 
 > >>> was
 > >>> only 7,800 auths/sec (with 8 client threads). With this patch it's 11,140
 > >>> auths/sec.
 > 
 > Those numbers are for Windows Server 2003 x86_64 on a Celestica A8440 with 4 
 > Opteron 875s, using OpenLDAP compiled with gcc 4.3.0. The following numbers 
 > are for Linux 2.6.23.1 x86_64, on the same machine, compiled first with gcc 
 > 4.1.2 and then later with gcc 4.2.2. There's no disk I/O in these tests.
 > 
 > >>> In both cases the throughput declines as more client threads are
 > >>> used. (Compare to 35,553 auths/sec for the same machine running Linux, 
 > >>> and no
 > >>> drop in throughput all the way up to hundreds/thousands of connections.)
 > 
 > > Re-running on Linux with a non-optimized build, peaked at 40,101 
 > > auths/sec. (I
 > > guess HEAD has sped up a bit more in the past week or so...)
 > 
 > OK, this is odd. The code compiled without optimization peaks at 40K 
 > auths/sec
 > at around 124-132 client threads. The code compiled with -O2 peaks at 37K sec
 > at around 128 client threads.
 > 
 > The -O2 build is faster from about 4 to 24 client threads. From 28 on up, the
 > nonoptimized code is faster at every load level. I was originally using gcc
 > 4.1.2 but I'm seeing the same result now using gcc 4.2.2. Also, slapd is only
 > configured with 8 worker threads in all of these tests. Strange that whatever
 > optimizations the compiler has generated speeds things up for lighter load,
 > but works against it under heavier load.
 > -- 
 >-- Howard Chu
 >Chief Architect, Symas Corp.  http://www.symas.com
 >Director, Highland Sunhttp://highlandsun.com/hyc/
 >Chief Architect, OpenLDAP http://www.openldap.org/project/

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 
1TE, UK
Registered in England and Wales No. 3798903

Re: [Fwd: performance with gcc -O0/-O2]

[J.C. Pizarro]

For your Opteron, try with this option

-O3 -fomit-frame-pointer -march=k8 -funroll-loops -finline-functions
-fpeel-loops \
-mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow

The Opteron hardware said that it's better to use SSE2 than SSE3.
The MMX and 3DNow!+ instructions are shorter and older than SSE2/SSE
instructions.

Sincerely, J.C.Pizarro

Reg: -fdump-translation-unit for "C"

[Praveen D V]

hi,
I was earlier using 3.x.x version where I used -fdump-translation-unit to dump
"typedef" tree.   Recently I upgraded to 4.1.x version, unfortunately,
that doesn't
dump the tree any more.  From documentation, it mentions it is for
"C++".  I need it
for "C".
It is a very useful utility.  Are there any other options that replace
-fdump-translation-unit?
--thanks, Praveen

Re: [Fwd: performance with gcc -O0/-O2]

[Tim Prince]

Richard Guenther wrote:
> On Nov 27, 2007 2:23 PM, Howard Chu <[EMAIL PROTECTED]> wrote:
>> A bit of a minor mystery. Not a problem, just a curiosity. If someone knew 
>> off
>> the top of their head a reason for it, that'd be cool, but otherwise no 
>> sweat.
> 
> I'd try -Os, you might run into ICache limitations.
Try -Os with and without setting -mpreferred-stack-boundary=4 (or
whatever value you currently have).  Watch memory usage, cache
evictions, etc. while running.
> 
> Richard.
> 
>>  Original Message 
>> Subject: Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h
>> syncrepl.c
>> Date: Tue, 27 Nov 2007 05:17:04 -0800
>> From: Howard Chu <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> References: <[EMAIL PROTECTED]>
>> <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
>> <[EMAIL PROTECTED]>
>>
>> Howard Chu wrote:
>>> Howard Chu wrote:
 Howard Chu wrote:
> For reference, the peak throughput with back-null on the previous code was
> only 7,800 auths/sec (with 8 client threads). With this patch it's 11,140
> auths/sec.
>> Those numbers are for Windows Server 2003 x86_64 on a Celestica A8440 with 4
>> Opteron 875s, using OpenLDAP compiled with gcc 4.3.0. The following numbers
>> are for Linux 2.6.23.1 x86_64, on the same machine, compiled first with gcc
>> 4.1.2 and then later with gcc 4.2.2. There's no disk I/O in these tests.
>>
> In both cases the throughput declines as more client threads are
> used. (Compare to 35,553 auths/sec for the same machine running Linux, 
> and no
> drop in throughput all the way up to hundreds/thousands of connections.)
>>> Re-running on Linux with a non-optimized build, peaked at 40,101 auths/sec. 
>>> (I
>>> guess HEAD has sped up a bit more in the past week or so...)
>> OK, this is odd. The code compiled without optimization peaks at 40K 
>> auths/sec
>> at around 124-132 client threads. The code compiled with -O2 peaks at 37K sec
>> at around 128 client threads.
>>
>> The -O2 build is faster from about 4 to 24 client threads. From 28 on up, the
>> nonoptimized code is faster at every load level. I was originally using gcc
>> 4.1.2 but I'm seeing the same result now using gcc 4.2.2. Also, slapd is only
>> configured with 8 worker threads in all of these tests. Strange that whatever
>> optimizations the compiler has generated speeds things up for lighter load,
>> but works against it under heavier load.
>> --
>>-- Howard Chu
>>Chief Architect, Symas Corp.  http://www.symas.com
>>Director, Highland Sunhttp://highlandsun.com/hyc/
>>Chief Architect, OpenLDAP http://www.openldap.org/project/
>>

Re: Reg: -fdump-translation-unit for "C"

[Ramana Radhakrishnan]

On Nov 27, 2007 7:42 PM, Praveen D V <[EMAIL PROTECTED]> wrote:
> hi,
> I was earlier using 3.x.x version where I used -fdump-translation-unit to dump
> "typedef" tree.   Recently I upgraded to 4.1.x version, unfortunately,
> that doesn't
> dump the tree any more.  From documentation, it mentions it is for
> "C++".  I need it
> for "C".
> It is a very useful utility.  Are there any other options that replace
> -fdump-translation-unit?

-fdump-tree-all dumps all the trees you want. What is that you are
looking for in the tree ?

And this is more a question for gcc-help@ rather than gcc@ .

cheers
Ramana


> --thanks, Praveen
>



-- 
Ramana Radhakrishnan

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Joseph S. Myers]

On Mon, 26 Nov 2007, Michael Eager wrote:

> Well, can't do that.  This is not target dependent.
> DImode gets defined, and used, for long long in unwind-dw2.c.

Is it defined what DWARF unwind information looks like when made up of 
bytes wider than 8 bits?  Certainly GCC's code won't allow for it at 
present.

The string handling code is a major area which doesn't allow for target 
and host bytes being different.  But everything target-independent 
hardcoding integer modes wider than QImode is potentially wrong; with wide 
bytes, many of those modes may not exist.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: why are stl template classes not mangled as other classes and templates

[Stephane Hockenhull]

On Monday 26 November 2007 19:29, Joe Buck wrote:
> On Mon, Nov 26, 2007 at 04:02:48PM -0500, Stephane Hockenhull wrote:
> > On Monday 26 November 2007 14:01, Daniel Jacobowitz wrote:
> > > On Mon, Nov 26, 2007 at 10:40:35AM -0800, Joe Buck wrote:
> > > > On Mon, Nov 26, 2007 at 01:33:54PM -0500, Stephane Hockenhull wrote:
> > > > > hi, it seem stl templates are not mangled as other classes and
> > > > > templates
> > > > >
> > > > > I was wondering why and where in the g++ source code is that
> > > > > special case implemented?
> > > > >
> > > > > it seem to cause a problem with -fleading-underscore
> > > >
> > > > AFAIK there is no special case, however there might be a bug lurking
> > > > somewhere.  Do you have a specific case where -fleading-underscore
> > > > messes up?
> > >
> > > There are a few special cases, e.g. for std::string and
> > > std::basic_string; the C++ ABI documents have the details.
> > >
> > > _ZSi -> std::basic_istream >
> >
> > those cause problem with -fleading-underscore.
> >
> > it seem there is more than one data path for the mangling and one of
> > those misses adding the extra underscore which cause missing symbols at
> > linking.
>
> Hm.  But -fleading-underscore is there to support an old ABI, the one that
> BSD Unix used to use, and the _ZSi is for the newer common ABI.  Probably
> no one tested the interaction, so I don't know what the correct solution
> is.
>
> But why are you using -fleading-underscore?

on the win32 platform all C symbols requires a leading underscore
everything works fine until we start using std::string objects, there is a bug 
with the special case name mangling.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166

-- 
Stephane Hockenhull
SSC-Studios.com

Re: [Fwd: performance with gcc -O0/-O2]

[Andi Kleen]

Andrew Haley <[EMAIL PROTECTED]> writes:

> Howard Chu writes:
>
>  > A bit of a minor mystery. Not a problem, just a curiosity. If
>  > someone knew off the top of their head a reason for it, that'd be
>  > cool, but otherwise no sweat.
>
> It's possible, although unlikley, that the optimized code has worse
> cache behaviour.  No way to know better without doing some profiling.

It's quite possible if he hits the conditional store "optimization"
(that actually adds unnecessary cache misses) that was recently discussed
in the load thread safety thread.

-Andi

Re: why are stl template classes not mangled as other classes and templates

[Stephane Hockenhull]

On Monday 26 November 2007 22:48, Daniel Jacobowitz wrote:
> It's the default for a lot of targets.  I'd still like to see a
> concrete example of the problem...

we're cross-compiling to win32, everything works fine until we use the 
std::string template, 
the special case name mangling for std::string is partially broken by 
-fleading-underscore.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166

-- 
Stephane Hockenhull
SSC-Studios.com

RE: why are stl template classes not mangled as other classes and templates

[Dave Korn]

On 27 November 2007 15:49, Stephane Hockenhull wrote:

>> But why are you using -fleading-underscore?
> 
> on the win32 platform all C symbols requires a leading underscore

  Yes, that is the case on almost all platforms.

  And the compiler *automatically* puts leading underscores on symbols on all
those platforms already.

  So the question remains: why are you using -fleading-underscores?

  -fleading-underscore is intended for use on platforms that *don't* require a
leading underscore (e.g. ppc), where you might for special reasons want to
force the symbols to have an underscore anyway.

> everything works fine until we start using std::string objects, there is a
> bug with the special case name mangling.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166

  Yes, but as you yourself explain, the symbols already have leading
underscores, and when you use -fleading-underscore, because it fails to
consistently add *extra* underscores.

  So: why are you using -fleading-underscores?

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: [Fwd: performance with gcc -O0/-O2]

[Howard Chu]

Richard Guenther wrote:

On Nov 27, 2007 2:23 PM, Howard Chu <[EMAIL PROTECTED]> wrote:

A bit of a minor mystery. Not a problem, just a curiosity. If someone knew off
the top of their head a reason for it, that'd be cool, but otherwise no sweat.


I'd try -Os, you might run into ICache limitations.


Thanks to everyone for the replies.

Fyi, the runs were all with -march=k8.

The test with gcc 4.2.2 and -Os just finished, it was again faster than -O0 
from 4 to 28 clients, but slower than -O0 the rest of the way. It peaked at 
38K auths/sec at 120 client threads. Slightly better than -O2. I'll try again 
with some of these other suggestions.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

RE: why are stl template classes not mangled as other classes and templates

[Dave Korn]

On 27 November 2007 16:10, Dave Korn wrote:

>   Yes, but as you yourself explain, the symbols already have leading
> underscores, and when you use -fleading-underscore, because it fails to
^

... when you use -fleading-underscores, *a problem arises* because it fails to
...

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: [Fwd: performance with gcc -O0/-O2]

[Andrew Haley]

Andi Kleen writes:
 > Andrew Haley <[EMAIL PROTECTED]> writes:
 > 
 > > Howard Chu writes:
 > >
 > >  > A bit of a minor mystery. Not a problem, just a curiosity. If
 > >  > someone knew off the top of their head a reason for it, that'd be
 > >  > cool, but otherwise no sweat.
 > >
 > > It's possible, although unlikley, that the optimized code has worse
 > > cache behaviour.  No way to know better without doing some profiling.
 > 
 > It's quite possible if he hits the conditional store "optimization"
 > (that actually adds unnecessary cache misses) that was recently discussed
 > in the load thread safety thread.

Possibly.  I'm guessing that what we are actually seeing is something
like an acutely timing-sensitive race condition, where making some
threads faster causes pessimal cache behaviour.  It's a really
interesting problem.  :-)

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 
1TE, UK
Registered in England and Wales No. 3798903

Dataflow question

[Rask Ingemann Lambertsen]

   I have a simple loop over the defs of an INSN, looking for the def of a
specific register X:

  struct df_ref **defs;
  for (defs = DF_INSN_DEFS (insn);
   *defs && !rtx_equal_p (DF_REF_REG (*defs), x);
   defs++)
;

   It doesn't work because the modes don't match:

(gdb) call debug_rtx (defs[0]->insn)
(insn 9 8 10 2 /tmp/pr3507-3.c:9 (set (reg:CCSO 13 cc)
(compare:CCSO (reg/v:HI 22 [ a ])
(reg/v:HI 23 [ b ]))) 269 {*cmphi_ccso} (nil))
(gdb) call debug_rtx (defs[0]->reg)
(reg:CC 13 cc)

   Should I just compare register numbers instead?

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Designs for better debug info in GCC

[Michael Matz]

Hi,

On Mon, 26 Nov 2007, Alexandre Oliva wrote:

> >> And then, you have to tweak everything else to keep the note that
> >> replaced the set up to date as you further optimize the code.
> 
> > No.  remove_insn() would replace the SET with a note.
> 
> What information would this note convey?

Oh my, sorry for adding confusion to the topic: I meant to write "would 
_not_ replace the SET with a note".


Ciao,
Michael.

Re: why are stl template classes not mangled as other classes and templates

[Stephane Hockenhull]

On Tuesday 27 November 2007 11:09, you wrote:
> On 27 November 2007 15:49, Stephane Hockenhull wrote:
> >> But why are you using -fleading-underscore?
> >
> > on the win32 platform all C symbols requires a leading underscore
>
>   Yes, that is the case on almost all platforms.
>
>   And the compiler *automatically* puts leading underscores on symbols on
> all those platforms already.
>
>   So the question remains: why are you using -fleading-underscores?
>
>   -fleading-underscore is intended for use on platforms that *don't*
> require a leading underscore (e.g. ppc), where you might for special
> reasons want to force the symbols to have an underscore anyway.
>
> > everything works fine until we start using std::string objects, there is
> > a bug with the special case name mangling.
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166
>
>   Yes, but as you yourself explain, the symbols already have leading
> underscores, and when you use -fleading-underscore, because it fails to
> consistently add *extra* underscores.

no, the symbol have a first underscore because that's how G++ mangles them, it 
ALWAYS add 1 underscore (without -fleading-underscore) and some other 
characters.

without -fleading-underscore for example "strstr" is called "strstr" but win32 
libraries need "_strstr" so -fleading-underscore must be used

with -fleading-underscore gcc/g++ adds an underscore to ALL symbols, including 
mangled ones, therefore it need TWO underscores for mangled names and ONE 
underscore for normal identifiers.

which g++ does right 99.9% of the time, but it only does it halfway to 
std::string.

it tries to call it as "__ZNSs7replaceEmmPKc"
but it instanciate it as "_ZNSs7replaceEmmPKc"

which is clearly a bug

I just need to know where in the code this boolean option is located and where 
the mangling is done so I can patch it up.

>   So: why are you using -fleading-underscores?
>
> cheers,
>   DaveK


I'm an underscorophile, underscores makes me horny, that's why I drive around 
town in an blue-screen-painted icecream truck playing windows's boot up 
sounds to attract little windows symbols with underscores and "@" signs. 

joking aside, we need to generate ELF object files for running on windows.

-- 
Stephane Hockenhull
SSC-Studios.com

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Michael Eager]

Joseph S. Myers wrote:

On Mon, 26 Nov 2007, Michael Eager wrote:


Well, can't do that.  This is not target dependent.
DImode gets defined, and used, for long long in unwind-dw2.c.


Is it defined what DWARF unwind information looks like when made up of 
bytes wider than 8 bits?  Certainly GCC's code won't allow for it at 
present.


I expect that the unwind code is broken unless long long is 8 bytes.
IIRC, unwind confuses host and target integer sizes.

The string handling code is a major area which doesn't allow for target 
and host bytes being different.  But everything target-independent 
hardcoding integer modes wider than QImode is potentially wrong; with wide 
bytes, many of those modes may not exist.


IMO, it looks like the absence of a supported 32-bit word-addressed
target let the support for BITS_PER_UNIT != 8 fall into disrepair.

I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Joseph S. Myers]

On Tue, 27 Nov 2007, Michael Eager wrote:

> I think that there is a pervasive understanding that SImode is
> single precision integer, 32-bits long.

Only among contributors not considering non-8-bit bytes.  SImode is 4 
times QImode, 4*BITS_PER_UNIT bits, and may not exist (or at least not be 
particularly usable, much like the limitations on TImode on 32-bit 
targets) with large BITS_PER_UNIT.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: PR1634: Request for gcc-cvs-patches list

[Daniel Berlin]

On 11/26/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Nov 2007, Paolo Bonzini wrote:
>
> > On the other hand, if it is meant for human usage the file list is already a
> > clue to spot "wrong" commits.  Then, an equivalent but more versatile 
> > feature
> > request would be to have patches visible online, with URLs like
> > http://gcc.gnu.org/viewcvs/?r1=11r2=12&view=patch (which would do a
> > "svn diff -x -u -r11 -r12").  Such URLs currently work with files 
> > but
> > not with directories.  I don't know how fundamental a problem with ViewVC 
> > and
> > svn-python bindings this is.
>
> The primary function is for a human reading the list (where patches
> directly inline in the message are by far preferable to URLs).
>
> I believe the SVN log mailer supports mailing patches anyway.

It does.
>  So you
> could get 90% of the benefit by having the SVN mailer run twice for each
> commit, once with the present configuration for gcc-cvs and once with a
> different configuration (including patches, 10MB message size limit (and a
> similarly large limit for the list itself), truncating rather than
> splitting anything larger) for gcc-cvs-patches.
>

You don't even need to do this, you can tell it to send patches to one
address and just what it does now to the other, and it will happily do
so in one run :)

> --
> Joseph S. Myers
> [EMAIL PROTECTED]
>

Re: BITS_PER_UNIT larger than 8 -- word addressing

[Michael Eager]

Joseph S. Myers wrote:

On Tue, 27 Nov 2007, Michael Eager wrote:


I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.


Only among contributors not considering non-8-bit bytes.  SImode is 4 
times QImode, 4*BITS_PER_UNIT bits, and may not exist (or at least not be 
particularly usable, much like the limitations on TImode on 32-bit 
targets) with large BITS_PER_UNIT.


I think you just described the majority of contributors.  :-)

It's human nature not to recognize one's tacit assumptions or their
consequences.  It's also normal for people to focus on what they are
working on and pay far less attention to other targets.  Since there
is no working and supported 32-bit word-addressed target, there's
little to alert anyone that one of their assumptions is not valid.

It may be that my current problem is limited to unwind-dw2.c.
If so, then I may be able to work around it by simply not building it.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Dataflow question

[Paolo Bonzini]

Rask Ingemann Lambertsen wrote:

   I have a simple loop over the defs of an INSN, looking for the def of a
specific register X:

   Should I just compare register numbers instead?


I think so, or maybe even use reg_overlap_mentioned_p.  It depends what 
you're doing.  For 4.4, it may be worth modifying df_find_def and 
df_find_use so that you can just use those.


Paolo

Re: why are stl template classes not mangled as other classes and templates

['Daniel Jacobowitz']

On Tue, Nov 27, 2007 at 06:39:09PM -, Dave Korn wrote:
> > joking aside, we need to generate ELF object files for running on windows.
> 
>   OK, you are now attempting something very very wrong indeed.  The win32
> version of the assembler will not generate ELF files, and even if it did,
> windows cannot make any use of the ELF format, it uses PE-COFF.  And the
> output file format has absolutely nothing to do with whether or not the
> symbols have leading underscores, so claiming that you have to use
> -fleading-underscores because you need to generate ELF files is a
> non-sequitur.

Please give them a little credit.  I would assume they're using an
i386-elf compiler and have some mechanism of their own to make the ELF
files run.

-- 
Daniel Jacobowitz
CodeSourcery

RE: why are stl template classes not mangled as other classes andtemplates

[Dave Korn]

On 27 November 2007 18:47, 'Daniel Jacobowitz' wrote:

> On Tue, Nov 27, 2007 at 06:39:09PM -, Dave Korn wrote:
>>> joking aside, we need to generate ELF object files for running on windows.
>> 
>>   OK, you are now attempting something very very wrong indeed.  The win32
>> version of the assembler will not generate ELF files, and even if it did,
>> windows cannot make any use of the ELF format, it uses PE-COFF.  And the
>> output file format has absolutely nothing to do with whether or not the
>> symbols have leading underscores, so claiming that you have to use
>> -fleading-underscores because you need to generate ELF files is a
>> non-sequitur.
> 
> Please give them a little credit.  I would assume they're using an
> i386-elf compiler and have some mechanism of their own to make the ELF
> files run.

  I am making no assumptions either way; I'd like some clarification.

  Wouldn't a simpler and more-likely-to-be-reliable technique be to use a
win32 /compiler/ (so as to get all the ABI issues right, not just the amount
of underscores on symbols) and only generate/convert to ELF further down the
toolchain?

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: why are stl template classes not mangled as other classes and templates

[Dave Korn]

On 27 November 2007 17:35, Stephane Hockenhull wrote:
> On Tuesday 27 November 2007 11:09, you wrote:
>> On 27 November 2007 15:49, Stephane Hockenhull wrote:

>>> on the win32 platform all C symbols requires a leading underscore
>> 
>>   Yes, that is the case on almost all platforms.
>> 
>>   And the compiler *automatically* puts leading underscores on symbols on
>> all those platforms already. 
>> 
>>   So the question remains: why are you using -fleading-underscores?

>>> everything works fine until we start using std::string objects, there is
>>> a bug with the special case name mangling.
>>> 
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166
>> 
>>   Yes, but as you yourself explain, the symbols already have leading
>> underscores, and when you use -fleading-underscore, because it fails to
>> consistently add *extra* underscores.
> 
> no, the symbol have a first underscore because that's how G++ mangles them,
> it ALWAYS add 1 underscore (without -fleading-underscore) and some other
> characters.
> 
> without -fleading-underscore for example "strstr" is called "strstr" but
> win32 libraries need "_strstr" so -fleading-underscore must be used

  You are simply wrong about this.  Let me demonstrate:

/tmp/lundersc $ cat test.cpp
extern "C" char *strstr (const char *, const char *);


void strtest (void)
{
  strstr ("foo", "foobar");
}

/tmp/lundersc $ g++ --save-temps -g -O0 -fno-builtin -c test.cpp -o test.o
/tmp/lundersc $ grep strstr test.s
call_strstr
.def_strstr;.scl3;  .type   32; .endef
/tmp/lundersc $

  As you see, all the reference the compiler generates to strstr are already
prefixed by an underscore, with no need for any special flags.

> with -fleading-underscore gcc/g++ adds an underscore to ALL symbols,
> including mangled ones, therefore it need TWO underscores for mangled names
> and ONE underscore for normal identifiers.

  Given that you have misunderstood the starting point, your conclusion here
is wrong.  *All* names, whether mangled or non-mangled, are given an
underscore by the compiler.  This underscore is concealed at the C and C++
level and is visible and relevant only in the assembler level.

> which g++ does right 99.9% of the time, but it only does it halfway to
> std::string.
> 
> it tries to call it as "__ZNSs7replaceEmmPKc"
> but it instanciate it as "_ZNSs7replaceEmmPKc"
> 
> which is clearly a bug

  Yes, that bit is, but then again, you should not be using
-fleading-underscore in the first place, and if you think you do need to do
so, there is something more fundamental wrong in your setup.  Are you sure
you're even using a win32 version of the compiler?

> I just need to know where in the code this boolean option is located and
> where the mangling is done so I can patch it up.

  No, you do not.  You have misdiagnosed the problem and obtained an incorrect
solution.  Have you read the manual?  When it explains -fleading-underscores,
it explicitly states:

" Not all targets provide complete support for this switch. "

  The x86 is one of those targets.  It does not provide complete support for
this switch, but then again, there is not and has never been any need for this
switch on the x86.

> joking aside, we need to generate ELF object files for running on windows.

  OK, you are now attempting something very very wrong indeed.  The win32
version of the assembler will not generate ELF files, and even if it did,
windows cannot make any use of the ELF format, it uses PE-COFF.  And the
output file format has absolutely nothing to do with whether or not the
symbols have leading underscores, so claiming that you have to use
-fleading-underscores because you need to generate ELF files is a
non-sequitur.

  So:  You do not need to use -fleading-underscores, if you think you do then
/something else/ is going wrong already, and you are just making it worse for
yourself because -fleading-underscores is not supported on x86/win32 and the
use of it is giving you *additional problems* on top of the problem you
already have, and you have a mistaken notion that any of this has anything to
do with ELF or non-ELF.

  What is the *real* problem?  What is it that convinced you that you needed
to use -fleading-underscores in the first place?  Because whatever it was, it
has a different and better solution - one that works, not one that breaks even
worse.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Designs for better debug info in GCC

[Alexandre Oliva]

On Nov 27, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:

> Hi,
> On Mon, 26 Nov 2007, Alexandre Oliva wrote:

>> >> And then, you have to tweak everything else to keep the note that
>> >> replaced the set up to date as you further optimize the code.
>> 
>> > No.  remove_insn() would replace the SET with a note.
>> 
>> What information would this note convey?

> Oh my, sorry for adding confusion to the topic: I meant to write "would 
> _not_ replace the SET with a note".

Aah, ok.  So, you do indeed completely lose track of the crucial
differences between the two cases for the removal of a SET.  And not
only about their implications, but also about where they ought to take
effect.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

ICE in gcc-3.3

[Bruce Korb]

$ /usr/bin/gcc-3.3  -I../../tpd-include  -E -DKERNEL_26 emlib.c -o emlib.i
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.


Sending the output to stdout instead, I get this:

static char const *
pfail_evt_type_desc_to_str(tpd_u32 evt_type)
{
switch (evt_type) {
case 0x400:
   ||<<

Re: [Fwd: performance with gcc -O0/-O2]

[Howard Chu]

J.C. Pizarro wrote:

For your Opteron, try with this option

-O3 -fomit-frame-pointer -march=k8 -funroll-loops -finline-functions
-fpeel-loops \
-mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow

The Opteron hardware said that it's better to use SSE2 than SSE3.
The MMX and 3DNow!+ instructions are shorter and older than SSE2/SSE
instructions.


Interesting. With these flags, the peak was 39K/sec, and it didn't top out 
until 272 client connections. (Quite a lengthy test; I'm running 2 minutes per 
iteration with X number of clients, then increasing on the next iteration, 
repeating until the transaction count stops growing. So this was over two 
hours before it finally maxed out.) I guess this is a pretty good setting for 
heavy scalability even though it didn't quite reach 40K/sec.


During these tests I see that about 94% of one core is consumed by interrupt 
processing, with 2% idle time left. I guess this ~200K packet per second rate 
is pretty near the limit of what this system can handle on gigabit ethernet. 
I've seen this box hit as high as 43K auths/sec using 4 slapd processes with 3 
threads each, as opposed to a single process with 8 threads. In that test 100% 
of a core was doing interrupt processing.


Anyway, thanks again for all your responses.
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sunhttp://highlandsun.com/hyc/
  Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: Progress on GCC plugins ?

[Alexandre Oliva]

On Nov 26, 2007, Tom Tromey <[EMAIL PROTECTED]> wrote:

> I do wonder if there is a platform out there that acts as if -rdynamic
> were the default.

I'm pretty sure I was surprised when I first ran into the need for
-rdynamic on GNU/Linux, because other platforms I'd used didn't need
that.  I'd guess that would have been SunOS4.1.3 or maybe Solaris2.1,
back then.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: ICE in gcc-3.3

[Joe Buck]

On Tue, Nov 27, 2007 at 11:51:18AM -0800, Bruce Korb wrote:
> $ /usr/bin/gcc-3.3  -I../../tpd-include  -E -DKERNEL_26 emlib.c -o emlib.i
> cc1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> For Debian GNU/Linux specific bug reporting instructions, see
> .

gcc-3.3 is quite old and is no longer maintained, though if the bug you
found is still present in current sources, it should be reported.

> Sending the output to stdout instead, I get this:

To do anything about a bug, the developers will need a complete test
case that produces the bug.  Changes to the test case that *don't*
produce a bug are not interesting.

Re: ICE in gcc-3.3 & 4.1

[Bruce Korb]

On Nov 27, 2007 12:03 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> gcc-3.3 is quite old and is no longer maintained, though if the bug you
> found is still present in current sources, it should be reported.

I know.  Debian's fresh releases are always full of really old stuff.
Anyway, 4.1 too:
$ /usr/bin/gcc-4.1  -I../../tpd-include  -E -DKERNEL_26 emlib.c -o emlib.i
:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .

> > Sending the output to stdout instead, I get this:
>
> To do anything about a bug, the developers will need a complete test
> case that produces the bug.  Changes to the test case that *don't*
> produce a bug are not interesting.

If it is worth chasing.  It is not worth chasing if someone readily
recognizes the
symptom and says, "Yes, I've fixed something like that."  Since the trivial
trim of the sources yielded something that did not fault, creating something
that still fails will wind up taking serious work.  It would need a reasonable
prospect of being useful before I would afford the time.  Thanks - Bruce

Re: why are stl template classes not mangled as other classes andtemplates

[Stephane Hockenhull]

On Tuesday 27 November 2007 14:00, Dave Korn wrote:
> On 27 November 2007 18:47, 'Daniel Jacobowitz' wrote:
> > On Tue, Nov 27, 2007 at 06:39:09PM -, Dave Korn wrote:
> >>> joking aside, we need to generate ELF object files for running on
> >>> windows.
> >>
> >>   OK, you are now attempting something very very wrong indeed.  The
> >> win32 version of the assembler will not generate ELF files, and even if
> >> it did, windows cannot make any use of the ELF format, it uses PE-COFF. 
> >> And the output file format has absolutely nothing to do with whether or
> >> not the symbols have leading underscores, so claiming that you have to
> >> use -fleading-underscores because you need to generate ELF files is a
> >> non-sequitur.
> >
> > Please give them a little credit.  I would assume they're using an
> > i386-elf compiler and have some mechanism of their own to make the ELF
> > files run.
>
>   I am making no assumptions either way; I'd like some clarification.
>
>   Wouldn't a simpler and more-likely-to-be-reliable technique be to use a
> win32 /compiler/ (so as to get all the ABI issues right, not just the
> amount of underscores on symbols) and only generate/convert to ELF further
> down the toolchain?

no, it would not.
because for one simple fact: COFF format lacks many features of ELF.

this is why we're compiling, assembling, linking, patching, and dynamically 
re-linking everything in ELF format, including using a custom linker script 
that generates an ELF file that is win32 "compatible" (load addresses and 
all)

we then convert the final executable to PE format and run it on the target 
platform.

this even allows us to debug the win32 application from linux using the ELF 
version of the executable file and system's default GDB, or Kdbg, or DDD, or 
what not, with a gdb stub so even if we're running fullscreen under windows 
we can still debug even tho the win32 GUI is frozen and a normal win32 
debugger would just deadlock the system.

this turns debugging under win32 into something akin to working on an embedded 
platform, we also have the same source code running natively on GameCube 
(PPC32-BE), Nintendo DS (ARM-LE), and Linux AMD64 among others.

please dont worry for us about ABI issues and what not, I've got that part 
working, thank you.

now, if only someone actually knew where in the g++ source code the special 
case for std::string is I could fix that, provide a patch, and make the world 
a little bit better.

-- 
Stephane Hockenhull
SSC-Studios.com

Re: why are stl template classes not mangled as other classes andtemplates

[Andrew Pinski]

On 11/27/07, Stephane Hockenhull <[EMAIL PROTECTED]> wrote:
> no, it would not.
> because for one simple fact: COFF format lacks many features of ELF.

What features are missing?  COFF is not used for Windows 32 anyways,
it is PE-COFF.  I am just wondering what exactly is missing that you
think you need to go this route.

Thanks,
Andrew Pinski

Re: ICE in gcc-3.3 & 4.1

[Joe Buck]

On Tue, Nov 27, 2007 at 12:19:40PM -0800, Bruce Korb wrote:
> > To do anything about a bug, the developers will need a complete test
> > case that produces the bug.  Changes to the test case that *don't*
> > produce a bug are not interesting.
> 
> If it is worth chasing.  It is not worth chasing if someone readily
> recognizes the
> symptom and says, "Yes, I've fixed something like that."

It rarely works that way; you will almost never be so lucky.

> trim of the sources yielded something that did not fault, creating something
> that still fails will wind up taking serious work.  It would need a reasonable
> prospect of being useful before I would afford the time.  Thanks - Bruce

There are ways of doing this automatically.  See

http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

Re: why are stl template classes not mangled as other classes andtemplates

[Andreas Schwab]

Stephane Hockenhull <[EMAIL PROTECTED]> writes:

> now, if only someone actually knew where in the g++ source code the special 
> case for std::string is

grep is your friend.  Look for find_substitution in cp/mangle.c.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: why are stl template classes not mangled as other classes andtemplates

[Andreas Schwab]

Stephane Hockenhull <[EMAIL PROTECTED]> writes:

> now, if only someone actually knew where in the g++ source code the special 
> case for std::string is I could fix that, provide a patch, and make the world 
> a little bit better.

Actually I think you rather want to look for places that use
USER_LABEL_PREFIX directly instead of user_label_prefix.  There is only
one occurrence under config/i386, but I don't know how relevant it is.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: why are stl template classes not mangled as other classes andtemplates

[Stephane Hockenhull]

On Tuesday 27 November 2007 15:40, Andrew Pinski wrote:
> On 11/27/07, Stephane Hockenhull <[EMAIL PROTECTED]> wrote:
> > no, it would not.
> > because for one simple fact: COFF format lacks many features of ELF.
>
> What features are missing?  COFF is not used for Windows 32 anyways,
> it is PE-COFF.  I am just wondering what exactly is missing that you
> think you need to go this route.
>
> Thanks,
> Andrew Pinski

we had some problem with some missing flags, like weak and others special 
attributes we use in some parts to provide extended features.

but anyway, we have some special processing done where we need to be able to 
read the object files and we also use a custom dynamic linker so everything 
has to be in ELF format.

BFD is really nice, but a bit too big to run on one of our platforms (3MB RAM 
embedded system) so we had to develop custom routines anyway and elf is easy 
enough to parse, so for KISS reasons those routines ends up on all platforms.

I can't say much more.

all I can say is going the all-ELF way right to the end really works nicely, 
*EXCEPT* for that std::string issue.

-- 
Stephane Hockenhull
SSC-Studios.com

Re: why are stl template classes not mangled as other classes andtemplates

[Stephane Hockenhull]

On Tuesday 27 November 2007 15:50, Andreas Schwab wrote:
> Stephane Hockenhull <[EMAIL PROTECTED]> writes:
> > now, if only someone actually knew where in the g++ source code the
> > special case for std::string is
>
> grep is your friend.  Look for find_substitution in cp/mangle.c.
>
> Andreas.

*THANK YOU*

... checking now

-- 
Stephane Hockenhull
SSC-Studios.com

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Bernd Schmidt wrote:

> I've committed the following to take care of this.  Neither -mfdpic nor
> -mid-shared-library are actually useful with bfin-elf toolchains, but by
> making them imply -msim, we can at least get these kinds of configure
> test executables to link.

My impression was that we'd developed the consensus that generic ELF
ports should not have a default board.  (IIRC, Power and MIPS are like
that; if you don't say -msim explicitly, you get a link error.)

If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
error?  Why accept it, but make it imply the simulator?

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Mark Mitchell wrote:
>> Bernd Schmidt wrote:
>> 
 If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
 error?  Why accept it, but make it imply the simulator?
>>> Because all the target libraries fail to build if the configure tests
>>> don't link.
>> 
>> But why isn't that a problem with the target libraries or the way in
>> which GCC is being configured?  Why don't we have that problem for MIPS
>> or Power, given that they don't link with a target board by default either?

That's not something I can answer, being unfamiliar with both targets.
Maybe they don't build/need a default multilib for "no particular target"?

>> I'm not trying to be rhetorical.  I just want to understand what's going
>> on here because it sounded to me from your patch like we were making the
>> compiler accept options that don't make sense in order to work around
>> some problem -- and maybe that problem is what should really be solved.

We have two uses for the bfin-elf compiler - building standalone
applications, and bootstrapping uClibc for
bfin-uclinux/bfin-linux-uclibc.  For the latter, we need -mfdpic and
-mid-shared-library multilibs, to at least get a libgcc.  This always
worked since what is now "-msim" was default behaviour, but it started
to fail the libstdc++ configury once Jie changed that to use
target-specific linker scripts.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Bernd Schmidt wrote:

>>> But why isn't that a problem with the target libraries or the way in
>>> which GCC is being configured?  Why don't we have that problem for MIPS
>>> or Power, given that they don't link with a target board by default either?
> 
> That's not something I can answer, being unfamiliar with both targets.
> Maybe they don't build/need a default multilib for "no particular target"?

I'm pretty certain that both do have a default multilib for a lowest
common denominator CPU, and that you have to provide explicit options to
link with it.

> We have two uses for the bfin-elf compiler - building standalone
> applications, and bootstrapping uClibc for
> bfin-uclinux/bfin-linux-uclibc.

Most targets just do the usual dance of building compilers and libraries
interleaved appropriately.  For example, we build ARM uClinux compilers
without ever building an ARM ELF compiler.  Why can't you do that for
Blackfin?

> For the latter, we need -mfdpic and
> -mid-shared-library multilibs, to at least get a libgcc.  This always
> worked since what is now "-msim" was default behaviour, but it started
> to fail the libstdc++ configury once Jie changed that to use
> target-specific linker scripts.

I really think that we ought to compare with what happens with MIPS or
Power and figure out what's different.  Are you by any chance
configuring a native compiler, rather than a cross?

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Mark Mitchell wrote:

>> We have two uses for the bfin-elf compiler - building standalone
>> applications, and bootstrapping uClibc for
>> bfin-uclinux/bfin-linux-uclibc.
> 
> Most targets just do the usual dance of building compilers and libraries
> interleaved appropriately.  For example, we build ARM uClinux compilers
> without ever building an ARM ELF compiler.  Why can't you do that for
> Blackfin?

It sounds more complicated than what we do.  We just build bfin-elf,
build uClibc with it, and build up the bfin-*linux* compilers.  Just
three simple steps.  What do you do for ARM uClinux?

> I really think that we ought to compare with what happens with MIPS or
> Power and figure out what's different.  Are you by any chance
> configuring a native compiler, rather than a cross?

No native compilers - I don't think the linux nommu memory manager would
be very happy about running gcc.  Running the testsuite is bad enough.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Mark Mitchell wrote:
> Bernd Schmidt wrote:
> 
>> I've committed the following to take care of this.  Neither -mfdpic nor
>> -mid-shared-library are actually useful with bfin-elf toolchains, but by
>> making them imply -msim, we can at least get these kinds of configure
>> test executables to link.
> 
> My impression was that we'd developed the consensus that generic ELF
> ports should not have a default board.  (IIRC, Power and MIPS are like
> that; if you don't say -msim explicitly, you get a link error.)
> 
> If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
> error?  Why accept it, but make it imply the simulator?

Because all the target libraries fail to build if the configure tests
don't link.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Bernd Schmidt wrote:

>> If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
>> error?  Why accept it, but make it imply the simulator?
> 
> Because all the target libraries fail to build if the configure tests
> don't link.

But why isn't that a problem with the target libraries or the way in
which GCC is being configured?  Why don't we have that problem for MIPS
or Power, given that they don't link with a target board by default either?

I'm not trying to be rhetorical.  I just want to understand what's going
on here because it sounded to me from your patch like we were making the
compiler accept options that don't make sense in order to work around
some problem -- and maybe that problem is what should really be solved.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Mark Mitchell wrote:
> Note that libstdc++/configure.ac carefully avoids linking except for
> $GLIBCXX_IS_NATIVE.  It's a design property that you should not need to
> link.  Where in libstdc++ is it requiring linking?

Jie started the thread back in September, and posted the following call
trace:

"libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
_LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF

which leads to
checking for shl_load... configure: error: Link tests are not allowed
after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1

Jie had a patch for that, but I decided to fix it by just making things
link, since I've seen other occurrences of this problem over the years.
 It just seems more robust not to require the configure scripts to avoid
linking.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Bernd Schmidt wrote:

>> Most targets just do the usual dance of building compilers and libraries
>> interleaved appropriately.  For example, we build ARM uClinux compilers
>> without ever building an ARM ELF compiler.  Why can't you do that for
>> Blackfin?
> 
> It sounds more complicated than what we do.  We just build bfin-elf,
> build uClibc with it, and build up the bfin-*linux* compilers.  Just
> three simple steps.  What do you do for ARM uClinux?

I'm not sure of the exact details.  It could be that your way is
simpler.  Perhaps on other systems the ABIs don't quite match, or
something.  In any case, I think that's immaterial.

>> I really think that we ought to compare with what happens with MIPS or
>> Power and figure out what's different.  Are you by any chance
>> configuring a native compiler, rather than a cross?
> 
> No native compilers - I don't think the linux nommu memory manager would
> be very happy about running gcc.  Running the testsuite is bad enough.

Yeah, I didn't think so, but I was trying to think about what could be
different.  I've CC'd Richard Sandiford, as I discussed some of the MIPS
stuff with him at one point.

Note that libstdc++/configure.ac carefully avoids linking except for
$GLIBCXX_IS_NATIVE.  It's a design property that you should not need to
link.  Where in libstdc++ is it requiring linking?

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Fwd: Suggestion for removing flex/bison as a dependancy

[Ben Elliston]

On Tue, 2007-11-27 at 00:25 +0530, Karthik Kumar wrote:

> I'm not saying we don't use flex/bison. I am only saying we can remove
> that as a build dependancy; Many people have to use specific versions
> of lex (flex) and yacc (bison) if they wish to compile gcc.

I agree with you: end users should not have to have these tools
installed in order to build GCC.  However, we expect that most end users
are building GCC *releases*, where we provide the generated files in the
release tarball.

If you check GCC out of the Subversion repository, you are now classed
as a developer and you are expected to have those tools installed.  I
don't think that is an unreasonable assumption.

Ben

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Bernd Schmidt wrote:

> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF
> 
> which leads to
> checking for shl_load... configure: error: Link tests are not allowed
> after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libstdc++-v3] Error 1

Thanks.  Perhaps the difference here is that  isn't available
for MIPS/Power ELF, but is available in your configuration because
you're building with uClibc as your C library?  If so, I think there are
ways that we can solve this problem that don't involve adding -msim.  (I
haven't looked at Jie's approach, so I can't comment on that.)

> Jie had a patch for that, but I decided to fix it by just making things
> link, since I've seen other occurrences of this problem over the years.
>  It just seems more robust not to require the configure scripts to avoid
> linking.

I disagree.  Since the preferred bare-metal setup is that linking not
work without -msim (or a -T option), we don't want configure tests that
detect any properties that might depend on what happens when you link.
We want to make sure that detected properties are a property only of the
parts that a user isn't going to change.

In any case, I think this is something that ought to be decided as a
global policy for GCC and its run-time libraries, not something that
differs between ports.  In particular, if run-time libraries are allowed
to depend on linking in their configure tests, that's something everyone
should know.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

GCC 4.3.0 Status Report (2007-11-27)

[Mark Mitchell]

Status
==

We are in Stage 3.  When we reach 100 open regressions, we will go to
regression-only mode.  When we approach the 4.3.0 release, we will
create a branch, and open Stage 1 for 4.4.0.

Issues
==

1. I noticed that there are quite a few P2 ICE reports regarding
   variadic templates.  Doug Gregor, would you please look into these?
   Jason, would you be able to review Doug's patches (as the arrive),
   given that you've looked at much of the rest of his code?

2. PR 33928, PR31897, PR32086 are performance regressions of large
   magnitude.  There are several more as well.  I would like to
   understand what's going on in these cases.  If they indicate bugs
   in algorithms that we've implemented, I'd like to have time to fix
   them -- rather than get into the situation where any fix is too
   risky because we're so close to a release.  I'd also be interested
   in any other benchmark data for 4.3, relative to previous releases.

Quality Data


We've made some progress over the past couple of weeks.  Kudos to all
who have been contributing and reviewing patches!  In particular,
we've made a dent in P2s, and are now down to 134 total regressions
open.

Unfortunately, a large number (33) of those are P1s.  The vast major
of the P1s are 4.3-only regressions, so we've got wrong-code or
ICE-on-valid regressions that need solving.  I noticed several issues
relating to -ftree-loop-linear.  I realize that some of the
optimization options that are mentioned in the P1s are new, and not on
by default -- but we'll be announcing these new options, and users
will want to use them, so it's best if they work.

Priority  # Change from Last Report
--- ---
P1   33 -  3
P2   97 - 18
P34 +  1
--- ---
Total   134 - 20  

Previous Report
===

http://gcc.gnu.org/ml/gcc/2007-11/msg00109.html

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Why don't use "Code Coverage" in GCC?

[J.C. Pizarro]

Hello.

I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html

I suppose that there is not time to eliminate many bugs from
open regressions & others.

Could not we to use "Code coverage" of the GCC snapshot
during its bootstrapping or testsuite time?

See http://en.wikipedia.org/wiki/Code_coverage

It's very useful to analyze, line by line, or frame by frame,
the traces of the GCC's sources.

So, we can investigate "what lines are executed?"
and "what lines aren't executed?", "how many times are executed"?,
etc.

Thanks to "Code Coverage", with the traces, we can to detect
the anomalies of the new algorithms or existent modified algorithms.

It's a little different to profiling (almost profiling functions only).

"No Code Coverage" means "No important help from Code Coverage",
so "Code Coverage" is our future help to follow.

   J.C.Pizarro

Re: Link tests after GCC_NO_EXECUTABLES

[Bernd Schmidt]

Mark Mitchell wrote:
> Bernd Schmidt wrote:
> 
>> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
>> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF
>>
>> which leads to
>> checking for shl_load... configure: error: Link tests are not allowed
>> after GCC_NO_EXECUTABLES.
>> make[1]: *** [configure-target-libstdc++-v3] Error 1
> 
> Thanks.  Perhaps the difference here is that  isn't available
> for MIPS/Power ELF, but is available in your configuration because
> you're building with uClibc as your C library?

We're talking bfin-elf here, so that'd be newlib.  I have no great
desire to meddle in the affairs of libtool, and I'd like to again make
the point that this isn't the first time I've seen the "Link tests are
not allowed after GCC_NO_EXECUTABLES" message; if there is a rule that
libstdc++ configure shouldn't try to link anything, it doesn't appear to
be well enforced.

There's another reason why the patch is helpful: the uClibc build system
tries to guess an OUTPUT_FORMAT for the linker from the output of
  bfin-elf-gcc -mfdpic -Wl,--verbose
which currently fails because without -msim, the linker is trying to
pull in the wrong objects.  I suppose that could be changed too, or I
could try to investigate other ways of building up all the toolchains
that don't require -mfdpic multilibs for bfin-elf.

> In any case, I think this is something that ought to be decided as a
> global policy for GCC and its run-time libraries, not something that
> differs between ports.  In particular, if run-time libraries are allowed
> to depend on linking in their configure tests, that's something everyone
> should know.

If you wish to approve Jie's original patch, I'm not stopping you.  I'll
then revert my patch if I can get some fix into the uClibc repository,
but I reserve the right to reapply it in the future if libstdc++ breaks
my build again.

What I'm trying to do here is to ensure that gcc-4.3 will work out of
the box as a compiler for our uClinux distribution.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Why don't use "Code Coverage" in GCC?

[Joe Buck]

On Wed, Nov 28, 2007 at 01:43:48AM +0100, J.C. Pizarro wrote:
> I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
> http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html
> 
> I suppose that there is not time to eliminate many bugs from
> open regressions & others.
> 
> Could not we to use "Code coverage" of the GCC snapshot
> during its bootstrapping or testsuite time?

Certainly.  Would you like to volunteer?

> See http://en.wikipedia.org/wiki/Code_coverage

Everyone here knows what code coverage is.  If you want to experiment with
gcov, see what our coverage rate is, or try to produce more tests to cover
more source lines, feel free.

You have a habit of saying "GCC should do X, GCC should do Y."
But things happen because people do the work, not because people
suggest that others do work.

Re: Why don't use "Code Coverage" in GCC?

[J.C. Pizarro]

2007/11/28, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 01:43:48AM +0100, J.C. Pizarro wrote:
> > I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
> > http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html
> >
> > I suppose that there is not time to eliminate many bugs from
> > open regressions & others.
> >
> > Could not we to use "Code coverage" of the GCC snapshot
> > during its bootstrapping or testsuite time?
>
> Certainly.  Would you like to volunteer?
>
> > See http://en.wikipedia.org/wiki/Code_coverage
>
> Everyone here knows what code coverage is.  If you want to experiment with
> gcov, see what our coverage rate is, or try to produce more tests to cover
> more source lines, feel free.
>
> You have a habit of saying "GCC should do X, GCC should do Y."
> But things happen because people do the work, not because people
> suggest that others do work.

No problem, i will start to experiment it for my night to have GCC-4.3 a
little bit cleaner :)

   J.C.Pizarro starting volunteerly ...

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

On Tue, 27 Nov 2007, Mark Mitchell wrote:

> In any case, I think this is something that ought to be decided as a
> global policy for GCC and its run-time libraries, not something that
> differs between ports.  In particular, if run-time libraries are allowed
> to depend on linking in their configure tests, that's something everyone
> should know.

For GNU/Linux, we decided some time ago that libstdc++ configuration would 
require link tests in order to identify the precise functions available in 
that particular multilib's libc version and configuration (depending, for 
example, on how uClibc is configured).  It is, after all, the case that 
you cannot create a proper libstdc++ shared library on a glibc system 
without linking it against a shared glibc so that it is bound to the right 
symbol versions in that glibc (static libraries do not generally remain 
compatible across glibc upgrades where symbols the static libraries use 
get new versions), and so you must already have a C library you can link 
against in order for libstdc++ to build, so you may as well use that 
library at configure time.  Some other targets similarly do many link 
checks in libstdc++-v3/crossconfig.m4.

If only static libraries are being built, it may be possible to build them 
without linking, and in such cases it may be possible to define a generic 
set of libc symbols considered to be present, as libstdc++-v3/configure.ac 
does with newlib.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Link tests after GCC_NO_EXECUTABLES

[Benjamin Kosnik]

> if there is a rule that
> libstdc++ configure shouldn't try to link anything, it doesn't appear
> to be well enforced. 

The rule is that libstdc++ shouldn't do link tests unless it knows it
is native. Not "libstdc++ configure shouldn't try to link anything."

This means that there is a huge bias to do compile-time tests if at
all possible, as then native/cross configury is unified.

From configure.ac...

# Enable all the variable C++ runtime options that doesn't require
linking. 
GLIBCXX_ENABLE_CSTDIO

...

# Checks for operating systems support that don't require linking.
GLIBCXX_CHECK_SYSTEM_ERROR

...

if $GLIBCXX_IS_NATIVE; then

  # We can do more elaborate tests that assume a working linker.
  CANADIAN=no


The intent here seems obvious to me: is this not clear? 

It's not especially well enforced, as you note. (And other runtimes
may not take as much care or notice about this at all.) In particular, 

>> AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
>> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF

is not something libstdc++ has much control over I see this as a
bug in AM_PROG_LIBTOOL or these other macros.

> In any case, I think this is something that ought to be decided as a
> global policy for GCC and its run-time libraries, not something that
> differs between ports.  In particular, if run-time libraries are
> allowed to depend on linking in their configure tests, that's
> something everyone should know.

And

> Since the preferred bare-metal setup is that linking not
> work without -msim (or a -T option), we don't want configure tests
> that detect any properties that might depend on what happens when you
> link. We want to make sure that detected properties are a property
> only of the parts that a user isn't going to change.

Thanks for this Mark. Absolutely agreed.

It is insanity to have this differ on a machine by machine or port by
port basis 

-benjamin

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

On Tue, 27 Nov 2007, Bernd Schmidt wrote:

> We have two uses for the bfin-elf compiler - building standalone
> applications, and bootstrapping uClibc for
> bfin-uclinux/bfin-linux-uclibc.  For the latter, we need -mfdpic and
> -mid-shared-library multilibs, to at least get a libgcc.  This always
> worked since what is now "-msim" was default behaviour, but it started
> to fail the libstdc++ configury once Jie changed that to use
> target-specific linker scripts.

When you are building a compiler to bootstrap libc, with a view to 
building a later full toolchain using that libc, the bootstrap compiler 
should be C-only (and have most of the other runtime libraries apart from 
libgcc disabled), so you only build libstdc++ after you have a libc.

The only exception would be if your libc contains C++ code and depends on 
libstdc++ - I think this has been mentioned as an issue for Cygwin.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

On Tue, 27 Nov 2007, Benjamin Kosnik wrote:

> > if there is a rule that
> > libstdc++ configure shouldn't try to link anything, it doesn't appear
> > to be well enforced. 
> 
> The rule is that libstdc++ shouldn't do link tests unless it knows it
> is native. Not "libstdc++ configure shouldn't try to link anything."

Unless it knows it must be able to link anyway when building libstdc++.  
Which is the case in order to build (shared) libstdc++ for GNU/Linux.  
Where link tests are more reliable than compile tests, given that uClibc 
doesn't always disable header declarations just because functions are 
disabled in the library.

(Dependencies on native or not are a bad idea.  It's much better always to 
do the same thing for a GNU/Linux target - or any other target that can 
also be native - than to do things differently depending on whether the 
same target is native or cross.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Joseph S. Myers wrote:
> On Tue, 27 Nov 2007, Mark Mitchell wrote:
> 
>> In any case, I think this is something that ought to be decided as a
>> global policy for GCC and its run-time libraries, not something that
>> differs between ports.  In particular, if run-time libraries are allowed
>> to depend on linking in their configure tests, that's something everyone
>> should know.
> 
> For GNU/Linux, we decided some time ago that libstdc++ configuration would 
> require link tests in order to identify the precise functions available in 
> that particular multilib's libc version and configuration (depending, for 
> example, on how uClibc is configured).

Yes, that makes sense to me.  Bare metal systems are of course somewhat
different.  What do you think about that?

> If only static libraries are being built, it may be possible to build them 
> without linking, and in such cases it may be possible to define a generic 
> set of libc symbols considered to be present, as libstdc++-v3/configure.ac 
> does with newlib.

Do you understand how MIPS/Power works?  I'd really like to know what
the difference is.  It might be an easy difference to resolve, or there
might be something more fundamental, but before we do anything I'd like
to know why one works and the other doesn't.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Bernd Schmidt wrote:

> If you wish to approve Jie's original patch, I'm not stopping you.

Do you have a pointer?  Otherwise, I'll poke around and find it.  I
don't have a preconceived notion here, and I'm not trying to kick up a
big fuss; I'm just trying to understand the situation better.

> What I'm trying to do here is to ensure that gcc-4.3 will work out of
> the box as a compiler for our uClinux distribution.

Understood.  Out of curiousity, do you eventually build a bfin-uclinux
compiler, once you've built uClibc, or do you just use the bfin-elf
compiler on uClinux?

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Joseph S. Myers]

On Tue, 27 Nov 2007, Mark Mitchell wrote:

> Yes, that makes sense to me.  Bare metal systems are of course somewhat
> different.  What do you think about that?

I think it's well established that at least some bare-metal systems 
default to not linking with any particular start-files (etc.).

> > If only static libraries are being built, it may be possible to build them 
> > without linking, and in such cases it may be possible to define a generic 
> > set of libc symbols considered to be present, as libstdc++-v3/configure.ac 
> > does with newlib.
> 
> Do you understand how MIPS/Power works?  I'd really like to know what
> the difference is.  It might be an easy difference to resolve, or there
> might be something more fundamental, but before we do anything I'd like
> to know why one works and the other doesn't.

* They only build static libstdc++.

* --with-newlib is used, either explicitly or implicitly if newlib is 
built in a combined tree.  (I do not know if it works with --with-newlib 
is not used and it's not a combined tree.)

* configure.ac then checks for --with-newlib and handles it specially by 
hardcoding information about the functions present.

* With --disable-shared, GLIBCXX_ENABLE_SYMVERS disables symbol versioning 
instead of trying to do certain link tests it would do if shared libraries 
are being built; it also does so if unable to link.

* Each other configure test that might wish to link also needs special 
handling or to be appropriately conditional.

* Such special handling is also needed in other target libraries that 
support bare-metal systems (some libraries such as libgomp and libmudflap 
may well not do so at all).


So make sure the build is using --disable-shared if you can't link; if 
that still doesn't help, some configure test somewhere may need disabling, 
either if unable to link, or if not building shared libraries, or some 
other condition.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Link tests after GCC_NO_EXECUTABLES

[Benjamin Kosnik]

> (Dependencies on native or not are a bad idea.  It's much better
> always to do the same thing for a GNU/Linux target - or any other
> target that can also be native - than to do things differently
> depending on whether the same target is native or cross.)

Agreed.

When we have a staged build directory, with all the libs that gcc +
deps need in one canonical place, named coherently and
consistently, built with proper deps, then we can use link tests.

Till then, we bite it, avoid, and hard-code the minimum amount
necessary.

It's not optimum, but it's well established procedure. Let's not change
this at random, on a per-port basis. Or, if we do, let's have a plan
and communicate it clearly, with a full transition by all the runtime
libs.

Haphazardly breaking stuff is weak.

-benjamin

Compiler fails to find header files.

[mofomojo]

When I compile any program with GCC, specifying that it is a .c file
and that I want to compile it as a C-file to produce a binary, I get -
with any file - something like this :


 "*any source file here* :stdio.h: No such file or directory"


I have the libraries installed, and EVEN if I specify the location of
the file - in a command like -I/usr/lib/include/gcc/i486
-linux-gnu/4.1.2/include/ssp/ (where the system headers are
installed)I still get the output ...


 "*any source file here*:stdio.h: No such file or directory"


where, obviously, stdio.h is a system header file specified by the .c
source file to be compiled with. I don't know much about programming
or anything like that, but I do know that something is wrong somewhere
and that my compiler isn't configured right to find the files... or
something like that.

I have installed, on my system, Debian 4.0 Gnu/Linux with GCC
installed from the CD provided from the Debian distribution site
(debian.org ).  I've struggled at this for hours trying to figure what
is wrong, and I've wasted most of the daylight today trying at this
which is very valuable to me, seeing as winter is approaching and I
get very little daylight as is with school and everything :(

 this is the summary of the output for what I tried to compile here.
It failed to produce the binary.

 gcc -g -I/usr/lib/include/gcc/i486-linux-gnu/4.1.2/include/ssp/ -c
pdf417decode.c
 pdf417decode.c:39:19: error: stdio.h: No such file or directory



If anyone could help, I would be very very gracious so I don't waste
any more time on this problem. It's really giving me headaches.

P.S. I sent the same help info to the [EMAIL PROTECTED] address as
well and have yet to receive any response after about 3 hours. Thank
you very much for reading this.

svn trunk reaches nearly 1 GiB!!! That massive!!!

[J.C. Pizarro]

$ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
$ du -s .
1044451 .
$

It's 1'069'517'824 characters made from keyboards and generators!!!

That massive!!! And slower checkout after several minutes!!!

Is not there any another solution to reduce this massive quantity
for the most recent part of the trunk of the tree instead of full trunk?

   J.C.Pizarro

Re: svn trunk reaches nearly 1 GiB!!! That massive!!!

[Ismail Dönmez]

Wednesday 28 November 2007 Tarihinde 04:04:18 yazmıştı:
> $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> $ du -s .
> 1044451 .
> $
>
> It's 1'069'517'824 characters made from keyboards and generators!!!
>
> That massive!!! And slower checkout after several minutes!!!
>
> Is not there any another solution to reduce this massive quantity
> for the most recent part of the trunk of the tree instead of full trunk?

git clone --depth 100 git://git.infradead.org/gcc.git

should give around ~50mb repository with usable trunk. This is all thanks to 
Bernardo Innocenti for setting up an up-to-date gcc git repo.

P.S: Please cut down on the usage of exclamation mark.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: svn trunk reaches nearly 1 GiB!!! That massive!!!

[Joe Buck]

On Wed, Nov 28, 2007 at 03:04:18AM +0100, J.C. Pizarro wrote:
> $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> $ du -s .
> 1044451 .
> $
> 
> It's 1'069'517'824 characters made from keyboards and generators!!!

Divide by at least 2, since your svn checkout has the files, plus
a database containing the same files again.

Re: svn trunk reaches nearly 1 GiB!!! That massive!!!

[J.C. Pizarro]

On 2007/11/28, Ismail DAnmez <[EMAIL PROTECTED]> wrote:
> > $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> > $ du -s .
> > 1044451 .
> > $
> >
> > It's 1'069'517'824 characters made from keyboards and generators!!!
> >
> > That massive!!! And slower checkout after several minutes!!!
> >
> > Is not there any another solution to reduce this massive quantity
> > for the most recent part of the trunk of the tree instead of full trunk?
>
> git clone --depth 100 git://git.infradead.org/gcc.git
>
> should give around ~50mb repository with usable trunk. This is all thanks to
> Bernardo Innocenti for setting up an up-to-date gcc git repo.

In the menu [ "Live" Sources ] from http://gcc.gnu.org/ , besides SVN, it
should appear this GIT (speeder help for speeder developers) too.

git clone --depth 100 git://git.infradead.org/gcc.git

or in the future

git clone --depth 100 git://gcc.gnu.org/gcc.git

for faster checkout and development.

   J.C.Pizarro

Re: Progress on GCC plugins ?

[Ian Lance Taylor]

Alexandre Oliva <[EMAIL PROTECTED]> writes:

> On Nov 26, 2007, Tom Tromey <[EMAIL PROTECTED]> wrote:
> 
> > I do wonder if there is a platform out there that acts as if -rdynamic
> > were the default.
> 
> I'm pretty sure I was surprised when I first ran into the need for
> -rdynamic on GNU/Linux, because other platforms I'd used didn't need
> that.  I'd guess that would have been SunOS4.1.3 or maybe Solaris2.1,
> back then.

-rdynamic was the default on SunOS and on SVR4.  It was not the
default on Solaris.  It is not the default for the GNU linker because
I was copying the Solaris linker.

Ian

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Joseph S. Myers wrote:
> On Tue, 27 Nov 2007, Mark Mitchell wrote:
> 
>> Yes, that makes sense to me.  Bare metal systems are of course somewhat
>> different.  What do you think about that?
> 
> I think it's well established that at least some bare-metal systems 
> default to not linking with any particular start-files (etc.).

Sorry, I meant to be asking: "for bare-metal, do you think we should
permit the library configure scripts to perform link tests (as we do for
GNU/Linux), or should we require that they perform no link tests?"

>> Do you understand how MIPS/Power works?  I'd really like to know what
>> the difference is.  It might be an easy difference to resolve, or there
>> might be something more fundamental, but before we do anything I'd like
>> to know why one works and the other doesn't.

Thanks for answering this.  Bernd, I'd be interested in whether any of
that helps.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Compiler fails to find header files.

[NightStrike]

On Nov 27, 2007 8:42 PM, mofomojo <[EMAIL PROTECTED]> wrote:
> P.S. I sent the same help info to the [EMAIL PROTECTED] address as
> well and have yet to receive any response after about 3 hours. Thank
> you very much for reading this.

That is outrageous!  3 Hours?  I will send an immediate TPS report as
a memo to upper management, and we will start compliance training post
haste to rectify this glaring deficiency in customer service.  My
apologies to you, good sir.  Please accept these coupons as a token of
goodwill.

Re: Link tests after GCC_NO_EXECUTABLES

[Hans-Peter Nilsson]

On Tue, 27 Nov 2007, Mark Mitchell wrote:
> > If only static libraries are being built, it may be possible to build them
> > without linking, and in such cases it may be possible to define a generic
> > set of libc symbols considered to be present, as libstdc++-v3/configure.ac
> > does with newlib.
>
> Do you understand how MIPS/Power works?  I'd really like to know what
> the difference is.  It might be an easy difference to resolve, or there
> might be something more fundamental, but before we do anything I'd like
> to know why one works and the other doesn't.

I don't, but IIRC one thing that was necessary at one time for
CRIS (cris-elf; supposedly bare-metal newlib) was to a bit
hackishly copy the libgloss startup files to the newlib build
directory where they were expected as per
.

You'll get a "X is not implemented and will always fail" warning
from linking with the non-working default stub functions when
not linking in any board-support package, so IMHO there are no
false pretenses about having built a correct program.

Not a proposed solution, just a datapoint of the hackery that's
pragmatically and historically been needed.  I think at the
time, I just noticed that a toolchain that built (might have
been ppc, might have been mips) happened to have a stub crt0.o
in a place that corresponded to search paths (newlib rather than
libgloss) when linking.

brgds, H-P

Re: GCC 4.3.0 Status Report (2007-11-27)

[Doug Gregor]

On Nov 27, 2007 4:19 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 1. I noticed that there are quite a few P2 ICE reports regarding
>variadic templates.  Doug Gregor, would you please look into these?

There are patches for a few of these issues (two P2s and a P3) that
still need review; see the links below. I'm swamped until the end of
the week, but I'll take a shot at fixing more of these after Saturday.

>Jason, would you be able to review Doug's patches (as the arrive),
>given that you've looked at much of the rest of his code?

There are a few variadic templates patches still to be reviewed:

  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00323.html
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00973.html
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00970.html

   - Doug

Re: GCC 4.3.0 Status Report (2007-11-27)

[Andreas Meier]

> We've made some progress over the past couple of weeks.  Kudos to all
> who have been contributing and reviewing patches!  In particular,
>we've made a dent in P2s, and are now down to 134 total regressions
> open.

This numbers are from the link of the main page: 
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3&target_milestone=4.0.4&target_milestone=4.1.3&target_milestone=4.2.3&target_milestone=4.3.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

If you use the following link: 
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3+regression&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

you can see 137 regression with high priority. 

With 
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.3+regression&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
 

you can see all 251 regression.

In my opinion you should change the links on the main page to these, so bugs 
with no target are not forgotten.

With
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=%5B4.3+regression&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

you can see the 71 new regression in 4.3

and with
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=%5B4.3+regression&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

you can see the 57 new regression with high priority.


Greets

Andreas Meier
  


-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos