enable __mt_alloc?

[Ola Rönnerup]

Hi,

How do I enable the use of the __mt_alloc-allocator instead of the default one?

I've searched google without any success more than internal documentation on 
mt_alloc.

Using: gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)

regards,
Robin

Re: enable __mt_alloc?

[R Hill]

Ola Rönnerup wrote:
Hi,
How do I enable the use of the __mt_alloc-allocator instead of the default one?
this patch applies to gcc-4 but i think it will give you an idea where 
to look.

http://cvs.fedora.redhat.com/viewcvs/*checkout*/devel/gcc/gcc4-libstdc%2B%2B-mt-alloc.patch

Wiki on home page

[dmdlf]

I note that you have a wiki from 27 January 2005.
It is made known by a line in the News/Announcements, which will 
disappear at some time, and anyway is not always the first reading for 
people.
I suggest that, when the state of the wiki will be mature enough from 
your perspective, to insert the wiki in the left column under 
Documentation an maybe also in your Welcome.
Regards.
Denis

Re: Stage2 Miscompilaton of Ada?

[Christian Joensson]

On 5/13/05, Andreas Jaeger <[EMAIL PROTECTED]> wrote:
> Anybody with the same problem?

maybe, maybe not, I'm in an endless loop at 


stage2/xgcc -Bstage2/ -B/usr/local/sparc-linux/bin/ -c -g -O2 
-gnatpg -gnata -I- -I. -Iada
-I/usr/local/src/trunk/gcc-binutils/gcc/ada
/usr/local/src/trunk/gcc-binutils/gcc/ada/ada.ads -o ada/ada.o

that was with LAST_UPDATED about Wed May 11 23:40:49 CEST 2005

-- 
Cheers,

/ChJ

Re: Stage2 Miscompilaton of Ada?

[Graham Stott]

Andreas,

I've had the same problem since updating on Wednesday evening :-( It did
bootstrap overnight Tuesday.

Cheers
Graham

Mainline broken

[Steven Bosscher]

Hi Joern,

You broke mainline.

gcc -c   -O0 -g -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes  -fno-common -DHAVE_CONFIG_H-I. -I. 
-I../../mainline/gcc -I../../mainline/gcc/. -I../../mainline/gcc/../include 
-I../../mainline/gcc/../libcpp/include  ../../mainline/gcc/fold-const.c -o 
fold-const.o
../../mainline/gcc/flow.c: In function `propagate_one_insn':
../../mainline/gcc/flow.c:1698: error: `PROP_DEAD_INSN' undeclared (first use 
in this function)
../../mainline/gcc/flow.c:1698: error: (Each undeclared identifier is reported 
only once
../../mainline/gcc/flow.c:1698: error: for each function it appears in.)
../../mainline/gcc/flow.c: In function `mark_set_1':
../../mainline/gcc/flow.c:2967: error: `PROP_DEAD_INSN' undeclared (first use 
in this function)
make[1]: *** [flow.o] Error 1

Seems like your forgot the basic-block.h bits in this commit:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00621.html

Gr.
Steven

Re: Mainline broken

[Joern RENNECKE]

Steven Bosscher wrote:
Seems like your forgot the basic-block.h bits in this commit:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00621.html
Gr.
Steven
 

Sorry.  Checked in now.

Re: check_ext_dependent_givs

[Canqun Yang]

Hi, all,

I do not want to modify the old loop optimizer defined 
in loop.c. I am preparing to port some improvements 
done on gcc-3.5 to gcc-4.0, and the GIV optimizations 
is one of my concerns.

On IA-64, the GIV optimizations can hardly improve the 
performance. The reason is that 
check_ext_dependent_givs can not give an exactly 
answer whether the BIVs will be wrap around or not. As
check_ext_dependent_givs can only deal with BIVs in 
constant-iteration loops or BIVs are the same as the 
loop iteration variable, and only small parts of BIVs 
satisfy this condition, that in most cases, only a 
conservative result is produced to report that the 
BIVs may overflow and the corresponding GIVs can not 
be reduced. 

I modified the code in check_ext_dependent_givs to let 
the BIVs always successfully pass the check, then 
tested the NAS benchmarks and SPEC CPF2000 benchmarks, 
excepting significant performance improvements, no 
extra errors occurred.

I have read the codes in check_ext_dependent_givs and 
the mails abount BIV overflow checking in GCC's 
mailing list written by Richard Henderson and Zdenek 
Dvorak, also tested the example Paolo Bonzini sent to 
me. But I still have some questions about this.

1. There is an option '-fwrapv' to control the 
behavior of signed overflows. Can it also be used in 
check_ext_dependent_givs?

2. If check_ext_dependent_givs has not been invoked, 
the program will give wrong result, otherwise, 
correct. Would you please send me an example to show 
this?  (FORTRAN programs are nicer).

3. For FORTRAN programs, is there any thing special. 
As I know, only signed integers in FORTRAN, also the 
counted loops in FORTRAN are more strict than in C?

4. Is it reasonable to turn off this checking at some 
optimization level or with compile options like '-
ffast-math' and '-fno-wrapv'?

5. Is there any way to extend the function of 
check_ext_dependent_givs to manage 
non-iteration-variable BIVs in non-constant-iteration 
loops. I have tried but failed. 


Best regards,

Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.

a question about peephole2

[zouq]

first i want to generate a three-operator multiply-add instruction similar
to four-operator multiply-add instruction in mips4 instruction sets.

i modify the gcc/config/mips/mips.md file as follow:
(define_peephole2
 [ (set (match_operand:SF 0 "register_operand" "=f")
(mult:SF (match_operand:SF 1 "register_operand" "f")
 (match_operand:SF 2 "register_operand" "f")))
 (set (match_operand:SF 3 "register_operand" "=f")
(plus:SF (match_operand:SF 4 "register_operand" "f")
 (match_operand:SF 5 "register_operand" "f")))]
   "ISA_HAS_MADD && TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT &&
TARGET_FUSED_MADD
   && ((rtx_equal_p(operands[3], operands[4]) && rtx_equal_p(operands[0],
operands[5]))
   ||  (rtx_equal_p(operands[3], operands[5]) && rtx_equal_p(operands[0],
operands[4])))"
  [(set (match_operand:SF 3 "register_operand" "=f")
(plus:SF (mult:SF (match_operand:SF 1 "register_operand" "f")
  (match_operand:SF 2 "register_operand" "f"))
 (match_dup 3)))
(clobber (match_dup 0))]
   "")

(define_insn ""
  [(set (match_operand:DF 0 "register_operand" "=f")
(plus:DF (mult:DF (match_operand:DF 1 "register_operand" "f")
  (match_operand:DF 2 "register_operand" "f"))
 (match_dup 0)))]
  "ISA_HAS_MADD && TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT &&
TARGET_FUSED_MADD "
  "madd.d\t%0,%1,%2"
  [(set_attr "type" "fmadd")
   (set_attr "mode" "DF")])

in many spec2000 cases , it can success to generate multiply-add
instrutions, but the problem i encounter now is:

original program is:
mul.d $f1, $f1, $f0
add.d $f2, $f2, $f1
div.d $f3, $f0, $f1;

after i compile used my changed gcc, it becomes:
madd.d $f2, $f1, $0
div.d  $f3, $f0, $f1

as you can see, the value of $f1 is wrong!!

How can i avoid it? modify my md???

RE: -fdump-translation-unit considered harmful

[Dams, Dennis (Dennis)]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Friday, May 13, 2005 12:33 PM
> To: Adam Nemet
> Cc: Ian Lance Taylor; Dams, Dennis (Dennis); [EMAIL PROTECTED]
> Subject: Re: -fdump-translation-unit considered harmful
> 
> Adam Nemet <[EMAIL PROTECTED]> writes:
> 
> | Ian Lance Taylor  writes:
> | > -fdump-translation-unit doesn't do anything in the C frontend.
> | 
> | Is the patch below OK to update documentation accordingly?  Tested 
> | with make info and make dvi.
> 
> OK.
> 
> Thanks,
> 
> -- Gaby
>

Have there been any new thoughts/developments on the issue of elevating the 
current dump facilities (-fdump-translation-unit, and the -fdump-tree 
functionality) to a more formal API?

We're working on a tool for static code analysis (aimed at verification issues 
and program understanding, rather than compile-time optimization). One kind of 
input that the tool can handle is the .t00.tu format as produced (for C) by an 
older version of the tree-ssa (in fact, the ast-optimizer) branch. Still, we 
had to make a few adjustments to make the dump format more useful - e.g.:

* preventing the disposal of trees of function bodies, so that the dump 
includes all file-level definitions
* preventing the insertion of pointer-offsets
* adding double quotes around strings, and escaping certain characters in them, 
so as to make parsing easier

It would be great if this behavior could be made part of the current GCC 
release. But it would be even better if there could be some prior agreement, 
among those who would be interested, about what a reasonable tree-dump format 
should look like.
And then there are the legal issues - I don't actually know what the conclusion 
was of the discussions in this thread last Dec./Jan.
--dennis.

Re: Stage2 Miscompilaton of Ada?

[Andreas Jaeger]

Diego,

it looks like it's this change:

+2005-05-10  Diego Novillo  <[EMAIL PROTECTED]>
+
+   * tree-optimize.c (init_tree_optimization_passes): Re-organize
+   optimization passes to do an initial batch of scalar cleanups.
+

which is rather unfortunate since this means we have some kind of
miscompilation.

Can you try bootstrapping with Ada included on x86-64 or ppc and does
this work for you?

Andreas

Andreas Jaeger <[EMAIL PROTECTED]> writes:

> Yesterday I tried building gcc again for the first time since two
> weeks and encountered what looks like an endless loop.
>
> This command:
> stage2/xgcc -Bstage2/ -B/opt/gcc/4.1-devel/x86_64-suse-linux-gnu/bin/ -c -g 
> -O2
>  -gnatpg -gnata -g -O1 -fno-inline \
>  -I- -I. -Iada -I/cvs/gcc/gcc/ada /cvs/gcc/gcc/ada/a-except.adb -o 
> ada/a-except.
> o
>
> was running for several hours.
> [...]

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpWlETtrS24D.pgp
Description: PGP signature

Re: Stage2 Miscompilaton of Ada?

[Andreas Jaeger]

Christian Joensson <[EMAIL PROTECTED]> writes:

> On 5/13/05, Andreas Jaeger <[EMAIL PROTECTED]> wrote:
>> Anybody with the same problem?
>
> maybe, maybe not, I'm in an endless loop at 

Yes, that's the same problem, if I do a parallel build, it hanges
there also...

>
> stage2/xgcc -Bstage2/ -B/usr/local/sparc-linux/bin/ -c -g -O2 
> -gnatpg -gnata -I- -I. -Iada
> -I/usr/local/src/trunk/gcc-binutils/gcc/ada
> /usr/local/src/trunk/gcc-binutils/gcc/ada/ada.ads -o ada/ada.o
>
> that was with LAST_UPDATED about Wed May 11 23:40:49 CEST 2005

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpUC0iaIzxn2.pgp
Description: PGP signature

Re: mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

[H. J. Lu]

On Thu, May 12, 2005 at 10:20:22PM -0400, Diego Novillo wrote:
> On Thu, May 12, 2005 at 05:33:05PM -0700, H. J. Lu wrote:
> 
> > I got the same comparsion failure.
> > 
> Have you tried with Zdenek's patch to LSM that I approved earlier today?
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01150.html
> 

It works on Linux/ia32 and Linux/EM64T now. But Linux/ia64 failed for
other reasons:

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


H.J.

Re: Stage2 Miscompilaton of Ada?

[Andrew Pinski]

On May 13, 2005, at 12:49 PM, Andreas Jaeger wrote:
Diego,
it looks like it's this change:
+2005-05-10  Diego Novillo  <[EMAIL PROTECTED]>
+
+   * tree-optimize.c (init_tree_optimization_passes): Re-organize
+   optimization passes to do an initial batch of scalar cleanups.
+
which is rather unfortunate since this means we have some kind of
miscompilation.
Can you try bootstrapping with Ada included on x86-64 or ppc and does
this work for you?
This would be PR 21029.
-- Pinski

Re: -fdump-translation-unit considered harmful

[Gabriel Dos Reis]

"Dams, Dennis (Dennis)" <[EMAIL PROTECTED]> writes:

|  
| 
| > -Original Message-
| > From: [EMAIL PROTECTED] 
| > [mailto:[EMAIL PROTECTED] 
| > Sent: Friday, May 13, 2005 12:33 PM
| > To: Adam Nemet
| > Cc: Ian Lance Taylor; Dams, Dennis (Dennis); [EMAIL PROTECTED]
| > Subject: Re: -fdump-translation-unit considered harmful
| > 
| > Adam Nemet <[EMAIL PROTECTED]> writes:
| > 
| > | Ian Lance Taylor  writes:
| > | > -fdump-translation-unit doesn't do anything in the C frontend.
| > | 
| > | Is the patch below OK to update documentation accordingly?  Tested 
| > | with make info and make dvi.
| > 
| > OK.
| > 
| > Thanks,
| > 
| > -- Gaby
| >
| 
| Have there been any new thoughts/developments on the issue of
| elevating the current dump facilities (-fdump-translation-unit, and
| the -fdump-tree functionality) to a more formal API? 

Not that I'm aware of.

Although I understand the utility of this flag, I do believe it is
premature and probably not well suited to define any formal API at
this point. 

[...]

| It would be great if this behavior could be made part of the current
| GCC release. But it would be even better if there could be some
| prior agreement, among those who would be interested, about what a
| reasonable tree-dump format should look like. 

I have gone over several formats for improved debugging information,
but I think we still need more experience.  At any case, it would not
be something that will have a formal API.  I consider it to be a
debugging aid; I would hate to be distracted from technical issues
into political matters.

-- Gaby

Is there a way to generate a cross reference listing for a c/c++ program using gcc?

[Paul Albrecht]

Is there a way to generate a cross reference listing for a c/c++ program
using gcc?

sh-elf tree-ssa failure

[Joern RENNECKE]

execute/20031215-1.c passes on i686 and ppc, but fails on sh-elf - both 
SH1 big endian and SH4 little endian, eight times each.
It still shows the same failure with mainline from 17:00 UTC today.

Executing on host: /mnt/scratch/nightly/2005-05-11/sh-elf/gcc/xgcc 
-B/mnt/scratch/nightly/2005-05-11/sh-elf/gcc/ 
/mnt/scratch/nightly/2005-05-11/srcw/gcc/testsuite/gcc.c-torture/execute/20031215-1.c  
-w  -O2  -DSTACK_SIZE=16384 -fno-show-column  -isystem 
/mnt/scratch/nightly/2005-05-11/sh-elf/sh-elf/./newlib/targ-include 
-isystem /mnt/scratch/nightly/2005-05-11/srcw/newlib/libc/include  
-L/mnt/scratch/nightly/2005-05-11/sh-elf/ld 
-B/mnt/scratch/nightly/2005-05-11/sh-elf/sh-elf/./newlib/ 
-L/mnt/scratch/nightly/2005-05-11/sh-elf/sh-elf/./newlib  -lm 
-Wl,--defsym,_stack=0xff000  -o 
/mnt/scratch/nightly/2005-05-11/sh-elf/gcc/testsuite/20031215-1.x2
(timeout = 300)
/mnt/scratch/nightly/2005-05-11/srcw/gcc/testsuite/gcc.c-torture/execute/20031215-1.c: 
In function 'test1':^M
/mnt/scratch/nightly/2005-05-11/srcw/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11: 
error: Statement makes a memory store, but has no V_MAY_DEFS nor 
V_MUST_DEFS^M
#   VUSE ;^M
ao.ch[2] = 0;^M
/mnt/scratch/nightly/2005-05-11/srcw/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11: 
internal compiler error: verify_ssa failed.^M

Re: sh-elf tree-ssa failure

[Andrew Pinski]

On May 13, 2005, at 2:18 PM, Joern RENNECKE wrote:
execute/20031215-1.c passes on i686 and ppc, but fails on sh-elf - 
both SH1 big endian and SH4 little endian, eight times each.
It still shows the same failure with mainline from 17:00 UTC today.
Huh, it fails on all targets.
-- Pinski

Re: sh-elf tree-ssa failure

[Joern RENNECKE]

Andrew Pinski wrote:
   
Huh, it fails on all targets.

-- Pinski
Sorry, my bad.  It passes at -O0 and -O1 on all targets, and fails at 
-Os etc on all of them, too.
I incorrectly asumed that eight errors per multilib must mean it fails 
across the board.

Re: a question about peephole2

[Richard Henderson]

On Fri, May 13, 2005 at 11:37:16PM +0800, zouq wrote:
> original program is:
> mul.d $f1, $f1, $f0
> add.d $f2, $f2, $f1
> div.d $f3, $f0, $f1;
> 
> after i compile used my changed gcc, it becomes:
> madd.d $f2, $f1, $0
> div.d  $f3, $f0, $f1
> 
> as you can see, the value of $f1 is wrong!!

Check

  (rtx_equal_p (operands[3], operands[0])
   || peep2_reg_dead_p (2, operands[0]))


r~

rtl printing

[Andrew MacLeod]

Do we currently have an RTL infix printing mechanism hidden away
somewhere?  I seem to vaguely recall new-ra might have had something
once upon a time...  I also suspect others have fooled with it over the
years.   

Is there code laying around I can snarf and work with? 

Andrew

Re: rtl printing

[Richard Henderson]

On Fri, May 13, 2005 at 02:31:12PM -0400, Andrew MacLeod wrote:
> Is there code laying around I can snarf and work with? 

See sched-vis.c.


r~

Re: Is there a way to generate a cross reference listing for a c/c++ program using gcc?

[E. Weddington]

Paul Albrecht wrote:
Is there a way to generate a cross reference listing for a c/c++ program
using gcc?
 

-Wl,-Map=mapfile.map,--cref
Docs for -Wl option:

Docs for linker options (-Map, --cref):

Questions like this are more topical for the gcc-help mailing list:

Eric

Re: Is there a way to generate a cross reference listing for a c/c++ program using gcc?

[Paul Albrecht]

Eric writes:

>
> -Wl,-Map=mapfile.map,--cref
>

I'm not looking for a cross-reference from a symbol to its memory location
in linked file, rather a cross-reference from a symbol definition in a
program source file to its line number references in all the program source
files.

Re: rtl printing

[Daniel Berlin]

On Fri, 2005-05-13 at 14:31 -0400, Andrew MacLeod wrote:
> Do we currently have an RTL infix printing mechanism hidden away
> somewhere?  I seem to vaguely recall new-ra might have had something
> once upon a time...  I also suspect others have fooled with it over the
> years.   

Yes, new-ra has a whole bunch of code devoted to printing RTL so it
looks like three address code.  IE

r12 = r13 + r14
clobber r15
r15 = 4(r14)

> 
> Is there code laying around I can snarf and work with? 
> 
> Andrew
> 

Re: Is there a way to generate a cross reference listing for a c/c++ program using gcc?

[Daniel Berlin]

On Fri, 2005-05-13 at 14:49 -0500, Paul Albrecht wrote:
> Eric writes:
> 
> >
> > -Wl,-Map=mapfile.map,--cref
> >
> 
> I'm not looking for a cross-reference from a symbol to its memory location
> in linked file, rather a cross-reference from a symbol definition in a
> program source file to its line number references in all the program source
> files.
> 

It's probably easiest to snarf that from the debug information produced
in the executable with -g.

unexpected hidden symbol in gcc 4.0.0

[Paul Koning]

I ran into link errors complaining about references to hidden symbol
_Unwind_GetIP from a DSO.

It turns out unwind-dw2.c is compiled with -fvisibility=hidden for the
static library case (but not for the shared library case).

In my link, I was using the libgcc.a (for that particular platform I
don't use libgcc.so).  So the linker complained.

The documentation for -fvisibility=hidden suggets that this switch is
useful for shared libraries, to make things smaller and faster.  It
doesn't seem to be appropriate for object libraries. 

I suppose I can override the "hidden" attribute for that one symbol,
or change Makefiles so that switch isn't put there, but I'm wondering
why this change and why the mismatch between usage and documentation.

paul

Re: unexpected hidden symbol in gcc 4.0.0

[Andrew Pinski]

On May 13, 2005, at 5:33 PM, Paul Koning wrote:
I ran into link errors complaining about references to hidden symbol
_Unwind_GetIP from a DSO.
It turns out unwind-dw2.c is compiled with -fvisibility=hidden for the
static library case (but not for the shared library case).
In my link, I was using the libgcc.a (for that particular platform I
don't use libgcc.so).  So the linker complained.
In that case, C++ exceptions for your target will never work correctly.
Anyways, -fvisibility=hidden is needed for libgcc.a (This was done a
different way in the past, by editing the assembly file) because
otherwise, you can have the same symbol exported from two different
shared libraries which is bad.
-- Pinski

Re: unexpected hidden symbol in gcc 4.0.0

[Daniel Jacobowitz]

On Fri, May 13, 2005 at 05:33:21PM -0400, Paul Koning wrote:
> I ran into link errors complaining about references to hidden symbol
> _Unwind_GetIP from a DSO.
> 
> It turns out unwind-dw2.c is compiled with -fvisibility=hidden for the
> static library case (but not for the shared library case).
> 
> In my link, I was using the libgcc.a (for that particular platform I
> don't use libgcc.so).  So the linker complained.
> 
> The documentation for -fvisibility=hidden suggets that this switch is
> useful for shared libraries, to make things smaller and faster.  It
> doesn't seem to be appropriate for object libraries. 
> 
> I suppose I can override the "hidden" attribute for that one symbol,
> or change Makefiles so that switch isn't put there, but I'm wondering
> why this change and why the mismatch between usage and documentation.

It sounds like you are building with --enable-shared and then
picking/choosing the libraries, but you haven't described how you
build, so I'm just guessing.

Normally in an --enable-shared build the copy in libgcc_eh.a has hidden
visibility, and can be included in built libraries.  The copy in
libgcc_s.so.1 is globally visible.

You are also misinterpreting the problem.  The hidden symbol is not the
problem; libstdc++ with an undefined reference to _Unwind_GetIP, and no
dependency on libgcc_s.so.1, is the problem.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: unexpected hidden symbol in gcc 4.0.0

[Paul Koning]

> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

 Daniel> On Fri, May 13, 2005 at 05:33:21PM -0400, Paul Koning wrote:
 >> I ran into link errors complaining about references to hidden
 >> symbol _Unwind_GetIP from a DSO.
 >> 
 >> It turns out unwind-dw2.c is compiled with -fvisibility=hidden for
 >> the static library case (but not for the shared library case).
 >> 
 >> In my link, I was using the libgcc.a (for that particular platform
 >> I don't use libgcc.so).  So the linker complained.
 >> 
 >> The documentation for -fvisibility=hidden suggets that this switch
 >> is useful for shared libraries, to make things smaller and faster.
 >> It doesn't seem to be appropriate for object libraries.
 >> 
 >> I suppose I can override the "hidden" attribute for that one
 >> symbol, or change Makefiles so that switch isn't put there, but
 >> I'm wondering why this change and why the mismatch between usage
 >> and documentation.

 Daniel> It sounds like you are building with --enable-shared and then
 Daniel> picking/choosing the libraries, but you haven't described how
 Daniel> you build, so I'm just guessing.

 Daniel> Normally in an --enable-shared build the copy in libgcc_eh.a
 Daniel> has hidden visibility, and can be included in built
 Daniel> libraries.  The copy in libgcc_s.so.1 is globally visible.

 Daniel> You are also misinterpreting the problem.  The hidden symbol
 Daniel> is not the problem; libstdc++ with an undefined reference to
 Daniel> _Unwind_GetIP, and no dependency on libgcc_s.so.1, is the
 Daniel> problem.

Ok, I can work on that.

The puzzle is that the build procedure is unchanged from gcc 3.3.3,
and with that version the application builds just fine.  It just drags
in unwind_dw2.o from libgcc.a and all is well.

   paul

Re: unexpected hidden symbol in gcc 4.0.0

[Richard Henderson]

On Fri, May 13, 2005 at 05:33:21PM -0400, Paul Koning wrote:
> The documentation for -fvisibility=hidden suggets that this switch is
> useful for shared libraries, to make things smaller and faster.  It
> doesn't seem to be appropriate for object libraries. 

It's done *exactly* so that we catch this bug in your configury.


r~

Re: Is there a way to generate a cross reference listing for a c/c++ program using gcc?

[William Beebe]

If you want that kind of cross referencing, then you shouild look at
Doxygen (http://www.stack.nl/~dimitri/doxygen/). It will produce
excellent cross references for HTML, Latex, RTF, and XML. There are
pre-built binaries for Linux distributions, Solaris, and Windows, and
Doxygen is usually in most current Linux distributions.

On 5/13/05, Paul Albrecht <[EMAIL PROTECTED]> wrote:
> Is there a way to generate a cross reference listing for a c/c++ program
> using gcc?
> 
>

GCC 3.4.4 RC2

[Mark Mitchell]

GCC 3.4.4 RC2 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
There are just a few changes from RC1 to fix critical problems people 
experienced with RC1.

Please download, build, and test.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

gcc-3.4-20050513 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050513 

You'll find:

gcc-3.4-20050513.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20050513.tar.bz2 C front end and core compiler

gcc-ada-3.4-20050513.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20050513.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20050513.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20050513.tar.bz2 Java front end and runtime

gcc-objc-3.4-20050513.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20050513.tar.bz2The GCC testsuite

Diffs from 3.4-20050506 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: a question about peephole2

[zouq]

en,i still have a problem,
the MAX_INSNS_PER_PEEP2 is 3,
when the program case is :
mul.d $f1, $f1, $f0
add.d $f2, $f2, $f1
sub.d $f3, $f3, $f2
sdc1  $f3, 0(v0)
addiu v0, v0, 1
add.d $f3, $f4, $f2
sdc1
> On Fri, May 13, 2005 at 11:37:16PM +0800, zouq wrote:
>> original program is:
>> mul.d $f1, $f1, $f0
>> add.d $f2, $f2, $f1
>> div.d $f3, $f0, $f1;
>>
>> after i compile used my changed gcc, it becomes:
>> madd.d $f2, $f1, $0
>> div.d  $f3, $f0, $f1
>>
>> as you can see, the value of $f1 is wrong!!
>
> Check
>
>   (rtx_equal_p (operands[3], operands[0])
>|| peep2_reg_dead_p (2, operands[0]))
>
>
> r~
>

Need help creating a small test case for g++ 4.0.0 bug

[Paul C. Leopardi]

Hi all,
I originally posted these messages to gcc-help, but had no reply, so I am 
re-posting links to them here. 

I think I have found a bug in g++ 4.0.0, but need help in reporting it. 
Maintainers like their bug reports to include short test cases, but I don't 
know how to generate a short test case involving inlining. I discovered the 
original problem by compiling GluCat ( http://glucat.sf.net ) and the 
preprocessor output from a short GluCat test program contains over 66 000 
lines of libstdc++, uBLAS and Glucat code.

Can anyone help, or should I just file a bug report using the huge test case?

The original posts were:

g++ 4.0.0: hash_map hangs when compiled with -O3 on AMD64
http://gcc.gnu.org/ml/gcc-help/2005-05/msg00030.html

Re: g++ 4.0.0: hash_map hangs when compiled with -O3 on AMD64
http://gcc.gnu.org/ml/gcc-help/2005-05/msg00087.html

I am particularly interested in the interference between hash_map, 
-fstrict-aliasing  and -finline-functions, and I wonder if it happens on 
other architectures, or only on AMD64.

Best regards, Paul Leopardi

PS.
If you try compling the current GluCat 0.1.8 using g++ 4.0.0, you will need 
the following patch.

diff 
-u /home/leopardi/src/glucat/glucat-0.1.8/glucat/portability.h ./portability.h
--- /home/leopardi/src/glucat/glucat-0.1.8/glucat/portability.h 2004-05-10 
21:28:42.0 +1000
+++ ./portability.h 2005-05-01 22:11:22.0 +1000
@@ -28,15 +28,15 @@
 #define ios_base ios // scope is different for standard C++
 #endif

-//* workaround for ICC and G++ 3.3+
-#if defined (__ICL) || defined (__ICC) || defined (__GNUG__) && (__GNUC__ >= 
3) && (__GNUC_MINOR__ >= 3)
+//* workaround for ICC, G++ 3.3+, G++ 4.0+
+#if defined (__ICL) || defined (__ICC) || defined (__GNUG__) && ((__GNUC__ == 
3) && (__GNUC_MINOR__ >= 3) || (__GNUC__ == 4))
 #define _GLUCAT_PRIVATE public
 #else
 #define _GLUCAT_PRIVATE private
 #endif

 //* workaround for G++ 3.2 typename bug
-#if defined (__GNUG__) && (__GNUC__ >= 3) && (__GNUC_MINOR__ <= 2)
+#if defined (__GNUG__) && (__GNUC__ == 3) && (__GNUC_MINOR__ <= 2)
 #define _GLUCAT_USE_STRUCT_NAME(T)
 #else
 #define _GLUCAT_USE_STRUCT_NAME(T) T::

Re: GCC 3.4.4 RC2

[Greg Schafer]

On Fri, May 13, 2005 at 03:44:59PM -0700, Mark Mitchell wrote:

> GCC 3.4.4 RC2 is now available here:
> 
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
> 
> There are just a few changes from RC1 to fix critical problems people 
> experienced with RC1.
> 
> Please download, build, and test.

Done.

Something went wrong with the libstdc++ testsuite. It doesn't show up in the
test results:

  http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00856.html

AFAICT, the libstdc++ testsuite _did_ run, but it doesn't show up. This
could be pilot error on my behalf, but I've followed the exact same scripted
procedure for ages so I don't think so.

Oops, I failed to realise it also happened with RC1:

  http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00670.html

I've run out of time right now and cannot investigate it immediately. Anyone
else seeing this? Quick browse of other test results suggests I'm not alone.
Maybe there's a BZ already? Dunno.

Thanks
Greg

Re: Need help creating a small test case for g++ 4.0.0 bug

[Andrew Pinski]

On May 13, 2005, at 10:16 PM, Paul C. Leopardi wrote:
+//* workaround for ICC, G++ 3.3+, G++ 4.0+
Why do you need this work around?  Why has this not been filed or really
fixed in their sources?
-- Pinski

Re: Need help creating a small test case for g++ 4.0.0 bug

[Paul C. Leopardi]

Andrew,
Thanks for reminding me about this. I'll need to take a good look at this. 

The effect of the workaround is to change any instance of _GLUCAT_PRIVATE to 
public. This does not affect the validity or otherwise of the g++ bug I'm 
currently trying to report.

I wrote GluCat at a time when earlier versions of ICC and gcc were not as 
compliant with the C++ standard. I'll have to take the current versions of 
ICC and gcc as correct, and change the code.
Best regards, Paul Leopardi
 
On Sat, 14 May 2005 02:03 pm, Andrew Pinski wrote:
> On May 13, 2005, at 10:16 PM, Paul C. Leopardi wrote:
> > +//* workaround for ICC, G++ 3.3+, G++ 4.0+
>
> Why do you need this work around?  Why has this not been filed or really
> fixed in their sources?
>
> -- Pinski

GCC 2.95.3 on Red Hat Entreprise Linux ES 3.0

[maha lakshmi]

Hello,

I would like know if GCC compiler 2.95.3 could be
installed on Red Hat Entreprise Linux ES 3.0 and
recompile 
C/C++ programs that were written/compiled earlier
using 2.95.3 GCC compiler on Sun Solaris V 2.6
machine.

Also would like to know the pros and cons in using GCC
2.95.3 in preference to the compiler version that is
shipped with Red Hat Entreprise Linux ES 3.0.

Thanks,
-Maha

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com