Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Rainer Orth]

Hi Richard,

>> Now that mpc 1.1.0 was released we could update the versions if we get
>> sufficient
>> "positives" from people testing with newer releases.
>
> I've given it a try with that combo on sparc-sun-solaris2.10 (a primary
> target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results:
>
> * The gmp reuse test enters an infinite loop on 32-bit sparc.
>
> * The mpfr trint test FAILs on sparcv9.  The failure vanishes with
>   --disable-thread-safe.
>
> * Many mpfr tests FAIL on amd64.  Again, they vanish with
>   --disable-thread-safe.
>
> I have not yet tried building gcc with those versions yet.
>
> Beside, IMO we need to make sure that trunk and all open branches can be
> built with that version set; having to maintain two different sets isn't
> an option.

prompted by Ian's patch that needed mpfr 3.0.0+, I've now completed the
tests, with mpfr built with --disable-thread-safe to avoid most of the
failures above.  Bootstrapped mainline on i386-pc-solaris2.11 and
sparc-sun-solaris2.11, both 32 and 64-bit, and gcc-6 branch on
i386-pc-solaris2.10 and sparc-sun-solaris2.10.

No regressions in all cases, so the new versions are an option with the
proviso of prominently documenting the need for --disable-thread-safe
(or fixing the bugs in time ;-).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Matthias Klose]

On 17.01.2018 09:19, Richard Biener wrote:
> On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts  
> wrote:
>> Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0
>> snapshot, it still is working fine with 7.2.0.
>> I've added bug: 83903
>>
>> x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been building
>> with latest gmp (6.1.2), mpfr (4.0.0) and mpc (1.1.) across all my systems.
>>
>> I observe isl was updated to 0.18 in the download_prerequisites script. Are
>> the other's going to get updated before the 8.0.0 release?
> 
> Now that mpc 1.1.0 was released we could update the versions if we get
> sufficient
> "positives" from people testing with newer releases.

I have seen some issues with mpfr 4.0.0 on 32bit platforms, however not in GCC
itself yet.  These are all fixed in 4.0.1 rc2, so maybe document 4.0.1 instead
of 4.0.0 once it is released.

Matthias

[gcc plugin] get member offset in struct just like offsetof

[dotpy]

Hi experts,



I am writing a gcc plugin for parsing the structure fields. But I have the 
problem how to get the offset of each field in the struct? Just like the 
offsetof macro in gcc.

I see DECL_FIELD_OFFSET in tree.h, but the result seems not right.

My test program could be found in stack overflow:

https://stackoverflow.com/questions/48582971/gcc-plugin-to-implement-offsetof




Could someone explain what is DECL_FIELD_OFFSET used for, and how to implement 
offsetof?




Thanks

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 10:49:48 +0100, Matthias Klose wrote:
> I have seen some issues with mpfr 4.0.0 on 32bit platforms, however
> not in GCC itself yet. These are all fixed in 4.0.1 rc2, so maybe
> document 4.0.1 instead of 4.0.0 once it is released.

The issues were also present on 64-bit platforms and were due to
a bug in mpfr_div_ui, which has always been present, since 1999.
With MPFR 4.0.0, they are also visible with mpfr_div just because
mpfr_div now uses mpfr_div_ui in some simple cases. I don't think
that GCC could be affected because AFAIK, a failure can only occur
when the input and output precisions are different, or is this
possible with GCC?

Now, I've just found a "regression" when comparing Sipe results with
MPFR results, but it is the Sipe result with SIPE_FLOAT equal to 1
(float) or 2 (double) that is incorrect, 3 (long double) being OK.
Bug triggered with -O2 -march=native on an Intel Xeon E5-2609 v3
machine. At least from 4.9 to 8.0.1 20180124 [trunk revision 257009]
are affected. I'll try to find a simple test case for a bug report.
I suspect that the regression comes from the fact this is a new
machine + the use (as in the past) of -march=native.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:14:38 +0100, Vincent Lefevre wrote:
> Now, I've just found a "regression" when comparing Sipe results with
> MPFR results, but it is the Sipe result with SIPE_FLOAT equal to 1
> (float) or 2 (double) that is incorrect, 3 (long double) being OK.
> Bug triggered with -O2 -march=native on an Intel Xeon E5-2609 v3
> machine. At least from 4.9 to 8.0.1 20180124 [trunk revision 257009]
> are affected. I'll try to find a simple test case for a bug report.
> I suspect that the regression comes from the fact this is a new
> machine + the use (as in the past) of -march=native.

Well, if I add -std=c99 or -std=c11, the failure disappears. The
reason is that GCC generates a FMA (indeed, this new machine has
a FMA), but this occurs across different C statements. So, maybe
not a bug, but a bad feature, IMHO.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [gcc plugin] get member offset in struct just like offsetof

[Eric Botcazou]

> I am writing a gcc plugin for parsing the structure fields. But I have the
> problem how to get the offset of each field in the struct? Just like the
> offsetof macro in gcc.
> 
> I see DECL_FIELD_OFFSET in tree.h, but the result seems not right.

The offset in bits/bytes is given by tree.c:bit_position/byte_position.

-- 
Eric Botcazou

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Joseph Myers]

On Tue, 6 Feb 2018, Vincent Lefevre wrote:

> The issues were also present on 64-bit platforms and were due to
> a bug in mpfr_div_ui, which has always been present, since 1999.
> With MPFR 4.0.0, they are also visible with mpfr_div just because
> mpfr_div now uses mpfr_div_ui in some simple cases. I don't think
> that GCC could be affected because AFAIK, a failure can only occur
> when the input and output precisions are different, or is this
> possible with GCC?

GCC doesn't use mpfr_div at all; it uses MPFR to fold calls to a range of 
libm functions with constant arguments (input and output precisions should 
always be the same, since GCC doesn't yet support built-in functions for 
the TS 18661-1 narrowing functions such as fsqrtl), and for correctly 
rounding conversions of decimal strings to binary floating point.  The + - 
* / operations are handled directly in real.c without use of MPFR.  Of 
course MPFR functions called might use mpfr_div indirectly.

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

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Joseph Myers]

On Tue, 6 Feb 2018, Vincent Lefevre wrote:

> Well, if I add -std=c99 or -std=c11, the failure disappears. The
> reason is that GCC generates a FMA (indeed, this new machine has
> a FMA), but this occurs across different C statements. So, maybe
> not a bug, but a bad feature, IMHO.

Use -ffp-contract=off to disable all contraction, or -ffp-contract=on to 
disable it between statements (which currently actually disables all 
contraction, as the FMA generation doesn't know what was originally a 
single source expression).  The default in the absence of such -std 
options is -ffp-contract=fast (allowing contraction including between 
different statements).

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

GCC 8.0.0 status on x86_64-w64-mingw32, some issues

[Rainer Emrich]

Here's a short status report for trunk on x86_64-w64-mingw32 host.

I know this is only a secondary platform, but there are some serius issues.

Especially the ada part is in a bad shape compared to 7.3.0, see
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00439.html
and
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00308.html

At least 20 of the acats tests catch all memory until the host memory is 
exhausted.
Same holds for the two libstdc++ tests
23_containers/unordered_set/requirements/exception/basic.cc
and
23_containers/unordered_set/requirements/exception/propagation_consistent.cc

For gcc 8.0.0 I had to disable lto due to the recent changes.

A second headsup, bintuils 2.30 breaks bootstraping for x86_64-w64-mingw32.
I get ICEs for the stage 2 compiler when configuring libgcc in stage 2, see
https://gcc.gnu.org/ml/gcc/2018-02/msg00034.html

Rainer




signature.asc
Description: OpenPGP digital signature

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

[Jonathan Wakely]

On 6 February 2018 at 18:03, Rainer Emrich wrote:

> At least 20 of the acats tests catch all memory until the host memory is 
> exhausted.
> Same holds for the two libstdc++ tests
> 23_containers/unordered_set/requirements/exception/basic.cc
> and
> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc

Are these new failures? What changed? Where does it get stuck?

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:32:30 +, Joseph Myers wrote:
> GCC doesn't use mpfr_div at all; it uses MPFR to fold calls to a range of 
> libm functions with constant arguments (input and output precisions should 
> always be the same, since GCC doesn't yet support built-in functions for 
> the TS 18661-1 narrowing functions such as fsqrtl), and for correctly 
> rounding conversions of decimal strings to binary floating point.  The + - 
> * / operations are handled directly in real.c without use of MPFR.  Of 
> course MPFR functions called might use mpfr_div indirectly.

Yes, it might be possible to get an error via a call to mpfr_div
inside MPFR. And perhaps mpfr_div_ui too (with any MPFR version).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

[Eric Botcazou]

> Here's a short status report for trunk on x86_64-w64-mingw32 host.
> 
> I know this is only a secondary platform, but there are some serius issues.
> 
> Especially the ada part is in a bad shape compared to 7.3.0, see
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00439.html
> and
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00308.html
> 
> At least 20 of the acats tests catch all memory until the host memory is
> exhausted. Same holds for the two libstdc++ tests
> 23_containers/unordered_set/requirements/exception/basic.cc
> and
> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc

Does passing -fno-reorder-blocks-and-partition change anything?

-- 
Eric Botcazou

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:34:23 +, Joseph Myers wrote:
> Use -ffp-contract=off to disable all contraction, or -ffp-contract=on to 
> disable it between statements (which currently actually disables all 
> contraction, as the FMA generation doesn't know what was originally a 
> single source expression).  The default in the absence of such -std 
> options is -ffp-contract=fast (allowing contraction including between 
> different statements).

An environment variable to specify default GCC options would be very
useful. It is too easy to forget such an option.

Note: In the long term, -std=c99 or -std=c11 is better, as if one day,
GCC supports the STDC FP_CONTRACT pragma, contraction could be partly
enabled.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

gcc 7.3: Replacing global operator new/delete in shared libraries

[Paul Smith]

Hi all.

Hopefully this isn't too annoying a question :).

My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems.  We use a separate heap management library (jemalloc) rather
than the libc allocator.  The way we did this in the past was to
declare operator new/delete (all forms) as inline functions in a header
and ensure that this header was always the very first thing in every
source file, before even any standard header files.  I know that inline
operator new/delete isn't OK in the C++ standard, but in fact it has
worked for us on the systems we care about.

I'm attempting a toolchain upgrade which is switching to GCC 7.3 /
binutils 2.30 (along with many other updates).

Now when I run our code, I get a core on exit.  It appears an STL
container delete is invoking libc free() with a pointer to memory
allocated by jemalloc.

I suspect that between 6.2 and 7.3 something in the STL has been
modified to call new in a header file, so it's using our inline
operator new, but call the matching delete from inside libstdc++.a (we
link with static libstdc++ for portability), so it doesn't use our
inline operator delete.

While it's unfortunate for us, obviously that's a perfectly legal
implementation choice.  I don't know whether this is something the GCC
folks care about.  If so I can do more to track down the specifics.

If I create a real global operator new/delete, even keeping the inlined
versions, then the problem goes away (lending more weight to my guess
above).

I should point out that we don't use much STL memory so having some
compiled (not header-based) STL use the libc allocator is not a big
deal to us... it's just the mismatch which is a problem.

This leads to my question:

One of the things we provide is a shared library including much of our
code, and also jemalloc.  Users link this shared library with their
code and we do not want them to use our allocator.  By having all our
operator new/delete inlined we are sure that all our requests go to our
allocator and their requests do not.  It's a bit grungy, perhaps, but
it's worked well until now.

My question is, what do I need to do to ensure this behavior persists
if I create a global operator new/delete?

Is it sufficient to ensure that the symbol for our shared library
global new/delete symbols are hidden and not global, using a linker map
or -fvisibility=hidden?

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

[Rainer Emrich]

Am 06.02.2018 um 22:50 schrieb Eric Botcazou:
>> Here's a short status report for trunk on x86_64-w64-mingw32 host.
>>
>> I know this is only a secondary platform, but there are some serius issues.
>>
>> Especially the ada part is in a bad shape compared to 7.3.0, see
>> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00439.html
>> and
>> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00308.html
>>
>> At least 20 of the acats tests catch all memory until the host memory is
>> exhausted. Same holds for the two libstdc++ tests
>> 23_containers/unordered_set/requirements/exception/basic.cc
>> and
>> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc
> 
> Does passing -fno-reorder-blocks-and-partition change anything?
> 
Sorry for the stupid question. How do I pass this to the testsuite?



signature.asc
Description: OpenPGP digital signature

finding bugs deferred from previous releases

[Alexandre Oliva]

Hi,

In this round of GCC stabilization, I've noticed a larger than usual
number of bugs that carried over from earlier cycles, with notes
indicating it was too late to fix them during stabilization.

I wish we had some means to mark such bugs clearly, so that they could
be found easily earlier in the development cycles, instead of lingering
on until we find it's too late again.

Just targeting it to a future release might be enough during
stabilization, but later on, it will be hard to tell these cases apart
from other bugs for which we didn't make such assessment, and that could
in theory still be addressed during the next round of stabilization.

What I wish for is some means to find these bugs easily, while we're
earlier in a development cycle.  We could mark them as we go through the
current regressions list, so that others wouldn't look at them again in
this cycle, but could find them at any point in the next.

Just bumping the target milestone would address part of the problem: it
would help exclude it from bug lists that need fixing in this cycle.
However, it wouldn't help locate these bugs during the next cycle, since
at some point GCC8 will be out and the target milestone for all unfixed
bugs will be bumped.  Also, when we get to GCC9 stabilization, it would
be nice to have some means to defer again any bugs that, during the
earlier stabilization cycles, were deemed unfixable in the stabilization
phase, so as to defer them again.

Any thoughts on how to mark such bugs in bugzilla?

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: gdb 8.x - g++ 7.x compatibility

[Daniel Berlin]

As the person who, eons ago, wrote a bunch of the the GDB code for this C++
ABI support, and as someone who helped with DWARF support in both GDB and
GCC, let me try to propose a useful path forward (in the hopes that someone
will say "that's horrible, do it this  instead")

Here are the constraints i believe we are working with.

1. GDB should work with multiple DWARF producers and multiple C++ compilers
implementing the C++ ABI
2. There is no canonical demangled format for the C++ ABI
3. There is no canoncial target demangler you can say everyone should use
(and even if there was, you don't want to avoid debugging working because
someone chose not to)
4. You don't want to slow down GDB if you can avoid it
5. Despite them all implementation the same ABI, it's still possible to
distinguish the producers by the producer/compiler in the dwarf info.

Given all that:

GDB has ABI hooks that tell it what to do for various C++ ABIs. This is how
it knows to call the right demangler for gcc v3's abi vs gcc v2's abi. and
handle various differences between them.

See gdb/cp-abi.h

The IMHO, obvious thing to do here is: Handle the resulting demangler
differences with 1 or more new C++ ABI hooks.
Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use if
folks want it to be separate.

Once the producer is detected, fill in the hooks with a set of functions
that does the right thing.

I imagine this would also clean up a bundle of hacks in various parts of
gdb trying to handle these differences anyway (which is where a lot of the
multiple symbol lookups/etc that are often slow come from.
If we just detected and said "this is gcc 6, it behaves like this", we
wouldn't need to do that)

In case you are worried, you will discover this is how a bunch of stuff is
done and already contains a ball of hacks.

Using hooks would be, IMHO, a significant improvement.



On Mon, Feb 5, 2018 at 7:52 PM, Martin Sebor  wrote:

> On 02/05/2018 09:59 AM, Simon Marchi wrote:
>
>> On 2018-02-05 11:45, Martin Sebor wrote:
>>
>>> Yes, with auto, the type of the constant does determine the type
>>> of the specialization of the template in the source code.
>>>
>>> In non-type template arguments, and more to the point I was making,
>>> in diagnostics, the suffix shouldn't or doesn't need to be what
>>> distinguishes the type of the template, even with auto.  The part
>>> "with auto IVAL = 10" in the message
>>>
>>>   'void foo::print() [with auto IVAL = 10]':
>>>
>>> would be far clearer if auto were replaced by the deduced type,
>>> say along these lines:
>>>
>>>   'void foo::print() [with int IVAL = 10]':
>>>
>>> rather than relying on the suffix alone to distinguish between
>>> different specializations of the template.  That seems far too
>>> subtle to me.  But I think the diagnostic format is (or should
>>> be) independent of the debug info.
>>>
>>
>> That makes sense.
>>
>> With respect to the suffix, I keep coming back to the reality
>>> that even if GCC were to change to emit a format that GDB can
>>> interpret easily and efficiently, there still are other
>>> compilers that emit a different format.  So the conclusion
>>> that a general solution that handles more than just one format
>>> (at least for non-type template arguments without auto) seems
>>> unescapable.
>>>
>>
>> If there are other compilers we wanted to support for which we can't
>> trust the template format, we could always ignore the template part of
>> DW_AT_name specifically for them.  But since g++ and gdb are part of the
>> same project and are expected to work well and efficiently together, I
>> would have hoped that we could agree on a format so that gdb would not
>> have to do the extra work when parsing a g++-generated file
>> (consequently the same format that libiberty's demangler produces).
>>
>> Given the problem I illustrated in my previous mail, I don't have a
>> general solution to the problem to propose.
>>
>
> Okay, let me talk to Jason to see what he thinks.  I'm open
> to restoring the suffix for the debug info as long as it doesn't
> adversely affect the diagnostics.  I agree that if GCC can help
> make GDB more efficient it's worth putting effort into.  (I do
> still think that GDB should work with other providers besides
> GCC, even if perhaps not necessarily as efficiently.)
>
> Martin
>

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

[Eric Botcazou]

> Sorry for the stupid question. How do I pass this to the testsuite?

For ACATS it's a little awkward: you manually need to add it to the gccflags 
variable in gcc/testsuite/ada/acats/run_all.sh

-- 
Eric Botcazou