Hello,
my purpose is to write informations about a function by reading its body
from internal representation. I got the body with DECL_SAVED_TREE and I
succeed to get the name of functions and methods called from CALL_EXPR,
using TREE_OPERAND, EXPR_STMT_EXPR, etc... But I can't get the object
Hello All,
Perhaps libiberty should be a shared library, not a static one, linked from
cc1, when GCC has plugin enabled.
I noticed the following in the MELT branch (while trying to build MELT as a
GCC-Trunk plugin).
Some functions of libiberty.h are not linked in cc1 (because cc1 don't call
Hi, everyone:
The address mode in my my RISC chip is like (BaseReg) + 8bit offset, or
(BaseReg) + indexReg.
And there a 16 general register from R0 to R15 which can be used as Base
register or Index Regster.
So you can see that if the frame space is larger than 255, there will be a
problem.
Basile Starynkevitch wrote:
Hello All,
Perhaps libiberty should be a shared library, not a static one, linked from
cc1, when GCC has plugin enabled.
We might also artificially add a reference to each libiberty function from
cc1.
Or link it into cc1 et al. using --whole-archive.
If we
I'm having trouble with an ICE, and I'm hoping somebody can enlighten me.
Given the following command:
cc1 -fpreprocessed ../pr34330.i -quiet -dumpbase pr34330.c -da -mb
-auxbase-strip pr34330.c -Os -version -ftree-parallelize-loops=4
-ftree-vectorize -o pr34330.s -fschedule-insns
I get an
Dave Korn wrote:
We might also artificially add a reference to each libiberty function from
cc1.
Or link it into cc1 et al. using --whole-archive.
Sorry, I am not aware of this option. And are we sure it works on all
the systems GCC is supposed to run on?
If we did link
Basile STARYNKEVITCH wrote:
Dave Korn wrote:
We might also artificially add a reference to each libiberty function
from
cc1.
Or link it into cc1 et al. using --whole-archive.
Sorry, I am not aware of this option. And are we sure it works on all
the systems GCC is supposed to
Dave Korn wrote:
Basile STARYNKEVITCH wrote:
Dave Korn wrote:
We might also artificially add a reference to each libiberty function
from
cc1.
Or link it into cc1 et al. using --whole-archive.
Sorry, I am not aware of this option. And are we sure it works on
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
But it seems to me that a plugin can call a libliberty function only if that
function is already referenced (e.g. called) from cc1. This is not the case
of all libiberty functions.
So... link libiberty into your plugin and
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
But it seems to me that a plugin can call a libliberty function only if that
function is already referenced (e.g. called) from cc1. This is not the case
of all libiberty functions.
So...
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 02:50:04PM CEST:
On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
But it seems to me that a plugin can call a libliberty function only if that
function is already referenced (e.g. called) from cc1. This is not the case
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with -fPIC.
We build a PIC libiberty already.
While Ralf's point about static data is valid, the functions likely to
be in libiberty on any
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with -fPIC.
We build a PIC libiberty already.
Thanks!
Where and how is it built? I cannot find any
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote:
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled with -fPIC.
We build a PIC libiberty
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:45:52PM +0200, Basile STARYNKEVITCH wrote:
Daniel Jacobowitz wrote:
On Thu, Jul 09, 2009 at 03:01:01PM +0200, Basile STARYNKEVITCH wrote:
In simpler words, *.so have to be compiled with -fPIC, and libiberty
is not compiled
Hey guys,
I noticed a strange performance hit in one of our stencil codes,
causing it to run twice as long.
To nail down the error, I reduced our code to the two attached demo
programs. Basically they take two matrices and average each matrix
element with its four direct neighbors. Depending on
On Thu, Jul 9, 2009 at 4:19 PM, Andreas Schäfergent...@gmx.de wrote:
Hey guys,
I noticed a strange performance hit in one of our stencil codes,
causing it to run twice as long.
To nail down the error, I reduced our code to the two attached demo
programs. Basically they take two matrices and
On 16:37 Thu 09 Jul , Richard Guenther wrote:
Depends on the GCC version used. First of all
printAddress(gridNew[0][0]);
printAddress(gridOld[0][0]);
makes the addresses escape and GCC versions other than the
current development trunk think that the malloced address can
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
While Ralf's point about static data is valid, the functions likely to
be in libiberty on any platform supporting plugins should not suffer
from this problem.
Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as
Ralf Wildenhues wrote:
* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
While Ralf's point about static data is valid, the functions likely to
be in libiberty on any platform supporting plugins should not suffer
from this problem.
Solaris 9 and IRIX 6.5 support
Larry == Larry Evans cppljev...@suddenlink.net writes:
Larry I compiled gcc with -g3 -O0' compiler flags to enable invocation of
Larry macros during a gdb session; however, the
Larry macro, PACK_EXPANSION_PATTERN, apparently uses a symbol:
Larry __extension__
Larry not understood by gdb. How
Hello
I believe plugins and PCH are not always mixing well. For sure, plugins
which are using PLUGIN_REGISTER_GGC_ROOTS are called when *generating*
a precompiled header should be coded with extraordinary care, and very
probably some more suppport is needed inside the GCC trunk.
See the
Nicolas COLLIN nicolas.col...@fr.thalesgroup.com writes:
From internal representation. I got the body with DECL_SAVED_TREE
and I
succeed to get the name of functions and methods called from
CALL_EXPR, using TREE_OPERAND, EXPR_STMT_EXPR, etc... But I can't get
the object on which is called
Andrew Stubbs a...@codesourcery.com writes:
The problem insn is created by gen_reload when it is given the
following rtl as input:
(plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:192 a ] [192])
(const_int 2 [0x2]))
(reg:SI 0 r0 [orig:188 ivtmp.24 ] [188]))
You need to backtrack before
Snapshot gcc-4.5-20090709 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090709/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
The OPTION is there because this was introduced for the option
attribute. But the entry in the target structure is named
can_inline_p, and the macro should be TARGET_CAN_INLINE_P. So the
doc is the desired state, and the code is not.
How's this?
* targhooks.c
Thanks, committed.
Im trying to install GCC 4.4.0 (i tried also with: gcc-4.3.3) my configure is:
../gcc-4.4.0/configure --enable-shared --enable-threads=gnat
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,ada
--prefix=/opt/gnu-gcc/gcc-4.4.0 --with-gmp=/usr --with-mpfr=/usr/local
--enable-libada
--- Comment #9 from eres at il dot ibm dot com 2009-07-09 07:32 ---
Not using unaligned stores for this kind of data dependence or peeling
for alignment will probably help here.
The decision of how to vectorized can be changed for x86 (or any other target).
Instead of first checking
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-07-09 07:53
---
What compiler do you use to bootstrap?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2009-07-09 09:05 ---
For some reason IRA reloads argp using ebp-relative address as:
Reloads for insn # 22
Reload 0: reload_in (DI) = (mem/c/i:DI (plus:SI (reg/f:SI 6 bp)
(const_int 8
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
Compile following function with options -Os -mthumb -march=armv5te
unsigned get_least_bits(unsigned value)
{
return value 9 9;
}
Gcc generates:
ldr r3, .L2
@ sp needed for prologue
and r0, r0, r3
bx lr
.L3:
.align 2
.L2:
.word
--- Comment #1 from carrot at google dot com 2009-07-09 09:24 ---
Created an attachment (id=18166)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18166action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40697
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-09 09:25 ---
Is this mandated to be an error by the standard? Perhaps GCC could just pedwarn
and add the ';' itself, and compile just fine.
Otherwise, I might add a hint:
note: either add ';' or open a block after the label.
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-09 09:42 ---
Subject: Bug 40604
Author: burnus
Date: Thu Jul 9 09:42:34 2009
New Revision: 149405
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149405
Log:
2009-07-09 Tobias Burnus bur...@net-b.de
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-09 09:57 ---
FIXED on the trunk (4.5). The commit message only made it to PR 40604 as I
forgot about PR 40605 ...
Subject: Bug 40604
Author: burnus
Date: Thu Jul 9 09:42:34 2009
New Revision: 149405
URL:
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-09 09:59 ---
Maybe we can fix this in expand instead: if we see (x CONST) and CONST is a
masking constant that isn't a legitimate constant for the the target, then see
if the sum of the rtx_cost of expressing the mask as shifts
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-09 10:32 ---
(In reply to comment #2)
Maybe we can fix this in expand instead: if we see (x CONST) and CONST is a
masking constant that isn't a legitimate constant for the the target, then see
if the sum of the rtx_cost of
--- Comment #2 from Chaipzor at hotmail dot com 2009-07-09 10:38 ---
(In reply to comment #1)
What compiler do you use to bootstrap?
erm... i think im using the old gcc to compile this new one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40696
--- Comment #21 from matz at gcc dot gnu dot org 2009-07-09 10:43 ---
I fear this is no expand-from-SSA problem anymore, but rather an IRA problem.
Unassigning and CCing Vlad.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-07-09 10:46
---
erm... i think im using the old gcc to compile this new one.
I was asking what version of GCC, i.e. the output of 'gcc -v'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40696
--- Comment #4 from Chaipzor at hotmail dot com 2009-07-09 10:58 ---
(In reply to comment #3)
erm... i think im using the old gcc to compile this new one.
I was asking what version of GCC, i.e. the output of 'gcc -v'.
i've installed other version of gcc: 3.4.3
3.4.3 is the GCC
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-07-09 11:00
---
3.4.3 is the GCC old version
Please post the output of 'gcc -v'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40696
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-09 11:19 ---
Subject: Bug 40692
Author: jakub
Date: Thu Jul 9 11:19:22 2009
New Revision: 149418
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149418
Log:
PR middle-end/40692
* fold-const.c
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-09 11:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-09 11:45 ---
Why do you think it has anything to do with IRA? It has all to do with dynamic
stack realignment IMNSHO.
Just try -fno-ira on any of the fall snapshots, it makes absolutely no
difference.
--
--- Comment #6 from Chaipzor at hotmail dot com 2009-07-09 11:48 ---
(In reply to comment #5)
3.4.3 is the GCC old version
Please post the output of 'gcc -v'.
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
--- Comment #7 from Chaipzor at hotmail dot com 2009-07-09 11:54 ---
(In reply to comment #6)
(In reply to comment #5)
3.4.3 is the GCC old version
Please post the output of 'gcc -v'.
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
--- Comment #6 from jakub at gcc dot gnu dot org 2009-07-09 12:04 ---
Indeed, on this testcase crtl-stack_realign_needed is 1, while when using say
int instead of long long it is 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
--- Comment #8 from aldyh at gcc dot gnu dot org 2009-07-09 12:31 ---
This patch fixes the remaining failures.
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00484.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40435
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-09 12:56 ---
There are multiple places which bump crtl-stack_alignment_estimated to 64
during expansion in this case (thus forcing stack_realign_needed):
if (SUPPORTS_STACK_ALIGNMENT)
{
unsigned int align
This bug appears in ALL version of gcc that we tested since gcc 4.1.2
If you see the assembly generated by the cpp source using the
-DNOT_WORKING
option
you will see:
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl
--- Comment #1 from jacob at jacob dot remcomp dot fr 2009-07-09 13:17
---
Created an attachment (id=18167)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18167action=view)
This is the cpp source needed to reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40698
--- Comment #2 from jacob at jacob dot remcomp dot fr 2009-07-09 13:18
---
Created an attachment (id=18168)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18168action=view)
Needed for linking the cpp code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40698
--- Comment #3 from jacob at jacob dot remcomp dot fr 2009-07-09 13:18
---
Created an attachment (id=18169)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18169action=view)
script that demonstrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40698
--- Comment #2 from dodji at gcc dot gnu dot org 2009-07-09 13:21 ---
Subject: Re: ICE in tsubst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The patch was submitted for review at
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00491.html .
-BEGIN PGP SIGNATURE-
Version: GnuPG
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-09 13:25 ---
Created an attachment (id=18170)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18170action=view)
gcc45-pr40667.patch
Very ugly patch which just shows that changing these 3 spots helps both of
these testcases.
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-09 13:50 ---
The code has a bunch of aliasing violations, so is invalid.
*** This bug has been marked as a duplicate of 21920 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #143 from jakub at gcc dot gnu dot org 2009-07-09 13:50 ---
*** Bug 40698 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2009-07-09 13:57 ---
(In reply to comment #8)
on -m32 we ever decrease the stack alignment, this shouldn't break anything.
BTW, the patch also changes something that looks like a thinko to me:
unsigned int align =
--- Comment #7 from janus at gcc dot gnu dot org 2009-07-09 14:07 ---
Subject: Bug 40646
Author: janus
Date: Thu Jul 9 14:07:03 2009
New Revision: 149419
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149419
Log:
2009-07-09 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #5 from jacob at jacob dot remcomp dot fr 2009-07-09 14:34
---
What do you mean by aliasing violations ???
Why would that code be invalid without any warning from the compiler?
It took us a lot of work for finding this bug and reporting it to you
can you explain?
Thanks
--- Comment #10 from mikpe at it dot uu dot se 2009-07-09 14:45 ---
I've identified Jakub's r140177 (PR37356) as the point where these test cases
were fixed in 4.4.0. A backport doesn't look easy (to me anyway).
--
mikpe at it dot uu dot se changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-09 14:48 ---
However, there is also a bug in 4.4: It simply compiles.
But if one adds a print *, there_is, one sees that it does not work (wrong
result, independent of sunshine()!)
--
burnus at gcc dot gnu dot org changed:
--- Comment #11 from marek dot rouchal at infineon dot com 2009-07-09
14:48 ---
(In reply to comment #10)
Thank you very much! I can confirm now that with the given information I was
able to compile on a x86_64 Linux box a gcc-4.3.3 with all executables (gcc,
cc1, ...) built in 32bit,
--- Comment #144 from manu at gcc dot gnu dot org 2009-07-09 15:20 ---
I added in the URL field the relevant section in the GCC manual.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-09 15:26 ---
g++-4.1 -S t.C -O2 -m32 -Wall
t.C: In function TwoPointers InterlockedExchange(TwoPointers*, TwoPointers):
t.C:60: warning: dereferencing type-punned pointer will break strict-aliasing
rules
t.C:60: warning:
--- Comment #145 from rguenth at gcc dot gnu dot org 2009-07-09 15:26
---
*** Bug 40698 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-09 15:32 ---
#1 0x008c8613 in can_be_reached_by_runtime (contains_stmt=0x188ab30,
r=0x75fc33f0) at /space/rguenther/src/svn/trunk/gcc/except.c:569
569 EXECUTE_IF_SET_IN_BITMAP (i-aka, 0, n, bi)
--- Comment #7 from manu at gcc dot gnu dot org 2009-07-09 15:35 ---
@Jacob,
The C/C++ standards have some precise rules of what can and cannot be done
about pointer casts.
See
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Optimize-Options.html#index-fstrict_002daliasing-749
See also
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-09 15:38 ---
Indeed fixed by gimplifying unit-at-a-time. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-09 15:38 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40435
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40496
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-09 15:41 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
Priority|P3
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-09 15:43 ---
./cc1 -quiet t.i -O2 -ftracer
t.i: In function 'f':
t.i:5:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40556
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599
--- Comment #4 from daney at gcc dot gnu dot org 2009-07-09 15:48 ---
The patches in comment #1 fix the problem.
If someone would review them we could probably close the bug.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40642
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ra |missed-optimization
Priority|P3
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-09 15:50 ---
Caused by honzas CD-DCE changes.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-09 15:55 ---
Thanks, it also happens in current trunk.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2009-07-09 16:24 ---
I'm not sure what you mean MINIMUM_TYPE_ALIGN should be. A new type field?
That would be IMHO an overkill, would enlarge types too much.
If it is just a macro, it should be probably MINIMUM_ALIGNMENT, not
--- Comment #11 from hjl dot tools at gmail dot com 2009-07-09 16:34
---
(In reply to comment #10)
I'm not sure what you mean MINIMUM_TYPE_ALIGN should be. A new type field?
That would be IMHO an overkill, would enlarge types too much.
If it is just a macro, it should be probably
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2009-07-09 16:40
---
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /oslo.c/gnatmail/release-6_0/gcc-41/build-oslo/src/configure
--prefix=/opt/gnu/gnat --enable-languages=c,ada --disable-nls --disable-libada
--- Comment #5 from pault at gcc dot gnu dot org 2009-07-09 16:49 ---
Subject: Bug 40629
Author: pault
Date: Thu Jul 9 16:48:50 2009
New Revision: 149422
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149422
Log:
2008-07-09 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #14 from pault at gcc dot gnu dot org 2009-07-09 17:06 ---
(In reply to comment #13)
Thus: I think this PR be closed, can it?
Tobias,
I was keeping it open for comment #8. I already built a patch for zero,
array-to-array and constant constructor assignments.
--- Comment #4 from pault at gcc dot gnu dot org 2009-07-09 17:08 ---
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pault at gcc dot gnu dot org 2009-07-09 17:10 ---
Sorry - I forgot about 40629.
Closing, closing now!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-09 17:15 ---
Already fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Between 20090522 and 20090702, all sparcv9 libjava execution tests started to
fail. libjava.log reveals:
set_ld_library_path_env_vars:
ld_library_path=.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc
Setting
--- Comment #3 from dodji at gcc dot gnu dot org 2009-07-09 17:56 ---
Subject: Bug 40684
Author: dodji
Date: Thu Jul 9 17:56:44 2009
New Revision: 149423
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149423
Log:
2009-07-09 Dodji Seketeli do...@redhat.com
gcc/cp/ChangeLog:
--- Comment #4 from dodji at gcc dot gnu dot org 2009-07-09 18:01 ---
Subject: Bug 40684
Author: dodji
Date: Thu Jul 9 18:00:58 2009
New Revision: 149425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149425
Log:
2009-07-09 Dodji Seketeli do...@redhat.com
gcc/cp/ChangeLog:
1 - 100 of 136 matches
Mail list logo
