Re: Spam, bounces and gcc list removal

[Winfried Magerl]

Hello Maciej,

On Sat, Mar 21, 2020 at 09:22:31PM +, Maciej W. Rozycki wrote:
[..]
>  Spam bouncing is evil and often hits an innocent person
[..]

others like me might see it different:
Spam discarding is evil and often hits an innocent person.

Silently discarding a legal mail because of false spam-detection is
the worst case for the sender. But this is OffTopic.

regards

winfried

Re: dejagnu version update?

[Winfried Magerl]

Hi,

On Fri, Aug 25, 2017 at 09:55:29AM -0400, David Edelsohn wrote:
> On Fri, Aug 25, 2017 at 9:50 AM, Rainer Orth
>  wrote:
> > Hi H.J.,
> >
> >> On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
> >>> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
>  On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  
>  wrote:
> > FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
> > Testsuite uses "unsetenv" in multiple instances and that feature has
> > been removed from DejaGNU.  The testsuite is going to experience
> > DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
> > DejaGNU in the 1.6 series.
> >
> 
>  I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
>  look for?
> >>>
> >>> ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
> >>> The error code is NONE
> >>> The info on the error is:
> >>> invalid command name "unsetenv"
> >>> while executing
> >>> "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
> >>> ("uplevel" body line 1)
> >>> invoked from within
> >>> "uplevel 1 ::tcl_unknown $args"
> >>>
> >>
> >> I checked my log.  I didn't see them.  Which log file do they appear in?
> >
> > unsetenv was only removed after DejaGnu 1.6 was released.  The change is
> > in the git repo; so far there exists no post-1.6 release.
> 
> That is why I wrote 1.6.1.  I didn't know if 1.6-2 was from snapshot after 
> 1.6.
> 
> Future releases of DejaGNU will elicit errors from the GCC Testsuite
> as currently written.  My message is a warning about future
> incompatibility.

from the current git-branch:

 +Changes since 1.6:
 +
 +1. The user-visible utility procedure `unsetenv' has been removed.  If
 +   a testsuite uses any of these procedures, a copy of the procedure
 +   should be made and placed in the lib directory of the testsuite.
 +

gcc is not the only testsuite which breaks. From a quick look on
some of my local source-packages:

 Python-2.7.13
 Python-3.6.2
 libffi-3.2.1
 gcc-7.2.0

Maybe reporting this to the dejagnu-developers might be the better
approach:

author   Ben Elliston  2016-04-24 20:46:53 +1000
committer Ben Elliston  2016-04-24 20:46:53 +1000
commit   c7185dfb66b0b278709d869ba020eec8348796ef (patch)

regards

winfried

Re: bootstrap broken for '-O3'

[Winfried Magerl]

On Sun, Jan 19, 2014 at 07:39:12PM +0100, Winfried Magerl wrote:
 Hi,
 
 since trunk revision 206525 I'm unable to bootstrap
 gcc with '-O3' as optimisation. No problem until
 revision 2065250.
 
 From the diff-output it looks like this entry from
 ChangeLog is the only candidate:
 
 ---
 diff -urN -x.svn gcc-head-206520/LAST_UPDATED gcc-head-206525/LAST_UPDATED
 --- gcc-head-206520/LAST_UPDATED2014-01-19 17:54:07.053340903 +0100
 +++ gcc-head-206525/LAST_UPDATED2014-01-19 18:58:54.049008110 +0100
 @@ -1,2 +1,2 @@
 -Sun Jan 19 17:54:07 CET 2014
 -Sun Jan 19 16:54:07 UTC 2014 (revision 206520)
 +Sun Jan 19 18:58:54 CET 2014
 +Sun Jan 19 17:58:54 UTC 2014 (revision 206525)
 diff -urN -x.svn gcc-head-206520/gcc/ChangeLog gcc-head-206525/gcc/ChangeLog
 --- gcc-head-206520/gcc/ChangeLog   2014-01-19 17:54:03.620441749 +0100
 +++ gcc-head-206525/gcc/ChangeLog   2014-01-19 18:58:51.113097157 +0100
 @@ -1,3 +1,15 @@
 +2014-01-10  Richard Biener  rguent...@suse.de
 +
 +   PR tree-optimization/59374
 +   * tree-vect-slp.c (vect_slp_analyze_bb_1): Move dependence
 +   checking after SLP discovery.  Mark stmts not participating
 +   in any SLP instance properly.
 +
 +2014-01-10  Kyrylo Tkachov  kyrylo.tkac...@arm.com
 +
 +   * config/arm/arm.c (arm_new_rtx_costs): Use destination mode
 +   when handling a SET rtx.
 +
  2014-01-10  Kyrylo Tkachov  kyrylo.tkac...@arm.com
 
 * config/arm/arm-cores.def (cortex-a53): Specify FL_CRC32.
 ---
 
 gcc is built with the following commands:
 
 ---
 CFLAGS=-O3; export CFLAGS
 CXXFLAGS=$CFLAGS; export CXXFLAGS
 CFLAGS=$CFLAGS CXXFLAGS=$CFLAGS XCFLAGS=$CFLAGS TCFLAGS=$CFLAGS \
 ../gcc-head-206525/configure --enable-shared --prefix=/usr 
 --enable-multilib=no --enable-checking=release --enable-werror=no 
 --enable-languages='c,c++'  configure.out
 make -j6 BOOT_CFLAGS=-O3  make.out || exit 1
 ---
 
 and results in the following error:
 
 --
 # make compare
 Comparing stages 2 and 3
 warning: gcc/cc1-checksum.o differs
 warning: gcc/cc1plus-checksum.o differs
 Bootstrap comparison failure!
 gcc/bitmap.o differs
 gcc/bt-load.o differs
 gcc/emit-rtl.o differs
 libiberty/pic/md5.o differs
 libiberty/md5.o differs
 Makefile:20642: recipe for target 'compare' failed
 make: *** [compare] Error 1
 --
 
 I've verified the behaviour on opensuse 13.1 too to ensure
 it's not caused by local tool-chain.

reverting the patch for tree-vect-slp.c fixes the build with -O3
for current trunk (revision 206934).

I've verified this on openSUSE 13.1 (x86_64).

regards

winfried

bootstrap broken for '-O3'

[Winfried Magerl]

High,

since trunk revision 206525 I'm unable to bootstrap
gcc with '-O3' as optimisation. No problem until
revision 2065250.

From the diff-output it looks like this entry from
ChangeLog is the only candidate:

---
diff -urN -x.svn gcc-head-206520/LAST_UPDATED gcc-head-206525/LAST_UPDATED
--- gcc-head-206520/LAST_UPDATED2014-01-19 17:54:07.053340903 +0100
+++ gcc-head-206525/LAST_UPDATED2014-01-19 18:58:54.049008110 +0100
@@ -1,2 +1,2 @@
-Sun Jan 19 17:54:07 CET 2014
-Sun Jan 19 16:54:07 UTC 2014 (revision 206520)
+Sun Jan 19 18:58:54 CET 2014
+Sun Jan 19 17:58:54 UTC 2014 (revision 206525)
diff -urN -x.svn gcc-head-206520/gcc/ChangeLog gcc-head-206525/gcc/ChangeLog
--- gcc-head-206520/gcc/ChangeLog   2014-01-19 17:54:03.620441749 +0100
+++ gcc-head-206525/gcc/ChangeLog   2014-01-19 18:58:51.113097157 +0100
@@ -1,3 +1,15 @@
+2014-01-10  Richard Biener  rguent...@suse.de
+
+   PR tree-optimization/59374
+   * tree-vect-slp.c (vect_slp_analyze_bb_1): Move dependence
+   checking after SLP discovery.  Mark stmts not participating
+   in any SLP instance properly.
+
+2014-01-10  Kyrylo Tkachov  kyrylo.tkac...@arm.com
+
+   * config/arm/arm.c (arm_new_rtx_costs): Use destination mode
+   when handling a SET rtx.
+
 2014-01-10  Kyrylo Tkachov  kyrylo.tkac...@arm.com

* config/arm/arm-cores.def (cortex-a53): Specify FL_CRC32.
---

gcc is built with the following commands:

---
CFLAGS=-O3; export CFLAGS
CXXFLAGS=$CFLAGS; export CXXFLAGS
CFLAGS=$CFLAGS CXXFLAGS=$CFLAGS XCFLAGS=$CFLAGS TCFLAGS=$CFLAGS \
../gcc-head-206525/configure --enable-shared --prefix=/usr --enable-multilib=no 
--enable-checking=release --enable-werror=no --enable-languages='c,c++'  
configure.out
make -j6 BOOT_CFLAGS=-O3  make.out || exit 1
---

and results in the following error:

--
# make compare
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/bitmap.o differs
gcc/bt-load.o differs
gcc/emit-rtl.o differs
libiberty/pic/md5.o differs
libiberty/md5.o differs
Makefile:20642: recipe for target 'compare' failed
make: *** [compare] Error 1
--

I've verified the behaviour on opensuse 13.1 too to ensure
it's not caused by local tool-chain.

regards

winfried

gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18

[Winfried Magerl]

Hi,

I've tried to compile upcoming glibc-2.18 with gcc-4.8.x and optimized
with '-O3' and testsuite breaks horrible with SIGSEGV and eating up
all available memory.

I've tracked it down to the flag 'tree-loop-distribute-patterns' and can
reproduce the problem with CFLAGS='-g -O2 -ftree-loop-distribute-patterns'
on my own system and on clean openSUSE 12.3 (x86_64) with gcc-4.8.1-20130519.

System:
AMD FX(tm)-6300 Six-Core Processor (fam: 15, model: 02, stepping: 00)
linux-3.9.3
gcc (GCC) 4.8.1 20130519
binutils-2.23.52.0.2

glibc-repository is from 20130519.

I've done some more checks on the first failing test 'csu/tst-atomic' which
is the second test in the test-suite:

env GCONV_PATH=/home/winfried/glibc-cvs/winni/iconvdata LC_ALL=C   
/home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2 --library-path 
/home/winfried/glibc-cvs/winni:/home/winfried/glibc-cvs/winni/math:/home/winfried/glibc-cvs/winni/elf:/home/winfried/glibc-cvs/winni/dlfcn:/home/winfried/glibc-cvs/winni/nss:/home/winfried/glibc-cvs/winni/nis:/home/winfried/glibc-cvs/winni/rt:/home/winfried/glibc-cvs/winni/resolv:/home/winfried/glibc-cvs/winni/crypt:/home/winfried/glibc-cvs/winni/nptl
 /home/winfried/glibc-cvs/winni/csu/tst-atomic

gdb-output:
# gdb /home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2 core
[.]
Reading symbols from 
/home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2...done.
warning: core file may not match specified executable file.
[New LWP 28667]
Core was generated by `/home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2 
--library-path /home/wi'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f92a16785c4 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=6) at ../string/memset.c:81
81while (len  0)
(gdb) where
#0  0x7f92a16785c4 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=6) at ../string/memset.c:81
#1  0x7f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=optimized out) at ../string/memset.c:81
#2  0x7f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=optimized out) at ../string/memset.c:81
#3  0x7f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=optimized out) at ../string/memset.c:81
[.]
#75638 0x7f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=optimized out) at ../string/memset.c:81
#75639 0x7f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=optimized out) at ../string/memset.c:81
#75640 0x7f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=optimized out, 
len=optimized out) at ../string/memset.c:81
[.]

some more notes:
- no problem with '-O3' and glibc-2.17
- no problem with gcc-4.7.3 and glibc-2.18
- CFLAGS for test-suite doesn't matter

I send this mail to gcc@gcc.gnu.org and libc-al...@sourceware.org because
it's not obvious if it's a bug in glibc or in gcc.
I can help with testing but I'm not realy able to track this problem
down.

regards

winfried

Re: gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18

[Winfried Magerl]

Hi,

On Mon, May 20, 2013 at 09:40:52AM -0300, Adhemerval Zanella wrote:
 Hi,
 
 Thanks for reporting it, I saw it too when building glibc with gcc-trunk.
 Carlos O'Donell already reported it could be an issue to glibc at
 http://sourceware.org/ml/libc-alpha/2013-02/msg00299.html and I also noted
 it causes PTL issues too at 
 http://sourceware.org/ml/libc-alpha/2013-04/msg00124.html
 I have proposed a patch 
 http://sourceware.org/ml/libc-alpha/2013-04/msg00196.html
 so configure can check if compiler transform loops into libc functions calls, 
 but
 Andreas Jaeger and Roland McGrath didn't approve the approach.
 
 Although, the problem persist and I think we need to figure out how to 
 proceed 
 before 2.18 release. Based on the loader memset recursion call you observe I 
 do
 suggest to use my approach and add '-fno-tree-loop-distribute-patterns' on
 rtld-memset.os object.
 
 Any comments?

tree-loop-distribute-patterns is enabled on gcc-4.7.3 with -O3:

# /usr/gcc47/bin/gcc --version
gcc (GCC) 4.7.3
[]
# /usr/gcc47/bin/gcc -c -Q -O3 --help=optimizers | fgrep 
tree-loop-distribute-patterns
  -ftree-loop-distribute-patterns   [enabled]

And it looks like it's the default for a long time:

# fgrep OPT_ftree_loop_distribute_patterns gcc-*/gcc/opts.c
gcc-4.6.3/gcc/opts.c:{ OPT_LEVELS_3_PLUS, 
OPT_ftree_loop_distribute_patterns, NULL, 1 },
gcc-4.7.0/gcc/opts.c:{ OPT_LEVELS_3_PLUS, 
OPT_ftree_loop_distribute_patterns, NULL, 1 },
gcc-4.7.1/gcc/opts.c:{ OPT_LEVELS_3_PLUS, 
OPT_ftree_loop_distribute_patterns, NULL, 1 },
gcc-4.7.2/gcc/opts.c:{ OPT_LEVELS_3_PLUS, 
OPT_ftree_loop_distribute_patterns, NULL, 1 },
gcc-4.7.3/gcc/opts.c:{ OPT_LEVELS_3_PLUS, 
OPT_ftree_loop_distribute_patterns, NULL, 1 },
gcc-4.8.0/gcc/opts.c:{ OPT_LEVELS_3_PLUS, 
OPT_ftree_loop_distribute_patterns, NULL, 1 },

I wonder what's the difference between gcc-4.7.3 and gcc-4.8.x for
'tree-loop-distribute-patterns' 

regards

winfried

Re: increasing testsuite-errors when optimizing for amdfam10/bdver2

[Winfried Magerl]

Hi,

looks like XOP/FAM4/FAM is responsible for the additional errors I
see when running gcc-testsuite or glibc-testsuite. I've opened Bug
56866 as a starting point, so the subject is a little bit misleading:

Bug 56866 - gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles 
glibc-2.17/crypt/sha512.c

Disabling XOP/FAM4/FAM shows no regression (compared with amdfam10) with
glibc-testsuite and no additional execution-errors in the gcc-testsuite.

Currently I'm running gcc-4.8-branch configured ith '--with-arch=bdver2'
and with a simple patch disabling XOP/FAM4/FAM for bdver2 in
gcc/config/i386/i386.c.

regards

winfried

On Mon, Apr 01, 2013 at 08:44:59PM +0200, winfried.mag...@t-online.de wrote:
 Hi,
 
 replacing my AMD Phenom2 with a AMD Piledriver (Bulldozer Version2)
 was reason enough for me to recompile gcc (and the whole linux-system)
 with hard optimisation set to bdver2 (as I've done since my first
 linux on an 68030).
 But this time an increasing number of errors makes me a little bit nervous
 and after some additional errors when running the glibc-2.17-testsuite
 I've refused to use this optimisation as default on my system.
 
 The results might be interesting for the gcc-developer-community and I've
 mailed four results with different set of '--with-arch' and '--with-tune'
 to gcc-testresu...@gcc.gnu.org from stock gcc-4.8.0.
 I've set '--build=x86_64-winnix-linux-gnu' just to make it easier to search
 the archive for this specific results (results include the complete set
 of relevant libs/tools).
 
 Basic flags for every compile/test-run:
 
 --build=x86_64-winnix-linux-gnu --enable-languages=c,c++ --enable-shared 
 --prefix=/usr --enable-multilib=no
 
 optimization for phenom2 (I've used since I've replaced
 my Athlon-FX):
 --with-arch=amdfam10 --with-tune=amdfam10
 
 soft-optimization for bdver2 which is the current configuration
 I use on my system (no additional errors in glibc-2.17:
 --with-arch=amdfam10 --with-tune=bdver2
 
 optimization for bdver2:
 --with-arch=bdver2 --with-tune=bdver2
 
 The number of additional errors is always increasing. Mostly errors
 in scan-assembler and scan-tree-dump (maybe wrong expections in the
 tests?) but with arch=bdver2 I see an increasing number of
 execution-tests failing.
 
 Surprisingly (at least for me) the difference is only visible in the
 gcc-testsuite and doesn't harm other languages.
 
 I've done some work to ensure errors are not related to the system-setup
 and maybe it's of interest what I've learned during this process:
 
 gcc.dg/guality/vla-1.c and vla-2.c depends on the gdb-version. Fails
 with stock gdb-7.5.1 (also tested prerelease gdb-7.5.91) and don't
 fail with gdb-patches from opensuse (fedora-patches works also).
 Using tcl8.6.0 as base for expect/dejagnu doesn't currently work,
 at least not with the gcc-testsuite.
 
 Please note that this is not a regression and that gcc-4.7.x gives
 very similar results.
 
 Thank you for listening and all the good work I apreciate since
 20 years with all sorts of cpu's and operating-systems gcc
 supports!
 
 best regards
 
 winfried
 

increasing testsuite-errors when optimizing for amdfam10/bdver2

[winfried . magerl]

Hi,

replacing my AMD Phenom2 with a AMD Piledriver (Bulldozer Version2)
was reason enough for me to recompile gcc (and the whole linux-system)
with hard optimisation set to bdver2 (as I've done since my first
linux on an 68030).
But this time an increasing number of errors makes me a little bit nervous
and after some additional errors when running the glibc-2.17-testsuite
I've refused to use this optimisation as default on my system.

The results might be interesting for the gcc-developer-community and I've
mailed four results with different set of '--with-arch' and '--with-tune'
to gcc-testresu...@gcc.gnu.org from stock gcc-4.8.0.
I've set '--build=x86_64-winnix-linux-gnu' just to make it easier to search
the archive for this specific results (results include the complete set
of relevant libs/tools).

Basic flags for every compile/test-run:

--build=x86_64-winnix-linux-gnu --enable-languages=c,c++ --enable-shared 
--prefix=/usr --enable-multilib=no

optimization for phenom2 (I've used since I've replaced
my Athlon-FX):
--with-arch=amdfam10 --with-tune=amdfam10

soft-optimization for bdver2 which is the current configuration
I use on my system (no additional errors in glibc-2.17:
--with-arch=amdfam10 --with-tune=bdver2

optimization for bdver2:
--with-arch=bdver2 --with-tune=bdver2

The number of additional errors is always increasing. Mostly errors
in scan-assembler and scan-tree-dump (maybe wrong expections in the
tests?) but with arch=bdver2 I see an increasing number of
execution-tests failing.

Surprisingly (at least for me) the difference is only visible in the
gcc-testsuite and doesn't harm other languages.

I've done some work to ensure errors are not related to the system-setup
and maybe it's of interest what I've learned during this process:

gcc.dg/guality/vla-1.c and vla-2.c depends on the gdb-version. Fails
with stock gdb-7.5.1 (also tested prerelease gdb-7.5.91) and don't
fail with gdb-patches from opensuse (fedora-patches works also).
Using tcl8.6.0 as base for expect/dejagnu doesn't currently work,
at least not with the gcc-testsuite.

Please note that this is not a regression and that gcc-4.7.x gives
very similar results.

Thank you for listening and all the good work I apreciate since
20 years with all sorts of cpu's and operating-systems gcc
supports!

best regards

winfried