Ticket #1930 (new bug)

Opened 4 years ago

Last modified 3 years ago

t/op/number.t: one test fails under --optimize on Darwin/PPC

Reported by: jkeenan Owned by:
Priority: minor Milestone:
Component: testing Version: master
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: darwin

Description

Configuring with:

perl Configure.pl --optimize

on Darwin/PPC, I got the following test failure, which I do not get when I configure without optimization:

t/op/number.t .. 
1..126
...
not ok 50 - mod_n
# Have: -0
# Want: 0

Note: I have rarely configured with --optimize on this platform, so I don't know whether this test failure has always been there or when it appeared. (I was working on a different ticket where I needed to see what difference --optimize made in %PConfig.)

Given what some would consider the antiquity of this platform, this is hardly a deal-breaker. Still, a bug is a bug, and it would be worthwhile if someone could speculate on why optimization made this bug manifest and how it might be fixed.

Thank you very much.

kid51

Attachments

parrot_config.dump Download (17.3 KB) - added by jkeenan 3 years ago.

Change History

  Changed 4 years ago by jkeenan

I have been getting a slightly different failure on this test file today. I configured with cc=g++. Normally, I configure with cc=gcc, while using g++ for cxx, link, ld. I also configured with --optimize, which translated into -O3 because that's apparently what my Perl 5 had.

321:  'optimize' => '-O3',
322:  'optimize_provisional' => '-O3',

This was the output I got:

t/op/number.t ............................... Failed 1/126 subtests 
...
t/op/number.t                             (Wstat: 0 Tests: 126 Failed: 1)
  Failed test:  50

When I tried to use prove, this is what I got:

$ prove -v t/op/number.t 
t/op/number.t .. dyld: Library not loaded: /usr/local/lib/libparrot.dylib
  Referenced from: /Users/jimk/gitwork/parrot/./parrot
  Reason: image not found
No subtests run 

Test Summary Report
-------------------
t/op/number.t (Wstat: 5 Tests: 0 Failed: 0)
  Non-zero wait status: 5
  Parse errors: No plan found in TAP output

This is puzzling. When I say something like prove t/dynoplibs/*.t or prove t/dynpmc/*.t, I get dyld: Library not loaded: /usr/local/lib/libparrot.dylib, apparently because when prove runs these files certain .mak files are not included, whereas make dynpmc_tests and make dynoplibs_tests do the right thing.

But I wouldn't expect this kind of dynamic linking problem to show up in something in t/op/.

I reconfigured with g++ but without --optimize and all tests passed as expected. So this is clearly a problem with --optimize.

By the way, here is the problematic test:

.sub test_mod_n
...
    set     $N0, 0.0
    set     $N1, 3.0
    mod     $N2, $N0, $N1
    is( $N2, "0", 'mod_n' )

Suggestions?

Thank you very much.

kid51

follow-up: ↓ 3   Changed 4 years ago by jkeenan

I should say that this appears to be two problems:

1. the test failure in t/op/number.t which occurs with --optimize.

2. I get the dynamic linking failure message when I run prove on any of the files in t/op/. I don't understand why that is so.

kid51

in reply to: ↑ 2   Changed 3 years ago by jkeenan

Replying to jkeenan:

I should say that this appears to be two problems: 1. the test failure in t/op/number.t which occurs with --optimize.

Apropos of the issues involved in the generational_gc branch over the last two days (see TT #2005), I should add that I got this failure in t/op/number.t in master at both (a) a commit which reflects the gen_gc merge, e.g., 77b57cc; and (b) a commit which reflects the reversion of the gen_gc merge, e.g., 8ae02700. So the failure in the mod_n test is independent of gen_gc issues.

Thank you very much.

kid51

follow-up: ↓ 5   Changed 3 years ago by dukeleto

Can you reproduce this on a recent version of Parrot? Also, please provide the full output of g++ --version and parrot_config --dump .

I think this should just be TODOed for this platform, in the meanwhile.

in reply to: ↑ 4   Changed 3 years ago by jkeenan

Replying to dukeleto:

Can you reproduce this on a recent version of Parrot? Also, please provide the full output of g++ --version and parrot_config --dump .

 $ grep -nE "'(optimize|cc|link|ld)" lib/Parrot/Config/Generated.pm  # edited
82:  'cc' => '/usr/bin/gcc',
274:  'ld' => '/usr/bin/g++',
292:  'link' => '/usr/bin/g++',
324:  'optimize' => '-O3',

With the exception of optimize, this is how I have configured on this machine since late 2006.

$ cat ~/learn/parrot/gcc.darwin.ppc.version.txt  # edited
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)

$ cat ~/learn/parrot/g++.darwin.ppc.version.txt 
powerpc-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Copyright (C) 2005 Free Software Foundation, Inc.
$ git show | head -1
commit 43ba0b079b80725c1b0752fcbfbfdb57a71ebc8e
$ prove t/op/number.t 
t/op/number.t .. Failed 1/126 subtests 

Test Summary Report
-------------------
t/op/number.t (Wstat: 0 Tests: 126 Failed: 1)
  Failed test:  50
Files=1, Tests=126,  0 wallclock secs 
    ( 0.19 usr  0.04 sys +  0.10 cusr  0.12 csys =  0.45 CPU)
Result: FAIL

Output of ./parrot_config --dump attached.

Thank you very much.

kid51

Changed 3 years ago by jkeenan

follow-ups: ↓ 9 ↓ 10   Changed 3 years ago by dukeleto

Compiling with gcc, but linking with g++ seems odd to me. For instance, all our GCC farm smokers either do everything with gcc or everything with g++.

Can you confirm for me that this problem still occurs when cc=link=ldd=g++ ? That will remove one more variable from the equation. Thanks!

  Changed 3 years ago by dukeleto

  • version changed from 2.11.0 to master

  Changed 3 years ago by dukeleto

  • platform set to darwin

in reply to: ↑ 6   Changed 3 years ago by jkeenan

Replying to dukeleto:

Compiling with gcc, but linking with g++ seems odd to me. For instance, all our GCC farm smokers either do everything with gcc or everything with g++.

Back in the day, when I was very young in Parrot years, I was having trouble getting Parrot to build on Mac. I consulted with the elders. They (well, Coke) gave me the shell script (with cc=gcc but link=g++ and ld=g++) which has worked ever since. So it may seem odd, but it has provided me/us with a consistent benchmark.

The only thing I did differently in this case was to add --optimize to the command-line options.

Can you confirm for me that this problem still occurs when cc=link=ldd=g++ ? That will remove one more variable from the equation. Thanks!

Yes, I get the same failure in t/op/number.t with an "all-g++" build with '--optimize'.

kid51

in reply to: ↑ 6   Changed 3 years ago by jkeenan

Replying to dukeleto:

Can you confirm for me that this problem still occurs when cc=link=ldd=g++ ? That will remove one more variable from the equation. Thanks!

Final data point. When I do an "all-g++" configuration but do not say --optimize, all tests pass in t/op/number.t.

Thank you very much.

kid51

  Changed 3 years ago by coke

On Wed, Jul 27, 2011 at 7:57 PM, Parrot <parrot-tickets@lists.parrot.org> wrote:
> #1930: t/op/number.t: one test fails under --optimize on Darwin/PPC
> ---------------------+------------------------------------------------------
>  Reporter:  jkeenan  |       Owner:
>     Type:  bug      |      Status:  new
>  Priority:  minor    |   Milestone:
> Component:  testing  |     Version:  master
>  Severity:  medium   |    Keywords:
>     Lang:           |       Patch:
>  Platform:  darwin   |
> ---------------------+------------------------------------------------------
>
> Comment(by jkeenan):
>
>  Replying to [comment:6 dukeleto]:
>  > Compiling with gcc, but linking with g++ seems odd to me. For instance,
>  all our GCC farm smokers either do everything with gcc or everything with
>  g++.
>
>  Back in the day, when I was very young in Parrot years, I was having
>  trouble getting Parrot to build on Mac.  I consulted with the elders.
>  They (well, Coke) gave me the shell script (with `cc=gcc` but `link=g++`
>  and `ld=g++`) which has worked ever since.  So it may seem odd, but it has
>  provided me/us with a consistent benchmark.

Those directions date when parrot and ICU were both in the CVS repo,
and we needed to jump through more hoops.

>  The only thing I did differently in this case was to add `--optimize` to
>  the command-line options.
>
>  >
>  > Can you confirm for me that this problem still occurs when
>  cc=link=ldd=g++ ? That will remove one more variable from the equation.
>  Thanks!
>
>  Yes, I get the same failure in ''t/op/number.t'' with an "all-g++" build
>  with '--optimize'.
>
>  kid51
>
> --
> Ticket URL: <https://trac.parrot.org/parrot/ticket/1930#comment:9>
> Parrot <https://trac.parrot.org/parrot/>
> Parrot Development
> _______________________________________________
> parrot-tickets mailing list
> parrot-tickets@lists.parrot.org
> http://lists.parrot.org/mailman/listinfo/parrot-tickets
>



-- 
Will "Coke" Coleda

  Changed 3 years ago by doughera@…

On Wed, 27 Jul 2011, Will Coleda wrote:

> >  Replying to [comment:6 dukeleto]:
> >  > Compiling with gcc, but linking with g++ seems odd to me. For instance,
> >  all our GCC farm smokers either do everything with gcc or everything with
> >  g++.
> >
> >  Back in the day, when I was very young in Parrot years, I was having
> >  trouble getting Parrot to build on Mac.  I consulted with the elders.
> >  They (well, Coke) gave me the shell script (with `cc=gcc` but `link=g++`
> >  and `ld=g++`) which has worked ever since.  So it may seem odd, but it has
> >  provided me/us with a consistent benchmark.
> 
> Those directions date when parrot and ICU were both in the CVS repo,
> and we needed to jump through more hoops.

It may well be that such hoops are necessary on Darwin anymore, and if 
that is all you mean to imply, then you are correct.

However, in general, Parrot should still jump through the same hoops.  
ICU (or part of it, at least) is compiled with a C++ compiler.  By 
default, parrot tries to link with ICU if available.  In order for that to 
work on Solaris (and possibly other systems as well) the linker needs to 
be a C++ compiler.  It doesn't matter if ICU was built as part of the 
parrot package (as was the case long ago) or if ICU was built and 
installed independently.  It's still a C++ library that parrot will link 
to, so parrot still needs to use a link editor that understands C++ 
libraries.  (See TT #309 for a specific example of the error messages that 
ensued when the link was accidentally changed to use cc instead of CC on 
OpenSolaris.)

-- 
    Andy Dougherty		doughera@lafayette.edu
Note: See TracTickets for help on using tickets.