Re: MIPS/FORTRAN failures...

[Tobias Burnus]

David Daney wrote:
> The gfortran.dg/optional_dim_2.f90 test has been failing on mipsel-linux
> ever since it was added.

See PR 34387. If you want, you could try the patch posted there.

Tobias

Re: __builtin_expect for indirect function calls

[Mark Mitchell]

Richard Guenther wrote:

>> What do people think?  Do we have the leeway to change this?  Or should
>> we add __builtin_expect2?  Or add an -fno-polymorphic-builtin-expect?
>> Or...?
> 
> I think we should simply make __builtin_expect polymorphic, but make sure
> to promote integral arguments with rank less than long to long.

I thought of that, but I hadn't suggested this idea because it seemed so
weird.  Promoting to int would not be odd, but promoting to long is
weird.  Anyhow, you're right; that's another option, and, despite
weirdness, plausible.  I can't think of a way in which it changes
current behavior, unless you call __builtin_expect with a long long, and
that's probably not going to do what you expect right now anyhow.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: __builtin_expect for indirect function calls

[Ross Ridge]

Mark Mitchell writes:
> What do people think?  Do we have the leeway to change this?

If it were just cases where using __builtin_expect is pointless that
would break, like function overloading and sizeof then I don't think
it would be a problem.  However, it would change behaviour when C++
conversion operators are used and I can see these being legitimately
used with __builtin_expect.  Something like:

struct C {
operator long();
};

int foo() {
if (__builtin_expect(C(), 0))
return 1;
return 2;
}

If cases like these are rare enough it's probably an acceptable change
if they give an error because the argument types don't match.

Ross Ridge