Re: Constraints and branching in -fanalyzer

[David Malcolm via Gcc]

On Fri, 2021-02-26 at 04:23 +, brian.sobulefsky wrote:
> Hi,
> 
> I have implemented the discussed change, bootstrapped, and run the
> testsuite. I
> would be submitting except to my disappointment I saw failures
> increase by 4. As
> it turns out, these "failures" are actually passes that had been
> marked "xfail"
> and "TRUE" "desired" in the testsuite. The items in question are in
> testsuite
> files gcc.dg/analyzer/operations.c and params.c. In particular
> operations.c
> is only partially fixed because, as I have described, I thus far have
> only added
> cases for PLUS and MINUS. As you can see in that test file, you have
> some tests
> involving multiplication and division. My question is, before
> bothering to
> submit would you like me to just add handlers for these? I guess it
> will save us
> a patch cycle.

Can you post what you have so far?

It's easier for me to understand a patch by looking at the patch,
rather than a description of a patch, if that makes sense.

Is the issue that doing a full bootstrap&test cycle is too slow?  If so
I'm fine with you posting preliminary patches for discussion if you're
upfront about the ones that haven't been through a full bootstrap&test
run.  Also, would it help if you had access to the GCC compiler farm? 
There are some very fast machines there.

(that said, I'm meant to be taking a day off today so I ought to sign
off for now)

Dave

> Also, your comment regarding overflows is well taken, but I think we
> should fix
> the overall problem first, then worry about the overflow corner case.
> 
> Brian
> 

printers.py issue

[Hoyer, David via Gcc]

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

We are noticing some problems using GDB with printers.py

Problem 1:  the function find_type was changed such that search now uses 
typ.unqualified() instead of typ.name.   In the case of a class, the former 
prepends class to the search string so that when it runs 
gdb.lookup_type(search), it does not find the definition.   If I switch it back 
to typ.name, this function works

Problem 2:  We are seeing an error in strip_versioned_namespace

  File 
"/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", 
line 668, in __init__
  self.typename = strip_versioned_namespace(typename)
  File 
"/usr/lib/x86_64-linux-gnu/../../share/gcc-8/python/libstdcxx/v6/printers.py", 
line 114, in strip_versioned_namespace
return typename.replace(_versioned_namespace, '')
AttributeError: 'gdb.Type' object has no attribute 'replace'
Error occurred in Python command: 'gdb.Type' object has no attribute 'replace'


David Hoyer
Controller Firmware Development
E-Series Storage Group

NetApp
3718 N. Rock Road
Wichita, KS 67226
316-636-8047 phone
316-617-3677 mobile
david.ho...@netapp.com
netapp.com

 [http://media.netapp.com/images/netapp-logo-sig-5.gif]

Re: printers.py issue

[Jonathan Wakely via Gcc]

On Fri, 26 Feb 2021, 21:59 Hoyer, David via Gcc,  wrote:

> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
> --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-8
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --enable-default-pie --with-system-zlib --with-target-system-zlib
> --enable-objc-gc=auto --enable-multiarch --disable-werror
> --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
> --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
> --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 8.3.0 (Debian 8.3.0-6)
>
> We are noticing some problems using GDB with printers.py
>

This belongs on the libstdc++ list, CC'd.

Which version of GDB are you using, and which version of Python does it use?



>
>

RE: printers.py issue

[Hoyer, David via Gcc]

Thank you for redirecting to the correct group!

Requested version information:
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Python 3.7.3

From: Jonathan Wakely 
Sent: Friday, February 26, 2021 4:27 PM
To: Hoyer, David 
Cc: gcc@gcc.gnu.org; libstdc++ 
Subject: Re: printers.py issue

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



On Fri, 26 Feb 2021, 21:59 Hoyer, David via Gcc, 
mailto:gcc@gcc.gnu.org>> wrote:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

We are noticing some problems using GDB with printers.py

This belongs on the libstdc++ list, CC'd.

Which version of GDB are you using, and which version of Python does it use?

gcc-9-20210226 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210226 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210226/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision 2259e712a6348bd23586dde06cc874a35fdc53c3

You'll find:

 gcc-9-20210226.tar.xzComplete GCC

  SHA256=c1298f1d107b6e3b156b8ae63cc18f3e81fddaf0df2ddde5eacf11a86c6f0947
  SHA1=06071aff4440c701e73bc49065641174b9c04e3a

Diffs from 9-20210219 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

bison -y overrides YACC in Make-lang.in

[James K. Lowden]

Using https://thinkingeek.com/gcc-tiny/ as a model, I've begun adding a
new language to gcc.  I'm having trouble controlling how Bison is
invoked. 

In my Make-lang.in, I have 

YACC = bison
YFLAGS = -Werror --debug --verbose

but when I build, I see bison invoked on my .y file as

$ bison -y -Werror --debug --verbose

Where did that "-y" come from?  The documentation 

https://gcc.gnu.org/onlinedocs/gccint/Front-End-Makefile.html#Front-End-Makefile

says: 

"It contains targets lang.hook ... and any
 other Makefile rules required to build those targets"

It doesn't say I can't use YACC = bison 

This was under the radar until an upgraded bison began flagging
 %empty as non-posix.

The observed behavior looked to me to be in error.  How is the
language-specific directory supposed to control the value of YACC?  

--jkl

Re: Constraints and branching in -fanalyzer

[brian.sobulefsky via Gcc]

I'll send it. It is not too slow. I just figured I would try to fix the others
but I get that it is easier for you to see changes in steps.


Brian


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, February 26, 2021 8:36 AM, David Malcolm  wrote:

> On Fri, 2021-02-26 at 04:23 +, brian.sobulefsky wrote:
>
> > Hi,
> > I have implemented the discussed change, bootstrapped, and run the
> > testsuite. I
> > would be submitting except to my disappointment I saw failures
> > increase by 4. As
> > it turns out, these "failures" are actually passes that had been
> > marked "xfail"
> > and "TRUE" "desired" in the testsuite. The items in question are in
> > testsuite
> > files gcc.dg/analyzer/operations.c and params.c. In particular
> > operations.c
> > is only partially fixed because, as I have described, I thus far have
> > only added
> > cases for PLUS and MINUS. As you can see in that test file, you have
> > some tests
> > involving multiplication and division. My question is, before
> > bothering to
> > submit would you like me to just add handlers for these? I guess it
> > will save us
> > a patch cycle.
>
> Can you post what you have so far?
>
> It's easier for me to understand a patch by looking at the patch,
> rather than a description of a patch, if that makes sense.
>
> Is the issue that doing a full bootstrap&test cycle is too slow? If so
> I'm fine with you posting preliminary patches for discussion if you're
> upfront about the ones that haven't been through a full bootstrap&test
> run. Also, would it help if you had access to the GCC compiler farm?
> There are some very fast machines there.
>
> (that said, I'm meant to be taking a day off today so I ought to sign
> off for now)
>
> Dave
>
> > Also, your comment regarding overflows is well taken, but I think we
> > should fix
> > the overall problem first, then worry about the overflow corner case.
> > Brian