Re: Handling of extern inline in c99 mode

[Jakub Jelinek]

On Wed, Nov 01, 2006 at 08:02:55AM -0800, Ian Lance Taylor wrote:
> 1) Implement a function attribute which is the equivalent of "extern
>inline".  Backport support for this attribute to all open branches.
>Try to persuade the glibc developers to use this feature instead of
>"extern inline" when it is available, by adjusting the handling of
>__USE_EXTERN_INLINES in features.h and elsewhere.

Backporting the attribute to all open branches isn't necessary,
glibc (and all other packages that use extern inline in their headers,
there are plenty of them) can conditionalize it on GCC version and
flags, something like:

/* GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO C99
   inline semantics.  */
#if __GNUC_PREREQ (4,3) && defined (__STDC__VERSION__) \
&& __STDC_VERSION__ >= 199901L
# define __extern_inline __attribute__((__extern_inline__)) __inline
# define __extern_always_inline __attribute__((__extern_inline__)) 
__always_inline
#else
# define __extern_inline extern __inline
# define __extern_always_inline extern __always_inline
#endif

and just use __extern_inline or __extern_always_inline instead
of current uses of __inline resp. extern __always_inline.

Jakub

Re: Handling of extern inline in c99 mode

[Jakub Jelinek]

On Wed, Nov 01, 2006 at 03:05:33PM -0800, Mark Mitchell wrote:
> I think it would be better to have GLIBC changed before changing the 
> behavior of the compiler.  It might even be better to have a released 
> version of GLIBC with the changes.  fixincludes causes sufficient 
> problems for people that ensuring that only users putting new compilers 
> on old systems suffer might be a good goal.

If we have an attribute for the old GNU extern inline semantics,
I think the GLIBC header changes could be backported to glibc-2_5-branch
once they hit GLIBC trunk and GLIBC 2.5.1 release could include them,
so this can be a matter of weeks or at most a few months.
There are other packages that use extern inline though.

Jakub

Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility

[Jakub Jelinek]

On Tue, Nov 07, 2006 at 10:59:05AM +0100, FX Coudert wrote:
> {
>   st_parameter_common common;
>   GFC_IO_INT rec;
>   [...lots of other struct members...]
>   /* Private part of the structure.  The compiler just needs
>  to reserve enough space.  */
> union
> {
>   struct
> {
>   [... the private stuff ...]
> } p;
>   /* This pad size must be equal to the pad_size declared in
>  trans-io.c (gfc_build_io_library_fndecls).  The above  
> structure
>  must be smaller or equal to this array.  */
>   char pad[16 * sizeof (char *) + 32 * sizeof (int)];
> } u;
> }
> st_parameter_dt;
> 
> The idea is that common.flags has a bit for every possible member  
> such as rec, to indicated whether it's present or not. The question  
> is that we sometimes need to add another struct member (like rec) in  
> this structure, to implement new features. I think we can add it at  
> the end, since when code generated by older compilers calls the  
> library, the flag for that new member is not set, and the struct  
> member is never accessed.

I designed it this way so that it is as fast as possible (can be
on the caller's stack and as few fields in the memory have to
be written as possible (the older struct was always cleared as whole)).

I think you generally can only keep backwards compatibility, not forward
compatibility (so gfortran 4.3 compiled objects should work with libgfortran
4.3, 4.4 etc., but 4.4 compiled objects if there were changes in the
struct shouldn't be expected to work with libgfortran 4.3).
This can be handled by symbol versioning, which I saw patches floating
around for.

If you want to add over time new fields, if there is space in
common.flags, you just define a new bit there and add the new field
to the end of u.p structure if there is space for it.  That's the
easy part.

If you are out of common.flags bits (or just one is left), you should
add another flags field and use the last bit in common.flags to
say "flags2 field is present".

For private space (i.e. something that you want to carry over from one
call with the same st_parameter_* argument to another with the same
argument), you can reuse all fields that aren't needed by the second
and following calls nor are used for returning value to the caller,
so if there is e.g. a field used for parameter which is only needed
by the initial call, you can just reuse it.  But, when you finally
run out of space in the struct, you can just increase the padding
and use another bit in common.flags (or flags2 when you get to it)
to say the whole struct is bigger.  Usually you will need extra
space only to implement new functionality (which has to be requested
by the caller), so if all that implementation is conditionalized
on some common.flags resp. flags2 bit, you should be backwards
compatible.  If you need extra space even for the backwards compatible
stuff, first try to move private things around so that stuff
that can be conditionalized on common.flags or flags2 bit is used
in the newly added memory space.  If even that fails, you can just
malloc/free a pointer to extra area if the bit which says the struct
is too short isn't set.

In any case, with symbol versioning when adding new feature bits
you should bump symbol version and add compatibility alias.

Say in GCC 4.5 you want to add new fields to struct st_parameter_open.
There is a free bit in common.flags, so you just allocate new
IOPARM_OPEN_HAS_FOOBAR bit and add foobar field at the end.
But, because libgfortran 4.4 won't grok that bit, you really
want to avoid GCC 4.5 compiled code to use libgfortran 4.4
_gfortran_st_open (== all routines that use the st_parameter_open
structure).  So, you have
internal_st_open (...)
{
  function definition;
}
#ifdef HAVE_SYMBOL_VERSIONING
extern __typeof (internal_st_open) st_open_4_5 __attribute__((alias 
("internal_st_open")));
extern __typeof (internal_st_open) st_open_4_3 __attribute__((alias 
("internal_st_open")));
asm (".symver st_open_4_5, _gfortran_st_open@@GFORTRAN_4.5");
asm (".symver st_open_4_3, [EMAIL PROTECTED]");
#endif

The two versioned symbols can have the same value if the new
st_open implementation is backwards but not forward compatible.

Jakub

Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility

[Jakub Jelinek]

On Tue, Nov 07, 2006 at 02:38:39AM -0800, Mike Stump wrote:
> >Now, we also sometimes want to increase the size of the private  
> >stuff, and I don't see how we can do that in a way that keeps ABI  
> >compatibility, because the bits in the private stuff are always  
> >used by the library. So, I am missing something here or is there  
> >actually no way to keep that scheme and have ABI compatibility?
> 
> A layer of indirection can solve almost any problem:
> 
> st_parameter_dt *parm = __gfortran_st_parameter_dt_factory ();

That would slow things down a lot.  This would mean you need to malloc
it, use it, then have some call which frees it at the end.

Jakub

Re: Aliasing: reliable code or not?

[Jakub Jelinek]

On Tue, Nov 28, 2006 at 11:36:19PM -0800, Ian Lance Taylor wrote:
> Or you can use constructor expressions to make this slightly more
> elegant, though I retain the assumptions about type sizes:
> 
> char *foo1(char* buf){
>   memcpy(buf, (char[]) { 42 }, 1);
>   buf += 1;
>   memcpy(buf, (short[]) { 0xfeed }, 2);
>   buf += 2;
>   memcpy(buf, (int[]) { 0x12345678 }, 4);
>   buf += 4;
>   memcpy(buf, (int[]) { 0x12345678 }, 4);
>   buf += 4;
>   return buf;
> }

Or even use mempcpy to make it even more compact:

char *
foo1 (char *buf)
{
  buf = mempcpy (buf, (char[]) { 42 }, 1);
  buf = mempcpy (buf, (short[]) { 0xfeed }, 2);
  buf = mempcpy (buf, (int[]) { 0x12345678 }, 4);
  buf = mempcpy (buf, (int[]) { 0x12345678 }, 4);
  return buf;
}

Jakub

Re: [Bug middle-end/29695] [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ? 0x80 : 0 for unsigned char or unsigned short a

[Jakub Jelinek]

On Fri, Dec 01, 2006 at 12:07:18AM -, chaoyingfu at gcc dot gnu dot org 
wrote:
> 
> 
> --- Comment #6 from chaoyingfu at gcc dot gnu dot org  2006-12-01 00:07 
> ---
> Subject: Bug 29695
> 
> Author: chaoyingfu
> Date: Fri Dec  1 00:05:26 2006
> New Revision: 119383
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119383
> Log:
> Merged revisions 118455-118543 via svnmerge from 
> svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk

Please, when svn merging to private branches never use all the ChangeLog entries
in svn commit messages (it is excessively huge anyway and
Merged revisions 118455-118543 via svnmerge from
svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk
information is all that is needed), or at least remove
all PR references from it, as it spams all the PR pages.

Jakub

Re: Unwinding CFI gcc practice of assumed `same value' regs

[Jakub Jelinek]

On Mon, Dec 11, 2006 at 02:40:22PM -0800, Roland McGrath wrote:
> My reading is that the "ABI authoring body" for GNU systems or the
> "compilation system authoring body" for GNU compilers already specifies
> that the default rule is same_value for callee-saves registers (as chosen
> by each particular ABI), even if this has not been formally documented
> anywhere heretofore.  (This is how I've written ABI support in another
> unwinder implementation I've worked on.)  As you've said, this is the only
> reading by which current CFI is correct and complete for getting the values
> of callee-saves registers.  I presume that GCC's omission of rules for
> those registers is in fact simply because EH unwinding doesn't care and
> people on the generation side just didn't think about it beyond that.
> Regardless of the true reasons for the history, the description above
> applies to the manifest practice that constitutes what we want the formal
> specification to mean.

Well, for satisfying the requirement that undefined retaddr_column
identifies outermost frame it matters whether retaddr_column's default rule
is same_value or undefined.  If it is by default same_value, then
unwind-dw2.c should just handle explicit DW_CFA_undefined retaddr_column
as outermost frame mark, otherwise it would need to handle any unspecified
or explicit DW_CFA_undefined retaddr_column (but not DW_CFA_same_value).
Here is something that would handle by default same_value retaddr_column:

--- gcc/unwind-dw2.h2006-10-29 21:49:23.0 +0100
+++ gcc/unwind-dw2.h2006-12-12 16:30:29.0 +0100
@@ -1,5 +1,5 @@
 /* DWARF2 frame unwind data structure.
-   Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003
+   Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2006
Free Software Foundation, Inc.
 
This file is part of GCC.
@@ -55,7 +55,8 @@ typedef struct
REG_SAVED_REG,
REG_SAVED_EXP,
REG_SAVED_VAL_OFFSET,
-   REG_SAVED_VAL_EXP
+   REG_SAVED_VAL_EXP,
+   REG_UNDEFINED
   } how;
 } reg[DWARF_FRAME_REGISTERS+1];
 
--- gcc/unwind-dw2.c2006-12-08 15:57:44.0 +0100
+++ gcc/unwind-dw2.c2006-12-12 16:38:26.0 +0100
@@ -887,12 +887,16 @@ execute_cfa_program (const unsigned char
  fs->regs.reg[DWARF_REG_TO_UNWIND_COLUMN(reg)].how = REG_UNSAVED;
  break;
 
-   case DW_CFA_undefined:
case DW_CFA_same_value:
  insn_ptr = read_uleb128 (insn_ptr, ®);
  fs->regs.reg[DWARF_REG_TO_UNWIND_COLUMN(reg)].how = REG_UNSAVED;
  break;
 
+   case DW_CFA_undefined:
+ insn_ptr = read_uleb128 (insn_ptr, ®);
+ fs->regs.reg[DWARF_REG_TO_UNWIND_COLUMN(reg)].how = REG_UNDEFINED;
+ break;
+
case DW_CFA_nop:
  break;
 
@@ -1255,6 +1259,7 @@ uw_update_context_1 (struct _Unwind_Cont
 switch (fs->regs.reg[i].how)
   {
   case REG_UNSAVED:
+  case REG_UNDEFINED:
break;
 
   case REG_SAVED_OFFSET:
@@ -1323,10 +1328,21 @@ uw_update_context (struct _Unwind_Contex
 {
   uw_update_context_1 (context, fs);
 
-  /* Compute the return address now, since the return address column
- can change from frame to frame.  */
-  context->ra = __builtin_extract_return_addr
-(_Unwind_GetPtr (context, fs->retaddr_column));
+  /* In general this unwinder doesn't make any distinction between
+ undefined and same_value rule.  Call-saved registers are assumed
+ to have same_value rule by default and explicit undefined
+ rule is handled like same_value.  The only exception is
+ DW_CFA_undefined on retaddr_column which is supposed to
+ mark outermost frame in DWARF 3.  */
+  if (fs->regs[fs->retaddr_column].how == REG_UNDEFINED)
+/* uw_frame_state_for uses context->ra == 0 check to find outermost
+   stack frame.  */
+context->ra = 0;
+  else
+/* Compute the return address now, since the return address column
+   can change from frame to frame.  */
+context->ra = __builtin_extract_return_addr
+  (_Unwind_GetPtr (context, fs->retaddr_column));
 }
 
 static void


Jakub

Re: Unwinding CFI gcc practice of assumed `same value' regs

[Jakub Jelinek]

On Tue, Dec 12, 2006 at 03:26:34PM +, Andrew Haley wrote:
> Ulrich Drepper writes:
>  > Andrew Haley wrote:
>  > > Null-terminating the call stack is too well-established practice to be
>  > > changed now.
>  > 
>  > Which does not mean that the mistake should hold people back.
> 
> Sure it does.  Not breaking things is an excellent reason, probably
> one of the the best reasons you can have.

Well, libgcc unwinder handles neither %rbp 0 termination (even
if that would be rephrased as outermost frame on x86-64 is determined
by %rbp == 0 if CFA is %rbp + offset (that would handle the
-fomit-frame-pointer routines where CFA is %rsp + offset)), nor
DW_CFA_undefined %rip termination ATM.  Things worked until now
simply because the outermost routine (_start resp. thread_start
hunk in clone in glibc) so far didn't have any unwind info.
What would work with stock libgcc unwinder would probably be if
_start or clone's child hunk had %rip point to memory containing 0
or DW_CFA_val_expression returning 0 (well, on SPARC that would
need to be -8, as RETURN_ADDR_OFFSET is added to it).

Jakub

Re: cross mode -fstack-protector ?

[Jakub Jelinek]

On Wed, Jan 17, 2007 at 11:15:55AM +0200, Balint Cristian wrote:
>  Is it a bug ?
> 
>  Maybe i still dont understand how this is emmited, but anyone knows why a
> cross-compiler vs normal compiler using the -fstack-protector option why
> will act differnetly ?
> 
> e.g nm on same object compiled with:
>  cross:
>   U __stack_chk_fail
>   U __stack_chk_guard
>  native:
>  U __stack_chk_guard
> 
>  somehow the cross one still put outside reference to __stack_chk_fail ...

Badly configured cross?
The configure check in question is:

case "$target" in
  *-*-linux*)
AC_CACHE_CHECK(__stack_chk_fail in target GNU C library,
  gcc_cv_libc_provides_ssp,
  [gcc_cv_libc_provides_ssp=no
  if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
if test "x$with_sysroot" = x; then
  glibc_header_dir="${exec_prefix}/${target_noncanonical}/sys-include"
elif test "x$with_sysroot" = xyes; then
  
glibc_header_dir="${exec_prefix}/${target_noncanonical}/sys-root/usr/include"
else
  glibc_header_dir="${with_sysroot}/usr/include"
fi
  else
glibc_header_dir=/usr/include
  fi
  # glibc 2.4 and later provides __stack_chk_fail and
  # either __stack_chk_guard, or TLS access to stack guard canary.
  if test -f $glibc_header_dir/features.h \
 && $EGREP '^@<:@   @:>@*#[ ]*define[   
]+__GNU_LIBRARY__[  ]+([1-9][0-9]|[6-9])' \
$glibc_header_dir/features.h > /dev/null; then
if $EGREP '^@<:@@:>@*#[ ]*define[   ]+__GLIBC__[
]+([1-9][0-9]|[3-9])' \
   $glibc_header_dir/features.h > /dev/null; then
  gcc_cv_libc_provides_ssp=yes
elif $EGREP '^@<:@  @:>@*#[ ]*define[   ]+__GLIBC__[
]+2' \
 $glibc_header_dir/features.h > /dev/null \
 && $EGREP '^@<:@   @:>@*#[ ]*define[   
]+__GLIBC_MINOR__[  ]+([1-9][0-9]|[4-9])' \
 $glibc_header_dir/features.h > /dev/null; then
  gcc_cv_libc_provides_ssp=yes
fi
  fi]) ;;
  *) gcc_cv_libc_provides_ssp=no ;;
esac

so when your cross is not --with-sysroot, you should have your
target glibc headers in /usr/sparc-redhat-linux/sys-include
before configure.

Jakub

Re: Failure to build libjava on 512MB machine

[Jakub Jelinek]

On Wed, Jan 31, 2007 at 11:42:12AM +, Andrew Haley wrote:
> Andrew Haley writes:
>  >  > 
>  >  > It does look like we are scaring away some people with the long
>  >  > build times and memory hungry build of libjava. I only started
>  >  > building libgcj again recently when I got a
>  >  > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an
>  >  > compile/install/test cycle is not something I want to do more than
>  >  > once or twice a day.
>  > 
>  > I'm surprised: the libgcj build takes about 15mis on my box, which is
>  > similar to yours.
> 
> Actually, it used to take that long, but libgcj is a lot bigger these
> days.  I will re-measure.

It takes 29 minutes for me on the trunk, with disabled java maintainer
mode.  Multilib (-m64/-m32) build on 2.66GHz/64-bit/quad-core/2GB machine.

Jakub

Re: gcc-4.3, glibc and AC_PROG_CC_STDC

[Jakub Jelinek]

On Sun, Feb 11, 2007 at 09:51:33PM -0800, Paul Eggert wrote:
> > Given that there is still discussion and work on GCC for this topic
> > anyway[1], I don't think Autoconf should be doing anything just yet.

Yeah, it is just too early.

> Both of the solutions that Bruno suggested seem too drastic to me as
> well.  I hope we can come up with something less intrusive.
> 
> Once GCC 4.3 settles down, perhaps we can work around any remaining
> problems with gnulib's wchar module.

When GCC implements -fgnu-extern-inline switch (or -fgnu89-extern-inline?),
glibc will likely switch to using that switch when building itself
and adding gnu_inline attributes to installed headers.

> But for this case I'm
> inclined to ask, along with Ralf, why GCC 4.3 doesn't apply
> fixincludes to the troublesome include files.

fixinclude is applied by gcc 4.3, but incorrectly.  It edits a few headers
by removing extern keyword for __STDC__ >= 199901L from extern inline
and for the biggest part it just disables glibc optimizations.
The right fix there is to do nothing if __extern_inline macro is
already defined (that means the headers are using gnu_inline attribute
as appropriate) and otherwise add gnu_inline attribute to all extern
inlines.

Jakub

Re: How should __attribute__ ((gnu_inline)) behave?

[Jakub Jelinek]

On Tue, Feb 13, 2007 at 06:21:41PM -0800, Ian Lance Taylor wrote:
> Should __attribute__ ((gnu_inline)) be treated the same as a gnu89
> extern inline definition?  Or should the extern part be optional?
> That is, should there be a difference between these two definitions?
> 
>   extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
>   __attribute__ ((gnu_inline)) inline int foo () { return 0; }

The gnu_inline attribute was meant to be a modifier for the inline
keyword, that would make it behave with GNU89 inline semantics.
So, extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
in -std=gnu99 mode is exactly the same as extern inline int foo () { return 0; }
in -std=gnu89 mode, similarly for
__attribute__ ((gnu_inline)) inline int foo () { return 0; } in -std=gnu99
vs. inline int foo () { return 0; } in -std=gnu89, etc.
The gnu_inline attribute should e.g. allow adding:
#define inline inline __attribute__ ((gnu_inline))
getting the same inline behavior as -std=gnu89 code (unless you #undef
it).

The testsuite/gcc.dg/inline-17.c testcase already verifies this.

Jakub

Re: GCC 4.2.0 Status Report (2007-02-19)

[Jakub Jelinek]

On Wed, Feb 21, 2007 at 08:49:38AM -0800, Mark Mitchell wrote:
> I don't know how to evaluate Danny B's claims that these things are
> rare.  We don't have nearly as a big a customer base as Red Hat or SuSE,
> and our customer base compiles a different class of applications on
> different hardware, so that may explain the differences.

I think we haven't encountered any 4.1.x aliasing bug on our distribution
or its aux repositories and we had just one report about an 4.1.x aliasing
bug reported to us (forwarded as PR30708, but was actually just an ALTlinux
bugreport they tried with our gcc as well and so reported to us).
So, I'd agree with Danny B that the problems are quite rare and the
performance hit is IMHO too big for fixing the bugs.  Every released GCC had
a bunch of wrong-code bugs, we of course need to try to fix them but in each
case need to look whether the cons of the fix don't outweight the benefit.

Jakub

Re: Question for removing trailing whitespaces (not vertical tab) from source

[Jakub Jelinek]

On Tue, Mar 13, 2007 at 03:22:50PM +, Andrew Haley wrote:
> Feel free to do it to your local copy.  Don't do it to the gcc source
> code repository.

Well, please do it on all your checkings - all lines you have changed
to fix some bug or add a new feature shouldn't have trailing whitespace
and in the leading whitespace should use tabs instead of 8 spaces.
But please don't change lines that wouldn't be otherwise touched just
to change their formatting.

Jakub

Re: libgomp failures on powerpc-apple-darwin8

[Jakub Jelinek]

On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote:
> Interestingly, while...
> 
> gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp 
> -lstdc++ -lm -m32 -o ./pr30703.exe
> /usr/bin/ld: Undefined symbols:
> __Unwind_Resume
> collect2: ld returned 1 exit status
> 
> fails on powerpc-apple-darwin8
> 
> gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp 
> -lstdc++ -lm -m32 -shared-libgcc  -o ./pr30703.exe
> 
> ...links fine. On powerpc-apple-darwin8, libgcc.a is missing __Unwind_Resume. 
> I wonder why this doesn't show up
> on any other architectures?

Because libstdc++.so links against libgcc_s.so.1 which exports that symbol
(was linked with -shared-libgcc).  Or, on ELFish targets that use recent
binutils when neither -shared-libgcc nor -static-libgcc is used,
libgcc_s.so.1 is linked in --as-needed.
libgcc.a doesn't contain the unwinder on purpose, it is only in libgcc_s.so
and libgcc_eh.a, so that every binary or library doesn't have its own copy
of the unwinder (which causes severe problems).

Jakub

Re: We're out of tree codes; now what?

[Jakub Jelinek]

On Tue, Mar 20, 2007 at 08:56:10AM -0400, Kaveh R. GHAZI wrote:
> We've been considering two solutions, the 9 bit codes vs the subcode
> alternative.
> 
> The 9 bit solution is considered simpler and without any memory penalty
> but slows down the compiler and doesn't increase the number of codes very
> much.  The subcodes solution increases memory usage (and possibly also
> slows down the compiler) and is more complex and changes are more
> pervasive.

But the subcodes approach would be only applied to the less often used
codes and ideally within the frontends only.  So the memory hit shouldn't be
as big as e.g. going to 16 bit tree codes if that means increasing the size
of most of the trees the compiler uses.

Jakub

Re: We're out of tree codes; now what?

[Jakub Jelinek]

On Tue, Mar 20, 2007 at 09:37:38AM -0400, Doug Gregor wrote:
> Even if we only use subcodes for the less often used codes, I think we
> still take the performance hit. The problem is that it's very messy to

I'm sure smaller hit than when going to 9 bit tree code, and on i386/x86_64
maybe even than 16 bit tree code (if I remember well, 8-bit and 32-bit
accesses are usually faster than 16-bit ones).

> deal with a two-level code structure inside, e.g., the C++ front end.
> I did a little experiment with a very rarely used tree code
> (TYPEOF_TYPE), and the results weren't promising:
> 
>  http://gcc.gnu.org/ml/gcc/2007-03/msg00493.html

If you use what has been suggested, i.e.:
#define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ? 
((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE))
then it shouldn't be so big.  Everywhere where you don't need >= 256
codes you'd just keep using TREE_CODE, only if e.g. some
switch contains >= 256 FE specific subcodes you'd use LANG_TREE_CODE
instead of TREE_CODE.  GCC would warn you if you forget to use
LANG_TREE_CODE even when it is needed, at least in switches, you'd get
warning: case label value exceeds maximum value for type

Jakub

Re: We're out of tree codes; now what?

[Jakub Jelinek]

On Tue, Mar 20, 2007 at 11:04:16AM -0600, Kevin Handy wrote:
> >#define LANG_TREE_CODE(NODE) (TREE_CODE (NODE) == LANG_CODE ? 
> >((tree_with_subcode *)(NODE))->subcode : TREE_CODE (NODE))
> >  
> This subcode idea feels like a bug attractor to me.
> 
> For example: #defines have enough problems with
> side effects, and this references NODE twice, so
> what happens when NODE is a function of some
> kind, or has other side effects?

Just look quickly at tree.h, there are plenty of other macros already
that evaluate their arguments multiple times.

> >switch contains >= 256 FE specific subcodes you'd use LANG_TREE_CODE
> >instead of TREE_CODE.  GCC would warn you if you forget to use
> >LANG_TREE_CODE even when it is needed, at least in switches, you'd get
> >warning: case label value exceeds maximum value for type
> >  
> I'd expect that the TREE_CODE would be referenced
> more often in comparisons, than in switch statements.
> These probably wouldn't generate the warning.

That warns too, see (-Wall):
enum foo
{
  A=0,
  B=1,
  C=2,
  X=254,
  Y=255
};
struct tree
{
  enum foo code : 8;
};
extern void bar (void);
void foo (struct tree *t)
{
  switch (t->code)
{
case C:
  break;
case 512:
  bar ();
  break;
case 1081:
  break;
}
  if (t->code == 1024)
bar ();
  if (t->code != 1035)
bar ();
}

Jakub

Re: Segfault on OpenMP program

[Jakub Jelinek]

On Wed, Apr 18, 2007 at 02:38:24PM +0100, Paul Brook wrote:
> On Wednesday 18 April 2007 00:19, FX Coudert wrote:
> > Someone reported on bug on a trivial statically-linked Fortran progam
> > with OpenMP and a I/O operation. I can reproduce the segfault, which
> > happens at:
> >...
> > Andrew suggested on bugzilla that this might be a GLIBC issue (I use
> > glibc-2.4 from redhat), with "pthreads not linking in correctly".
> > Does this ring a bell? Can someone confirm that it's not a GCC issue
> > (or that it is)? Details can be found in PR 31604.
> 
> The answer to any question involving glibc and static linking is 
> generally "don't do that".

Yeah, especially anything involving libpthread.  As a workaround you can
link whole libpthread.a in (... -static ... -Wl,--whole-archive -lpthread \
-Wl,--no-whole-archive) but even that it really is not supported, if it
works for you, fine, though even then you should study all the reasons why
we don't recommend static linking, if it doesn't, just link dynamically.

Jakub

Re: Segfault on OpenMP program

[Jakub Jelinek]

On Wed, Apr 18, 2007 at 07:38:40PM +0200, Kenneth Hoste wrote:
> Is this only advised with parallel programs, or is it a general rule?
> In my research, I statically link all my benchmarks because that I  
> measure stuff about them using instrumentation on a bunch of computer  
> (which might have various OSs, OS versions, libc versions, ...).  
> Because we want to analyze the same dynamic executed code over and  
> over again (no matter on which machine the analysis is donne), I use  
> static linking.

General rule.  Statically linked programs are actually far more dependent
on the environment they are compiled in rather than less dependent,
please read e.g. http://people.redhat.com/drepper/no_static_linking.html

> - How can I easily dynamically link against libc, but statically link  
> with everything else? Currently, making everything statically linked  
> is easy: in the various makefiles I set CC="gcc -static". Is there a  
> similar 'trick' to link libc dynamically but everything else  
> statically? (I'm using GCC 4.1.2 if it matters)

The libraries which you want to link statically into the application
just mention between -Wl,-Bstatic ... -Wl,-Bdynamic on the command line.
So say 
gcc -o foo . -Wl,-Bstatic -lfoo -lbar -lbaz -Wl,-Bdynamic -ldl -lpthread
will link libfoo, libbar and libbaz into the application and libdl,
libpthread, libc dynamically.

Jakub

Re: Hot and Cold Partitioning (Was: GCC 4.1 Projects)

[Jakub Jelinek]

On Mon, Feb 28, 2005 at 12:43:35PM +, Joern RENNECKE wrote:
> Well, even then, using of the cold section can increase the hot section 
> size, depending on target, and for some
> targets the maximum supported distance of the cold section.
> 
> For SH, using the cold section, you get (for non-PIC):
> 
> L2: mov.l 0f,rn
>jmp @rn
>nop
>.balign 4
> 0:  .long L3
> 
>.coldsection:
> L3: mov.l 0f,rn
>jmp @rn
>mov #0,rn
>.balign 4
> 0:  .long L1
> 
> I.e. 10 to 12 bytes each in in hot and cold sections.
> 
> Without the cold section, you need only 4 bytes:
> L2: bra L1
>mov #0,rn
> 
> Note also, that in order to avoid the condjump-around-jump syndrome, L2 has
> to be within about +-256 bytes of the condjump.
> Should I do custom basic block reordering in machine_dependent_reorg to 
> clean up
> the turds of hot and cold partitioning?

Its nothing SH specific, this particular example I'd say results in bigger code
in hot section on almost all arches.
The hot&cold partitioning patch simply must have some low bounds on how big
a cold BB must be if moving it to cold partition is worthwhile.

Jakub

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

[Jakub Jelinek]

On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> typedef unsigned int size_t;
> 
> static inline void * __memcpy(void * to, const void * from, size_t n)
> {
> int d0, d1, d2;
> __asm__ __volatile__(
> "rep ; movsl\n\t"
> "testb $2,%b4\n\t"
> "je 1f\n\t"
> "movsw\n"
> "1:\ttestb $1,%b4\n\t"
> "je 2f\n\t"
> "movsb\n"
> "2:"
> : "=&c" (d0), "=&D" (d1), "=&S" (d2)
> :"0" (n/4), "q" (n),"1" ((long) to),"2" ((long) from)
> : "memory");
> return (to);
> }
> 
> /*
>  * This looks horribly ugly, but the compiler can optimize it totally,
>  * as the count is constant.
>  */
> static inline void * __constant_memcpy(void * to, const void * from, size_t n)
> {
> if (n <= 128)
> return __builtin_memcpy(to, from, n);
> 
> #define COMMON(x) \
> __asm__ __volatile__( \
> "rep ; movsl" \
> x \
> : "=&c" (d0), "=&D" (d1), "=&S" (d2) \
> : "0" (n/4),"1" ((long) to),"2" ((long) from) \
> : "memory");
> {
> int d0, d1, d2;
> switch (n % 4) {
> case 0: COMMON(""); return to;
> case 1: COMMON("\n\tmovsb"); return to;
> case 2: COMMON("\n\tmovsw"); return to;
> default: COMMON("\n\tmovsw\n\tmovsb"); return to;
> }
> }
> 
> #undef COMMON
> }
> 
> #define memcpy(t, f, n) \
> (__builtin_constant_p(n) ? \
>  __constant_memcpy((t),(f),(n)) : \
>  __memcpy((t),(f),(n)))
> 
> int f3(char *a, char *b) { memcpy(a,b,3); }

The problem is that in GCC < 4.0 there is no constant propagation
pass before expanding builtin functions, so the __builtin_memcpy
call above sees a variable rather than a constant.

Either use GCC 4.0+, where this works just fine, or move the
n <= 128 case into the macro:
#define memcpy(t, f, n) \
(__builtin_constant_p(n) ? \
 ((n) <= 128 ? __builtin_memcpy(t,f,n) : __constant_memcpy(t,f,n) : \
 __memcpy(t,f,n))

Jakub

Re: Semi-Latent Bug in tree vectorizer

[Jakub Jelinek]

On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> There's a rather annoying bug in the vectorizer which can cause us to
> have SSA_NAMEs which are used, but never defined.
> 
> Consider this testcase compiled with -msse2 -ftree-vectorize:
> 
> typedef char achar __attribute__ ((__aligned__(16)));
> int main1 ()
> {
>   struct {
> achar *p;
> achar *q;
>   } s;
>   int i;
>   achar x[16];
>   achar cb[16];
>   s.p = x;
>   i = 0;
>   do
> {
>   s.p[i] = cb[i];
>   i++;
> } while (i < 16);
> 
>   if (s.p[0])
> abort ();
> }

See middle-end/20794, there is discussion about declaring this
invalid.  When a type with size that is not an integral multiple
of alignment (e.g. smaller size than alignment) is used in an
array, we have the choice either to violate the alignment
request for second and some subsequent array elements,
or make the elements bigger, but then pointer arithmetics
won't work very well.

Jakub

Re: Semi-Latent Bug in tree vectorizer

[Jakub Jelinek]

On Fri, Apr 08, 2005 at 10:11:33AM -0700, Joe Buck wrote:
> On Fri, Apr 08, 2005 at 06:58:54PM +0200, Jakub Jelinek wrote:
> > See middle-end/20794, there is discussion about declaring this
> > invalid.  When a type with size that is not an integral multiple
> > of alignment (e.g. smaller size than alignment) is used in an
> > array, we have the choice either to violate the alignment
> > request for second and some subsequent array elements,
> > or make the elements bigger, but then pointer arithmetics
> > won't work very well.
> 
> The problem, then, is that there's no way for the user to specify
> that we have an array whose beginning has, say, 16-byte alignment,
> but that after that, the elements have their ordinary sizes (meaning
> that subsequent elements are not aligned).

We do.
char array[32] __attribute__ ((__aligned__ (16)));

Tried HEAD/4.0/3.4/3.2/2.96-RH and it works in all of them.

Jakub

Re: GCC 4.0 RC1 Available

[Jakub Jelinek]

On Mon, Apr 11, 2005 at 12:49:39AM +0200, Eric Botcazou wrote:
> sparc-sun-solaris2.9 is OK for C/C++/Objective-C/Ada/F95, except
> 
>   FAIL: gcc.dg/builtin-apply4.c execution test

Is that a regression though?  builtin-apply4.c is a new test.

Jakub

Re: GCC 4.0 RC1 Available

[Jakub Jelinek]

On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
> The first GCC 4.0 candidate is available from:
> 
> /pub/gcc/prerelease-4.0.0-20050410/
> 
> on the usual gcc.gnu.org mirrors:
> 
> http://gcc.gnu.org/mirrors.html
> 
> I would like to know whether or not we have achieved the objective 
> aspects of the release criteria:
> 
> http://gcc.gnu.org/gcc-4.0/criteria.html
> 
> for primary and secondary platforms.  In particular, for primary platforms:
> 
> * The DejaGNU testsuite has been run, and compared with a run of 
> the testsuite on the previous release of GCC, and no regressions are 
> observed.

Just an early warning.
We are seeing (possible) miscompilation of KDE 3.4.0's cssstyleselector.cpp
on i386-linux, a regression between 20050330 (where it worked) and 20050403.
The resulting assembly with 20050403+ is also ~ 17% bigger.
There are no differences in *.generic dump, but already in *.gimple
dump the difference is huge.
We'll keep looking into this.

Jakub

Re: GCC 4.0 RC2

[Jakub Jelinek]

On Tue, Apr 12, 2005 at 10:59:42AM -0700, Mark Mitchell wrote:
> I don't have a date for RC2 yet; that will depend in part on when Jason 
> is able to fix the C++ issues.  However, I would certainly hope that we 
> could get it done shortly.

FYI, I have bootstrapped/regtested 4.0 RC1 with:

> Here are the patches approved thus far for RC2:
> 
> * http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01036.html
> 
>   GLIBC does not compile on S390.
> 
> * http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01015.html
> 
>   Fortran fix.
> 
> * http://gcc.gnu.org/ml/java-patches/2005-q2/msg00088.html
> 
>   Java library patch.

Plus from the patches still in consideration for 4.0 also:

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00321.html

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20929

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01421.html

on {i386,x86_64,ia64,ppc,ppc64,s390,s390x}-linux, no regressions.

Jakub

Re: GCC 4.0 RC2

[Jakub Jelinek]

On Wed, Apr 13, 2005 at 12:37:00PM -0700, Mark Mitchell wrote:
> >>Sadly, it's become clear there's going to have to be a second release
> >>candidate.  In particular, there are some wrong-code bugs that are popping
> >>up on real packages on primary platforms.  Jason Merill is looking into
> >>some of the C++ issues, but he's in Lillehammer this week for the ISO
> >>meeting.

BTW, http://gcc.gnu.org/PR20991 looks like an important newly (mid March)
introduced regression, but unfortunately I'm travelling today and so won't
be able to look at it toda and not sure if tomorrow.
I think we haven't rebuilt all our distro packages after mid March with GCC 4
pre though, so it might very well happen in other packages too.

Jakub

Re: libgcc_s.so 3.4 vs 3.0 compatibility

[Jakub Jelinek]

On Tue, Apr 19, 2005 at 02:23:26PM +0200, Peter FELECAN wrote:
> Currently the libgcc_s.so library has the same version in 3.4 and 4.0,
> i.e libgcc_s.so.1 (SONAME = libgcc_s.so.1).
> 
> Is this as expected?

Yes.

> Are the 2 libraries compatible? Interchangeable? Looking in the map
> file, I don't think so.

There is backwards compatibility.  So you want the latest libgcc_s.so.1
from the compilers used to build your applications.

Jakub

Re: GCC 4.1: Buildable on GHz machines only?

[Jakub Jelinek]

On Fri, Apr 29, 2005 at 10:47:06AM +0100, Andrew Haley wrote:
> Ian Lance Taylor writes:
>  > 
>  > And, yes, we clearly need to do something about the libjava build.
> 
> OK, I know nothing about libtool so this might not be possible, but
> IMO the easiest way of making a dramatic difference is to cease to
> compile every file twice, once with PIC and once without.  There would
> be a small performance regression for statically linked Java apps, but
> in practice Java is very hard to use with static linkage.

Definitely.  For -static you either have the choice of linking the
binary with -Wl,--whole-archive for libgcj.a (and likely other Java libs),
or spend a lot of time adding more and more objects that are really
needed, but linker doesn't pick them up.

For the distribution, we simply remove all Java *.a libraries, but it would
be a build time win if we don't have to compile them altogether.

Jakub

Re: gcc 3.4.2 stack variable lifetime analysis

[Jakub Jelinek]

On Wed, May 04, 2005 at 07:22:12AM -0700, Earl Chew wrote:
> Can anyone tell me if there is a patch for this problem?

Yes, there is:
ftp://sources.redhat.com/pub/gcc/releases/gcc-4.0.0/diffs/gcc-3.4.3-4.0.0.diff.bz2

FYI, this is PR middle-end/9997

> Consider:
> 
> void bar(char*);
> 
> void foo(int x)
> {
> if (x) { char y[4096]; bar(y); }
> else   { char z[4096]; bar(z); }
> }
> 
> Cygwin gcc 3.4.2 -O2 yields:
> 
> pushl   %ebp
> movl$8216, %eax   /* Should be about 4k */
> movl%esp, %ebp
> call__alloca
> 
> PPC cross compiler 3.4.2 -O2 yields:
> 
> cmpwi 7,3,0
> mflr 0
> stwu 1,-8208(1)  /* Should be about 4k */

Jakub

Re: gcc.dg/compat/struct-layout-1.exp does not supported installed-compiler testing

[Jakub Jelinek]

On Mon, May 16, 2005 at 05:26:36PM -0700, Mark Mitchell wrote:
> 2005-05-16  Mark Mitchell  <[EMAIL PROTECTED]>
> 
>   * gcc.dg/compat/generate-random.c (config.h): Do not include.
>   (limits.h): Include unconditionally.
>   (stdlib.h): Likewise.
>   * gcc.dg/compat/generate-random_r.c (config.h): Do not include.
>   (limits.h): Include unconditionally.
>   (stdlib.h): Likewise.
>   * gcc.dg/compat/struct-layout-1.exp: Do not link with libiberty.
>   * gcc.dg/compat/struct-layout-1_generate.c (config.h): Do not include.
>   (limits.h): Include unconditionally.
>   (stdlib.h): Likewise. 
>   (hashtab.h): Do not include.
>   (getopt.h): Likewise.
>   (stddef.h): Include.
>   (hashval_t): Define.
>   (struct entry): Add "next" field.
>   (HASH_SIZE): New macro.
>   (hash_table): New variable.
>   (switchfiles): Do not use xmalloc.
>   (mix): New macro.
>   (iterative_hash): New function.
>   (hasht): Remove.
>   (e_exists): New function.
>   (e_insert): Likewise.
>   (output): Use, instead of libiberty hashtable functions.
>   (main): Do not use getopt.  Do not call htab_create.

Thanks.

> + static hashval_t
> + iterative_hash (const void *k_in /* the key */,
> + register size_t  length /* the length of the key */,
> + register hashval_t initval /* the previous hash, or
> +   an arbitrary value */)
> + {
> +   register const unsigned char *k = (const unsigned char *)k_in;
> +   register hashval_t a,b,c,len;
> + 
> +   /* Set up the internal state */
> +   len = length;
> +   a = b = 0x9e3779b9;  /* the golden ratio; an arbitrary value */
> +   c = initval;   /* the previous hash value */
> + 
> +   /* handle most of the key */
> + #ifndef WORDS_BIGENDIAN
> +   /* On a little-endian machine, if the data is 4-byte aligned we can hash
> +  by word for better speed.  This gives nondeterministic results on
> +  big-endian machines.  */

WORDS_BIGENDIAN is not being defined in the headers that are included.
I think best would be just to kill this hunk and unconditionally do it the
slower way.

> +   if (sizeof (hashval_t) == 4 && (((size_t)k)&3) == 0)
> + while (len >= 12)/* aligned */
> +   {
> + a += *(hashval_t *)(k+0);
> + b += *(hashval_t *)(k+4);
> + c += *(hashval_t *)(k+8);
> + mix(a,b,c);
> + k += 12; len -= 12;
> +   }
> +   else /* unaligned */
> + #endif
> + while (len >= 12)
> +   {
> + a += (k[0] +((hashval_t)k[1]<<8) +((hashval_t)k[2]<<16) 
> +((hashval_t)k[3]<<24));
> + b += (k[4] +((hashval_t)k[5]<<8) +((hashval_t)k[6]<<16) 
> +((hashval_t)k[7]<<24));
> + c += (k[8] +((hashval_t)k[9]<<8) 
> +((hashval_t)k[10]<<16)+((hashval_t)k[11]<<24));
> + mix(a,b,c);
> + k += 12; len -= 12;
> +   }

Jakub

Why doesn't gcc.pot use gcc-internal-format?

[Jakub Jelinek]

Hi!

Bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
shows that it is very dangerous to not check format strings
in translations.  No translation of a particular message is always
better than a bad translation that causes compiler crash.

Now, looking at gettext, it seems to support GCC internal
message format, although older one (3.3.x - it doesn't grok e.g. %J,
q, ll and w format flags, %<, %>, %').

exgettext would probably need to pass --flag options in $kopt
(not sure if that needs to be in addition to --keyword or in addition to).

Jakub

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Jakub Jelinek]

On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:
> Could there please at some point be serious discussion of making this a
> supported way of working? In this case dl_iterate_phdr is weak so could
> the decision about whether to use it or not could be made at runtime, not
> build time?

It can't, this decision must be done at compiler configuration time.
Compiler built in presence of dl_iterate_phdr creates binaries and shared
libraries, that rely on its presence in target glibc, as support code
for older glibc's is intentionally left out in that case.

BTW, all glibc versions are really only backwards compatible, not forward
compatible, new symbols are added through symbol versioning all the time.

You can always install into a chroot an older distribution and compile/link
programs in there if you want one library or binary to work with multiple
OS releases.

Jakub

Re: 4.0 regression: missing debug info for global variables in C with -O2

[Jakub Jelinek]

On Mon, May 30, 2005 at 10:13:19PM +0200, Ulrich Weigand wrote:
> Andrew Pinski wrote:
> 
> > You can reproduce it using:
> > static int i;
> > int main(void)
> > {
> >i += 3;
> >i *= 5;
> >return 0;
> > }
> > 
> > and readelf and looking for the DW_TAG_variable tag.
> 
> Yes; in fact 'main' is even superfluous.  Just compile
> 
>   int var;
> 
> with -S -O2 -g on gcc 3.4 and 4.0 and look at the resulting
> assembler file, the difference is quite obvious ...

BTW, I tried to understand what the PR18556 problem was, but
apparently reverting the PR18556 patch makes zero difference
on eh53.C -fexceptions -g.

Even if PR18556 is still needed for C++, we could perhaps
check cgraph_global_info_ready before setting DECL_IGNORED_P,
assuming this hunk makes no sense for C code.  Reordering
cgraph_optimize and c_write_global_declarations_1 might be
too risky for 4.0 I'm afraid (the C++ frontend apparently
first calls cgraph_optimize and then wrapup_globals_for_namespace
plus check_global_declarations).

Jakub

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Jakub Jelinek]

On Tue, May 31, 2005 at 07:20:49PM +0200, Vincent Lefevre wrote:
> On 2005-05-31 17:10:58 +0200, Andreas Schwab wrote:
> > Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> > > "Portability" means different things to different people. There's a
> > > difference between source code portability and "result" portability.
> > 
> > But making round to double the default makes it only worse in this case,
> > since there is no portable way to change the rounding precision.
> 
> No, if the goal is to be portable with various platforms, you need
> to round to double by default, since single precision (almost no
> longer used for FP computations) and double precision are the only
> standard precisions in IEEE 754.

IEEE 754 is not mandated by the ISO C{90,99} standards and there are indeed
platforms where float and double are not using IEEE 754 single resp. double
precision formats.

Jakub

Re: ERROR in the gfortran testsuite

[Jakub Jelinek]

On Tue, May 31, 2005 at 05:24:15PM -0700, Steve Kargl wrote:
> On Tue, May 31, 2005 at 07:40:37PM -0400, Andrew Pinski wrote:
> > Right now on powerpc-darwin with the following versions:
> > Expect version is   5.38.0
> > Tcl version is  8.4
> > Framework version is1.4.4
> > 
> > I get the following failure in the gfortran-
> > ERROR: tcl error sourcing  
> 
> (snip)
> 
> > I think this is due to the empty file  
> > "testsuite/gfortran.fortran-torture/execute/forall_3.x" but I don't  
> > know for sure.  Could someone check to make sure and fix this?
> 
> I just finished a bootstrap/regression test of gfortran on HEAD
> and do not see this problem.  Can you XFAIL forall_3.f90 and
> see if the problem persists?

Works for me too.  BTW, there is no forall_3.x nor forall_3.f90.x
in CVS...

Jakub

Re: duplicate -lgcc --as-needed -lgcc_s --no-as-needed

[Jakub Jelinek]

On Thu, Jun 02, 2005 at 01:59:46PM +0200, Peter S. Mazinger wrote:
> Hello!
> 
> the sequence used for linking on x86 (but most archs will have it too)
> -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
> --no-as-needed
> contains duplicate. Is this really necessary?
> 
> Will the '--as-needed -lgcc_s --no-as-needed' ever apply?

> The missing symbols will be found in -lgcc.

That's not true.  The EH stuff is not in -lgcc, so if -lc needs it,
it wouldn't be found.

Jakub

Re: sizeof(int) in testsuite

[Jakub Jelinek]

On Fri, Jun 03, 2005 at 02:07:57AM -0700, Mark Mitchell wrote:
> >Doesn't "is-effective-target ilp32" test for 32 bits int?
> 
> Good point!  I forgot about that.  My brain is stuck in some other year.
> 
> That doesn't let you adjust the test based on the compiler, but it does 
> let you skip tests that aren't appropriate.

struct-layout-1 tests are certainly supposed to work on lp64 targets as
well and many others though, so requiring ilp32 is a wrong thing to do
there.

Jakub

Re: sizeof(int) in testsuite

[Jakub Jelinek]

On Thu, Jun 02, 2005 at 09:49:03PM -0400, DJ Delorie wrote:
> 
> gcc.dg/compat/struct-layout-1_generate.c assumes sizeof(int) is 4.
> This of course fails on any target where sizeof(int) is 2.  They may
> fail when sizeof(int) is 8 too, or at least they won't be testing the
> full range of possibilities.

struct-layout-1_generate.c is run on the host, not on the target.
And for hosts AFAIK GCC requires 32-bit int.

Jakub

Re: duplicate -lgcc --as-needed -lgcc_s --no-as-needed

[Jakub Jelinek]

On Fri, Jun 03, 2005 at 10:56:37AM +0100, Nix wrote:
> The point of that trickery is to avoid introducing a dependency on the
> shared libgcc for programs that don't use exception handling. If they
> do, it'll come from the shared libgcc: otherwise, the shared libgcc gets
> entirely dropped thanks to --as-needed. (This is *not* quite the same as
> dropping it for C programs and keeping it for C++ programs: C programs
> can be linked with -fexceptions for the same of exception propagation
> from C++, and then they'd pull in symbols from libgcc_s, even if they
> are themselves not using the symbol anywhere else: perhaps they're a
> shared library, or will dlopen() something written in C++ which may
> throw.)

Right, just a minor nit.  -fexceptions alone in C code does not
cause libgcc_s to be brought in, you need to do something in C that
requires the EH stuff from libgcc_s.  So, either explicitely call
one of the _Unwind_* routines, or use __attribute__((cleanup (fn))).

Jakub

Re: Howto biarch compiler default to -m32?

[Jakub Jelinek]

On Wed, Jun 08, 2005 at 10:50:16AM +0200, Andreas Jaeger wrote:
> On Wednesday 08 June 2005 09:56, René Rebe wrote:
> > Hi all,
> >
> > I did this once in the past but lost my transscript ... What was the
> > recommended way to get a sparc64-gnu-linux (or other biarch) compiler that
> > defaults to -m32? Is there a config or was the way to patch the linux64.h
> > in the arch config dir?
> 
> For PowerPC I just add:
> --with-cpu=default32
> 
> But I do not know whether this is generic,

It is not generic (yet).
On sparc64-linux, --with-cpu=v7 can be used to create a compiler defaulting
to -m32, but being able to handle -m64 as well.

Jakub

po file update

[Jakub Jelinek]

On Tue, Jun 14, 2005 at 04:43:47PM -0700, Mark Mitchell wrote:
> Right now, the libstdc++ versioning/ABI situation is is all that stands 
> between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation.

Weren't we waiting for the updated po files (at least for the translations
that were known to contain bugs that resulted in compiler crashes,
i.e. de, es, tr and zh_CN)?

Joseph, have you uploaded 4.0.1 RC to the TP robot?
Will it msgmerge automatically and send back or do we need to wait for
the translators to actually msgmerge it manually?

Jakub

Re: GCC 4.0.1 Status (2005-06-13)

[Jakub Jelinek]

On Thu, Jun 16, 2005 at 10:56:52AM +0200, Eric Botcazou wrote:
> > I would be especially grateful for people testing this on primary hosts
> > that are not linux. In particular, AIX and Solaris.
> 
> OK on Solaris 2.5.1 and 2.6, but not OK on Solaris 7, 8, 9 and 10:

Can you please post output from
readelf -Ws libstdc++.so.6 \
  | sed -n '/\.symtab/,$d;/ UND /d;/\(GLOBAL\|WEAK\)/p' \
  | awk '{ if ($4 == "OBJECT") { printf "%s %s %s %s %s\n", $8, $4, $5, $6, $3 
} else { printf "%s %s %s %s\n", $8, $4, $5, $6 }}' \
  | LC_ALL=C sort -u

before and after the patch?
Thanks.

Jakub

Re: GCC 4.0.1 Status (2005-06-13)

[Jakub Jelinek]

On Thu, Jun 16, 2005 at 05:10:49PM +0200, Eric Botcazou wrote:
> The diff is attached.

Except that
-_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEil@@GLIBCXX_3.4 FUNC GLOBAL 
DEFAULT
the diff just shows the expected 24 changes of @@GLIBCXX_3.4 symbols
to @GLIBCXX_3.4 + @@GLIBCXX_3.4.5 and 2 additions of symbols
to both @GLIBCXX_3.4 + @@GLIBCXX_3.4.5 (those 2 are what appeared
in GCC 3.4.4).
And that one should be fixed by the patch I posted, so Solaris
should be hopefully fine.

Jakub

Re: Forward: gcc-4.0.1-b20050607.de.po [REJECTED]

[Jakub Jelinek]

On Sat, Jun 18, 2005 at 11:27:15PM +0200, "Martin v. L?wis" wrote:
> > This worked before. Why shouldn't it? Please tell me how to work

Before the string was marked as c-format and therefore gettext
did not complain.  But GCC whenever it tried to issue that diagnostics
worked in english, but crashed in german.

> > around it except not using the n$ feature of standard format
> > strings. If GCC implements its own format strings, it should
> > at least support the standard feature set.
> 
> So the questions are:
> - Does GCC support $ reordering of arguments?
> - If yes, why does gettext complain?
> - If no, shouldn't it?

I have posted a patch that implements it, but it hasn't been reviewed
(yet).  If it ever goes in (which would be certainly after 4.0.1 release),
the next step would be to modify gettext again to grok it.

Jakub

Re: GCC 4.0.1 RC2

[Jakub Jelinek]

On Sat, Jun 18, 2005 at 11:46:42AM -0700, Mark Mitchell wrote:
> Benjamin Kosnik wrote:
> >>Please test this version and report problems in Bugzilla, with a Cc:
> >>to me. I'd also appreciate explicit confirmation from a representative
> >>of the libstdc++ team that this version as packaged still has the
> >>desired behavior, just to catch any packaging snafus.
> >
> >
> >This version looks correct to me. Thanks!
> 
> Would you please comment on PR 22111?  This is apparently a new 
> testsuite failure from the changes.

PR 22111 is about libstdc++-v3 being built with binutils 2.15, while
2.15.90 or later are required by the patch.  But as seen on hppa,
even 2.15.90 is at least on some arches not enough.
The problem is still the one I have tried to explain to Paolo in
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01421.html
Although what is ATM in CVS avoids doing that for 4 of the symbols
that need to be dual exported (@GLIBCXX_3.4 and @@GLIBCXX_3.4.5),
it does not avoid that for the remaining 22 symbols and clearly
it makes many linkers (apparently all I have tried < 2.15.90
and from recent PR also latest hppa GNU ld) very unhappy.

Below is a patch that makes sure all the 26 symbols in compatibility.cc
are renamed, rather than just the 4 that makes even current CVS crash
on all architectures.
I admit it is fragile, the renaming using #define is quite brutal hack,
as the #define can't selectively apply only to some occurences of the name
that needs to be renamed, but with current libstdc++-v3 it works properly
and exports the same symbols as current CVS, and is linkable even by far
older binutils (tried current CVS, 2.15.94.0.2.2 and 2.14.90.0.4, but
really, what it wants from the linker is what is glibc using for years).

The alternative is to add _GLIBCXX_SYMVER_COMPATIBILITY
renames like ATM include/bits/char_traits.h has to the remaining 22
templates, which would be cleaner thing for compatibility.cc, but
further uglification of the installed headers.

2005-06-19  Jakub Jelinek  <[EMAIL PROTECTED]>

* src/compatibility.cc (_GLIBCXX_SYMVER_COMPATIBILITY): Remove.
(istreambuf_iterator, basic_fstream, basic_ifstream, basic_ofstream,
_M_copy, _M_move, _M_assign, _M_disjunct, _M_check_length,
_M_set_length_and_sharable, ignore, eq): Define to XX suffixed
variants.
(ignore (streamsize)): Remove _W prefixed aliases.
(_GLIBCXX_3_4_SYMVER_SPECIAL, _GLIBCXX_3_4_5_SYMVER_SPECIAL,
_GLIBCXX_APPLY_SYMVER_SPECIAL): Remove.
(_GLIBCXX_3_4_SYMVER, _GLIBCXX_3_4_5_SYMVER): Add XXname argument.
Use #XXname instead of #name as the alias argument.
* config/abi/compatibility.h: Replace uses of
_GLIBCXX_APPLY_SYMVER_SPECIAL with _GLIBCXX_APPLY_SYMVER.  Always
pass 2 arguments to the _GLIBCXX_APPLY_SYMVER macro.
* include/bits/char_traits.h (char_traits::eq): Revert 2005-06-15
change.
* acinclude.m4: Decrease glibcxx_min_gnu_ld_version back to 21400.
* configure: Rebuilt.

--- libstdc++-v3/src/compatibility.cc.jj2005-06-18 04:15:05.0 
-0400
+++ libstdc++-v3/src/compatibility.cc   2005-06-19 02:52:31.0 -0400
@@ -31,7 +31,18 @@
 #include 
 
 #if defined(_GLIBCXX_SYMVER) && defined(PIC)
-# define _GLIBCXX_SYMVER_COMPATIBILITY 1
+#define istreambuf_iterator istreambuf_iteratorXX
+#define basic_fstream basic_fstreamXX
+#define basic_ifstream basic_ifstreamXX
+#define basic_ofstream basic_ofstreamXX
+#define _M_copy(a, b, c) _M_copyXX(a, b, c)
+#define _M_move(a, b, c) _M_moveXX(a, b, c)
+#define _M_assign(a, b, c) _M_assignXX(a, b, c)
+#define _M_disjunct(a) _M_disjunctXX(a)
+#define _M_check_length(a, b, c) _M_check_lengthXX(a, b, c)
+#define _M_set_length_and_sharable(a) _M_set_length_and_sharableXX(a)
+#define ignore ignoreXX
+#define eq eqXX
 #endif
 
 #include 
@@ -42,27 +53,6 @@
 namespace std
 {
   // std::istream ignore explicit specializations.
-#if defined(_GLIBCXX_SYMVER) && defined(PIC)
-  template<>
-basic_istream&
-basic_istream::ignore(streamsize __n) 
-#ifdef _GLIBCXX_PTRDIFF_T_IS_INT
-asm ("_W_ZNSi6ignoreEi");
-#else
-asm ("_W_ZNSi6ignoreEl");
-#endif
-
-#ifdef _GLIBCXX_USE_WCHAR_T
-  template<>
-basic_istream&
-basic_istream::ignore(streamsize __n)
-#ifdef _GLIBCXX_PTRDIFF_T_IS_INT
- asm ("_W_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEi");
-#else
- asm ("_W_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl");
-#endif
-#endif
-#endif // _GLIBCXX_SYMVER && PIC
 
   template<>
 basic_istream&
@@ -347,43 +337,27 @@ namespace std
 // In the future, GLIBCXX_ABI > 6 should remove all uses of
 // _GLIBCXX_*_SYMVER macros in this file.
 
-#define _GLIBCXX_3_4_SYMVER(name) \
-   extern "C" void \
-   _X##name() \
-   __attribute

Re: expanding builtins

[Jakub Jelinek]

On Mon, Jun 27, 2005 at 10:11:50AM -0400, James Lemke wrote:
> I have a situation where a structure is not properly aligned and I want
> to copy it to fix this.
> 
> I'm aware that -no-builtin-memcpy will suppress the expansion of
> memcpy() (force library calls) for a whole module.  Is it possible to
> suppress the expansion for a single invocation?

You can:
#include 
...
extern __typeof(memcpy) my_memcpy __asm ("memcpy");

and use my_memcpy instead of memcpy in the place where you want to force
library call.

Or you can use memcpy builtin, just tell GCC it should forget everything
it knows about alignment of whatever you know is not aligned.
void *psrc = (void *) src;
__asm ("" : "+r" (psrc));
memcpy (dest, psrc, len);

Jakub

Re: var_tracking question

[Jakub Jelinek]

On Thu, Jun 30, 2005 at 09:25:47PM -0400, DJ Delorie wrote:
> 
> My m32c port is generating tracking notes that look like this:
> 
> (var_location 0x2a95758dd0 (parallel [
> (expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:123 remainder_size ] 
> [123])
> (const_int 0 [0x0]))
> (expr_list:REG_DEP_TRUE (reg:HI 1 r2 [ remainder_size+2 ])
> (const_int 2 [0x2]))
> ]))
> 
> Note that registers are HI natively, and r2 is the upper half of the
> [r2:r0] pair.  In other words, the location given above describes an
> overlap between the two pieces.  The code itself refers to the
> variable in both SI (full) and HI (part) modes.
> 
> The dwarf2 location lists generated from this are bogus.

Even on mainline?  See PR debug/21946 and
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00312.html.
Var-tracking is very broken in that it doesn't care about register modes,
but what I have comitted should at least prevent bogus dwarf2 location
list generation.

Jakub

Re: A trouble with libssp in one-tree builds

[Jakub Jelinek]

On Mon, Jul 04, 2005 at 09:50:08PM -0700, Kazu Hirata wrote:
> I am having a trouble with libssp in one-tree builds.  That is, if I
> try to build binutils and gcc at the same time, libssp/configure
> complains while compiling (and linking) the following program and the
> build process stops.
> 
> /* confdefs.h.  */
> 
> #define PACKAGE_NAME "libssp"
> #define PACKAGE_TARNAME "libssp"
> #define PACKAGE_VERSION "1.0"
> #define PACKAGE_STRING "libssp 1.0"
> #define PACKAGE_BUGREPORT ""
> #define PACKAGE "libssp"
> #define VERSION "1.0"
> /* end confdefs.h.  */
> 
> int
> main ()
> {
> 
>   ;
>   return 0;
> }
> 
> The problem is that libssp/configure contains a link test, but we may
> not have crt0.o built yet (assuming targets like h8300-elf,
> arm-none-eabi, etc).

DJ, can this be solved by toplevel Makefile.in's dependencies or
lang_env_dependencies?

Jakub

Re: sparc-linux results for 4.0.1 RC3

[Jakub Jelinek]

On Wed, Jul 06, 2005 at 04:33:43PM +0200, Paolo Carlini wrote:
> Eric Botcazou wrote:
> 
> >>Yes, I would definitely encourage a little more analysis. I'm rather
> >>puzzled. We have got very nice testsuites on sparc-solaris and on
> >>*-linux, in general, and those failures certainly are not expected.
> >>
> >>
> >Is the
> >
> >FAIL: abi_check
> >
> >failure expected?  Should config/abi/sparc-linux-gnu/baseline_symbols.txt be 
> >somehow updated?
> >  
> >
> Yes, probably we should concentrate on that failure. It's the most
> strange, probably, because Benjamin and Jakub (certainly a Sparc expert)
> updated the sparc-linux baseline around mid of June. Maybe we should
> involve Jakub too in the discussion, at least to confirm that on his
> sparc-linux machines abi_check doesn't fail.

The best would be if Christian could post (bzip2ed) readelf -Ws of
the libstdc++.so that fails the abi_check.

Jakub

Re: isinf

[Jakub Jelinek]

On Thu, Jul 14, 2005 at 06:27:06PM +0900, Hiroshi Fujishima wrote:
> Andreas Schwab <[EMAIL PROTECTED]> writes:
> 
> > Why not just use AC_HAVE_FUNCS(isinf)?  IIUC this is part of a configure
> > script, although whether it is autoconf generated is not clear so far.
> 
> Though I don't know the why, rrdtool-1.2.10/configure.ac has the
> following macro.
> 
> dnl HP-UX 11.00 does not have finite but does have isfinite as a macro so we 
> need
> dnl actual code to check if this works
> AC_CHECK_FUNCS(fpclassify, ,
>   [AC_MSG_CHECKING(for fpclassify with )
> AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; 
> fpclassify(f)]])],[AC_MSG_RESULT(yes)
>   AC_DEFINE(HAVE_FPCLASSIFY)],[AC_MSG_RESULT(no)])])
> AC_CHECK_FUNCS(finite, ,
>   [AC_CHECK_FUNCS(isfinite, ,
> [AC_MSG_CHECKING(for isfinite with )
> AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; 
> isfinite(f)]])],[AC_MSG_RESULT(yes)
>   AC_DEFINE(HAVE_ISFINITE)],[AC_MSG_RESULT(no)])])])
> AC_CHECK_FUNCS(isinf, ,
>   [AC_MSG_CHECKING(for isinf with )
> AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], [[float f = 0.0; 
> int x = isinf(f)]])],[AC_MSG_RESULT(yes)
>   AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])])

Guess that's because AC_HAVE_FUNCS(isinf) is wrong.
isinf/isfinite/fpclassify are all documented as macros in ISO C99.
So
   [AC_MSG_CHECKING(for isinf with )
 AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include 
volatile int x; volatile float f;]], [[x = isinf(f)]])],[AC_MSG_RESULT(yes)
   AC_DEFINE(HAVE_ISINF)],[AC_MSG_RESULT(no)])])
should be reasonably safe for now.

Jakub

Re: PATCH: Enable FTZ/DAZ for SSE via fast math

[Jakub Jelinek]

On Wed, Aug 10, 2005 at 07:09:04AM -0700, H. J. Lu wrote:
> On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> > On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > > There is a minor problem. How can I add crtfastmath.o for SSE targets
> > > only? 
> > 
> > You don't.  You either add code to detect sse, or you make the
> > spec depend on -mfpmath=sse.
> > 
> 
> Here is the patch to enable FTZ/DAZ for SSE via fast math. There are
> no regressions on Linux/x86_64 nor Linux/ia32. The performance of one
> FP benchmark on EM64T is more than doubled with -ffast-math.

Not all i?86 CPUs support cpuid instruction.
Please look at
gcc/testsuite/gcc.dg/i386-cpuid.h
for the ugly details.

> +static void __attribute__((constructor))
> +set_fast_math (void)
> +{
> +  /* Check if SSE is available.  */
> +  unsigned int eax, ebx, ecx, edx;
> +  asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1"
> + : "=a" (eax), "=r" (ebx), "=c" (ecx), "=d" (edx)
> + : "0" (1));
> +
> +  if (edx & (1 << 25))
> +{
> +  unsigned int mxcsr = __builtin_ia32_stmxcsr ();
> +  mxcsr |= MXCSR_DAZ | MXCSR_FTZ;
> +  __builtin_ia32_ldmxcsr (mxcsr);
> +}
> +}

Jakub

Re: gcc.c-torture/execute/stdarg-2.c: long vs int

[Jakub Jelinek]

On Mon, Aug 22, 2005 at 08:38:01PM -0400, DJ Delorie wrote:
> 
> This test assumes that integer constants passed as varargs are
> promoted to a type at least as big as "long", which is not valid on 16
> bit hosts.  For example:
> 
> void
> f1 (int i, ...)
> {
>   va_start (gap, i);
>   x = va_arg (gap, long);
> 
> 
> int
> main (void)
> {
>   f1 (1, 79);
>   if (x != 79)
> abort ();
> 
> 
> Shouldn't those constants be 79L, not just 79?  That change fixes one
> m32c failure, but given that it's a test case I'm not going to make
> any assumptions about it.

This certainly wasn't my intention, please change it to 79L.

Jakub

Re: Undefined behavior in genautomata.c?

[Jakub Jelinek]

On Mon, Sep 19, 2005 at 09:03:48AM -0400, Daniel Berlin wrote:
> Anyway, the real fix is to simply not attempt to derive information when
> the access is through a pointer (IE it is not related to structs at all,
> it's the fact that these are heap allocated), unless you have info about
> the malloc sites and the upper bound on what size it is allocating.
> 
> I'll actually soon be providing you such malloc site size info :)

tree-object-size.c already provides that...

Jakub

Re: Undefined behavior in genautomata.c?

[Jakub Jelinek]

On Mon, Sep 19, 2005 at 09:22:56AM -0400, Daniel Berlin wrote:
> On Mon, 2005-09-19 at 15:07 +0200, Jakub Jelinek wrote:
> > On Mon, Sep 19, 2005 at 09:03:48AM -0400, Daniel Berlin wrote:
> > > Anyway, the real fix is to simply not attempt to derive information when
> > > the access is through a pointer (IE it is not related to structs at all,
> > > it's the fact that these are heap allocated), unless you have info about
> > > the malloc sites and the upper bound on what size it is allocating.
> > > 
> > > I'll actually soon be providing you such malloc site size info :)
> > 
> > tree-object-size.c already provides that...
> 
> 1. Not interprocedurally.

True, it was written before the IPA infrastructure was added.
For 4.2 the plan is to rewrite it using Diego's propagator and then
IPA propagation should be added too.  It will be useful for both
__builtin_object_size builtin itself as well as other passes that might
use the info (e.g. mudflap).

> 2. Not for regular objects, only things involved with
> builtin_object_siz.

Not true, you can call it internally on any anything.

> tree-object-size is also a bit hard to follow, in part because it does
> things like:
> if (object_size_type & 2)
> 
> *all over the place*, and says to go look at the builtin_object_size
> documentation.  It would have been nice to give the existing bits
> symbolic names of some sort :)

++todo, that certainly will not hurt.  Though out of the 11 occurrences
of & 1 and & 2 tests, 4 of them are documented...

Jakub

Re: Char *Foo = "ABC" or Char Foo[] = "ABC"" ?

[Jakub Jelinek]

On Fri, Oct 07, 2005 at 11:39:46AM -0700, Richard Henderson wrote:
> That said, some ABIs over-align arrays, and so you might get more
> padding with arrays than raw strings.  But it'll be less than the
> size of an extra pointer variable.

Plus constant merging will not happen (at least not unless
-fmerge-all-constants) when using:
const char foo[] = "Hello, world!";
in one file and
const char bar[] = "Hello, world!";
in another one (or even in the same file), while the strings are merged
for
const char *foo = "Hello, world!";
and
const char *bar = "Hello, world!";
in another file.

Jakub

Re: Heads up: many recent Fortran SPEC regressions

[Jakub Jelinek]

On Tue, Oct 18, 2005 at 01:47:33AM -0700, Richard Henderson wrote:
> On Tue, Oct 18, 2005 at 12:39:14AM +0200, Paul Thomas wrote:
> > Have you made any progress on fixing this?  I would rather that the 
> > debug information is not available than that equivalence is broken.
> 
> My mind is going.  After checking 4 or 5 different trees wondering
> where the patch is, I noticed that I've checked it in already.
> 
> 2005-10-15  Richard Henderson  <[EMAIL PROTECTED]>
> 
> * gimplify.c (gimplify_var_or_parm_decl): Split out from ...
> (gimplify_expr): ... here.
> (gimplify_compound_lval): Use it in initial scan loop.  Allow
> fb_lvalue in base expression.
> 
> If it's still not fixed, I guess I'll have to look again...

Well, certainly the graphs on Diego's page returned ~ up to normal values
when you committed the fix.

Jakub

[gomp] C++ #pragma omp for and -fno-for-scope

[Jakub Jelinek]

Hi!

While looking at PR c++/24512, I have noticed that for
#pragma omp {,parallel }for loops we don't handle -fno-for-scope
and don't emit the default error messages that point people to
the problem otherwise.

So my question is, should we consider #pragma omp for and
#pragma omp parallel for a separate scope around the for loop for
this kind of purpose or not?  I think it would be better to be
consistent with -fno-openmp (i.e. if there is a declaration
in the for loop, move the DECL_EXPR right before the loop, either
into a separate sk_for scope if flag_new_for_scope > 0, or just into
the parent scope at that point) and create sk_omp scope for the
rest of the construct.

What do you think?

extern void bar (int);

void foo ()
{
#pragma omp for lastprivate (i)
  for (int i = 0; i < 10; i++)
bar (i);
  bar (i);
#pragma omp parallel for lastprivate (j)
  for (int j = 0; j < 10; j++)
bar (j);
  bar (j);
}

Jakub

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Jakub Jelinek]

On Tue, Nov 01, 2005 at 02:01:43PM +0100, [EMAIL PROTECTED] wrote:
> [ Bringing this back to fortran@, taking the optimizer guys out of CC: ]
> 
> Quoting Toon Moene:
> > I still have to construct a bug report of something that confuses the parser
> > and that basically looks like this:
> >
> >  IMPLICIT CHARACTER*8 (Y)
> >  CHARACTER*11 Y1, Y2, Y3
> >  ...
> >  YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) //
> > 1 // YB(1:5)
> >   1
> > Unclassifiable statement at (1)
> >
> > Unfortunately, if I reduce the code to this one (continued) line and the
> > necessary declarations, it doesn't fail ;-)
> 
> Does this fail as long as you keep the type implicit?  This reminds me of
> another PR, where the parser would decide too early that it had seen an array
> range instead of a substring, which would lead to these kinds of niceties
> further down the line.  Unfortunately, I couldn't find this bug in bugzilla,
> looks like its PR's summary is not very descriptive.

You mean PR18833?

Jakub

Re: [RFC] Enabling loop unrolls at -O3?

[Jakub Jelinek]

On Sun, Nov 06, 2005 at 01:32:43PM +0100, Giovanni Bajo wrote:
> If -O1 means "optimize, but be fast", what does -O2 mean? And what does -O3
> mean? If -O2 means "the current set of optimizer that we put in -O2", that's
> unsatisfying for me.

`-O2'
 Optimize even more.  GCC performs nearly all supported
 optimizations that do not involve a space-speed tradeoff.  The
 compiler does not perform loop unrolling or function inlining when
 you specify `-O2'.  As compared to `-O', this option increases
 both compilation time and the performance of the generated code.

Including loop unrolling to -O2 is IMNSHO a bad idea, as loop unrolling
increases code size, sometimes a lot.  And the distinction between -O2
and -O3 is exactly in the space-for-speed tradeoffs.

On many CPUs for many programs, -O3 generates slower code than -O2,
because the cache footprint  disadvantages override positive effects
of the loop unrolling, extra inlining etc.

Jakub

Re: BROKEN: pthreads and c++ statically linked

[Jakub Jelinek]

On Tue, Nov 08, 2005 at 09:31:56AM -0500, Dixon, Lee L. wrote:
> I really don't know what I could be doing wrong, but on a _stock_ FC4
> install, I'm having a segfault in a pthread call when
> statically linked and including iostream (or STL includes like string)
> 
> Here's the code:
> 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
>   pthread_mutexattr_t attr;
>   pthread_mutexattr_init( &attr );
> }

This is a known problem, see
http://gcc.gnu.org/ml/gcc/2005-10/msg00235.html
for details.

In the mean time, don't link statically (which is a terribly bad idea
anyway), or use -Wl,--whole-archive -lpthread -Wl,--no-whole-archive.

Jakub

Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative

[Jakub Jelinek]

On Tue, Nov 08, 2005 at 04:05:20PM +0100, Christian Joensson wrote:
> Currently, on the gomp branch, I get this:
> 
> if /bin/sh ./libtool --mode=compile
> /usr/local/src/branch/objdir.gomp/./gcc/xgcc
> -B/usr/local/src/branch/objdir.gomp/./gcc/
> -B/usr/local/sparc64-unknown-linux-gnu/bin/
> -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
> /usr/local/sparc64-unknown-linux-gnu/include -isystem
> /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
> -I../../../gcc.gomp/libgomp -I. 
> -I../../../gcc.gomp/libgomp/config/linux/sparc
> -I../../../gcc.gomp/libgomp/config/linux
> -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp 
> -Wall -Werror -ftls-model=initial-exec -mcpu=v9 -Wc,-pthread -O2 -g
> -O2  -MT env.lo -MD -MP -MF ".deps/env.Tpo" -c -o env.lo
> ../../../gcc.gomp/libgomp/env.c; \
> then mv -f ".deps/env.Tpo" ".deps/env.Plo"; else rm -f
> ".deps/env.Tpo"; exit 1; fi
> /usr/local/src/branch/objdir.gomp/./gcc/xgcc
> -B/usr/local/src/branch/objdir.gomp/./gcc/
> -B/usr/local/sparc64-unknown-linux-gnu/bin/
> -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
> /usr/local/sparc64-unknown-linux-gnu/include -isystem
> /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
> -I../../../gcc.gomp/libgomp -I.
> -I../../../gcc.gomp/libgomp/config/linux/sparc
> -I../../../gcc.gomp/libgomp/config/linux
> -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp
> -Wall -Werror -ftls-model=initial-exec -pthread -mcpu=v9 -O2 -g -O2
> -MT env.lo -MD -MP -MF .deps/env.Tpo -c
> ../../../gcc.gomp/libgomp/env.c  -fPIC -DPIC -o .libs/env.o
> In file included from ../../../gcc.gomp/libgomp/env.c:32:
> ./libgomp_f.h: In function 'omp_check_defines':
> ./libgomp_f.h:71: error: size of array 'test' is negative

Can you please paste the omp_check_defines routine as from libgomp_f.h
and grep config_path Makefile
?

Jakub

Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative

[Jakub Jelinek]

On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> Sure, here's the (relevant(?) part of) generated libgomp_f.h:
> 
> static inline void
> omp_check_defines (void)
> {
>   char test[(24 != sizeof (omp_lock_t)
>|| 4 != __alignof (omp_lock_t)
>|| 24 != sizeof (omp_nest_lock_t)
>|| 4 != __alignof (omp_nest_lock_t)
>|| 8 != sizeof (*(omp_lock_arg_t) 0)
>|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
>   ? -1 : 1] __attribute__ ((__unused__));
> }

That smells like libgomp_f.h has been generated before linux/sparc and linux
have been added to the search path.
Can you remove it and make so that it will be recreated?
If on the first line is still not 4, please investigate with what exact
options is the mkomp_h.pl script called and why it doesn't include
config/linux/omp-lock.h instead of config/posix/omp-lock.h.

Jakub

Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative

[Jakub Jelinek]

On Tue, Nov 08, 2005 at 07:28:45PM +0100, Christian Joensson wrote:
> > Before I experiment with that, pls note that the compiler is (default)
> > configured for target sparc64-unknown-linux-gnu and with the configure
> > option --with-cpu=v7 resulting in default v7 (32-bit) code. May this
> > "trick" be the trouble here?

No, I have been using exactly the same when I built it on SPARC a few days
ago.

> simply deleting the file libgomp_f.h does not work. I get this new
> file generated, different:

The sparc64-unknown-linux-gnu/libgomp/libgomp_f.h one contains the
expected numbers.  If that fails the env.c check too, please replace
-c on the command line you pasted with -E -dD and mail the result to me.

> /usr/local/src/branch/objdir.gomp/./gcc/xgcc
> -B/usr/local/src/branch/objdir.gomp/./gcc/
> -B/usr/local/sparc64-unknown-linux-gnu/bin/
> -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
> /usr/local/sparc64-unknown-linux-gnu/include -isystem
> /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
> -I../../../../gcc.gomp/libgomp -I.
> -I../../../../gcc.gomp/libgomp/config/linux/sparc
> -I../../../../gcc.gomp/libgomp/config/linux
> -I../../../../gcc.gomp/libgomp/config/posix
> -I../../../../gcc.gomp/libgomp -Wall -Werror -pthread
> -ftls-model=initial-exec -O2 -g -O2 -m64 -MT env.lo -MD -MP -MF
> .deps/env.Tpo -c ../../../../gcc.gomp/libgomp/env.c  -fPIC -DPIC -o
> .libs/env.o
> In file included from ../../../../gcc.gomp/libgomp/env.c:32:
> ./libgomp_f.h: In function 'omp_check_defines':
> ./libgomp_f.h:71: error: size of array 'test' is negative

Jakub

SVN conversion glitch?

[Jakub Jelinek]

Hi!

While doing svn diff, I've noticed
gcc/config/i386/xm-dgux.h
gcc/config/i386/xm-sysv3.h
gcc/config/i386/xm-sun.h
gcc/config/i386/scodbx.h
files popped out of nowhere on the trunk (and through
4.1 branching also on gcc-4_1-branch).
The files according to ChangeLogs were clearly removed back in 2001
and don't appear on gcc-{3_1,3_2,3_3,3_4,4_0}-branch.
Could you please check what exactly happened with these files and
why they show on the trunk and 4.1 branch?

Thanks.

Jakub

ppc-linux and s390-linux compilers requiring 64-bit HWI?

[Jakub Jelinek]

Hi!

What's the reason why ppc-linux and s390-linux targetted GCC
requires 64-bit HWI these days?
If it is a native compiler, this means using long long in a huge part
of the compiler and therefore slower compile times and bigger memory
consumption.
ppc-linux configured compiler (nor s390-linux) isn't multilibbed and
ppc-linux only supports -m32 (s390-linux one apparently supports
both -m31 and -m64 on the GCC side, but without multilibs it isn't very
helpful).
Say i386 or sparc-linux which also only support -m32 don't require 64-bit
HWI, while if you target x86_64 or sparc64-linux which support both -m32
and -m64 obviously 64-bit HWI is required.

--- libcpp/configure.ac.jj  2005-10-28 23:13:40.0 +0200
+++ libcpp/configure.ac 2005-11-25 14:34:31.0 +0100
@@ -112,6 +112,8 @@ fi
 
 m4_changequote(,)
 case $target in
+   powerpc-*-linux*)
+   need_64bit_hwint=no ;;
alpha*-*-* | \
arm*-*-*eabi* | \
arm*-*-symbianelf* | \
@@ -123,7 +125,7 @@ case $target in
mmix-*-* | \
powerpc*-*-* | \
rs6000*-*-* | \
-   s390*-*-* | \
+   s390x-*-* | \
sparc64*-*-* | ultrasparc-*-freebsd* | \
sparcv9-*-solaris2* | \
sparc-*-solaris2.[789] | sparc-*-solaris2.1[0-9]* | \
--- libcpp/configure.jj 2005-10-28 23:13:40.0 +0200
+++ libcpp/configure2005-11-25 14:34:40.0 +0100
@@ -8217,6 +8217,8 @@ fi
 
 
 case $target in
+   powerpc-*-linux*)
+   need_64bit_hwint=no ;;
alpha*-*-* | \
arm*-*-*eabi* | \
arm*-*-symbianelf* | \
@@ -8228,7 +8230,7 @@ case $target in
mmix-*-* | \
powerpc*-*-* | \
rs6000*-*-* | \
-   s390*-*-* | \
+   s390x-*-* | \
sparc64*-*-* | ultrasparc-*-freebsd* | \
sparcv9-*-solaris2* | \
sparc-*-solaris2.[789] | sparc-*-solaris2.1[0-9]* | \
--- gcc/config.gcc.jj   2005-11-19 09:27:16.0 +0100
+++ gcc/config.gcc  2005-11-25 14:29:30.0 +0100
@@ -294,7 +294,10 @@ mips*-*-*)
 powerpc*-*-*)
cpu_type=rs6000
extra_headers="ppc-asm.h altivec.h spe.h"
-   need_64bit_hwint=yes
+   case ${target} in
+   powerpc-*-linux*) ;;
+   *) need_64bit_hwint=yes ;;
+   esac
case x$with_cpu in
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[345]|xrs64a)
cpu_is_64bit=yes
@@ -311,10 +314,13 @@ sparc64*-*-*)
 sparc*-*-*)
cpu_type=sparc
;;
-s390*-*-*)
+s390x-*-*)
cpu_type=s390
need_64bit_hwint=yes
;;
+s390*-*-*)
+   cpu_type=s390
+   ;;
 # Note the 'l'; we need to be able to match e.g. "shle" or "shl".
 sh[123456789lbe]*-*-*)
cpu_type=sh

Jakub

s390{,x} ABI incompatibility between gcc 4.0 and 4.1

[Jakub Jelinek]

Hi!

There are several g*dg/compat/ tests failing that show ABI
incompatibilities:

FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_tst.o-cp_compat_y_alt.o 
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_alt.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_tst.o-c_compat_y_alt.o 
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_alt.o-c_compat_y_tst.o 
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_alt.o 
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_alt.o-c_compat_y_tst.o 
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_alt.o 
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_alt.o-c_compat_y_tst.o 
execute

I have looked just at one failure, but maybe all of them are the same thing.
typedef char __attribute__((vector_size (16))) v16qi;
int i = __alignof__ (v16qi);

with GCC 4.0 sets i to 8 (s390{,x} have BIGGEST_ALIGNMENT 64), but
GCC 4.1 sets i to 16.
The changes that created this binary incompatibility are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23467
I think.  layout_type sets TYPE_ALIGN to 128 bits (size of v16qi)
and in 4.0 and earlier finalize_type_size used to decrease the size
to GET_MODE_ALIGNMENT (TImode), which is 64 on s390{,x}.

Was this change intentional?  If yes, I think it should be documented in 4.1
release notes, but I still hope it wasn't intentional.

Jakub

Re: C++ vague linkage data

[Jakub Jelinek]

On Mon, Nov 28, 2005 at 04:10:55PM +0100, Lubos Lunak wrote:
>  when gcc emits vague linkage data for C++ like vtables it makes them all 
> weak. Is there some reason why this needs to be done?
> 
>  If I'm getting it right, based on e.g. on the comment in binutils/bfd/elf.c 
> saying that they are weak in order to allow multiple copies and that the GNU 
> ld extension linkonce will discard all but one, this seems to be done only 
> for historical reasons (or call that compatibility, whatever). With the usual 
> setup of using the complete GNU toolchain, there will be always only one such 
> symbol because of the linkonce feature in each resulting binary/library. If 
> there will be more such libraries each of them having the same symbol, the 
> normal ELF symbol rules will bind all references only to one of them, and 
> those symbols are all the same anyway.
> 
>  Which means that in such case there's no reason to have those symbols weak, 
> and having them weak means that the symbol lookup in ld.so for them will be 
> more expensive (because it has to search all libraries for a non-weak symbol 
> only to find out there's obviously no such thing). Is there some reason why 
> this shouldn't be changed to have these symbols emitted normally as non-weak?

glibc ld.so doesn't work that way for almost 3 years now, it doesn't special
case weak symbols, first matching symbol is returned and I believe
glibc was the only one that violated the spec in that case.

Jakub

Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1

[Jakub Jelinek]

On Tue, Nov 29, 2005 at 01:44:44PM +, Joern RENNECKE wrote:
> No, it wasn't.  The change was supposed to affect structures only.
> As I understand the documentation ,the expected behaviour would be to 
> limit the alignment
> to BIGGEST_ALIGNMENT, unless the user has specified a larger alignment 
> with the
> aligned attribute.
> 
> One possible solution appears to be along the lines of
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stor-layout.c.diff?cvsroot=gcc&r1=1.239&r2=1.240
>  
> ,
> but with the comment changed to explain what we want to preserve now.
> 
> However, I think it is probably better to start out with the right 
> alignment, by fix this code
> in layout_type to take BIGGEST_ALIGNMENT into account:
>case VECTOR_TYPE:
> ...
>/* Always naturally align vectors.  This prevents ABI changes
>   depending on whether or not native vector modes are 
> supported.  */
>TYPE_ALIGN (type) = tree_low_cst (TYPE_SIZE (type), 0);

If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT)
here, I'm afraid that would be much bigger ABI incompatibility.
Currently, say
typedef char __attribute__((vector_size (64))) v64qi;
is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is much
smaller.
GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
to their size, just vector_size 16 and 32 has been 8 bytes aligned
(BIGGEST_ALIGNMENT).
Not capping to BIGGEST_ALIGNMENT might have issues with some object formats
though, if they don't support ridiculously big aligments.

Jakub

Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1

[Jakub Jelinek]

On Tue, Nov 29, 2005 at 10:01:25PM +, Joern RENNECKE wrote:
> >If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT)
> >here, I'm afraid that would be much bigger ABI incompatibility.
> >Currently, say
> >typedef char __attribute__((vector_size (64))) v64qi;
> >is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is much
> >smaller.
> >GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
> >to their size, just vector_size 16 and 32 has been 8 bytes aligned
> >(BIGGEST_ALIGNMENT).
> > 
> >
> That sounds very strange.  Is there a rationale for that, or is this a 
> SNAFU?

It is just a side-effect of the 3.4/4.0 code - if there was a supported
integer mode on the target for the requested size, then alignment of that
mode was used (and mode alignments are at most BIGGEST_ALIGNMENT).
If no integer mode was supported for that size, it would use the earlier
alignment, i.e. vector_size.
Unfortunately, while say vector_size (64) etc. vectors are IMHO very unlikely,
vector_size (16) will occurr in user programs from time to time and thus the
ABI incompatibility might affect existing programs.
We can document the incompatibility as a feature (after all, getting
rid of that alignment anomaly on s390{,x} wouldn't be a bad thing I guess).
> 
> >Not capping to BIGGEST_ALIGNMENT might have issues with some object formats
> >though, if they don't support ridiculously big aligments.

> We have MAX_OFILE_ALIGNMENT for that.

But is it used for vector type alignments?

Jakub

Re: weakref and static

[Jakub Jelinek]

On Sun, Dec 11, 2005 at 06:46:39PM -0200, Alexandre Oliva wrote:
> Err...  The above is a bit misleading, in that it at first appeared to
> be referring to the target of the weakref, not to the weakref itself.
> The weakref may alias to something that is static or not (the whole
> point is being able to refer to symbols in other translation units
> with weak and non-weak semantics).  The weakref itself could be static
> or extern, and both possibilities could be argued for and match
> certain uses.  Since attribute alias has traditionally required the
> extern keyword, I figured it would make sense to keep it as such, but
> if you prefer to change that and adjust all cases in which the use of
> static might cause problems, that's certainly fine with me.  I don't
> see that you're taking care of such cases, though.

Yeah, as shown on the s390 bootstrap failure, I suspect there will be
many such corner cases lurking around on various targets.
I prefer weakrefs to be extern too. 

Jakub

Re: mainline and 4.1 bootstrap broken on i686-pc-linux-gnu

[Jakub Jelinek]

On Tue, Dec 13, 2005 at 07:44:39PM +0100, Laurent GUERBY wrote:
> 2005-12-13  Jakub Jelinek  <[EMAIL PROTECTED]>
> 
> PR debug/25023
> PR target/25293
> * expr.c (emit_move_resolve_push): Handle PRE_MODIFY
> and POST_MODIFY with CONST_INT adjustment equal to PUSH_ROUNDING.
> Fix POST_INC/POST_DEC handling if PUSH_ROUNDING is not identity.
> * config/i386/i386.md (pushhi2, pushqi2): Use pushl instead of pushw.
> Set mode to SI, adjust constraints.
> (pushhi2_rex64, pushqi2_rex64): Set mode to DI.
> * config/i386/i386.h (PUSH_ROUNDING): Round up to 4 instead of 2 for
> 32-bit code.
> 
> Jakub, any idea?
> > /scratch/gcc/libmudflap/mf-runtime.c:1032: error: unrecognizable insn:
> > (insn 1385 1384 1386 31 /scratch/gcc/libmudflap/mf-runtime.c:1457 (set 
> > (mem:HI (pre_dec:SI (reg/f:SI 7 sp)) [0 S2 A8])
> >  (reg:HI 0 ax [orig:182 __mf_lc_shift ] [182])) -1 (nil)
> >  (nil))
> > /scratch/gcc/libmudflap/mf-runtime.c:1032: internal compiler error: in 
> > extract_insn, at recog.c:2084

I can't reproduce it (otherwise I wouldn't have committed it), it
bootstrapped/regtested just fine for me.

Can one of those who can reproduce it give me preprocessed mf-runtime.i
and exact gcc options that triggered it?

It is correct that the above is rejected, but nothing should be generating
it, unless it disregards PUSH_ROUNDING.

Jakub

[PATCH] Fix bootstrap on i686-pc-linux-gnu

[Jakub Jelinek]

On Tue, Dec 13, 2005 at 08:49:56PM +, Joern RENNECKE wrote:
> >I can't reproduce it (otherwise I wouldn't have committed it), it
> >bootstrapped/regtested just fine for me.
> 
> >Can one of those who can reproduce it give me preprocessed mf-runtime.i
> >and exact gcc options that triggered it?
> 
> I have attached the stripped down testcase.
> The bug is triggered with:
> ./cc1  mf-runtime-i.c -march=i686

Turns out I missed -mtune=pentium4 I was using when building libmudflap
and other target libraries, sorry.

Here is a fix I have verified on the testcase and am going to bootstrap
it right now.  As pushhi2 pattern is now actually pushing 32 bits,
it is the same insn as pushsi2.  While we could use pushhi2 insn
(would need to use pre_modify rather than pre_dec etc.), it wouldn't
buy us anything.  For -m64 we always do a DImode push as well.
Ok to commit if it succeeds?

2005-12-13  Jakub Jelinek  <[EMAIL PROTECTED]>

PR debug/25023
* config/i386/i386.c (ix86_force_to_memory): Always use
SImode push for HImode in -m32.

* gcc.dg/pr25023.c: New test.

--- gcc/config/i386/i386.c.jj   2005-12-13 12:31:15.0 +0100
+++ gcc/config/i386/i386.c  2005-12-13 22:07:18.0 +0100
@@ -15790,9 +15790,8 @@ ix86_force_to_memory (enum machine_mode 
  }
  break;
case HImode:
- /* It is better to store HImodes as SImodes.  */
- if (!TARGET_PARTIAL_REG_STALL)
-   operand = gen_lowpart (SImode, operand);
+ /* Store HImodes as SImodes.  */
+ operand = gen_lowpart (SImode, operand);
  /* FALLTHRU */
case SImode:
  emit_insn (
--- gcc/testsuite/gcc.dg/pr25023.c.jj   2005-12-13 22:11:38.0 +0100
+++ gcc/testsuite/gcc.dg/pr25023.c  2005-12-13 22:12:50.0 +0100
@@ -0,0 +1,12 @@
+/* PR debug/25023 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-options "-O2 -mtune=i686" { target { { i?86-*-* || x86_64-*-* } && 
ilp32 } } } */
+
+extern unsigned char v;
+
+float
+foo (void)
+{
+  return v;
+}


Jakub

Re: [PATCH] Fix bootstrap on i686-pc-linux-gnu

[Jakub Jelinek]

On Tue, Dec 13, 2005 at 09:25:45PM +, Joern RENNECKE wrote:
> >While we could use pushhi2 insn
> >(would need to use pre_modify rather than pre_dec etc.), it wouldn't
> >buy us anything.
> >
> Presumably, it would prevent a partial register stall.

Only if we use the real pushw instruction.  But in that case
unwind info can't represent the stack movement.

Jakub

Re: [PATCH] Fix bootstrap on i686-pc-linux-gnu

[Jakub Jelinek]

On Tue, Dec 13, 2005 at 09:25:45PM +, Joern RENNECKE wrote:
> >While we could use pushhi2 insn
> >(would need to use pre_modify rather than pre_dec etc.), it wouldn't
> >buy us anything.
> >
> Presumably, it would prevent a partial register stall.

Alternatively we could
subl $4, %esp
movw %ax, (%esp)
instead of
pushl %eax
Not sure how would that perform cycle wise though (on the testcase
there is actually not a partial register stall at all, since the QI->HI
zero extension is movzbl, so pushl %eax in this case is best).

BTW, I just noticed I posted an older incomplete version of the patch,
ix86_free_from_memory obviously needs corresponding adjustement.

2005-12-13  Jakub Jelinek  <[EMAIL PROTECTED]>

PR debug/25023
* config/i386/i386.c (ix86_force_to_memory): Always use
SImode push for HImode in -m32.
(ix86_free_from_memory): Likewise.

* gcc.dg/pr25023.c: New test.

--- gcc/config/i386/i386.c.jj   2005-12-13 12:31:15.0 +0100
+++ gcc/config/i386/i386.c  2005-12-13 22:07:18.0 +0100
@@ -15790,9 +15790,8 @@ ix86_force_to_memory (enum machine_mode 
  }
  break;
case HImode:
- /* It is better to store HImodes as SImodes.  */
- if (!TARGET_PARTIAL_REG_STALL)
-   operand = gen_lowpart (SImode, operand);
+ /* Store HImodes as SImodes.  */
+ operand = gen_lowpart (SImode, operand);
  /* FALLTHRU */
case SImode:
  emit_insn (
@@ -15820,8 +15819,6 @@ ix86_free_from_memory (enum machine_mode
 
   if (mode == DImode || TARGET_64BIT)
size = 8;
-  else if (mode == HImode && TARGET_PARTIAL_REG_STALL)
-   size = 2;
   else
size = 4;
   /* Use LEA to deallocate stack space.  In peephole2 it will be converted
--- gcc/testsuite/gcc.dg/pr25023.c.jj   2005-12-13 22:11:38.0 +0100
+++ gcc/testsuite/gcc.dg/pr25023.c  2005-12-13 22:12:50.0 +0100
@@ -0,0 +1,12 @@
+/* PR debug/25023 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-options "-O2 -mtune=i686" { target { { i?86-*-* || x86_64-*-* } && 
ilp32 } } } */
+
+extern unsigned char v;
+
+float
+foo (void)
+{
+  return v;
+}

Jakub

Re: unable to build head on Fedora

[Jakub Jelinek]

On Wed, Dec 14, 2005 at 04:34:17PM -0600, Joel Sherrill <[EMAIL PROTECTED]> 
wrote:
> 
> My fresh check out on the head build using the gcc shipped with
> Fedora Core 4 has failed for the past couple of days with this error:

A day and half.

> /home/joel/gcc-work/head/b-native/./gcc/xgcc 
> -B/home/joel/gcc-work/head/b-native/./gcc/ 
> -B/home/joel/gcc-head-test//i686-pc-linux-gnu/bin/ 
> -B/home/joel/gcc-head-test//i686-pc-linux-gnu/lib/ -isystem 
> /home/joel/gcc-head-test//i686-pc-linux-gnu/include -isystem 
> /home/joel/gcc-head-test//i686-pc-linux-gnu/sys-include -c -g -O2 -fPIC 
>  -W -Wall -gnatpg  g-alleve.adb -o g-alleve.o
> g-alleve.adb: In function 
> ?GNAT.ALTIVEC.LOW_LEVEL_VECTORS.LL_VUC_OPERATIONS.SATURATE.2XNN?: 
> 
> g-alleve.adb:871: error: unrecognizable insn: 
> (insn 113 112 114 4 g-alleve.adb:866 (set (mem:HI (pre_dec:SI 
> (reg/f:SI 7 sp)) [0 S2 A8])
> (reg:HI 0 ax [orig:77 d ] [77])) -1 (nil)
> (nil))

> Is this a known failure?

Yes, just svn update and retry.

Jakub

Re: weakref and static

[Jakub Jelinek]

On Sat, Dec 17, 2005 at 10:56:51AM -0200, Alexandre Oliva wrote:
> > I thus propose your change to be reverted, and request you to explain
> > what you were trying to fix with this patch so that I can try to do
> > something about it.
> 
> Nevermind this bit :-)
> 
> 
> Jakub, do you have any further details on the s390 bootstrap failure
> introduced with this patch?  I'm not aware of it, and I feel I should

That one is already fixed,
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00646.html
But there are dozens of other uses of TREE_PUBLIC in the backends, so
it wouldn't surprise me if something similar is not present on other arches.

Normal aliases are usually declared through
extern __typeof (foo) bar __attribute__((alias ("foo")));
eventhough the alias really is defined in that file, so I don't see why
weakref aliases couldn't be declared the same way.

Jakub

Re: GCC 4.1 ICE during CPU2000/177.mesa build

[Jakub Jelinek]

On Tue, Dec 20, 2005 at 11:04:11PM +0300, Grigory Zagorodnev wrote:
> GCC 4.1 is getting ICE in ' refers_to_regno_for_reload_p' while 
> compiling CPU2000/177.mesa on ia32 Linux.
> 
> Is that a known issue?
> This is what I got:
> 
> triangle.c: In function 'simple_z_textured_triangle':
> triangle.c:461: internal compiler error: in 
> refers_to_regno_for_reload_p, at reload.c:
> 6285
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> specmake: *** [mesa] Error 1

See http://gcc.gnu.org/PR24982
Just svn update and try again.

Jakub

Re: weakref miscompiling libgfortran

[Jakub Jelinek]

On Mon, Dec 26, 2005 at 11:34:16PM -0800, Geoff Keating wrote:
> We've had Real Problems with this feature since it was introduced.  I  
> expect it'll take at least another two or three months before it  
> settles down and starts to work on most targets; that's only to be  
> expected for such a far-reaching change to GCC's capabilities.

It works just fine on ELF targets on gcc-4_1-branch, where you haven't
applied your set of changes (as well as in the 4.0, 3.4 and 3.2 backports
Alex did).

More importantly, it is very wrong if GCC 4.1 and 4.2 weakrefs are
incompatible in their user visible part (trunk requires
static __typeof (bar) foo __attribute__ ((weakref ("bar")))
while 4.1 requires
extern __typeof (bar) foo __attribute__ ((weakref ("bar")))
).

IMHO this needs to be resolved before GCC 4.1 is released, so very soon.

Either someone needs to investigate all TREE_PUBLIC checks in whole GCC
and backport trunk changes to 4.1; I'd say this is pretty dangerous.
Or the trunk change needs to be reverted.  Or perhaps 4.1 could keep
the static __typeof (bar) ... syntax, but internally set TREE_PUBLIC
in those cases (this will need some changes if we want to allow say
static __typeof (bar) foo;
...
static __typeof (bar) foo __attribute__ ((weakref ("bar")));
or
static __typeof (bar) foo __attribute__ ((weakref ("bar")));
...
static __typeof (bar) foo;
but I don't think they really need to be allowed).

Jakub

Re: weakref miscompiling libgfortran

[Jakub Jelinek]

On Tue, Dec 27, 2005 at 02:20:44PM -0800, Geoff Keating wrote:
> I'm not sure what "just fine" definition you're using here.  I don't  
> think you can say it's been extensively tested, and I'm fairly sure I  
> can find a bunch of bugs in it.  I have already filed one as  gcc.gnu.org/bugzilla/show_bug.cgi?id=25140>; I understand that also  
> occurs on ELF targets.  I don't believe it's been tested with IMA  

PR25140 talks about something common to all kinds of aliases (replace
`weakref' with `alias' or `weak, alias' and you'll get exactly the same
result), so I don't know why you make a case against weakref from it.
Weakrefs aren't really needed on Darwin for the purpose they have been
added, so they could very well just be unsupported there too (if the
target object file format doesn't support any kinds of aliases, why should
it support weakrefs?).

> I would describe the version on the 4.1 branch as a hack that's to  
> work only for libgfortran on ELF targets, and that's OK; but that  
> version is not ready for general use.  I'd like to see such a general- 

It has nothing to do with libgfortran actually, libgfortran only ever
uses the weak pthread function aliases within libgfortran.
The reason why weakref attribute has been added is primarily libstdc++,
see PR4372, because unlike libgfortran or libobjc, libstdc++ installed
headers were using #pragma weak on all pthread_* functions it wanted
to use.

Jakub

Re: weakref miscompiling libgfortran

[Jakub Jelinek]

On Tue, Dec 27, 2005 at 06:39:58PM -0500, Andrew Pinski wrote:
> 
> On Dec 27, 2005, at 6:36 PM, Jakub Jelinek wrote:
> >It has nothing to do with libgfortran actually, libgfortran only ever
> >uses the weak pthread function aliases within libgfortran.
> >The reason why weakref attribute has been added is primarily libstdc++,
> >see PR4372, because unlike libgfortran or libobjc, libstdc++ installed
> >headers were using #pragma weak on all pthread_* functions it wanted
> >to use.
> 
> But as mentioned the feature was not thought through.  It has not been 
> tested
> that well (or at all) with stuff like IMA or templates.

It works with templates the same way as __attribute__ ((alias ("...")))
and has no ambitions to work any better than that.

And at least the way it is used in gthr*.h, it works with IMA (the weakref
aliases have the same name in all compile units they are used in and are
never used for anything else).

Both TREE_PUBLIC and !TREE_PUBLIC on the weakref have some sense,
weakref is a static alias to external object/function, so either
you need to handle weakrefs specially in some parts of the frontends/IMA
and have TREE_PUBLIC set, or you need to special case it in middle-end
and all backends and have TREE_PUBLIC unset.

> I still support a reverting of the weakref patch as it was put way too 
> late
> for 4.1 (stage 3 is not a good idea for a new feature).

Depends on if you consider it a new feature or a bug fix.

Jakub

Re: RFC: An option to link against static gcc libraries

[Jakub Jelinek]

On Fri, Dec 30, 2005 at 10:58:16AM -0800, H. J. Lu wrote:
> > One, this will not work at all libobjc or libgcj since they
> > require lookups at runtime.
> 
> Are you saying "gcc -static" doesn't work with libobjc and libgcj?

It certainly doesn't work with libgcj (well, you can link in libgcj.a,
but it will almost certainly never work right, for some programs
--whole-archive helps a bit, but for most programs doesn't).
That's why Fedora stopped including any Java .a libraries many
months ago.

Jakub

Re: RFC: generalize STARTFILE/ENDFILE_SPEC for linux

[Jakub Jelinek]

On Mon, Jan 09, 2006 at 02:38:17PM +0100, Peter S. Mazinger wrote:
> for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility 
> would be
> %{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
> %{ffast-math|funsafe-math-optimizations:%:if-exists(crtfastmath.o%s)}

That's IMHO a bad idea, because that means additional runtime overhead.

Jakub

Re: merges

[Jakub Jelinek]

On Thu, Jan 12, 2006 at 11:12:36AM +0100, Giovanni Bajo wrote:
> Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> 
> >> mysql> delete from longdescs where length(thetext) > 100;
> >> Query OK, 251 rows affected (2 min 12.11 sec)
> > 
> > Thank you.
> > 
> >> I may just set up a pre-commit hook to check the log message length and
> >> hav eit not let you commit if it's ridiculously large.
> > 
> > Maybe checkins on a branch shouldn't affect the bugzilla database at all?
> 
> Not sure. We badly need them at least for release branches...

Yes.  I think they are useful for all branches if you backport a patch for
a particular fix or e.g. fix something that is not yet fixed on the trunk
and will be only when a particular devel branch with that fix is merged
into trunk.  But in all cases that should be a single commit to fix a
particular bug (or a set of closely related bugs).  Plain merges from
other branches should just say what branch, perhaps revisions were merged.

Jakub

Re: libgomp and OMP_NUM_THREADS

[Jakub Jelinek]

On Thu, Jan 19, 2006 at 04:35:17PM -0700, Walter Szeliga wrote:
> Hello,
>   It appears that although the most recent svn update (Revision  
> 109975) of gcc compiles apparently fine, simple OpenMP programs will  
> only operate when OMP_NUM_THREADS=1.  I am compiling and running gcc  
> on a Dual CPU G5 PowerPC running OS X 10.4.4.  If I compile  
> omp_hello.c from testsuite/libgomp.c with
> 
>  gcc -fopenmp omp_hello.c -o omp_hello -lgomp
> 
> then the program reports that 1 thread is created.  If I then set  
> OMP_NUM_THREADS=2, omp_hello hangs.  If one runs recomplies this  
> program, runs it in gdb and Ctrl-C's it when it hangs, here is the  
> backtrace generated

Yeah, that's a known thing, libgomp is miscompiled on PowerPC.
> 
> #0  0x900c48fc in sem_wait ()
> #1  0x00020c24 in gomp_sem_wait (sem=0x222c4) at ../../../gomp/ 
> libgomp/config/posix/sem.c:44
> #2  0x00020d68 in gomp_barrier_wait_end (bar=0x22298,  
> last=4294967295) at ../../../gomp/libgomp/config/posix/bar.c:92
> #3  0x000202f8 in gomp_team_start (fn=0x2a08 ,  
> data=0x0, nthreads=2, work_share=0x0) at ../../../gomp/libgomp/team.c: 
> 293
> #4  0x29e0 in main (argc=1, argv=0xb714) at omp_hello.c:33

On redhat/gcc-4_1-branch (which has also a gomp branch backport)
I'm using following patch that cures it, but I bet it won't apply cleanly
to the trunk.

2005-11-25  Jakub Jelinek  <[EMAIL PROTECTED]>

* config/rs6000/rs6000.md (UNSPEC_LWSYNC, UNSPEC_ISYNC,
UNSPEC_SYNC_OP, UNSPEC_ATOMIC, UNSPEC_CMPXCHG, UNSPEC_XCHG): Rename
to...
(UNSPECV_LWSYNC, UNSPECV_ISYNC, UNSPECV_SYNC_OP, UNSPECV_ATOMIC,
UNSPECV_CMPXCHG, UNSPECV_XCHG): ... these.
* config/rs6000/sync.md: Adjust for the above changes, use
unspec_volatile instead of unspec for
UNSPECV_{SYNC_OP,ATOMIC,CMPXCHG,XCHG}.

--- gcc/config/rs6000/sync.md.jj2005-11-24 13:24:35.0 +0100
+++ gcc/config/rs6000/sync.md   2005-11-25 10:43:31.0 +0100
@@ -70,10 +70,10 @@
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=&r")
(match_operand:GPR 1 "memory_operand" "+Z"))
(set (match_dup 1)
-   (unspec:GPR
+   (unspec_volatile:GPR
  [(match_operand:GPR 2 "reg_or_short_operand" "rI")
   (match_operand:GPR 3 "gpc_reg_operand" "r")]
- UNSPEC_CMPXCHG))
+ UNSPECV_CMPXCHG))
(clobber (match_scratch:GPR 4 "=&r"))
(clobber (match_scratch:CC 5 "=&x"))]
   "TARGET_POWERPC"
@@ -90,9 +90,9 @@
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=&r")
(match_operand:GPR 1 "memory_operand" "+Z"))
(set (match_dup 1)
-   (unspec:GPR
+   (unspec_volatile:GPR
  [(match_operand:GPR 2 "reg_or_short_operand" "rL")]
- UNSPEC_XCHG))
+ UNSPECV_XCHG))
(clobber (match_scratch:GPR 3 "=&r"))
(clobber (match_scratch:CC 4 "=&x"))]
   "TARGET_POWERPC"
@@ -107,10 +107,10 @@
 
 (define_expand "sync_"
   [(parallel [(set (match_operand:INT1 0 "memory_operand" "")
-  (unspec:INT1
+  (unspec_volatile:INT1
 [(FETCHOP:INT1 (match_dup 0)
(match_operand:INT1 1 "" ""))]
-UNSPEC_ATOMIC))
+UNSPECV_ATOMIC))
  (clobber (scratch:INT1))
  (clobber (scratch:CC))])]
   "TARGET_POWERPC"
@@ -128,10 +128,10 @@
 
 (define_insn_and_split "*sync_si_internal"
   [(set (match_operand:SI 0 "memory_operand" "+Z")
-   (unspec:SI
+   (unspec_volatile:SI
  [(FETCHOP:SI (match_dup 0)
 (match_operand:SI 1 "" ""))]
- UNSPEC_ATOMIC))
+ UNSPECV_ATOMIC))
(clobber (match_scratch:SI 2 "=&b"))
(clobber (match_scratch:CC 3 "=&x"))]
   "TARGET_POWERPC"
@@ -146,10 +146,10 @@
 
 (define_insn_and_split "*sync_di_internal"
   [(set (match_operand:DI 0 "memory_operand" "+Z")
-   (unspec:DI
+   (unspec_volatile:DI
  [(FETCHOP:DI (match_dup 0)
 (match_operand:DI 1 "" ""))]
- UNSPEC_ATOMIC))
+ UNSPECV_ATOMIC))
(clobber (match_scratch:DI 2 "=&b"))
(clobber (match_scratch:CC 3 "=&x"))]
   "TARGET_POWERPC"
@@ -164,10 +164,10 @@
 
 (define_expand "sync_nand"
   [(parallel [(set (match_operand:INT1 0 "memory_operand" "")
- (unspec:INT1
+ (unspec_volatile:INT1
[(and:INT1 (not:INT1 (match_dup 0))
   (match_

Whitespace at the start of first line of commit

[Jakub Jelinek]

Hi!

I've noticed that a couple of Jason's commits show up in gcc-cvs
in mutt as:
[gcc r10-5937] ?PR c++/92582 - ICE with member template as requirement.
The ? in there comes from a tab character, the full subject is like
Subject: 
=?utf-8?q?=5Bgcc_r10-5937=5D_=09PR_c++/92582_-_ICE_with_member_template_a?=
 =?utf-8?q?s_requirement=2E?=

One possibility to deal with this is:
--- hooks/updates/__init__.py   2020-01-12 22:30:37.143193572 +0100
+++ hooks/updates/__init__.py   2020-01-14 11:20:05.746749843 +0100
@@ -315,7 +315,7 @@ class AbstractUpdate(object):
 subject = '[%(repo)s%(branch)s] %(subject)s' % {
 'repo': self.email_info.project_name,
 'branch': branch,
-'subject': commit.subject[:SUBJECT_MAX_SUBJECT_CHARS],
+'subject': commit.subject[:SUBJECT_MAX_SUBJECT_CHARS].strip (),
 }
 
 # Generate the body of the email in two pieces:
(untested), another, suggested by Richard on IRC, would be to reject
commits where the first line starts with whitespace.

So, what do we want to do here?

Jakub

Re: git conversion in progress

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 12:34:13PM +0100, Andreas Schwab wrote:
> On Jan 14 2020, Georg-Johann Lay wrote:
> 
> > git clone --reference original-gcc ...
> 
> Don't use --reference.  It is too easy to lose work if you don't know
> what you are doing.

Wouldn't git clone --reference original-gcc --dissociate ...
be ok?  I.e. just save bandwidth when needing second repo if for whatever
reason git worktree isn't possible?

Jakub

Re: Do we want to add -fsanitize=function?

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 12:36:11PM +0100, Martin Liška wrote:
> The missing sanitizer reports about violations of function signatures
> for indirect calls, like:
> 
> $ cat sanitize-function.cpp
> #include 
> 
> void f() {}
> void (*fnpointer) (int);
> 
> void save () {
>   fnpointer = reinterpret_cast(reinterpret_cast(f));
> }
> 
> int main(void) {
>   save ();
>   fnpointer (32);
> }

_Z4savev:   # @_Z4savev
.cfi_startproc
.long   846595819   # 0x327606eb
.long   .L__unnamed_2-_Z4savev
# %bb.0:# %entry
...
seems to be what they emit on x86_64.  Now, wonder what they do on other
targets, and how does it play with all the other options that add stuff
to the start of functions, e.g. -fcf-protection=full (where it needs to
really start with endbr64 instruction), or the various options for
patcheable function entries, -mfentry, profiling and the like.

Jakub

Re: Do we want to add -fsanitize=function?

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 01:57:47PM +0100, Martin Liška wrote:
> > seems to be what they emit on x86_64.  Now, wonder what they do on other
> > targets
> 
> Other targets are not supported :P
> 
> > , and how does it play with all the other options that add stuff
> > to the start of functions, e.g. -fcf-protection=full (where it needs to
> > really start with endbr64 instruction)
> 
> Using the options one will get:
> 
> _Z4savev:   # @_Z4savev
>   .cfi_startproc
>   .long   846595819   # 0x327606eb
>   .long   .L__unnamed_2-_Z4savev
> # %bb.0:
>   endbr64
> 
> So endbr64 is placed after the RTTI record.

Which is wrong, this will then fail on CET hardware.

Jakub

Re: Do we want to add -fsanitize=function?

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 02:56:38PM +0100, Martin Liška wrote:
> On 1/14/20 1:59 PM, Jakub Jelinek wrote:
> > On Tue, Jan 14, 2020 at 01:57:47PM +0100, Martin Liška wrote:
> > > > seems to be what they emit on x86_64.  Now, wonder what they do on other
> > > > targets
> > > 
> > > Other targets are not supported :P
> > > 
> > > > , and how does it play with all the other options that add stuff
> > > > to the start of functions, e.g. -fcf-protection=full (where it needs to
> > > > really start with endbr64 instruction)
> > > 
> > > Using the options one will get:
> > > 
> > > _Z4savev:   # @_Z4savev
> > >   .cfi_startproc
> > >   .long   846595819   # 0x327606eb
> > >   .long   .L__unnamed_2-_Z4savev
> > > # %bb.0:
> > >   endbr64
> > > 
> > > So endbr64 is placed after the RTTI record.
> > 
> > Which is wrong, this will then fail on CET hardware.
> 
> Sure, which is a minor limitation. FCF is supposed to be production
> security feature while UBSAN is more for a testing playground.

But then the compiler should just fail if you mix the two, rather than
emitting something that doesn't work at all.
Or better fix the design, so that it can grok an endbr64 together with
the following jump as another magic.

Jakub

Re: Do we want to add -fsanitize=function?

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 04:15:54PM +0100, Martin Liška wrote:
> On 1/14/20 3:00 PM, Jakub Jelinek wrote:
> > But then the compiler should just fail if you mix the two, rather than
> > emitting something that doesn't work at all.
> > Or better fix the design, so that it can grok an endbr64 together with
> > the following jump as another magic.
> 
> Sure. One can make an error when these 2 options are mixed together.
> So the question still remains opened, do we want to implement the
> sanitizer feature?

IMHO not for GCC 10, for GCC 11, it really sounds too hackish, so unsure.
It should at least cover more than one arch and have these issues like CET
etc. discussed upstream.

Jakub

Towards removal of gcc/DATESTAMP

[Jakub Jelinek]

Hi!

The following command prints the same string as DATESTAMP file
contains in all gcc-7 and later based branches I've tried so far (and nothing 
when
e.g. invoked from within svn checkout).

o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat 
BASE-VER | cut -d. -f 1); b=; if git rev-parse --verify --quiet 
$o/releases/gcc-$r >/dev/null; then b=origin/releases/gcc-$r; elif git 
rev-parse --verify --quiet $o/releases/gcc-9 >/dev/null; then b=$o/master; fi; 
test -n "$b" && TZ=UTC LC_ALL=C git log --date=iso -1 $(git merge-base HEAD $b) 
| sed -n 's/^Date:[[:blank:]]*//p' | sed 's/ .*$//;s/-//g'

I haven't bothered with the bumping at 00:16 UTC, the script assumes bump
on 00:00 UTC instead.

Do we want to replace DATESTAMP bumping with something like that?

There are several issues that need to be figured out:

1) some trees will not be git repositories, e.g. release tarballs, snapshot
   tarballs or e.g. vendor gcc tarball snapshots; for release
   tarballs/snapshots, we could arrange for gcc_release to create
   gcc/DATESTAMP file that way and have some script e.g. for vendors to
   use that would do the same; gcc/Makefile.in then could use
   gcc/DATESTAMP if it is present, fallback to git command above (perhaps
   made more portable if needed) and fail if neither works?
2) in gcc/Makefile.in, e.g. version.o depends on DATESTAMP file and the
   rebuild happens when the timestamp on that file changes; should we
   e.g. create gcc/DATESTAMP file in the build directory with some
   move-if-change hacks around and let version.o depend on a goal that
   will do that and on the build directory gcc/DATESTAMP?
3) should we handle gcc/REVISION stuff similarly (and use what
   gcc-descr alias does without that alias) for that commit, perhaps
   with --full or maybe just with somewhat smaller --abbrev= (say 20 rather
   than 40 chars)?

Jakub

Re: Towards removal of gcc/DATESTAMP

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 04:52:12PM +0100, Jakub Jelinek wrote:
> The following command prints the same string as DATESTAMP file
> contains in all gcc-7 and later based branches I've tried so far (and nothing 
> when
> e.g. invoked from within svn checkout).

Jonathan wondered on IRC about the weirdo hardcoded check for releases/gcc-9.
The intent was to punt if it isn't a git tree at all, or e.g. somebody
unpacks gcc tarball without gcc/DATESTAMP file in it into his git tracked
home directory.

Perhaps better might be start with
if git merge-base --is-ancestor 633c65dda889eb887fb6ce3b04cefdeb4a69b0b3 HEAD; 
then ... ; fi
to verify it is GCC 8+ (for older we of course would never omit
gcc/DATESTAMP).

> o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat 
> BASE-VER | cut -d. -f 1); b=; if git rev-parse --verify --quiet 
> $o/releases/gcc-$r >/dev/null; then b=origin/releases/gcc-$r; elif git 
> rev-parse --verify --quiet $o/releases/gcc-9 >/dev/null; then b=$o/master; 
> fi; test -n "$b" && TZ=UTC LC_ALL=C git log --date=iso -1 $(git merge-base 
> HEAD $b) | sed -n 's/^Date:[[:blank:]]*//p' | sed 's/ .*$//;s/-//g'

Jakub

Re: git conversion in progress

[Jakub Jelinek]

On Tue, Jan 14, 2020 at 06:06:36PM +, Joseph Myers wrote:
> On Tue, 14 Jan 2020, Jason Merrill wrote:
> 
> > I notice that git.html on the website doesn't match what's currently in
> > wwwdocs git, is automatic updating broken?
> 
> /www/gcc/wwwdocs-checkout/cgi-bin/gcc-gitref.cgi had local changes 
> (committed, but not reverted in that checkout before they were committed), 
> thereby breaking automatic updates:
> 
> error: Your local changes to the following files would be overwritten by 
> merge:
> cgi-bin/gcc-gitref.cgi
> Please commit your changes or stash them before you merge.
> Aborting
> 
> I've now reverted that and updated that checkout and am running 
> update_web_docs_git which preprocesses the whole website among other 
> things.

Oops, sorry for that, forgot to remove those after I was done with testing
it.

Jakub

gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

Hi!

As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
a simple
git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
which merged in just a few hours from trunk, but that resulted in
20 separate mails to gcc-cvs ml.
Is that what we want?  I mean it doesn't scale well, even if everybody has
just a couple of personal branches + few vendor branches for all, if some of
them will be tracking master or release branches, if each such push
pushes all the commits again, there will be tens of thousands of mails.
And forcing everybody to squash all merge commits because of this is
undesirable.
Could we somehow detect merges from other branches (or say only master or
release branches) and don't send mails for those and send just a mail for
the merge commit?
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?

Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Wed, Jan 15, 2020 at 02:56:45PM +, Joseph Myers wrote:
> > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> > a simple
> > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> > git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> > which merged in just a few hours from trunk, but that resulted in
> > 20 separate mails to gcc-cvs ml.
> 
> Joel, this is definitely a question for you; it's beyond my expertise in 
> the working of the hooks.  The issue is that when a merge commit is 
> pushed, we only want mails for commits that are new *to the repository* - 
> not those that are already in the repository (accessible from some other 
> ref before the ref update being processed by the hook comes into effect), 
> but are new *to the branch*.

Yeah.  For release branches I think we want mails for all changes, but
then we don't allow merge commits there; for cherry-picked patches e.g. from
trunk to release branches we should still send mail.

> I think there's a similar issue not just for merges but for 
> non-fast-forward pushes as well.  As a glibc example, consider 
>  and the long 
> series of subsequent mails in the glibc-cvs archives.  It's correct that 
> the five or so rebased patches on the branch got mailed out again.  It's 
> *not* desirable that the 50 or so patches that were already on master, 
> that the branch got rebased on top of, got mailed out again.

Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote:
> > I think there's a similar issue not just for merges but for 
> > non-fast-forward pushes as well.  As a glibc example, consider 
> >  and the long 
> > series of subsequent mails in the glibc-cvs archives.  It's correct that 
> > the five or so rebased patches on the branch got mailed out again.  It's 
> > *not* desirable that the 50 or so patches that were already on master, 
> > that the branch got rebased on top of, got mailed out again.
> 
> At heart, it is really the same issue. New commits were brought into
> this branch, and thus if email notification is enabled for that branch,
> then those commits should trigger emails for their own as well.
> 
> Typically, branches were non-fast-forward changes are allowed are
> branches that are personal and not shared. In those instances,
> the typical setup is to disable emails on those development branches.
> It sounds to me like turning emails off for branches that can
> do non-fast-forward is the better solution here.

Couldn't it be then per-branch setting, whether to mail even commits
that aren't new to the repository or not (like I understood it is already
possible to decide per-branch whether to send mails at all)?
E.g. for GCC, I'd certainly like to see mails for all commits on the
trunk and release branches (but we don't allow merge commits on them
anyway), and for other branches (personal, vendor, devel) I think mailing
only about new commits not already in the repository would be better over
not mailing at all.

Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 02:15:21PM +, Richard Earnshaw (lists) wrote:
> The alternative I suggested to Joseph yesterday was a separate mailing list
> for all the personal and vendor commits.  But I think that would need a
> change to the hooks infrastructure.

Would that solve it?  We have around 7500 to 8000 trunk commits a year
lately, so on the trunk+release branch mailing list it would be say 12000
mails a year, but if there are say 30 long lived devel/personal/vendor
branches that track trunk that would already mean 24 mails alone in
those merge commits.  Sure, for branches tracking release branches it will
be less than that.  As a random sample, I've picked a random gcc trunk test
added in June and it got merged into 5 tracking branches later on 6 branches
tracking release branches.  That was with svn (but that one sent one mail
per merge, not hundreds), but git encourages that people push their devel
branches upstream.

Jakub

Re: 1-800-GIT-HELP: Fixing a commit message?

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 07:51:37PM +0100, Gerald Pfeifer wrote:
> It turns out I fumbled the commit message on the commit below to wwwdocs.
> 
> Instead of 
> Redirect cvswrite.html to gitwrite.html instead of svnwrite.html.
> I committed this with a message of 
> Redirect cvs.html to git.html instead of svn.html.
> and pushed already.
> 
> In CVS I could manually edit the ,v files; in SVN I believe we did
> not want to allow for fixing commit messages a posteriori -- how 
> about our Git setup?  Policy-wise and practically?

In SVN one could do it and various people have done it (I see 96 svn:log
changed mails since we started using svn in gcc-cvs).
In Git, one can do it before pushing (git rebase -i), but it is highly
undesirable to do it after pushing (for some branches disallowed completely,
for wwwdocs maybe not but it will break everybody else who has checked it
out, including sourceware's automatic copy).

Jakub