H.J. Lu writes:
> What value did you use for -mpreferred-stack-boundary? The x86 backend
> defaults to 16byte.
On Windows the 16-byte default pretty much just wastes space, so I use
-mpreferred-stack-boundary=2 where it might make a difference. In the
case where I wanted to use SSE vector instruc
Ross Ridge writes:
> As I mentioned later in my message STACK_BOUNDARY shouldn't be defined in
> terms of hardware, but in terms of the ABI. While the i386 allows the
> stack pointer to bet set to any value, by convention the stack pointer
> is always kept 4-byte aligned at all times. GCC should
On 12/18/07, Ross Ridge <[EMAIL PROTECTED]> wrote:
> Look at it another way. Lets say you were compiling x86_64 code with
> -fpreferred-stack-boundary=3, an 8-byte PREFERRED alignment.
Can we stop talking about x86/x86_64 specifics issues here? I have an
use case for the PowerPC side of the Cell
Andrew Pinski writes:
> Can we stop talking about x86/x86_64 specifics issues here?
No.
>I have an use case for the PowerPC side of the Cell BE for variables
>greater than the normal stack boundary alignment of 16bytes. They need
>to be 128byte aligned for DMA transfering to the SPUs.
>
>I alrea
Hello,
I see quite a few instances when i get the following RTL. A conditional
branch, followed by a BASIC_BLOCK note, followed by a non-TImode
instruction. Theoretically, i should be allowed to package the non-TI
instruction along with the conditional branch, but doing so seems to be
produce
Thanks for Ross and HJ's comments. Here is updated proposal:
Changes:
- value of REQUIRED_STACK_BOUNDARY of leaf function
- value of INCOMING_STACK_BOUNDARY
-- 0. MOTIVATION --
Some local variables (such as of __m128 type or marked with alignment
attribute) require stack aligned at a boundary la
On 19/12/2007, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> The current list of "All regressions" should be a list of bugs that
> people are actively trying to resolve, preferably before the release
> of GCC 4.3. Instead, it is a mix of high-activity bug reports and bug
> reports where even the t
On Wed, Dec 19, 2007 at 04:12:55AM -0500, Ross Ridge wrote:
>
> I'm suggesting a different defintion of STACK_BOUNDARY which wouldn't,
> if strictly followed, result STACK_BOUNDARY being defined as 8 on
> the i386. The i386 hardware doesn't enforce a minimum alignment on the
> stack pointer.
On
On Wed, Dec 19, 2007 at 04:12:59AM -0500, Ross Ridge wrote:
>
> >STACK_BOUNDARY is the minimum stack boundary. MAX(STACK_BOUNDARY,
> >PREFERRED_STACK_BOUNDARY) == PREFERRED_STACK_BOUNDARY. So the question is
> >if we should assume INCOMING == PREFERRED_STACK_BOUNDARY in all cases:
>
> Doing this
On Wed, Dec 19, 2007 at 01:59:51AM +0100, Steven Bosscher wrote:
> The current list of "All regressions" should be a list of bugs that
> people are actively trying to resolve, preferably before the release
> of GCC 4.3.
No, it should be exactly what it says it is. If you want an additional
list
On 12/19/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> >
> > > Consider PRE alone,
> >
> > > If your debug statement strategy is "move debug statements when we
> > > insert cod
On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> >> int c = z;
> >> whatever0(c);
> >> c = x;
>
> > Because you have added information you have no way of knowing.
> > How exactly did you compute that the call *definitely sets
Daniel Berlin wrote:
Here is the easy one:
z_5 = a_3 + b_3
x_4 = z_5 + c_3
DEBUG(x, x_4)
Reassoc may transform this into:
z_5 = c_3 + b_3
x_4 = z_5 + a_3
DEBUG(x, x_4)
Now x has the wrong value.
??
x_4 looks like it has the value 'a_3 + b_3 + c_3' in both examples to
me, although c
On 12/18/07 08:29, Jan Hubicka wrote:
Doing call graph changes should not be that hard (I was trying to keep
similar deisgn in mind when implementing it, even if we stepped away
from the plan in some cases, like reorganizing passes from vertical to
horisontal order). Nearest problem I see is mer
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 [in module /home/aph/a.out]
>
>
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
don
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 d
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> You snipped (skipped?) one aspect of the reasoning on why it is
> appropriate. Of course this doesn't prove it's the best possibility,
> but I haven't seen evidence of why it isn't.
You will find it easier to demonstrate the worth of your proposal if
Diego Novillo wrote
> On 12/18/07 08:29, Jan Hubicka wrote:
>
>> Doing call graph changes should not be that hard (I was trying to keep
>> similar deisgn in mind when implementing it, even if we stepped away
>> from the plan in some cases, like reorganizing passes from vertical to
>> horisontal ord
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 nothing else it might be.
>F
On Wed, Dec 19, 2007 at 10:00:38AM -0800, Ian Lance Taylor wrote:
> int f(int x, int y) {
> int i = 0, j = 0;
>
> probe1();
> i = x;
> j = y;
> probe2();
> Of course there are no actual instructions between the calls to
> probe1() and probe2(). If I use gdb's "finish" command out of
>
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 inte
On Wed, Dec 19, 2007 at 07:00:41PM +, Andrew Haley wrote:
> It seems to me that even if gcj did generate the name for the
> interface, gdb would still die because it doesn't have any handlers
> for DW_TAG_interface_type in dwarf2read.c
Yes, you're probably right. It thinks it's some kind of s
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> Dwarf enables arbitrary value expressions too.
> Well, uh, no.
> The only way to directly specify the value of a variable is for
> constants. DW_AT_const_value does not allow
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
> >
> > Here is the easy one:
> >
> > z_5 = a_3 + b_3
> > x_4 = z_5 + c_3
> >
> > DEBUG(x, x_4)
> >
> >
> > Reassoc may transform this into:
> >
> >
> > z_5 = c_3 + b_3
> > x_4 = z_5 + a_3
> >
> > DEBUG(x, x_4)
> >
> > No
On Wed, 2007-12-19 at 10:00 -0800, Ian Lance Taylor wrote:
> One way to make a principled choice is to consider the line notes we
> are going to emit with the debugging information. Presumably we do
> not have the goal of emitting correct debug information in between
> line notes--e.g., when using
It gets worse, however
c_3 = a_1 + b_2
z_5 = c_3 + d_9
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + g_12
->
c_3 = a_1 + b_2
z_5 = c_3 + g_12
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + d_9
x_4 now no longer represents the value of x, but we haven't directly
ch
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> Here is the easy one:
> z_5 = a_3 + b_3
> x_4 = z_5 + c_3
> DEBUG(x, x_4)
> Reassoc may transform this into:
> z_5 = c_3 + b_3
> x_4 = z_5 + a_3
> DEBUG(x, x_4)
> Now x has the wrong value.
As Andrew said, no, it doesn't.
Now,
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>>
>> > Consider PRE alone,
>>
>> > If your debug statement strategy is "move debug statements when we
>> > insert
Hello Gentlemen,
Much as I'm a fan of the GCC and rely on -Wall, I would like to suggest
to you that -Wparentheses should be split up, and things it checks/suggests
be moved out of -Wall. If this is not the right forum or if you'd rather
see this as a bug report, I'm happy to go where I'm point
On Wed, Dec 19, 2007 at 05:02:52PM -0200, Alexandre Oliva wrote:
> That said... I can't find any more the equivalent of
> DW_CFA_val_expression in DW_OP_*s that could be used in location
> expressions. I just *knew* it was there, but I guess I just imagined
> it. This is embarrassing.
I am pret
On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote:
> One last point. In looking for the rationale behind this warning, I searched
> for examples of it. I didn't find any discussion on this list. What I did
> find were many examples of people rototilling perfectly fine code, "improving"
> it by
On Wed, Dec 19, 2007 at 03:02:35PM -0500, [EMAIL PROTECTED] wrote:
> My specific candidate for exclusion from -Wall is this one:
>
> if (a && b || c && d)
>
> which yields (as you know) advice to parenthesize the two && pairs.
>
> I very much think this is unhelpful, counterproductive ad
Wednesday 19 December 2007 22:11:22 tarihinde Doug Gregor şunları yazmıştı:
> On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote:
> > One last point. In looking for the rationale behind this warning, I
> > searched for examples of it. I didn't find any discussion on this list.
> > What I did fi
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>
> > It gets worse, however
> >
> > c_3 = a_1 + b_2
> > z_5 = c_3 + d_9
> > x_4 = z_5 + e_10
> > DEBUG(x, x_4)
> > y_7 = x_4 + f_11
> > z_8 = y_7 + g_12
> > ->
> >
> > c_3 = a_1 + b_2
> > z_5 = c_3 + g_12
> > x_4 = z_5 + e_10
> > DEBUG(x, x_4
On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> > Here is the easy one:
>
> > z_5 = a_3 + b_3
> > x_4 = z_5 + c_3
>
> > DEBUG(x, x_4)
>
>
> > Reassoc may transform this into:
>
>
> > z_5 = c_3 + b_3
> > x_4 = z_5 + a_3
>
> >
Janis Johnson <[EMAIL PROTECTED]> writes:
> On Wed, 2007-12-19 at 10:00 -0800, Ian Lance Taylor wrote:
> > One way to make a principled choice is to consider the line notes we
> > are going to emit with the debugging information. Presumably we do
> > not have the goal of emitting correct debug in
On Dec 19, 2007 4:32 PM, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 01:59:51AM +0100, Steven Bosscher wrote:
> > The current list of "All regressions" should be a list of bugs that
> > people are actively trying to resolve, preferably before the release
> > of GCC
On Thu, 2007-12-13 at 08:27 -0500, Diego Novillo wrote:
> On 12/13/07 2:39 AM, Ollie Wild wrote:
>
> > The lto branch is already doing this, so presumably that discussion
> > was resolved (Maybe someone in the know should pipe up.).
>
> Yes, streaming the IL to/from disk is a resolved issue.
> ..
On Dec 19, 2007 5:19 PM, Tim Josling <[EMAIL PROTECTED]> wrote:
> This means passing over a file. So I would like to understand how to
> avoid getting into political/legal trouble when doing this.
Passing over a file in what format? If you are writing a COBOL to C
translator, that will certainly
On Dec 19, 2007, at 2:19 PM, Tim Josling wrote:
...
http://gcc.gnu.org/projects/lto/lto.pdf
...
Was there any more about this?
I have restarted work on my COBOL front end. Based on my previous
experiences writing a GCC front end I want to have as little code as
possible in the same process
On Dec 19, 2007 5:29 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> I'd be interested to hear if keeping the LTO format stable is
> something the GCC community plans to do,
I doubt it. We may end up doing it for practical reasons within a
release, but I'm not sure if it's high on anyone's priori
Snapshot gcc-4.2-20071219 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071219/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
[EMAIL PROTECTED] writes:
> Much as I'm a fan of the GCC and rely on -Wall, I would like to suggest
> to you that -Wparentheses should be split up, and things it checks/suggests
> be moved out of -Wall. If this is not the right forum or if you'd rather
> see this as a bug report, I'm happy to go
On Wed, Dec 19, 2007 at 10:17:00PM +0100, Steven Bosscher wrote:
> On Dec 19, 2007 4:32 PM, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>
> > If you want an additional
> > list of bugs that are being actively worked on (and labelled as such),
> > that's fine (although I have no idea how th
On 12/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Let's take a bug as an example case: http://gcc.gnu.org/23835
>
> Here, there is a bug report about a huge compile time increase. The
> release manager decided that this was not a release blocker for GCC
> 4.2. So it was marked P4, and it
Is it possible to disable the heuristic inline function logic? I would
like to select the following behaviour:
* all static inline functions are always inlined
* all static functions that are called once are inlined
(-finline-functions-called-once)
* no other functions are inlined
I'm using -Os a
Is there a switch to never inline a non-static function?
Thanks,
Shaun
On Dec 19, 2007 6:25 PM, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> Is it possible to disable the heuristic inline function logic? I would
> like to select the following behaviour:
>
> * all static inline functions are always
On Dec 19, 2007 1:41 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> I am hoping that in the next couple of days, Nathan and I will be able
> to say that we have completed to work that Codesourcery/NaturalBridge
> contracted to do with IBM. Completion means that we are able to compile
> and run t
Diego Novillo wrote:
> On Dec 19, 2007 1:41 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>
>> I am hoping that in the next couple of days, Nathan and I will be able
>> to say that we have completed to work that Codesourcery/NaturalBridge
>> contracted to do with IBM. Completion means that we
NightStrike wrote:
On 12/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
Let's take a bug as an example case: http://gcc.gnu.org/23835
Here, there is a bug report about a huge compile time increase. The
release manager decided that this was not a release blocker for GCC
4.2. So it was m
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>> Now, if z_5 were present in a debug expression, then it would need
>> adjusting. No different from the adjusting need for any other
>> instruction in which z_5 was present, though.
> uh, but if you don't adjust in the fixed examples,
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 types for a long while.
For ve
Ian Lance Taylor wrote:
> I have no objection to splitting -Wparentheses into separate warnings
> controlled by separate options.
Thank you, Ian.
> > which yields (as you know) advice to parenthesize the two && pairs.
>
> That particular warning happened to find dozens of real errors when I
On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> For some things, sure, but we are just talking about the values in
> user visible variables stored in registers. There is no way we can
> make that information be correct between line notes.
Err... I think there is, and one way to d
On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> You snipped (skipped?) one aspect of the reasoning on why it is
>> appropriate. Of course this doesn't prove it's the best possibility,
>> but I haven't seen evidence of why it isn't.
>
56 matches
Mail list logo
