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