Wrong information about GnuPG keys at page listing GCC mirrors

[Damian Pietras]

There is probably an outdated information on GnuPG keys at
http://gcc.gnu.org/mirrors.html

The newest gcc 4.4.0 (gcc-4.4.0.tar.bz2) is signed using a key not listed
on this page (key ID C3C45C06). I think it's worth to fix this
information.

-- 
Damian Pietras

http://www.linuxprogrammingblog.com

dodgy syntax in acx.m4?

[Jay Foad]

I've just noticed this in config/acx.m4:

dnl GCC_TARGET_TOOL(PROGRAM, TARGET-VAR, HOST-VAR, IN-TREE-TOOL, LANGUAGE)
AC_DEFUN([GCC_TARGET_TOOL],
[AC_MSG_CHECKING(where to find the target $1)
if test "x${build}" != "x${host}" ; then
  ...
else
  ifelse([$4],,,
  [ok=yes
  case " ${configdirs} " in
*" patsubst([$4], [/.*], []) "*) ;;
*) ok=no ;;
  esac
  ifelse([$5],,,
  [case ,${enable_languages}, in
*,$5,*) ;;
*) ok=no ;;
  esac])
  if test $ok = yes; then
# An in-tree tool is available and we can use it
$2='$$r/$(HOST_SUBDIR)/$4'
AC_MSG_RESULT(just compiled)
  el])if expr "x[$]$2" : "x/" > /dev/null; then
  ^^

That "el])if" looks very odd. Is it meant to be like that?

Thanks,
Jay.

Re: gcc-4.4.0.tar.gz.sig, expired key

[Jakub Jelinek]

On Thu, Apr 23, 2009 at 08:09:55PM -0700, Keith Thompson wrote:
> gcc-4.4.0.tar.gz.sig was generated with an expired key:
> 
> gpg: Signature made Tue 21 Apr 2009 07:35:29 AM PDT using DSA key ID C3C45C06
> gpg: Good signature from "Jakub Jelinek "
> gpg: Note: This key has expired!
> Primary key fingerprint: 33C2 35A3 4C46 AA3F FB29  3709 A328 C3A2 C3C4 5C06
> 
> I'm using ftp://ftp.gnu.org/gnu/gnu-keyring.gpg, downloaded after I
> downloaded gcc-4.4.0.tar.gz.sig.

I've extended its expiration before the release.  Just
gpg --keyserver hkp://pgp.mit.edu/ --recv-keys C3C45C06

Jakub

Re: dodgy syntax in acx.m4?

[Andreas Schwab]

Jay Foad  writes:

> I've just noticed this in config/acx.m4:
>
> dnl GCC_TARGET_TOOL(PROGRAM, TARGET-VAR, HOST-VAR, IN-TREE-TOOL, LANGUAGE)
> AC_DEFUN([GCC_TARGET_TOOL],
> [AC_MSG_CHECKING(where to find the target $1)
> if test "x${build}" != "x${host}" ; then
>   ...
> else
>   ifelse([$4],,,
>   [ok=yes
>   case " ${configdirs} " in
> *" patsubst([$4], [/.*], []) "*) ;;
> *) ok=no ;;
>   esac
>   ifelse([$5],,,
>   [case ,${enable_languages}, in
> *,$5,*) ;;
> *) ok=no ;;
>   esac])
>   if test $ok = yes; then
> # An in-tree tool is available and we can use it
> $2='$$r/$(HOST_SUBDIR)/$4'
> AC_MSG_RESULT(just compiled)
>   el])if expr "x[$]$2" : "x/" > /dev/null; then
>   ^^
>
> That "el])if" looks very odd. Is it meant to be like that?

If $4 is empty this expands to "if expr ...", otherwise you get "ok=yes
... if test $ok = yes; then ... elif expr ..."

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: testsuite fixes for small doubles

[Joseph S. Myers]

On Thu, 23 Apr 2009, DJ Delorie wrote:

> Index: gcc.dg/torture/fp-int-convert-long-double.c
> ===
> --- gcc.dg/torture/fp-int-convert-long-double.c   (revision 146652)
> +++ gcc.dg/torture/fp-int-convert-long-double.c   (working copy)
> @@ -10,9 +10,12 @@ int
>  main (void)
>  {
>TEST_I_F(signed char, unsigned char, long double, LDBL_MANT_DIG);
>TEST_I_F(signed short, unsigned short, long double, LDBL_MANT_DIG);
>TEST_I_F(signed int, unsigned int, long double, LDBL_MANT_DIG);
>TEST_I_F(signed long, unsigned long, long double, LDBL_MANT_DIG);
> -  TEST_I_F(signed long long, unsigned long long, long double, LDBL_MANT_DIG);
> +  if (sizeof(long double) > sizeof(long long))
> +{
> +  TEST_I_F(signed long long, unsigned long long, long double, 
> LDBL_MANT_DIG);
> +}

The fp-int-convert tests are meant to be correct independent of the sizes 
involved, so this change is inappropriate and may point to a bug 
elsewhere.  Note that there are tests of conversion between long long and 
float (and between TImode and float where TImode is supported).  The only 
case these tests don't handle is inexact conversions to/from non-IEEE 
types (IBM long double), hence the conditional in fp-int-convert-timode.c 
on LDBL_MANT_DIG != 106.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Wrong information about GnuPG keys at page listing GCC mirrors

[Gerald Pfeifer]

On Fri, 24 Apr 2009, Damian Pietras wrote:
> There is probably an outdated information on GnuPG keys at
> http://gcc.gnu.org/mirrors.html

Thanks for the report, Damian.  Jakub just updated the website, and
you should now find the key having signed the GCC 4.4.0 release there.

Gerald

Slight tree reorganization for cygming platforms

[Vincent R.]

Hi,

I am playing(don't know if it's the right word) for a few months with a
modified gcc targeting
arm-wince-pe and I have noticed some ugly organization in files that force
to have multiple files
with in general only one or two differences.
For instance here is some part of our patch :

--- libgcc/config/arm/t-wince-pe(revision 0)
+++ libgcc/config/arm/t-wince-pe(revision 0)
@@ -0,0 +1,11 @@
+CUSTOM_CRTSTUFF = yes
+
+crtbegin.o: $(gcc_srcdir)/config/i386/cygming-crtbegin.c
+   $(crt_compile) -fno-omit-frame-pointer  -c \
+   $(gcc_srcdir)/config/i386/cygming-crtbegin.c

so as you can see even if we are working on a arm platform we are using a
file in i386.

--- gcc/config.gcc  (revision 144970)
+++ gcc/config.gcc  (working copy)
+arm-*-mingw32*)
+   tm_file="${tm_file} arm/semi.h arm/aout.h arm/coff.h dbxcoff.h arm/pe.h
arm/wince-pe.h arm/mingw32.h"
+   # xm_file=arm/xm-mingw32.h
+   # This has to match the logic for DWARF2_UNWIND_INFO in
gcc/config/i386/cygming.h
+   if test x$sjlj = x0; then
+   tmake_eh_file="i386/t-dw2-eh"
+   else
+   tmake_eh_file="i386/t-sjlj-eh"
+   fi
+   tmake_file="${tmake_file} ${tmake_eh_file} arm/t-arm arm/t-wince-pe
arm/t-cygming arm/t-mingw32"
+   target_gtfiles="\$(srcdir)/config/arm/pe.c"
+   extra_options="${extra_options} arm/pe.opt arm/cygming.opt"
+   extra_objs="pe.o pe-stubs.o"
+   c_target_objs="${c_target_objs} \$(srcdir)/config/i386/msformat-c.o"
+   cxx_target_objs="pe-cxx.o \$(srcdir)/config/i386/msformat-c.o"
+   default_use_cxa_atexit=yes
+   case ${enable_threads} in
+ "" | yes | win32)
+ thread_file='win32'
+ tmake_file="${tmake_file} i386/t-gthr-win32"
+ ;;
+   esac

Once again we are  referencing i386/t-gthr-win32, i386/t-dw2-eh and
i386/t-sjlj-eh 
and this is stupid because those files have only one definition that is not
i386 specific.

I will show with a last example but I could continue like that with more
cases :

--- gcc/config/arm/t-wince-pe   (revision 144970)
+++ gcc/config/arm/t-wince-pe   (working copy)
@@ -20,12 +20,34 @@
echo '#endif' >> dp-bit.c
cat $(srcdir)/config/fp-bit.c >> dp-bit.c
 
...
+#hack! using i386 file directly...
+msformat-c.o: $(srcdir)/config/i386/msformat-c.c $(CONFIG_H) $(SYSTEM_H)
coretypes.h \
+  $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \
+  $(TM_P_H) toplev.h $(HASHTAB_H) $(GGC_H)
+   $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
+   $(srcdir)/config/i386/msformat-c.c 

Once again we are referencing a file in i386 that is not specific ...


What I propose is to reorganize a bit files for ms support and to put
together common
declaration and stop to consider it as i386 specific.
Couldn't be more clever to create a cygwmin folder with the following file
:

+cygmin
  t-gthr-win32
  msformat-c.c
  t-dw2-eh
  t-sjlj-eh
  mingw32.h

For information all the ms platforms are sharing lots of defintions and the
following platforms
could benefit from it because right now we are have to copy/paste for every
new ms derived platform
or reference files in i386 folder.

i386-w32 (win32)
i386-w64 (win64)
i386-wce (wince)
arm-wce (arm-wince-pe)
mips-wce(mips-wince-pe)

What do you think ? 


Vincent R.

Re: dodgy syntax in acx.m4?

[Jay Foad]

> If $4 is empty this expands to "if expr ...", otherwise you get "ok=yes
> ... if test $ok = yes; then ... elif expr ..."

Thanks for the explanation! I didn't realise it was trying to be that clever.

Thanks,
Jay.

Emit jump insn in function prologue

[Peter Leist]

Hi all,

can I use emit_cmp_and_jump_insns while creating the function prologue/epilogue?
If I try, I always get an error at runtime

func.c:33: internal compiler error: in make_edges, at cfgbuild.c:354

I think this is because the jump doesn't get an JUMP_LABEL associated to it.
Is there an other way at this pass to add loops to the code?

thanks,
peter

Re: -O3 and new optimizations in 4.4.0

[Sebastian Pop]

Hi,

On Thu, Apr 23, 2009 at 10:57, Joseph S. Myers  wrote:
> Because the behavior of -O3 must not depend on whether optional libraries
> are linked into GCC, and we did not decide to make PPL and CLooG required
> to build GCC, so -O3 cannot enable any optimizations using optional
> libraries.
>

What would we have to do to make PPL and CLooG required to build GCC?

Sebastian Pop
--
AMD - GNU Tools

Re: -O3 and new optimizations in 4.4.0

[Robert Dewar]

Sebastian Pop wrote:

Hi,

On Thu, Apr 23, 2009 at 10:57, Joseph S. Myers  wrote:

Because the behavior of -O3 must not depend on whether optional libraries
are linked into GCC, and we did not decide to make PPL and CLooG required
to build GCC, so -O3 cannot enable any optimizations using optional
libraries.



What would we have to do to make PPL and CLooG required to build GCC?


Why would that be desirable? Seems to me the current situation is
clearly preferable.

Re: -O3 and new optimizations in 4.4.0

[Sebastian Pop]

On Fri, Apr 24, 2009 at 08:12, Robert Dewar  wrote:
>> What would we have to do to make PPL and CLooG required to build GCC?
>
> Why would that be desirable? Seems to me the current situation is
> clearly preferable.

To enable loop transforms in -O3.

Sebastian Pop
--
AMD - GNU Tools

Re: Slight tree reorganization for cygming platforms

[Dave Korn]

Vincent R. wrote:
> to have multiple files with in general only one or two differences.

  Funny, I thought that was good modular design with inheritance and override.
 YMMV!

> For instance here is some part of our patch :
> 
> --- libgcc/config/arm/t-wince-pe  (revision 0)
> +++ libgcc/config/arm/t-wince-pe  (revision 0)
> @@ -0,0 +1,11 @@
> +CUSTOM_CRTSTUFF = yes
> +
> +crtbegin.o: $(gcc_srcdir)/config/i386/cygming-crtbegin.c
> + $(crt_compile) -fno-omit-frame-pointer  -c \
> + $(gcc_srcdir)/config/i386/cygming-crtbegin.c
> 
> so as you can see even if we are working on a arm platform we are using a
> file in i386.

  That is not good.  If there's some common functionality it could be
extracted into a new file in config/ which could then be referenced from both
config/arm/ and config/i386/.

> Once again we are  referencing i386/t-gthr-win32, i386/t-dw2-eh and
> i386/t-sjlj-eh 
> and this is stupid because those files have only one definition that is not
> i386 specific.

  Or you could add your own fragments in config/arm/ to provide the
definitions that you want for your system.  But yes, you can't extract just
part of the i386 CRT EH machinery without dragging the rest with it.  I guess
nobody thought at the time it would turn out to be general enough to apply to
the embedded windows platforms as well as the i386.

> Once again we are referencing a file in i386 that is not specific ...
> 
> 
> What I propose is to reorganize a bit files for ms support and to put 
> together common declaration and stop to consider it as i386 specific. 

> For information all the ms platforms are sharing lots of defintions and the
> following platforms could benefit from it because right now we are have to
> copy/paste for every new ms derived platform or reference files in i386
> folder.

  I think there are more options than just those two, but certainly it is
right to common out the shared functionality.  I believe it should just go one
level up in config/ rather than have a subdir; there's a ton of shared stuff
in that directory already.

cheers,
  DaveK

Re: -O3 and new optimizations in 4.4.0

[Jack Howarth]

On Fri, Apr 24, 2009 at 08:30:37AM -0500, Sebastian Pop wrote:
> On Fri, Apr 24, 2...@08:12, Robert Dewar  wrote:
> >> What would we have to do to make PPL and CLooG required to build GCC?
> >
> > Why would that be desirable? Seems to me the current situation is
> > clearly preferable.
> 
> To enable loop transforms in -O3.
> 
> Sebastian Pop
> --
> AMD - GNU Tools
> 

Sebastian,
   I assume you are talking about enabling these optimizations
in -O3 for gcc 4.5. Unless the alias improvement changes
are backported for gcc 4.4.1, the graphite optimizations 
will yield performance degradations for the polyhedron 2005
benchmarks at -O3 in that case.
   Jack

What version of Boehm for --enable-objc-gc ?

[Fabrice Feray]

Hi,

What version of Boehm's gc is best fit for the objc runtime? It seems  
that the one that comes with gcc is a special version meant for java.  
Am I wrong?


Fab

Re: Slight tree reorganization for cygming platforms

[Pedro Alves]

On Friday 24 April 2009 10:05:00, Vincent R. wrote:
> Once again we are  referencing i386/t-gthr-win32, i386/t-dw2-eh and
> i386/t-sjlj-eh 
> and this is stupid because those files have only one definition that is not
> i386 specific.

That's the definition of a ...

> +#hack! using i386 file directly...
   ^

... hack.  This is not stupid.  It was a deliberate decision ---
it makes it much easier to carry around small local changes in the original
files, than to keep around local patches moving a bunch of things around...

On Friday 24 April 2009 14:50:06, Dave Korn wrote:
>   I think there are more options than just those two, but certainly it is
> right to common out the shared functionality.  


> I believe it should just go one 
> level up in config/ rather than have a subdir; there's a ton of shared stuff
> in that directory already.

I completelly agree.  This option has been my intent all along.  It just
needs someone to seriously propose doing it, and then, doing it.

How would people prefer something like this going forward?  Start with
extracting common stuff into config/, while making sure e.g, at least
one of mingw or cygwin still bootstraps/tests OK; or, start by
updating config/arm/ with copies of what's under config/i386/, and once
that is in, work on extracting/abstracting common stuff out?

Vincent pointed out the obvious abuses that are 100% reusable, but,
I'd like to reuse e.g., config/i386/winnt.c, config/i386/winnt-cxx.c,
config/i386/winnt-stubs.c for ARM as well.  E.g, currently, I've copied
config/i386/winnt.c over the current config/arm/pe.c (completelly replacing
it), and adjusted it a bit to make it work for ARM.  As you can see from
the hunk below, the main juice is shareable here (there's no fastcall
on ARM WinCE):

-- 
Pedro Alves

--- i386/winnt.c2009-04-19 21:56:24.0 +0100
+++ arm/pe.c2009-04-19 21:56:30.0 +0100
@@ -1,7 +1,6 @@
-/* Subroutines for insn-output.c for Windows NT.
-   Contributed by Douglas Rupp (dr...@cs.washington.edu)
-   Copyright (C) 1995, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
-   2005, 2006, 2007, 2008 Free Software Foundation, Inc.
+/* Routines for GCC for ARM/pe.
+   Copyright (C) 1995, 1996, 2000, 2001, 2002, 2004, 2005, 2007, 2008
+   Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -32,13 +31,11 @@ along with GCC; see the file COPYING3.  
 #include "tm_p.h"
 #include "toplev.h"
 #include "hashtab.h"
-#include "langhooks.h"
 #include "ggc.h"
-#include "target.h"
 
-/* i386/PE specific attribute support.
+/* arm/PE specific attribute support.
 
-   i386/PE has two new attributes:
+   arm/PE has two new attributes:
dllexport - for exporting a function/variable that will live in a dll
dllimport - for importing a function/variable from a dll
 
@@ -50,7 +47,7 @@ along with GCC; see the file COPYING3.  
 /* Handle a "shared" attribute;
arguments as in struct attribute_spec.handler.  */
 tree
-ix86_handle_shared_attribute (tree *node, tree name,
+arm_pe_handle_shared_attribute (tree *node, tree name,
  tree args ATTRIBUTE_UNUSED,
  int flags ATTRIBUTE_UNUSED, bool *no_add_attrs)
 {
@@ -67,7 +64,7 @@ ix86_handle_shared_attribute (tree *node
 /* Handle a "selectany" attribute;
arguments as in struct attribute_spec.handler.  */
 tree
-ix86_handle_selectany_attribute (tree *node, tree name,
+arm_pe_handle_selectany_attribute (tree *node, tree name,
 tree args ATTRIBUTE_UNUSED,
 int flags ATTRIBUTE_UNUSED,
 bool *no_add_attrs)
@@ -77,7 +74,7 @@ ix86_handle_selectany_attribute (tree *n
  until the language frontend has processed the decl. We'll check for
  initialization later in encode_section_info.  */
   if (TREE_CODE (*node) != VAR_DECL || !TREE_PUBLIC (*node))
-{  
+{
   error ("%qs attribute applies only to initialized variables"
 " with external linkage",  IDENTIFIER_POINTER (name));
   *no_add_attrs = true;
@@ -100,7 +97,7 @@ associated_type (tree decl)
 /* Return true if DECL should be a dllexport'd object.  */
 
 static bool
-i386_pe_determine_dllexport_p (tree decl)
+arm_pe_determine_dllexport_p (tree decl)
 {
   tree assoc;
 
@@ -113,7 +110,7 @@ i386_pe_determine_dllexport_p (tree decl
   /* Also mark class members of exported classes with dllexport.  */
   assoc = associated_type (decl);
   if (assoc && lookup_attribute ("dllexport", TYPE_ATTRIBUTES (assoc)))
-return i386_pe_type_dllexport_p (decl);
+return arm_pe_type_dllexport_p (decl);
 
   return false;
 }
@@ -121,7 +118,7 @@ i386_pe_determine_dllexport_p (tree decl
 /* Return true if DECL should be a dllimport'd object.  */
 
 static bool
-i386_pe_determine_dllimport_p (tree decl)
+arm_pe_determine_dllimport_p (tree decl)
 {
   tree assoc;
 
@@ -139,109 +136,32 @@ i386_pe_determine_dllimport_p (tree decl
  out-of-class d

Re: Slight tree reorganization for cygming platforms

[Dave Korn]

Pedro Alves wrote:

> How would people prefer something like this going forward?  Start with
> extracting common stuff into config/, while making sure e.g, at least
> one of mingw or cygwin still bootstraps/tests OK; or, start by
> updating config/arm/ with copies of what's under config/i386/, and once
> that is in, work on extracting/abstracting common stuff out?

  I think it would be better to do the commoning out first, having cygwin and
mingw to test that it's correct with, and then extend the arm stuff to make
use of it; it save what would be the otherwise redundant effort of adding a
bunch of files only to take them away again.

> Vincent pointed out the obvious abuses that are 100% reusable, but,
> I'd like to reuse e.g., config/i386/winnt.c, config/i386/winnt-cxx.c,
> config/i386/winnt-stubs.c for ARM as well.  E.g, currently, I've copied
> config/i386/winnt.c over the current config/arm/pe.c (completelly replacing
> it), and adjusted it a bit to make it work for ARM.  As you can see from
> the hunk below, the main juice is shareable here (there's no fastcall
> on ARM WinCE):

  I see in general no limits on what we should common out, anything that is
truly target-independent and can be useful elsewhere is fair game.  I suggest
that on doing so we rename files and functions to use a "pe-" or "pe_" prefix,
replacing any current "ix86_" or "arm_" or whatever else.

cheers,
  DaveK

Re: What version of Boehm for --enable-objc-gc ?

[Andrew Haley]

Fabrice Feray wrote:

> What version of Boehm's gc is best fit for the objc runtime? It seems
> that the one that comes with gcc is a special version meant for java. Am
> I wrong?

It's not substantially customized for Java, although it has some hooks that
make it work better on Java.  I don't think there's any reason not to use
it for Objc.

Maybe someone on the GC Mailing List has more info, but I think that's right.

Andrew.

Re: What version of Boehm for --enable-objc-gc ?

[Andrew Pinski]

On Fri, Apr 24, 2009 at 7:20 AM, Andrew Haley  wrote:
> Fabrice Feray wrote:
>
>> What version of Boehm's gc is best fit for the objc runtime? It seems
>> that the one that comes with gcc is a special version meant for java. Am
>> I wrong?
>
> It's not substantially customized for Java, although it has some hooks that
> make it work better on Java.  I don't think there's any reason not to use
> it for Objc.
>
> Maybe someone on the GC Mailing List has more info, but I think that's right.


in fact recent versions of gcc, turn on the in tree version for use
with libobjc also.

--Pinski

Re: -O3 and new optimizations in 4.4.0

[Robert Dewar]

Sebastian Pop wrote:

On Fri, Apr 24, 2009 at 08:12, Robert Dewar  wrote:

What would we have to do to make PPL and CLooG required to build GCC?

Why would that be desirable? Seems to me the current situation is
clearly preferable.


To enable loop transforms in -O3.


To me, you would have to show very clearly a significant performance
gain for typical applications to justify the impact of adding
PPL and CLooG. I don't see it. If you want these transformations
you can get them, why go to all this disruptive effort for the
default optimization case?

[[webmaster] New contact address for ftp.fu-berlin.de]

[Christopher Faylor]

- Forwarded message from Holger Weiss  
-

Hello,

ftp.fu-berlin.de is listed as a mirror of the gcc.gnu.org FTP site on
 with Felix von Leitner's e-mail
address.  As Felix is no longer a contact for our site, could you please
replace his address with ?

Thank you, Holger


- End forwarded message -

Re: testsuite fixes for small doubles

[DJ Delorie]

The fp-int-convert-long-double test does this:

  static volatile signed long long ivin, ivout;
  static volatile long double fv1, fv2;
  ivin = ((signed long long) (((unsigned long long) ~(unsigned long long) 0) >> 
1));
  fv1 =  ((signed long long) (((unsigned long long) ~(unsigned long long) 0) >> 
1));
  fv2 = ivin;
  ivout = fv2;

When sizeof(long double) <= sizeof(long long), it cannot store that
~0 value in a long double.

Re: gcc-4.4.0.tar.gz.sig, expired key

[Keith Thompson]

On Fri, Apr 24, 2009 at 12:31:43PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 23, 2009 at 08:09:55PM -0700, Keith Thompson wrote:
> > gcc-4.4.0.tar.gz.sig was generated with an expired key:
> > 
> > gpg: Signature made Tue 21 Apr 2009 07:35:29 AM PDT using DSA key ID 
> > C3C45C06
> > gpg: Good signature from "Jakub Jelinek "
> > gpg: Note: This key has expired!
> > Primary key fingerprint: 33C2 35A3 4C46 AA3F FB29  3709 A328 C3A2 C3C4 5C06
> > 
> > I'm using ftp://ftp.gnu.org/gnu/gnu-keyring.gpg, downloaded after I
> > downloaded gcc-4.4.0.tar.gz.sig.
> 
> I've extended its expiration before the release.  Just
> gpg --keyserver hkp://pgp.mit.edu/ --recv-keys C3C45C06

Ok.

Rather than importing all those signatures from a keyserver, I
always check signatures for GNU software against a downloaded copy
of gnu-keyring.gpg.  Presumably gnu-keyring.gpg will be updated Real
Soon Now, so there should be no problem.

-- 
Keith Thompson (The_Other_Keith) k...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Emit jump insn in function prologue

[Ian Lance Taylor]

Peter Leist  writes:

> can I use emit_cmp_and_jump_insns while creating the function 
> prologue/epilogue?
> If I try, I always get an error at runtime
>
> func.c:33: internal compiler error: in make_edges, at cfgbuild.c:354
>
> I think this is because the jump doesn't get an JUMP_LABEL associated to it.
> Is there an other way at this pass to add loops to the code?

Using a general function like emit_cmp_and_jump_insns when generating
the prologue is somewhat risky, because emit_cmp_and_jump_insns expects
to be run before reload.  It freely calls functions like force_reg and
gen_reg_rtx which may not be used before reload.

In the function prologue you should know precisely which insns you want
to emit.  It will be safer in general to use emit_insn (gen_XXX ())
rather than to call a general routine.

I don't know of any existing cases where the prologue needs a jump, but
it should be easy enough to emit a jump insn and set JUMP_LABEL
yourself.

Ian

Re: testsuite fixes for small doubles

[Joseph S. Myers]

On Fri, 24 Apr 2009, DJ Delorie wrote:

> The fp-int-convert-long-double test does this:
> 
>   static volatile signed long long ivin, ivout;
>   static volatile long double fv1, fv2;
>   ivin = ((signed long long) (((unsigned long long) ~(unsigned long long) 0) 
> >> 1));
>   fv1 =  ((signed long long) (((unsigned long long) ~(unsigned long long) 0) 
> >> 1));
>   fv2 = ivin;
>   ivout = fv2;
> 
> When sizeof(long double) <= sizeof(long long), it cannot store that
> ~0 value in a long double.

But it doesn't need to store it *exactly*; it only tests that the 
conversion reverses if PREC_OK (argument to TEST_I_F_VAL) is true, and 
TEST_I_F sets PREC_OK to what should be an appropriate value (based on the 
types involved, LDBL_MANT_DIG, etc.) in each case.  The other tests are 
applicable even when the conversion is inexact (and even if it overflows 
to infinity): the compile-time conversions should agree with the runtime 
ones since the results of converting integers to floating-point are 
well-defined by IEEE.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: testsuite fixes for small doubles

[DJ Delorie]

> But it doesn't need to store it *exactly*; it only tests that the 
> conversion reverses if PREC_OK (argument to TEST_I_F_VAL) is true, and 
> TEST_I_F sets PREC_OK to what should be an appropriate value (based on the 
> types involved, LDBL_MANT_DIG, etc.) in each case.  The other tests are 
> applicable even when the conversion is inexact (and even if it overflows 
> to infinity): the compile-time conversions should agree with the runtime 
> ones since the results of converting integers to floating-point are 
> well-defined by IEEE.

Hmmm... in that case, the test is just failing, so I guess I'll debug
it some more.

Re: Emit jump insn in function prologue

[Jan Hubicka]

> Peter Leist  writes:
> 
> > can I use emit_cmp_and_jump_insns while creating the function 
> > prologue/epilogue?
> > If I try, I always get an error at runtime
> >
> > func.c:33: internal compiler error: in make_edges, at cfgbuild.c:354
> >
> > I think this is because the jump doesn't get an JUMP_LABEL associated to it.
> > Is there an other way at this pass to add loops to the code?
> 
> Using a general function like emit_cmp_and_jump_insns when generating
> the prologue is somewhat risky, because emit_cmp_and_jump_insns expects
> to be run before reload.  It freely calls functions like force_reg and
> gen_reg_rtx which may not be used before reload.
> 
> In the function prologue you should know precisely which insns you want
> to emit.  It will be safer in general to use emit_insn (gen_XXX ())
> rather than to call a general routine.
> 
> I don't know of any existing cases where the prologue needs a jump, but
> it should be easy enough to emit a jump insn and set JUMP_LABEL
> yourself.

x86_64 has jump around saving SSE regs for variadic function prologue.

Honza
> 
> Ian

Re: Emit jump insn in function prologue

[Ian Lance Taylor]

Jan Hubicka  writes:

>> I don't know of any existing cases where the prologue needs a jump, but
>> it should be easy enough to emit a jump insn and set JUMP_LABEL
>> yourself.
>
> x86_64 has jump around saving SSE regs for variadic function prologue.

Doesn't count, because that is done in the TARGET_SETUP_INCOMING_VARARGS
hook which is called before reload.  The interesting case here is
prologue generation done after reload.

Ian

Re: Emit jump insn in function prologue

[Eric Botcazou]

> Doesn't count, because that is done in the TARGET_SETUP_INCOMING_VARARGS
> hook which is called before reload.  The interesting case here is
> prologue generation done after reload.

Alpha emits a loop in the prologue to check the stack as per the Tru64 ABI.

-- 
Eric Botcazou

Re: Emit jump insn in function prologue

[Ian Lance Taylor]

Eric Botcazou  writes:

>> Doesn't count, because that is done in the TARGET_SETUP_INCOMING_VARARGS
>> hook which is called before reload.  The interesting case here is
>> prologue generation done after reload.
>
> Alpha emits a loop in the prologue to check the stack as per the Tru64 ABI.

You're right.  It does it wrapped up a single insn, though, so the jump
is never seen at the RTL level.  The prologue_stack_probe_loop insn does
this:
  operands[2] = gen_label_rtx ();
  (*targetm.asm_out.internal_label) (asm_out_file, "L",
 CODE_LABEL_NUMBER (operands[2]));
  return "stq $31,-8192(%1)\;subq %0,1,%0\;lda %1,-8192(%1)\;bne %0,%l2";

Ian

Re: -O3 and new optimizations in 4.4.0

[Andi Kleen]

Robert Dewar  writes:

> Sebastian Pop wrote:
>> On Fri, Apr 24, 2009 at 08:12, Robert Dewar  wrote:
 What would we have to do to make PPL and CLooG required to build GCC?
>>> Why would that be desirable? Seems to me the current situation is
>>> clearly preferable.
>> To enable loop transforms in -O3.
>
> To me, you would have to show very clearly a significant performance
> gain for typical applications to justify the impact of adding
> PPL and CLooG. I don't see it. If you want these transformations
> you can get them, why go to all this disruptive effort for the
> default optimization case?

I think his point was that they would be only widely used if they
were part of -O3 because likely most users are not willing to 
set individual -f optimization flags.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: -O3 and new optimizations in 4.4.0

[Joe Buck]

On Fri, Apr 24, 2009 at 01:34:37PM -0700, Andi Kleen wrote:
> Robert Dewar  writes:
> 
> > Sebastian Pop wrote:
> >> On Fri, Apr 24, 2009 at 08:12, Robert Dewar  wrote:
>  What would we have to do to make PPL and CLooG required to build GCC?
> >>> Why would that be desirable? Seems to me the current situation is
> >>> clearly preferable.
> >> To enable loop transforms in -O3.
> >
> > To me, you would have to show very clearly a significant performance
> > gain for typical applications to justify the impact of adding
> > PPL and CLooG. I don't see it. If you want these transformations
> > you can get them, why go to all this disruptive effort for the
> > default optimization case?
> 
> I think his point was that they would be only widely used if they
> were part of -O3 because likely most users are not willing to
> set individual -f optimization flags.

Agreed.  It might be a wise idea to include them in -O3 in 4.5,
provided that we are confident by then that they are a consistent win.
At that stage the libraries could be required.

Making CFLAGS=-g1 bigger but more useful

[Frank Ch. Eigler]

Hi -

I'm working on a little patch that extends the data produced for the
little-used (?)  -g1 mode.  Normally, this produces very little DWARF
data (basically just function declaration locus, PC range, and basic
backtrace-enabling data).  Compared to normal -g (== -g2) mode, this
is very small.

It would be desirable to have an additional level in between -g1 and
-g2, one that also emits just enough data to decode ordinary
functions' parameters at the entry point.  No locals or blocks for
what's inside the function, such as data for inlined functions.  Just
enough to generate call-graphy traces.

The attached patch is a stab in the dim, and eyeballing the results
seems to accomplish the goal (as tested by systemtap gaily tracing
function call graphs with parameters), at the cost of enlarging the
debug data.  For a fedoraish linux kernel (vmlinux), I get these
numbers:

  vmlinux size
stripped18299708
old-style -g1   23307848  <--
new   -g1   58265716  <--
  -g2   93232955

The stab-in-the-dim -g1 is ten times bigger than the old -g1, but half
the size of -g2.  I am certain that a "stab-in-the-bright" version
should be smaller, if a wise one treaded upon dwarf2out.c more
gingerly than my stomp of a hack.

The basic question though is whether there is interest here for this
sort of -g1.5 mode.  We could ...

- ignore the value of this enlarged -g1 and forget the idea

- adopt the enlarged definition for -g1 and live with the size penalty

- introduce a new -g1.5 (between DINFO_LEVEL_TERSE and DINFO_LEVEL_NORMAL)
  to select the enlarged definition (syntax suggestions wanted)

Suggestions please?


- FChE


diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 69cdb03..eb2116c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -13437,7 +13437,7 @@ dwarf2out_abstract_function (tree decl)
 
   /* Be sure we've emitted the in-class declaration DIE (if any) first, so
  we don't get confused by DECL_ABSTRACT.  */
-  if (debug_info_level > DINFO_LEVEL_TERSE)
+  if (debug_info_level >= DINFO_LEVEL_TERSE)
 {
   context = decl_class_context (decl);
   if (context)
@@ -13520,7 +13520,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   if (!declaration && !origin && !old_die
   && DECL_CONTEXT (decl) && TYPE_P (DECL_CONTEXT (decl))
   && !class_or_namespace_scope_p (context_die)
-  && debug_info_level > DINFO_LEVEL_TERSE)
+  && debug_info_level >= DINFO_LEVEL_TERSE)
 old_die = force_decl_die (decl);
 
   if (origin != NULL)
@@ -13592,7 +13592,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
add_AT_flag (subr_die, DW_AT_external, 1);
 
   add_name_and_src_coords_attributes (subr_die, decl);
-  if (debug_info_level > DINFO_LEVEL_TERSE)
+  if (debug_info_level >= DINFO_LEVEL_TERSE)
{
  add_prototyped_attribute (subr_die, TREE_TYPE (decl));
  add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
@@ -13740,7 +13740,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   /* In the case where we are describing a mere function declaration, all we
  need to do here (and all we *can* do here) is to describe the *types* of
  its formal parameters.  */
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+  if (debug_info_level < DINFO_LEVEL_TERSE)
 ;
   else if (declaration)
 gen_formal_types_die (decl, subr_die);

Re: testsuite fixes for small doubles

[DJ Delorie]

> The fp-int-convert tests are meant to be correct independent of the sizes 
> involved, so this change is inappropriate and may point to a bug 
> elsewhere.

It did, I fixed it.  Thanks for the insight.