GCC 4.1/4.2 Status Report (2005-11-18)
The number of open serious regressions against 4.1 is a respectable 87, quite a few of which are P3s, waiting for me to categorize them. We still have some work to do before the release, but we will branch on 2005-11-18, as previously announced, at some point late Friday evening. Thank you for being patient through the long Stage 3. I am still reviewing the 4.2 projects, but I will post some ideas about staging those in before I create the branch tomorrow. There looks to be some exciting stuff in the pipeline! I would like to better understand the status of GOMP; is it going to be ready for 4.2 within a couple of months? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Successfull build of gcc-4.1.0 20051112 (experimental) on hppa2.0w-hp-hpux11.00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.1.0 20051112 (experimental) Platform: hppa2.0w-hp-hpux11.00 configure flags: - --prefix=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/bin/as - --with-ld=/usr/ccs/bin/ld --enable-threads=posix --disable-shared - --with-gmp=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00 - --with-mpfr=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00 - --enable-languages=c,c++,fortran,java,objc,obj-c++ binutils: binutils-2.16.1 Build system: HP-UX c3600-1 B.11.00 A 9000/785 unknown unknown HP-UX cc for building: gcc -mpa-risc-2-0 gcc (GCC) 4.0.2 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`hppa2.0w-hp-hpux11.00'. ld for building: 92453-07 linker command s800.sgs ld PA64 B.11.43 REL 050124 /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld [options] [flags] files /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.43 050125 testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00897.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfZWf3s6elE6CYeURAheAAJ4u/W6iCbjaZebRE/hWIVcDU4Bf8gCdE5wU P+TI/o3v2LnkdDB4JwzoCs4= =iBs4 -END PGP SIGNATURE-
Successfull build of gcc-4.1.0 20051112 (experimental) on mips-sgi-irix6.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.1.0 20051112 (experimental) Platform: mips-sgi-irix6.5 configure flags: - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld - --disable-shared --enable-threads=posix - --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - --enable-languages=c,ada,c++,objc,obj-c++ binutils: binutils-2.16.1 Build system: IRIX64 octane-3 6.5 10070055 IP30 mips unknown Irix cc for building: gcc gcc (GCC) 4.0.2 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`mips-sgi-irix6.5'. ld for building: GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00898.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfZYd3s6elE6CYeURAgLJAJ49oG3OQMlMm+fc2KSsnmittVUmYgCgpd4t aJ1dWyp3pz1bW2QcOAC02Lo= =3l6s -END PGP SIGNATURE-
Successfull build of gcc-4.1.0 20051112 (experimental) on i686-pc-linux-gnu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.1.0 20051112 (experimental) Platform: i686-pc-linux-gnu configure flags: - --prefix=/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/install/bin/ld - --enable-threads=posix --enable-shared --enable-__cxa_atexit - --with-gmp=/appl/shared/gnu/Linux/i686-pc-linux-gnu - --with-mpfr=/appl/shared/gnu/Linux/i686-pc-linux-gnu - --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ binutils: binutils-2.16.1 Build system: Linux cfd-1 2.6.14-1.1637_FC4smp #1 SMP Wed Nov 9 18:34:11 EST 2005 i686 i686 i386 GNU/Linux cc for building: gcc gcc (GCC) 4.0.2 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`i686-pc-linux-gnu'. ld for building: GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00899.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfZZv3s6elE6CYeURAiEJAKCDUwi23PkjsVUVASRDB0vgfnj5EACgtTM7 JWeQy1I/WtznnfOUid1c7CE= =4nGs -END PGP SIGNATURE-
Successfull build of gcc-4.1.0 20051112 (experimental) on x86_64-unknown-linux-gnu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.1.0 20051112 (experimental) Platform: x86_64-unknown-linux-gnu configure flags: - --prefix=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/Linux/x86_64-unknown-linux-gnu/install/bin/ld - --enable-threads=posix --enable-shared --enable-__cxa_atexit - --with-gmp=/appl/shared/gnu/Linux/x86_64-unknown-linux-gnu - --with-mpfr=/appl/shared/gnu/Linux/x86_64-unknown-linux-gnu - --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ binutils: binutils-2.16.1 Build system: Linux cfd-6 2.6.13-1.1532_FC4smp #1 SMP Thu Oct 20 01:42:06 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux cc for building: gcc gcc (GCC) 4.0.2 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`x86_64-unknown-linux-gnu'. ld for building: GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00900.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfZbW3s6elE6CYeURAgDCAJ9jjTV87GzFNiCoIIyBFW+0rJpX5wCfa1M6 TWGoTDckZSWTSkwYDqq+ink= =qgOF -END PGP SIGNATURE-
failed to run testsuite for libstdc++ on x86_64-unknown-linux-gnu for target unix/-m32
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
testsuite fails with the following message:
Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for
target.
Using
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
...
ERROR: tcl error sourcing
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not compile testsuite_shared.cc
while executing
"error "could not compile $f""
(procedure "v3-build_support" line 56)
invoked from within
"v3-build_support"
(file
"/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
line 22)
invoked from within
"source
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-abi/abi.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Running
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-dg/normal.exp
...
ERROR: tcl error sourcing
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-dg/normal.exp.
ERROR: could not compile testsuite_shared.cc
while executing
"error "could not compile $f""
(procedure "v3-build_support" line 56)
invoked from within
"v3-build_support"
(file
"/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-dg/normal.exp"
line 25)
invoked from within
"source
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-dg/normal.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20051112/libstdc++-v3/testsuite/libstdc++-dg/normal.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Any hints?
- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim
Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.: +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDfZfj3s6elE6CYeURAvYCAKDLYXrrXqcLm/hIyYhm7cY7oXtgKACcDuh3
aR5dZuF5vmc9kq0D6Q4Le+0=
=naBp
-END PGP SIGNATURE-
Code getting optimized away after instrumenation for memory analysis
Hello,
I am doing some code instrumentation for program memory access
validation using gcc-4.1 head.
For every assignment, p=q
I pass the address of the operands, "&p" and "&q" to an external
library function.
This works fine at O0, but at O1, some legitimate code gets optimized
away. In the dumps generated by my pass( runs immediately after
t08.useless), there is a statement
*D.2383 = __taint_addr10;
The "__taint_addr10" is an artificial variable created by my pass,
which replaces the original operand, since the address of the original
operand is taken. If this variable is used later in any expression
with a binary operator or a COND_EXPR, then it must be replaced by a
copy that doesnot have its address taken. So, in this prototype
currently I replace its occurance in every rhs expression.
This statement gets optimized away in the dead code elemination(t26.dce1)
pass, because in the "is_global_hidden_store" function , there is a
check :
if (!ZERO_SSA_OPERANDS (stmt, SSA_OP_VIRTUAL_DEFS))
which fails, and the function returns false. Thus, this statement is
not marked as necessary and gets removed.
The program which I am instrumenting is as follows:
int
main()
{
int i, k=1, n, *x;
printf( "Enter n: ");
scanf( "%d", &n );
x = malloc( (n+1) * sizeof(int));
x[1] = 1;
while (k)
{
if ( x[k]== n)
{
k--;
x[k]++;
}
else
{
k++;
x[k] = x[k-1] + 1;
}
}
return 0;
}
The dump after my instrumentation for "x[k]++" in the first if block
in while looks like -
L1:
...
...
/* Computes in __taint_addr.121 = k*4 */
__taint_addr.115 = k;
D.2381 = __taint_addr.115 * 4;
__taint_addr.125 = D.2381;
__taint_addr.128 = x;
D.2383 = __taint_addr.125 + __taint_addr.128;
library_call (D.2383);
/* Computes the incremented value in D.2385 */
D.2384 = *D.2383;
__taint_addr.135 = D.2384;
D.2385 = __taint_addr.135 + 1;
__taint_addr.11 = D.2385
*D.2383 = __taint_addr.11; /* ==> gets optimized away */
I would be thankful if someone could give me pointers to what could be
going wrong here. Clearly, The reference to *D.2383, is a valid heap
address, and hence must not be removed as a dead store. There is
something which my instrumentation is messing up.
I looked at the alias analysis dumps t20.alias1 . What I noticed is
that in function update_alias_info (),
there is a place where gcc processes each operand use is seen ,and for
pointers, it determines whether they are dereferenced by a given
statement or not. So, I added some printfs there, as follows:
FOR_EACH_PHI_OR_STMT_USE (use_p, stmt, iter, SSA_OP_USE)
{
tree op, var;
var_ann_t v_ann;
struct ptr_info_def *pi;
bool is_store, is_potential_deref;
unsigned num_uses, num_derefs;
op = USE_FROM_PTR (use_p);
/* Debug statemets added */
==> fprintf (stderr, "Stament and uses\n");
==> debug_generic_stmt (stmt);
==> debug_generic_stmt (op);
At this point, the stmt:
# VUSE ;
*D.2383 = __taint_addr.11D.3119_323;
_doesnot_ show any used op like,
D.2383.
why is this happening?
Thanks in advance,
Prateek.
Re: Link-time optimzation
Daniel Jacobowitz wrote: On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote: I just tried a simple unoptimized compile. -ftime-report said that final took 5% of the time (obviously final does more than formatting), and the assembler took 4% of the total user time, and system time took 16% of wall clock time. Cutting those numbers in half makes 1% seem not implausible to me, maybe even low. I'm considering an unoptimized compile because that is where the assembler makes the most difference--the compiler is faster and the assembler output probably tends to be longer, and also an unoptimized compile is when people care most about speed. For an optimizing compile, the assembler is obviously going to be less of a factor. Also, please keep in mind that generating and then assembling debug info takes a huge amount of I/O relative to code size. I'd expect much more than 1% saving the write-out and write-in on -g. So, maybe a simpler strategy could be to make minor modifications to gas and gcc so that the former is linked in and the latter can pass strings to it? Maybe that could get us a performance improvement without the need for a massive overhaul of all backends, and the need to duplicate object code generation. Bernd
Re: Register Allocation
Andrew MacLeod <[EMAIL PROTECTED]> wrote: > It is my intention over the next few months to do some of the initial > underlying infrastructure bits upon which the entire document is > based. Presuming that proceeds OK and I can build up the data > structures I am looking for, I'll move on from there. If anyone > wants to help, I'm sure there will be some juicy things to do. 1) Do you believe there will be sub-parts of this project which could be carried on succesfully and efficiently by programmers without previous RTL experience? IIUC, the optimizers will be basically abstracted by RTL details, but I was thinking of something within the critical path. 2) As for the new tables needed by the RTL library, I suppose they will be generated by some new gen* program. Did you consider using a scripting language as a fast prototype to munge .md files and generate those tables? I believe it would allow faster initial development and more flexibility in changes. Much later, it can be rewritten in C. Giovanni Bajo
Re: [RFC] PR/24900: computed but not used cast values
Richard Henderson wrote:- > On Thu, Nov 17, 2005 at 03:18:00PM -0800, Ian Lance Taylor wrote: > > I don't think you should get a warning for not using the return value of a > > function, at least not under -Wunused. > > For this, I agree. Except that we're not talking about the > return value of the function directly, we're talking about > the return value of a cast. > > Given that one can always cast any value to void to suppress > this warning, I'm unconcerned about getting every single edge > case "correct". Especially for edge cases for which one can > reasonably disagree as to what is correct. My 2 cents: a) the warning should stay, but the wording should be about a pointless (or unused) cast instead b) the kernel folks should have 2 macros, with and without the cast, and use whichever is appropriate. Assuming the cast is useful somewhere, of course. Neil.
Re: Link-time optimzation
Bernd Schmidt wrote: So, maybe a simpler strategy could be to make minor modifications to gas and gcc so that the former is linked in and the latter can pass strings to it? Maybe that could get us a performance improvement without the need for a massive overhaul of all backends, and the need to duplicate object code generation. I don't see that passing strings "internally" would be significantly faster than the current setup, and depending on how it was done, might even end up being slower. And it is well to remember that assembler technology is not trivial. There are environments in which the object formats are quite complex. I think it may well be possible to achieve an improvement of a few per cent in overall performance, but I would guess that the ratio of effort to improvement could be very high. Furthermore, I think you would certainly want to retain the possibility of generating assembler files for two reasons at least: 1) it is very helpful to be able to see the exact asm that is generated, knowing that it really IS the exact asm, and not some possibly incorrect attempt to reconstruct it. 2) when doing a new port for a new target with a new peculiar object format, you really don't want to have to tackle the details of the object format as part of the port.
Re: GCC 4.1/4.2 Status Report (2005-11-18)
On Friday 18 November 2005 03:48, Mark Mitchell wrote: > I would like to better understand the status of GOMP; is it going to be > ready for 4.2 within a couple of months? > Most definitely. We have been essentially waiting for 4.1 to branch. There are 5 modules to merge: library, C, C++, Fortran, middle-end. The FEs can be merged in more or less independently from library and middle-end.
Re: Link-time optimzation
On Fri, 2005-11-18 at 09:29, Bernd Schmidt wrote: > > Also, please keep in mind that generating and then assembling debug > > info takes a huge amount of I/O relative to code size. I'd expect much > > more than 1% saving the write-out and write-in on -g. > > So, maybe a simpler strategy could be to make minor modifications to gas > and gcc so that the former is linked in and the latter can pass strings > to it? Maybe that could get us a performance improvement without the > need for a massive overhaul of all backends, and the need to duplicate > object code generation. That's surprisingly close to how I'd see a migration strategy working anyway. Firstly we have to retain permanent access to the assembler's parser to handle inline asm statements. However, we don't have to use the parsing stage within the guts of the compiler. So I see a migration strategy something as follows: - Create a more complete set of output routines for printing assembly (ultimately a backend should never write to asm_out_file but to the new routines -- we're probably 90%+ towards that goal already). A back-end can't convert to embedded assembly until that process is complete. - once that's done we can start integrating the assembler code, the first step would be to feed the standard parser directly from the new assembly output routines (probably a line, or a statement at a time). - Then, incrementally, we can bypass the parse layer to call routines directly in the assembler. This can be done both for directives and for assembly of instructions. *but it can all be done incrementally*. The main difficulty is preserving -S output in a converted target if that is requested. It ought to be possible but it will need some care. R.
Directly generating binary code [Was Re: Link-time optimzation]
Richard Earnshaw writes: > - Then, incrementally, we can bypass the parse layer to call routines > directly in the assembler. This can be done both for directives and for > assembly of instructions. *but it can all be done incrementally*. > > The main difficulty is preserving -S output in a converted target if > that is requested. It ought to be possible but it will need some care. A nightmare scenario is debugging the compiler when its behaviour changes due to using "-S". Assembly source is something that we maintainers use more than anyone else. I expect that if we go down this road the gcc back end routines that generate assembly source will rot. I've seen compilers generate "assembly" code that fails to assemble even though the binaries it generated were correct. Needless to say, this can make life very difficult. Andrew.
Re: Code getting optimized away after instrumenation for memory analysis
On Friday 18 November 2005 04:13, Prateek Saxena wrote: > At this point, the stmt: > > # VUSE ; > *D.2383 = __taint_addr.11D.3119_323; > > _doesnot_ show any used op like, > > D.2383. > > why is this happening? > D.2383 is virtual (see the VUSE). Show me the points-to set for D.2383? That store is generating no V_MAY_DEFs and that is why DCE is removing it. I'll need to see the .alias1 and .dce1 dumps.
Re: Directly generating binary code [Was Re: Link-time optimzation]
On Fri, 2005-11-18 at 11:40 +, Andrew Haley wrote: > A nightmare scenario is debugging the compiler when its behaviour > changes due to using "-S". Assembly source is something that we > maintainers use more than anyone else. If we go the direct generation route, I think it would be more efficient (if possible) to add whatever extra information is needed in the object file (like the asm template string, compiler comments, ...) so that object code dumper will get it back to you on request. So skip the -S altogether, always use the object dumper to "look at assembly". Of course you then depend on the full target object toolchain, if it is a proprietary one and we can't feed extra information through its object dumper, my scheme won't work. Laurent
Target processor detection
I am working on a portable low-level library of atomic operations, so I need to detect the exact type of the target processor, which is specified by -mcpu or -march. However, there are two problems. On a sparc-based platform (Sun Fire 880, Solaris 2.8, 4x UltraSparc III) this program #if defined(__arch64__) #warning 64-bit architecture #else #warning 32-bit architecture #endif #if defined(__sparcv9__) || defined(__sparc_v9__) || defined(__sparcv9) #warning Sparc V9 #endif compiled using GCC 3.4.1 g++ -mcpu=v9 -mv8plus -mvis -m32 main.cpp displays only #warning 32-bit architecture with g++ -mcpu=v9 -mv8plus -mvis -m64 main.cpp the result is #warning 64-bit architecture #warning Sparc V9 Why does __sparc_v9__ depend on the number of bits instead of the -mcpu? Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which claims, that "__sparc_v9__ macro is for -mcpu=ultrasparc or -mcpu=v9, which is implied by -m64, but can be used in 32-bit code as well. __sparc_v9__ means using v9 instructions, __sparc__ __arch64__ means 64-bit ABI with the exception of Solaris which uses __sparcv9." It seems that my interpretation is confirmed by the above text and that it is a GCC bug. Could you please clarify the exact meaning of __sparc_v9__? The second problem is more general. Is it possible to change the meaning of __i386, __sparc, etc. in the next release of GCC? It should return the number provided by the user in -mcpu, for example: -mcpu=i386 => __i386 = 300 -mcpu=i486 => __i386 = 400 -mcpu=i586 => __i386 = 500 -mcpu=pentiumpro => __i386 = 600 -mcpu=pentium2 => __i386 = 625 -mcpu=pentium3 => __i386 = 650 -mcpu=pentium4 => __i386 = 700 -mcpu=v8 => __sparc = 800 -mcpu=v8 -mv8plus => __sparc = 850 -mcpu=v9 => __sparc = 900 -mcpu=ultrasparc => __sparc = 1000 and so on. Currently it is just defined to "1", which doesn't help much if the programmer would like to use something very architecture-specific. This modification would be backward compatible, because the result of #if defined(__i386) is the same as in the current compiler version. Best regards Piotr Wyderski This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments transmitted with it are confidential and may contain privileged or copyright information. Any views or opinions expressed in this email are those of the individual sender, except where the sender specifically states them to be the views of Microgen. If you are not the named or intended recipient of this email you must not read, use or disseminate the information contained within it for any purpose other than to notify us. If you have received this email in error, please notify the sender immediately and delete this email from your system. It is your responsibility to protect your system from viruses and any other harmful code or device, we try to eliminate them from emails and attachments, but accept no liability for any which remain. We may monitor or access any or all emails sent to us. In the event of technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk
Re: Build using --with-gmp and shared libraries
>> Basic testing done on i686-linux (built with --languages=c,fortran and >> a shared libgmp in /foo/bar, and regtested). Extended testing (which >> takes ages on my computer) in progress. >> >> OK for mainline? OK for 4.0? > > *ping* > > This patch has both a toplevel part and a part in gcc/, so I don't > know exactly who can approve it. ping**2 I know the ideal world solution is to have a GMP/MPFR in-tree, but nobody proposed a patch to do it and we do have a build failure with the current situation. -- FX
Pragma callback to insert text in input buffer?
Hi, I need to handle certain pragmas such that something special is generated in the assembly output roughly at the place that corresponds to the place of the pragma in the source code. Doing this in gcc in a clean way is not possible I guess, so I have to apply a hack. The hack that I want to apply is to insert a text like "asm volatile(...)" in the input buffer of gcc by the pragma callback handler. Gcc will encounter this text after the #pragma is handled. Is this possible? If so how? I hope that cpp_push_buffer() makes this possible. Regards, Jan
Issue with find_tail_calls
I sent email about this a few months ago (I can't find it since I'm having a problem getting a browser to work on gcc.gnu.org) and thought I'd raise it again since it would be good to get this into 4.1 Currently, tail call detected is almost completely disabled for Ada due to confusion as to which conversions are stripped off. It used to be that STRIP_USELESS_TYPE_CONVERSION used to strip exactly those conversions that the types_compatible_p langhook said were compatible. But that's no longer true. Because of that, find_tail_call says most calls in Ada aren't eligable. I propose the following patch and also propose doing it in all similar uses of a direct call of the lang hook in the optimizer since I think all have the same problem. But I've only tested the patch below so far. Comments? *** tree-tailcall.c (revision 107176) --- tree-tailcall.c (working copy) *** find_tail_calls (basic_block bb, struct *** 447,452 we emitted a suitable type conversion statement. */ if (!is_gimple_reg_type (TREE_TYPE (param)) ! || !lang_hooks.types_compatible_p (TREE_TYPE (param), !TREE_TYPE (arg))) break; --- 447,452 we emitted a suitable type conversion statement. */ if (!is_gimple_reg_type (TREE_TYPE (param)) ! || !tree_ssa_useless_type_conversion_1 (TREE_TYPE (param), ! TREE_TYPE (arg))) break;
Re: Issue with find_tail_calls
On 11/18/05, Richard Kenner <[EMAIL PROTECTED]> wrote: > I sent email about this a few months ago (I can't find it since I'm having > a problem getting a browser to work on gcc.gnu.org) and thought I'd raise > it again since it would be good to get this into 4.1 > > Currently, tail call detected is almost completely disabled for Ada due > to confusion as to which conversions are stripped off. > > It used to be that STRIP_USELESS_TYPE_CONVERSION used to strip exactly > those conversions that the types_compatible_p langhook said were > compatible. But that's no longer true. > > Because of that, find_tail_call says most calls in Ada aren't eligable. > > I propose the following patch and also propose doing it in all similar > uses of a direct call of the lang hook in the optimizer since I think all > have the same problem. But I've only tested the patch below so far. > > Comments? Be careful, tree_ssa_useless_type_conversion_1 strips CV qualifiers from pointers, f.i. See various different cleanup-patches I posted long time ago. Richard.
Re: Issue with find_tail_calls
Be careful, tree_ssa_useless_type_conversion_1 strips CV qualifiers from pointers, f.i. See various different cleanup-patches I posted long time ago. Right, but the point is that whatever it does, at least that code (and perhaps other current callers of the lang hook) have to duplicate exactly. Whether it should strip those or not is, in my view, a different issue.
Re: Register Allocation
On Fri, 2005-11-18 at 10:53 +0100, Giovanni Bajo wrote: > Andrew MacLeod <[EMAIL PROTECTED]> wrote: > 1) Do you believe there will be sub-parts of this project which could be > carried on succesfully and efficiently by programmers without previous RTL > experience? IIUC, the optimizers will be basically abstracted by RTL details, > but I was thinking of something within the critical path. > Some aspects require a little less intimate knowledge of RTL. I think the insn annotation and operand summary could be done with just basic RTL understanding, and then the live range code, if it were built on top of that, would require very little RTL knowledge. The RTL library, insn selector, and insn rewriter will be the most knowledge intensive. The degree of knowledge required for the rest of the critical path goes down a bit to where a more basic knowledge should be all that is necessary. > 2) As for the new tables needed by the RTL library, I suppose they will be > generated by some new gen* program. Did you consider using a scripting > language > as a fast prototype to munge .md files and generate those tables? I believe it > would allow faster initial development and more flexibility in changes. Much > later, it can be rewritten in C. > Thats quite possible, I hadn't really thought about that too much. I was actually thinking about looking into commandeering one or more of the gen programs and having them generate the tables at the same time as what they currently generate. That might be a bad idea, as I have never really looked at them. There is a relationship between the assembler table and the insn alternative table for instance, so I figured it might be possible to enhance it for what I want instead of doing something from scratch. If working with an existing gen program turns out to not be a good idea, perhaps a scripting language might be helpful, but I don't have much experience with any of them. Andrew
Re: GCC 4.1/4.2 Status Report (2005-11-18)
Diego Novillo wrote: > On Friday 18 November 2005 03:48, Mark Mitchell wrote: > > >>I would like to better understand the status of GOMP; is it going to be >>ready for 4.2 within a couple of months? >> > Most definitely. We have been essentially waiting for 4.1 to branch. > There are 5 modules to merge: library, C, C++, Fortran, middle-end. > The FEs can be merged in more or less independently from library and > middle-end. Great news. (The GOMP entry on the projects list was just a link to the project page; it didn't have this data.) It seems like it makes sense to do the library and middle-end first, and then the various front-ends in serial? Do you agree? I'd like to have a look at the C++ bits before they go in, but I'll not be looking to make life difficult. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Link-time optimzation
Hi, On Thu, 17 Nov 2005, Kenneth Zadeck wrote: > A stack machine representation was chosen for the same reason. Tree > gimple is a series of statements each statement being a tree. IMHO we should follow that path of thinking. The representation of GIMPLE where we do most optimizations on (i.e. tree-ssa) is implemented as GCC trees, thats true. But this is just an implementation detail, and one which somewhen in the future hopefully will be changed. Because in essence GIMPLE is a rather flat intermediate form, most of the time just three address form. I think it would be a mistake in the long run if we would now use a stack based external representation just because right now gimple is implemeted via trees. For instance the gimple statement a = b + c would need to be implemented ala push id_b push id_c add pop id_a The expansion of the trivial operation into four stackops is horrible to read (think reading debug dumps). Additionally the change of representation form might introduce hard to overcome issues due to mismatches in the expressiveness. We would possibly need a mini stack optimizer for just reading back this form into gimple. I think writing out gimple directly, i.e. using a register machine and three address code, is the better way. I could even imagine some custom extensions to the three address form to easily represent nested constructs which still happen in gimple (e.g. type conversions, address taking etc). > 1) Do some register allocation of the temps so that they are reused. >This is non trivial to undo (but truely doable), especially where >you wish to not adversely impact debugging. > > 2) Just generate a lot of temps and hope that some other form of >compression will save the day. In the above light I would go for 2) together with perhaps relatively trivial form of 1) (e.g. reusing temps per gimple statements, which reduces the overall need for temps to the max Sethi-Ullman number for the statements to be converted, most of the time lower than lets say 20). OTOH it might be a good idea to persue both strategies at first (i.e. a gimple writer/reader based on stack machine and one based on register machine), and then see which feels better. Perhaps even a merger of both approaches is sensible, three address form for most simple gimple statements with falling back to stack encoding for deeply nested operands. Ciao, Michael.
Re: GCC 4.1/4.2 Status Report (2005-11-18)
On Friday 18 November 2005 11:24, Mark Mitchell wrote: > Great news. (The GOMP entry on the projects list was just a link to the > project page; it didn't have this data.) > Yeah, we hadn't updated the status section yet. I added a paragraph earlier today. > It seems like it makes sense to do the library and middle-end first, and > then the various front-ends in serial? Do you agree? > Yes. The mental model is something like this: 1- Thread safety changes for libgfortran. These are relatively independent from gomp and Jakub will submit them the minute we branch 4.1. 2- Library and middle end. This can probably go in on its own, but I would prefer to commit it together with the C front end. Otherwise, there won't be anything to play with. 3- C front end. This may need a bit of review, though Richard has not expressed any reservations about it. 4- C++ and Fortran will need a fair bit of in-depth review by FE maintainers. I expect these two to take the longest to merge. > I'd like to have a look at the C++ bits before they go in, but I'll not > be looking to make life difficult. :-) :) Yes, we will probably request quite a bit of help from you folks.
Re: Link-time optimzation
On Friday 18 November 2005 17:31, Michael Matz wrote: > Perhaps even a merger of both > approaches is sensible, three address form for most simple gimple > statements with falling back to stack encoding for deeply nested operands. That would be a bad violation of the KISS principle. Gr. Steven
Re: Link-time optimzation
Kenneth Zadeck wrote: The stack machine that we have in mind will be as stripped down as possible. The idea is just to get the trees in and get them back out. When I first read the proposal, I too wondered if a register machine would be better here. I've come to the conclusion that it wouldn't be, and that a stack machine is a fine choice. *) Unlike JVM, we're not producing something that is supposed to be immediately executable. Making hardware stack machines go fast is very hard -- TOS acts as a huge atomic operator. *) I can well imagine more complicated gimple nodes than simple 3 address forms. A stack machine makes this kind of thing easy to extend. As Kenny says, a stack machine is an ideal way to serialize a tree. *) The stack machine decouples the getting and putting of operands from the actual operations. Although this could lead to excessive size, that does depend on the actual encoding chosen -- something that affects both stack and register machines. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Link-time optimzation
Hi, On Fri, 18 Nov 2005, Steven Bosscher wrote: > On Friday 18 November 2005 17:31, Michael Matz wrote: > > Perhaps even a merger of both > > approaches is sensible, three address form for most simple gimple > > statements with falling back to stack encoding for deeply nested operands. > > That would be a bad violation of the KISS principle. Of course. It was just an idea coming to my mind, you don't have to start with that. And sometimes one shouldn't avoid complexity at all cost, if the gain is high enough ;) Ciao, Michael.
Re: Ada Broken with h_errno change
* Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-17 : > I hope the explanation above helps make it clearer. Yes, thanks for the clarification. In light of this explanation the proposed fix seems appropriate; maybe a comment could be added along with the extern declaration to note that it is necessary because of the way the bootstrap procedure is organized. -- Thomas Quinot, Ph.D. ** [EMAIL PROTECTED] ** Senior Software Engineer AdaCore -- Paris, France -- New York, USA
Re: Directly generating binary code [Was Re: Link-time optimzation]
On 11/18/05, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > On Fri, 2005-11-18 at 11:40 +, Andrew Haley wrote: > > A nightmare scenario is debugging the compiler when its behaviour > > changes due to using "-S". Assembly source is something that we > > maintainers use more than anyone else. > > If we go the direct generation route, I think it would be more > efficient (if possible) to add whatever extra information is needed in > the object file (like the asm template string, compiler comments, ...) > so that object code dumper will get it back to you on request. So skip > the -S altogether, always use the object dumper to "look at assembly". The point Andrew's raising here is that you are replacing an intermediate form that is very useful for isolating problems --- the assembly language file --- with an in-core form that is much more difficult to inspect. And there are various side consequences: for example, you know the compiler isn't going to go and tweak the assembly-language file you're looking at, because it's exited. But with an in-core representation (and a non-type-safe language like C), compiler bugs can still be mangling the assembly code "after" it's been generated. For a 2% speedup? That hasn't been carefully measured?
Successfull build of gcc-4.1.0 20051112 (experimental) on ia64-unknown-linux-gnu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.1.0 20051112 (experimental) Platform: ia64-unknown-linux-gnu configure flags: - --prefix=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld - --enable-threads=posix --enable-shared --enable-__cxa_atexit - --with-gmp=/appl/shared/gnu/Linux/ia64-unknown-linux-gnu - --with-mpfr=/appl/shared/gnu/Linux/ia64-unknown-linux-gnu - --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ binutils: binutils-2.16.1 Build system: Linux exxon 2.4.21-32.0.1.EL.cern #1 SMP Thu May 26 11:51:54 CEST 2005 ia64 ia64 ia64 GNU/Linux cc for building: gcc gcc (GCC) 4.0.2 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`ia64-unknown-linux-gnu'. ld for building: GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00921.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfhKv3s6elE6CYeURApNpAKCmg2Yy8KN1hK37fGTUKHz/cLOAfwCfdVmw gF2s7ouF43qykCf6vIPEgBM= =DQE8 -END PGP SIGNATURE-
Re: GCC 4.1/4.2 Status Report (2005-11-18)
Diego Novillo wrote: > Yes. The mental model is something like this: Makes sense. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.1/4.2 Status Report (2005-11-18)
On Nov 18, 2005, at 8:24 AM, Mark Mitchell wrote: I'd like to have a look at the C++ bits before they go in, but I'll not be looking to make life difficult. :-) There was one thing I saw that was bad, as I recall, but I didn't mention it as I thought it'd be cleaned up on the branch. And now, I can't recall what it was. I'll see about doing a once over of the C+ + bits and see if I can spot it.
Re: Link-time optimzation
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote: I never like arguments which have loaded words like "lot" without quantification. Just how long *is* spent in this step, is it really significant? as is 2-3% as I recall (Finder_FE C++) of total build time.
Re: Link-time optimzation
On Nov 17, 2005, at 6:13 PM, Daniel Jacobowitz wrote: Also, please keep in mind that generating and then assembling debug info takes a huge amount of I/O relative to code size. I'd expect much more than 1% saving the write-out and write-in on -g. I'd hope that we can contribute code to eliminate this, so, it might be possible to not consider any benefit this would have in the current decision making. compiler -> debug info repository -> gdb (side stepping the linker, the assembler)
Re: Link-time optimzation
On Nov 17, 2005, at 6:33 PM, Dale Johannesen wrote: When I arrived at Apple around 5 years ago, I was told of some recent measurements that showed the assembler took around 5% of the time. Yeah, it's been sped up actually.
compiling gcc-4.0.2 on solaris 9
(NOTE: I originally posted this to gcc-help, but only got one response that the sender said they had posted a similar posting a while back and got no responses. So, I am reposting the below to gcc in hopes that this might be a better place to post this question.) I am on: SunOS hostname 5.9 Generic_118558-14 sun4u sparc SUNW,Sun-Blade-1500. I try to do a bootstrap with the following using gnu make 3.80: mkdir objectdir;cd objectdir CC="cc -xildoff -xarch=v9" export CC ../gcc-4.0.2/configure gmake bootstrap I get the following errors: stage1/xgcc -Bstage1/ -B/usr/local/sparc-sun-solaris2.9/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-sparc-sun-solaris2.9/libiberty/libiberty.a ld: warning: file ../build-sparc-sun-solaris2.9/libiberty/libiberty.a(hashtab.o): wrong ELF class: ELFCLASS64 Undefined first referenced symbol in file htab_create_alloc build/genmodes.o htab_find build/genmodes.o xcalloc build/genmodes.o htab_hash_stringbuild/genmodes.o htab_find_slot build/genmodes.o xmalloc build/genmodes.o xstrdup build/genmodes.o ld: fatal: Symbol referencing errors. No output written to build/genmodes collect2: ld returned 1 exit status make[2]: *** [build/genmodes] Error 1 make[2]: Leaving directory `/export/home/src/net/gnu/odir/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/export/home/src/net/gnu/odir/gcc' make: *** [bootstrap] Error 2 I am new to the sun environment, so any help would be appreciated. Thanks!
Re: Code getting optimized away after instrumenation for memory analysis
Hi,
Thanks for looking at this problem.
The points-to set says :
D.2383 = { ANYTHING ANYOFFSET }
Here is the shortened .alias1 dump. If you need the whole thing (its
2000 lines), I can send that as well.
Please grep for D.2383, to see all info about it.
Dereferences pointers doesnot show D.2383 as one.
Should I attach the whole .alias1 and .dce1 and send? Just thought
this might be sufficient.
All __taint_* are functions and variables inserted by my instrumentation.
Thanks,
Prateek.
===
main ()
{
int D.2385;
int D.2384;
int * D.2383;
unsigned int __taint_addr.88;
int * __taint_addr.89;
unsigned int __taint_addr.90;
void * __taint_addr.91;
int * __taint_addr.92;
unsigned int __taint_addr.93;
unsigned int __taint_addr.124;
int * __taint_addr.125;
int * __taint_addr.128;
unsigned int __taint_addr.129;
void * __taint_addr.130;
void * D.3102;
void * __taint_addr.131;
void * D.3104;
unsigned int __taint_addr.132;
int __taint_addr.140;
:
goto ();
:;
__taint_addr.88_129 = &D.2383;
taint_assmt_handler (__taint_addr.88_129, 4, __taint_addr.95_139);
D.2383 = __taint_addr.89_130 + __taint_addr.92_134;
D.3057_142 = D.2383;
D.3058_143 = taint_get_tag_val (D.3057_142, 4);
D.2384 = *D.2383;
...
if (__taint_addr.102_152 == __taint_addr.103_153) goto ; else goto ;
:;
__taint_addr.124_294 = &D.2383;
taint_assmt_handler (__taint_addr.124_294, 4, __taint_addr.131_304);
D.2383 = __taint_addr.125_295 + __taint_addr.128_299;
D.3057_307 = D.2383;
D.3107_308 = taint_get_tag_val (D.3057_307, 4);
__taint_addr.133_309 = D.3107_308;
taint_assmt_handler (__taint_addr.132_306, 4, __taint_addr.133_309);
D.2384 = *D.2383;
__taint_addr.135_312 = D.2384;
...
D.2385 = __taint_addr.135_312 + 1;
__taint_addr.140_321 = D.2385;
*D.2383 = __taint_addr.140_321;
goto ();
:;
... some similar instrumentation here as under :
*D.2383 = __taint_addr.207_257;
:;
__taint_addr.210_106 = k;
if (__taint_addr.210_106 != 0) goto ; else goto ;
:;
return;
}
Points-to analysis
Constraints:
ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTEGER = &ANYTHING
ANYOFFSET = &ANYOFFSET
D.2963_15 = &ANYTHING
__taint_addr.31_16 = D.2963_15
D.2965_19 = INTEGER
D.2965_19 = INTEGER
__taint_addr.32_20 = D.2965_19
__taint_addr.32_20 = &ANYOFFSET
D.2382 = &ANYTHING
__taint_addr.89_130 = D.2382
__taint_addr.91_133 = D.3048_132
__taint_addr.92_134 = x
__taint_addr.94_137 = D.3052_136
__taint_addr.95_139 = D.3054_138
__taint_addr.97_144 = D.3058_143
__taint_addr.101_150 = D.3063_149
__taint_addr.107_266 = D.3070_265
__taint_addr.108_268 = D.3072_267
__taint_addr.109_270 = D.3074_269
__taint_addr.113_276 = D.3079_275
__taint_addr.117_282 = D.3084_281
__taint_addr.118_284 = D.3086_283
__taint_addr.119_286 = D.3088_285
__taint_addr.123_292 = D.3093_291
D.2382 = &ANYTHING
__taint_addr.125_295 = D.2382
__taint_addr.127_298 = D.3098_297
__taint_addr.128_299 = x
D.2383 = __taint_addr.125_295
D.2383 = &ANYOFFSET
D.3057_307 = D.2383
D.3107_308 = &ANYTHING
__taint_addr.133_309 = D.3107_308
D.3114_316 = &ANYTHING
__taint_addr.139_319 = D.3116_318
__taint_addr.142_324 = D.3120_323
__taint_addr.146_158 = D.3125_157
D.3127_159 = &ANYTHING
__taint_addr.147_160 = D.3127_159
D.3129_161 = &ANYTHING
__taint_addr.148_162 = D.3129_161
D.3134_167 = &ANYTHING
__taint_addr.152_168 = D.3134_167
D.3139_173 = &ANYTHING
__taint_addr.156_174 = D.3139_173
D.3141_175 = &ANYTHING
__taint_addr.157_176 = D.3141_175
D.3143_177 = &ANYTHING
__taint_addr.158_178 = D.3143_177
D.3148_183 = &ANYTHING
__taint_addr.162_184 = D.3148_183
D.2382 = &ANYTHING
__taint_addr.164_187 = D.2382
D.3153_189 = &ANYTHING
__taint_addr.166_190 = D.3153_189
__taint_addr.167_191 = x
D.3157_193 = &ANYTHING
__taint_addr.169_194 = D.3157_193
D.3159_195 = &ANYTHING
__taint_addr.170_196 = D.3159_195
D.2383 = __taint_addr.164_187
D.2383 = &ANYOFFSET
D.3164_201 = &ANYTHING
__taint_addr.174_202 = D.3164_201
D.3169_207 = &ANYTHING
__taint_addr.178_208 = D.3169_207
D.3171_209 = &ANYTHING
__taint_addr.179_210 = D.3171_209
D.3173_211 = &ANYTHING
__taint_addr.180_212 = D.3173_211
D.3178_217 = &ANYTHING
__taint_addr.184_218 = D.3178_217
D.2386 = &ANYTHING
__taint_addr.186_221 = D.2386
D.3183_223 = &ANYTHING
__taint_addr.188_224 = D.3183_223
__taint_addr.189_225 = x
D.3187_227 = &ANYTHING
__taint_addr.191_228 = D.3187_227
D.3189_229 = &ANYTHING
__taint_addr.192_230 = D.3189_229
D.2387 = __taint_addr.186_221
D.2387 = &ANYOFFSET
__taint_addr.194_233 = D.2387
D.3194_235 = &ANYTHING
__taint_addr.196_236 = D.3194_235
D.3196_237 = &ANYTHING
__taint_addr.197_238 = D.3196_237
D.3198_239 = &ANYTHING
__taint_addr.198_240 = D.3198_239
D.2388 = __taint_addr.194_233
D.2388 = &ANYTHING
D.3201_243 = D.2388
D.3202_244 = &ANYTHING
__taint_addr.209_260 = D.3215_259
D.3057_261 = D.2383
Collapsing static cycles and doing variable substitution:
Solving graph
GCC 4.0.2 build report on Fedora Core 3
GCC 4.0.2 has been successfully built on Fedora Core 3 config.guess returned: > i686-pc-linux-gnu gcc -v returned: > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: /home/devel/gcc/gcc- 4.0.2/configure --program-suffix=-4.0.2 > Thread model: posix > gcc version 4.0.2 built frontends: > C, C++, Obj-C, Fortran system info: > Fedora Core release 3 (Heidelberg) > Linux localhost.localdomain 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004 i686 > i686 i386 GNU/Linux > glibc-2.3.3-74 All the configuration, compilation, and installation worked without any problems. KUDOS to the GCC team!!! Josef Nygrin FNSPE CTU Prague Czech Republic
Re: compiling gcc-4.0.2 on solaris 9
On Fri, Nov 18, 2005 at 01:48:57PM -0500, Douglas B. Jones wrote: > I am on: > > SunOS hostname 5.9 Generic_118558-14 sun4u sparc SUNW,Sun-Blade-1500. > I try to do a bootstrap with the following using gnu make 3.80: > > mkdir objectdir;cd objectdir > CC="cc -xildoff -xarch=v9" > export CC Why are you choosing those flags? > ../gcc-4.0.2/configure > gmake bootstrap > > I get the following errors: > > stage1/xgcc -Bstage1/ -B/usr/local/sparc-sun-solaris2.9/bin/ -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE -o > build/genmodes \ > build/genmodes.o build/errors.o > ../build-sparc-sun-solaris2.9/libiberty/libiberty.a > ld: warning: file > ../build-sparc-sun-solaris2.9/libiberty/libiberty.a(hashtab.o): wrong ELF > class: ELFCLASS64 Just do CC=cc, you will get both a 32-bit and a 64-bit compiler. What seems to be happening is that the build process assumes that the first libiberty you get (the one built with the native compiler) is 32-bit code.
Re: pruning unused debugging types (enums/PR23336)
On Thu, Nov 17, 2005 at 10:24:21PM -0800, Mark Mitchell wrote: > Richard Henderson wrote: > > > A solution that comes to mind is to have the front-end add dummy > > TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most > > BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and had > > no DECL_NAME, it'd be easy for us to notice that we shouldn't > > actually emit debug info for the TYPE_DECL itself, but that we > > should consider its TREE_TYPE to be used. > > > > I'm open to better schemes. Perhaps a used-type hash table in > > the struct function. > > I like the idea, but I think a hash table would be better. In fact, I > think the best choice would be a hash table during compilation of the > function, transformed into a vector after the closing brace of the Either way is fine by me. Just to make sure I understand things; you want me to hack the front-end to fill the hash table every time it parses a cast or enum type? For example: Index: c-parser.c === --- c-parser.c (revision 107115) +++ c-parser.c (working copy) @@ -4485,6 +4485,7 @@ c_parser_cast_expression (c_parser *pars ret.original_code = ERROR_MARK; return ret; } + add_to_some_hash (TREE_TYPE (groktypename (type_name))); if (c_parser_next_token_is (parser, CPP_OPEN_BRACE)) return c_parser_postfix_expression_after_paren_type (parser, Thanks.
Re: compiling gcc-4.0.2 on solaris 9
> > mkdir objectdir;cd objectdir > > CC="cc -xildoff -xarch=v9" > > export CC > > Why are you choosing those flags? Probably because they are advertised on: http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 > Just do CC=cc, you will get both a 32-bit and a 64-bit compiler. What > seems to be happening is that the build process assumes that the first > libiberty you get (the one built with the native compiler) is 32-bit code. Douglas has simply mixed 32-bit and 64-bit configuration. For the 32-bit compiler (sparc-sun-solaris2.9), CC=cc is fine. For the 64-bit compiler (sparc64-sun-solaris2.9), CC="cc -xarch=v9" is fine. -- Eric Botcazou
Re: compiling gcc-4.0.2 on solaris 9
On Fri, Nov 18, 2005 at 09:17:11PM +0100, Eric Botcazou wrote: > > > mkdir objectdir;cd objectdir > > > CC="cc -xildoff -xarch=v9" > > > export CC > > > > Why are you choosing those flags? > > Probably because they are advertised on: > http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 > > > Just do CC=cc, you will get both a 32-bit and a 64-bit compiler. What > > seems to be happening is that the build process assumes that the first > > libiberty you get (the one built with the native compiler) is 32-bit code. > > Douglas has simply mixed 32-bit and 64-bit configuration. > > For the 32-bit compiler (sparc-sun-solaris2.9), CC=cc is fine. > For the 64-bit compiler (sparc64-sun-solaris2.9), CC="cc -xarch=v9" is fine. This seems error-prone; maybe more warnings need to be added to the installation note. Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means "build both compilers, defaulting to 32 bits".
Re: compiling gcc-4.0.2 on solaris 9
> Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means > "build both compilers, defaulting to 32 bits". No, the compiler is purely 32-bit, only the libraries are of both flavors. -- Eric Botcazou
Re: Pragma callback to insert text in input buffer?
On Fri, Nov 18, 2005 at 02:22:16PM +0100, Jan Hoogerbrugge wrote: > Gcc will encounter this text after the #pragma > is handled. Is this possible? Nope, at least not this way. With the rewritten pragma handing on the gomp branch you have a bit more control in the front ends about what happens when a pragma is seen, but manipulating the input stream is not in the cards. r~
RTEMS GCC Status Report
Mark Mitchell wrote: The number of open serious regressions against 4.1 is a respectable 87, quite a few of which are P3s, waiting for me to categorize them. We still have some work to do before the release, but we will branch on 2005-11-18, as previously announced, at some point late Friday evening. Thank you for being patient through the long Stage 3. Mark we are trying to test furiously and I know that neither Ada nor RTEMS is a primary target but I wanted to pass along a few issues that are being worked by various people. I am sure that this is not a complete list but covers the important issues impacting RTEMS GCC. + PR24912 - m68k build failure: ICE: in reload_cse_simplify_operands This is a recent regression and a patch has just been proposed. + No PR - The Ada tools mangle target names like arm-rtems4.7. Apparently they don't like the version part. Laurent is working on this. + No PR - The Ada tools end up invoking a cross compiler which is hard coded to be in /usr/bin. This may be a side-effect of the name mangling problem and just a default that is being tripped. We don't know yet. Ralf if I missed something really critical, speak up. I was focusing more on "doesn't work at all" issues. I don't see any ICEs while building RTEMS right now. The targets we try to build are: avr-rtems4.7- C i386-rtems4.7 - C, C++, Ada powerpc-rtems4.7- C, C++, Ada sparc-rtems4.7 - C, C++, Ada mips64-rtems4.7 - C, C++, Ada m68k-rtems4.7 - C, C++, Ada i686-pc-linux-gnu - C, C++, Ada (to bootstrap the others with) mips-rtems4.7 - C, C++, Ada arm-rtems4.7- C, C++, Ada sh-rtems4.7 - C, C++, Ada h8300-rtems4.7 - C, C++ For each target, we have been building RTEMS and a handful of other libraries including ncurses, readline, and libtecla. We are pushing at the avr and it won't build right now and we have filed a PR. I need to check if the Ada multilib support is ready for us to turn on and push. Right now, I am more concerned that the target name issue is preventing us from even getting a hello world to link. --joel
Re: Issue with find_tail_calls
On Fri, Nov 18, 2005 at 08:42:43AM -0500, Richard Kenner wrote: > if (!is_gimple_reg_type (TREE_TYPE (param)) > ! || !tree_ssa_useless_type_conversion_1 (TREE_TYPE (param), > ! TREE_TYPE (arg))) Seems reasonable. These are the conversions we strip across move statements. Which is about the same for what we'd want across a return. r~
Incompatible behavior -O0, -O3, std::cout
Hello Everyone
I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
-f2() called
-f1() called-
12
And with -O3 flag:
-f1() called-
-f2() called
12
Here's the code:
#include
#include
int f1() {
fprintf(stderr, "-f1() called-\n");
return 1;
}
int f2() {
fprintf(stderr, "-f2() called\n");
return 2;
}
int main(int argc, char **argv) {
std::cout << f1() << f2() << std::endl;
}
I'm pretty sure that I am depending on an undefined behavior here, but
maybe you guys would want to have a deeper look at this.
Also, if this is not very off-topic, could some one please tell me whether
the << operators for std::ostream are members of the class, or are global
functions (operators).
I think, if are global, it would be same as depending upon the order of
evaluation of arguments to a function (which would be wrong according to
the C++ standard), but if they were members of the stream classes, then it
would evaluate to a().b().c().d() and we should expect f1() to be called
before f2(). - Is that correct?
Thanks and Best Regards
Pankaj
--
--
Pankaj Gupta
Infrastructure Team - Tower Research Capital
Phone: 212-219-6012 [Work]
551-358-0684 [Cell]
Mail: [EMAIL PROTECTED]
--
Re: Incompatible behavior -O0, -O3, std::cout
>
> Hello Everyone
>
> I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
> 20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
> int main(int argc, char **argv) {
> std::cout << f1() << f2() << std::endl;
> }
>
>
> I'm pretty sure that I am depending on an undefined behavior here, but
> maybe you guys would want to have a deeper look at this.
Yes are you dependening on undefined behavior. Since there is no sequence
point
between the calls to f1() and f2(), then they can be evaluated in either order.
> I think, if are global, it would be same as depending upon the order of
> evaluation of arguments to a function (which would be wrong according to
> the C++ standard), but if they were members of the stream classes, then it
> would evaluate to a().b().c().d() and we should expect f1() to be called
> before f2(). - Is that correct?
No because the above is equvliant to the following pesdu C code:
operator <<(operator << (operator << (std::cout, f1()), f2()), std::endl)
and the order evaluatation of expressions inside a function call is undefined.
Thanks,
Andrew Pinski
Re: RTEMS GCC Status Report
On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill wrote: > + No PR - The Ada tools mangle target names like arm-rtems4.7. >Apparently they don't like the version part. Laurent is working on >this. To be accurate I promised to work on this once Paolo configure patch is in, because I'm currently unable to apply it cleanly to my tree :). Laurent
Re: Incompatible behavior -O0, -O3, std::cout
Thanks Andrew. That answers it.
Pankaj
On Fri, 18 Nov 2005, Andrew Pinski wrote:
Hello Everyone
I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
int main(int argc, char **argv) {
std::cout << f1() << f2() << std::endl;
}
I'm pretty sure that I am depending on an undefined behavior here, but
maybe you guys would want to have a deeper look at this.
Yes are you dependening on undefined behavior. Since there is no sequence
point
between the calls to f1() and f2(), then they can be evaluated in either order.
I think, if are global, it would be same as depending upon the order of
evaluation of arguments to a function (which would be wrong according to
the C++ standard), but if they were members of the stream classes, then it
would evaluate to a().b().c().d() and we should expect f1() to be called
before f2(). - Is that correct?
No because the above is equvliant to the following pesdu C code:
operator <<(operator << (operator << (std::cout, f1()), f2()), std::endl)
and the order evaluatation of expressions inside a function call is undefined.
Thanks,
Andrew Pinski
--
--
Pankaj Gupta
Infrastructure Team - Tower Research Capital
Phone: 212-219-6012 [Work]
551-358-0684 [Cell]
Mail: [EMAIL PROTECTED]
--
Re: RTEMS GCC Status Report
Laurent GUERBY wrote: On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill wrote: + No PR - The Ada tools mangle target names like arm-rtems4.7. Apparently they don't like the version part. Laurent is working on this. To be accurate I promised to work on this once Paolo configure patch is in, because I'm currently unable to apply it cleanly to my tree :). Yes. I should have included Paolo's patch as a MAJOR requirement. Otherwise you can't build a newlib cross target as best I can tell. Please, pretty please get that merged. --joel
Sta cekate?
POTREBAN VAM JE NOVAC??? IMATE 2-3 h DNEVNO SLOBODNOG VREMENA??? KORISTITE MOC INTERNETA??? STA CEKATE??? Pitajte me: "KAKO USPETI?" na [EMAIL PROTECTED] i otkricu Vam tajnu uspeha! Korak po korak i uspeh ne moze izostati. Bogatstvo ostvaruju oni koje motivise zelja za uspehom!!! Mislite pozitivno - priustite sebi radost! Proverite Ovakvu ponudu ne mozete naci nigde!!! Ja ulazem svoje vreme i iskustvo u Vas = Vi postajete moj saradnik!!! Kontakt na [EMAIL PROTECTED] i Vase zelje pocinju da se ostvaruju Raspitajte se DA LI SE NEKO POKAJAO??? S postovanjem, Voja
Re: compiling gcc-4.0.2 on solaris 9
On Fri, Nov 18, 2005 at 09:35:28PM +0100, Eric Botcazou wrote: > > Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means > > "build both compilers, defaulting to 32 bits". > > No, the compiler is purely 32-bit, only the libraries are of both flavors. We are using the term in a differnent way, it appears. Although the compiler's executable is composed of 32-bit code, it can generate 32 or 64 bit code, which is what I meant by "both compilers".
Re: dwarf2 unwinder hacks get my static build going: Bug, or indication of what I'm doing wrong?
Two thoughts:
1) Post this on gcc@ as undoubtedly RTH will have an opinion about it.
2) Perhaps your glibc build is somehow screwed up. As it is some of the
startup files in glibc that add the end of eh table markers.
David Daney
Scott Gilbertson wrote:
I wonder if someone reasonably familiar with the unwinder can have a look at
the hacks documented below, and tell me whether they indicate a bug, or
conversely whether they provide a clue as to why the interpreter and
static-built executables aren't working for me, even though other people
seem to have no problem. Thanks.
I now have a simple program like the following one working as static
binaries with recent gcc (this program crashed without my hacks).
public class Nothing
{
public static void main (String[] args)
{
}
}
More complex programs also now work, including AWT with xlib, and an example
that throws and catches an Exception (demonstrating, I think, that the
unwinder sometimes works in my environment). The GIJ interpreter (which is
of course NOT statically linked) still aborts, and since I don't get any
symbols in its backtrace, I'm not sure how to pursue that. My programs work
fine when built as dynamic executables even without the hacks. The
interpreter works fine with the SJLJ unwinder (without the hacks), but
static executables don't.
I'm using this software:
gij (GNU libgcj) version 4.1.0 20051116 (experimental)
(revision 107090 from SVN, checked out 2005-11-16)
gcj (GCC) 4.1.0 20051116 (experimental)
(same sources)
Linux version 2.6.8.1-10mdk
(cpu is Pentium 4)
binutils-2.15.90.0.3-1mdk
glibc-2.3.3-21mdk
My original gcc configuration, which works fine with gcc-4_0-branch from
July
../gcc/configure
--prefix=/var/local/gcc/tip_20051115
--mandir=/var/local/gcc/man
--infodir=/var/local/gcc/info
--enable-shared
--enable-threads=posix
--disable-checking
--host=i386-redhat-linux
--enable-java-awt=xlib
--enable-libgcj
--enable-languages=c,c++,java
--with-system-zlib
--enable-__cxa_atexit
For my SJLJ unwinder tests, I added --enable-sjlj-exceptions
Here are the hacks I did to get the static builds working. Do they offer
any clues?
HACK #1:
The first hack addresses this crash:
#9020
#9021 0x080921db in _Unwind_IteratePhdrCallback (info=0xb040, size=32,
ptr=0xb094)
at ../../gcc/gcc/unwind-dw2-fde-glibc.c:262
Index: unwind-dw2-fde-glibc.c
===
--- unwind-dw2-fde-glibc.c (revision 107090)
+++ unwind-dw2-fde-glibc.c (working copy)
@@ -257,7 +257,7 @@ _Unwind_IteratePhdrCallback (struct dl_p
if (size >= sizeof (struct ext_dl_phdr_info))
{
- if (last_cache_entry != NULL)
+ if (prev_cache_entry != NULL && last_cache_entry != NULL)
{
prev_cache_entry->link = last_cache_entry->link;
last_cache_entry->link = frame_hdr_cache_head;
[end of hack diff]
So prev_cache_entry is obviously null sometimes, presumably because this
thing in the same file "found an unused entry":
last_cache_entry = cache_entry;
/* Exit early if we found an unused entry. */
if ((cache_entry->pc_low | cache_entry->pc_high) == 0)
break;
if (cache_entry->link != NULL)
prev_cache_entry = cache_entry;
Looking at the changes to unwind-dw2-fde-glibc.c, I see that the parts of
the code I've shown here were structured differently in the 4.0 branch
(which works just fine for me with static builds). Maybe that's a clue.
HACK #2:
The first hack got the unwinder to return to _Jv_Throw rather than crashing,
so I was able to get an error code: _URC_END_OF_STACK.
That leads to an abort in _Jv_Throw. I did another backtrace (that's about
all I can do - gdb hangs up running these executables for some reason, so
I'm stuck with core dumps).
#0 0x08325081 in kill ()
#1 0x0830d1aa in __pthread_raise ()
#2 0x08325368 in abort ()
#3 0x0809dc9d in _Jv_Throw (value=0x4d828) at
../../../gcc/libjava/exception.cc:114
#4 0x08093537 in catch_segv (_dummy=Could not find the frame base for
"catch_segv".
) at ../../../gcc/libjava/prims.cc:152
#5
#6 0x080b6a65 in _Jv_FreeMethodCache () at
../../../gcc/libjava/java/lang/natClass.cc:941
#7 0x080bd279 in java::lang::Thread::finish_ (this=0x61f18)
at ../../../gcc/libjava/java/lang/natThread.cc:219
#8 0x080943a2 in _Jv_RunMain (vm_args=0x0, klass=0x851d660, name=0x0,
argc=1, argv=0xb8a4,
is_jar=false) at ../../../gcc/libjava/prims.cc:1386
#9 0x080944f8 in _Jv_RunMain (klass=0x851d660, name=0x0, argc=1,
argv=0xb8a4, is_jar=false)
at ../../../gcc/libjava/prims.cc:1397
#10 0x0809452b in JvRunMain (klass=0x851d660, argc=1, argv=0xb8a4)
at ../../../gcc/libjava/prims.cc:1403
#11 0x08048235 in main ()
Strange: natClass.cc:941 is just "if (method_cache != NULL)", which
shouldn't be able to cause a segv. I'm guessing the error is actually in
_Jv_Free. So I just commented out
Re: compiling gcc-4.0.2 on solaris 9
> Although the compiler's executable is composed of 32-bit code, it can > generate 32 or 64 bit code, which is what I meant by "both compilers". Ah! Indeed, but you're going to further confuse the readers. :-) I think the best terminology is "32-bit multilib compiler" for sparc-sun-solaris and "64-bit multilib compiler" for sparc64-sun-solaris. -- Eric Botcazou
dwarf2 unwinder hacks get my static build going: Bug, or indication of what I'm doing wrong?
I originally posted this on the java list, but the suggestion was made that
I post it here to see if somebody can help.
My previous related posts to the java list (I was originally thinking I had
two separate problems):
http://gcc.gnu.org/ml/java/2005-11/msg00230.html
http://gcc.gnu.org/ml/java/2005-11/msg00229.html
I wonder if someone reasonably familiar with the unwinder can have a look at
the hacks documented below, and tell me whether they indicate a bug, or
conversely whether they provide a clue as to why the interpreter and
static-built executables aren't working for me, even though other people
seem to have no problem. Thanks.
I now have a simple program like the following one working as static
binaries with recent gcc (this program crashed without my hacks).
public class Nothing
{
public static void main (String[] args)
{
}
}
More complex programs also now work, including AWT with xlib, and an example
that throws and catches an Exception (demonstrating, I think, that the
unwinder sometimes works in my environment). The GIJ interpreter (which is
of course NOT statically linked) still aborts, and since I don't get any
symbols in its backtrace, I'm not sure how to pursue that. My programs work
fine when built as dynamic executables even without the hacks. The
interpreter works fine with the SJLJ unwinder (without the hacks), but
static executables don't.
I'm using this software:
gij (GNU libgcj) version 4.1.0 20051116 (experimental)
(revision 107090 from SVN, checked out 2005-11-16)
gcj (GCC) 4.1.0 20051116 (experimental)
(same sources)
Linux version 2.6.8.1-10mdk
(cpu is Pentium 4)
binutils-2.15.90.0.3-1mdk
glibc-2.3.3-21mdk
My original gcc configuration, which works fine with gcc-4_0-branch from
July
../gcc/configure
--prefix=/var/local/gcc/tip_20051115
--mandir=/var/local/gcc/man
--infodir=/var/local/gcc/info
--enable-shared
--enable-threads=posix
--disable-checking
--host=i386-redhat-linux
--enable-java-awt=xlib
--enable-libgcj
--enable-languages=c,c++,java
--with-system-zlib
--enable-__cxa_atexit
For my SJLJ unwinder tests, I added --enable-sjlj-exceptions
Here are the hacks I did to get the static builds working. Do they offer
any clues?
HACK #1:
The first hack addresses this crash:
#9020
#9021 0x080921db in _Unwind_IteratePhdrCallback (info=0xb040, size=32,
ptr=0xb094)
at ../../gcc/gcc/unwind-dw2-fde-glibc.c:262
Index: unwind-dw2-fde-glibc.c
===
--- unwind-dw2-fde-glibc.c (revision 107090)
+++ unwind-dw2-fde-glibc.c (working copy)
@@ -257,7 +257,7 @@ _Unwind_IteratePhdrCallback (struct dl_p
if (size >= sizeof (struct ext_dl_phdr_info))
{
- if (last_cache_entry != NULL)
+ if (prev_cache_entry != NULL && last_cache_entry != NULL)
{
prev_cache_entry->link = last_cache_entry->link;
last_cache_entry->link = frame_hdr_cache_head;
[end of hack diff]
So prev_cache_entry is obviously null sometimes, presumably because this
thing in the same file "found an unused entry":
last_cache_entry = cache_entry;
/* Exit early if we found an unused entry. */
if ((cache_entry->pc_low | cache_entry->pc_high) == 0)
break;
if (cache_entry->link != NULL)
prev_cache_entry = cache_entry;
Looking at the changes to unwind-dw2-fde-glibc.c, I see that the parts of
the code I've shown here were structured differently in the 4.0 branch
(which works just fine for me with static builds). Maybe that's a clue.
HACK #2:
The first hack got the unwinder to return to _Jv_Throw rather than crashing,
so I was able to get an error code: _URC_END_OF_STACK.
That leads to an abort in _Jv_Throw. I did another backtrace (that's about
all I can do - gdb hangs up running these executables for some reason, so
I'm stuck with core dumps).
#0 0x08325081 in kill ()
#1 0x0830d1aa in __pthread_raise ()
#2 0x08325368 in abort ()
#3 0x0809dc9d in _Jv_Throw (value=0x4d828) at
../../../gcc/libjava/exception.cc:114
#4 0x08093537 in catch_segv (_dummy=Could not find the frame base for
"catch_segv".
) at ../../../gcc/libjava/prims.cc:152
#5
#6 0x080b6a65 in _Jv_FreeMethodCache () at
../../../gcc/libjava/java/lang/natClass.cc:941
#7 0x080bd279 in java::lang::Thread::finish_ (this=0x61f18)
at ../../../gcc/libjava/java/lang/natThread.cc:219
#8 0x080943a2 in _Jv_RunMain (vm_args=0x0, klass=0x851d660, name=0x0,
argc=1, argv=0xb8a4,
is_jar=false) at ../../../gcc/libjava/prims.cc:1386
#9 0x080944f8 in _Jv_RunMain (klass=0x851d660, name=0x0, argc=1,
argv=0xb8a4, is_jar=false)
at ../../../gcc/libjava/prims.cc:1397
#10 0x0809452b in JvRunMain (klass=0x851d660, argc=1, argv=0xb8a4)
at ../../../gcc/libjava/prims.cc:1403
#11 0x08048235 in main ()
Strange: natClass.cc:941 is just "if (method_cache != NULL)", which
shouldn't be able to cause a segv. I'm guess
Re: Incompatible behavior -O0, -O3, std::cout
Andrew Pinski <[EMAIL PROTECTED]> writes:
>>
>> Hello Everyone
>>
>> I noticed some thing strange recently. This code (under g++ (GCC) 3.2.3
>> 20030502 (Red Hat Linux 3.2.3-53)), provides this output with -O0 flag:
>> int main(int argc, char **argv) {
>> std::cout << f1() << f2() << std::endl;
>> }
>>
>>
>> I'm pretty sure that I am depending on an undefined behavior here, but
>> maybe you guys would want to have a deeper look at this.
>
>
> Yes are you dependening on undefined behavior.
Actually, it is unspecified behavior.
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: pruning unused debugging types (enums/PR23336)
Aldy Hernandez wrote: > Either way is fine by me. Just to make sure I understand things; > you want me to hack the front-end to fill the hash table every time > it parses a cast or enum type? Yes. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Issue with find_tail_calls
> if (!is_gimple_reg_type (TREE_TYPE (param)) > ! || !tree_ssa_useless_type_conversion_1 (TREE_TYPE (param), > ! TREE_TYPE (arg))) Seems reasonable. These are the conversions we strip across move statements. Which is about the same for what we'd want across a return. What about the other cases where this would apply? I can't think of any cases where checking the lang hook directly is correct. Can you?
Re: dwarf2 unwinder hacks get my static build going: Bug, or indication of what I'm doing wrong?
On Fri, Nov 18, 2005 at 06:17:49PM -0500, Scott Gilbertson wrote:
> - if (last_cache_entry != NULL)
> + if (prev_cache_entry != NULL && last_cache_entry != NULL)
This one looks like it may be a legitimate problem with the list
manipulation, though this isn't the proper fix.
> Looking at the changes to unwind-dw2-fde-glibc.c, I see that the parts of
> the code I've shown here were structured differently in the 4.0 branch
> (which works just fine for me with static builds). Maybe that's a clue.
Um, I don't see that at all. I see some minor changes wrt abort,
and one spot where we use a local temporary instead of storing the
value directly into data->func.
> _Jv_FreeMethodCache function, and now my simple test cases work. Like so:
> void
> _Jv_FreeMethodCache ()
> {/*
> #ifdef HAVE_TLS
> if (method_cache != NULL)
I will say that staticly linked linuxthreads tls is known to be
broken. Or at least known to me. I encountered this while doing
OpenMP work on RHEL3. The problem I saw doesn't appear with nptl.
r~
LLVM/GCC Integration Proposal
Hi Everyone, At the request of several members of the GCC community, I'm writing this email to describe some of my short-term plans with GCC and describe an alternative to the recent link-time optimization [1] and code generator rewrite [2] proposals. For those who are not familiar with me, I'm one of the main developers working on the LLVM project (http://llvm.org/). One important way that LLVM is currently used is as a back-end for GCC. In this role, it provides a static optimizer, interprocedural link- time optimizer, JIT support, and several other features. Until recently, LLVM has only been loosely integrated with an old version of GCC (a 3.4 prerelease), which limited its effectiveness. Recently, at Apple, I have been working on a new version of the llvm- gcc translation layer, built on GCC 4. This implementation links the LLVM optimizers and code generator directly into the GCC process, replacing the tree-ssa optimizers and the RTL code generator with the corresponding LLVM components when enabled. The end result is a compiler that is command line compatible with GCC: 'gcc -S t.c -o t.s' does exactly what you'd expect, and most standard command line options are supported (those that aren't are very specific to the design of the RTL backend, which we just ignore). I plan to have this work committed to the Apple branch within a month. Though not yet implemented, we intend to support link-time optimization with many design constraints that match the recent proposal [1]. Because LLVM already currently supports link-time optimization and has an architecture that makes it straight-forward, this work mainly amounts to changes in the GCC compiler-driver. If you're interested in the link-time IPO architecture, there are documents that describe the high level ideas [10,11] with some (potentially out of date) implementation information. In this email, I want to briefly talk about the strengths that LLVM brings to the table, some of the implementation details of my integration work, some of the important ongoing work that we are working on, and answer some of the hot questions that will inevitably come up. :) Strengths of LLVM LLVM is a modern and efficient compiler framework built out of libraries with well defined APIs. As I mentioned above, LLVM provides an optimizer and code generator. It also provides several other components I won't discuss here. If you are interested, please see LLVM's extensive documentation [9] for more information. The LLVM mid-level and interprocedural optimizer work on a common representation (the LLVM IR), which is a three-address SSA-based representation that is somewhat similar to GIMPLE. It is fully specified [3], is easy to analyze and manipulate [4], and is very memory efficient (for example, it takes about 50M of memory on a 32- bit host to hold the IR for all of 176.gcc, which is about 230K LOC). The IR has a text form (suitable for compiler dumps and fine- grained regression testing) and a 100% equivalent compressed binary form (suitable for interchange between compile-time and link-time optimization steps), both of which correspond to the in-memory IR. The IR supports several features that are useful to various communities, including true tail calls, accurate garbage collection, etc. The IR is continuously evolving to add new features, and we plan several extensions in the future. The optimizer itself has a full suite of standard scalar optimizations and also includes a collection of interprocedural optimizations and interprocedural analyses, some of which are quite aggressive [5] (though this particular set is not enabled by default). The optimizer is fully modular, which allows us to have nice tools for working with the IR and optimizer, including an automated bug finding tool [6] which makes tracking down miscompilations and ICEs really easy. The LLVM code generator is built on modern techniques. For example, it uses pattern-matching DAG-based instruction selection, maintains SSA form up until register allocation, represents code in a form quite similar to the "compressed RTL" proposal [7], and supports dynamically loaded targets. We currently have stable code generators for PowerPC and X86, with targets for Alpha, IA-64, and Sparc also available, but less stable. LLVM can also emit C code, which allows it to support systems for which we do not have a native code generator implemented. The design of the register allocation components is very close to that proposed in Andrew MacLeod's recent proposal [2]. We have separate instruction selection, global coalescing, and register allocation stages, have a spiller that does simple local register allocation, etc. We currently support multiple pluggable register allocators, to (for example) support quick -O0 compiles, and to support targets who want to h
Re: Issue with find_tail_calls
On Fri, Nov 18, 2005 at 08:12:32PM -0500, Richard Kenner wrote: > What about the other cases where this would apply? I can't think of any > cases where checking the lang hook directly is correct. Can you? Deciding if one can replace one object with another, or one pointer with another in an actual dereference. I think this is used pleanty of places that are not moves. lang_hooks.types_compatible_p has the benefit of being commutative, whereas tree_ssa_useless_type_conversion is not. r~
Re: dwarf2 unwinder hacks get my static build going: Bug, or indication of what I'm doing wrong?
On Fri, Nov 18, 2005 at 05:48:26PM -0800, Richard Henderson wrote:
> > _Jv_FreeMethodCache function, and now my simple test cases work. Like so:
> > void
> > _Jv_FreeMethodCache ()
> > {/*
> > #ifdef HAVE_TLS
> > if (method_cache != NULL)
>
> I will say that staticly linked linuxthreads tls is known to be
> broken. Or at least known to me. I encountered this while doing
> OpenMP work on RHEL3. The problem I saw doesn't appear with nptl.
Got a handy testcase, or is it catastrophic? There are a small number
of static tests in the linuxthreads testsuite and I've run it on HEAD
recently.
--
Daniel Jacobowitz
CodeSourcery, LLC
Re: LLVM/GCC Integration Proposal
On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote: > * This will not support ! > > As describe above, we won't support every target that GCC currently > does. Three options are possible: > > 1. We (the GCC community) could build an LLVM to GIMPLE translator. > This would probably take about as much work as the GIMPLE -> LLVM > translator (about 4000 LOC), which is not a huge project. > 2. We could build an LLVM to RTL translator. Let's run with the hypotheticals for a bit here... I have questions for both Chris and for GCC maintainers. Chris tells me that an LLVM->GIMPLE translator wouldn't have target dependencies. I'm not 100% sure I buy that, but I'll take it as given for now (if not they should be pleasantly small). So suppose we implement that. It seems like a much better choice than RTL anyway. (A) What bits of LLVM would we be bypassing, and how badly would we miss them? I know it has its own register allocation and instruction selection, and they have advantages and disadvantages relative to the existing ones. We could either take advantage of those as a framework to modernize GCC's, or move on with Andrew's new design to modernize GCC's. (B) What bits of GCC would we be bypassing, and how badly would we miss them? Presumably, many of the shiny new tree optimizers. Ow. But GCC was not in any state to do this sort of surgery a year ago, I think. -- Daniel Jacobowitz CodeSourcery, LLC
GCC 4.1 branch created
I have created the GCC 4.1 branch, so any future commits for bug-fixes destined for 4.1 should go on the branch as well as on the mainline. I am still working through the remainder of the branch checklist. Please treat the mainline as if it were still in 4.1 Stage 3 until I have a chance to complete the checklist and send out information about 4.2 Stage 1; that will happen within the next thirty minutes. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: LLVM/GCC Integration Proposal
Daniel Jacobowitz writes: As describe above, we won't support every target that GCC currently does. Three options are possible: Chris tells me that an LLVM->GIMPLE translator wouldn't have target dependencies. I'm not 100% sure I buy that, but I'll take it as given for now (if not they should be pleasantly small). So suppose we implement that. It seems like a much better choice than RTL anyway. I'm not sure exactly what you mean by target dependencies, but everything target dependent has to (by definition) be represented in the LLVM code already. LLVM makes things like "implicitly passing a pointer when returning a struct" explicit in the representation, as well as funny ABI things like passing FP values in integer registers. Given that this is already handled, translating to GIMPLE should be quite straight-forward. GIMPLE and LLVM are really quite close to each other: I've built the LLVM to GIMPLE translator in about 2-3 weeks, and most of that time has been figuring out target hooks to do the target-specific lowering correctly. (A) What bits of LLVM would we be bypassing, and how badly would we miss them? A system that used LLVM for the mid-level IR and then converted back to RTL would enjoy all of the benefits of the LLVM IR (compactness, ease of manipulation, testability, modularity, etc) but would just not have the code generator. I see this as a great intermediate point that would be good for migrating targets if and when desired. For example, targets that the GCC backend currently serves well could stay with the RTL backend until the LLVM targets improve (or exist :) ), and those targets that are better served by the LLVM backend could use it. One example area where LLVM excels is lowering of code in the backend (e.g. promoting small values to GPRs for RISC machines, and breaking up large integer values for targets without 64-bit registers). (B) What bits of GCC would we be bypassing, and how badly would we miss them? Presumably, many of the shiny new tree optimizers. Ow. But GCC was not in any state to do this sort of surgery a year ago, I think. Quite true. I'll let others comment about the implications of that. One very important point is that because GIMPLE and LLVM are very similar in spirit, optimizers could easily be moved over (just like the LLVM reassociation pass was moved over to GCC). I assert that the *implementation* of the LLVM IR is lighter weight than the current "tree"-based GIMPLE IR (though they are both very close in spirit to each other), which helps with memory usage and compile times. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
> (B) What bits of GCC would we be bypassing, and how badly would we miss > them? > > Presumably, many of the shiny new tree optimizers. Ow. But GCC was > not in any state to do this sort of surgery a year ago, I think. > Probably true on both counts, but that wouldn't bother me, speaking as someone who has written a lot of code for the tree optimizers. The tree optimizers serve a purpose, they are not a goal unto themselves. If LLVM can serve that purpose, and do so better (or can be made to do so better by moving improvements, extending it), while at the same time bringing us other benefits, then the correct technical decision is to move to it and replace the tree optimizers. Realistically, we are going to end up doing as much surgery on the GIMPLE and SSA representation (in terms of underlying data structures, aliasing, re-writing and re-tooling optimizers, etc) in order to make IPA work well, that 1. It will probably be same amount of work (if not less work) to move the improvements we have *to* LLVM, as all the surgery is going to take to make IPA sane in GCC. The only real difference is in what work you are doing. Building it from scratch may seem intellectually cool or whatever, but from a technical standpoint, you aren't going to end up with an infrastructure significantly better than LLVM's infrastructure is or could be extended to be. This is because anybody who has looked at compilers that have really good IPA will tell you that you realistically can't do better in terms of compile speed or memory usage, and that there is no magic that we could perform that we can't make LLVM perform. 2. LLVM is here and we know it works, plus we know it's memory usage and compile time on various applications. All *we* have is guesses on how much memory and compile time we can save based on what kind of surgery you want to perform. We have some idea for what it would take to make IPA work well, and the rest is just expected to "become clear" as things progress. The bottom line is that personally, I'm not in love with tree-ssa or my code enough that I think ego should stand in the way of GCC making the right decision. I would hope others who have written the "shiny new tree optimizers" feel the same way. I'd be just as happy moving data dependence, aliasing improvements (that aren't subsumed by DSAA, which there are still plenty of :P), high level loop transforms, better PRE, etc, from GCC to LLVM, as i would re-tooling it to work with whatever we came up with from scratch. GCC has a lot of hard work ahead of it, whether we choose to build it from scratch and do major surgery. The question is whether you want to take what we know works, or roll the dice and hope you can make something better. Unless y'all think you are going to get really lucky, and do something nobody has been able to do yet, integrating LLVM is, IMHO, a sound technical decision, even if it means replacing the tree optimizers. Just my 2 cents, Dan
Re: GCC 4.1 branch created
Mark Mitchell wrote: > I am still working through the remainder of the branch checklist. I believe that I have now completed the checklist, with the exception of: # Generate the next mainline snapshot manually, using the -p option of the gcc_release script. For that single run, adjust the script such that the announcement mail is sent to you personally so that you can adjust references to the previous snapshot in the README and index.html files of the new snapshot as well as the mail itself before relaying it. # Regenerate gcc.pot and cpplib.pot. Send them to the translation project. Joseph, would you be willing to help me with those two items? I don't know how do to the first, and you seem more facile than I with the .pot files. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC 4.2
I've reviewed the GCC 4.2 projects on the Wiki. It certainly looks like some exciting stuff is in the pipeline. For 4.2, I'm not going to try to be too fine-grained about scheduling the individual projects; in 4.1, I don't think I added much value by doing that. Also, a lot of the project pages didn't have very precise data about availability. So, all I did here is separate them into Stage 1 and Stage 2 contributions. Even then, I don't want to forbid things listed under Stage 2 from going in under Stage 1, if the Stage 2 things are ready, but let's give priority to the Stage 1 things. I put things into Stage 1 that seemed either (a) most risky or (b) most ready. I'll readily concede that I may have miscategorized, and it's OK with me if people just treat the categorization as an informal guideline. Rather than try to make a fine-grained schedule, I'd like to ask that we just try to cooperate with each other to avoid destabilizing the mainline unduly, even through Stage 1. In particular: * Please announce major merges of new functionality 24 hours before the actual merge * Please allow 24 hours after a major merge before the next major merge * Please refrain from a major merge if we're currently experiencing serious stability problems that are being resolved from the previous merge. As of now, we're in GCC 4.2 Stage 1! == Stage 1 Projects * Decimal Floating Point * GOMP: library, middle-end, C * IPA cleanups * Load partial redundancy elimination * New tree reassociation pass * Remove old loop optimizer * Section Anchor Optimisations * Sign Extension Removal * Support for IA-64 speculation * Vectorization Enhancements, Part 1 Stage 2 Projects * Array references on pointers * GOMP: C++, Fortran * Induction variable optimizations cleanups * IPA on SSA Form * Omega data dependence test * Record GCC command line switches in object files * Replacements for CSE path following * Replace backend dataflow * Response files * Sub-Target specific math routines library * Vectorization Enhancements, Parts 2 and onwards. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Dich vu moi!!!
Kinh gui quy Ong/Ba chu doanh nghiep, Chung toi xin gui toi quy Ong/Ba Dich vu quang cao qua e-mail hieu qua nhat, gia hop ly. Voi hon 1.800.000 dia chi e-mail cua cac to chuc, don vi, ca nhan trong va ngoai nuoc, chung toi khang dinh se quang ba rong rai ten tuoi cua doanh nghiep do quy Ong/Ba la chu nhan. Chi voi chi phi rat nho la 200.000VND cho 03 lan gui, thong tin ve san pham, dich vu do cong ty cua quy Ong/Ba cung cap, se duoc hon 1.800.000 ca nhan va to chuc, trong va ngoai nuoc biet toi. Quy Ong/Ba co the chon lua gui theo 03lan/tuan hoac 03lan/thang(gia khong doi), hoac mua tron goi ca phan mem gui va co so du lieu gom hon 1.800.000 dia chi e-mail de tu gui. Neu quy Ong/Ba co nhu cau, xin vui long gui e-mail den dia chi: [EMAIL PROTECTED] .Xin cam on da doc tin. Rat han hanh duoc phuc vu.
Dich vu moi!!!
Kinh gui quy Ong/Ba chu doanh nghiep, Chung toi xin gui toi quy Ong/Ba Dich vu quang cao qua e-mail hieu qua nhat, gia hop ly. Voi hon 1.800.000 dia chi e-mail cua cac to chuc, don vi, ca nhan trong va ngoai nuoc, chung toi khang dinh se quang ba rong rai ten tuoi cua doanh nghiep do quy Ong/Ba la chu nhan. Chi voi chi phi rat nho la 200.000VND cho 03 lan gui, thong tin ve san pham, dich vu do cong ty cua quy Ong/Ba cung cap, se duoc hon 1.800.000 ca nhan va to chuc, trong va ngoai nuoc biet toi. Quy Ong/Ba co the chon lua gui theo 03lan/tuan hoac 03lan/thang(gia khong doi), hoac mua tron goi ca phan mem gui va co so du lieu gom hon 1.800.000 dia chi e-mail de tu gui. Neu quy Ong/Ba co nhu cau, xin vui long gui e-mail den dia chi: [EMAIL PROTECTED] .Xin cam on da doc tin. Rat han hanh duoc phuc vu.
