In the following test case (based on gcc.dg/tree-ssa/copy-headers.c),
the volatile asm statement is duplicated:
extern int foo (int);
void bla (void)
{
int i, n = foo (0);
for (i = 0; (({{ __asm__ volatile (foo_label:); }}), i n); i++)
foo (i);
}
In this case, this is problematic
On Nov 14, 2005 10:31 AM, Florian Weimer [EMAIL PROTECTED] wrote:
What do you think?
I thought labels can't appear in an asm statement...?
Gr.
Steven
Hi,
current mainline boostrap breaks (at least for me) on i686-pc-linux-gnu.
configure flags : --quiet --prefix=$DESTDIR --enable-languages=c++,fortran
--with-gmp=/afs/mpa/data/martin/mygmp
/scratch/gccmake bootstrap
[...]
stage1/xgcc -Bstage1/
Hi,
I've had a report from a friend that a program that I had written
was crashing running a basic test which ran fine on my machine.
He noted that he was using gcc 4.0.1, whereas I am running 3.4.1
(Mandrake 10.1) so I suspected a compiler bug might be the case.
I use the gcc compiler a lot, but
* Steven Bosscher:
On Nov 14, 2005 10:31 AM, Florian Weimer [EMAIL PROTECTED] wrote:
What do you think?
I thought labels can't appear in an asm statement...?
Of course, you can put pretty much what you want into asm statements,
the compiler does not look at them. Jumping from one asm
On 11/14/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I appreciate that this is quite valid according to the ANSI C
standard and the team are within their rights to change this,
but I am curious to know the reasoning behind the change which
seems to me to make the object code less optimal.
[EMAIL PROTECTED] wrote:
I appreciate that this is quite valid according to the ANSI C
standard and the team are within their rights to change this,
but I am curious to know the reasoning behind the change which
seems to me to make the object code less optimal.
It is not a deliberate
On Nov 14, 2005 12:52 PM, Martin Reinecke [EMAIL PROTECTED]
wrote:
Hi,
current mainline boostrap breaks (at least for me) on
i686-pc-linux-gnu.
Known problem, someone checked in a bad patch.
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00946.html
Gr.
Steven
I didn't realize that we had a target with BITS_PER_UNIT == 8
UNITS_PER_WORD == 1. I see that for the AVR POINTER_SIZE is 16, which
suggests that this code should use POINTER_SIZE or GET_MODE_BITSIZE
(Pmode) rather than BITS_PER_WORD. But restricting it to
BITS_PER_WORD = 32 should also be
Laurent GUERBY wrote:
On Thu, 2005-11-03 at 17:43 +0100, Paolo Bonzini wrote:
Joel Sherrill [EMAIL PROTECTED] wrote:
Hi,
I have been trying to build sparc-rtems4.7 on the head using newlib's
head for a few days now. I have finally narrowed the behavior down.
If I configure for sparc I
Hi all,
I have this function defined twice. One in the libgcc2.c file and one in
gcc/config/arm/ieee754-df.S
__floatdisf
I have problem during compilation of a arm soft float toolchain. Is
there any fix?
Regards Michael
On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote:
Hi all,
I have this function defined twice. One in the libgcc2.c file and one in
gcc/config/arm/ieee754-df.S
__floatdisf
I have problem during compilation of a arm soft float toolchain. Is
there any fix?
Regards Michael
The build
The current gcc --version prints out
gcc (GCC) 4.1.0 20051113 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Can we change it
Richard Earnshaw wrote:
On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote:
Hi all,
I have this function defined twice. One in the libgcc2.c file and one in
gcc/config/arm/ieee754-df.S
__floatdisf
I have problem during compilation of a arm soft float toolchain. Is
there any fix?
On Mon, 2005-11-14 at 17:17, Michael Trimarchi wrote:
Richard Earnshaw wrote:
On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote:
Hi all,
I have this function defined twice. One in the libgcc2.c file and one in
gcc/config/arm/ieee754-df.S
__floatdisf
I have problem during
On Sun, Nov 13, 2005 at 04:29:26AM -0500, Robert Dewar wrote:
Richard Guenther wrote:
And this is why there seemed to be consensus to merge the two in the
middle-end and preserve debug-info somehow differently. Like with
a frontend type-id on the decl. That would allow lowering of f.i.
On Sat, Nov 12, 2005 at 04:01:07PM -0500, Andrew Pinski wrote:
Was there an example of:
int f(int );
int g(void)
{
int *a = 0;
return f(*a);
}
Yes this would be undefined code but so what.
In a case like this, gcc could emit an error (since we can already
detect that a
On Sat, Nov 12, 2005 at 10:47:33AM -0800, Per Bothner wrote:
Per Bothner wrote:
A function-never-returns-null attribute doesn't seem like
the right mechanism. Instead, there should be a never-null
attribute on pointer types. A function-never-returns-null is
just a function whose
Eric Botcazou wrote:
Building a --target=avr compiler currently fails because
/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/
-B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem
On 13 Nov 2005 21:36:02 -0800, Ian Lance Taylor ian@airs.com wrote:
Jan Hubicka [EMAIL PROTECTED] writes:
in testsuite there are few reduced testcases where unit growth (an
inliner limit - inliner is allowed to inline as long as the unit don't
grow by given percentage, set to 50%) is too
Joe Buck wrote:
On Sat, Nov 12, 2005 at 04:01:07PM -0500, Andrew Pinski wrote:
Was there an example of:
int f(int );
int g(void)
{
int *a = 0;
return f(*a);
}
Yes this would be undefined code but so what.
In a case like this, gcc could emit an error (since we can already
detect that a
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
Excuse me. IANALL nor am I a compiler expert but ...
what kind of optimization might be done with the information
that a reference *should* never be null? Especially within
the server code (the implementation of int f(int a) in
On Nov 14, 2005, at 1:31 AM, Florian Weimer wrote:
The documentation of the asm keyword does not explicitly say that a
volatile asm statement may be duplicated by the compiler, but of
course it is to be expected in some cases (inlining, for example).
However, for consistency, it might be better
Michael N. Moran [EMAIL PROTECTED] writes:
| And what is the meaning of code that does this:
|
| int foo(int a)
| {
| int*b = a;
|
| if(b ==0)
| {
| a();
| }
| else
| {
| b();
| }
According to the standard, the compiler can assume that
On Nov 14, 2005, at 9:14 AM, H. J. Lu wrote:
Can we change it to something like
gcc (GCC) 4.1.0 20051113 (revision 106863) (experimental)
Doesn't work, unless you also have the branch name. Further, the
substitutions that svn can do, doesn't allow for the above, and they
don't want to
Joe Buck wrote:
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
Excuse me. IANALL nor am I a compiler expert but ...
what kind of optimization might be done with the information
that a reference *should* never be null? Especially within
the server code (the implementation of
Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
| And what is the meaning of code that does this:
|
| int foo(int a)
| {
| int*b = a;
|
| if(b ==0)
| {
| a();
| }
| else
| {
| b();
| }
According to the standard,
Michael N. Moran [EMAIL PROTECTED] writes:
[...]
| Do we want to hide the error by not crashing? Why not just do the
| math and keep running? This seems like a run-time check that
| is not a part of the C/C++ language as I understand it.
defined by which standards?
-- Gaby
Joe Buck wrote:
On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
Excuse me. IANALL nor am I a compiler expert but ...
what kind of optimization might be done with the information
that a reference *should* never be null? Especially within
the server code (the implementation of
Michael N. Moran [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael N. Moran [EMAIL PROTECTED] writes:
| | And what is the meaning of code that does this:
| | | int foo(int a)
| | {
| | int*b = a;
| | | if(b ==0)
| | {
| | a();
| | }
| |
Michael N. Moran [EMAIL PROTECTED] writes:
| Joe Buck wrote:
| On Mon, Nov 14, 2005 at 01:43:38PM -0500, Michael N. Moran wrote:
|
| Excuse me. IANALL nor am I a compiler expert but ...
| what kind of optimization might be done with the information
| that a reference *should* never be null?
Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
[...]
| Do we want to hide the error by not crashing? Why not just do the
| math and keep running? This seems like a run-time check that
| is not a part of the C/C++ language as I understand it.
defined by which standards?
Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
| void buzz(Abc b)
| {
| delete b;
| }
|
| void baz()
| {
| Abc a = * new Abc();
If no memory is available, the new-expression throws an exception so
the dereference never occurs. Check out C++ manuals.
As a
Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
| Wow. I'm sure there is sound reasoning for this ... but I can't
| understand what that might be given a client module could intentionally
| (if ill-adviseadly) simply invoke the function:
then it gets what it deserves. Check
Michael N. Moran [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael N. Moran [EMAIL PROTECTED] writes:
| | void buzz(Abc b)
| | {
| | delete b;
| | }
| | | void baz()
| | {
| | Abc a = * new Abc();
| If no memory is available, the new-expression throws an exception
Michael N. Moran [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael N. Moran [EMAIL PROTECTED] writes:
| | Wow. I'm sure there is sound reasoning for this ... but I can't
| | understand what that might be given a client module could intentionally
| | (if ill-adviseadly) simply
On Mon, Nov 14, 2005 at 12:52:49PM -0800, Mike Stump wrote:
On Nov 14, 2005, at 9:14 AM, H. J. Lu wrote:
Can we change it to something like
gcc (GCC) 4.1.0 20051113 (revision 106863) (experimental)
Doesn't work, unless you also have the branch name. Further, the
substitutions that svn
Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael N. Moran [EMAIL PROTECTED] writes:
| | void buzz(Abc b)
| | {
| | delete b;
| | }
| | | void baz()
| | {
| | Abc a = * new Abc();
| If no memory is available, the
Hello list.
I've recently been toying with the rref patch found here:
http://mndfck.org/~pedro.lamarao/projects/c++0x/
As part of my learning process I've modified it and broken it in three
parts: new flags to activate c++0x syntax and semantics, reference
collapsing as per DR #106 proposed
Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
| From info gcc:
|
| `-fdelete-null-pointer-checks'
| Use global dataflow analysis to identify and eliminate useless
| checks for null pointers. The compiler assumes that dereferencing
| a null pointer would
Michael N. Moran [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael N. Moran [EMAIL PROTECTED] writes:
| | From info gcc:
| | | `-fdelete-null-pointer-checks'
| | Use global dataflow analysis to identify and eliminate useless
| | checks for null pointers. The
On Mon, Nov 14, 2005 at 11:56:16PM +0100, Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
SEGFAULT is not a behaviour defined by the language. It is *just* one
form of undefined behaviour. If you execute that function, it might
reformat your harddrive and that woud be fine
Lars Callenbach wrote:
v = new double **[100];
operator new[]() - operator new() - malloc () - _int_malloc()
Without a testcase we can compile, we probably can't do anything except
point out that a malloc failure is probably not due to a gcc problem.
--
Jim Wilson, GNU Tools Support,
Rafael Ávila de Espíndola wrote:
DECL_RESULT holds a RESULT_DECL node for the value of a function,
or it is 0 for a function that returns no value.
(C functions returning void have zero here.)
I looked at gcc-1.42, and even there, a DECL_RESULT always holds a
RESULT_DECL. It can
Joern RENNECKE wrote:
When you compile a file that contains a line directive, e.g.:
using the -fpreprocessed option to cc1, but without -fdumpbase, the base
filename of the
line number directive us used both for the assembly output file and for
debugging dumps
from -da.
This is probably a
Ioannis E. Venetis wrote:
I sent this message about a week ago, but didn't get any response. So, I
try again. My question is whether this is a bug of gfortran and if I
should open a bug report about it. I haven't found this in Bugzilla.
Yes, go ahead and create a bug report, and mention that
Joel Sherrill [EMAIL PROTECTED] wrote:
s-auxdec.ads:286:13: alignment for Aligned_Word must be at least 4
Any ideas?
I'm guessing this is because ARM sets STRUCTURE_SIZE_BOUNDARY to 32
instead of 8, and this confuses the Ada front end.
--
Jim Wilson, GNU Tools Support,
Rafael Espíndola wrote:
Why does treelang defines signedness of char with flag_signed_char?
IMHO it would be better if it had a fixed definition of it. I have
tried to use
Signedness of char depends on the OS. If you want compatibility with C,
and in particular, the standard C library, then
Andreas Jaeger wrote:
Running make check in fixincludes on x86_64-gnu-linux I get the
following failure:
Just grepping for _STRING_INCLUDED it is easy to see the input rule in
inclhack.def that defines this transformation, and the output rule in
fixincl.x that actually does the
Jim Wilson [EMAIL PROTECTED] writes:
| Rafael Ávila de Espíndola wrote:
| DECL_RESULT holds a RESULT_DECL node for the value of a function,
| or it is 0 for a function that returns no value.
| (C functions returning void have zero here.)
|
| I looked at gcc-1.42, and even there, a
Gabriel Dos Reis wrote:
Michael N. Moran [EMAIL PROTECTED] writes:
| void bar(int a);
|
| void foo(int* a)
| {
| // dereference: conversion to reference
| // Since there is not necessarily any object access,
| // thus no assured SEGFAULT.
| bar(*a);
SEGFAULT is not a
Maybe the middle end should only have one pointer type, but with at
least two attributes, one to tell the debugger to auto-dereference,
one to mark those pointers that cannot point to null. This might
enable more optimization.
That would certainly be my recommendation. It would
mathieu lacage wrote:
Clearly, 0x11 is not a bb boundary so we have a bug.
Looks like it could be the prologue end, but I don't see any obvious
reason why this patch could do that. I suggest you try debugging your
patch to see why you are getting the extra call with
LINE_FLAG_BASIC_BLOCK
On Mon, Nov 14, 2005 at 06:24:47PM -0800, Jim Wilson wrote:
mathieu lacage wrote:
Clearly, 0x11 is not a bb boundary so we have a bug.
Looks like it could be the prologue end, but I don't see any obvious
reason why this patch could do that. I suggest you try debugging your
patch to see
On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
While the debugging output looks quite correct at -O0, the -O2 output
seems broken:
main:
0: 8d 4c 24 04 lea0x4(%esp),%ecx
4: 83 e4 f0and$0xfff0,%esp
7: ff 71 fc
Michael N. Moran [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael N. Moran [EMAIL PROTECTED] writes:
| | void bar(int a);
| | | void foo(int* a)
| | {
| | // dereference: conversion to reference
| | // Since there is not necessarily any object access,
| | //
On Mon, 2005-11-14 at 18:16, Gabriel Dos Reis wrote:
I was under the impression that the DECL_RESULT is nullified for a
function that passes the named return-value optimization.
Just using grep, I don't see any obvious evidence of that. I don't know
where to look for more info. I see a
This branch will act as a repository for new optimizations mostly meant to
improve code generation on IA-64. However, some of the work currently
going on should help other targets as well. For now, this will help
independent contributors to have a common code base to work with.
The branch
Peter S. Mazinger wrote:
-fno-stack-protector-all is not recognised/implemented
You could just submit this as a bug report into bugzilla.
apps built w/ -fstack-protector-all segfault
You will have to give us more info. Most gcc developers probably don't
have a copy of UClibc, and plus it
Mike Lerwill wrote:
#undef TARGET_DEFAULT_TARGET_FLAGS
#define TARGET_DEFAULT_TARGET_FLAGS (MASK_QUICKCALL)
This is mostly right, except that second line should be
#define TARGET_DEFAULT_TARGET_FLAGS (TARGET_DEFAULT)
Alternatively, we could delete the 2 lines defining
On Mon, 2005-11-14 at 22:18 -0500, Andrew Pinski wrote:
--Boundary-00=_dwUeD1M6OcgA542
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
This branch will act as a repository for new optimizations mostly meant to
improve
apps built w/ -fstack-protector-all segfault
You will have to give us more info. Most gcc developers probably
don't have a copy of UClibc, and plus it sounds like you have made
gcc changes that weren't included in your message. So there isn't
much we can do here except ask for more
On Mon, 14 Nov 2005, Jim Wilson wrote:
Peter S. Mazinger wrote:
-fno-stack-protector-all is not recognised/implemented
You could just submit this as a bug report into bugzilla.
apps built w/ -fstack-protector-all segfault
You will have to give us more info. Most gcc developers
On Mon, 14 Nov 2005, Eric Christopher wrote:
apps built w/ -fstack-protector-all segfault
You will have to give us more info. Most gcc developers probably
don't have a copy of UClibc, and plus it sounds like you have made
gcc changes that weren't included in your message. So
this should also influence the -fstack-protector behaviour, but
that seems
to be OK.
__builtin_trap is used as I can see only if a vulnerability is
found, this
happens though on a simple hello world.
Aaah. You'll probably need to step through the program in a debugger
then and find out
On Mon, 2005-11-14 at 21:30 -0500, Daniel Jacobowitz wrote:
On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote:
While the debugging output looks quite correct at -O0, the -O2 output
seems broken:
main:
0: 8d 4c 24 04 lea0x4(%esp),%ecx
4: 83 e4
Gabriel Dos Reis wrote:
I'm saying that if you call foo with a null pointer, you get into
undefined behaviour territory. And GCC is founded to make
optimization based on that. And you -- as a user -- generally don't
know how and when GCC can apply that assumption. And it is already
doing so in
On Mon, 14 Nov 2005, Eric Christopher wrote:
this should also influence the -fstack-protector behaviour, but
that seems
to be OK.
__builtin_trap is used as I can see only if a vulnerability is
found, this
happens though on a simple hello world.
Aaah. You'll probably need to
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-14 15:27 ---
Created an attachment (id=10233)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10233action=view)
testcase
self-contained (but complete) yyparse function.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-14 15:29 ---
The problem is that with 31.ccp we introduce:
bb 0:
save1 = yylval;
save2 = yyval;
save3_92 = yynerrs;
save4_94 = yyerrflag;
yystate_95 = 0;
yychar_96 = -1;
yynerrs = 0;
yyerrflag = 0;
yyp_99 =
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 ---
*** This bug has been marked as a duplicate of 6259 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 ---
*** Bug 24848 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-14 15:40 ---
Reduced testcase:
void abort(void);
int main()
{
int a[10], *p;
p = a[-1];
if (p = a[9])
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
--- Comment #1 from aoliva at gcc dot gnu dot org 2005-11-14 15:41 ---
Yeah, weakref support in the compiler is independent of .weakref support in the
assembler. If .weakref is not available, the compiler will emulate that by
always using the target symbol name, and deciding at the
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-14 15:42 ---
C++ frontend is fine. With C out of
(.03.gimple)
p = a + -4B;
D.1282 = a + 36B;
we (fold?) get
(.10.cleanup_cfg)
p = a[1073741823];
D.1282 = a[9];
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-14 15:42 ---
Confirmed, short testcase:
int f(void)
{
int i = -1;
int a[10];
int *b = a[2];
return a[i]=b;
}
int main(void)
{
if (f())
abort();
}
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #17 from sje at cup dot hp dot com 2005-11-14 15:44 ---
Eric, can you be more specific about what won't work? The regression testing
with Zack's patch seemed to go fine and hand testing some cases looks OK too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-14 15:52
---
Eric, can you be more specific about what won't work? The regression testing
with Zack's patch seemed to go fine and hand testing some cases looks OK too.
Do you have a eh_dummy.o file for both -milp32 and
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:56 ---
The problem here is that we are comparing in unsigned when we shoud be
comparing in a signed type.
This was introduced by:
2005-01-29 Richard Guenther [EMAIL PROTECTED]
PR tree-optimization/15791
--- Comment #19 from sje at cup dot hp dot com 2005-11-14 16:01 ---
Yes, I checked the installed libgcc_eh.a
(lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
eh_dummy.o. I do not getting any warnings messages from ld
--- Comment #7 from amacleod at redhat dot com 2005-11-14 16:01 ---
Subject: Bug 24709
Author: amacleod
Date: Sun Nov 13 16:09:14 2005
New Revision: 106865
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106865
Log:
PR tree-optimization/24709
* tree-ssa-operands.c
// compile this with -O3 to get segfault on 4.0.3,
// note the warning: inline function 'A::~A()' used but never defined.
// 3.3 and 4.1 accept this code without warning.
// This bug was originally reported by Alexey Maximov [EMAIL PROTECTED]
struct A;
templateclass T
struct P
{
P() : p(0) { }
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 ---
This is a dup of bug 24248 which in turn is a dup of bug 22252.
*** This bug has been marked as a duplicate of 22252 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 ---
*** Bug 24852 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:07 ---
(In reply to comment #19)
Yes, I checked the installed libgcc_eh.a
(lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
eh_dummy.o. I do
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:09
---
Yes, I checked the installed libgcc_eh.a
(lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
eh_dummy.o. I do not getting any warnings
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Target Milestone|---
For current mainline and Apple 3.3/4.0, the top pass in the profile is
scheduling: 14.99 (42%) usr 4.32 (75%) sys 19.32 (46%) wall
Note that at -O0, instead, it is
global alloc : 1.06 (30%) usr 0.03 ( 5%) sys 1.09 (26%) wall
but I doubt we can do much about it.
--- Comment #1 from bonzini at gcc dot gnu dot org 2005-11-14 16:22 ---
Created an attachment (id=10234)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10234action=view)
file used for benchmarking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-14 16:27 ---
Valid testcase (?):
void abort(void);
int main()
{
int a[10], *p, *q;
q = a[1];
p = q[-1];
if (p = a[9])
abort ();
return 0;
}
fold_stmt is doing the a[0] + -4B to a[1073741823] transformation. But
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:28
---
Odd. We have the latest linker patch installed on our system (PHSS_33349) and
applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still
gave
a warning. I guess 'struct eh_dummy;' didn't add
--- Comment #23 from sje at cup dot hp dot com 2005-11-14 16:33 ---
I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib
when building GCC:
ar --version
GNU ar 2.16.91 20051103
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you
--- Comment #24 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:59 ---
(In reply to comment #23)
I build binutils 2.16 as part of my GCC build/test so I used that ar and
ranlib
when building GCC:
We're using the system ar/ranlib. I built binutils-2.16 with _no_ patches
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-14 17:03 ---
Patch to avoid the situation posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-14 17:04 ---
(In reply to comment #8)
Patch to avoid the situation posted.
So this patch makes the real bug latent.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from sje at cup dot hp dot com 2005-11-14 17:05 ---
I build binutils with --disable-shared and using flex/bison instead of
lex/yacc, that is probably why my ar works. I experimented with the use of the
system ar/ranlib by just building eh_dummy.o and .a by hand and they
--- Comment #26 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:18 ---
(In reply to comment #25)
I build binutils with --disable-shared and using flex/bison instead of
lex/yacc, that is probably why my ar works. I experimented with the use of
the
system ar/ranlib by
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-14 17:25 ---
Gfortran is doing the right thing with respect to
a BOZ-literal-constant (other than a BOZ can only
be used in a DATA statement per the F95 standard,
so the code is invalid).
If you look at the definition of BOZ in
--- Comment #27 from sje at cup dot hp dot com 2005-11-14 17:26 ---
In your last comment you mention the binutils ar, but later the binutils as. I
cannot reproduce the problem by just using the binutils ar command but I can
reproduce it using the binutils as (assembler) command. Which
1 - 100 of 248 matches
Mail list logo
