Re: Clarifying attribute-const

[Richard Biener]

On Fri, Oct 2, 2015 at 1:40 AM, Geert Bosch  wrote:
>
>> On Oct 1, 2015, at 11:34 AM, Alexander Monakov  wrote:
>>
>> Can you expand on the "etc." a bit, i.e., may the compiler ...
>>
>>  - move a call to a "const" function above a conditional branch,
>>causing a conditional throw to happen unconditionally?
> No, calls may only be omitted, not moved.
>>
>>  - move a call to a "const" function below a conditional branch,
>>causing an unconditional throw to happen only conditionally?
>> No, calls may only be omitted, not moved.

I think that's less clear as the transform basically duplicates the call
on both branches and removes the one that is not necessary.

>>  - reorder calls to "const" functions  w.r.t. code with side effects, or
>>other throwing functions?
> A call to a pure function (Ada's version of "const") may be omitted if its 
> result is not used,
> or if results of an earlier call with the same argument values (including 
> referenced values) can
> be used. This is allowed regardless of whether the original function had any 
> side effects.
> Note that if a function raised an exception (threw) the call can only be 
> replaced with throwing
> that exception.
>
> So, reordering is not allowed, but omitting is, in the context of Ada.

I think GCC does both though (if it throws only externally, for
internally throwing ones
the transforms would be too complicated).

Richard.

>   -Geert
>

Re: Clarifying attribute-const

[Eric Botcazou]

> I think that's less clear as the transform basically duplicates the call
> on both branches and removes the one that is not necessary.

Yes, IMO that one is allowed under the as-if rule.

> I think GCC does both though (if it throws only externally, for
> internally throwing ones the transforms would be too complicated).

We never ran into a problem with that in practice AFAIK.

-- 
Eric Botcazou

Re: missed optimization

[Janne Blomqvist]

On Tue, Sep 29, 2015 at 11:20 PM, Richard Biener
 wrote:
> On September 29, 2015 9:27:13 PM GMT+02:00, fxcoud...@gmail.com wrote:
>>It cannot be done in the front-end, but has to happen during value
>>propagation in the middle-end. But the middle-end only handles known
>>*_EXPR and built-ins. So this would require adding either a POWINT_EXPR
>>or a type-generic __builtin_powint. No small task.
>>
>>I think there is already a PR for that (at the very least, I have
>>looked into it and discussed it with some middle-end experts before). I
>>cannot look it up right now, it's the interlude of Don Govanni at Paris
>>Opera :)
>
> The middle-end knows sth remotely related, __builtin_powi, already.  What 
> we'd need though is a way for a frontend to specify which library function to 
> use as fallback.  In principle I would suggest to add a general POW_EXPR tree 
> code.  But the issue as what library call to expand to remains.  Usually such 
> functions reside in libgcc (powi has some there).

Several years ago (PR 32239, geez back in 2007, has it already been
that long...), I already implemented the optimization whereby the
frontend uses __builtin_powi, but that's only for REAL(kind=whatever
corresponds to C float/double/long double) ** INT(kind=C_INT), whereas
the issue here is apparently int**int, for which there is no
equivalent builtin.


-- 
Janne Blomqvist

Re: Debugger support for __float128 type?

[Ulrich Weigand]

Joseph Myers wrote:
> On Thu, 1 Oct 2015, Ulrich Weigand wrote:
> 
> > The _DecimalN types are already supported by DWARF using a base type with
> > encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size.
> 
> Which doesn't actually say whether the DPD or BID encoding is used, but as 
> long as each architecture uses only one that's not a problem in practice.

I see.  Well, one could add a DW_ATE_decimal_interchange_float for
completeness, if necessary.
 
> > For the interchange type, it seems one could define a new encoding,
> > e.g. DW_ATE_interchange_float, and use this together with the
> > appropriate DW_AT_byte_size to identify the format.
> 
> It's not clear to me that (for example) distinguishing float and _Float32 
> (other than by name) is useful in DWARF (and if you change float from 
> DW_ATE_float to DW_ATE_interchange_float that would affect old debuggers - 
> is the idea to use DW_ATE_interchange_float only for the new types, not 
> for old types with the same encodings, so for _Float32 but not float?).  
> But it's true that if you say it's an interchange type then together with 
> size and endianness that uniquely determines the encoding.

So my thinking here was: today, DWARF deliberately does not specify the
details of the floating-point encoding format, so that it doesn't have
to get into all the various formats that exist on all the platforms
supported by DWARF.  That is why a DW_ATE_float encoding simply says;
this is a floating-point number of size N encoded as defined by the
platform ABI.

The new DW_ATE_interchange_float encoding would say instead; this is
a floating-point number of size N encoded as defined by the IEEE
interchange format.

On platforms where the ABI-defined format actually *is* the interchange
format, a DWARF producer would be free to use either DW_ATE_float or
DW_ATE_interchange_float.  This decision could of course take into
consideration compatibility requirements with older debuggers etc.

However, having two encoding definitions would allow platforms to use
both the interchange format and one additional platform-defined
non-interchange format of the same size, if needed.

> > Well, complex types have their own encoding (DW_ATE_complex_float), so we'd
> > have to define the corresponding variants for those as well, e.g.
> > DW_ATE_complex_interchange_float or the like.
> 
> And DW_ATE_imaginary_interchange_float, I suppose.

Right.


As an alternative to specifying the well-defined interchange format,
another option might be to simply add a second DWARF attribute,
e.g. DW_AT_encoding_variant, to floating-point and related base types.
This would simply be an integer with platform-specific semantics.
So DWARF producers could simply describe a type as:
  this is a floating-point number of size N encoded as defined by
  platform ABI encoding variant #V

(If the attribute isn't present, we'd default to variant 0, which
is just the current encoding.)

This would allow an arbitrary number of platform-specific encodings,
any of which might or might not be IEEE-defined formats ...


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Offloading: libgfortran, libm dependencies

[Thomas Schwinge]

Hi!

For example, Fortran source code that uses the ABORT intrinsic, such as:

program main
  implicit none

  print *, "CheCKpOInT"
  !$omp target
  call abort
  !$omp end target

end program main

... currently indeed does terminate program execution, for example with
Intel MIC (emulated) offloading:

 CheCKpOInT
/tmp/offload_5YrtEq/offload_target_main: symbol lookup error: 
/tmp/offload_5YrtEq/lib00.so: undefined symbol: _gfortran_abort

offload error: process on the device 0 unexpectedly exited with code 0

..., but that is clearly not how that is meant to happen (missing
_gfortran_abort symbol).  This can be "fixed" with an explicit
-foffload=-lgfortran to tell the offloading compiler(s) that the
libgfortran support library needs to be brought in.

As ABORT and similar intrinsics are part of the Fortran language, my
assumption is that users expect that they can use such intrinsics inside
offloaded code, even more so for mathematical functions and the like,
.

The same conceptual problem exists with nvptx OpenACC offloading.  Bernd
has once implemented a -Xoffload option which then can be used such as
proposed in ;
see the changes to lang_specific_driver in gcc/fortran/gfortranspec.c, to
have it add -Xoffload options to link -lgfortran and -lm.  Given all the
logic in gcc/fortran/gfortranspec.c dealing with libgfortran (and also
the math library for that matter), I'm not convinced that such a simple
approach (always add these "-Xoffload -lgfortran -Xoffload -lm" options)
is sufficient in all offloading configuration cases.  (And, why can't we
use the existing -foffload instead of adding a new -Xoffload option?)

(And then of course, there is the issue that the libgomp Fortran
testsuite doesn't even use the gfortran driver, but instead manually adds
-lgfortran to the xgcc command line.  I have a patch series to address
this, , but
that's an orthogonal problem.)

A similar problem does not exist when inside offloaded regions you're
using functions that are provided by libgomp itself.  If my understanding
is correct, due to the -fopenacc/-fopenmp flags appearing on the
offloading compilers' command line, this will again cause the libgomp
link spec (libgomp/libgomp.spec.in) to be added, which will link in the
offload targets' libgomp.  Also, the offloading compilers' default link
spec does include libc and libgcc, so C/C++ source code, for example,
using the C library's abort function in offloaded code does work as
expected.

How should we handle libgfortran and libm dependencies in offloaded code?

As the linking requirements especially regarding libgfortran may be
different for each offloading target (shared and/or static libraries
supported, static linking enforced, libquadmath needed, and so on), I
think the specific configuration must happen inside the offloading
execution path (mkoffload).  Thus, trying to do this inside the gfortran
front end, gcc/fortran/gfortranspec.c:lang_specific_driver etc., does not
appear to be doing it the right way; for offloaded code, we'll always be
using the lto1 front end instead of the gfortran one.  Is a libgfortran
link spec like libgomp's, together with some flag (similar to
-fopenmp/-fopenacc being used with the libgomp link spec) the right thing
to do?


Grüße,
 Thomas


signature.asc
Description: PGP signature

Re: Debugger support for __float128 type?

[Joseph Myers]

On Fri, 2 Oct 2015, Ulrich Weigand wrote:

> Joseph Myers wrote:
> > On Thu, 1 Oct 2015, Ulrich Weigand wrote:
> > 
> > > The _DecimalN types are already supported by DWARF using a base type with
> > > encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size.
> > 
> > Which doesn't actually say whether the DPD or BID encoding is used, but as 
> > long as each architecture uses only one that's not a problem in practice.
> 
> I see.  Well, one could add a DW_ATE_decimal_interchange_float for
> completeness, if necessary.

Since both DPD and BID are interchange encodings, that doesn't actually 
determine things without some way to say which was used (that is, both 
DW_ATE_decimal_float and DW_ATE_decimal_interchange_float would rely on 
platform-specific information to determine the format).  I don't know if 
DW_ATE_decimal_float is being used anywhere for something that's not an 
interchange format.

> The new DW_ATE_interchange_float encoding would say instead; this is
> a floating-point number of size N encoded as defined by the IEEE
> interchange format.
> 
> On platforms where the ABI-defined format actually *is* the interchange
> format, a DWARF producer would be free to use either DW_ATE_float or
> DW_ATE_interchange_float.  This decision could of course take into
> consideration compatibility requirements with older debuggers etc.
> 
> However, having two encoding definitions would allow platforms to use
> both the interchange format and one additional platform-defined
> non-interchange format of the same size, if needed.

That makes sense to me.

> As an alternative to specifying the well-defined interchange format,
> another option might be to simply add a second DWARF attribute,
> e.g. DW_AT_encoding_variant, to floating-point and related base types.
> This would simply be an integer with platform-specific semantics.
> So DWARF producers could simply describe a type as:
>   this is a floating-point number of size N encoded as defined by
>   platform ABI encoding variant #V

Do you want entirely platform-specific semantics?  Or would it be better 
to define standard values to mean it's an IEEE interchange format (or, for 
decimal floating point, to specify whether it's DPD or BID), plus space 
for future standard values and space for platform-specific values?

Would existing consumers safely ignore that attribute (so that producers 
could safely specify IEEE interchange encoding for float, double etc. if 
applicable, without breaking existing consumers)?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Debugger support for __float128 type?

[Ulrich Weigand]

Joseph Myers wrote:
> On Fri, 2 Oct 2015, Ulrich Weigand wrote:
> > I see.  Well, one could add a DW_ATE_decimal_interchange_float for
> > completeness, if necessary.
> 
> Since both DPD and BID are interchange encodings, that doesn't actually 
> determine things without some way to say which was used (that is, both 
> DW_ATE_decimal_float and DW_ATE_decimal_interchange_float would rely on 
> platform-specific information to determine the format).  I don't know if 
> DW_ATE_decimal_float is being used anywhere for something that's not an 
> interchange format.

Ah, yes.  I missed that both DPD and BID are defined as interchange
formats.  This suggestion doesn't make sense then ...

> > As an alternative to specifying the well-defined interchange format,
> > another option might be to simply add a second DWARF attribute,
> > e.g. DW_AT_encoding_variant, to floating-point and related base types.
> > This would simply be an integer with platform-specific semantics.
> > So DWARF producers could simply describe a type as:
> >   this is a floating-point number of size N encoded as defined by
> >   platform ABI encoding variant #V
> 
> Do you want entirely platform-specific semantics?  Or would it be better 
> to define standard values to mean it's an IEEE interchange format (or, for 
> decimal floating point, to specify whether it's DPD or BID), plus space 
> for future standard values and space for platform-specific values?

Hmm, I had been thinking of leaving that entirely platform-specific.
I guess one could indeed define some values with well-defined standard
semantics; that would assume DWARF would want to start getting into the
game of defining floating-point formats -- not sure what the position
of the committee would be on this question ...

[ Back when DW_ATE_decimal_float was added, the initial proposal did
indeed specify the encoding should follow IEEE-754R, but that was
removed when the proposal was actually added to the standard.  ]

> Would existing consumers safely ignore that attribute (so that producers 
> could safely specify IEEE interchange encoding for float, double etc. if 
> applicable, without breaking existing consumers)?

Yes, existing consumers should simply ignore attributes they are not
aware of.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Bug 66848 - boehm-gc fails test suite on x86_64-apple-darwin15

[Jack Howarth]

   Does anyone know which upstream boehm-gc release FSF gcc's copy was
last synchronized against? The system libunwinder.dylib (providing the
compatibility unwinder on darwin) has been recompiled, without source
changes, in OS X 10.11 El Capitan. This recompilation with the newer
Apple clang 7.0 compiler has broken the boehm-gc test suite on
darwin15...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848

as demonstrated by the fact that substituting the libunwind.dylib from
darwin14 on darwin15 eliminates the boehm-gc test suite failures.
Apple considers the optimization changes made by the Clang 7.0
compiler to the compatibility unwinder in libunwind.dylib to be safe
and believes that it tickles a latent bug in FSF gcc's boehm-gc.
 The upstream release for boehm-gc 7.2 through 7.4.2 all build
fine and pass their test suite on darwin15. Looking at the sources, it
seems that the current boehm-gc is based on upstream gc 7.1 or earlier
so perhaps updating the FSF gcc's boehm-gc to 7.2 or later may help
resolve this issue.
  Jack