Hi,
I've filed PR25218:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
which leads at -O3 to:
4.0.1
bug.c:20: internal compiler error: in compensate_edge, at reg-stack.c:2795
4.1
bug.c:20: internal compiler error: in initialize_original_copy_tables, at
cfg.c:1025
Cheers,
Joost
Mark Mitchell wrote:
Jason Merrill wrote:
On Mon, 07 Mar 2005 11:49:05 -0800, Mark Mitchell
<[EMAIL PROTECTED]> wrote:
IMO, if these are C++-only, it's relatively easy to deprecate these
extension -- but I'd like to hear from Jason and Nathan, and also the
user
community before we do that. Of
Jason Merrill wrote:
On Mon, 07 Mar 2005 11:49:05 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
IMO, if these are C++-only, it's relatively easy to deprecate these
extension -- but I'd like to hear from Jason and Nathan, and also the user
community before we do that. Of all the extensions we've
On Mon, 07 Mar 2005 11:49:05 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> IMO, if these are C++-only, it's relatively easy to deprecate these
> extension -- but I'd like to hear from Jason and Nathan, and also the user
> community before we do that. Of all the extensions we've had, this one
On Mar 7, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> For example, I believe that Alex's proposed solution to PR c++/19199
> isn't an appropriate fix. It's perfectly reasonable for fold to convert
> a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
> front-end all three of
On Mar 8, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
>> As has been described earlier on this thread, GCC has folded the C++
>> source "(a >= b ? a : b) = c" into "MAX_EXPR (a,b) = c" and equivalently
>> "(a > b ? a : b) = c" into "MAX_EXPR (b,a) = c" since the creation of
>> current CVS.
On Mon, Mar 07, 2005 at 08:29:48PM -0700, Roger Sayle wrote:
> Which docs?! There's currently *no* documentation for MIN_EXPR
> or MAX_EXPR in c-tree.texi.
Ah, I misremembered the docs for the rtl patterns.
Signed minimum and maximum operations. When used with floating point,
if both operan
On Mon, 7 Mar 2005, Richard Henderson wrote:
> On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote:
> > For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need
> > to specify a reference to the first operand is returned for values
> > comparing equal.
>
> NOT true. And the docs explic
On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote:
> For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need
> to specify a reference to the first operand is returned for values
> comparing equal.
NOT true. And the docs explicitly say so.
r~
On Mon, Mar 07, 2005 at 11:49:05AM -0800, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> >>I'd be happy to see it (deprecated and then) removed, but I think we'd
> >>need
> >>buy-in from the C front end maintainers. As extensions go, it's actually
> >>not
> >>that bad; the semantics are rela
Joseph S. Myers wrote:
I'd be happy to see it (deprecated and then) removed, but I think we'd need
buy-in from the C front end maintainers. As extensions go, it's actually not
that bad; the semantics are relatively well defined.
The min/max expression extension is C++ only, the C front end doesn'
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > On Monday 07 March 2005 19:49, Mark Mitchell wrote:
> >
> > > The way I think about this is that G++ has long supported the GNU
> > > min/max expression extension -- and it's long been broken. Over the
> > > years, I've fielde
On Mon, Mar 07, 2005 at 08:02:40PM +0100, Steven Bosscher wrote:
> [ min/max expr ]
> So, maybe the extension is not used very much. Perhaps it should be
> removed?
Then we'll just get RMS pissed off at the SC again; he hates it when we
remove his extensions. (We've sometimes done so anyway, but
On Mar 7, 2005, at 2:13 PM, Giovanni Bajo wrote:
Well, that sounds largely impossible. Can you point exactly which bug
are
you talking of? I know for a fact that the extension itself has always
worked for basic rvalue usage, with basic types. Instead, I would not
be
surprised if some more complex
Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> The way I think about this is that G++ has long supported the GNU
>> min/max expression extension -- and it's long been broken. Over the
>> years, I've fielded several bug reports about that extension, and we've
>> gradually cleaned it up, but mostly
Steven Bosscher wrote:
On Monday 07 March 2005 19:49, Mark Mitchell wrote:
The way I think about this is that G++ has long supported the GNU
min/max expression extension -- and it's long been broken. Over the
years, I've fielded several bug reports about that extension, and we've
gradually cleaned
On Monday 07 March 2005 19:49, Mark Mitchell wrote:
> The way I think about this is that G++ has long supported the GNU
> min/max expression extension -- and it's long been broken. Over the
> years, I've fielded several bug reports about that extension, and we've
> gradually cleaned it up, but mos
Roger Sayle wrote:
On Mon, 7 Mar 2005, Mark Mitchell wrote:
Roger Sayle wrote:
I truly hope you're not trying to suggest that it was me that introduced
the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
I thought you were the person who introduced changes to fold that caused
it
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > I truly hope you're not trying to suggest that it was me that introduced
> > the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
>
> I thought you were the person who introduced changes to fold that caused
> it t
Roger Sayle wrote:
I truly hope you're not trying to suggest that it was me that introduced
the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
I thought you were the person who introduced changes to fold that caused
it to generate these expressions when the GNU source extensio
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > For example, I believe that Alex's proposed solution to PR c++/19199
> > isn't an appropriate fix. It's perfectly reasonable for fold to convert
> > a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
> > front-end
On Mar 7, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> For example, I believe that Alex's proposed solution to PR c++/19199
> isn't an appropriate fix. It's perfectly reasonable for fold to convert
> a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
> front-end all three of
Roger Sayle wrote:
For example, I believe that Alex's proposed solution to PR c++/19199
isn't an appropriate fix. It's perfectly reasonable for fold to convert
a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
front-end all three of these tree nodes are valid lvalues. Hence it'
Hi Alex and Mark,
On 7 Mar 2005, mark at codesourcery dot com wrote:
> Yes, I understand. You still need to take it up with Roger, though.
My apologies to both of you for being curiously/annoyingly silent on
this is issue. I've been getting up to speed on the internals of the
C++ parser, in or
24 matches
Mail list logo
