On 6/7/07, Bernardo Innocenti [EMAIL PROTECTED] wrote:
Harvey Harrison wrote:
The final results of a repository holding a clone of trunk:
With or without branches? (shouldn't matter that much, just
for the record)
Just trunk.
Size of git packs:
pack + index - 286344kB
git svn metadata
Zdenek Dvorak [EMAIL PROTECTED] writes:
The problem is, that it does not give any speedups (it is almost
completely compile-time neutral for compilation of preprocessed
gcc sources). I will check whether moving also edges to pools
changes anything, but so far it does not seem very
Hello,
as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html,
it might be a good idea to try moving cfg to alloc pools. The patch
below does that for basic blocks (each function has a separate pool
from that its basic blocks are allocated). At the moment, the patch
On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote:
I am aware of three remaining projects which are or might be
appropriate
for Stage 1:
I wasn't sure of the Objective-C 2.0 timing until recently... I'd
like to contribute it during stage 2.
Brooks Moses wrote (on the Fortran BIND(C) project):
I don't believe this project has been documented very well (if at all)
on the standard Wiki page for Stage-1 projects, but I haven't looked at
it in a while. I am also not entirely certain whether this qualifies as
a Stage 1 or a Stage 2
On Thu, Jun 07, 2007 at 08:40:14AM +1000, Ben Elliston wrote:
On Wed, 2007-06-06 at 16:46 +0200, Gerald Pfeifer wrote:
In that case it's probably not that good of a idea to promote it (unless
the maintainers are in favor, of course ;-).
I'm happy to leave things as they are for now.
On Thu, Jun 07, 2007 at 10:33:26PM -0700, Mark Mitchell wrote:
I am aware of three remaining projects which are or might be appropriate
for Stage 1:
In the interests of moving forwards, I therefore plan to close this
exceptionally long Stage 1 as of next Friday, June 15th. The projects
Hello everyone,
For my bachelor thesis I'm modifying gcc to use machine learning to
predict the optimal unroll factor for different loops (inspired from
this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-938.pdf).
I've compiled gcc 4.1.2 on my machine and I've located the
On 6/8/07, Brooks Moses [EMAIL PROTECTED] wrote:
Mark Mitchell wrote:
In the interests of moving forwards, I therefore plan to close this
exceptionally long Stage 1 as of next Friday, June 15th. The projects
named above may be merged, even though we will be in Stage 2 -- but no
other
Hello everyone,
For my bachelor thesis I'm modifying gcc to use machine learning to
predict the optimal unroll factor for different loops (inspired from
this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-938.pdf).
I've compiled gcc 4.1.2 on my machine and I've located the
H.J.,
Yes, that is possible
Marius
-Original Message-
From: H. J. Lu [mailto:[EMAIL PROTECTED]
Sent: Friday, June 08, 2007 6:07 AM
To: Mark Mitchell
Cc: GCC; Kenneth Zadeck; Andrew Pinski; Cornea, Marius
Subject: Re: GCC 4.3.0 Status Report (2007-06-07)
On Thu, Jun 07, 2007 at
All,
I have booked a 2 bedroom suite at Les Suites for 07/17 checkin and
07/21 checkout. If someone would like to take the second bedroom (or
the living room daybed) we can split costs.
-All 4 nights please
-Everyone's name will be added to the reservation to avoid checkin
problems.
If you're
I recall there were supposed to be some unresolved
issues with creating shared libraries for ada on darwin
in the past. Have those been resolved or will they be
addressed for the gcc 4.3.0 release? I ask because I
am considering adding ada to the set of languages built
for a future fink gcc43
Richard == Richard Kenner [EMAIL PROTECTED] writes:
Richard The simplest example of that is an uninitialized variable.
Richard I think the best approach is to use flags set by the front
Richard end to indicate which of these is to be the case. For C, I
Richard believe (1) is always the proper
With Java the middle end should never see an uninitialized variable.
Uninitialized variables are precluded by the language definition, or
the bytecode verifier.
Then if there's no other way in the language to create an undefined value,
Java should certainly use the undefined choice, like C.
On 08 Jun 2007, at 16:31, Stefan Ciobaca wrote:
Hello everyone,
For my bachelor thesis I'm modifying gcc to use machine learning to
predict the optimal unroll factor for different loops (inspired from
this paper: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-
TR-938.pdf).
The comment for note_stores() (in rtlanal.c) says:
/* Call FUN on each register or MEM that is stored into or clobbered by X.
(X would be the pattern of an insn).
But this doesn't happen when a register is modified by e.g. a PRE_DEC
expression. Is this an oversight or intentional? If
Mike Stump wrote:
On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote:
I am aware of three remaining projects which are or might be appropriate
for Stage 1:
I wasn't sure of the Objective-C 2.0 timing until recently... I'd like
to contribute it during stage 2.
That's OK with me, but with two
On Jun 8, 2007, at 12:50 PM, Mark Mitchell wrote:
That's OK with me, but with two caveats:
We are in the final stages of releasing this, so most development and
testing has been done as well as ensuring that C and C++ are
unaffected. This should help us meet the safeness goals. Thanks
I'm working with a target that has a call instruction
similar to SPARC: the address of the calling instruction
is saved in a link register (lr). The actual return address
is, like SPARC, lr+8.
It seemed to me that the right thing would be to have the
initial value of the return address column
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes:
The comment for note_stores() (in rtlanal.c) says:
/* Call FUN on each register or MEM that is stored into or clobbered by X.
(X would be the pattern of an insn).
But this doesn't happen when a register is modified by e.g. a
Joseph S. Myers wrote:
On Thu, 7 Jun 2007, Mark Mitchell wrote:
I am aware of three remaining projects which are or might be appropriate
for Stage 1:
Do we at this point believe that the people who were working on updating
the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk
Brooks Moses wrote:
Several members of the GFortran team (primarily Chris Rickett and Steve
Kargl) have been working on a project to add the BIND(C) functionality
from the Fortran 2003 standard. This provides for a standard means of
linking Fortran code with code that uses standard C linkage
Mark Mitchell wrote:
I attached a diff file for 14 files of the new structures
and documents. You and other maintainers are welcome to
check it. Thanks a lot!
Thank you for posting this.
Things about which I am clueless:
What is the difference between a _Fract type and an
Mark Mitchell wrote:
Brooks Moses wrote:
Several members of the GFortran team (primarily Chris Rickett and Steve
Kargl) have been working on a project to add the BIND(C) functionality
from the Fortran 2003 standard. This provides for a standard means of
linking Fortran code with code that uses
Snapshot gcc-4.3-20070608 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070608/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Andrew,
I tested mipsel-linux and mips64-elf on the pointer_plus branch for c,
and c++.
For r125291 mips64-elf the only regressions are those that would be
expected (I think):
-PASS: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1
+FAIL: gcc.dg/matrix/matrix-1.c
Hello,
The number of floating point ops. in loop body.
The number of memory ops. in loop body.
The number of operands in loop body.
The number of implicit instructions in loop body.
The number of unique predicates in loop body.
The number of indirect references in loop body.
The number of
On 6/7/07, Mark Mitchell [EMAIL PROTECTED] wrote:
* PTR_PLUS branch.
I believe that this branch should be included in GCC 4.3. Andrew,
would you please update me as to its status?
Yes, the summary is the branch has two autovector regressions in the
testsuite, not directly related to the IR
Fu, Chao-Ying wrote:
Right now, the fixed-point support is a configure-time option.
Each target can decide to support it or not. I think there is no
harm to enable for every target. But, each target needs to modify
tm.h tm.c tm-modes.def to set or change some target macros.
I would
--- Comment #10 from irar at gcc dot gnu dot org 2007-06-08 06:31 ---
Subject: Bug 31699
Author: irar
Date: Fri Jun 8 06:31:39 2007
New Revision: 125560
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125560
Log:
Backport from mainline:
2007-05-03 Dorit Nuzman
The following code compiles and run find using my system's
g++-4.1.3 but when compiled with g++-4.2.1 from SVN,
I get
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
//-
#include clocale
--- Comment #2 from ubizjak at gmail dot com 2007-06-08 07:20 ---
Confirmed, fails also on i686 (-O3 -msse2 -ftree-vectorize).
Backtrace:
#1 0x08686e6e in vectorizable_type_promotion (stmt=0xb7d0624c, bsi=0x0,
vec_stmt=0x0) at ../../gcc-svn/trunk/gcc/tree-vect-transform.c:2891
#2
--- Comment #171 from ian at airs dot com 2007-06-08 07:49 ---
Created an attachment (id=13666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666action=view)
Patch
This variant of the previous patch does better on at least some of the tramp3d
functions. Here we eliminate the
--- Comment #12 from rakdver at gcc dot gnu dot org 2007-06-08 07:29
---
Subject: Bug 32209
Author: rakdver
Date: Fri Jun 8 07:28:50 2007
New Revision: 125563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125563
Log:
PR middle-end/32209
* dominance.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-08 07:52 ---
(In reply to comment #1)
no, this is OK (whether it is a good design choice is another thing, I will
think about that).
I actually have a fix for this issue (the MEM with just index: and offset:) but
it is going
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06
---
Patch reverted until Lee comes back, PR assigned to him.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:04
---
(In reply to comment #1)
r125316 | fxcoudert | 2007-06-04 22:59:49 +0200 (Mo, 04 Jun 2007) | 31 lines
2007-06-04 Lee Millward [EMAIL PROTECTED]
http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00072.html
Patch
--- Comment #7 from chrbr at gcc dot gnu dot org 2007-06-08 07:58 ---
Subject: Bug 29953
Author: chrbr
Date: Fri Jun 8 07:58:41 2007
New Revision: 125564
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125564
Log:
PR target/29953
* config/sh/sh.md (doloop_end): New pattern and
--- Comment #3 from ubizjak at gmail dot com 2007-06-08 08:02 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06
---
Patch reverted until Lee comes back, and bug assigned to him so that he takes
care of it in the next round.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from chrbr at gcc dot gnu dot org 2007-06-08 08:18 ---
doloop_optimize does the iv inversion with the doloop_end insn support in the
machine description.
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-06-08 08:38 ---
The only possible explanation is that, at build time, the configury didn't find
the required localedata (at least de_DE) or other tests failed, and the
generic (instead of gnu) locale model has been selected. In that case
--- Comment #5 from dorit at gcc dot gnu dot org 2007-06-08 08:58 ---
Subject: Bug 32224
Author: dorit
Date: Fri Jun 8 08:57:54 2007
New Revision: 125566
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125566
Log:
PR tree-optimization/32224
* tree-vect-analyze.c
--- Comment #4 from uros at gcc dot gnu dot org 2007-06-08 09:06 ---
Subject: Bug 32243
Author: uros
Date: Fri Jun 8 09:06:46 2007
New Revision: 125567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125567
Log:
PR tree-optimization/32243
* tree-vect-transform.c
--- Comment #5 from ubizjak at gmail dot com 2007-06-08 09:14 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|ubizjak at gmail dot
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:11 ---
Confirmed. Instead of calls to _gfortran_pow_r4_i4, gfortran should use
__builtin_powi in this case. __builtin_powi is either expanded inline or
implemented by the libgcc powi function which looks like
TYPE
NAME
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-08 10:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:28 ---
Confirmed. We are wrongly expanding
;; D.2027 = D.2026 32
(insn 18 17 0 (parallel [
(set (reg:DI 59 [ D.2027 ])
(ashift:DI (reg:DI 60 [ D.2026 ])
(const_int 32
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:36 ---
Confirmed.
{
struct foo x = {.mem1=0, .mem2=-1};
cleanup_point struct foo x = {.mem1=0, .mem2=-1};;
cleanup_point Unknown tree: expr_stmt
bar (x.mem2 == (TARGET_EXPR D.2011, {}).mem2)
;
return retval
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:39 ---
works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-08 12:56 ---
(In reply to comment #2)
Also breaks 465.tonto in SPEC2006.
I'd say it's
2007-06-04 Lee Millward [EMAIL PROTECTED]
Gentlemen, you will see that this patch was reverted this morning because it
caused PRs3, 38
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-08 12:27 ---
Also breaks 465.tonto in SPEC2006.
I'd say it's
2007-06-04 Lee Millward [EMAIL PROTECTED]
* trans-intrinsic.c (gfc_conv_intrinsic_function_args): Adjust
to operate on a stack allocated array for
--- Comment #172 from rguenther at suse dot de 2007-06-08 13:47 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Fri, 8 Jun 2007, ian at airs dot com wrote:
--- Comment #171 from ian at airs dot com 2007-06-08
--- Comment #4 from r dot f dot arduini at larc dot nasa dot gov
2007-06-08 14:15 ---
Subject: Re: internal compiler error: in gfc_assign_data_value, at
fortran/data.c:288
Can you please tell me why the compiler flags tauaero.f:1517 while
the problem seems to be associated with the
gcc version 4.3.0 20070608 (experimental)
--
Summary: warning can't open dynamic library
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned
--- Comment #1 from dir at lanl dot gov 2007-06-08 14:59 ---
I just noticed that programs work anyway -
[dranta:~/tests/gfortran-D] dir% rm testioBackspace
[dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f
/usr/bin/ld: warning can't open dynamic library:
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-08 15:13 ---
/usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced
I have seen this problem while regetesting g++. I am not sure, but I think I
have reported the problem to the gcc list without answer
--- Comment #3 from dir at lanl dot gov 2007-06-08 15:32 ---
It is something new for me. My last build from 4 days ago did not have the
problem -
[dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f
[dranta:~/tests/gfortran-D] dir% gfortran --v
Using built-in
The following program exposes a problem with the scoping of the loop variable
in the IO statement:
program test
implicit none
character(len=100) :: value
integer, dimension(100) :: intvalues
integer i
i = 2
intvalues = 42
value = 2 5 69
write(*,*) len(trim(value))
--- Comment #5 from brolley at redhat dot com 2007-06-08 15:41 ---
OK, I've looked into this a bit more. For inspiration I looked into where the
error is generated when an incomplete struct is used instead of an unsized
array. I found it in:
cxx_incomplete_type_diagnostic called by
--- Comment #7 from brolley at redhat dot com 2007-06-08 15:46 ---
Small optimization. We need only call complete_type_or_else once we know it's
an array type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
--- Comment #6 from brolley at redhat dot com 2007-06-08 15:42 ---
Created an attachment (id=13667)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13667action=view)
New proposed patch
--
brolley at redhat dot com changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2007-06-08 15:35 ---
You may also have a look to PR30572.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
Hi, this header (header.h):
#pragma GCC system_header
int noreturn() { }
included by (file.cc):
#include header.h
void ok() { }
Leads to:
paolo:~/Work g++ -Wall -c file.cc
header.h: In function 'int noreturn()':
header.h:2: warning: control reaches end of non-void function
Note, this problem
--- Comment #8 from brolley at redhat dot com 2007-06-08 15:47 ---
Created an attachment (id=13668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13668action=view)
Improvement on previous patch
--
brolley at redhat dot com changed:
What|Removed
-testresults/2007-05/msg01083.html
Here are some other people's results - some used the --with-mpfr option:
Compiled using --with-mpfr=/remote/atg5/jbuck/mpfr-linux :
Results for 4.3.0 20070608 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00396.html
--- Comment #1 from pcarlini at suse dot de 2007-06-08 16:53 ---
In fact, the problem is of the same type of that in C++/30500: in C++ only when
execute_warn_function_return begins in_system_header is zero (in C is 1 and all
the warnings are suppressed because
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-08 16:51 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Hi,
maybe someone of the gcc bugs group can help you, this bug is
unrelated to the video4linux/em28xx project.
Maybe retrying to compile the code might fix it, (I would try to run
memcheck and checking for faulty memory)
Markus
On 6/8/07, Romain Fluttaz [EMAIL PROTECTED] wrote:
Hi, i'm under
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-08 17:14 ---
(In reply to comment #0)
I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
the
most recent patches. My version is 2.2.1-p5.
What does p4 do?
--
kargl at gcc dot gnu dot org changed:
--- Comment #7 from rask at sygehus dot dk 2007-06-08 17:35 ---
Created an attachment (id=13669)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13669action=view)
Patch v3 to add -L and -B as necessary
This patch should fix the mep* case that I accidentally deleted.
--
rask at
I checked http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16104 which is for
gcc.c-torture/execute/20050316-1.c and this is not related.
In this test optimization levels -O0, -O1 and -O2 are broken, levels
-O3 and -Os are OK. I am using rtl and rtlflag checking.
# gcc/xgcc -v
Using built-in specs.
--- Comment #4 from ian at airs dot com 2007-06-08 17:57 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 125521)
+++ tree-vrp.c (working copy)
@@ -2208,6 +2208,8 @@
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:35 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org changed:
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:36 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org changed:
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-06-08 18:46
---
Thank you both for your explanation to a newbie having no experience with
valgrind tool. I have come up with a simpler version which similar to
Laurent's. Here it goes.
Thanks - but how is it supposed to
The following code, compiled with -O2 -Wall (g++ 4.3 as of 20070607),
produces the following unexpected/annoying warning:
test_typeinfo.cpp: In function 'int main()':
test_typeinfo.cpp:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test_typeinfo.cpp:5: warning:
--- Comment #4 from simartin at gcc dot gnu dot org 2007-06-08 18:27
---
Fixed on the mainline.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from anhvofrcaus at gmail dot com 2007-06-08 19:11 ---
You are right Constraint_Error is raised when checking for validity through
Item.all'Valid if Item is null. Therefore, using Laurent's to check Item for
null is the only way. Either one of these methods verifies that
--- Comment #2 from goeran at uddeborg dot se 2007-06-08 19:25 ---
Ok. I've found a few more in parse.y, but I won't bother to report them then.
So far nothing outside this time around, but I have a few hundred messages to
go ... :-)
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 19:50 ---
It is also fixed in 3.4.6.
Well then it is fixed as 3.3.x is no longer being maintained and has not been
for over a year (or two).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Compiling with:
g++ -g -O3 gccbug.cpp -pthread -o gccbug -s
Note that removing the -s eliminates the segfault, as does removing
optimizations with -O0.
This occurs with gcc 3.3 and 3.3.6 but does not occur with the gcc 3.2.3
delivered as part of RedHat ES3.0u5. It is also fixed in 3.4.6.
I have configure gcc like this:
/n/08/rask/src/gcc/configure --target=m68hc11-none --disable-multilib
--disable-nls --with-newlib --enable-sim
Building libgfortran fails with this message:
libtool: compile: /home/rask/build/gcc-m68hc11-none/./gcc/gfortran
Document the required versions of glibc and binutils.
Typically only a couple versions of glibc and binutils are compatible with each
version of gcc, and finding out which ones are compatible is often quite
time-consuming. While gcc/doc/gccinstall.info does document some minimum
versions, it
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 20:16 ---
HUH? I had never had any problems with older versions of GCC with newer
versions of binutils. If you do then either it is a bug in the older version
of GCC (which is likely) or a bug in the newer binutils (which is
When Linux vanilla kernel 2.4.34.5 is compiled with -march=c3 (VIA C3)
- kernel crashes after boot on a VIA C3
.config: CONFIG_MCYRIXIII=y
Environment:
System: Linux bongo 2.4.34.5-ARXc3 COHERENT #9-ARX (Build 3359) Fri Jun 8
16:41:33 CEST 2007 i686 i686 i386 GNU/Linux
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:18 ---
I think we need more information from you about what issues you are running
into.
I also use glibc 2.3.2 with many different versions of GCC too. I still don't
see what regressions you are talking about anyways.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:19 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
--- Comment #3 from axel at freakout dot de 2007-06-08 20:25 ---
Subject: Re: 03.5: gcc 4.2.0 compiled vanilla
kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pinskia at gcc dot gnu dot org:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08
--- Comment #9 from mueller at gcc dot gnu dot org 2007-06-08 21:48 ---
Subject: Bug 31806
Author: mueller
Date: Fri Jun 8 21:48:34 2007
New Revision: 125580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125580
Log:
2007-06-08 Dirk Mueller [EMAIL PROTECTED]
PR
--- Comment #10 from mueller at gcc dot gnu dot org 2007-06-08 21:48
---
Subject: Bug 31809
Author: mueller
Date: Fri Jun 8 21:48:34 2007
New Revision: 125580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125580
Log:
2007-06-08 Dirk Mueller [EMAIL PROTECTED]
PR
No matter how high the optimzation level,
--never_inline prevents all inlining, even when called for in source code
--no_automatic_inline prevents automatic inlining, i.e. inlining by the
compiler when not specifically called for in the source code
--
Summary: --never_inline and
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 22:14 ---
--never_inline prevents all inlining, even when called for in source code
-fno-inline
(Or do you mean even with attribute always_inline?)
--no_automatic_inline prevents automatic inlining, i.e. inlining by the
--- Comment #7 from rob1weld at aol dot com 2007-06-08 23:34 ---
I tried this on i686-pc-linux-gnu using gcc-3.4 (from Debian), gcc-4.1 (from
Debian), gcc version 4.2.0 20070501 (prerelease) (from SVN), and gcc version
4.3.0 20070607 (experimental) (from SVN):
I modified as follows:
I will attach the example in a subsequent comment. If I execute:
gcc -O1 -c xf86ScanPci.c
it sucks up 805M of virtual memory. No optimization, no problem.
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.0/configure --prefix=/opt/gcc-4.2.0
--enable-threads
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 23:38 ---
*** This bug has been marked as a duplicate of 30052 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from pinskia at gcc dot gnu dot org 2007-06-08 23:38
---
*** Bug 32266 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsberg04+computing dot bugs dot gcc at ftml dot net
2007-06-08 23:38 ---
Created an attachment (id=13670)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13670action=view)
Preprocessed, bzip2 compressed example.
From Xorg 7.2.0, if anyone cares...
--
--- Comment #2 from thanate at asu dot edu 2007-06-08 23:40 ---
umm... I don't know how to check for that.
But I ran configure with --enable-clocale=gnu.
I posted my build log at
http://mathpost.asu.edu/~thanate/build.log
I'll keep the build dir for a while in case
you need some more
1 - 100 of 111 matches
Mail list logo
