Kaveh R. Ghazi | 1 Mar 2004 01:13
Picon
Favicon

Re: [patch] Fix builtin-explog-1.c.

 > From: Kazu Hirata <kazu <at> cs.umass.edu>
 > 
 > Hi,
 > 
 > Attached is a patch to fix builtin-explog-1.c.
 > 
 > On H8, float is the only floating point math available, and types like
 > long double or double are the same as float.  Consequently, the
 > following test fails by the smallest margin.
 > 
 >  if (EXP(5.0) < (BASE)*(BASE)*(BASE)*(BASE)*(BASE) - PREC \
 >   || EXP(5.0) > (BASE)*(BASE)*(BASE)*(BASE)*(BASE) + PREC \
 > 
 > The patch relaxes PREC and PRECL if the target does not actually have
 > double or long double.
 > 
 > Tested on h8300-elf.  OK to apply?
 > 
 > Kazu Hirata
 > 
 > 2004-02-28  Kazu Hirata  <kazu <at> cs.umass.edu>
 > 
 > 	* gcc.dg/torture/builtin-explog-1.c (PREC): Make it the same
 > 	as PRECF if sizeof (float) > sizeof (double).
 > 	(PRECL): Make it the same as PRECF if
 > 	sizeof (float) > sizeof (long double).

I can't approve your change, but FWIW as the author of the testcase,
your approach is fine with me (assuming you correct the comparison
problem noted earlier.)
(Continue reading)

Andrew Pinski | 1 Mar 2004 03:01
Picon

[PING] patch for PR13708 for 3.4 and the mainline

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03355.html
Do not use getClass but link to the selected class.

Thanks,
Andrew Pinski

Mark Mitchell | 1 Mar 2004 03:27

C++ PATCH: PR 14267


This patch fixes PR 14267 -- but only on the mainline, because I'm
just a tad nervous about the patch.  The patch removes another piece
of the cast-as-lvalue extension, but I'm just a wee bit nervous it
will somehow impact valid code, so I'll put this on the branch after
3.4.0 is out -- assuming that all goes well on the mainline.

Tested on i686-pc-linux-gnu, applied on the mainline.

--
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com

2004-02-29  Mark Mitchell  <mark <at> codesourcery.com>

	PR c++/14267
	* typeck.c (build_modify_expr): Remove more of the cast-as-lvalue
	extension.

2004-02-29  Mark Mitchell  <mark <at> codesourcery.com>

	PR c++/14267
	* g++.dg/expr/crash2.C: New test.

Index: cp/typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/typeck.c,v
retrieving revision 1.529
diff -c -5 -p -r1.529 typeck.c
(Continue reading)

Hans-Peter Nilsson | 1 Mar 2004 03:41
Picon
Favicon

[RFA:] Fix other/14354: low precision on subnormal single FP numbers multiplied with fp-bit.c

I got a report that the multiplications below failed a precision test in
javasoft.sqe.tests.lang.fpl038.fpl03804m1 from the Sun JCK, using a Java
VM about which I have no further details.  Anyway, the point it is that
the numbers are calculated "natively", which is by fp-bit.c for cris-*.

The errors for these calculations are >0.5ulp, but not by much.  I don't
know if any of the relevant language standards (besides Java) have strict
requirements on FP precision, so I'll settle for this being a
"quality-of-implementation issue" rather than a plain bug.

Staring at fp-bit.c and simulator traces, I saw that there's rounding in
multiplication and division core functions respectively, and then *also*
in the bit-packing core function.  Fixing that fixes the test-case.
There's a cryptic ill-formatted comment before some pre-historic #if 0:d
code that seems to warn about double rounding not being done in the #if
0:d code (implementing rounding for multiplication).  Go figure.  I kept
the rounding in pack_d and removed the rounding in mul and div except for
special cases when their calculated result has extra bits of precision
that isn't is not passed to pack_d.

Tested on i686-pc-linux-gnu cross with simulator to cris-axis-elf,
v850-elf, m32r-elf, mn10300-elf, all fp-bit.c targets, thus failing this
test without the patch.

For sanity of test-case, also on built and checked on host,
mmix-knuth-mmixware, arm-unknown-elf.  The test-case itself was also
checked for sanity on sparc, hppa, ia64 and parisc64 (in the odd case any
of them would get the precision wrong or have strangely mapped IEEE 32-bit
fp layout).

(Continue reading)

Picon

Patch for libstdc++/14353 libstdc++ wchar tests run for -mabi=32

The following patch fixes libstdc++/14353 by using the testsuite_files in the 
correct multilib directory.

Tested on mips-sgi-irix6.5 for 3.4 branch with 
	RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'

2004-03-01  David Billinghurst <David.Billinghurst <at> riotinto.com>

	* testsuite/lib/libstdc++.exp: Use testsuite_files from
	correct multilib blddir when running testsuite

 Index: testsuite/lib/libstdc++.exp
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/lib/libstdc++.exp,v
retrieving revision 1.15
diff -u -r1.15 libstdc++.exp
--- testsuite/lib/libstdc++.exp 12 Jan 2004 20:47:44 -0000      1.15
+++ testsuite/lib/libstdc++.exp 1 Mar 2004 03:36:50 -0000
 <at>  <at>  -246,9 +246,14  <at>  <at> 
 proc v3-list-tests { filename } {
     global srcdir
     global outdir
+    global blddir

-    set tests_file "${outdir}/${filename}"
+    set tests_file "${blddir}/testsuite/${filename}"
     set sfiles ""
+
+    verbose -log "In v3-list-tests"
+    verbose -log "blddir = ${blddir}"
(Continue reading)

Phil Edwards | 1 Mar 2004 05:09

Re: Patch for libstdc++/14353 libstdc++ wchar tests run for -mabi=32

On Mon, Mar 01, 2004 at 02:46:58PM +1100, Billinghurst, David (CALCRTS) wrote:
> The following patch fixes libstdc++/14353 by using the testsuite_files in the 
> correct multilib directory.
> 
> Tested on mips-sgi-irix6.5 for 3.4 branch with 
> 	RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'
> 
> 2004-03-01  David Billinghurst <David.Billinghurst <at> riotinto.com>
> 
> 	* testsuite/lib/libstdc++.exp: Use testsuite_files from
> 	correct multilib blddir when running testsuite

Works for now.  (I think there's another way to do this that will let us
remove code, but that's for the future.)  Don't forget to put a period on
the end of the ChangeLog sentence.

--

-- 
America may be unique in being a country which has leapt
from barbarism to decadence without touching civilization.
  - John O'Hara

Mark Mitchell | 1 Mar 2004 05:11

PATCH: Fix debug/14328


This patch fixes a problem with the representation of enumeration
constants emitted by GCC.  In particular, GCC failed to recognize that
all enumeration constants are signed from the point of view of DWARF
2.  As a result, we tried to emit short representations of unsigned
constants, but the debugger interpreted those as having negative
values.

Tested on i686-pc-linux-gnu by compiling the test case in the PR,
applied as obvious on the 3.4 branch and on the mainline.

--
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com

2004-02-29  Mark Mitchell  <mark <at> codesourcery.com>

	PR debug/14328
	* dwarf2out.c (gen_enumeration_type_die): Output all enumeration
	constants as signed values.

Index: dwarf2out.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.497
diff -c -5 -p -r1.497 dwarf2out.c
*** dwarf2out.c	27 Feb 2004 07:09:42 -0000	1.497
--- dwarf2out.c	1 Mar 2004 04:06:10 -0000
*************** gen_enumeration_type_die (tree type, dw_
(Continue reading)

Eric Christopher | 1 Mar 2004 05:13
Picon
Favicon

Re: [patch, rfa] charset testsuite patches, take 2

On Sun, 2004-02-29 at 12:31, David Edelsohn wrote:
> >>>>> Eric Christopher writes:
> 
> Eric> OK. See, that's a problem with *_target_compile. I'm not actually doing
> Eric> anything but calling that. If this doesn't work then how did the
> Eric> testcase work at all in the first place? (Since we just call
> Eric> $tool_target_compile on each file...)
> 
> 	The previous testing of iconv functionality was within
> libstdc++-v3 testsuite.  libstdcc++.so links against libiconv.a on
> platforms where that library is required and implicitly provides that
> functionality.  iconv_open() is not explicitly in the test itself.
> 
> 	Your new tests explicitly reference iconv_open() without linking
> against LIBICONV.
> 

I'm still confused how: gcc.c-torture/execute/wchar_t-1.c could work
then. Maybe it doesn't. I'll look into it more.

--

-- 
Eric Christopher <echristo <at> redhat.com>

David Edelsohn | 1 Mar 2004 05:31
Picon
Favicon

Re: [patch, rfa] charset testsuite patches, take 2

>>>>> Eric Christopher writes:

Eric> I'm still confused how: gcc.c-torture/execute/wchar_t-1.c could work
Eric> then. Maybe it doesn't. I'll look into it more.

	cc1 is linked with libiconv.a (see LIBICONV in Makefile).  wchar_t
is testing cc1's implicit iconv support, not invoking iconv API explicitly
in testcase.

David

Mostafa Hagog | 1 Mar 2004 05:49
Picon
Favicon

Re: [PATCH] GCSE after reload - resubmit (SPECint +1.5% fp -0.5%).

Roger Sayle <roger <at> eyesopen.com> wrote on 25/02/2004 15:31:32:

>
> On Wed, 25 Feb 2004, Mostafa Hagog wrote:
> > So I need approval for cvs write access.
> >
>
> In the meantime, I'd suggest that you repost the patch with all of the
> necessary corrections, so that I or someone else with CVS write access
> can commit it for you.

Here is an updated patch with the fixes, Passed regression tests and
bootstrap (again) on powerpc-apple-darwin7.2.0 and i686-pc-linux-gnu.

ChangeLog entry
---------------
2004-03-01  Mostafa Hagog  <mustafa <at> il.ibm.com>

      * common.opt: Add description of the new -fgcse-after-reload flag.

      * flags.h (flag_gcse_after_reload): Declaration of global variable.

      * gcse.c (reg_used_on_edge ,reg_set_between_after_reload_p,
      reg_used_between_after_reload_p, rtx get_avail_load_store_reg,
      is_jump_table_basic_block, bb_has_well_behaved_predecessors,
      get_bb_avail_insn, hash_scan_set_after_reload,
      compute_hash_table_after_reload, eliminate_partially_redundant_loads,
      gcse_after_reload, get_bb_avail_insn): New functions to implement
      gcse-after-reload.
      (gcse_after_reload_main): New function, the main entry point to
(Continue reading)


Gmane