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 pro
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, 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:
> > :
> > 0: 8d 4c 24 04 lea0x4(%esp),%ecx
> > 4:
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, 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 mess
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 develop
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 det
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
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 TARGET_DE
>
> --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 code generation on IA-64. However, some of the work c
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
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 wi
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 numb
"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 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:
> :
> 0: 8d 4c 24 04 lea0x4(%esp),%ecx
> 4: 83 e4 f0and$0xfff0,%esp
> 7: ff 71 fc
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 t
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 se
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 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 b
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,
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 transformati
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 y
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, http://www.specifix
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 t
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 na
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 neve
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, h
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
"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.
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 wo
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 r
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 availa
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
"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)
"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 th
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. Che
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:
[...]
| 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?
"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 b
"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();
| > |
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:
[...]
| 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
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 standar
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 "
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 `fi
"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 t
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 t
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
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
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
/opt/cross/avr/
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 wh
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 th
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
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
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?
Regar
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
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 b
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
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
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 f
[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 cha
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
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 optim
* 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 a
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 d
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/gcc>make bootstrap
[...]
stage1/xgcc -Bstage1/ -B/afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/
On 13 Nov 2005 21:36:02 -0800, Ian Lance Taylor 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 stri
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
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 b
69 matches
Mail list logo
