headers
Joe Buck | 1 May 2004 01:06

bootstrap failure with HP's C compiler on trunk: PR 12186 returns

The trunk fails to bootstrap on HP due to an HP compiler bug.  This
is the same issue as bootstrap/12186, but it has arisen in a different
place: the compiler crashes if the |= operator is applied to a bitfield.

Here's a patch.  Should I re-open PR 12186 or make a new PR?

Index: cppfiles.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cppfiles.c,v
retrieving revision 1.206
diff -u -r1.206 cppfiles.c
--- cppfiles.c	23 Apr 2004 02:22:24 -0000	1.206
+++ cppfiles.c	30 Apr 2004 23:03:21 -0000
 <at>  <at>  -1398,7 +1398,8  <at>  <at> 
 	return 1;

       d->entries[count].once_only = f->once_only;
-      d->have_once_only |= f->once_only;
+      /* |= is avoided in the next line because of an HP C compiler bug */
+      d->have_once_only = d->have_once_only | f->once_only; 
       if (f->buffer_valid)
 	  md5_buffer ((const char *)f->buffer,
 		      f->st.st_size, d->entries[count].sum);
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 May 2004 01:13
Picon
Favicon

Re: 3.4/3.5 PATCH: Fix many Solaris 10 g++ testsuite failures

On Fri, Apr 30, 2004 at 09:31:26PM +0200, Rainer Orth wrote:
> +	   In Solaris 10, int64_t from <sys/int_types.h>\
> +	   is only visible with g++ -ansi for ISO C99	\
> +	   compilations.  Those only work together with	\
> +	   XPG6.  */					\
>  	if (c_dialect_cxx ())				\
>  	  {						\
> -	    builtin_define ("_XOPEN_SOURCE=500");	\
> +	    builtin_define ("__STDC_VERSION__=199901L");\
> +	    builtin_define ("_XOPEN_SOURCE=600");	\

Does this get us into any other trouble assuming C99 features in C++98?
Would we be better off not using int64_t from system headers, but instead
via __attribute__((mode("DI"))) or somesuch?

> +  /* Solaris 2/x86, like SPARC, uses the default.  */
> +  if (TARGET_SOLARIS2)
> +    return std_build_builtin_va_list ();
> +
>    /* For i386 we use plain pointer to argument area.  */
>    if (!TARGET_64BIT)

Nest this inside TARGET_64BIT, lest you break Solaris/amd64
(reportedly under construction).

r~
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 May 2004 01:20
Picon
Favicon

Re: [PATCH]: fold constant arguments to lround et al.

On Fri, Apr 30, 2004 at 04:48:56PM -0400, Kaveh R. Ghazi wrote:
> 	* builtins.c (fold_builtin_round): Fix comment typo.
> 	(fold_builtin_lround): New function.
> 	(fold_builtin): Use it.
> 	* gcc.dg/torture/builtin-rounding-1.c: New test.
> 	* gcc.dg/builtins-25.c: Delete.
> 	* gcc.dg/builtins-29.c: Delete.

Ok.

r~
Permalink | Reply | 0 comments |
headers
Mike Stump | 1 May 2004 01:28
Picon
Favicon

Add -iquote support

We need a way for a user to be able to use a conflicting header file in 
their project, as well as on the system and #include <> to get the 
system one, and #include "" to get their local one.  Normally -I- does 
this just fine, but, it has one small problem.  This disables looking 
in the containing directory for additional #includes.  In trivial 
projects that only have headers at the top level, one can put in a -I. 
at just the right spot and pick them up, but in less trivial software, 
putting in -Idir for all the places is, well, annoying.

So, the solutions that come to mind, would be to add a flag that allows 
one to not turn off searching in the local directory when -I- is used, 
or another flag to take the place of -I- that does what it does, but 
does not turn off searching in local directories, or add an option like 
-iquote, which would be the same as adding the directory to the end of 
the quote chain.

-iquote dir1 -iquote dir2

== -I dir1 -I dir2 -I- (without turning off searching in the containing 
directory)

Which option do people like best?  All of them are trivial enough to 
implement, as all the required semantics are in the existing code, just 
no way to select those semantics.

See split_quote_chain where we do quote_ignores_source_dir = true; for 
the semantic I want to avoid.

Another option, if people want this to be target dependent would be to 
add an -m option that sets pfile->quote_ignore_source_dir to false;
(Continue reading)

Permalink | Reply | 24 comments |
headers
Zdenek Dvorak | 1 May 2004 01:45
Picon
Favicon

[lno] Bounds analysis and other improvements

Hello,

this patch adds the following features

-- It uses analysis of bounds on number of iterations of a loop to
   determine whether an induction variable can be computed in
   a wider mode.  This enables strength reduction on architectures
   where sizeof (void *) != sizeof (int).

-- It enables handling of hard registers in invariant motion.

Some smaller improvements and bugfixes:

-- The code to determine number of iterations of a loop was moved
   to tree-ssa-loop-niter.c.
-- Some type handling bugs in tree-chrec.c fixed.
-- A bug causing the newly created induction variables not to be
   coalesced into one variable fixed.

Zdenek

Index: ChangeLog.lno
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Attic/ChangeLog.lno,v
retrieving revision 1.1.2.150
diff -c -3 -p -r1.1.2.150 ChangeLog.lno
*** ChangeLog.lno	27 Apr 2004 14:10:15 -0000	1.1.2.150
--- ChangeLog.lno	30 Apr 2004 23:36:55 -0000
***************
*** 1,3 ****
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoff Keating | 1 May 2004 01:55

Re: rs6000 stack boundary

> Date: Fri, 30 Apr 2004 18:12:06 -0400
> From: David Edelsohn <dje <at> watson.ibm.com>

> >>>>> Geoff Keating writes:
> 
> Geoff> This isn't right; it's not true that all ELF targets have a 128-bit
> Geoff> stack boundary.  In particular, EABI targets don't.  Remember,
> Geoff> TARGET_ALTIVEC does not change ABI.  The change would be OK if it
> Geoff> didn't have the TARGET_ALTIVEC part.  (Note that the sysv4.h
> Geoff> definition of STACK_BOUNDARY was correct.)
> 
> 	TARGET_ALTIVEC cannot work without some form of stricter
> alignment.  It is fine to separate the ABI in theory, but the alignment
> requirements and truncated displacements of Altivec instructions forces
> stricter alignment for Altivec variables.

I agree, but the correct behaviour if the alignment can't be achieved is
to warn about the user's incompatible choice of options, not silently
generate code that assumes an alignment greater than actually exists.

> 	Are STARTING_FRAME_OFFSET and STACK_DYNAMIC_OFFSET sufficient?
> Remember that Darwin has enforced a stricter alignment for all
> applications and something similar is needed for SVR4 when Altivec is
> enabled. 

I think they are not sufficient.  I believe that GCC does not have
full support for creating a stack alignment greater than the
pre-existing one in the procedure prolog.  It might actually not be
that hard to make the prolog/epilog code do it, but I don't think it'd
be that useful, since the only case where this is necessary is for
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Edelsohn | 1 May 2004 02:40
Picon
Favicon

Re: rs6000 stack boundary

>>>>> Geoff Keating writes:

Geoff> I agree, but the correct behaviour if the alignment can't be achieved is
Geoff> to warn about the user's incompatible choice of options, not silently
Geoff> generate code that assumes an alignment greater than actually exists.

	TARGET_ALTIVEC_ABI implies more than just correct alignment, it
affects argument passing and vrsave as well.  I think issue this may be
confusion about TARGET_ALTIVEC actually implies.

David
Permalink | Reply | 0 comments |
headers
Andrew Pinski | 1 May 2004 02:47
Picon

[PATCH] [committed] Fix PR target/11608 testcases fails with -gstabs1 on sh*-elf

The problem is that Letext label is already used a new label needs some 
about.
This patch fixes this by using asm_fprintf instead of fprintf and 
%LLetext instead
of just Letext just like config/dbxelf.h does.

Committed as obvious and Dan Kegel said it fixes the testcases on 
sh-elf.

Thanks,
Andrew Pinski

ChangeLog:

	* config/sh/elf.h (DBX_OUTPUT_MAIN_SOURCE_FILE_END): Update and make it
	more like the one in config/dbxelf.h.

Index: elf.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sh/elf.h,v
retrieving revision 1.32
diff -u -p -r1.32 elf.h
--- elf.h	27 Sep 2003 04:48:28 -0000	1.32
+++ elf.h	2 Jan 2004 07:23:23 -0000
 <at>  <at>  -95,7 +95,7  <at>  <at>  while (0)
  #define DBX_OUTPUT_MAIN_SOURCE_FILE_END(FILE, FILENAME)			\
  do {									\
    text_section ();							\
-  fprintf ((FILE), "\t.stabs \"\",%d,0,0,Letext\nLetext:\n", N_SO);	\
+  asm_fprintf ((FILE), "\t.stabs \"\",%d,0,0,%LLetext\n%LLetext:\n",
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kaz Kojima | 1 May 2004 03:26
Picon

Re: [PATCH/RFC] PR target/15130 SH: A tail call optimization

Joern Rennecke <joern.rennecke <at> superh.com> wrote:
> The patch as such look OK, however, as a re-read the code that you are
> patching, it appears to me that we have a latent bug here, which will
> be made worse by your patch.
> We are testing only for the general purpose registers used up by DImode
> values (or smaller).  This seems to always give you r2.
> If the function returns a 128 bit value in general purpose registers,
> e.g. CDImode, TImode, or DCmode (the latter for soft floating point),
> then r2 is live.

Sure.  The appended patch is revised one.  Does it looks ok?

Regards,
	kaz
--
	* config/sh/sh.c (output_stack_adjust): Get a temporary	register
	by scan for epilogue when sibling call optimization is enabled.
	Take account of parmeter registers and static-chain register
	for that case.  Compute the correct number of general registers
	for the return value.

--- ORIG/gcc-3.4.0/gcc/config/sh/sh.c	2004-03-09 12:00:12.000000000 +0900
+++ LOCAL/gcc-3.4.0/gcc/config/sh/sh.c	2004-05-01 09:10:06.000000000 +0900
 <at>  <at>  -4571,7 +4571,8  <at>  <at>  output_stack_adjust (int size, rtx reg, 
 	  /* If TEMP is invalid, we could temporarily save a general
 	     register to MACL.  However, there is currently no need
 	     to handle this case, so just abort when we see it.  */
-	  if (current_function_interrupt
+	  if ((epilogue_p && flag_optimize_sibling_calls)
+	      || current_function_interrupt
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jason Merrill | 1 May 2004 03:58
Picon
Favicon

Re: fix PR 14718

OK.

Jason
Permalink | Reply | 0 comments |

Gmane