On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> Do we still want to keep this branch alive?
Looking at the changes that were made in the last three months still,
it seems the branch is still surprisingly alive, so it may not yet be
the time to close it. Personally I don't have a preference either w
Hi,
I just noticed an error in a part of the code that I converted, that
looks this way:
switch (gimple_assign_subcode (stmt))
{
case SSA_NAME:
handle_ssa_name ();
break;
case PLUS_EXPR:
handle_plus ();
break;
default:
something ();
}
The problem of course is that for
Desineni, Harikishan wrote:
I just compiled an app with GCC. It is segmentation faulting in call_gmon_start
(even before reaching main() of my program
Gcc usage questions should not be sent to the gcc list. This list is
for being doing development work on gcc. This is an appropriate
questi
Hi,
I have problem with data flow and combine that is causing ICE with
experimental build. Despite all efforts to blame my own target changes,
I have reached the conclusion that this is a gcc COMBINE bug, but seek
your advice before filing a bug report.
The problem seems to be that the LOG_LI
On Sat, 8 Mar 2008, Alexandre Oliva wrote:
> On Mar 4, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > the type of the result is unspecified.
>
> ??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm
> pretty sure that's what specifies the type of the result.
You are late,
On Mar 4, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> the type of the result is unspecified.
??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm
pretty sure that's what specifies the type of the result.
> I suggest to make sure that bit position and size are constants,
+1
On Mar 4, 2008, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> Richard Sandiford wrote:
>> If we went for an explicit move, I assume we would either have to
>> (a) discount hard regs that can't be moved, (b) force backends to
>> allow all no-op moves or (c) circumvent the backend somehow.
> From my
On Mar 6, 2008, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> It's extremely rare, no doubt about it. It's just that it *yells*
> security issue in the making. It's not a source bug, i.e. not easily
> reviewable. It's related to signal handlers which are the mark of a
> server and/or more fail
> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes:
Andi> [also sometimes I would love to have an option in gcc to just
Andi> display the preprocessed input when something bad happens inside
Andi> a macro. I usually do that from hand using gcc -E, but it would be cool
Andi> if the compiler coul
Ian> For a middle-end error like
Ian> "assuming signed overflow does not occur when simplifying
Ian> multiplication" a caret pointer might be more misleading than
Ian> otherwise, as one thing we know for sure is that it would not point at
Ian> a multiplication operator.
Chris> An important class o
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> >Another approach would be to only use the carets for parse errors,
> >which is where they are the most helpful.
>
> And preprocessor if possible
>
> [also sometimes I would love to have an option in gcc to just
> display the preprocessed inpu
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>Another approach would be to only use the carets for parse errors,
>which is where they are the most helpful.
And preprocessor if possible
[also sometimes I would love to have an option in gcc to just
display the preprocessed input when something b
12 matches
Mail list logo
