Re: [patch] Streamline debug info for up-level references

[Eric Botcazou]

> Looks good to me.  Rather than removing dwarf2/pr37726.c can you try
> turning that into a guality test that verifies the debug experience is the
> same (or better) than before?  I realize guality stuff is fragile but you
> can restrict it to -O0 if you like (not sure if dg-skip-if supports that).

Yes, it does, I have attached the final testcase.  It passes with e.g. the 
system debugger on OpenSuSE Leap 42.3.


* gcc.dg/debug/dwarf2/pr37726.c: Move to...
* gcc.dg/guality/pr37726.c: ...here and turn into GDB test.

-- 
Eric Botcazou/* PR debug/37726 */
/* { dg-do run } */
/* { dg-options "-g" } */
/* { dg-skip-if "" { *-*-* }  { "*" } { "-O0" } } */

int foo (int parm)
{
  int var = 0;
  int bar (void)
  {
return parm + var; /* BREAK */
  }
  parm++;  /* BREAK */
  var++;
  return bar ();
}

int
main (void)
{
  return foo (4) - 6;
}

/* { dg-final { gdb-test 11 "parm" "5" } } */
/* { dg-final { gdb-test 11 "var"  "1" } } */
/* { dg-final { gdb-test 13 "parm" "4" } } */
/* { dg-final { gdb-test 13 "var"  "0" } } */

Re: RFC: What should go in our header?

[Ed Smith-Rowland]

On 06/15/2018 11:52 AM, Jonathan Wakely wrote:

C++20 adds a  header, which should define all the library
feature test macros, as well as implementation-specific macros like
_GLIBCXX_RELEASE and __GLIBCXX__.

We should decide whether to implement  by simply including
 and then adding the feature test macros, or if we
should keep it minimal and *only* define _GLIBCXX_RELEASE and
__GLIBCXX__ and the feature tests (and then have 
include ?)

I think I prefer to make  just include .

I think we should define the feature-test macros in both  and
the relevant header (e.g. __cpp_string_view in ). We
could make everything include  and then every header would
define every feature test macro, but I don't think that's good for
portability.

My preference is implemented by the attached patch.


This is pretty much what I was looking at doing.  I say go!


While on the subject, should we just delete some of this autoconf-junk
from our c++config.h headers?

/* Name of package */
/* #undef _GLIBCXX_PACKAGE */

/* Define to the address where bug reports for this package should be 
sent. */

#define _GLIBCXX_PACKAGE_BUGREPORT ""

/* Define to the full name of this package. */
#define _GLIBCXX_PACKAGE_NAME "package-unused"

/* Define to the full name and version of this package. */
#define _GLIBCXX_PACKAGE_STRING "package-unused version-unused"

/* Define to the one symbol short name of this package. */
#define _GLIBCXX_PACKAGE_TARNAME "libstdc++"

/* Define to the home page for this package. */
#define _GLIBCXX_PACKAGE_URL ""

/* Define to the version of this package. */
#define _GLIBCXX_PACKAGE__GLIBCXX_VERSION "version-unused"

I don't have an opinion here except if this is unused cruft let's lose 
it.  I think we *are* supposed to have some project and version 
identification.  We have _GLIBCXX_* everywhere.  The folks that use 
libstdc++ *outside* of g++ might have some opinions about this too.


Ed

Re: [PATCH][ARM] Use __ARM_ARCH instead of __ARM_ARCH__

[Christophe Lyon]

On Fri, 15 Jun 2018 at 17:22, Richard Earnshaw (lists)
 wrote:
>
> On 15/06/18 15:30, Christophe Lyon wrote:
> > Hello,
> >
> > As suggested in [1], the attached patch removes all definitions and
> > uses of __ARM_ARCH__ and uses __ARM_ARCH instead. The later is indeed
> > defined by the preprocessor to the appropriate value.
> >
> > I ran make check on arm-none-eabi (with A-profile multilib),
> > arm-none-linux-gnueabi, arm-none-linux-gnueabihf (with cortex-a9, a15,
> > a5, a57 and armtdmi as --with-cpu), armeb-none-linux-gnueabihf and
> > armv8l-linux-gnueabihf, and noticed no regression.
> >
> > OK for trunk?
> >
> > Thanks,
> >
> > Christophe
> >
> > [1] https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00445.html
> >
> >
> > ARM_ARCH.chlog.txt
> >
> >
> > libatomic/ChangeLog:
> >
> > 2018-06-15  Christophe Lyon  
> >
> >   * config/arm/arm-config.h (__ARM_ARCH__): Remove definitions, use
> >   __ARM_ARCH instead.
> >
> > libgcc/ChangeLog:
> >
> > 2018-06-15  Christophe Lyon  
> >
> >   * config/arm/lib1funcs.S (__ARM_ARCH__): Remove definitions, use
> >   __ARM_ARCH instead.
> >   * config/arm/ieee754-df.S: Use __ARM_ARCH instead of __ARM_ARCH__.
> >   * config/arm/ieee754-sf.S: Likewise.
> >   * config/arm/libunwind.S: Likewise.
> >
> >
> > ARM_ARCH.patch.txt
> >
>
> Thanks, this is a useful start.  We can, however, go further.  ACLE
> defines a number of 'feature' pre-defines and we can use those to void
> direct tests of the architecture version directly.  For example,
> __ARM_FEATURE_LDREX could directly replace having to calculate
> HAVE_STREX and HAVE_STREXBHD.
>
Hi,

Here is an updated patch using __ARM_FEATURE_LDREX.
I didn't find other opportunities to use ACLE pre-defines, did I miss any?

Thanks,

Christophe

> From a quick look it looks like the only one we can't really support
> with the new tests is the check for DMB.  I'll have a chat with the ACLE
> maintainers about that...
>
> R.
>
> >
> > diff --git a/libatomic/config/arm/arm-config.h 
> > b/libatomic/config/arm/arm-config.h
> > index c0504be..ce8ff0e 100644
> > --- a/libatomic/config/arm/arm-config.h
> > +++ b/libatomic/config/arm/arm-config.h
> > @@ -23,57 +23,15 @@
> > .  */
> >
> >
> > -#if defined(__ARM_ARCH_2__)
> > -# define __ARM_ARCH__ 2
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_3__)
> > -# define __ARM_ARCH__ 3
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_3M__) || defined(__ARM_ARCH_4__) \
> > - || defined(__ARM_ARCH_4T__)
> > -/* We use __ARM_ARCH__ set to 4 here, but in reality it's any processor 
> > with
> > -   long multiply instructions.  That includes v3M.  */
> > -# define __ARM_ARCH__ 4
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_5__) || defined(__ARM_ARCH_5T__) \
> > - || defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__) \
> > - || defined(__ARM_ARCH_5TEJ__)
> > -# define __ARM_ARCH__ 5
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) \
> > - || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6Z__) \
> > - || defined(__ARM_ARCH_6ZK__) || defined(__ARM_ARCH_6T2__) \
> > - || defined(__ARM_ARCH_6M__)
> > -# define __ARM_ARCH__ 6
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) \
> > - || defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) \
> > - || defined(__ARM_ARCH_7EM__)
> > -# define __ARM_ARCH__ 7
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_8A__)
> > -# define __ARM_ARCH__ 8
> > -#endif
> > -
> > -#ifndef __ARM_ARCH__
> > -#error Unable to determine architecture.
> > -#endif
> > -
> > -#if __ARM_ARCH__ >= 7 || defined(__ARM_ARCH_6K__) || 
> > defined(__ARM_ARCH_6ZK__)
> > +#if __ARM_ARCH >= 7 || defined(__ARM_ARCH_6K__) || 
> > defined(__ARM_ARCH_6ZK__)
> >  # define HAVE_STREX  1
> >  # define HAVE_STREXBHD   1
> > -#elif __ARM_ARCH__ == 6
> > +#elif __ARM_ARCH == 6
> >  # define HAVE_STREX  1
> >  #endif
> >
> > -#if __ARM_ARCH__ >= 7
> > +#if __ARM_ARCH >= 7
> >  # define HAVE_DMB1
> > -#elif __ARM_ARCH__ == 6
> > +#elif __ARM_ARCH == 6
> >  # define HAVE_DMB_MCR1
> >  #endif
> > diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
> > index 04c1b77..264d54a 100644
> > --- a/libgcc/config/arm/lib1funcs.S
> > +++ b/libgcc/config/arm/lib1funcs.S
> > @@ -74,49 +74,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
> >  If not, see
> >
> >  /* Function end macros.  Variants for interworking.  */
> >
> > -#if defined(__ARM_ARCH_2__)
> > -# define __ARM_ARCH__ 2
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_3__)
> > -# define __ARM_ARCH__ 3
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_3M__) || defined(__ARM_ARCH_4__) \
> > - || defined(__ARM_ARCH_4T__)
> > -/* We use __ARM_ARCH__ set to 4 here, but in reality it's any processor 
> > with
> > -   long multiply instructions.  That includes v3M.  */
> > -# define __ARM_ARCH__ 4
> > -#endif
> > -
> > -#if defined(__ARM_ARCH_5__) || defined(__ARM_ARCH_5

Re: [PATCH, alpha] PR target/85095

[coypu]

Ping.
Anything else to do for this?

Thanks.

Re: Incremental LTO linking part 2: lto-plugin support

[Sandra Loosemore]

On 05/08/2018 09:14 AM, Jan Hubicka wrote:

Hi,
with lto, incremental linking can be meaninfuly done in three ways:
  1) read LTO file and produce non-LTO .o file
 this is current behaviour of gcc -r or ld -r with plugin
  2) read LTO files and merge section for later LTO
 this is current behaviour of ld -r w/o plugin
  3) read LTO files into the compiler, link them and produce
 incrementaly linked LTO object.

3 makes most sense and I am maing it new default for gcc -r. For testing 
purposes
and perhaps in order to have tool to turn LTO object into real object, we want
to have 1) available as well.  GCC currently have -flinker-output option that
decides between modes that is decided by linker plugin and can be overwritten
by user (I have forgot to document this).

I am targeting for -flinker-output=rel to be incremental linking into LTO
and adding -flinker-output=nolto-rel for 1).

The main limitation of 2 and 3 is that you can not link LTO and non-LTO
object files theger.  For 2 HJ's binutils patchset has support and I think
it can be extended to handle 3 as well. But with default binutils we want
to warn users.  This patch implements the warning (and prevents linker plugin
to add redundat linker-ouptut options.


This patch seems to have caused a lot of LTO tests in the G++ testsuite 
to fail on bare-metal targets because of the new warning.  Here's a list 
for arm-none-eabi:


FAIL: g++.dg/lto/20091002-1 cp_lto_20091002-1_0.o-cp_lto_20091002-1_0.o 
link, -fPIC -flto -Wno-return-type
FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, 
-O3 -flto
FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, 
-flto -std=c++11
FAIL: g++.dg/lto/pr65193 cp_lto_pr65193_0.o-cp_lto_pr65193_0.o link, 
-fPIC -r -nostdlib -flto -O2 -g -Wno-return-type
FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, 
-flto -O0 -std=c++11
FAIL: g++.dg/lto/pr65302 cp_lto_pr65302_0.o-cp_lto_pr65302_1.o link, 
-flto -O2 -Wno-return-type
FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o-cp_lto_pr65316_1.o link, 
-flto -std=c++11 -g2 -fno-lto-odr-type-merging -O2 -Wno-return-type
FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, 
-std=gnu++14 -flto -g -Wno-return-type
FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, 
-std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type
FAIL: g++.dg/lto/pr66180 cp_lto_pr66180_0.o-cp_lto_pr66180_1.o link, 
-flto -std=c++14 -r -nostdlib
FAIL: g++.dg/lto/pr66705 cp_lto_pr66705_0.o-cp_lto_pr66705_0.o link, 
-O2 -flto -flto-partition=max -fipa-pta
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 
-flto -flto-partition=none -fuse-linker-plugin
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 
-flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 
-flto -fuse-linker-plugin -fno-fat-lto-objects
FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 
-flto -fuse-linker-plugin
FAIL: g++.dg/lto/pr69077 cp_lto_pr69077_0.o-cp_lto_pr69077_1.o link, 
-O3 -g -flto
FAIL: g++.dg/lto/pr69133 cp_lto_pr69133_0.o-cp_lto_pr69133_1.o link, 
-flto -O2
FAIL: g++.dg/lto/pr69137 cp_lto_pr69137_0.o-cp_lto_pr69137_0.o link, 
-std=c++11 -g -flto
FAIL: g++.dg/lto/pr79000 cp_lto_pr79000_0.o-cp_lto_pr79000_1.o link, 
-flto -g
FAIL: g++.dg/lto/pr81940 cp_lto_pr81940_0.o-cp_lto_pr81940_0.o link,  -O 
-flto
FAIL: g++.dg/lto/pr85176 cp_lto_pr85176_0.o-cp_lto_pr85176_0.o link, 
-flto -g1


I got a similar list on the csky-elf port I'm preparing for submission, 
but I didn't see any of these FAILs for csky-linux-gnu.  LTO is a 
mysterious black box to me, but maybe it has something to do with 
linking with static vs shared libraries?  Or some linker script issue? 
I see part 8 of this patch series touched a whole bunch of other test 
cases, but not these.


-Sandra