Re: Cannot configure gcc4.4.0 in order to build h8300 crosscompiler

[ariga masahiro]

Hello,

I am very sorry to have found previous mail was badly formatted.
I send the same text.

I found next patch in GCC project site.
From: Eric Christopher 
Date: Tue, 3 Jul 2007 08:35:21 -0700
Subject: [patch] conditionally declare bswap functions depending on target

Do you think it is effective ?

-- this is patch begin
--- libgcc2.h (revision 126242)
+++ libgcc2.h (working copy)
@@ -342,18 +342,23 @@ extern UWtype __udiv_w_sdiv (UWtype *, U
extern word_type __cmpdi2 (DWtype, DWtype);
extern word_type __ucmpdi2 (DWtype, DWtype);

+#if MIN_UNITS_PER_WORD > 1
+extern SItype __bswapsi2 (SItype);
+#endif
+#if LONG_LONG_TYPE_SIZE > 32
+extern DItype __bswapdi2 (DItype);
+#endif
+
extern Wtype __absvSI2 (Wtype);
extern Wtype __addvSI3 (Wtype, Wtype);
extern Wtype __subvSI3 (Wtype, Wtype);
extern Wtype __mulvSI3 (Wtype, Wtype);
extern Wtype __negvSI2 (Wtype);
-extern SItype __bswapsi2 (SItype);
extern DWtype __absvDI2 (DWtype);
extern DWtype __addvDI3 (DWtype, DWtype);
extern DWtype __subvDI3 (DWtype, DWtype);
extern DWtype __mulvDI3 (DWtype, DWtype);
extern DWtype __negvDI2 (DWtype);
-extern DItype __bswapdi2 (DItype);

#ifdef COMPAT_SIMODE_TRAPPING_ARITHMETIC
extern SItype __absvsi2 (SItype);
-- this is patch end

I tried to patch to GCC4.4.0 libgcc2.h then resulted in next message and did 
not

change file at all.

$ patch -p0 < libgcc2_h_diff.txt
(Stripping trailing CRs from patch.)
patching file libgcc2.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file libgcc2.h.rej

I am not deft of handling patch file,so would you please modify it to apply 
to GCC4.4.0 libgcc2.h ?

And please teach me how to apply it.

I append GCC4.4.0 libgcc2.h and patch file.

Masahiro Ariga



libgcc_files.tar.bz2
Description: Binary data

Re: Cannot configure gcc4.4.0 in order to build h8300 crosscompiler

[ariga masahiro]

Hello,

I am sorry to rush mails.
But I found the patch I sent was already included in GCC4.4.0 libgcc2.h.
So please ignore my previous mail.

Returning to original problem,apparently
L_bswapdi2 is somewhere defined.
But I could not find L_bswapdi2 defined anywhere.
Where and how is it defined ?

#ifdef L_bswapdi2
DItype
__bswapdi2 (DItype u)

Masahiro Ariga

Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu

[Andrew Stubbs]

On 09/07/09 19:11, Ian Lance Taylor wrote:

Andrew Stubbs  writes:


The problem insn is created by gen_reload when it is given the
following rtl as input:

(plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:192 a ] [192])
 (const_int 2 [0x2]))
 (reg:SI 0 r0 [orig:188 ivtmp.24 ] [188]))


You need to backtrack before that point to see why find_reloads let that
go through.


OK, I've gone through it all trying to understand it, but this is fairly 
complex code and I don't claim to get it.


Here's my analysis of the problem.

The problem instruction in pr34330.c.181r.sched1 (the state before 
register allocation/reload) is:


(insn 97 103 111 5 .../pr34330.c:17 (set (mem/s:HI (reg/f:SI 239 [ 
D.1960 ]) [6 D.1960_8->s1+0 S2 A16])
(subreg:HI (reg:SI 257) 2)) 187 {movhi_i} (expr_list:REG_DEAD 
(reg:SI 257)

(nil)))

The reloads for this instruction are:

Reloads for insn # 97
Reload 0: reload_in (SI) = (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ] [250])
(const_int 2 [0x2]))
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
reload_in_reg: (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ] [250])
(const_int 2 [0x2]))
 reload_reg_rtx: (reg:SI 8 r8)
Reload 1: reload_in (SI) = (plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:250 
a ] [250])
(const_int 2 
[0x2]))
(reg:SI 0 r0 
[orig:243 ivtmp.11 ] [243]))

GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
reload_in_reg: (plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ] 
[250])
(const_int 2 
[0x2]))
(reg:SI 0 r0 
[orig:243 ivtmp.11 ] [243]))

reload_reg_rtx: (reg:SI 9 r9)
Reload 2: reload_out (HI) = (mem/s:HI (reg/f:SI 2 r2 [orig:239 D.1960 ] 
[239]) [6 D.1960_8->s1+0 S2 A16])

NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/s:HI (reg/f:SI 2 r2 [orig:239 D.1960 ] 
[239]) [6 D.1960_8->s1+0 S2 A16])
Reload 3: reload_in (HI) = (mem:HI (plus:SI (plus:SI (reg/v/f:SI 4 r4 
[orig:250 a ] [250])
(const_int 
2 [0x2]))
(reg:SI 0 r0 
[orig:243 ivtmp.11 ] [243])) [3 S4 A32])

GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (subreg:HI (reg:SI 257) 2)
reload_reg_rtx: (reg:HI 8 r8)


Which results in this instruction sequence in pr34330.c.183r.ira:

(insn 169 103 170 4 .../pr34330.c:17 (set (reg:SI 8 r8)
(const_int 2 [0x2])) 175 {movsi_ie} (nil))

(insn 170 169 171 4 .../pr34330.c:17 (set (reg:SI 8 r8)
(plus:SI (reg:SI 8 r8)
(reg/v/f:SI 4 r4 [orig:250 a ] [250]))) 35 
{*addsi3_compact} (expr_list:REG_EQUIV (plus:SI (reg/v/f:SI 4 r4 
[orig:250 a ] [250])

(const_int 2 [0x2]))
(nil)))

(insn 171 170 172 4 .../pr34330.c:17 (set (reg:SI 9 r9)
(plus:SI (reg:SI 8 r8)
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) 35 
{*addsi3_compact} (nil))


(insn 172 171 97 4 .../pr34330.c:17 (set (reg:HI 8 r8)
(mem:HI (reg:SI 9 r9) [3 S4 A32])) 187 {movhi_i} (nil))

(insn 97 172 111 4 .../pr34330.c:17 (set (mem/s:HI (reg/f:SI 2 r2 
[orig:239 D.1960 ] [239]) [6 D.1960_8->s1+0 S2 A16])

(reg:HI 8 r8)) 187 {movhi_i} (nil))


The problem is in insn 171 where r9 != r8 and therefore cannot match an 
SH 2-operand add instruction.


Looking back at how this happens, insn 171 is created by gen_reload from 
reload #1 and initially looks like this:


(insn 171 170 172 5 .../pr34330.c:17 (set (reg:SI 9 r9)
(plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ] [250])
(const_int 2 [0x2]))
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) -1 (nil))

This is then transformed by subst_reloads to the final broken form:

(insn 171 170 172 5 .../pr34330.c:17 (set (reg:SI 9 r9)
(plus:SI (reg:SI 8 r8)
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) -1 (nil))

This is logically correct as r9 genuinely does contain the result of the 
substituted expression, but it does not satisfy the constraints.


And here's where I get stuck. I don't know where in the code it's 
supposed to check that the code will be correct after the substitution.


The (plus (plus ...) ...) rtl is generated by 
find_reloads_subreg_address using make_memloc and plus_constant, and it 
seems correct in itself.


Any help would be appreciated.

Thanks

Andrew

[testsuite] Executing testcases under wine

[FX]

Hi all,

I'm trying to run the GCC testsuite for the mingw target, on a i686- 
darwin host. The cross compiler builds fine, and I have wine  
installed, so I'd like testsuite executables, once compiled, to simply  
run under wine (that means, instead of running "PR10431.exe", running  
"wine PR10431.exe"). I've found a crude way to do this by patching my  
system dejagnu config file (/usr/share/dejagnu/config/unix.exp):


--- unix.exp.old2009-07-30 12:08:04.0 +0200
+++ unix.exp2009-07-30 11:57:37.0 +0200
@@ -73,7 +73,7 @@ proc unix_load { dest prog args } {
setenv SHLIB_PATH "$ld_library_path:$orig_ld_library_path"
 	verbose -log "Setting LD_LIBRARY_PATH to $ld_library_path: 
$orig_ld_library_path" 2


-   set id [remote_spawn $dest "$command" "readonly"]
+   set id [remote_spawn $dest "wine $command" "readonly"]
if { $id < 0 } {
set output "remote_spawn failed"
set status -1


I've tried to create a new board in the gcc/testsuite/lib directory  
(wine.exp) by copying unix.exp and modifying it, but I've not been  
able to get any luck at all. I hope maybe a dejagnu expert could point  
me in the right direction! (is it possible, what do I put in the  
wine.exp, where do I put this file and how to I get it to be called?)


Many thanks in advance,
FX

Re: [testsuite] Executing testcases under wine

[Ben Elliston]

> I'm trying to run the GCC testsuite for the mingw target, on a i686- 
> darwin host. The cross compiler builds fine, and I have wine  
> installed, so I'd like testsuite executables, once compiled, to simply  
> run under wine (that means, instead of running "PR10431.exe", running  
> "wine PR10431.exe"). I've found a crude way to do this by patching my  
> system dejagnu config file (/usr/share/dejagnu/config/unix.exp):

I think the right way to handle this is to treat wine as a simulator.
Take a look at some of the existing dejagnu board definitions to see how
to do this.  Perhaps something like:

  set_board_info sim xt-run

Cheers, Ben

ARM conditional instruction optimisation bug (feature?)

[Zoltán Kócsi]

On the ARM every instruction can be executed conditionally. GCC very
cleverly uses this feature:

int bar ( int x, int a, int b )
{
   if ( x )

  return a;
else
  return b;
}

compiles to:

bar:
cmp r0, #0  // test x
movne   r0, r1  // retval = 'a' if !0 ('ne')
moveq   r0, r2  // retval = 'b' if 0 ('eq')
bx  lr

However, the following function:

extern unsigned array[ 128 ];

int foo( int x )
{
   int y;

   y = array[ x & 127 ];

   if ( x & 128 )

  y = 123456789 & ( y >> 2 );
   else
  y = 123456789 & y;

   return y;
}

compiled with gcc 4.4.0, using -Os generates this:

foo:

ldr r3, .L8
tst r0, #128
and r0, r0, #127
ldr r3, [r3, r0, asl #2]
ldrne   r0, .L8+4***
ldreq   r0, .L8+4***
movne   r3, r3, asr #2
andne   r0, r3, r0   ***
andeq   r0, r3, r0   ***
bx  lr
.L8:
.word   array
.word   123456789

The lines marked with the *** -s do the same, one executing if the
condition is one way, the other if the condition is the opposite.
That is, together they perform one unconditional instruction, except
that they use two instuctions (and clocks) instead of one.

Compiling with -O2 makes things even worse, because an other issue hits:
gcc sometimes changes a "load constant" to a "generate the constant on
the fly" even when the latter is both slower and larger, other times it
chooses to load a constant even when it can easily (and more cheaply)
generate it from already available values. In this particular case it
decides to build the constant from pieces and combines that with
the generate an unconditional instruction using two complementary
conditional instructions method, resulting in this:

foo:
ldr r3, .L8
tst r0, #128
and r0, r0, #127
ldr r0, [r3, r0, asl #2]
movne   r0, r0, asr #2
bicne   r0, r0, #-134217728
biceq   r0, r0, #-134217728
bicne   r0, r0, #10747904
biceq   r0, r0, #10747904
bicne   r0, r0, #12992
biceq   r0, r0, #12992
bicne   r0, r0, #42
biceq   r0, r0, #42
bx  lr
.L8:
.word   array

Should I report a bug?

Thanks,

Zoltan

Re: GCC 4.5 Status Report (2009-07-29)

[Laurent GUERBY]

Hi,

The compile farm builders show two broken bootstraps:

* sparc-linux (gcc54)
C bootstrap is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40788
I just added a 1 day revision range to this PR, sparc-solaris is broken
too.

../../trunk/gcc/genattrtab.c: In function 'attr_rtx_1':
../../trunk/gcc/genattrtab.c:479:28: internal compiler error: tree
check: expected class 'expression', have 'declaration' (var_decl) in
gimplify_va_arg_expr, at builtins.c:5107

* powerpc64-linux (gcc40)
Ada bootstrap is broken, ICE during stage3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
(I'm trying to identify the commit)

And 7 ok bootstraps:

* powerpc-linux (gcc53)
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03211.html

* ia64-linux (gcc60)
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03208.html

* sparc64-linux (gcc62)
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03154.html

* arm-linux (gcc50) - c,c++,fortran
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03129.html

* x86_64-linux (gcc13)
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03118.html

* mips64el-linux (gcc51)
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg03076.html

* hppa-linux (gcc61)
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02639.html
(was two month ago, tester was stuck and I just relaunched it)

Laurent
http://gcc.gnu.org/wiki/CompileFarm

need help on GCC driver

[Vikram KS]

Hi,

I have some question on gcc driver.

Whenever we invoke gcc, it'll pass some default options to the
compiler, assembler linker etc. But if i dont want to pass all these
default options but only some of them, what should i do?

For eg: gcc will pass the following option to cc1

/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -quiet -v test.c -quiet
-dumpbase test.c -mtune=generic -auxbase test -version -o
/tmp/ccM89Tz7.s

and to "as"

 as -V -Qy -o /tmp/ccP6YP4n.o /tmp/ccM89Tz7.s

Now i dont want to generate "-o /tmp/ccM89Tz7.s" instead i want to
generate "/tmp/ccM89Tz7.sl" and this generated ".sl" should be picked
by my assembler and it should generate the o/p with ".ol" extension.

as -V -Qy -o /tmp/ccP6YP4n.ol /tmp/ccM89Tz7.sl

Also if i give "-S" switch, it should generate the the output with the
".sl" extension instead of  ".s".

Is this possible to do it in "gcc/config/.h" or do i need to
write a separate spec file.

Please help me out.


Thanks,
Vikram

Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu

[Joern Rennecke]

This is then transformed by subst_reloads to the final broken form:

(insn 171 170 172 5 .../pr34330.c:17 (set (reg:SI 9 r9)
 (plus:SI (reg:SI 8 r8)
 (reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) -1 (nil))

This is logically correct as r9 genuinely does contain the result of the
substituted expression, but it does not satisfy the constraints.

And here's where I get stuck. I don't know where in the code it's
supposed to check that the code will be correct after the substitution.

The (plus (plus ...) ...) rtl is generated by
find_reloads_subreg_address using make_memloc and plus_constant, and it
seems correct in itself.


This used to be 'handled' by reload register allocation which would
use the same reload register for RELOAD_FOR_INPUT_ADDRESS as for
RELOAD_FOR_INPADDR_ADDREESS if both are for the same operand.
It is strange that you have two RELOAD_FOR_INPUT_ADDRESS reloads
instead.

Although, in terms of ensuring correctness, it would be saner if
gen_reload would make sure it generates valid code even for unusual
reload register allocations.
Unfortunately, that'll require it to make a guess if a two-address add
is required; you can scan the insn pattern for matching constraints, but
that is somewhat hit-and-miss (obviously you can't use constrain_operands
there unless you want to save / restore all the extraction data); you'll
end up generating some unneeded register-register moves on some
architectures.  But you could make sure they get removed in postreload.

Build failure in libgfortran on i386-pc-solaris2.10

[Art Haas]

Hi.

My bootstrap builds have been failing in the 'libgfortran' portion
of the build since this patch:

2009-07-27  Tobias Burnus  

PR fortran/40863
* c99_functions.c: Define complex I, if not defined.
Create prototypes for C99 functions to silence warnings.
* gfortran.map: Add missing functions to GFORTRAN_C99_1.0
and new GFORTRAN_C99_1.1.

Here's the error message from the build log:

libtool: compile:  /export/home/arth/gnu/gcc-0730/./gcc/xgcc 
-B/export/home/arth/gnu/gcc-0730/./gcc/ 
-B/export/home/arth/local/i386-pc-solaris2.10/bin/ 
-B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem 
/export/home/arth/local/i386-pc-solaris2.10/include -isystem 
/export/home/arth/local/i386-pc-solaris2.10/sys-include -DHAVE_CONFIG_H -I. 
-I/export/home/arth/gnu/gcc.git/libgfortran -I. 
-iquote/export/home/arth/gnu/gcc.git/libgfortran/io 
-I/export/home/arth/gnu/gcc.git/libgfortran/../gcc 
-I/export/home/arth/gnu/gcc.git/libgfortran/../gcc/config -I../.././gcc 
-D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules 
-ffunction-sections -fdata-sections -g -O2 -march=pentium4 -MT c99_functions.lo 
-MD -MP -MF .deps/c99_functions.Tpo -c 
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c  -fPIC 
-DPIC -o .libs/c99_functions.o
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'casinf':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1585:11: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1585:11: 
error: (Each undeclared identifier is reported only once
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1585:11: 
error: for each function it appears in.)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'casin':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1597:11: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'casinl':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1609:11: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'cacosf':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1624:11: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'cacos':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1636:11: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'cacosl':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1648:11: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'catanf':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1663:10: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'catan':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1675:10: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'catanl':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1687:10: 
error: '_Imaginary_I' undeclared (first use in this function)
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1688:1: 
warning: control reaches end of non-void function
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'catan':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1676:1: 
warning: control reaches end of non-void function
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'catanf':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1664:1: 
warning: control reaches end of non-void function
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'cacosl':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1649:1: 
warning: control reaches end of non-void function
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'cacos':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1637:1: 
warning: control reaches end of non-void function
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c: In 
function 'cacosf':
/export/home/arth/gnu/gcc.git/libgfortran/intrinsics/c99_functions.c:1625:1: 
warning: control reaches end of non-void function
/export/home/arth/gnu/gcc.

Re: need help on GCC driver

[Basile STARYNKEVITCH]

Vikram KS wrote:

Hi,

I have some question on gcc driver.


You really should give more context. Are you doing cross-compilation? 
Are you patching the GCC sources? Why do you want to generate a *.sl 
file? What are your host & target systems?


Whenever we invoke gcc, it'll pass some default options to the
compiler, assembler linker etc. But if i dont want to pass all these
default options but only some of them, what should i do?

For eg: gcc will pass the following option to cc1

/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -quiet -v test.c -quiet
-dumpbase test.c -mtune=generic -auxbase test -version -o
/tmp/ccM89Tz7.s


Why are you talking of gcc-4.1.1? It is quite old now! If you want to 
patch or hack inside GCC, I strongly suggest working on the trunk 
(future gcc-4.5) or on your branch, or at least the latest GCC release 
(ie 4.4.1).




and to "as"

 as -V -Qy -o /tmp/ccP6YP4n.o /tmp/ccM89Tz7.s

Now i dont want to generate "-o /tmp/ccM89Tz7.s" instead i want to
generate "/tmp/ccM89Tz7.sl" and this generated ".sl" should be picked
by my assembler and it should generate the o/p with ".ol" extension.

I suppose it is a typo, and should read with ".sl" extension.



as -V -Qy -o /tmp/ccP6YP4n.ol /tmp/ccM89Tz7.sl

Also if i give "-S" switch, it should generate the the output with the
".sl" extension instead of  ".s".

Is this possible to do it in "gcc/config/.h" or do i need to
write a separate spec file.


I don't understand if you have your own target or not. I would suggest 
using a spec file (it is probably the easiest way to do). But I am not 
very expert on the gcc.c driver!


I really suggest you if possible to avoid hacking gcc 4.1.x and work on 
something more recent (otherwise you'll get few help from here...).


Regards.


--
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} ***

extern variable

[sumanth]

Hi,
How can I make sure the debugging  information printed by my 
compiler for extern variables is correct.
I am able to print them in gdb in with an _ (underscore). I am 
using Gcc-4.3.4 and gdb 5.3


Thanks,
Sumanth G 

Re: ARM conditional instruction optimisation bug (feature?)

[Steven Bosscher]

On 7/30/09, Zoltán Kócsi  wrote:
> On the ARM every instruction can be executed conditionally. GCC very
> cleverly uses this feature:
>
> int bar ( int x, int a, int b )
> {
>   if ( x )
>
>  return a;
>else
>  return b;
> }
>
> compiles to:
>
> bar:
>cmp r0, #0  // test x
>movne   r0, r1  // retval = 'a' if !0 ('ne')
>moveq   r0, r2  // retval = 'b' if 0 ('eq')
>bx  lr
>
> However, the following function:
>
> extern unsigned array[ 128 ];
>
> int foo( int x )
> {
>   int y;
>
>   y = array[ x & 127 ];
>
>   if ( x & 128 )
>
>  y = 123456789 & ( y >> 2 );
>   else
>  y = 123456789 & y;
>
>   return y;
> }
>
> compiled with gcc 4.4.0, using -Os generates this:
>
> foo:
>
>ldr r3, .L8
>tst r0, #128
>and r0, r0, #127
>ldr r3, [r3, r0, asl #2]
>ldrne   r0, .L8+4***
>ldreq   r0, .L8+4***
>movne   r3, r3, asr #2
>andne   r0, r3, r0   ***
>andeq   r0, r3, r0   ***
>bx  lr
> .L8:
>.word   array
>.word   123456789
>
> The lines marked with the *** -s do the same, one executing if the
> condition is one way, the other if the condition is the opposite.
> That is, together they perform one unconditional instruction, except
> that they use two instuctions (and clocks) instead of one.
>
> Compiling with -O2 makes things even worse, because an other issue hits:
> gcc sometimes changes a "load constant" to a "generate the constant on
> the fly" even when the latter is both slower and larger, other times it
> chooses to load a constant even when it can easily (and more cheaply)
> generate it from already available values. In this particular case it
> decides to build the constant from pieces and combines that with
> the generate an unconditional instruction using two complementary
> conditional instructions method, resulting in this:
>
> foo:
>ldr r3, .L8
>tst r0, #128
>and r0, r0, #127
>ldr r0, [r3, r0, asl #2]
>movne   r0, r0, asr #2
>bicne   r0, r0, #-134217728
>biceq   r0, r0, #-134217728
>bicne   r0, r0, #10747904
>biceq   r0, r0, #10747904
>bicne   r0, r0, #12992
>biceq   r0, r0, #12992
>bicne   r0, r0, #42
>biceq   r0, r0, #42
>bx  lr
> .L8:
>.word   array
>
> Should I report a bug?

This looks like my bug PR21803 (gcc.gnu.org/PR21803). Can you check if
the ce3 pass creates this code? (Compile with -fdump-rtl-all and look
at the .ce3 dump and one dump before to see if the .ce3 pass created
your funny sequence.)

If your problem is indeed caused by the ce3 pass, you should add your
problem to PR21803, change the "Component" field to "middle-end", and
adjust the bug summary to make it clear that this is not ia64
specific.

Ciao!
Steven

Re: ARM conditional instruction optimisation bug (feature?)

[Steven Bosscher]

On 7/30/09, Steven Bosscher  wrote:
> On 7/30/09, Zoltán Kócsi  wrote:
> > On the ARM every instruction can be executed conditionally. GCC very
> > cleverly uses this feature:
> >
> > int bar ( int x, int a, int b )
> > {
> >   if ( x )
> >
> >  return a;
> >else
> >  return b;
> > }
> >
> > compiles to:
> >
> > bar:
> >cmp r0, #0  // test x
> >movne   r0, r1  // retval = 'a' if !0 ('ne')
> >moveq   r0, r2  // retval = 'b' if 0 ('eq')
> >bx  lr
> >
> > However, the following function:
> >
> > extern unsigned array[ 128 ];
> >
> > int foo( int x )
> > {
> >   int y;
> >
> >   y = array[ x & 127 ];
> >
> >   if ( x & 128 )
> >
> >  y = 123456789 & ( y >> 2 );
> >   else
> >  y = 123456789 & y;
> >
> >   return y;
> > }
> >
> > compiled with gcc 4.4.0, using -Os generates this:
> >
> > foo:
> >
> >ldr r3, .L8
> >tst r0, #128
> >and r0, r0, #127
> >ldr r3, [r3, r0, asl #2]
> >ldrne   r0, .L8+4***
> >ldreq   r0, .L8+4***
> >movne   r3, r3, asr #2
> >andne   r0, r3, r0   ***
> >andeq   r0, r3, r0   ***
> >bx  lr
> > .L8:
> >.word   array
> >.word   123456789
> >
> > The lines marked with the *** -s do the same, one executing if the
> > condition is one way, the other if the condition is the opposite.
> > That is, together they perform one unconditional instruction, except
> > that they use two instuctions (and clocks) instead of one.
> >
> > Compiling with -O2 makes things even worse, because an other issue hits:
> > gcc sometimes changes a "load constant" to a "generate the constant on
> > the fly" even when the latter is both slower and larger, other times it
> > chooses to load a constant even when it can easily (and more cheaply)
> > generate it from already available values. In this particular case it
> > decides to build the constant from pieces and combines that with
> > the generate an unconditional instruction using two complementary
> > conditional instructions method, resulting in this:
> >
> > foo:
> >ldr r3, .L8
> >tst r0, #128
> >and r0, r0, #127
> >ldr r0, [r3, r0, asl #2]
> >movne   r0, r0, asr #2
> >bicne   r0, r0, #-134217728
> >biceq   r0, r0, #-134217728
> >bicne   r0, r0, #10747904
> >biceq   r0, r0, #10747904
> >bicne   r0, r0, #12992
> >biceq   r0, r0, #12992
> >bicne   r0, r0, #42
> >biceq   r0, r0, #42
> >bx  lr
> > .L8:
> >.word   array
> >
> > Should I report a bug?
>
> This looks like my bug PR21803 (gcc.gnu.org/PR21803). Can you check if
> the ce3 pass creates this code? (Compile with -fdump-rtl-all and look
> at the .ce3 dump and one dump before to see if the .ce3 pass created
> your funny sequence.)
>
> If your problem is indeed caused by the ce3 pass, you should add your
> problem to PR21803, change the "Component" field to "middle-end", and
> adjust the bug summary to make it clear that this is not ia64
> specific.

Oh, and you may also want to try my patch "crossjump_abstract.diff" in
PR20070, it solves problems like yours sometimes (if the sequence is
just right) by crossjumping earlier.

Ciao!
Steven

Targets still needing stdint.h type information

[Joseph S. Myers]

I previously listed  
those target OSes still needing GCC to be told internally about the 
stdint.h types used on those OSes (so allowing the Fortran C bindings for 
these types to work), and told in what way to install stdint.h for those 
OSes.  That message gives further information about how to configure this 
information in GCC.

Information has been added for some OSes, but the following still need it, 
and I encourage the maintainers of these OS ports to add it.  If testing 
shows stdint.h tests failing because of bugs in the OS's own stdint.h, 
fixincludes fixes may be needed as well.

* NetBSD
* OpenBSD
* VxWorks
* alpha*-dec-osf[45]*
* VMS
* SymbianOS
* WinCE
* DJGPP
* LynxOS
* Netware
* QNX
* Interix
* IRIX
* s390x-ibm-tpf*

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: MELT tutorial on the wiki

[Tom Tromey]

> "Basile" == Basile STARYNKEVITCH  writes:

Hi Basile.

Basile> I added as a turorial on the wiki, a small MELT pass which warns
Basile> against fprintf(stdout, ...) in the compiled code.

Basile> For GCC hackers, is the page
Basile> http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT
Basile> clear enough?

I've been looking for a very simple way to do some kinds of static
analysis on gdb, so today I tried building the MELT branch in hopes it
would serve this need.  Unfortunately, it didn't compile.

With C++ enabled, I got this failure:

/space/tromey/MELT/gcc/libstdc++-v3/include/precompiled/stdc++.h:98:18: fatal 
error: chrono: No such file or directory


With just C enabled, I got:

make[2]: *** No rule to make target `install-melt-headers', needed by 
`install'.  Stop.
make[2]: Leaving directory `/space/tromey/MELT/build/gcc'


In both cases I just configured with --disable-bootstrap --enable-melt,
plus the appropriate --enable-langauges option.  This is on x86 F11.

Basile> (of course, the pass implementation is imperfect, but I have hard time
Basile> finding good *small* examples).

My gdb examples involve finding broken code that can't be diagnosed by
the compiler.  Most of my examples are simple, but also actually useful.

For example, gdb has function that in the past could return null, but
which now cannot.  So, I'd like to find all places where the return
result is checked.

Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops.
It is not ok to 'return' or 'goto' from inside the inner loop, as this
causes hard-to-find bugs.  So, it would be nice to find any place that
tries this.

Or, there is a data type in gdb that used to be freed using 'xfree', but
which now requires a special function to be called instead.  So, it
would be nice to find any place where xfree is passed an argument of
this type.

Etc.  For my purposes, any kind of simple analysis pass that is simple
to hack and doesn't require me to learn too much would be ideal.

Tom

gcc-4.5-20090730 is now available

[gccadmin]

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

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

You'll find:

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

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

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

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

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

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

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

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

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

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

Porting GCC 4.4.0 to interix

[Robert Oeffner]

Hi,
I'm new to this mailing list and hope this is the right one I'm addressing.
Lately I have been trying to port gcc and g++ from GCC 4.4.0 to interix (the 
BSD-like unix subsystem optionally available for WinXP and Vista). The 
subsystem is shipped with gcc and g++ 3.3 and binutils 2.13 which I have 
used for the bootstrap. Based on other peoples patches I have had some 
success.


Until now there is no compiler available for interix that supports OpenMP 
and that's what I'm after. As libgomp in GCC so far isn't targeting interix 
I have made some changes to libgomp in my copy of the GCC 4.4.0 
distribution.  A new source file was created, 
gcc-4.4.0/libgomp/config/posix/interix/proc.c, which is templated on the 
existing gcc-4.4.0/libgomp/config/posix/proc.c and 
gcc-4.4.0/libgomp/config/posix/mingw32/proc.c in the distribution (see

http://www.oeffner.net/stuff/gcc-4.4.0_interix_changes.zip
or http://www.suacommunity.com/forum/tm.aspx?m=16600 ). With this file and 
modifications to GCC configuration files in the distribution I can bootstrap 
GCC 4.4.0 to build gcc and g++ compilers to support OpenMP on interix.


Although small OpenMP C++ programs builds and runs just fine I have problems 
with a large program that also uses OpenMP. The large program is unstable 
and crashes when compiled with OpenMP on interix. Compiled with g++4.4.0 
without OpenMP it runs like a charm. As we distribute this program to other 
platforms like Linux, MacOSX and Win32 where it runs fine with OpenMP I 
believe that my current implementation I have for porting libgomp to interix 
is buggy.


If anyone knows about some common or obvious pitfalls when porting libgomp 
to a new platform or if anyone has got any advice about what not to do I'd 
be very grateful.


Many thanks,

Rob

Re: Porting GCC 4.4.0 to interix

[Ben Elliston]

On Thu, 2009-07-30 at 23:58 +0100, Robert Oeffner wrote:

> Until now there is no compiler available for interix that supports OpenMP 
> and that's what I'm after. As libgomp in GCC so far isn't targeting interix 
> I have made some changes to libgomp in my copy of the GCC 4.4.0 
> distribution.

libgomp relies on pthreads (well, at least in the only current
implementation of that library).  Which pthread library are you using?
Does Interix supply one?

Ben

Re: need help on GCC driver

[Vikram KS]

On Thu, Jul 30, 2009 at 8:14 PM, Basile STARYNKEVITCH
 wrote:
>
> Vikram KS wrote:
>>
>> Hi,
>>
>> I have some question on gcc driver.
>
> You really should give more context. Are you doing cross-compilation? Are you 
> patching the GCC sources? Why do you want to generate a *.sl file? What are 
> your host & target systems?

Thanks for your reply. I am sorry that i was not clear. I am involved
in a private port for GCC 4.4.0. I have to integrate the compiler with
the rest of the existing tool chain. So as a part of this process i
have to invoke the rest of the tool chain through GCC driver.

>>
>> Whenever we invoke gcc, it'll pass some default options to the
>> compiler, assembler linker etc. But if i dont want to pass all these
>> default options but only some of them, what should i do?
>>
>> For eg: gcc will pass the following option to cc1
>>
>> /usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -quiet -v test.c -quiet
>> -dumpbase test.c -mtune=generic -auxbase test -version -o
>> /tmp/ccM89Tz7.s
>
> Why are you talking of gcc-4.1.1? It is quite old now! If you want to patch 
> or hack inside GCC, I strongly suggest working on the trunk (future gcc-4.5) 
> or on your branch, or at least the latest GCC release (ie 4.4.1).

I used the native complier only to show my requirement. I am using GCC 4.4.0
>
>>
>> and to "as"
>>
>>  as -V -Qy -o /tmp/ccP6YP4n.o /tmp/ccM89Tz7.s
>>
>> Now i dont want to generate "-o /tmp/ccM89Tz7.s" instead i want to
>> generate "/tmp/ccM89Tz7.sl" and this generated ".sl" should be picked
>> by my assembler and it should generate the o/p with ".ol" extension.
>
> I suppose it is a typo, and should read with ".sl" extension.
>
>>
>> as -V -Qy -o /tmp/ccP6YP4n.ol /tmp/ccM89Tz7.sl
>>
>> Also if i give "-S" switch, it should generate the the output with the
>> ".sl" extension instead of  ".s".
>>
>> Is this possible to do it in "gcc/config/.h" or do i need to
>> write a separate spec file.
>
> I don't understand if you have your own target or not. I would suggest using 
> a spec file (it is probably the easiest way to do). But I am not very expert 
> on the gcc.c driver!
>
> I really suggest you if possible to avoid hacking gcc 4.1.x and work on 
> something more recent (otherwise you'll get few help from here...).
>

So in the back-end there are driver options that will help me to
invoke the existing tool-chain through GCC driver. But the assembler
takes only .sl extensions. I tried to replace the .s extension with
.sl extension. But by default the cc1 will have some options passed
from the driver which also includes -o option. So if to add my own -o
option i am getting error due to repetition of -o option. So my
question is how to replace the .s extension with .sl extension for the
compiler output.

Hope i am clear.

Regards,
Vikram

Difference between Windows and Linux GCC compiler

[Rayne]

Hi all,

I'm interested to know what is the difference in programming using MS Visual 
C++ on Windows and using the GCC compiler on Linux, i.e. what are some of the 
things I can do on Visual C++ that won't compile/run on Linux, and vice versa.

For example, I know that Windows uses the LLP64 model, while Linux uses the 
LP64 model, so the long data type is only 32-bit on Windows but 64-bit on 
Linux. Also, the windows.h file is only available in Windows, and can't be used 
on Linux. I've also read that there is also some differences in network 
programming, since winsock, and especially the underlying ip headers are much 
different in Windows than Unix/Linux gcc. Is this true?

Thank you. 


  

Re: need help on GCC driver

[Basile STARYNKEVITCH]

Vikram KS wrote:


So in the back-end there are driver options that will help me to
invoke the existing tool-chain through GCC driver. But the assembler
takes only .sl extensions. I tried to replace the .s extension with
.sl extension. But by default the cc1 will have some options passed
from the driver which also includes -o option. So if to add my own -o
option i am getting error due to repetition of -o option. So my
question is how to replace the .s extension with .sl extension for the
compiler output.


I would imagine that an appropriate .spec file would do the trick; 
however, I am not sure of that, because I don't understand all the gory 
details of spec files.


Regards.

--
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: Difference between Windows and Linux GCC compiler

[Ben Elliston]

Hi.

> I'm interested to know what is the difference in programming using MS
> Visual C++ on Windows and using the GCC compiler on Linux, i.e. what
> are some of the things I can do on Visual C++ that won't compile/run
> on Linux, and vice versa.

This mailing list is for discussing GCC development, not questions about
using GCC or porting software to/from Linux.  Please try asking this
question on the gcc-h...@gcc.gnu.org list instead.  Thanks,

Ben

Re: MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Tom Tromey wrote:

"Basile" == Basile STARYNKEVITCH  writes:


Hi Basile.

Basile> I added as a turorial on the wiki, a small MELT pass which warns
Basile> against fprintf(stdout, ...) in the compiled code.

Basile> For GCC hackers, is the page
Basile> http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT
Basile> clear enough?



A very big thanks to Tom for looking at the page & trying MELT. I would 
be very proud if Tom happens to use it.



I've been looking for a very simple way to do some kinds of static
analysis on gdb, so today I tried building the MELT branch in hopes it
would serve this need.  Unfortunately, it didn't compile.



My current belief is that MELT is easier built (and used) as a GCC-trunk 
(or future GCC-4.5) plugin melt.so. The advantage for you is also to be 
better fit to your GCC (provided it is similar enough to a recent trunk 
and have plugins enabled).

See the http://gcc.gnu.org/wiki/MELT%20tutorial

There are however a few caveats when building MELT as a plugin:

 a) The patch (submitted to the trunk on gcc-patches@) 
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html which provides a 
gengtype usable for MELT as a plugin is required. I hope it will be 
reviewed & accepted for the trunk. The current gengtype (in recent 
trunk) is not good enough for complex plugins like MELT. Of course, you 
have the patched gengtype.c in the MELT branch.

Currently, this is the most annoying issue when building MELT as a plugin.

 b) some more headers are needed to MELT. the PLUGIN_HEADERS in 
gcc/Makefile.in is really incomplete. See footnote 9 of 
http://gcc.gnu.org/wiki/MELT%20tutorial


 c) you need to hack the MELT compile script (used to compile MELT 
generated C code into a shared library), that is, you should edit the 
file gcc/melt-cc-script.proto of MELT branch to suit your needs, and 
rename it appropriately.


 d) you need the PPL library (version 0.10.2 at least; the 0.10 is not 
enough). This is also needed when graphite is enabled.



With C++ enabled, I got this failure:

/space/tromey/MELT/gcc/libstdc++-v3/include/precompiled/stdc++.h:98:18: fatal 
error: chrono: No such file or directory





My fault: I had a mysterious message from svnmerge a few days ago about 
this file. I just copied it manually (from trunk to MELT branch rev 
150308 which I just commited).



With just C enabled, I got:

make[2]: *** No rule to make target `install-melt-headers', needed by 
`install'.  Stop.
make[2]: Leaving directory `/space/tromey/MELT/build/gcc'


In both cases I just configured with --disable-bootstrap --enable-melt,
plus the appropriate --enable-langauges option.  This is on x86 F11.



You probably missed some configure arguments. The MELT's 
gcc/configure.ac ends with

## Basile adds a notice if the MELT branch is configured without
## --enable-melt
if test "$enabled_melt" != "yes" ; then
   AC_MSG_NOTICE(
[GCC MELT branch is configured WITHOUT enabling melt.
 Are you sure to want that?])
fi


So if you got the GCC MELT branch is configured WITHOUT enabling melt 
message, your configure is wrong.




Basile> (of course, the pass implementation is imperfect, but I have hard time
Basile> finding good *small* examples).

My gdb examples involve finding broken code that can't be diagnosed by
the compiler.  Most of my examples are simple, but also actually useful.

For example, gdb has function that in the past could return null, but
which now cannot.  So, I'd like to find all places where the return
result is checked.

Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops.
It is not ok to 'return' or 'goto' from inside the inner loop, as this
causes hard-to-find bugs.  So, it would be nice to find any place that
tries this.

Or, there is a data type in gdb that used to be freed using 'xfree', but
which now requires a special function to be called instead.  So, it
would be nice to find any place where xfree is passed an argument of
this type.

Etc.  For my purposes, any kind of simple analysis pass that is simple
to hack and doesn't require me to learn too much would be ideal.

Tom


So Tom, be kind enough to try MELT again (preferably in plugin mode). I 
am on holidays without email access from august 3rd to august 26th.



Tom, you are definitely the best MELT user I could have, since you know 
much better than I do the internals of GCC! I hope to be able to help you.


You could need to extend MELT (mostly file gcc/melt/ana-base.melt) to 
add all the hooks to GCC that you need and that are not there yet. Ask 
me for help please!


A very big thanks for your message & efforts.

Regards.

--
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} ***