Andrew Pinski wrote:
On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley [EMAIL PROTECTED] wrote:
I have some broken code, compiled from Java source.
It looks like:
D.843 = java.text.Collator.class
Richard Guenther wrote:
On Mon, Oct 13, 2008 at 4:38 PM, Andrew Haley [EMAIL PROTECTED] wrote:
Andrew Pinski wrote:
On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley [EMAIL PROTECTED] wrote:
I have
Andrew Pinski wrote:
On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley [EMAIL PROTECTED] wrote:
I have some broken code, compiled from Java source.
It looks like:
D.843 = java.text.Collator.class
I have some broken code, compiled from Java source.
It looks like:
D.843 = java.text.Collator.class$$;
_Jv_InitClass (D.843);
D.845 = _CD_java_text_Collator;
is being turned into:
D.843 = java.text.Collator.class$$;
D.845 = _CD_java_text_Collator;
_Jv_InitClass (D.843);
Richard Guenther wrote:
On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley [EMAIL PROTECTED] wrote:
I have some broken code, compiled from Java source.
It looks like:
D.843 = java.text.Collator.class$$;
_Jv_InitClass (D.843);
D.845 = _CD_java_text_Collator;
is being turned
)
-- java.lang.String.toString(char[],int,int)
I've also had to add a new field to the rewrite rules, that of the
destination class, but unless I've made a mistake this won't make
any difference to the existing rules.
Andrew.
2008-09-22 Andrew Haley [EMAIL PROTECTED]
* expr.c (rules): Add new
Etienne Lorrain wrote:
On C structures, for attributes like const, it is enough to consider
that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
An object that has volatile-qualified type may
Etienne Lorrain wrote:
On C structures, for attributes like const, it is enough to
consider that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
An object that has volatile-qualified type may
Klaus Grue wrote:
Is this a known problem:
After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
preprocessing.
The function (named testsuite) is just a long list of statements
essentially of form
Thomas A.M. Bernard wrote:
Hi,
Is there a way to order the compiler to output only virtual registers
within the assembly code ? (pointers to GCC code sections in back-end or
in MD files are welcome) Hence the result assembly code would not have a
conventional register allocation. It would
Sebastian Redl wrote:
Balogh, Ray wrote:
Dear GCC folks:
I'm having a problem with GCC 2.95.3 that appears to be a compiler
bug. It seems to be optimizing out inlined function code with side
effects, and is related to binding a non-const pointer to a const
pointer reference function
Tom Quarendon wrote:
If I do this I get std::terminate called from __cxa_throw. Researching
this it seems that I somehow need to register some exception handling
tables to correspond to the magic function to enable the exception
handler to allow the exception to propagate through.
Right.
Sergei Poselenov wrote:
Hello,
A naive question. For the same toolchain (gcc-3.2, binutils-2.11.94,
glibc-2.3.1) I've got the following binary sizes (busybox, built
with -Os):
MIPS:
bash# size busybox
textdata bss dec hex filename
1650805564 10168 180812
Aaron W. LaFramboise wrote:
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
./sysdep/backtrace.h:107: error: ISO C++
G Shyam Sundar wrote:
Hi,
I am working with a kernel module, which was compiled using GCC
4.X, for x86_64 platform.
After dis-assembling the module object file, I see that the callq
function is always called with the next instruction of the code as the
target address(based on IP only),
Manuel López-Ibáñez wrote:
2008/7/30 Aaron W. LaFramboise [EMAIL PROTECTED]:
Andrew Haley wrote:
Aaron W. LaFramboise wrote:
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace
Agner Fog wrote:
Basile STARYNKEVITCH wrote:
At last, at the recent (july 2008) GCC summit, someone (sorry I forgot
who, probably someone from SuSE)
proposed in a BOFS to have architecture and machine specific
hand-tuned (or even hand-written assembly) low
level libraries for such basic
Tom Tromey wrote:
Jay == Jay [EMAIL PROTECTED] writes:
Jay This is an incomplete bug report.
Jay unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree:
Jay -bash-3.00$ gcc -v
Jay Using built-in specs.
Jay Target: sparc-sun-solaris2.10
[...]
Jay /.libs/HTML_401F.o
Jay gcj:
Steve Perkins wrote:
I have a question about using GCC/GCJ to compile a Java application
which uses the SWT framework for its GUI, and whether this locks you in
or out of any licensing options. I apologize in advance if this
question is somewhat off-topic... I searched gnu.org for a
Steve Perkins wrote:
You couldn't do that. However, libgcj carries with it an exception that
allows you to link non-GPL code. Look at the license for more details.
Can you perhaps elaborate? No offense, but I think the original
message makes clear that looking at the licenses for more
Chris Lattner wrote:
IMO, the whole notion of a compiler-specific macro has pretty limited
usefulness. Why not add macros for specific *features* offered by the
compiler. For example:
#ifdef __SUPPORTS_NESTED_FUNCTIONS__
is much better than some mismash of version checking, which isn't
Jim Wilson wrote:
If the Intel compiler correctly implements the GNU C language,
then it shouldn't matter if the code is being compiled by GCC or ICC.
Unless maybe you ran into a GCC bug, and want to enable a workaround
only for GCC.
I think you'd want to conditionalize such a test on the GCC
x z wrote:
I would like to see that GCC define a macro in the case it is being
used to compile a program. Currently there is a __GNUC__ macro
defined by the GNU C preprocessor CPP. That does not suit the need.
As the CPP Manual says: __GNUC__ is defined by all GNU compilers
that use the C
x z wrote:
I think an important point was missed in the discussion. Some seem
to focus on the dishonest definition of __GNUC__ by non-GNU C
compilers. That was not my point. My point is that if __GNUC__ is
defined by CPP, not the GNU C compiler proper, (and this seems to be
supported by
Bingfeng Mei wrote:
Hello,
In following code, gcc (mainline version as well as previous versions)
produces wrong code without giving any warning regarding strict aliasing
violation.
~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
./tst
barrier1
Miscompilation
If I
Bingfeng Mei wrote:
Sorry, I made a mistake. My local copy of mainline version (still 4.3.0
20080213) doesn't gave warning. I just updated my mainline GCC and it
does give warning now.
I think that you'll find the release 4.3 version does too.
While we try to ensure that gcc warns whenever
Mark Mitchell wrote:
Andrew Haley wrote:
But, I am actually ok with having it be disabled by default, provided
that regressions affect gcj are treated seriously: fixed in a timely
way by the person causing the regression, or, if not, letting gcj
maintainers start the patch-reversion clock
Mark Mitchell wrote:
Andrew Haley wrote:
I agree. I also agree that if someone breaks Java, they should be
required to fix the problem. In fact, we could have the rule that the
Java maintainers get to revert a patch summarily based merely on the
fact that there exists a Java post-patch
Richard Guenther wrote:
On Wed, Jun 25, 2008 at 4:04 PM, Andrew Haley [EMAIL PROTECTED] wrote:
Hans-Peter Nilsson wrote:
Date: Tue, 24 Jun 2008 10:36:15 +0100
From: Andrew Haley [EMAIL PROTECTED]
I thought cast-through-pointer-to-union didn't work and was already
disallowed; we've been
Gabriel Dos Reis wrote:
On Wed, Jun 25, 2008 at 9:49 AM, Andrew Haley [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
The C++ standard calls this a type pun, so -- with all due respect -- I'm
The C++ standard does not actually call it a type pun, but I think I
understand what you mean
Hans-Peter Nilsson wrote:
There's background in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593. Neither
Richi nor me could find the union-assignment gcc extension at
a glance, probably because it's not an *extension* but an
implementation-defined behavior, and actually duly documented as
Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the compiler that can't possible affect it.
I didn't make it completely clear, but my suggestion
Steven Bosscher wrote:
On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi [EMAIL PROTECTED] wrote:
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad, but
when it breaks it affects hundreds of developers
Tom Tromey wrote:
Florian == Florian Weimer [EMAIL PROTECTED] writes:
We could look into this. The minimum subset is probably several
hundred classes. For instance, Class refers to URL, which will
probably pull in most of java.net.
Florian Can't you fallback to the interpreter for the
Diego Novillo wrote:
I posted this question to the SC panel at the GCC Summit today. I
wanted to consider the possibility of making java a non-default language.
Would the Java maintainers agree to this?
The rationale is mostly that Java takes a very long time to build, and
it does not
Tom Tromey wrote:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Diego I posted this question to the SC panel at the GCC Summit today. I
Diego wanted to consider the possibility of making java a non-default
language.
Andrew If this were to happen it would break repeatedly.
Yeah
Janis Johnson wrote:
On Fri, 2008-06-20 at 10:41 -0600, Tom Tromey wrote:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Diego I posted this question to the SC panel at the GCC Summit today. I
Diego wanted to consider the possibility of making java a non-default
language.
Andrew
Tom Tromey wrote:
Ian == Ian Lance Taylor [EMAIL PROTECTED] writes:
Ian Is it possible to only build and test a subset of libjava by default,
Ian and still get useful coverage of Java? The issue I see is simply that
Ian building libjava is half of the time required for a bootstrap.
We
Diego Novillo wrote:
On 6/19/08 11:06 AM, Janis Johnson wrote:
I'll continue to include java in my nightly builds on
powerpc64-unknown-linux-gnu, for which I test with both -m32 and -m64.
Likewise. I will keep including java in my ppc64, i686 and x86_64 daily
testers. I'm only trying to
Karen Shaeffer wrote:
On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote:
output ~~
$ const_ints
const int ic = 0 *cip = 5 *ip = 5
ic = 0xbfbd72a0cip = 0xbfbd72a0
[EMAIL PROTECTED] wrote:
my intention is to add a pass at the Gimple (maybe SSA) level. The
current problem is that I would like to generate code that saves the
contents of the stack to a different memory location. Is there a way to
access stack pointer and stack size (and the direction in
H.J. Lu wrote:
On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
Joseph S. Myers wrote:
I hold that it is a bug that i686-* tools default to -march=i386 instead
of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and
-mcpu means -march for SPARC).
Seconded.
Basile STARYNKEVITCH wrote:
Hello All
As (I imagine) many developers I have a 64 bits machine - running Debian
(Sid) Linux AMD64.
I want to test my MELT branch on x86 (32 bits). So I set up (using
debootstrap) a x86 32 bits Debian/Lenny chroot-ed system (in /debian32)
which has most of
Ian Lance Taylor wrote:
Andrew Haley [EMAIL PROTECTED] writes:
Richard Guenther wrote:
On Fri, May 30, 2008 at 10:57 AM, Kai Tietz [EMAIL PROTECTED] wrote:
Hi,
as I noticed, most hash value calculations are trying to use pointer
values for building the value and assume that a long
Kai Tietz wrote:
as I noticed, most hash value calculations are trying to use pointer
values for building the value and assume that a long/unsigned long scalar
is wide enough for a pointer. This is at least for w64 target not true. So
I want to know, if it would be good to introduce an gcc
Kai Tietz wrote:
Andrew Haley [EMAIL PROTECTED] wrote on 30.05.2008 11:45:50:
Kai Tietz wrote:
as I noticed, most hash value calculations are trying to use pointer
values for building the value and assume that a long/unsigned long
scalar
is wide enough for a pointer. This is at least
Richard Guenther wrote:
On Fri, May 30, 2008 at 10:57 AM, Kai Tietz [EMAIL PROTECTED] wrote:
Hi,
as I noticed, most hash value calculations are trying to use pointer
values for building the value and assume that a long/unsigned long scalar
is wide enough for a pointer. This is at least for
Paul M. Dubuc wrote:
Joseph S. Myers wrote:
GCC 4.2.4 has been released.
GCC 4.2.4 is a bug-fix release, containing fixes for regressions in
GCC 4.2.3 relative to previous GCC releases. This release is
available from the FTP servers listed at:
http://www.gnu.org/order/ftp.html
Please
Paul M. Dubuc wrote:
Andrew Haley wrote:
Paul M. Dubuc wrote:
Joseph S. Myers wrote:
GCC 4.2.4 has been released.
GCC 4.2.4 is a bug-fix release, containing fixes for regressions in
GCC 4.2.3 relative to previous GCC releases. This release is
available from the FTP servers listed
chris kuhlman wrote:
Hello:
I wrote to the help gcc site and got no response, so I am writing here.
Help would be immensely appreciated.
I am trying to build GCC 4.3.0. I built GMP 4.2.2 and MPFR 2.3.1,
and then I built GCC 4.3.0. Everything appeared to go fine. I
installed compilers
Till Straumann wrote:
What is the proper way to tell gcc that a
inline assembly statement either modifies
a particular area of memory or needs it
to be updated/in-sync because the assembly
reads from it.
E.g., assume I have a
struct blah {
int sum;
...
};
which is accessed by
Paolo Bonzini wrote:
I'd like to implement something similar for MaverickCrunch, using the
integer 32-bit MAC functions, but there is no reciprocal estimate
function on the MaverickCrunch. I guess a lookup table could be
implemented, but how many entries will need to be generated, and how
Paolo Bonzini wrote:
I'd like to implement something similar for MaverickCrunch, using the
integer 32-bit MAC functions, but there is no reciprocal estimate
function on the MaverickCrunch. I guess a lookup table could be
implemented, but how many entries will need to be generated, and how
Andrew Haley wrote:
Paolo Bonzini wrote:
I'd like to implement something similar for MaverickCrunch, using the
integer 32-bit MAC functions, but there is no reciprocal estimate
function on the MaverickCrunch. I guess a lookup table could be
implemented, but how many entries will need
Robert C. Seacord wrote:
Neil,
I'm not sure I understand what you mean by the following:
A program that does not satisfy this constraint is erroneous, and many
compilers take advantage of this constraint to optimize code more
effectively.
Just because a program contains undefined
Hugh Leather wrote:
Hi,
I am trying to add a new destructor function to object files I
compile. I'm doing this to instrument programs and then, once the
program has finished I want to print out the statistics I've gathered.
So, just before pass 'remove_useless_stmts' is called on each
Boris Boesler wrote:
The following program can be compiled without problems.
extern void something(char *s);
char msg[] = 123456;
int main(int argc, char **argv)
{
something(msg);
return 0;
}
But I can't compile it correctly with my backend. The content of msg is
not emitted;
[EMAIL PROTECTED] wrote:
Dear gcc users and developers,
This might be a stupid question, nevertheless...
I've been wondering for a long time, why the behaviour of
variable-length arrays w.r.t. the sizeof operator is different
for local/auto variables and for function arguments (in
Fran Baena wrote:
what are the advantages and inconvenients of get RTL from SSA rather
than GIMPLE (previously translated from SSA)?
It would mean that the expander would have to understand and unpick
SSA-specific stuff like PHI-nodes. It could be done, but I sure can't
think of any reason
Paweł Sikora wrote:
Hi all,
I noticed (readelf -lW/grep) that some gcc libraries require executable stack:
/usr/lib64/libffi.so.4.0.1 GNU_STACK 0x00 0x
0x 0x00 0x00 RWE 0x8
/usr/lib64/libgcj.so.8.0.0 GNU_STACK
[EMAIL PROTECTED] wrote:
21/3/2008, Andrew Haley [EMAIL PROTECTED] napisał/a:
I don't know for sure about libgmp, but the others don't need execstack.
hmm, looks like PR libffi/28036.
How would this affect libgmp?
Andrew.
[EMAIL PROTECTED] wrote:
21/3/2008, Andrew Haley [EMAIL PROTECTED] napisał/a:
[EMAIL PROTECTED] wrote:
21/3/2008, Andrew Haley [EMAIL PROTECTED] napisał/a:
I don't know for sure about libgmp, but the others don't need execstack.
hmm, looks like PR libffi/28036.
How would this affect
Jack Howarth wrote:
It appears that gcj in gcc 4.3.0 is broken on Darwin. If
one builds gcc 4.3.0 executing...
contrib/download_ecj
before running configure, the build succeeds in creating an
ecj1 but when gcj is used to compile an example like testme.java...
public class testme {
Jack Howarth wrote:
Matthias,
My mistake. I see the same issue with gcc-4.2.2 on darwin
which is indeed resolved with --main=testme. I am puzzled why
this isn't automatically handled (as it seems to be with
javac)?
It's isn't automatically handled, you have to provide it at runtime:
Peter Dolding wrote:
Ian Lance Taylor wrote:
Peter Dolding [EMAIL PROTECTED] writes:
Since test is in a different object file it gets completely skiped
from optimising even that it should be optimised out.
http://gcc.gnu.org/wiki/LTO_Driver
Ian
Ok that is half my idea. Let
Ben Elliston wrote:
David Woodhouse wrote:
To be honest, I find it weird that Subversion even exists. Precisely
because it _is_ so close to what people were using before, as you point
out. I've never really understood why anyone would bother to change from
CVS to SVN -- it just seems to be
David Woodhouse wrote:
On Thu, 2008-03-13 at 13:35 -0400, Daniel Berlin wrote:
If by really weird you mean nobody has any real complaints about
the way it works and are happy it is close to what they were using
before, then yes, they are using something really weird.
To be honest, I find it
Aurelien Jarno wrote:
H. Peter Anvin a écrit :
Michael Matz wrote:
On Wed, 5 Mar 2008, Aurelien Jarno wrote:
So I think gcc at least needs an *option* to revert to the old
behavior,
and there's a good argument to make it the default for now, at least
for
x86/x86-64 on Linux.
And for
Olivier Galibert wrote:
On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
Olivier Galibert wrote:
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
Ross Ridge wrote:
Segher Boessenkool writes:
... People are relying on this undocumented GCC behaviour already,
and when things break, chaos ensues.
GCC has introduced many changes over the years that have broken many
programs that have relied on undocumented or unspecified behaviour.
You
Martin Jambor wrote:
On Tue, Mar 04, 2008 at 10:50:17PM +, Paul Brook wrote:
AFAIK the only reason we don't break this rule is that doing so would
be grossly inefficient; there's nothing to stop any gcc back-end with
(say) seriously slow DImode writes from using two SImode writes instead.
Paul Koning wrote:
I'm really wondering why this is being considered.
A documented property of the form GCC will use a single instruction
to do X when possible means exactly nothing. In particular, to call
such a statement a guarantee is seriously misleading.
I agree.
If Linux needs the
Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one
Segher Boessenkool wrote:
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort
Sunzir Deepur wrote:
On Feb 17, 2008 3:55 PM, Andrew Haley [EMAIL PROTECTED] wrote:
Sunzir Deepur wrote:
followup:
After a considerabale amount of time (e.g. 15 seconds), something is suddenly
freed, and the compilation completes successfully. afterwards trying
to recompile
the file completes
Sunzir Deepur wrote:
followup:
After a considerabale amount of time (e.g. 15 seconds), something is suddenly
freed, and the compilation completes successfully. afterwards trying
to recompile
the file completes immediately (it is not a big file, so it takes
fraction of a second).
I don't know
Pavan R wrote:
Can I get some help on this.
Surely you already have an answer. The libgcc on suse 10 isn't
compatible with your RHEL3-compiled program, so you discovered
the fix was to put a better libgcc in your LD_LIBRARY_PATH.
Since you have found a fix that works, why do you still want
Pavan R wrote:
Hi,
We find our application dumps core on Suse 10 SP1 that has
libgcc-4.1.2_20070115-0.11 shipped, with the top of the stack as :
Program terminated with signal 11, Segmentation fault.
#0 0xf7aca09c in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0xf7aca09c in memcpy () from
NightStrike wrote:
On 1/21/08, John David Anglin [EMAIL PROTECTED] wrote:
The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax.
Regarding vax, I don't have the time to maintain it. HPPA
Manuel López-Ibáñez wrote:
On 22/01/2008, Andrew Haley [EMAIL PROTECTED] wrote:
NightStrike wrote:
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user
Gabriel Paubert wrote:
On Thu, Jan 17, 2008 at 05:48:10PM +0300, Sergei Poselenov wrote:
Hello Andrew,
Preprocessed and assembler code generated by the GCC 4.2.2 ppc-linux
cross-compiler:
http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.i
David Edelsohn wrote:
Andrew Haley writes:
Andrew I suspect that the real reason for the change in save/restore is because
Andrew not using lmw/stmw is faster. That's just a guess though. gcc could
probably
Andrew be fixed to use ldmw/stmw if -Os is used.
Andrew Anyway, now we've found
Sergei Poselenov writes:
Hello all,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same code, same compile-
and configuration-time options. Binutils are differ
(2.16.1
Sergei Poselenov writes:
No, all results are for the GCC project. Mainline here means the
current development version of GCC. For it, the sum of the test code
size is 3503061, vs. 3542052 for the gcc_4_0_0 branch. But again,
this performance is achieved by the significant regression for
) and it doesn't fit into the reserved space
anymore.
Andrew Haley wrote:
Sergei Poselenov writes:
Hello all,
I'm using the ppc-linux gcc-4.2.2 compiler and noted the code
size have increased significantly (about 40%!), comparing with
old 4.0.0 when using the -Os option. Same
Sergei Poselenov writes:
Hello Andrew,
Now, I sympathize that in your particular case you have a code size
regression. This happens: when we do optimization in gcc, some code
bases will lose out. All that we can promise is that we try not to
make it worse for most users.
Kaveh R. Ghazi writes:
From: Tom Tromey [EMAIL PROTECTED]
Kaveh == Kaveh R GHAZI [EMAIL PROTECTED] writes:
Kaveh + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
A valgrind
Harpal Grover writes:
On Jan 14, 2008 5:09 AM, Andrew Haley [EMAIL PROTECTED] wrote:
Harpal Grover writes:
Hello all,
I downloaded and built gcc 4.2.2 on my linux box. I have also used the
sources to build a cross compiler using Ranjit's Matthews guide. The
build
Harpal Grover writes:
Hello all,
I downloaded and built gcc 4.2.2 on my linux box. I have also used the
sources to build a cross compiler using Ranjit's Matthews guide. The
build went just fine. I tried to compile my java application and got
the following error:
c1: out of
Adrián Bravo Navarro writes:
I come to you looking for some light ;) We are developing an
application that needs to link statically math.h. I've been looking
for libm.a for Tru64 Alpha with no success at all. System comes
with .so so but i think it's not possible converting .so into .a
Benjamin Kosnik writes:
Attached is a rough cut of a detailed portability document
I also put this up here temporarily:
http://people.redhat.com/~bkoz/porting_to_gcc43.html
The Java issues part isn't quite right. It turns out that the java
1.2 problem with the new gcj is really a
H.J. Lu writes:
On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote:
So, what now? Can we even agree about what the psABI actually says
about sign-extending result values? Was what we did before correct,
or what we do now? I don't believe that it doesn't matter.
You
H.J. Lu writes:
On Tue, Jan 08, 2008 at 01:57:50PM +, Andrew Haley wrote:
H.J. Lu writes:
On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote:
So, what now? Can we even agree about what the psABI actually says
about sign-extending result values? Was what
gcc (x86) recently changed its behaviour when returning values shorter
than int. It used to sign extend, and now it doesn't.
short func2( short *size) { return *size; }
trunk:
func2:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movzwl (%eax), %eax
Alexandre Oliva writes:
On Dec 21, 2007, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Alexandre, I have to say that in my opinion absurd arguments like this
do not strengthen your position.
I'm sorry that you feel that way, but I don't understand why you and
so many others apply
Alexandre Oliva writes:
On Dec 19, 2007, Andrew Haley [EMAIL PROTECTED] wrote:
Right, so read_type_die() doesn't know how to handle
DW_TAG_interface_type. The weird thing is that I have never seen
this error mesage before today, and AFAIAA gcj has been
generating these interface
Alexandre Oliva writes:
How about this patch, instead? It will restore debuggability to Java
while at the same time maintaining the progress of using the
long-supported-by-GDB DW_TAG_class_type in both C++ and Java.
for gcc/java/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
Die: DW_TAG_interface_type (abbrev = 23, offset = 4181)
has children: FALSE
attributes:
DW_AT_declaration (DW_FORM_flag) flag: TRUE
Dwarf Error: Cannot find type of die [in module /home/aph/a.out]
I suppose this means that gcj is generating bad debug info, but I
Daniel Jacobowitz writes:
On Wed, Dec 19, 2007 at 05:21:50PM +, Andrew Haley wrote:
Die: DW_TAG_interface_type (abbrev = 23, offset = 4181)
has children: FALSE
attributes:
DW_AT_declaration (DW_FORM_flag) flag: TRUE
Dwarf Error: Cannot find type of die
Daniel Jacobowitz writes:
On Wed, Dec 19, 2007 at 05:54:10PM +, Andrew Haley wrote:
That DIE doesn't have any content. It says I am a declartion of an
interface. But not which interface or what it's called or what the
type is.
Well, the type is the interface: there's
701 - 800 of 1166 matches
Mail list logo
