Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
-Original Message- From: Dongsheng Song Sent: Tuesday, March 12, 2013 2:25 PM To: gcc@gcc.gnu.org ; m...@loria.fr Subject: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate Test on x86_64-w64-mingw32, only tfprintf.exe, tprintf.exe, tsprintf.exe, and tstrtofr.exe FAILED, the other tests passed. Why would those tests fail for your x86_64-w64-mingw32 build, but not for my x86_64-w64-mingw32 build ? What was the configure command that you ran ? What version of MS Windows do you have ? Cheers, Rob
Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?
On Mon, Mar 11, 2013 at 5:30 PM, Georg-Johann Lay wrote:
> Richard Biener wrote:
>> On Fri, Mar 8, 2013 at 5:03 PM, Georg-Johann Lay wrote:
>>> Richard Biener wrote:
On Fri, Mar 8, 2013 at 3:19 PM, Richard Biener
wrote:
> On Fri, Mar 8, 2013 at 2:57 PM, Georg-Johann Lay wrote:
>> While implementing PR56263 (Strict address-space checking for AVR), I
>> encountered the problem that pointer casts with address spaces are always
>> expanded as const_int 0.
>>
>> The problem occurs if the attached patch that implements PR56263 and the
>> following code is compiled as
>>
>> $ avr-gcc -Os flash-cast.c -S -mstrict-addr-space-subsets
>>
>>
>> #define PROGMEM __attribute__((__progmem__))
>>
>> #define PSTR(s) \
>> (__extension__\
>>({ \
>> static const char __c[] PROGMEM = (s); \
>> &__c[0]; \
>>}))
>>
>> extern void print (const __memx char*, ...);
>>
>> const __flash char *p;
>>
>> void f (const char *c)
>> {
>> c = (const char*) p;
>>
>> print ((const __flash char*) PSTR ("Hallo flash"));
>> }
>>
>>
>>
>> The corresponding .expand dump reads:
>>
>>
>> f (const char * c)
>> {
>> static const char __c[12] = "Hallo flash";
>> const char * _2;
>> const char * _3;
>>
>> ;; basic block 2, loop depth 0
>> ;;pred: ENTRY
>> _2 = (const char *) (&__c[0]);
>> _3 = (const char *) _2;
>> print (_3); [tail call]
>> return;
>> ;;succ: EXIT
>>
>> }
>>
>>
>> but the expression is always emit as (const_int 0).
>>
>>
>> Trying to track this issue, I ended up in build1_stat which enters the
>> default
>> case for "code" (ADDR_SPACE_CONVERT_EXPR at that time) and returns the
>> following tree:
>>
>>
>> (gdb) p t
>> $62 = (tree) 0xb7bb4578
>> (gdb) pt
>> > type > type > address-space-1 string-flag QI
>> size
>> unit size
>> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a20
>> precision 8
>> min max
>> pointer_to_this >
>> unsigned HI
>> size
>> unit size
>> align 8 symtab 0 alias set -1 canonical type 0xb7bc3a80>
>> readonly constant
>> arg 0 > type
>> public unsigned HI size unit size
>>
>> align 8 symtab 0 alias set -1 canonical type 0xb7b4f2a0
>> pointer_to_this >
>> readonly constant
>> arg 0
>> readonly arg 0
>> arg 1
>> flash-cast.c:18:128>
>> flash-cast.c:18:124>>
>>
>> Problem is the arg 1 at the end
>> which leads
>> to the expansion of 0.
>>
>> The call chain is:
>>
>> #0 build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
>> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
>> (gdb) bt
>> #0 build1_stat (code=ADDR_SPACE_CONVERT_EXPR, type=0xb7bc3a80,
>> node=0xb7bb449c) at ../../../gcc.gnu.org/trunk/gcc/tree.c:3848
>> #1 0x08286be0 in gimple_assign_rhs_to_tree (stmt=0xb7bc2c30) at
>> ../../../gcc.gnu.org/trunk/gcc/cfgexpand.c:86
>> #2 0x0837047f in expand_expr_real_1 (exp=0xb7b972f8, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
>> #3 0x083762f2 in expand_expr_real (exp=0xb7b972f8, target=0x0,
>> tmode=VOIDmode,
>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>> #4 0x08376a7e in expand_expr (exp=0xb7b972f8, target=0x0, mode=VOIDmode,
>> modifier=EXPAND_STACK_PARM) at ../../../gcc.gnu.org/trunk/gcc/expr.h:444
>> #5 0x0836ae96 in expand_expr_real_2 (ops=0xbfffca10, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:8150
>> #6 0x08376234 in expand_expr_real_1 (exp=0xb7bb4564, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:10491
>> #7 0x083762f2 in expand_expr_real (exp=0xb7bb4564, target=0x0,
>> tmode=VOIDmode,
>> modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:7863
>> #8 0x083704a6 in expand_expr_real_1 (exp=0xb7b97320, target=0x0,
>> tmode=VOIDmode, modifier=EXPAND_STACK_PARM, alt_rtl=0x0) at
>> ../../../gcc.gnu.org/trunk/gcc/expr.c:9274
>> #9 0x083762f
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
I use stable/v2.x of mingw-w64, not trunk. On Tue, Mar 12, 2013 at 4:43 PM, wrote: > > > -Original Message- From: Dongsheng Song > Sent: Tuesday, March 12, 2013 2:25 PM > To: gcc@gcc.gnu.org ; m...@loria.fr > Subject: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate > > >> Test on x86_64-w64-mingw32, only tfprintf.exe, tprintf.exe, >> tsprintf.exe, and tstrtofr.exe FAILED, the other tests passed. > > > Why would those tests fail for your x86_64-w64-mingw32 build, but not for my > x86_64-w64-mingw32 build ? > What was the configure command that you ran ? > What version of MS Windows do you have ? > > Cheers, > Rob
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
You have in your test output:
Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...);
expected: "0010610209857723, -1.2345678875e+07, 0.032258"
got: "0010610209857723, -1.2345678875e+07, 0.00"
That "0.00" for the "%Lf" usually indicates that the "%Lf" formatting is
not supported.
Is that the case here ? or did the test *really* arrive at a wrong
answer of "0.00" ?
With the (gcc-4.7.0) x86_64-w64-mingw32 compiler that I use, I need to first
define __USE_MINGW_ANSI_STDIO if I want support for "%Lf" formatting:
#
C:\_32\C>type try.c
#include
int main(void) {
long double x = 0.347L;
printf("%Lf\n", x);
return 0;
}
C:\_32\C>x86_64-w64-mingw32-gcc -o try.exe try.c
C:\_32\C>try
0.00
C:\_32\C>x86_64-w64-mingw32-gcc -o try.exe -D__USE_MINGW_ANSI_STDIO try.c
C:\_32\C>try
0.347000
C:\_32\C>
#
Is it the same for your compiler ?
Was __USE_MINGW_ANSI_STDIO defined when you built mpfr ? (It is *not*
defined for my build - but I think configure detects that for me, and skips
any tests that involve the "%Lf" format.)
Cheers,
Rob
From: Dongsheng Song
I use stable/v2.x of mingw-w64, not trunk.
On Tue, Mar 12, 2013 at 4:43 PM, wrote:
>
>
> -Original Message- From: Dongsheng Song
> Sent: Tuesday, March 12, 2013 2:25 PM
> To: gcc@gcc.gnu.org ; m...@loria.fr
> Subject: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
>
>
>> Test on x86_64-w64-mingw32, only tfprintf.exe, tprintf.exe,
>> tsprintf.exe, and tstrtofr.exe FAILED, the other tests passed.
>
>
> Why would those tests fail for your x86_64-w64-mingw32 build, but not
> for my
> x86_64-w64-mingw32 build ?
> What was the configure command that you ran ?
> What version of MS Windows do you have ?
>
> Cheers,
> Rob
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
On Tue, Mar 12, 2013 at 6:54 PM, wrote:
> You have in your test output:
>
>
> Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...);
> expected: "0010610209857723, -1.2345678875e+07, 0.032258"
> got: "0010610209857723, -1.2345678875e+07, 0.00"
>
> That "0.00" for the "%Lf" usually indicates that the "%Lf" formatting is
> not supported.
> Is that the case here ? or did the test *really* arrive at a wrong
> answer of "0.00" ?
>
> With the (gcc-4.7.0) x86_64-w64-mingw32 compiler that I use, I need to first
> define __USE_MINGW_ANSI_STDIO if I want support for "%Lf" formatting:
>
> #
> C:\_32\C>type try.c
>
> #include
>
> int main(void) {
>
>long double x = 0.347L;
>printf("%Lf\n", x);
>
>return 0;
> }
>
>
> C:\_32\C>x86_64-w64-mingw32-gcc -o try.exe try.c
>
> C:\_32\C>try
> 0.00
>
> C:\_32\C>x86_64-w64-mingw32-gcc -o try.exe -D__USE_MINGW_ANSI_STDIO try.c
>
> C:\_32\C>try
> 0.347000
>
> C:\_32\C>
> #
>
> Is it the same for your compiler ?
Yes.
> Was __USE_MINGW_ANSI_STDIO defined when you built mpfr ? (It is *not*
> defined for my build - but I think configure detects that for me, and skips
> any tests that involve the "%Lf" format.)
>
> Cheers,
> Rob
>
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
Hi Dongsheng, > > Is it the same for your compiler ? > > Yes. then you should define __USE_MINGW_ANSI_STDIO as pointed out by Rob. However it is strange that the configure did not detect that %Lf was not supported. Please could you send the config.log and the output from configure? Paul Zimmermann
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
Hi, > Test on x86_64-w64-mingw32, only tfprintf.exe, tprintf.exe, > tsprintf.exe, and tstrtofr.exe FAILED, the other tests passed. > > fixme:msvcrt:pf_printf_a multibyte characters printing not supported > Error in test 8, got '% a. 15, b. -1, c. td' > Error in test #8: mpfr_vfprintf printed 21 characters instead of 20 note the "fixme" message above, which may indicate a problem in your environment. Paul Zimmermann
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
On Tue, Mar 12, 2013 at 8:02 PM, Zimmermann Paul wrote: >Hi Dongsheng, > >> > Is it the same for your compiler ? >> >> Yes. > > then you should define __USE_MINGW_ANSI_STDIO as pointed out by Rob. > Perfect, now all tests passed !
Re: ADDR_SPACE_CONVERT_EXPR always expanded to 0?
> A quick grep shows not many targets would be affected, AVR, m32c, rl78 and > spu. > You should work with the maintainers of those targets to see which approach > would be the best. For both m32c and rl78, one address space is a strict subset of the other (16-bit "near" vs 20/24/32-bit "far" pointers, that's all) so nothing magic there.
Re: 4.7.2 TLS on AIX 6.1 (ppc) ?
Thanks for your informative response, David! This is what I really wanted to know: > All previous and current releases of GCC do not support > native TLS on AIX. GCC 4.8 will provide TLS on AIX, as listed in the > announcements for the release. Great! I'll look forward to testing with 4.8 when it becomes GA . Thanks for comments on configuration options - points noted - but I was only copying the options used for the IBM freeware GCC distribution. But why didn't the compiler complain that TLS was not supported ? Shouldn't it be doing so ? It is definitely not OK in my book for gcc to finish compilation and linkage with no errors or warnings, when it has encountered a __thread usage that it must know will have no effect. And isn't there an easier way to determine if TLS is enabled or not than by compiling a test program ? Thanks & Regards, Jason On Mon, Mar 11, 2013 at 10:07 PM, David Edelsohn wrote: > On Mon, Mar 11, 2013 at 3:46 PM, Jason Vas Dias > wrote: >> Hi - I wonder if anyone could please tell me if gcc's thread local >> storage support is meant to be enabled on AIX or not - >> I've built gcc-4.7.2 on AIX 6.1 OK, with "---enable-threads" , >> using the AIX system /usr/ccs/bin ld and as , both of which >> claim to provide TLS support , but now this test program is getting >> the same address for its __thread variable in different threads - >> it is compiled and linked without warnings or error, and prints three >> different addresses at the end on Linux, Solaris x86 & SPARC, and >> HP-UX, >> but not on AIX 6.1 . This also happens with the IBM freeware >> gcc-4.4.6. Yet 4.7.2's libgomp was built OK ... doesn't this depend >> on TLS? >> >> Must I use --enable-tls as well as --enable-threads in configuration >> options and rebuild GCC ? Is this likely to work ? >> >> gcc-4.7.2 is reporting its thread model as 'aix' - shouldn't this be >> 'posix' ( the system /usr/lib/libpthread.a is installed and the >> pthread_* headers look POSIX compatible ). > >> Shouldn't GCC be terminating compilation with an error if it >> encounters use of __thread when TLS is not enabled ? >> Is there an option to enable this / if not , could one be added ? >> Is there an option to make GCC tell the user if TLS is enabled or not >> - again, if not, could there be one ? >> >> I don't think gcc should be allowing programmers to assume TLS is in >> use when it is not - this is dangerous! >> >> If GCC does not support TLS with AIX 'ld' + 'as' (which seems likely), >> could this not be documented somewhere in the installation >> documentation (it does not appear to be) ? Any plans to enable it in >> near future ? > > First, because of the way that AIX supports pthreads, GCC requires > different libraries for pthread and non-pthread code. GCC -pthread > links with the pthread version of the libraries. This is why thread > model is reported as "aix" and not "posix". > > Second, when native TLS is not available, GCC emulates TLS using > pthread keys. All previous and current releases of GCC do not support > native TLS on AIX. GCC 4.8 will provide TLS on AIX, as listed in the > announcements for the release. > > Third, one should not add configuration options like "--enable-tls" or > "--enable-threads". The defaults are correct and will enable the > appropriate features for the system. No one chose to implement a > feature but leave it disabled by default. No one is hiding features > and one should not approach the configuration process by trying to > force override options. > > Compiling your example with GCC 4.8 snapshot from last night produces > the following on AIX 7.1: > > $ ./xgcc -B./ -O2 -pthread code.c > $ ./a.out > main : 200080d0 20112000 20218000 > $ ./xgcc -B./ -O2 -pthread -maix64 code.c > $ ./a.out > main : 11000de20 11011a000 110221000 > > Thanks, David
Re: 4.7.2 TLS on AIX 6.1 (ppc) ?
On Tue, Mar 12, 2013 at 3:06 PM, Jason Vas Dias wrote: > But why didn't the compiler complain that TLS was not supported ? > Shouldn't it be doing so ? It is definitely not OK in my book for gcc > to finish compilation and linkage with no errors or warnings, when > it has encountered a __thread usage that it must know will have no > effect. > > And isn't there an easier way to determine if TLS is enabled or not > than by compiling a test program ? It is enabled. It is working. It is using the pthreads emulation. - David
