C++ PATCH: Fix sprintf format

Eric Botcazou ebotcazou@libertysurf.fr
Wed Jun 18 17:23:00 GMT 2003


> You're still seeing a "\n" in the output, which suggests that you didn't
> pick up the fix that came with the email above.

The fix in the aforementioned email still contains the "\n". It corresponds 
to rev1.73 --> rev1.74. You commited a second fix, that I didn't see on the 
list.

> In cp/mangle.c:mangle_conv_op_name_for_type you should have:
>
> !   /* Create a unique name corresponding to TYPE.  */
> !   sprintf (buffer, "operator %lu",
>   	   (unsigned long) htab_elements (conv_type_names));
>
> Do you have that code?  Or do you still have a version with a \n at the
> end of the string literal?

I still had a "\n" by the time I was bootstrapping.

> I'm running a SPARC bootstrap now to see if I can reproduce your
> problem.

I should now be gone.

> With respect to the DejaGNU issue, I cannot reproduce it.  On the 32-bit
> SPARC system, the test does pass with -m64.
>
> Your testsuite/lib/gcc-dg.exp should contain:
>
> # Like check_conditional_xfail, but callable from a dg test.
>
> proc dg-xfail-if { args } {
>     set args [lreplace $args 0 0]
>     global compiler_conditional_xfail_data
>     set compiler_conditional_xfail_data $args
> }

I already double-checked.

> If it does, then we'll have to figure out what's going wrong on
> SPARC64.  The first thing would be for you to send me the .log file
> output for the simd-5.c test.

Basically unchanged (the failures at -O1 and -O2 are at a different location 
in the compiler, due to a recent SIMD-related patch).

-- 
Eric Botcazou



More information about the Gcc-patches mailing list