Phil Edwards | 1 Sep 02:33 2002

[libstdc++] automate documentation.html changes, basic_string doxygen hooks

string, wstring, and basic_string hav never been doxygenated.  This adds
the initial hooks to make them at least show up the output.

The "how to get basic_string<some_random_type> to work" question needs an
answer in the string howto.  This adds a placeholder for that.  I'll come
back to that later.

Benjmain recently copied out all of the "Contents" blocks from our
various HOWTOs into an expanded form in the parent documentation.html.
To avoid repetitious editing, this makes documentation.html a target in
docs/html/Makefile.  So, for example, after editing 21_strings/howto.html
to add a new entry, it automatically showed up in the expanded list.
(The initial regen changed indentation on all those lines, and added </li>
also, so the diff is large.)

Some comment and whitespace fixups.

2002-08-31  Phil Edwards  <pme <at>>

	* acinclude.m4:  Minor comment tweaks.

	* docs/html/makedoc.awk:  New file...
	* docs/html/Makefile:  ...called from here...
	* docs/html/documentation.html: help generate this.

	* docs/html/21_strings/howto.html:  Prepare for new entry.
	* include/bits/basic_string.h:  Initial basic_stirng hook for
	doxygen.  Remove trailing whitespace.
	* include/bits/char_traits.h:  Point to onlinedocs for new entry.
	* include/bits/stringfwd.h:  Add doxygen hooks for string and
(Continue reading)

Frank Ch. Eigler | 1 Sep 03:25 2002

Re: [tree-ssa mudflap] source file/line locations

Hi -

rth wrote:

> > What's the alternative?  At this point, a single location string
> > is given to each __mf_check call.
> There are lots of solutions, depending on how elaborate
> you want to get.  

I was responding to the "having to pass more arguments to the runtime"
part of what you wrote.  I was pointing out that the single additional
string is pretty minimal already, and we were definitely not
contemplating adding more for this purpose.

> Do you store this location, or only 
> use it immedately if the check fails?

The latter, at this point.

> I think the most clever solution would be to use the debug
> information present in the executable image, using the return
> address of the __mf_check call as the location key.  [...]

Right, and using `addr2line` to map to a source file/line.
One obvious problem is that this relies on the presence and
accuracy/usability of debugging info.  FWIW, we already toy
with the glibc backtrace functions.

- FChE
(Continue reading)

Roger Sayle | 1 Sep 03:39 2002

Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis

Hi John David,
> This test fails on hppa64-hpux at -O3.  The function foo is correctly
> optimized but the inline copy in main is not.  After the life pass, the
> abs operation is gone and we have this rtl:
> (insn 16 15 27 0 800003ffeffbb960 (set (reg/v:DF 69)
>         (mem/u/f:DF (reg/f:DI 70) [2 S8 A64])) 110 {*} (insn_list 15 (nil))
>     (expr_list:REG_DEAD (reg/f:DI 70)
> 	(expr_list:REG_EQUAL (const_double:DF 0 [0x0] 0 [0x0] -9223301672405565440 [0x80003fff00000000])
> 	    (nil))))
> (insn 27 16 28 0 800003ffeffbb9c0 (set (reg:CCFP 0 %r0)
> 	(lt:CCFP (reg/v:DF 69)
> 	    (const_double:DF 0 [0x0] 0 [0x0] 0 [0x0]))) 1 {*} (insn_list 16 (nil))
>     (expr_list:REG_DEAD (reg/v:DF 69)
> 	(expr_list:REG_EQUAL (const_int 0 [0x0])
> 	    (nil))))
> (jump_insn 28 27 54 0 800003ffeffbb9c0 (set (pc)
> 	(if_then_else (ne (reg:CCFP 0 %r0)
> 		(const_int 0 [0x0]))
> 	    (label_ref 31)
> 	    (pc))) 66 {*} (insn_list 27 (nil))
>     (expr_list:REG_DEAD (reg:CCFP 0 %r0)
> 	(expr_list:REG_BR_PROB (const_int 3000 [0xbb8])
>             (nil))))
> >From the discussion, it appears that combine should know how to optimize
> this rtl (3 insns?) but apparently there is a problem.  However, the
(Continue reading)

John David Anglin | 1 Sep 04:35 2002

Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis

> > >From the discussion, it appears that combine should know how to optimize
> > this rtl (3 insns?) but apparently there is a problem.  However, the
> > problem in this case isn't the abs optimization.
> This is very interesting!  Notice the REG_EQUAL note on instruction
> 27, the compiler has determined that the condition flags are always
> false (i.e. that 1.0 is not less than 0.0)!  I'd be surprised that
> with this information the conditional branch survives the rest of
> compilation.

Hmmm, is the REG_EQUAL note for %r0 rather than the condition code?
It is always 0.  The conditional branch does survive the rest of the

> I've tried reproducing this problem on a cross compiler from
> i686-pc-cygwin to hppa64-hp-hpux11.00, but I've been unable to
> reproduce the behaviour as "foo" refuses to be inlined at -O3.
> Is the inliner a known deficiency of cross-compiling from 32bit
> hosts to 64bit targets?


> One observation is that the .s files still contain references
> to ".IMPORT link_error,ENTRY" even though link_error is never
> referenced or called in the generated code.  I didn't build a
> full hppa64 toolchain, so I've no idea if this is the issue.

These don't cause a link error or the test to fail at lower
optimization levels.  This is a problem that's not easily fixed,
(Continue reading)

Jason Merrill | 1 Sep 09:42 2002

Re: PATCH to avoid copying tail padding (was: GCC 3.2)

Jakub found a case where the abort was inappropriate, for which I'll check
in a testcase shortly.  For the 3.2 branch, it seems reasonable just to
remove the sanity check.

2002-08-31  Jason Merrill  <jason <at>>

	* cp-lang.c (cp_expr_size): Don't abort.

Attachment: text/x-patch, 927 bytes
Jason Merrill | 1 Sep 09:45 2002

Re: PATCH to avoid copying tail padding (was: GCC 3.2)

For the trunk, just allow this case where it's reasonable to call
expr_size.  Test in g++.dg/init/aggr1.C.

2002-08-31  Jason Merrill  <jason <at>>

	* cp-lang.c (cp_expr_size): Allow initialization from a

Attachment: text/x-patch, 948 bytes
Jakub Jelinek | 1 Sep 12:38 2002

[PATCH] Use __uselocale in

On Fri, Aug 30, 2002 at 12:38:28PM +0200, Jakub Jelinek wrote:
> The following patch fixes libstdc++-v3 compilation and use on GLIBC 2.2.9x+.
> It passed libstdc++-v3 make check with 24 XPASSes and 1 FAIL - the remaining
> 2 missing XPASSes (ie. the only 2 XFAILs) are:
> XFAIL: 22_locale/ execution test
> XFAIL: 22_locale/ execution test
> which fail because of a glibc bug Roland is working on.

Follow up patch - was still using setlocale.
With current CVS glibc plus a one-liner fix for locale-archive support
I now get back the expected 1 FAIL and 26 XPASSes on i386-redhat-linux,
both when using locale-archive and when forcing to not use
it (export LOCPATH=/usr/lib/locale).

Ok to commit?

2002-09-01  Jakub Jelinek  <jakub <at>>

	* config/locale/gnu/
	(moneypunct<wchar_t, true>::_M_initialize_moneypunct,
	moneypunct<wchar_t, false>::_M_initialize_moneypunct): Use
	__uselocale instead of setlocale for glibc 2.3+.

--- libstdc++-v3/config/locale/gnu/	2002-08-30 12:09:12.000000000 +0200
+++ libstdc++-v3/config/locale/gnu/	2002-08-31 23:41:51.000000000 +0200
 <at>  <at>  -335,9 +335,13  <at>  <at>  namespace std
 	  // Named locale.
-	  // XXX Fix me. Switch to named locale so that mbsrtowcs will work.
(Continue reading)

Gabriel Dos Reis | 1 Sep 12:36 2002

Re: V3 PATCH: numeric_limits<> support, fix PR/3865

Richard Henderson <rth <at>> writes:

| On Fri, Aug 30, 2002 at 12:43:55PM +0200, Gabriel Dos Reis wrote:
| > |   if (wchar_t(-1) < 0)
| > 
| > I'm afraid this doesn't solve the problem:  We want something at the
| > preprocessor level.
| For what purpose? 

Initialization values for several const static (integral) data members of
numeric_limits<wchar_t> depend on whether or not wchar_t is signed.

| Can't you do everything you need at the C++
| and let constant folding do its job?

That would be an easier path to take weren't there constraints on how
the integral static data members of numeric_limits<wchar_t> have to be

It may be possible to use internal templates specializations to arrive
at something, but the one I have
  (1) breaks V3 binary interface;
  (2) isn't cleaner nor easier than the __WCHAR_UNSIGNED__ path.

There may be other possibilities.  I would be glad to look at them if

-- Gaby

(Continue reading)

Gabriel Dos Reis | 1 Sep 12:49 2002

Re: V3 PATCH: numeric_limits<> support, fix PR/3865

Richard Henderson <rth <at>> writes:

| On Tue, Aug 27, 2002 at 10:35:59PM +0200, Gabriel Dos Reis wrote:
| > + #if __GCC_FLOAT_FORMAT__ == __IEEE_FORMAT__
| > + #  define __glibcpp_f32_infinity_bytes { 0x7f800000 }
| > + #  define __glibcpp_f32_has_infinity true
| > + #  define __glibcpp_f32_QNaN_bytes { 0x7fc00000 }
| > + #  define __glibcpp_f32_has_QNaN true
| > + #  define __glibcpp_f32_SNaN_bytes { 0x7f800001 }
| > + #  define __glibcpp_f32_has_SNaN true
| > + #  define __glibcpp_f32_denorm_min_bytes { 0x00000001 }
| > + #  define __glibcpp_f32_has_denorm denorm_present
| > + #  define __glibcpp_f32_is_iec559  true
| > + #endif
| This is incomplete.
| First, MIPS swaps the usual meaning of QNaN and SNaN encoding
| interpretations.  Don't ask me why.

Yes, I noted that one.  See my discussion with Matt Austern on that topic.


| If you know that infinities exist, it's much easier to produce
| them with (1.0f / 0.0f) than futz about with bitwise definitions.

That makes the assumption that IEEE-exception for division by zero is
disabled.  Something I can't control.  Instead, we should just produce
the right thing in the compiler, as a builtin.
(Continue reading)

Neil Booth | 1 Sep 12:57 2002

Re: V3 PATCH: numeric_limits<> support, fix PR/3865

Gabriel Dos Reis wrote:-

> I like your design better.  Can we agree on implementing that for 3.4
> rather than 3.3?

If we do this, let's leave the macros undocumented so that third
party code doesn't come to rely on them.