On Fri, Mar 18, 2016 at 3:50 PM, Bill Allombert <Bill.Allombert@math.u-bordeaux.fr> wrote:
On Fri, Mar 18, 2016 at 03:21:13PM -0400, Igor Schein wrote:
> Package: pari
> Version: git
>
>           GP/PARI CALCULATOR Version 2.8.0 (development 18700-3cadb51)
>           ix86 running solaris (ix86/GMP-4.3.2 kernel) 32-bit version
>                  compiled: Mar 18 2016, gcc version 4.8.2 (GCC)
>                            threading engine: pthread
>                 (readline v5.2 disabled, extended help enabled)
>
>                      Copyright (C) 2000-2016 The PARI Group
>
> PARI/GP is free software, covered by the GNU General Public License, and
> comes
> WITHOUT ANY WARRANTY WHATSOEVER.
>
> Type ? for help, \q to quit.
> Type ?15 for how to get moral (and possibly technical) support.
>
> parisize = 4000000, primelimit = 500000
>    echo = 1 (on)
> ? bnfisprincipal(bnfinit(x^2-x-57),[5,1;0,1])
>   ***   at top-level: bnfisprincipal(bnfin
>   ***                 ^--------------------
>   *** bnfisprincipal: bug in PARI/GP (Segmentation Fault), please report.
>
> Debug version works fine with pthread.

I do not know how good is the TLS support in this configuration.
Your example does not actually run any threads, so it is purely
a TLS issue.

Could you try
polmodular(127)

Cheers,
Bill

I was able to work around the said SEGV by configuring with CFLAGS=-fno-tree-loop-vectorize

When I do use -ftree-loop-vectorize, I get the following stack trace (for what it's worth):

#0  getrand () at ../src/basemath/random.c:134
#1  0x079eb2c0 in bnfisprincipal0 (bnf=0xfe5d0e00, x=<optimized out>, flag=1) at ../src/basemath/buch2.c:1902
#2  0x07d62ae5 in closure_eval (C=C@entry=0xfe5d0fb4) at ../src/language/eval.c:1305
#3  0x07d6425c in closure_return (C=<optimized out>) at ../src/language/eval.c:614
#4  closure_evalres (C=0xfe5d0fb4) at ../src/language/eval.c:1585
#5  0x08071ca6 in gp_main_loop (ismain=ismain@entry=1) at ../src/gp/gp.c:371
#6  0x08072912 in main (argc=<optimized out>, argv=<optimized out>) at ../src/gp/gp.c:598

I get the identical behavior with both
gcc version 4.8.2 (GCC)
and 
gcc version 6.0.0 20160327 (experimental) (GCC)

Thanks,

Igor

Igor