I couldn't compile gdb with python 3.6 so I filled an upstream issue to protect the HAVE_LONG_LONG definition (as gdb defines it as well), which is in Python 3.6.0 final that currently resides in rawhide.

Relevant issue: http://bugs.python.org/issue28898

This seems to be a different issue though. I guess the gcc defines HAVE_LONG_LONG but it does not protect it against redefinition?

The people I requested a needinfo might provide us some insight here.

Python itself doesn't use HAVE_LONG_LONG (it doesn't work on platforms without the type), but, for backwards compatibility, it defines the macro if undefined.

A possible workaround could be to `#define HAVE_LONG_LONG 1` *before* including the Python headers, or to #undefine it just after.

Even if I undefine HAVE_LONG_LONG after including Python.h, the build fails.

Will attach build.log

Created attachment 1236911 [details]
Build.log when adding `#undef HAVE_LONG_LONG` after `#include <Python.h>`

Um, did a file get corrupted in that build?

gcc-python-tree.c:2:4: error: 'Copyright' does not name a type
    Copyright 2011-2015 David Malcolm <dmalcolm>
    ^~~~~~~~~

Oh, my bad. Sorry, will try again.

Created attachment 1236947 [details]
Workaround of this issue

So I've managed to workaround this issue by adding `#undef HAVE_LONG_LONG` after `#include <Python.h>`.

Since there are tests that check line numbers in gcc errors of autogenerated C files and the workaround adds an extra line, I disabled those tests for now, because adding workarounds for workarounds was going too deep.

Added a comment to remember to re-enable those tests once a proper fix is introduced.

All worked in mock, so I've tried Koji scratch build. It failed on ppc64le (I think with unrelated issue).

Dist-git commit patch attached.

https://koji.fedoraproject.org/koji/taskinfo?taskID=17157941

As for proper fix I think one of the following is needed:

 * guarded HAVE_LONG_LONG definition in /usr/lib/gcc/x86_64-redhat-linux/6.3.1/plugin/include/auto-host.h
 * don't define HAVE_LONG_LONG in Python.h or undefine it at the end (might possibly break other stuff)

ppc64 failed as well

(In reply to Charalampos Stratakis from comment #1)
> I couldn't compile gdb with python 3.6 so I filled an upstream issue to
> protect the HAVE_LONG_LONG definition (as gdb defines it as well), which is
> in Python 3.6.0 final that currently resides in rawhide.
> 
> Relevant issue: http://bugs.python.org/issue28898
> 
> This seems to be a different issue though. I guess the gcc defines
> HAVE_LONG_LONG but it does not protect it against redefinition?

Thanks.  Looking at that upstream bug, I see:

  [cherrypicked for 3.6.0rc2]

so it looks like this was fixed in that release of CPython:

  https://hg.python.org/cpython/rev/d6c8803c55b4/

Do we have that patch in our builds on Python 3?

(In reply to Miro Hrončok from comment #9)
> ppc64 failed as well

Looks like some of the testsuite failed within %check:

Specifically, ppc64le and ppc64 both show one unexpected failure:
  tests/cpychecker/absinterp/bitfields/reading: FAIL

due to int vs char issues.

(In reply to Dave Malcolm from comment #11)
> (In reply to Miro Hrončok from comment #9)
> > ppc64 failed as well
> 
> Looks like some of the testsuite failed within %check:
> 
> Specifically, ppc64le and ppc64 both show one unexpected failure:
>   tests/cpychecker/absinterp/bitfields/reading: FAIL
> 
> due to int vs char issues.

The question is: Is that expected and can the test be safely changed on those arches? I'd say yes, but would like some confirmation.

Trying a Koji scratch build with:

  %ifarch ppc64 ppc64p7 ppc64le
  # see https://bugzilla.redhat.com/show_bug.cgi?id=1409009#c11
  sed -i 's/(unsigned char)/(unsigned int)/g' tests/cpychecker/absinterp/bitfields/reading/stdout.txt
  %endif

https://koji.fedoraproject.org/koji/taskinfo?taskID=17159245

(In reply to Miro Hrončok from comment #13)
> Trying a Koji scratch build with:
> 
>   %ifarch ppc64 ppc64p7 ppc64le
>   # see https://bugzilla.redhat.com/show_bug.cgi?id=1409009#c11
>   sed -i 's/(unsigned char)/(unsigned int)/g'
> tests/cpychecker/absinterp/bitfields/reading/stdout.txt
>   %endif
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=17159245

Apparently, not enough.

Created attachment 1237053 [details]
Workaround of this issue

Here is another (more staightforward) attempt to workaround the HAVE_LONG_LONG issue. It just adds `-D HAVE_LONG_LONG=1` to CFLAGS.

It builds and the affected tests from previous attempt are not affected here, so no need to disable them all as before.

However, those test fail on python3-debug with:

  #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]

(The entire line was `gcc -o /tmp/tmp0y9lkyj1/example.cpython-36dm-x86_64-linux-gnu.so -I/usr/include/python3.6dm -I/usr/include/python3.6dm -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O0 -Wall -Werror -fPIC -shared -fplugin=/builddir/build/BUILD/gcc-python-plugin-0.15-building-for-python3_debug/python3_debug.so -fplugin-arg-python3_debug-script=cpychecker.py -fno-diagnostics-show-caret /tmp/tmp0y9lkyj1/example.c`. Notice that `-O*` is used multiple times.)

So I've disabled them on python3-debug for now. Since they were disabled anyway in the previous attempt I think this patch is better and making it obsolete the previous one.

(This is unrelated to the ppc error, that remains there.)

Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=17159421

(In reply to Dave Malcolm from comment #10)
> (In reply to Charalampos Stratakis from comment #1)
> > I couldn't compile gdb with python 3.6 so I filled an upstream issue to
> > protect the HAVE_LONG_LONG definition (as gdb defines it as well), which is
> > in Python 3.6.0 final that currently resides in rawhide.
> > 
> > Relevant issue: http://bugs.python.org/issue28898
> > 
> > This seems to be a different issue though. I guess the gcc defines
> > HAVE_LONG_LONG but it does not protect it against redefinition?
> 
> Thanks.  Looking at that upstream bug, I see:
> 
>   [cherrypicked for 3.6.0rc2]
> 
> so it looks like this was fixed in that release of CPython:
> 
>   https://hg.python.org/cpython/rev/d6c8803c55b4/
> 
> Do we have that patch in our builds on Python 3?

Yep, our build is the 3.6.0 final which includes this fix

The macro definition was fixed upstream; the fix should appear in Python 3.6.1.

https://hg.python.org/cpython/rev/fad67c66885f
http://bugs.python.org/issue27961

Even though gcc-plugin is the only thing in Fedora that hit this, I think we should backport it in Python.

(In reply to Petr Viktorin from comment #17)
> The macro definition was fixed upstream; the fix should appear in Python
> 3.6.1.
> 
> https://hg.python.org/cpython/rev/fad67c66885f
> http://bugs.python.org/issue27961
> 
> Even though gcc-plugin is the only thing in Fedora that hit this, I think we
> should backport it in Python.

Just backported the fix in rawhide at python3-3.6.0-4.fc26 build, so the HAVE_LONg_LONG definition shouldn't be a problem anymore.

The competing HAVE_LONG_LONG definitions have been fixed.

The issue as it seems is that when the test for reading from a bitfield [0] is invoked then as we can see at the expected output [1], an unsigned int is expected for Trace 0, 3 and 4 [2].

This holds True for all the platforms except the ppc ones where an unsigned int is returned (or sent to the stdout).

[0] https://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/tests/cpychecker/absinterp/bitfields/reading/input.c

[1] https://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/tests/cpychecker/absinterp/bitfields/reading/stdout.txt

[2] when considering value == (unsigned char)

So I used Miro's patch to skip the tests when being invoked with the python3-debug, and also I added an extra patch to skip this one test case that fails on ppc, for the time being.

I, uh, well, that's a way to fix it, sure =)

maybe file a bug upstream or mention it to the ppc64 team? it sounds a lot like a big-endian bug they'd want to get fixed.

(In reply to Adam Williamson from comment #21)
> I, uh, well, that's a way to fix it, sure =)
> 
> maybe file a bug upstream or mention it to the ppc64 team? it sounds a lot
> like a big-endian bug they'd want to get fixed.

gcc-python-plugin is not really maintained anymore upstream. I will file a bugzilla for the ppc64 tracker though, if someone wants to tackle that issue.

(In reply to Charalampos Stratakis from comment #22)
> (In reply to Adam Williamson from comment #21)
> > I, uh, well, that's a way to fix it, sure =)
> > 
> > maybe file a bug upstream or mention it to the ppc64 team? it sounds a lot
> > like a big-endian bug they'd want to get fixed.

It's not so much a bug in the code as a bug in the tests.  When I wrote the test suite I fell into the trap of the "gold output" anti-pattern.  Rewriting the test suite to work in a saner way is lower priority than my gcc work, so it's unlikely I'll ever do it.

> gcc-python-plugin is not really maintained anymore upstream. I will file a
> bugzilla for the ppc64 tracker though, if someone wants to tackle that issue.

It's, err,  pining for the fjords.   I do a release about once a year, when the a gcc comes out.

(In reply to Dave Malcolm from comment #23)
[...]
> It's, err,  pining for the fjords.   I do a release about once a year, when
> the a gcc comes out.

s/a gcc/new release of gcc/

Oh, and thanks for fixing this Charalampos.

I see, thanks guys! Sounds like there's nothing to worry about.