On 5/2/07, Sjodin, Jan [EMAIL PROTECTED] wrote:
Thanks for all the responses. It seems like LTO will have to wait for
the tuples or there will be a lot of throw-away code.
If you really only can think of LTO as the reader/writer, then perhaps
yes. But if you read back this thread, you would
Hi,
for reasons I don't know, I am not able to create attachments in gcc's
bugzilla for ca the last 24hrs. When doing so, I am greeted with the
message below.
--- snip ---
Internal Error
GCC Bugzilla has suffered an internal error. Please save this page and
send it to [EMAIL PROTECTED] with
On 03 May 2007 08:52, Ralf Corsepius wrote:
Hi,
for reasons I don't know, I am not able to create attachments in gcc's
bugzilla for ca the last 24hrs. When doing so, I am greeted with the
message below.
--- snip ---
Internal Error
GCC Bugzilla has suffered an internal error. Please
On Thu, 2007-05-03 at 10:36 +0100, Dave Korn wrote:
On 03 May 2007 08:52, Ralf Corsepius wrote:
Hi,
for reasons I don't know, I am not able to create attachments in gcc's
bugzilla for ca the last 24hrs. When doing so, I am greeted with the
message below.
--- snip ---
Internal
On 5/3/07, Ralf Corsepius [EMAIL PROTECTED] wrote:
Hi,
for reasons I don't know, I am not able to create attachments in gcc's
bugzilla for ca the last 24hrs. When doing so, I am greeted with the
message below.
--- snip ---
Internal Error
GCC Bugzilla has suffered an internal error. Please
Andreas Krebbel [EMAIL PROTECTED] writes:
What I'm curious about is why this didn't occur earlier?! The symbol
is available since 2003 and I can hardly imagine that no platform was
ever in need of it till now.
To answer that, I'm afraid my patch is to blame:
2007-04-24 Richard Sandiford
On Thu, 2007-05-03 at 07:01 -0400, Daniel Berlin wrote:
On 5/3/07, Ralf Corsepius [EMAIL PROTECTED] wrote:
Hi,
for reasons I don't know, I am not able to create attachments in gcc's
bugzilla for ca the last 24hrs. When doing so, I am greeted with the
message below.
--- snip ---
Hi,
I'm debugging a problem with the GCC 4.1 old loop optimizer.
Consider the following example:
After gcse1 a loop body contains the following two insns. Note that gcse
has already replaced r974 with r1218 in insn 1743 and has attached a REG_EQUAL
note. Insn 2308 stays as a dead store - maybe
To answer that, I'm afraid my patch is to blame:
2007-04-24 Richard Sandiford [EMAIL PROTECTED]
* optabs.c (set_conv_libfunc): Prefer libgcc2's __ffsMM2 functions
over an external ffs function.
We used to use ffs to implement __builtin_ffs if sizeof (int),
even if libgcc
Bradley Lucier wrote:
I just (re-)discovered these tables giving maximum known errors in
some libm functions when extended precision is enabled:
http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html
and when the precision of the mantissa is set to 53 bits (double
precision):
Ralf Corsepius wrote:
1. I submitted a PR, and was asked to login several times inbetween.
I have found that clearing the browser's cookie cache for the site will
often correct this problem.
2. Later I returned to PR XXX, pressed Create attachment and ...
first was asked to login, then
David Daney wrote:
Ralf Corsepius wrote:
1. I submitted a PR, and was asked to login several times inbetween.
I have found that clearing the browser's cookie cache for the site will
often correct this problem.
I should have read the rest of the thread :(. It looks like this was
On 5/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
dberlin has been mailed, but no reaction so far.
I was off fixing my Nintendo Wii, so i wasn't checking email :)
Wait, it needed to fixed already, you should have got a PS3.
-- Andrew
On Thu, 2007-05-03 at 08:54 -0700, David Daney wrote:
Ralf Corsepius wrote:
1. I submitted a PR, and was asked to login several times inbetween.
I have found that clearing the browser's cookie cache for the site will
often correct this problem.
I've never had this problem before, ever
On 03 May 2007 17:04, Ralf Corsepius wrote:
On Thu, 2007-05-03 at 08:54 -0700, David Daney wrote:
Ralf Corsepius wrote:
1. I submitted a PR, and was asked to login several times inbetween.
I have found that clearing the browser's cookie cache for the site will
often correct this
I agree. Also, the LTO requirements and high-level design document
states that the external format should be compiler-independent and it
should be possible for other tools to read and write that format. Is
this still a goal? It would require a separate design with a distinct
API to read and write
On 5/2/07, Sjodin, Jan [EMAIL PROTECTED] wrote:
Thanks for all the responses. It seems like LTO will have to wait for
the tuples or there will be a lot of throw-away code.
If you really only can think of LTO as the reader/writer, then perhaps
yes. But if you read back this thread, you
On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:
Could you please post a patch with suggested wording about this
option (I was trying to write something similar to the warning that
icc has in its documentation about precision settings).
How about this? It perhaps reflects my own biases,
On Tue, 2007-05-01 at 09:27 +1000, Ben Elliston wrote:
On Mon, 2007-04-23 at 22:16 +0200, Danny Backx wrote:
Gcov normally puts the files where it writes profiling information in
the source directory. In a cross-development environment, that directory
isn't always available.
So I
Bradley Lucier wrote:
On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:
Could you please post a patch with suggested wording about this
option (I was trying to write something similar to the warning that
icc has in its documentation about precision settings).
How about this? It perhaps
On May 3, 2007, at 2:45 PM, Uros Bizjak wrote:
Bradley Lucier wrote:
On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:
Could you please post a patch with suggested wording about this
option (I was trying to write something similar to the warning
that icc has in its documentation about
On 5/3/07, Dave Korn [EMAIL PROTECTED] wrote:
On 03 May 2007 16:59, Andrew Pinski wrote:
On 5/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
dberlin has been mailed, but no reaction so far.
I was off fixing my Nintendo Wii, so i wasn't checking email :)
Wait, it needed to fixed already, you
Bradley Lucier wrote:
What about significant loss of accuracy as these options probably
won't cause a nuclear reactor meltdown ;)
Well, I did some googling, and the technical term I was thinking of
was catastrophic cancellation. So how about
Note that some mathematical routines in such
After gcse1 a loop body contains the following two insns. Note that gcse
has already replaced r974 with r1218 in insn 1743 and has attached a
REG_EQUAL note. Insn 2308 stays as a dead store - maybe thats what confuses
the loop optimizer.
(insn 2308 1740 1743 111 (set (reg/f:DI 974)
Dear all,
I must calculate the address of an element's array.
If the size of an element is one integer it's good.
I do like that:
new_rhs=fold_build2(PLUS_EXPR,TREE_TYPE(TREE_OPERAND(rhs,1)),
build1(ADDR_EXPR, build_pointer_type (TREE_TYPE
(array)),array),
On May 3, 2007, at 3:29 PM, Uros Bizjak wrote:
Bradley Lucier wrote:
What about significant loss of accuracy as these options
probably won't cause a nuclear reactor meltdown ;)
Well, I did some googling, and the technical term I was thinking
of was catastrophic cancellation. So how
Mark Mitchell wrote:
GCC 4.2.0 RC3 is now available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501
This build now contains the fixes for the Ada build problem present in RC2.
At this point, I have no plans for an RC4. However, I am reviewing the
various open issues, and
On 03 May 2007 03:41, Aaron Gray wrote:
Various people run the testsuite on cygwin every now and again; check
the
gcc-testresults@ mailinglist archive.
Yes, Tim has allready run it :-
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01540.html
I haven't done one for weeks
On Thu, 2007-05-03 at 19:55 +0200, Danny Backx wrote:
Ok, a command line option is what I have. I'll try to clean up my
patch shortly, and see if it still applies cleanly in a recent gcc
tree. Our current version is based on gcc-4.1.0. Or is a patch against
that ok ?
This feature would not
Hello,
ii)
In loop_version there are two calls to loop_split_edge_with
1. loop_split_edge_with (loop_preheader_edge (loop), NULL);
2. loop_split_edge_with (loop_preheader_edge (nloop), NULL);
nloop is the versioned loop, loop is the original.
loop_split_edge_with has the following:
Fernando Lozano wrote:
Hi Pizarro,
Today is 01 of May, the worker's day.
I've not the code in May, Fernando.
How long have i to wait?
Just google around to find when JavaOne will be held. Just as I said on
my original post.
JavaOne starts May 8.
Besides, the Worker's day is a holiday in
On Thu, May 03, 2007 at 06:29:29PM -0700, Michael Eager wrote:
The engineer's definition of available in May is May 1.
The marketer's definition of available in May is May 30.
Nope. The engineer's definition of available in May depends on whether
the engineer needs the item (then it's May 1)
On 5/2/07, Christian Joensson [EMAIL PROTECTED] wrote:
2007/5/2, Andrew Haley [EMAIL PROTECTED]:
Christian Joensson writes:
On cygwin, with D. Korn's proposed patch to cygwin's (i.e., newlib's)
stdio.h, I get a bootstrap failure do to comparison difference(s):
Did you do a total rebuild
--- Comment #6 from brooks at gcc dot gnu dot org 2007-05-03 07:15 ---
Subject: Bug 31776
Author: brooks
Date: Thu May 3 06:14:52 2007
New Revision: 124373
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124373
Log:
PR bootstrap/31776
* system.h: Remove inclusion of double-int.h
--- Comment #7 from brooks at gcc dot gnu dot org 2007-05-03 07:22 ---
The above commit should fix this problem.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
When building RTEMS with gcc-4.2.0-20070430, gcc races on one file of the RTEMS
sources. It consumes up all available CPU time, gradually (very slowly) seems
consume all memory and doesn't seem to finish:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
6176 joel
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-03 09:16 ---
Compiles cleanly on trunk
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from charlet at gcc dot gnu dot org 2007-05-03 09:25 ---
The error message looks valid to me: it's not a matter of visibility: the
protected procedure is visible, but does not match, since it's not a
procedure, it's a protected procedure.
Arno
--
charlet at gcc dot
--- Comment #1 from ralf_corsepius at rtems dot org 2007-05-03 09:36
---
Using -O1 instead of -O2 causes the hogging to vanish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
--- Comment #2 from rob1weld at aol dot com 2007-05-03 09:49 ---
Reviewing my old bug reports I noticed a reply may be needed here...
I _do_ build in a directory that is different from the source.
It is my guess that part of the problem is that Cygwin is attempting to make
unix-LIKE
I have a toolcahin working quite well: gcc-4.1.2 binutils-2.17, generic
arm softfloat supporting EABI. This works with kernel and userspace
well. Only on u-boot it fails at the final stage:
UNDEF_SYM=`arm-linux-objdump -x lib_generic/libgeneric.a
board/scb9328/libscb9328.a
--- Comment #3 from rob1weld at aol dot com 2007-05-03 09:55 ---
Another test results report (4.2.0 20070501 on i686-pc-linux-gnu) is here:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00135.html
Almost every option enabled, almost all tests passed (except dfp, in C).
--
--- Comment #3 from rob1weld at aol dot com 2007-05-03 10:00 ---
Another test results report for i686-pc-linux-gnu (4.2.0 20070501):
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00135.html
Nearly all options are enabled. Nearly all tests pass. A few have ZERO errors!
(hurray). DFP
--- Comment #2 from rob1weld at aol dot com 2007-05-03 10:09 ---
Confirmed. My Linux system has gcc 4.2.0 installed and I do NOT get that many
warnings, only a couple.
I _do_ have the _newest_ possible version of all programs for Cygwin.
In any event, on _any_ platform, it is
--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:27
---
I can also reproduce the bug with 4.2.0-20070501.
It also is related to optimization levels. Newlib is being compiled with -O2,
which triggers this breakdown. Using -O1 or -Os to build init.c lets the
breakdown
--- Comment #3 from ralf_corsepius at rtems dot org 2007-05-03 10:43
---
Created an attachment (id=13501)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13501action=view)
*.i of the breakdown above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:45
---
Created an attachment (id=13502)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13502action=view)
*.i of the breakdown above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:47
---
Created an attachment (id=13503)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13503action=view)
*.i of the breakdown above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
--- Comment #1 from aldot at gcc dot gnu dot org 2007-05-03 11:16 ---
Maybe related to 30438, 18624
I started to do
Index: gcc/tree.h
===
--- gcc/tree.h (revision 124373)
+++ gcc/tree.h (working copy)
@@ -364,7 +364,7 @@
--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-03 12:08 ---
Thanks for the feedback.
Closing this PR then.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-05-03 12:44
---
I also did compile for my other platform (i686-pc-linux-gnu) and did not
notice
if these warnings occurred when make was running.
They are only present on platforms that do not use DWARF-2 EH.
--
--- Comment #20 from aaronavay62 at aaronwl dot com 2007-05-03 13:00
---
It looks like this will not be backported to 4.2 as its not strictly a
regression. See http://gcc.gnu.org/ml/gcc/2007-05/msg00067.html. If you use
this sort of pimpl and anonymous namespaces or similar, and you
--- Comment #4 from eweddington at cso dot atmel dot com 2007-05-03 13:05
---
Subject: RE: error: unable to find a register to spill in
class 'BASE_POINTER_REGS'
--- Comment #2 from ralf_corsepius at rtems dot org
2007-05-03 10:27 ---
I can also reproduce the bug with
--- Comment #5 from ralf dot corsepius at rtems dot org 2007-05-03 13:12
---
Subject: RE: error: unable to find a register to spill
in class 'BASE_POINTER_REGS'
On Thu, 2007-05-03 at 06:05 -0600, Eric Weddington wrote:
--- Comment #2 from ralf_corsepius at rtems dot
--- Comment #7 from dorit at gcc dot gnu dot org 2007-05-03 13:55 ---
Subject: Bug 31699
Author: dorit
Date: Thu May 3 12:54:45 2007
New Revision: 124375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124375
Log:
PR tree-optimization/31699
* tree-vect-analyze.c
--- Comment #6 from ralf_corsepius at rtems dot org 2007-05-03 14:07
---
This is the minimised *.c having been extracted from newlib's file exposing the
bug:
-- snip --
extern void (*array_start []) (void);
extern void (*array_end []) (void);
void
init_array (void)
{
int count;
--- Comment #7 from tbm at cyrius dot com 2007-05-03 14:12 ---
It's hard to say when this was introduced. The problem is that starting with
r123363, gcc won't accept this preprocessed code. I used preprocessed code
generated by 4.3 20070326 to test older revisions, but there the bug
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-03 14:16 ---
Mark as duplicate as the fix in PR 31699 fixes this bug.
*** This bug has been marked as a duplicate of 31699 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from burnus at gcc dot gnu dot org 2007-05-03 14:16 ---
*** Bug 31697 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
--- Comment #9 from burnus at gcc dot gnu dot org 2007-05-03 14:18 ---
As the fix has been checked in and it works (at least here ;-), mark as FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-05-03 14:27 ---
Subject: Bug 30565
Author: rakdver
Date: Thu May 3 13:27:26 2007
New Revision: 124378
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124378
Log:
PR tree-optimization/30565
* lambda-code.c
--- Comment #7 from ralf_corsepius at rtems dot org 2007-05-03 15:20
---
FYI: Vanilla gcc-4.1.2 without newlib also exposes this issue with the code
fragment from comment #6:
./avr-gcc -o tmp.o -c init.c -O2
init.c: In function 'init_array':
init.c:12: error: unable to find a register
For
void
foo (int x, int *y, int *z)
{
*z = ++x;
if (x != 0)
*y = 1;
}
gcc 4.3 generates
foo:
.LFB2:
addl$1, %edi
testl %edi, %edi
movl%edi, (%rdx)
je .L3
movl$1, (%rsi)
.L3:
rep ; ret
But testl %edi, %edi isn't needed
--- Comment #1 from uros at gcc dot gnu dot org 2007-05-03 15:32 ---
Subject: Bug 31768
Author: uros
Date: Thu May 3 14:32:25 2007
New Revision: 124379
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124379
Log:
PR target/31768
* config/i386/i386.c (print_operand)
--- Comment #2 from ubizjak at gmail dot com 2007-05-03 15:41 ---
(In reply to comment #0)
unsigned long c;
Fixed in mainline. But don't use long types on out insn, as you will generate
outll on x86_64.
--
ubizjak at gmail dot com changed:
What|Removed
test -d testsuite/ada/acats || mkdir -p testsuite/ada/acats
testdir=`cd ../../gcc-4.2.0-20070501/gcc/testsuite/ada/acats; ${PWDCMD-pwd}`;\
export testdir; cd testsuite/ada/acats; /bin/sh ${testdir}/run_acats
=== acats configuration ===
target gcc is /home/voax/build-4.2.0/gcc/xgcc
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-03 15:49
---
(In reply to comment #5)
I am not able to reproduce a segfault. However, this patch eliminates the
double error message. Could someone verify that they still get a segfault
without this patch and then try
--- Comment #3 from us15 at os dot inf dot tu-dresden dot de 2007-05-03
16:22 ---
Is there any chance of this problem being fixed in 4.1 and 4.2 as well? If so,
should I open new bugs for those?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31768
--- Comment #8 from eweddington at cso dot atmel dot com 2007-05-03 16:40
---
Confirmed. Code snippet fails for 4.1.2 when compiling for -O2 and -O3. Note
that compiling with -O[0,1,s] is successful.
Changing target to all avr.
--
eweddington at cso dot atmel dot com changed:
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-03 16:52 ---
*** Bug 31795 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-03 16:52 ---
*** This bug has been marked as a duplicate of 18624 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from eweddington at cso dot atmel dot com 2007-05-03 16:56
---
Confirmed on GCC 4.1.2.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #1 from eweddington at cso dot atmel dot com 2007-05-03 17:06
---
Confirmed. Also fails for 4.1.2.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-05-03 17:08 ---
(In reply to comment #0)
foo:
addl$1, %edi
testl %edi, %edi
movl%edi, (%rdx)
je .L3
movl$1, (%rsi)
.L3:
rep ; ret
This is just an unfortunate
--- Comment #2 from ubizjak at gmail dot com 2007-05-03 17:22 ---
Ah, for some reason insn 13 does not have the insn link pointing to insn 10.
Probably dataflow should/could fix this?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-05-03 17:38 ---
(In reply to comment #3)
Is there any chance of this problem being fixed in 4.1 and 4.2 as well? If so,
should I open new bugs for those?
The %z modifier is IMO not intended for general use, so I don't think the
--- Comment #5 from patchapp at dberlin dot org 2007-05-03 18:37 ---
Subject: Bug number PR31630
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00116.html
--
--- Comment #3 from patchapp at dberlin dot org 2007-05-03 18:37 ---
Subject: Bug number PR31399
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00121.html
--
Hello,
the targets avr, cris, h8300, m32c and v850 show the same error when build
in the dataflow-branch:
gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings
--- Comment #3 from ludovic at ludovic-brenta dot org 2007-05-03 19:15
---
I disagree. As highlighted at the beginning of this PR, per 8.2(2), the
instance becomes visibleonly _after_ its declaration, i.e. at the semicolon.
Before the semicolon, the two Foos are NOT ambiguous because
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-03 19:24 ---
This is all target issues, they should be including a pattern for blockage.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ludovic at ludovic-brenta dot org 2007-05-03 19:27
---
I disagree. Per RM 9.5.1(1), a protected subprogram IS a subprogram...
(emphasis mine). Furthermore, the last sentence of 12.6(9) says: The view is
a function or procedure, never an entry. Both of these
When I compile the following testcase with '-O3 -msse3' options it runs in
22.562sec, without 'union' clause it runs in 0.280sec. And should be the same
time.
-- begin testcase --
typedef float __v2df __attribute__ ((__vector_size__ (16)));
typedef __v2df __m128;
static __inline __m128
--- Comment #8 from sje at cup dot hp dot com 2007-05-03 19:36 ---
I went back to r124216 and added a print to see what the next instruction was,
since it wasn't a barrier. What I found was a NOTE_INSN_DELETED_LABEL,
followed by a barrier. I am guessing we want to ignore that (and any
character (len = 70), target :: textt
character (len = 70), pointer :: textp
character (len = 50), pointer :: textp2
a = 42
textp = textt
textp2 = textt(1:50)
end
--
Summary: ICE when for character pointer = target(range)
Product: gcc
Version: 4.3.0
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-03 19:43 ---
==11966== Invalid read of size 8
==11966==at 0x41BF0C: gfc_check_pointer_assign (expr.c:2555)
==11966==by 0x4519D0: resolve_code (resolve.c:5225)
==11966==by 0x452D3D: resolve_codes (resolve.c:7386)
--- Comment #3 from ludovic at ludovic-brenta dot org 2007-05-03 19:45
---
Since when are regressions priority P5? I understand Ada is never
release-critical (what a shame) but P2 would be appropriate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30618
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-05-03 19:47
---
Please specify how you invoked the compiler, and understand that you need
gnatdist for distributed programs. gnatdist is part of GLADE which is separate
from GNAT.
--
--- Comment #2 from dj at redhat dot com 2007-05-03 20:01 ---
Note that only 19 out of 33 target directories (trunk) even mention the word
blockage and there's no mention of blockage in the trunk documentation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31801
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-03 20:01
---
Please try again, it may be spurious.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-05-03 20:14 ---
The following testcase should be equivalent to the original one but not involve
IMA:
void f1()
{
static __gthrw_pthread_once __attribute__ ((__weakref__ (pthread_once)));
}
void f2()
{
static
--- Comment #33 from ian at airs dot com 2007-05-03 20:33 ---
Created an attachment (id=13504)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13504action=view)
Patch
Here is a much simpler patch which also fixes the problem. This simply inserts
a memory clobber before each
--- Comment #3 from patchapp at dberlin dot org 2007-05-03 20:50 ---
Subject: Bug number PR25071
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00186.html
--
$ perl -wle 'print int, * x 99, p;' try.c gcc try.c
gcc: Internal error: Segmentation fault (program cc1)
...
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-03 21:44 ---
This is because the union does not get the correct mode (it gets BLK or TImode)
so GCC stores the union to the stack all the time.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #34 from pcarlini at suse dot de 2007-05-03 21:45 ---
First blush, I'm not enthusiastic about this last proposal. Seems to me just a
concealed way to do what Richard suggested at the beginning of this thread. As
such, I'm still finding it, in spirit at least, against the
--- Comment #35 from pinskia at gcc dot gnu dot org 2007-05-03 21:48
---
(In reply to comment #34)
*intentionally* (emphasis mine) performs no other action.
There is no other action taken, it is just a barrior, not even really an action
in my mind.
--
--- Comment #36 from rguenth at gcc dot gnu dot org 2007-05-03 21:59
---
Well, the patch in comment #33 really does what I did with the patch to
libstdc++.
If we take the first patch (from comment #29) and change its effects on the
alias machinery so that for
q = ALIAS_CONVERT_EXPR
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-03 22:00 ---
(In reply to comment #2)
there's no mention of blockage in the trunk documentation.
HUH?
@cindex @code{blockage} instruction pattern
@item @samp{blockage}
This pattern defines a pseudo insn that prevents the
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-03 22:02 ---
you must be kidding.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 140 matches
Mail list logo
