Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bleadperl v5.25.6-90-g3619505 breaks SMUELLER/XS-TCC-0.04.tar.gz #15701

Closed
p5pRT opened this issue Nov 8, 2016 · 10 comments
Closed

Bleadperl v5.25.6-90-g3619505 breaks SMUELLER/XS-TCC-0.04.tar.gz #15701

p5pRT opened this issue Nov 8, 2016 · 10 comments
Labels
BBC Blead Breaks CPAN - changes in blead broke a cpan module(s) distro-All type-core

Comments

@p5pRT
Copy link

p5pRT commented Nov 8, 2016

Migrated from rt.perl.org#130046 (status was 'resolved')

Searchable as RT130046$

@p5pRT
Copy link
Author

p5pRT commented Nov 8, 2016

From @dcollinsn

Greetings. The above commit seems to break XS​::TCC v0.04, due to the
following errors​:

tcc​: error​: undefined symbol '__builtin_expect' at t/10_lowlevel.t line 82.
tcc​: error​: undefined symbol '__builtin_expect' at t/30_inline.t line 24.

Bisect​:

cpanbisect@​digitalis​:~/perl$ perl Porting/bisect.pl --module=XS​::TCC
--start=11a12be --end=fe546b3 -Dusedevel -DDEBUGGING -Dusethreads
...
<SNIP>
...
3619505 is the first bad commit
commit 3619505
Author​: Karl Williamson <khw@​cpan.org>
Date​: Tue Oct 25 10​:47​:23 2016 -0600

  Add branch predictors for DEBUG statements

  It is unlikely that any given debug flag will be set in any given run,
  even under DEBUGGING builds.

:100644 100644 b43ae90e1282fa980c9f15d39bddd3ecc6a22e8c
accc628c3b76cc392ad4cdbfbc3a9f50fdce98d0 M perl.h
bisect run success
That took 3342 seconds.

Perl -V included in the attached CPAN Testers reports (which are not
uploaded yet, since I'm still working through this run.)

--
Dan

@p5pRT
Copy link
Author

p5pRT commented Nov 8, 2016

@p5pRT
Copy link
Author

p5pRT commented Nov 8, 2016

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2016

From @jkeenan

On Tue, 08 Nov 2016 01​:48​:18 GMT, dcollinsn@​gmail.com wrote​:

Greetings. The above commit seems to break XS​::TCC v0.04, due to the
following errors​:

tcc​: error​: undefined symbol '__builtin_expect' at t/10_lowlevel.t line 82.
tcc​: error​: undefined symbol '__builtin_expect' at t/30_inline.t line 24.

Bisect​:

cpanbisect@​digitalis​:~/perl$ perl Porting/bisect.pl --module=XS​::TCC
--start=11a12be --end=fe546b3 -Dusedevel -DDEBUGGING -Dusethreads
...
<SNIP>
...
3619505 is the first bad commit
commit 3619505
Author​: Karl Williamson <khw@​cpan.org>
Date​: Tue Oct 25 10​:47​:23 2016 -0600

Add branch predictors for DEBUG statements

It is unlikely that any given debug flag will be set in any given run\,
even under DEBUGGING builds\.

:100644 100644 b43ae90e1282fa980c9f15d39bddd3ecc6a22e8c
accc628c3b76cc392ad4cdbfbc3a9f50fdce98d0 M perl.h
bisect run success
That took 3342 seconds.

Perl -V included in the attached CPAN Testers reports (which are not
uploaded yet, since I'm still working through this run.)

--
Dan

What is puzzling about these failures is that *most* of the smoke testing runs on this platform after the commit indicated via bisection have gotten PASS. See​: http​://matrix.cpantesters.org/?dist=XS-TCC;os=linux;perl=5.25.7;reports=1#sl=1,1

On the other hand, configuring in a way very similar to the way Dan Collins did in http​://www.cpantesters.org/cpan/report/c08895d8-a65f-11e6-932a-f4415c96acb4 (now, a month-and-a-half ago), I was able to reproduce the same test failures.

The documentation for XS-TCC states​: "This is a highly experimental module. Use at your own risk. Get in touch with the author(s) if in doubt." So perhaps that's what we have to do here.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2016

From @jkeenan

On Mon, 26 Dec 2016 00​:57​:50 GMT, jkeenan wrote​:

On Tue, 08 Nov 2016 01​:48​:18 GMT, dcollinsn@​gmail.com wrote​:

Greetings. The above commit seems to break XS​::TCC v0.04, due to the
following errors​:

tcc​: error​: undefined symbol '__builtin_expect' at t/10_lowlevel.t
line 82.
tcc​: error​: undefined symbol '__builtin_expect' at t/30_inline.t line
24.

Bisect​:

cpanbisect@​digitalis​:~/perl$ perl Porting/bisect.pl --module=XS​::TCC
--start=11a12be --end=fe546b3 -Dusedevel -DDEBUGGING -Dusethreads
...
<SNIP>
...
3619505 is the first bad commit
commit 3619505
Author​: Karl Williamson <khw@​cpan.org>
Date​: Tue Oct 25 10​:47​:23 2016 -0600

Add branch predictors for DEBUG statements

It is unlikely that any given debug flag will be set in any given
run,
even under DEBUGGING builds.

:100644 100644 b43ae90e1282fa980c9f15d39bddd3ecc6a22e8c
accc628c3b76cc392ad4cdbfbc3a9f50fdce98d0 M perl.h
bisect run success
That took 3342 seconds.

Perl -V included in the attached CPAN Testers reports (which are not
uploaded yet, since I'm still working through this run.)

--
Dan

What is puzzling about these failures is that *most* of the smoke
testing runs on this platform after the commit indicated via bisection
have gotten PASS. See​: http​://matrix.cpantesters.org/?dist=XS-
TCC;os=linux;perl=5.25.7;reports=1#sl=1,1

On the other hand, configuring in a way very similar to the way Dan
Collins did in http​://www.cpantesters.org/cpan/report/c08895d8-a65f-
11e6-932a-f4415c96acb4 (now, a month-and-a-half ago), I was able to
reproduce the same test failures.

More specifically, I got the "undefined symbol '__builtin_expect'" failures when I configured with -DDEBUGGING​:

#####
$ diff install_debugging_threaded_blead_for_testing.sh install_threaded_blead_for_testing.sh
14c14
< ./Configure -des -Dusedevel -Dusethreads -Uversiononly -Dprefix=${BLEADDIR} -Dman1dir=none -Dman3dir=none -DDEBUGGING


./Configure -des -Dusedevel -Dusethreads -Uversiononly -Dprefix=${BLEADDIR} -Dman1dir=none -Dman3dir=none
#####

When I dropped '-DDEBUGGING' from the config args, all tests in XS-TCC PASSed.

So something's problematic about -DDEBUGGING.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2016

From dcmertens.perl@gmail.com

Hello James,

Quick answer​: in this case it's probably easiest for Steffen to just
#define __builtin_expect in his xs files.

Long answer​: This is an error thrown by the Tiny C Compiler as it tries to
compile the Perl header files using a configuration generated assuming gcc.
I have worked a lot trying to get the Tiny C Compiler to interface nicely
with Perl, though my efforts have been directed at C​::Blocks. There are two
interleaved problems here. First, gcc was used at the configure stage when
building Perl, and at that time some compiler-specific switches get turned
on. Second, tcc is so similar to tcc that it is not worth the effort of
re-running or emulating a configure script when setting up modules like
XS​::TCC. It is easier to just borrow settings from Config.pm with a couple
of manual modifications.

Two gccisms that Perl uses (if configure indicates that it can) include
__builtin_expect and brace groups. With C​::Blocks, I have worked around
__builtin_expect by tweaking my fork of tcc (though a preprocessor macro
should also fix it). I have fixed issues with brace groups by scrubbing
-DDEBUGGING and -DDEBIAN from the compiler arguments. (Presumably adding
-DPERL_GCC_BRACE_GROUPS_FORBIDDEN should fix this issue, but it did not
work for me.) See
https://github.com/run4flat/C-Blocks/blob/master/lib/C/Blocks/PerlAPI.xs.PL#L80

I hope that provides enough context for the situation. It would be very
nice if ExtUtils;​:Embed or some other tool could generate a Perl
configuration consistent with the currently compiled perl that does not
include the gcc-isms, but that is a wishlist item, not a bug. I would say
this is an issue with XS​::TCC.

@​Stephen, if you like, I can try to look into this and figure out a pull
request for XS​::TCC. If you know exactly where this needs to get fixed, it
may be faster for you to do it.

I hope that helps!
David

On Sun, Dec 25, 2016 at 8​:07 PM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

On Mon, 26 Dec 2016 00​:57​:50 GMT, jkeenan wrote​:

On Tue, 08 Nov 2016 01​:48​:18 GMT, dcollinsn@​gmail.com wrote​:

Greetings. The above commit seems to break XS​::TCC v0.04, due to the
following errors​:

tcc​: error​: undefined symbol '__builtin_expect' at t/10_lowlevel.t
line 82.
tcc​: error​: undefined symbol '__builtin_expect' at t/30_inline.t line
24.

Bisect​:

cpanbisect@​digitalis​:~/perl$ perl Porting/bisect.pl --module=XS​::TCC
--start=11a12be --end=fe546b3 -Dusedevel -DDEBUGGING -Dusethreads
...
<SNIP>
...
3619505 is the first bad commit
commit 3619505
Author​: Karl Williamson <khw@​cpan.org>
Date​: Tue Oct 25 10​:47​:23 2016 -0600

Add branch predictors for DEBUG statements

It is unlikely that any given debug flag will be set in any given
run,
even under DEBUGGING builds.

:100644 100644 b43ae90e1282fa980c9f15d39bddd3ecc6a22e8c
accc628c3b76cc392ad4cdbfbc3a9f50fdce98d0 M perl.h
bisect run success
That took 3342 seconds.

Perl -V included in the attached CPAN Testers reports (which are not
uploaded yet, since I'm still working through this run.)

--
Dan

What is puzzling about these failures is that *most* of the smoke
testing runs on this platform after the commit indicated via bisection
have gotten PASS. See​: http​://matrix.cpantesters.org/?dist=XS-
TCC;os=linux;perl=5.25.7;reports=1#sl=1,1

On the other hand, configuring in a way very similar to the way Dan
Collins did in http​://www.cpantesters.org/cpan/report/c08895d8-a65f-
11e6-932a-f4415c96acb4 (now, a month-and-a-half ago), I was able to
reproduce the same test failures.

More specifically, I got the "undefined symbol '__builtin_expect'"
failures when I configured with -DDEBUGGING​:

#####
$ diff install_debugging_threaded_blead_for_testing.sh
install_threaded_blead_for_testing.sh
14c14
< ./Configure -des -Dusedevel -Dusethreads -Uversiononly
-Dprefix=${BLEADDIR} -Dman1dir=none -Dman3dir=none -DDEBUGGING
---

./Configure -des -Dusedevel -Dusethreads -Uversiononly
-Dprefix=${BLEADDIR} -Dman1dir=none -Dman3dir=none
#####

When I dropped '-DDEBUGGING' from the config args, all tests in XS-TCC
PASSed.

So something's problematic about -DDEBUGGING.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130046

--
"Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2016

From @jkeenan

On Mon, 26 Dec 2016 02​:55​:19 GMT, run4flat wrote​:

Hello James,

Quick answer​: in this case it's probably easiest for Steffen to just
#define __builtin_expect in his xs files.

Long answer​: This is an error thrown by the Tiny C Compiler as it
tries to
compile the Perl header files using a configuration generated assuming
gcc.
I have worked a lot trying to get the Tiny C Compiler to interface
nicely
with Perl, though my efforts have been directed at C​::Blocks. There
are two
interleaved problems here. First, gcc was used at the configure stage
when
building Perl, and at that time some compiler-specific switches get
turned
on. Second, tcc is so similar to tcc that it is not worth the effort
of
re-running or emulating a configure script when setting up modules
like
XS​::TCC. It is easier to just borrow settings from Config.pm with a
couple
of manual modifications.

Two gccisms that Perl uses (if configure indicates that it can)
include
__builtin_expect and brace groups. With C​::Blocks, I have worked
around
__builtin_expect by tweaking my fork of tcc (though a preprocessor
macro
should also fix it). I have fixed issues with brace groups by
scrubbing
-DDEBUGGING and -DDEBIAN from the compiler arguments. (Presumably
adding
-DPERL_GCC_BRACE_GROUPS_FORBIDDEN should fix this issue, but it did
not
work for me.) See
https://github.com/run4flat/C-
Blocks/blob/master/lib/C/Blocks/PerlAPI.xs.PL#L80

I hope that provides enough context for the situation. It would be
very
nice if ExtUtils;​:Embed or some other tool could generate a Perl
configuration consistent with the currently compiled perl that does
not
include the gcc-isms, but that is a wishlist item, not a bug. I would
say
this is an issue with XS​::TCC.

@​Stephen, if you like, I can try to look into this and figure out a
pull
request for XS​::TCC. If you know exactly where this needs to get
fixed, it
may be faster for you to do it.

I hope that helps!
David

Thanks, David. On the basis of your explanation, there is no bug in perl. So I'm closing this ticket.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2016

@jkeenan - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Dec 26, 2016
@p5pRT
Copy link
Author

p5pRT commented Dec 27, 2016

From mail@steffen-mueller.net

Hi David,

thank you for your, once again, friendly, helpful, and thorough email. :)

@​p5p​: This is clearly a problem for the module, not perl.

On 12/26/2016 03​:54 AM, David Mertens wrote​:
[snip explanation of the issue]

@​Stephen, if you like, I can try to look into this and figure out a pull
request for XS​::TCC. If you know exactly where this needs to get fixed,
it may be faster for you to do it.

I have another 20 minutes of battery left and need to head to bed anyway
so I get some sleep before the first of the kids wakes up. I'll try to
cook up a patch in that time, but I doubt with building a copy blead,
that'll do. I'd be very grateful if you could give it a shot. The right
place for this would be in the C code string in TCC.pm.

Thank you and best regards,
Steffen

@p5pRT p5pRT added BBC Blead Breaks CPAN - changes in blead broke a cpan module(s) Severity Low distro-All type-core labels Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BBC Blead Breaks CPAN - changes in blead broke a cpan module(s) distro-All type-core
Projects
None yet
Development

No branches or pull requests

1 participant