Something is marking random_seed as noreturn.
As far as I understand, symbols are marked as noreturn by use of
TREE_THIS_VOLATILE, which is done on a few selected trees and is also
done whenever a symbol has the noreturn attribute. This noreturn
attribute can be set to 1 by make_noreturn,
My first patch didn't even compile :(
Here's a new one.
Something is marking random_seed as noreturn.
As far as I understand, symbols are marked as noreturn by use of
TREE_THIS_VOLATILE, which is done on a few selected trees and is
also done whenever a symbol has the noreturn attribute.
Joern RENNECKE wrote:
In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote:
As fwprop is no longer on the table for 4.2, and as the vectorizer
improvements seem to have stalled due to a combination of lack of review
and Dorit's leave, I think it's time to declare 4.2 feature-complete.
This status report has been a long time coming, for which I apologize.
As fwprop is no longer on the table for 4.2, and as the vectorizer
improvements seem to have stalled due to a combination of lack of review
and Dorit's leave,
That is unfortunate. Dorit did make a sincere effort to
Wolfgang Mües [EMAIL PROTECTED] writes:
On Sunday 04 June 2006 23:36, Rask Ingemann Lambertsen wrote:
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
(define_insn *arm_movqi_insn
[(set (match_operand:QI 0 nonimmediate_operand =r,r,r,m)
(match_operand:QI 1
--disable-nls --disable-checking --disable-debug --e
nable-threads=win32 --disable-win32-registry --enable-languages=c --disable-werr
or
Thread model: win32
gcc version 4.2.0 20060606 (experimental)
c:/temp/mgw/mymingw/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/cc1.exe -quiet -v
- -iprefix c:\temp\mgw
On 6/6/06, Ayal Zaks [EMAIL PROTECTED] wrote:
This status report has been a long time coming, for which I apologize.
As fwprop is no longer on the table for 4.2, and as the vectorizer
improvements seem to have stalled due to a combination of lack of review
and Dorit's leave,
That is
Fengwei Yin wrote:
Hi Daniel,
I have already reported this bug. The bug number is #27363.
I also tried the gcc snapshot 4.1.1-20060421. The bug is not
fixed in this version too.
On 5/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Sun, Apr 30, 2006 at 11:03:05AM +0800, Fengwei Yin wrote:
On Tue, 2006-06-06 at 15:05, Dirk Behme wrote:
Fengwei Yin wrote:
Hi Daniel,
I have already reported this bug. The bug number is #27363.
I also tried the gcc snapshot 4.1.1-20060421. The bug is not
fixed in this version too.
On 5/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On
Hi,
I'm updating a port from 3.4.6 to 4.1.1. In 3.4.6, I hadn't implemented
movmemsi patterns, but the compiler could still inline memcpy's (and also
strcpys where source string is a const) by itself. After updating to 4.1.1,
calls to memcpy are always generated.
I've had a bash at implementing
Hi,
i just built GCC 4.1.1 on AIX 5.1 using the following commands:
../gcc-4.1.1/configure --with-libiconv-prefix=/usr --disable-nls
--disable-multilib
make bootstrap-lean
make install
$ config.guess
powerpc-ibm-aix5.1.0.0
$ gcc -v
Using built-in specs.
Target:
You make a good point about the linker aspect but I was first most
concerned about the code generation differences, if any.
However, you are absolutely correct! A test is in order. I whipped up
a quick test program and was able to successfully compile, link and run
it, so it does indeed work!
oops! forgot to cc the list. thanks Per.
- Forwarded Message
From: Per Bothner [EMAIL PROTECTED]
To: Davanum Srinivas [EMAIL PROTECTED]
Sent: Tuesday, June 6, 2006 11:49:23 AM
Subject: Re: GCC SC request about ecj
Davanum Srinivas wrote:
Please see
In http://gcc.gnu.org/ml/gcc/2006-06/msg00185.html, your wrote:
So, two questions: any idea why 4.1.1 is no longer able to automatically
inline memcpys and why is the source operand for movmemsi not know to be as
widely aligned as it actually is?
See PR middle-end/27226
On Tue, Jun 06, 2006 at 08:16:54AM +0200, FX Coudert wrote:
Something is marking random_seed as noreturn.
As far as I understand, symbols are marked as noreturn by use of
TREE_THIS_VOLATILE, which is done on a few selected trees and is
also done whenever a symbol has the noreturn
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang DW_AT_APPLE.../DW_AT_GNU...
I read this. I'm not anywhere near an expert in dwarf or anything
related to this proposal, so please bear with me if I say something
dumb :-).
On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
Wolfgang Mües [EMAIL PROTECTED] writes:
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
__register_frame_info_table_bases':
../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
satisfy its constraints:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang DW_AT_APPLE.../DW_AT_GNU...
I read this. I'm not anywhere near an expert in dwarf or anything
related to this proposal, so please bear
Tom Tromey wrote:
* Why put the optimization diary into the object file?
Why not just have -Wdiary and print it along with all the warnings?
(I'm sure there's an answer to this, it would just be nice if it
were in the document...)
These are not warnings and they should not cause build
These are not warnings and they should not cause build failures
when -Werror is used, hence warnings are not suitable medium to
communicate this info.
There is a third type of diagnostic in GCC which gets not much
use at all. It is called note. It might be interesting to use that instead
of
Andrew Pinski wrote:
These are not warnings and they should not cause build failures
when -Werror is used, hence warnings are not suitable medium to
communicate this info.
There is a third type of diagnostic in GCC which gets not much
use at all. It is called note. It might be
Andrew Pinski wrote:
These are not warnings and they should not cause build failures
when -Werror is used, hence warnings are not suitable medium to
communicate this info.
There is a third type of diagnostic in GCC which gets not much
use at all. It is called note. It might
On Tue, Jun 06, 2006 at 07:42:20AM +0200, Wolfgang Mües wrote:
Rask,
On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote:
I think the comment in arm.h is wrong. The manual seems to agree with
the code.
Just to make it easy for beginners...
In mainline GCC, it is defined like
I've studied a fair bit of analytic philosophy and feel that it is
the rigorous arguments and detailed justification that separates
worthwhile philosophy from mere speculation or faith based spiritual
musings. Is there any reason for someone like me to take Hegel
seriously? You've
Ignore that last email. It was sent to the wrong address.
Peter
Peter Gerdes -- [EMAIL PROTECTED]
Find what I have to say interesting? Check out my blog or my
analytic philosophy blog.
On Jun 6, 2006, at 12:36 PM, Peter Michael Gerdes wrote:
I've studied a fair bit of analytic
On 6/6/06, Peter Michael Gerdes [EMAIL PROTECTED] wrote:
Ignore that last email. It was sent to the wrong address.
Thesis, antithesis, synthesis.
--
David L Nicol
fans of liza minelli should always be
disconnected immediately -- Matthew Henry
Andrew Pinski wrote:
Andrew Pinski wrote:
These are not warnings and they should not cause build failures
when -Werror is used, hence warnings are not suitable medium to
communicate this info.
There is a third type of diagnostic in GCC which gets not much
use at all. It is
On Tue, Jun 06, 2006 at 12:36:42PM -0700, Peter Michael Gerdes wrote:
Does Hegel actually have good arguments for his views or is he just
musing and throwing out ideas? If not why should we take him seriously?
I don't think any of his patches have been accepted by GCC, so I'd say
his
On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote:
Devang Patel [EMAIL PROTECTED] writes:
| [ Interestingly, there is a long standing request, here at Apple, to list
| command line options in object file (even when optimization is not used).
| One of our intern tried to
Is this what you want ?
yes :)
Thanks,
-
Devang
On Mon, Jun 05, 2006 at 09:53:00PM -0700, Andrew Pinski wrote:
Also what about moving the News up to a noticeable spot since right now
it is down in a corner so it looks out of place. In fact on my screen
which is set to 1024x768, I have to scroll to get to the news.
Yes, the top news needs
On Tue, 6 Jun 2006, Daniel Jacobowitz wrote:
| On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote:
| Devang Patel [EMAIL PROTECTED] writes:
|
| | [ Interestingly, there is a long standing request, here at Apple, to list
| | command line options in object file (even when
Devang == Devang Patel [EMAIL PROTECTED] writes:
Tom * Why put the optimization diary into the object file?
[...]
Devang 2) This info is consumed by other tools (e.g. IDE, performance
Devang analyzer). It makes sense for a tool like Shark to use dwarf
Devang reader to get this info then parse
Devang == Devang Patel [EMAIL PROTECTED] writes:
* DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms
of text highlighting. Why have a separate code here for dead
code instead of just marking a text region and having a new _msg
value meaning dead code?
Devang In the case
Dan == Daniel Berlin [EMAIL PROTECTED] writes:
Dan In addition to Tom's concerns, it seems to me to be a *really bad idea*
Dan to try to come up with integer values for every single message, instead
Dan of just placing a string there.
One reason to prefer the numerical approach is that it makes
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang DW_AT_APPLE.../DW_AT_GNU...
I read this. I'm not anywhere near an expert in dwarf or anything
Geoffrey Keating wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang DW_AT_APPLE.../DW_AT_GNU...
I read this. I'm not anywhere near an expert in dwarf
Trying to catalogue and assign a permanent place and number to every
single optimization message a compiler can generate is a much much much
worse idea, IMHO.
In the same way numbering warning messages is a bad idea (yes ICC and a couple
other compilers do but we should not).
-- Pinski
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang DW_AT_APPLE.../DW_AT_GNU...
I read
Geoffrey Keating wrote:
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang
On 06/06/2006, at 5:11 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal
Right above, you said We control the debug output machinery
generating this, and can simply tell it to only deal in one
language. Here, you seem to be implying that the messages should be
localised in the language the compiler is going to output messages
in. I suppose you could
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said We control the debug output machinery
generating this, and can simply tell it to only deal in one
language. Here, you seem to be implying that the messages should be
localised in the language the compiler is going to output
--Apple-Mail-9--465959030
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said We control the debug output machinery
generating this, and can
On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said We control the debug output machinery
generating this, and can simply tell it to only deal in one
language. Here, you seem to be implying that the messages
should be
I don't see how making it a string makes this different. Either your
new string will be a standard string or it won't. Either your new
number will be a standard number or it won't. If you want it to be
standard, you have to go through the committee.
I don't understand why it has to
I believe I may have discovered the component that was causing the
c++ regressions I was seeing on Darwin when fink was sourced. I have
found that after I deinstalled bison v2.1 installed by fink, I was
able to build gcc trunk on MacOS X 10.4 with fink sourced and still
pass the c++ testsuite
On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote:
I don't see how making it a string makes this different. Either your
new string will be a standard string or it won't. Either your new
number will be a standard number or it won't. If you want it to be
standard, you
Hi, all,
After I refer to the Intel paper titled Threading
Methodology : Principles and Practices versin 2.0
published in 2003, I note the following message in the
article mentioning:(from page 22, web site :
http://cache-www.intel.com/cd/00/00/21/93/219349_threadingmethodology.pdf)
Rask,
On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
+ swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0
You should get a price for cleverness here!
Thanks! Indeed it looks good until you think of volatile variables.
Because volatile variables can change their values from another
Andrew Pinski wrote:
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
We can allocate space in numbering for vendor extensions.
What happens when you compile two sources with two different compilers
and they
use the same number for vendor extension?
What happens when another compiler
On Jun 6, 2006, at 10:34 PM, Devang Patel wrote:
Andrew Pinski wrote:
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
We can allocate space in numbering for vendor extensions.
What happens when you compile two sources with two different
compilers and they
use the same number for vendor
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-06
06:13 ---
Subject: RE: ICE on complex assignment
FX,
Paul, I'm adding you to the CC list since this looks fully
module-related.
Oh Gee, thanks - that's all I need!..
I'll take a look at it this
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-06 06:15 ---
(In reply to comment #7)
Paul, I'm adding you to the CC list since this looks fully
module-related.
Oh Gee, thanks - that's all I need!..
Look at my C example, it is not related to Fortran at all. :).
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-06
06:18 ---
Subject: RE: [4.1/4.2 Regression] ICE on complex assignment in nested function
Andrew,
Thanks, I just went at the mail in the wrong order. I discovered that it is
not fortran by peaking at the PR.
--- Comment #1 from csm at gnu dot org 2006-06-06 06:42 ---
This is apparently caused by the default implementation of VMSecureRandom,
which uses some threads concurrently modifying counters, and uses those
counters to construct random bytes.
It's odd that on GCJ this runs so slow;
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-06-06
06:47 ---
Noting the non-fortran tilt on this, it is interesting that
implicit COMPLEX (a-z)
CALL foo
CONTAINS
SUBROUTINE foo
t = s + s
END SUBROUTINE foo
END
is OK and produces declarations for s
--- Comment #2 from happyarch at gmail dot com 2006-06-06 07:13 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561
--- Comment #6 From Serge Belyshev 2006-03-08 12:46 ---
This bug prevents emacs from working, it says M-x is undefined.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-06 07:19 ---
(In reply to comment #2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561
That bug was fixed 3 months ago so that is not the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
In order to build correctly in libjava and libjava/classpath, i had to:
1) in libjava/classpath/lib/Makefile.gcj, replace $(SHELL) by /bin/sh
2) in libjava/classpath/lib/gen-classlist.sh.in, replace the four occurrences
of while read pkg file with an appropriate awk sentence (eg for the first
one:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-06 08:08 ---
Why are you trying to build with /bin/ksh? That is just wrong.
How is ${SHELL} is being set to /bin/ksh anyways, SHELL is set by MAKE to
/bin/sh by default unless someone else overrides it.
Did you set
--- Comment #2 from Denis dot Excoffier at airbus dot com 2006-06-06 08:33
---
Oops, i've found an unnoticed CONFIG_SHELL=/bin/ksh around the configure step
in my build instructions. Sorry for that. Bug is not confirmed any longer.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-06 08:37 ---
Ok, closing as invalid, you might also want to report to Apple that ksh does
not work correctly for POSIX cases.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-06-06 08:54
---
Based on David's descripion, a reduced testcase appears to be:
static short f[100];
int
bar (void)
{
return f[0];
}
void
foo (void)
{
int i;
for (i = 0; i 100; i++)
f[i]++;
}
Looking at the assembly
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-06-06 09:02 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00284.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pcarlini at suse dot de 2006-06-06 09:36 ---
(In reply to comment #10)
In C90 strtod does not say anything specifically about inf, etc. However,
it
does say:
In other than the C locale, additional implementation-defined subject
sequence forms may be
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-06-06
10:10 ---
This is now open since more than a year.
Is there any hope of getting it fixed for gfortran 4.2?
Correct uninitialized warnings are a very desirable feature IMO
and have always been a stron point in gcc.
--- Comment #13 from martin at mpa-garching dot mpg dot de 2006-06-06
10:11 ---
(In reply to comment #12)
Correct uninitialized warnings are a very desirable feature IMO
Sorry, I meant unused of course :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-06-06 10:14
---
Is it possible to fix this before gcc 4.2?
Whenever I see these garbled warnings I have a very bad feeling that
something completely unintended is happening inside the compiler,
and I guess that many users
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-06
10:26 ---
Created an attachment (id=11607)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11607action=view)
Patch and testcase for the PR
The problem lay in simplification of the binary expression because the
--- Comment #3 from paulg at chiark dot greenend dot org dot uk 2006-06-06
11:16 ---
Tried the following
1) Bootstrap GCC 4.1.1 using a GCC 3.4.4 host compiler without STAGE1_CFLAGS or
BOOT_CFLAGS set.
2) Bootstrap another clean copy of GCC 4.1.1 using the GCC 4.1.1 from step (1)
as
--- Comment #3 from gcc at pdoerfler dot com 2006-06-06 11:22 ---
I get the following with -O3 -march=pentium4 -fomit-frame-pointer on a pentium4
gentoo machine:
gcc-3.4.6 gcc-4.0.2 gcc-4.1.1
2.69s 4.14s 3.26s
These are all with gentoo's patches.
Also, current
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-06-06
11:46 ---
(In reply to comment #3)
This bug report is approaching its second anniversary.
Does anybody still watch it or take care?
Yes, Harald. I have been looking these last days at a number of array
I've stumbled on a gfortran Fortran runtime error when using allocatable
arrays inside OpenMP PARALLEL DO LOOPS
Consider the folowing reduced testcase.
cat allocate_in_loop.f90
program allocate_in_loop
use omp_lib, only: omp_get_num_threads,omp_get_thread_num
implicit none
integer ::
--- Comment #1 from benjamin dot reveille at gmail dot com 2006-06-06
12:01 ---
For the fortran mailing list thread on this bug see:
http://gcc.gnu.org/ml/fortran/2006-06/msg00096.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
--- Comment #14 from bonzini at gnu dot org 2006-06-06 12:10 ---
Patch pr27390-more.patch was bootstrapped/regtested and the approach was
confirmed to be ok by Roger.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-06
12:14 ---
Subject: Re: FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors)
I wonder what outmode is in emit_library_call_value_1:
tfom = lang_hooks.types.type_for_mode (outmode, 0);
I might
--- Comment #13 from guerby at gcc dot gnu dot org 2006-06-06 12:37 ---
Subject: Bug 27769
Author: guerby
Date: Tue Jun 6 12:37:01 2006
New Revision: 114429
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114429
Log:
2006-06-06 Laurent GUERBY [EMAIL PROTECTED]
PR
--- Comment #14 from guerby at gcc dot gnu dot org 2006-06-06 12:38 ---
Subject: Bug 27769
Author: guerby
Date: Tue Jun 6 12:37:36 2006
New Revision: 114430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114430
Log:
2006-06-06 Laurent GUERBY [EMAIL PROTECTED]
PR
--- Comment #15 from laurent at guerby dot net 2006-06-06 12:43 ---
Should be fixed now.
--
laurent at guerby dot net changed:
What|Removed |Added
Status|NEW
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-06-06
12:54 ---
Subject: Re: [4.2 Regression] libgcc_s.so.1 causes SEGV on Solaris 10/x86
steven at gcc dot gnu dot org writes:
Rainer, there is no test case and no description for how to reproduce this.
I couldn't
--- Comment #4 from happyarch at gmail dot com 2006-06-06 13:02 ---
Weird, it doesn't fixed.
my gcc version is
4.2.0 20060603 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
make boostrap
(...)
stage1/xgcc -Bstage1/
-B/local/devel/toolchain41/sparc-sun-solaris2.9/sparc-sun-solaris2.9/bin/ -g
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-06
14:06 ---
Created an attachment (id=11608)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11608action=view)
Patch for this and PR27583
This needs cleaning up and a testcase writing but it is nearly there.
--- Comment #6 from fitzsim at redhat dot com 2006-06-06 14:07 ---
On the JDK lib files are stored in $JAVA_HOME/jre/lib. I've recently moved
some files, like libjawt.so, that would conflict for multiple, parallel libgcj
installations to the same prefix, to
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-06 14:12 ---
make boostrap
This is invalid, you are trying to bootstrap a cross compiler which will never
work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-06-06 14:21
---
Btw, the fix for PR27804 fixed the problem on mainline before Mark's patch
went in. (This might be interesting for a backport to the 4.0 branch.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-06 14:26 ---
What about instead of absolute numbers doing label subtraction for section
anchors and then we can defer the decision for the layout of the section until
after all functions are done compiling?
--
pinskia at gcc
--- Comment #2 from tomdkat at comcast dot net 2006-06-06 14:34 ---
I do not get this problem with gcc 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26614
--- Comment #13 from amacleod at redhat dot com 2006-06-06 14:43 ---
Created an attachment (id=11609)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609action=view)
assert to add if Jakub's idea is implemented.
So do you want to fix it Jakub's way instead of hacking up the tree
--- Comment #9 from richard at codesourcery dot com 2006-06-06 15:02
---
Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize
-maltivec
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
What about instead of absolute numbers doing label subtraction for
--- Comment #10 from dje at gcc dot gnu dot org 2006-06-06 15:10 ---
The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass.
I do not understand why the alignment of the vectorized variables is not known
at section anchor creation time.
--
--- Comment #11 from richard at codesourcery dot com 2006-06-06 15:16
---
Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize
-maltivec
dje at gcc dot gnu dot org [EMAIL PROTECTED] writes:
The auto-vectorizer is a Tree-SSA pass. The section anchors are an
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-06-06 15:18
---
(In reply to comment #10)
The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass.
I do not understand why the alignment of the vectorized variables is not known
at section anchor creation
--- Comment #13 from dje at gcc dot gnu dot org 2006-06-06 15:22 ---
We're performing the auto-vectorization in unit-at-a-time-mode, so maybe we
need to recompile the other functions. It seems that we're going to encounter
more problems along these lines with LTO.
--
--- Comment #8 from ian at airs dot com 2006-06-06 15:42 ---
As I mentioned in the original submission, I'm pretty sure it is caused by
RTH's patch for PR 23190.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
--- Comment #14 from richard at codesourcery dot com 2006-06-06 15:53
---
Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize
-maltivec
dje at gcc dot gnu dot org [EMAIL PROTECTED] writes:
We're performing the auto-vectorization in unit-at-a-time-mode, so
--- Comment #7 from ayers at gcc dot gnu dot org 2006-06-06 16:05 ---
Subject: Bug 13946
Author: ayers
Date: Tue Jun 6 16:05:47 2006
New Revision: 114435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114435
Log:
2006-06-06 David Ayers [EMAIL PROTECTED]
PR
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-06-06 16:35
---
For other reasons it would be nice to be able to place sync points in the
pass schedule where we re-start with going over all functions for the remaining
passes. Per function SSA form is requires for this, though,
1 - 100 of 172 matches
Mail list logo
