yunfeng zhang wrote:
The idea I got is about removing .got section in ELF format totally.
Before we go, let's see the limitation on the idea
1) It must be deployed on aligned segment model, such as Linux, which cs.start
= ds.start.
2) Currently, I only know how to do on x86 ELF.
Here is
Paul Edwards wrote:
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them? Note that I have never had to do the machine changes
myself - in the past I simply waiting for Dave Pitts to do the
upgrade to the new version,
A change on November 23 is causing every C++ testcase to fail on AIX
because of _ZNSsD1Ev not being exported. c++filt reports the symbol
corresponds to
std::basic_stringchar, std::char_traitschar, std::allocatorchar
::~basic_string [in-charge]()
David
I can see one significant change: the GCC middle-end now no
longer supports base-16 floating point at all. The old i370
port was the only user of this feature, and some time after
the port was removed, the middle-end support was removed as
well in order to simplify floating-point handling code.
H.J. Lu wrote:
On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley a...@redhat.com wrote:
H.J. Lu wrote:
On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley a...@redhat.com wrote:
Steven Rostedt wrote:
Ingo, Thomas and Linus,
I know Thomas did a patch to force the -mtune=generic, but just in case
gcc
On Tue, 24 Nov 2009, Andrew Haley wrote:
H.J. Lu wrote:
On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley a...@redhat.com wrote:
H.J. Lu wrote:
On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley a...@redhat.com wrote:
Steven Rostedt wrote:
Ingo, Thomas and Linus,
I know Thomas did a patch
Hi Rafael,
I'm sorry I cannot try the patch until next weekend.
However, from a first look, it should work but I wonder: if the first
maybe_unlink_file fails the others are never reached, leaving some
temporary files in place. Is this ok?
Yes, I talked with Diego and he thinks that this is
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic. Is that right?
Seems to work. What other side effects has that ?
Faster code, significant increase in code size though.
Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic. Is that right?
Seems to work. What other side effects has that ?
Faster code, significant increase
On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote:
Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic. Is that right?
Seems to work. What
Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote:
Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic. Is that right?
Derrick Coetzee wrote:
1. We have a C/C++ source-to-source translation framework. We could
translate each function call f(a,b,c) to something like ({ _asm {
... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })
2. We could modify the code generation of gcc in a private fork.
I
Mark Mitchell wrote:
Derrick Coetzee wrote:
1. We have a C/C++ source-to-source translation framework. We could
translate each function call f(a,b,c) to something like ({ _asm {
... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })
2. We could modify the code generation of gcc in
On 11/24/2009 07:46 AM, Andrew Haley wrote:
Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
space for arguments of the callee with most arguments in the prologue, using
subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
and the stack pointer
Hi!
I totally agree with Basille. Actually pretty similar thing was
implemented by Liang Peng (ICT) as GCC GSoC'09 project -
http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Function_cloning_and_program_instrumentation
So, probably you should take a look at the code in the
Andrew Haley writes:
Alright. So, it is possible in theory for gcc to generate code that
only uses -maccumulate-outgoing-args when it needs to realign SP.
And, therefore, we could have a nice option for the kernel: one with
(mostly) good code density and never generates the bizarre code
sequence
On 11/23/2009 05:58 PM, yunfeng zhang wrote:
next:
pop %ebx // A.
...
movl new_offset(%ebx), %eax // B. load global variable foo to eax.
...
.global foo // C.
OK!, to ld, offsetof(C - A) is const...
Your premise is wrong right there. C-A is *not* a constant.
Ross Ridge wrote:
Andrew Haley writes:
Alright. So, it is possible in theory for gcc to generate code that
only uses -maccumulate-outgoing-args when it needs to realign SP.
And, therefore, we could have a nice option for the kernel: one with
(mostly) good code density and never generates the
H. Peter Anvin wrote:
On 11/24/2009 07:46 AM, Andrew Haley wrote:
Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
space for arguments of the callee with most arguments in the prologue, using
subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
and
On Tue, 2009-11-24 at 17:12 +, Andrew Haley wrote:
H. Peter Anvin wrote:
If we're changing gcc anyway, then let's add the option of intercepting
the function at the point where the machine state is well-defined by
ABI, which is before the function stack frame is set up.
Hmm. On the
Kaveh R. Ghazi gh...@caip.rutgers.edu writes:
Agreed. I guess my remaining questions are for AIX and mipsisa64-elf.
Can someone please confirm that mipsisa64-elf is a cross-compile-only target
and therefore not relevant for host-based MPC portability testing?
Yes, that's right.
I'm sure
On 11/24/2009 09:12 AM, Andrew Haley wrote:
If we're changing gcc anyway, then let's add the option of intercepting
the function at the point where the machine state is well-defined by
ABI, which is before the function stack frame is set up.
Hmm. On the x86 I suppose we could just inject a
Hi Paolo,
Just saw your email.
Do you mind to send the forms to Yuanjie (huangyuan...@ict.ac.cn)
and Liang (pengli...@ict.ac.cn) so that they could add their GSoC'09
developments
to the mainline with the help of Joern, please?!
I send an offline email to David and Sebastian but if you already
Hello All,
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins mention a plugin
directory which can be queried with
gcc-trunk -print-file-name=plugin
Notice that we are calling that plugin, not plugin-header! In my opinion, this
is significant.
on my system, after installation of
Snapshot gcc-4.4-20091124 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091124/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi Derrick,
As Yuri pointed out we needed some similar instrumentation
for our function cloning work. It may not be exactly
what you need but could be useful.
By the way, it seems that you are interested to use GCC as a research
platform. In this case, sorry for a small advertisement, but I
I've recently come across a couple of issues trying to compile Firefox
trunk with 4.5 (I have a very simple plugin that I need to run on
mozilla-central). I've posted two bugs here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139 and here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42171
I''m
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-24 08:10 ---
-Wunused-variable is checking the TREE_USED flag, which is set quite early
during the parsing (in C FE build_external_ref, in C++ FE mark_used called from
finish_id_expression). At that point the parser doesn't track
--- Comment #4 from hjl dot tools at gmail dot com 2009-11-24 08:14 ---
It is caused by revision 154433:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00654.html
I also saw it on Linux/ia32, Linux/ia64 and Linux/x86-64.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-24 08:16 ---
Subject: Bug 42045
Author: janus
Date: Tue Nov 24 08:16:32 2009
New Revision: 154492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154492
Log:
2009-11-24 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-24 08:18 ---
Fixed with r154492. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2009-11-24 08:28 ---
(In reply to comment #7)
b) Implicit typing of procedure components:
This has been fixed in PR42045.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-24 08:37
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01304.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42057
Compile the attached test case with options -Os -mthumb, gcc generates
following code to destruct the array of objects:
__tcf_0:
.fnstart
.LFB1:
.save {r3, r4, r5, lr}
push{r3, r4, r5, lr}
.LCFI0:
ldr r5, .L5
mov r4, r5
add r4, r4,
--- Comment #1 from carrot at google dot com 2009-11-24 08:52 ---
Created an attachment (id=19108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19108action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42161
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-24 09:55 ---
*** Bug 42160 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-24 09:55 ---
*** This bug has been marked as a duplicate of 42154 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-24 10:47 ---
Ugh. Packing standard library classes will change the ABI (the packing state
is not mangled), so I'd say it's strongly advised to not do this unless you
know what you are doing (appearantly you don't).
Paolo, I
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-24 10:49 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-24 10:49
---
Of course, this is completely unsupported.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-11-24 10:56 ---
Subject: Bug 42154
Author: jamborm
Date: Tue Nov 24 10:56:14 2009
New Revision: 154493
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154493
Log:
2009-11-24 Martin Jambor mjam...@suse.cz
PR
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-11-24 10:58 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from info at hex-rays dot com 2009-11-24 11:02 ---
What is embarrassing is that the compiler does not issue at least a warning and
changes the alignment depending on some very obscure factor. I understand why
it happens but really do not like it.
If I add one more line
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-24 11:36 ---
*** This bug has been marked as a duplicate of 18624 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jakub at gcc dot gnu dot org 2009-11-24 11:36 ---
*** Bug 36390 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from jakub at gcc dot gnu dot org 2009-11-24 11:38 ---
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01338.html
is an example where the warning would be very useful, we create GC garbage
uselessly...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-11-24 11:57 ---
Subject: Bug 42142
Author: rguenth
Date: Tue Nov 24 11:57:26 2009
New Revision: 154494
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154494
Log:
2009-11-24 Richard Guenther rguent...@suse.de
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-11-24 11:57 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
I get this error while trying to compile a simple code which (I think) is valid
omp. I tried gfortran 4.3.3 (ubuntu 9.04 amd64 server) 4.4.1 (ubuntu 9.10
amd64) and 4.5.0 20091105 . This is the code that triggered it:
PROGRAM ordered
IMPLICIT NONE
INTEGER :: i
!$omp parallel do
do i=1,2
I get this error while trying to compile a simple code which (I think) is valid
omp. I tried gfortran 4.3.3 (ubuntu 9.04 amd64 server) 4.4.1 (ubuntu 9.10
amd64) and 4.5.0 20091105 . This is the code that triggered it:
PROGRAM ordered
IMPLICIT NONE
INTEGER :: i
!$omp parallel do
do i=1,2
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2009-11-24
13:09 ---
Created an attachment (id=19109)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19109action=view)
assembly for problem object file in libssp.0.dylib that causes dsymutil to
assert
--- Comment #46 from jakub at redhat dot com 2009-11-24 13:11 ---
Subject: Re: [4.5 Regression] dsymutil Assertion failed ...
assembly for problem object file in libssp.0.dylib that causes dsymutil to
assert
You forgot -dA, without that it is not very readable.
--
--- Comment #3 from rainer at emrich-ebersheim dot de 2009-11-24 13:29
---
Confirmed.
In file included from ../../../../../../../src/ppl-0.10.2/src/Box.cc:24:0:
../../../../../../../src/ppl-0.10.2/src/Grid_Generator_System.inlines.hh: In
constructor
--- Comment #47 from jakub at gcc dot gnu dot org 2009-11-24 13:40 ---
Also, Alex is probably far more interested in preprocessed source plus exact
cc1 options rather than assembly, because the former can be debugged a cross
compiler.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-24 13:42 ---
*** Bug 42163 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42162
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-24 13:42 ---
*** This bug has been marked as a duplicate of 42162 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #48 from howarth at nitro dot med dot uc dot edu 2009-11-24
13:57 ---
Unfortunately, I won't be able to provide additional files until tonight.
However, looking at the ssp.s, I am wondering if the entries in the...
.section __DWARF,__debug_loc,regular,debug
--- Comment #49 from howarth at nitro dot med dot uc dot edu 2009-11-24
14:10 ---
I should also note that the ssp.s was generated using gcc trunk with
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html. The generated
libssp.0.dylib asserts dsymutil. Out of the object files
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-11-24 14:16
---
Created an attachment (id=19110)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19110action=view)
candidate patch
Patch I was testing. Unfortunately I get
Comparing stages 2 and 3
warning:
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-24 14:17 ---
Reduced:
struct A { A(); };
struct B: A {
B() : A::A() { }
};
There's no need to write the extra scope here, but I guess we should accept it.
--
jason at gcc dot gnu dot org changed:
What
I'm using the latest gcc 4.5 to compile the latest linux kernel(rc8).
$ mips64el-unknown-linux-gnu-gcc --version
mips64el-unknown-linux-gnu-gcc (GCC) 4.5.0 20091123 (experimental)
and encountered this error:
$ make ARCH=mips CROSS_COMPILE=mips64el-unknown-linux-gnu- mm/rmap.o
CHK
--- Comment #3 from vlad at demoninsight dot com 2009-11-24 15:48 ---
(In reply to comment #1)
This bug doesn't appear to be present in current gcc trunk on
x86_64-apple-darwin10.
Jack, how should I interpret your comment? That all is well in 4.4.3 branch or
something? Or that you
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-24 16:02 ---
Confirm. With -fopenmp it fails with:
test.f90:17:0: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'indirect_ref' in omp_add_variable, at
gimplify.c:5282
[In 4.3 and
--- Comment #3 from burnus at gcc dot gnu dot org 2009-11-24 16:11 ---
The simplified test case is just having the work subroutine.
The problem is that the argument k is also the loop variable. I am not sure
that this is allowed.
Jakub, do you quickly see whether this is allowed?
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-24 16:19 ---
There are other bugs in the testcase too, e.g. you must not nest worksharing
regions, but the testcase uses !$omp do inside of !$omp parallel do.
That said, gcc shouldn't ICE on any kind of garbage.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |target
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-24 16:23 ---
Can you provide the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Using -masm=intel and -mavx together with something that uses a 256-bit vector
causes an internal error:
$ gcc arst.c -mavx -masm=intel
arst.c: In function âfooâ:
arst.c:2: internal compiler error: in print_operand, at
config/i386/i386.c:11324
$ cat arst.c
typedef unsigned long vec
--- Comment #12 from toon at moene dot org 2009-11-24 18:03 ---
Any tricks I have missed?
Yes - we could provide for loop versioning in the front end.
I.e., generate code like:
IF (M3 0) THEN
... compute loop count ...
... perform loop ...
ELSE IF (M3 0) THEN
... compute
--- Comment #1 from jakub at gcc dot gnu dot org 2009-11-24 18:04 ---
--- gcc/config/i386/i386.c2009-11-24 09:59:29.0 +0100
+++ gcc/config/i386/i386.c2009-11-24 19:03:24.871058078 +0100
@@ -11849,6 +11849,7 @@ print_operand (FILE *file, rtx x, int co
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-24 18:16 ---
Can you please add a check before the qsort call (tree-sra.c, line
1407) whether all pointers in the access_vec seem OK or whether it is
SRA that passes the invalid pointer to qsort? Nothing fancy,
something as
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-24
18:42 ---
Subject: Re: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in
compare_access_positions
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-24 18:16
---
Can you please
gfortran -c -fbounds-check -g -O3bug.f90
bug.f90: In function newuob:
bug.f90:4:0: error: definition in block 11 does not dominate use in block 17
for SSA_NAME: sum_4 in statement:
# DEBUG sum = D#1 + sum_4
bug.f90:4:0: internal compiler error: verify_ssa failed
Please submit a full bug
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
|
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-24 19:20 ---
and confirmed for current trunk.
gcc version 4.5.0 20091124 (experimental) [trunk revision 154511] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42166
--- Comment #50 from howarth at nitro dot med dot uc dot edu 2009-11-24
19:22 ---
Created an attachment (id=19111)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19111action=view)
output from /usr/bin/dwarfdump --verbose --show-form ssp.o
See...
When the argument to a TYPE IS construct is a function result variable with the
same name as the encompassing function, the compiler interprets the variable as
a function invocation and fails without arguments. The code below produces the
error message below the code. Also, replacing TYPE IS
Minor problem as the code isn't really valid. GNAT probably shouldn't
explode in this manner, however.
gcc -c timer2.adb
+===GNAT BUG DETECTED==+
| 4.4.0 (x86_64-portbld-freebsd7.2) Assert_Failure sinfo.adb:2362 |
| Error detected at
--- Comment #1 from gcc at coreland dot ath dot cx 2009-11-24 20:20 ---
Created an attachment (id=19112)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19112action=view)
case 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42168
--- Comment #2 from gcc at coreland dot ath dot cx 2009-11-24 20:21 ---
Created an attachment (id=19113)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19113action=view)
Assertion failure with with_clause removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42168
--- Comment #3 from laurent at guerby dot net 2009-11-24 20:52 ---
Confirmed and this is a regression from 4.3.
$ gcc -c timer3.adb
+===GNAT BUG DETECTED==+
| 4.5.0 20091109 (experimental) [trunk revision 154026]
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-24 20:55 ---
Subject: Bug 42137
Author: jason
Date: Tue Nov 24 20:55:24 2009
New Revision: 154519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154519
Log:
PR c++/42137
* parser.c
--- Comment #19 from jason at gcc dot gnu dot org 2009-11-24 20:55 ---
Subject: Bug 11764
Author: jason
Date: Tue Nov 24 20:55:24 2009
New Revision: 154519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154519
Log:
PR c++/42137
* parser.c
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-24 21:04 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from jason at gcc dot gnu dot org 2009-11-24 21:05 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
model: posix
gcc version 4.4.3 20091124 (prerelease) [gcc-4_4-branch revision 154487] (GCC)
--
Summary: gfortran.dg/pr41928.f90:47: internal compiler error: in
store_can_be_removed_p, at ira-emit.c:371
Product: gcc
Version: 4.4.3
--- Comment #11 from dwitte at mozilla dot com 2009-11-24 21:12 ---
Anthony, any chance you could pick this fix up for libffi 3.0.9?
--
dwitte at mozilla dot com changed:
What|Removed |Added
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #7 from bangerth at gmail dot com 2009-11-24 21:52 ---
Jason, is this PR related to your recent work on injecting class names into
scopes? I don't know what makes gcc reject the constructor specialization,
but it seems to me that it might be because it parses the X part of
--- Comment #51 from howarth at nitro dot med dot uc dot edu 2009-11-24
22:21 ---
Created an attachment (id=19114)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19114action=view)
ssp.s generated with -dA
--
howarth at nitro dot med dot uc dot edu changed:
What
--- Comment #52 from howarth at nitro dot med dot uc dot edu 2009-11-24
22:22 ---
Created an attachment (id=19115)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19115action=view)
preprocessed source for ssp.c created on x86_64-apple-darwin10
--
AS
PARAMETERS TO GENERIC PROCEDURES.
C36205L PASSED .
PASS: c36205l
+===GNAT BUG DETECTED==+
| 4.5.0 20091124 (experimental) [trunk revision 154487]
(hppa-unknown-linux-gnu)
|
| Storage_Error stack overflow
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-11-24 22:51
---
All but six of the fails go away if I increase the stack limit in
run_acats to 16384
OK, thanks, I'll try and increase it.
The remaining six are:
FAIL: c52103x
FAIL: c52104x
FAIL: c52104y
FAIL:
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-24 23:09 ---
Yep, fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #53 from howarth at nitro dot med dot uc dot edu 2009-11-24
23:40 ---
Created an attachment (id=19116)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19116action=view)
assembly with -dA for problem file in libgfortran dylib
--
--- Comment #54 from howarth at nitro dot med dot uc dot edu 2009-11-24
23:45 ---
Created an attachment (id=19117)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19117action=view)
assembly with -dA for problem file in libgfortran dylib
--
--- Comment #55 from howarth at nitro dot med dot uc dot edu 2009-11-24
23:48 ---
Created an attachment (id=19118)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19118action=view)
assembly with -dA for problem file in libgfortran dylib
--
--- Comment #56 from howarth at nitro dot med dot uc dot edu 2009-11-24
23:53 ---
Created an attachment (id=19119)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19119action=view)
assembly with -dA for problem file in libgfortran dylib
--
1 - 100 of 145 matches
Mail list logo
