Option to print word size, alignment on the target platform

[Igor Bukanov]

Is there any option to ask GCC to print various size and alignment
info on the target platform?  This would be very nice during cross
compilation when one can not run the executables to autoconfigure for
such parameters.

Currently I consider for that a hack like copiling the following source:

#include 
union aligned_fields {
double d;
void (*f)();
...
};

struct align_test {
union aligned_fields u1;
char c;
};

const char DATA_POINTER_SIZE[sizeof(void *)];
const char FUNCTION_POINTER_SIZE[sizeof(void (*)())];
const char UNIVERSAL_ALIGN[offsetof(struct align_test, c)];
const char SHORT_SIZE[sizeof(short)];

and then running "nm --print-size" from binutils for the target on it to get:
0004 0004 C DATA_POINTER_SIZE
0004 0004 C FUNCTION_POINTER_SIZE
0002 0002 C SHORT_SIZE
0008 0008 C UNIVERSAL_ALIGN

But I doubt that this is reliable. So perhaps there is something like
gcc -print-target-info ?

cp/do_poplevel

[Marcin Dalecki]

The following:

2006-01-23  Volker Reichelt  <[EMAIL PROTECTED]>

* cp-tree.h (do_poplevel): Remove prototype.
* semantics.c (do_poplevel): Add prototype.  Make static.


Is a plain mistake due to:

../.././gcc/objcp/objcp-decl.c: In function 'tree_node*  
objcp_end_compound_stmt(tree_node*, int)':
../.././gcc/objcp/objcp-decl.c:114: error: 'do_poplevel' was not  
declared in this scope
../.././gcc/objcp/objcp-decl.c:118: error: 'do_poplevel' was not  
declared in this scope

Re: cp/default_conversion

[Marcin Dalecki]

The following removal of global default_conversion inside the C++  
frontend:


2006-01-25  Volker Reichelt  <[EMAIL PROTECTED]>

(default_conversion): Likewise.

Is junk due to the fact that it gets used for example in rs6000/rs6000.c
The results in *actual* build failure on Darwin/PowerPC.

Re: Patch: Boehm GC 6.6 merge

[Andrew Haley]

Ranjit Mathew writes:
 > -BEGIN PGP SIGNED MESSAGE-
 > Hash: SHA1
 > 
 > Bryce McKinlay wrote:
 > > This patch merges the GC 6.6 sources into the libgcj trunk. Two patches 
 > [...]
 > 
 > This little bit in "boehm-gc/include/private/gcconfig.h" (line 306):
 > - - 8< -
 > > +# else
 > > +#if defined(__i386__)
 > > +#  define I386
 > >   --> Not really supported, but at least we recognize it.
 > > +#endif
 > - - 8< -
 > causes a bootstrap failure for me on i686-pc-linux-gnu.
 > Note that the "Not really" bit is not inside a comment.

The differences between our gcconfig.h and the stock Boehm 6.6 version
are hard for me to understand.  Bryce, what are the reasons for them?
I understand why we want to define USE_MMAP for Linux, but the rest
look spurious.

Andrew.


--- /home/aph/gcconfig.h2006-01-25 10:28:06.0 +
+++ include/private/gcconfig.h  2006-01-25 10:07:56.0 +
@@ -131,9 +131,6 @@
 #   endif
 #  endif
 #endif /* !LINUX */
-#if defined(__NetBSD__) && defined(__MIPSEL__)
-#  undef ULTRIX
-#endif
 #define mach_type_known
 # endif
 # if defined(DGUX) && (defined(i386) || defined(__i386__))
@@ -297,15 +294,17 @@
 #   define MACOS
 #   define mach_type_known
 # endif
-# if defined(macosx) || (defined(__APPLE__) && defined(__MACH__))
-#   define DARWIN
-#   if defined(__ppc__)  || defined(__ppc64__)
+# if defined(macosx) \
+ || defined(__APPLE__) && defined(__MACH__) && defined(__ppc__) \
+ || defined(__APPLE__) && defined(__MACH__) && defined(__ppc64__)
+#define DARWIN
 #define POWERPC
 #define mach_type_known
-#   elif defined(__i386__)
-#define I386
+# else
+#if defined(__i386__)
+#  define I386
  --> Not really supported, but at least we recognize it.
-#   endif
+#endif
 # endif
 # if defined(NeXT) && defined(mc68000)
 #   define M68K
@@ -667,7 +666,8 @@
 #   define OS_TYPE "LINUX"
 #   define STACKBOTTOM ((ptr_t)0xf000)
 #   define USE_GENERIC_PUSH_REGS
-   /* We never got around to the assembly version. */
+#   define USE_MMAP
+ /* We never got around to the assembly version. */
 /* #   define MPROTECT_VDB - Reported to not work  9/17/01 */
 #   ifdef __ELF__
 #define DYNAMIC_LOADING
@@ -1406,8 +1406,8 @@
 #   define DATAEND /* not needed */
 #   endif
 #   if defined(NETBSD)
-# define ALIGNMENT 4
 # define OS_TYPE "NETBSD"
+# define ALIGNMENT 4
 # define HEURISTIC2
 # define USE_GENERIC_PUSH_REGS
 # ifdef __ELF__
@@ -1587,7 +1587,7 @@
/* the text segment immediately follows the stack.  */
/* Hence we give an upper pound.*/
/* This is currently unused, since we disabled HEURISTIC2   */
-   extern int __start[];
+   extern int __start[];
 #  define HEURISTIC2_LIMIT ((ptr_t)((word)(__start) & ~(getpagesize()-1)))
 #  ifndef GC_OSF1_THREADS
  /* Unresolved signal issues with threads. */

Re: /gcc/testsuite disappears when recompiling

[Paolo Bonzini]

I tried 'make all-stage1 STAGE1_LANGUAGES=c++,fortran'.  Not only that
didn't work, it wiped the directory /gcc/testsuite.


I believe it was only relocated in stage3-gcc/testsuite.

Right now to change the STAGE1_LANGUAGES, you have to remove the 
stage1-gcc directory.  I have a patch to fix this; I'm not sure that the 
slush is the best time to submit it though.


Paolo

/gcc/testsuite disappears when recompiling

[Diego Novillo]

I've asked about this recently, but I still cannot do what I used to do
before the toplevel bootstrap changes.

The scenario is this: I just finished bootstrapping the compiler and
found that there are new C++ and Fortran failures in the testsuite.  So,
I go into  and want to rebuild f951 and cc1plus with the host
compiler and '-g -O0'.

I tried 'make all-stage1 STAGE1_LANGUAGES=c++,fortran'.  Not only that
didn't work, it wiped the directory /gcc/testsuite.

Is it possible to make /gcc/testsuite more resilient to things like
this?  I only want to make it disappear if I do 'make clean'.


Thanks.

Re: /gcc/testsuite disappears when recompiling

[Diego Novillo]

Paolo Bonzini wrote:
> I believe it was only relocated in stage3-gcc/testsuite.
Huh.  Any reason in particular?  Why not leave it in /gcc?
> Right now to change the STAGE1_LANGUAGES, you have to remove the
> stage1-gcc directory.  I have a patch to fix this; I'm not sure that
> the slush is the best time to submit it though.
So, the new patch will let me do 'make all-stage1
STAGE1_LANGUAGES=c++,fortran'?  Would it be possible to have a shortcut
for this?  Something that would recompile all the languages I originally
specified in --enable-languages with -g -O0.


Thanks.

Re: /gcc/testsuite disappears when recompiling

[Paolo Bonzini]

Diego Novillo wrote:


Paolo Bonzini wrote:
 


I believe it was only relocated in stage3-gcc/testsuite.
   


Huh.  Any reason in particular?  Why not leave it in /gcc?
 

Because all the gcc directory has been relocated in stage3-gcc.  It 
allows you for example to run the testsuite for stage2 and then to 
compare stage2 and stage3 results, for example.



Right now to change the STAGE1_LANGUAGES, you have to remove the
stage1-gcc directory.  I have a patch to fix this; I'm not sure that
the slush is the best time to submit it though.
   


So, the new patch will let me do 'make all-stage1
STAGE1_LANGUAGES=c++,fortran'?

No, it will allow you to do "make cc1plus" or "make f951" within the 
build directory for the stage1 compiler, even if the stage1 compiler 
does not have C++ and Fortran 95 enabled.


See http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00404.html (most of the 
patch will be the same).


Paolo

Porting problem from GCC-4.0 to GCC 4.1

[Shrirang Khishti]

Hi all
   I have ported GCC-4.0 for a new target. Initially I started porting
with GCC-3.4 and then shifted to GCC-4.0 without any problems. Now I
want to port same code for GCC-4.1 . As there are some structural
differences in GCC-4.0 and gcc-4.1 back-ends specially regarding
addition of .opt file. I have removed all the macros related to
TARGET_SWITCHES and made appropriate entries in .opt file. With this and
some other changes I build cc1. I have also updated TARGET_DEFAULT macro
in target.h file.  But problem that I found is that if I don't specify
any target specific option target_flags are remaining zero. They are not
getting set as expected for DEFAULT_TARGET and so it is giving me ICE.
   If I explicitly give target specific option which is on DEFAULT, then
I am not having any problems.
   Anything is missing from my side? 
Any help will be appreciated

Thanking in advance
Regards

Shrirang Khisti 
KPIT Cummins Infosystems Ltd. 

Re: /gcc/testsuite disappears when recompiling

[Diego Novillo]

Paolo Bonzini wrote:
> Because all the gcc directory has been relocated in stage3-gcc.  It
> allows you for example to run the testsuite for stage2 and then to
> compare stage2 and stage3 results, for example.
>
Ah, OK.

> No, it will allow you to do "make cc1plus" or "make f951" within the
> build directory for the stage1 compiler, even if the stage1 compiler
> does not have C++ and Fortran 95 enabled.
>
Even better.  Thanks!

So, I would just need to move /gcc/testsuite into /stage1-gcc?

Re: /gcc/testsuite disappears when recompiling

[Paolo Bonzini]

So, I would just need to move /gcc/testsuite into /stage1-gcc?
 

I suppose.  I don't understand why can't you just look in 
stage3-gcc/testsuite, but I guess you know what you're doing. :-)


Also note that with my patch you could do make check-fortran: all the 
targets for the disabled languages are not invoked by default, but present.


Paolo

Re: /gcc/testsuite disappears when recompiling

[Diego Novillo]

Paolo Bonzini wrote:
> I suppose.  I don't understand why can't you just look in
> stage3-gcc/testsuite, but I guess you know what you're doing. :-)
>
Hmm, now that I think about it again.  The log contains command lines
that use the compiler built in /gcc.  Something like
/gcc/testsuite/gfortran/../../gfortran, right?

If I had to rebuild the stage1 binaries inside /stage1-gcc, it
seems to me that I won't be able to cut and paste from gfortran.log
anymore.  I will have to modify all the paths to /stage1-gcc?

Re: /gcc/testsuite disappears when recompiling

[Daniel Jacobowitz]

On Wed, Jan 25, 2006 at 09:06:06AM -0500, Diego Novillo wrote:
> Paolo Bonzini wrote:
> > I suppose.  I don't understand why can't you just look in
> > stage3-gcc/testsuite, but I guess you know what you're doing. :-)
> >
> Hmm, now that I think about it again.  The log contains command lines
> that use the compiler built in /gcc.  Something like
> /gcc/testsuite/gfortran/../../gfortran, right?
> 
> If I had to rebuild the stage1 binaries inside /stage1-gcc, it
> seems to me that I won't be able to cut and paste from gfortran.log
> anymore.  I will have to modify all the paths to /stage1-gcc?

If you run all-stage1, or stage1-start, then the top level will put the
stage1 gcc directory back into place.

There's a separate gcc subdirectory for every stage; the "current"
stage will be named "gcc", and all the others will be named
"stageFOO-gcc".

-- 
Daniel Jacobowitz
CodeSourcery

Re: cp/do_poplevel

[Volker Reichelt]

On 25 Jan, Marcin Dalecki wrote:
> The following:
> 
> 2006-01-23  Volker Reichelt  <[EMAIL PROTECTED]>
> 
>   * cp-tree.h (do_poplevel): Remove prototype.
>   * semantics.c (do_poplevel): Add prototype.  Make static.
> 
> 
> Is a plain mistake due to:
> 
> ../.././gcc/objcp/objcp-decl.c: In function 'tree_node*  
> objcp_end_compound_stmt(tree_node*, int)':
> ../.././gcc/objcp/objcp-decl.c:114: error: 'do_poplevel' was not  
> declared in this scope
> ../.././gcc/objcp/objcp-decl.c:118: error: 'do_poplevel' was not  
> declared in this scope

Since Objective-C++ isn't built by default I didn't see that.
I just reverted the patch, see
  http://gcc.gnu.org/ml/gcc-cvs/2006-01/msg01012.html
Sorry for the inconvenience!

Regards,
Volker

Re: cp/default_conversion

[Volker Reichelt]

On 25 Jan, Marcin Dalecki wrote:
> The following removal of global default_conversion inside the C++  
> frontend:
> 
> 2006-01-25  Volker Reichelt  <[EMAIL PROTECTED]>
> 
>   (default_conversion): Likewise.
> 
> Is junk due to the fact that it gets used for example in rs6000/rs6000.c
> The results in *actual* build failure on Darwin/PowerPC.

I reverted the patch to cure the bootstrap-failure, but there are
some things that make me wonder:

The function default_conversion is used in rs6000/rs6000-c.c.
The first line of the file reads:

  /* Subroutines for the C front end on the POWER and PowerPC architectures.

The file doesn't include cp-tree.h, but only c-tree.h.
But nevertheless the function default_conversion from the C++ frontend
is linked and not the one from the C frontend.

Is that intentional or a bug?
Do we need a langhook to get the right function?

Regards,
Volker

Re: cp/default_conversion

[Andrew Pinski]

> 
> On 25 Jan, Marcin Dalecki wrote:
> > The following removal of global default_conversion inside the C++  
> > frontend:
> > 
> > 2006-01-25  Volker Reichelt  <[EMAIL PROTECTED]>
> > 
> > (default_conversion): Likewise.
> > 
> > Is junk due to the fact that it gets used for example in rs6000/rs6000.c
> > The results in *actual* build failure on Darwin/PowerPC.
> 
> I reverted the patch to cure the bootstrap-failure, but there are
> some things that make me wonder:
> 
> The function default_conversion is used in rs6000/rs6000-c.c.
> The first line of the file reads:
> 
>   /* Subroutines for the C front end on the POWER and PowerPC architectures.
> 
> The file doesn't include cp-tree.h, but only c-tree.h.
> But nevertheless the function default_conversion from the C++ frontend
> is linked and not the one from the C frontend.
> 
> Is that intentional or a bug?
> Do we need a langhook to get the right function?

This is intentional, this function is called between the two front-ends.
Maybe this function prototype should be moved over to c-common.h like
the other common functions.

Thanks,
Andrew Pinski

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Zack Weinberg]

On Tue, Jan 24, 2006 at 11:55:32PM -0500, Kaveh R. Ghazi wrote:
> Okay, now I get:
[...]
>"build/gencondmd.c", line 60: incomplete struct/union/enum c_test: 
> insn_conditions
>"build/gencondmd.c", line 1952: warning: syntax error:  empty initializer
>"build/gencondmd.c", line 1952: cannot recover from previous errors
>cc: acomp failed for build/gencondmd.c
>make[3]: *** [build/gencondmd.o] Error 2

On Wed, Jan 25, 2006 at 02:04:04PM +0100, Andreas Krebbel wrote:
> the insn-conditions.md file doesn't preserve escaping of
> characters. So in the s390.md example
> "CONST_OK_FOR_CONSTRAINT_P (INTVAL (operands[2]), 'K', \"K\")"
> becomes
> "CONST_OK_FOR_CONSTRAINT_P (INTVAL (operands[2]), 'K', "K")"
> which a syntax error for the gen... tools.

The appended patch (superseding the earlier one, Kaveh) should fix
both these issues.  I have to run off to school and won't be able
to do anything more till this evening, but please let me know how
it goes.

zw

==
--- genconditions.c (revision 110242)
+++ genconditions.c (local)
@@ -52,9 +52,14 @@ write_header (void)
machine description file.  */\n\
 \n\
 #include \"bconfig.h\"\n\
-#include \"insn-constants.h\"\n");
+#include \"system.h\"\n");
 
   puts ("\
+/* It is necessary, but not entirely safe, to include the headers below\n\
+   in a generator program.  As a defensive measure, don't do so when the\n\
+   table isn't going to have anything in it.  */\n\
+#if GCC_VERSION >= 3001\n\
+\n\
 /* Do not allow checking to confuse the issue.  */\n\
 #undef ENABLE_CHECKING\n\
 #undef ENABLE_TREE_CHECKING\n\
@@ -64,9 +69,9 @@ write_header (void)
 #undef ENABLE_GC_ALWAYS_COLLECT\n");
 
   puts ("\
-#include \"system.h\"\n\
 #include \"coretypes.h\"\n\
 #include \"tm.h\"\n\
+#include \"insn-constants.h\"\n\
 #include \"rtl.h\"\n\
 #include \"tm_p.h\"\n\
 #include \"function.h\"\n");
@@ -86,8 +91,7 @@ write_header (void)
 #include \"hard-reg-set.h\"\n\
 #include \"resource.h\"\n\
 #include \"toplev.h\"\n\
-#include \"reload.h\"\n\
-#include \"gensupport.h\"\n");
+#include \"reload.h\"\n");
 
   if (saw_eh_return)
 puts ("#define HAVE_eh_return 1");
@@ -97,7 +101,9 @@ write_header (void)
 /* Dummy external declarations.  */\n\
 extern rtx insn;\n\
 extern rtx ins1;\n\
-extern rtx operands[];\n");
+extern rtx operands[];\n\
+\n\
+#endif /* gcc >= 3.0.1 */\n");
 }
 
 /* Write out one entry in the conditions table, using the data pointed
@@ -118,12 +124,14 @@ write_one_condition (void **slot, void *
   fputs ("  { \"", stdout);
   for (p = test->expr; *p; p++)
 {
-  if (*p == '\n')
-   fputs ("\\n\\\n", stdout);
-  else if (*p == '"')
-   fputs ("\\\"", stdout);
-  else
-   putchar (*p);
+  switch (*p)
+   {
+   case '\n': fputs ("\\n\\", stdout); break;
+   case '\\':
+   case '\"': putchar ('\\'); break;
+   default: break;
+   }
+  putchar (*p);
 }
 
   printf ("\",\n__builtin_constant_p ");
@@ -140,20 +148,29 @@ static void
 write_conditions (void)
 {
   puts ("\
+/* Structure definition duplicated from gensupport.h rather than\n\
+   drag in that file and its dependencies.  */\n\
+struct c_test\n\
+{\n\
+  const char *expr;\n\
+  int value;\n\
+};\n");
+
+  puts ("\
 /* This table lists each condition found in the machine description.\n\
Each condition is mapped to its truth value (0 or 1), or -1 if that\n\
-   cannot be calculated at compile time. */\n\
-\n\
-static const struct c_test insn_conditions[] = {\n \
-/* If we don't have __builtin_constant_p, or it's not acceptable in array\n\
+   cannot be calculated at compile time.\n\
+   If we don't have __builtin_constant_p, or it's not acceptable in array\n\
initializers, fall back to assuming that all conditions potentially\n\
vary at run time.  It works in 3.0.1 and later; 3.0 only when not\n\
optimizing.  */\n\
-#if GCC_VERSION >= 3001");
+\n\
+static const struct c_test insn_conditions[] = {\n\
+#if GCC_VERSION >= 3001\n");
 
   traverse_c_tests (write_one_condition, 0);
 
-  puts ("#endif\n};\n");
+  puts ("\n#endif /* gcc >= 3.0.1 */\n};\n");
 }
 
 /* Emit code which will convert the C-format table to a
@@ -163,16 +180,31 @@ static const struct c_test insn_conditio
 static void
 write_writer (void)
 {
-  puts ("int\nmain(void)\n{\n\
-  unsigned int i;\n\
-\n\
-  puts (\"(define_conditions [\");\n\
-  for (i = 0; i < ARRAY_SIZE (insn_conditions); i++)\n\
-printf (\"  (%d \\\"%s\\\")\\n\",\n\
-   insn_conditions[i].value, insn_conditions[i].expr);\n\
-  puts (\"])\");\n\
-  fflush (stdout);\n\
-  return (ferror (stdout) != 0 ? FATAL_EXIT_CODE : SUCCESS_EXIT_CODE);\n}");
+  puts ("int\n"
+   "main(void)\n"
+   "{\n"
+   "  unsigned int i;\n"
+"  const char *p;\n"
+"  puts (\"(define_conditions [\");\n"
+   "  for (i = 0; i < ARRAY_SIZE (insn_conditions); i++)\n"
+   "{\

Re: Option to print word size, alignment on the target platform

[Paul Brook]

On Wednesday 25 January 2006 10:20, Igor Bukanov wrote:
> Is there any option to ask GCC to print various size and alignment
> info on the target platform?  This would be very nice during cross
> compilation when one can not run the executables to autoconfigure for
> such parameters.
>
> Currently I consider for that a hack like copiling the following source:
>
> #include 
> union aligned_fields {
> double d;
> void (*f)();
> ...
> };
>
> struct align_test {
> union aligned_fields u1;
> char c;
> };

Autoconf already has tests for things like this. Something along the lines of:

const char D_P_S_4[sizeof(void *) == 4 : -1 : 1];
const char D_P_S_8[sizeof(void *) == 8 : -1 : 1];

Then see which compiles, or grep the error messages.

Paul

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John David Anglin schrieb:
>> Perhaps I have to be more precise. Bootstrapping ada failed!
> 
> That's not enough!   In order for someone else to duplicate the failure
> and investigate the problem, you need to provide the log of what happened,
> your configure command, etc.  For example, I would have never guessed that
> you were using "-mpa-risc-2-0".  See http://gcc.gnu.org/bugs.html.
> 
> Dave

Ok, I did a bootstrap and testsuite run without passing -mpa-risc-2-0 to the
boostrap compiler. Testresults including configure options and environment at

http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01297.html

the only acats test that failed: c52103x

That's really good.

I will try current 4.0 end of the week.


A few words to the -mpa-risc-2-0 switch:

As the documentation says, there are two different target for hppa*-hp-hpux11*:

The `hppa[1-2]*-hp-hpux11*' target generates code for the 32-bit PA-RISC runtime
architecture and uses the HP linker.
The `hppa64-hp-hpux11*' target generates 64-bit code for the PA-RISC 2.0
architecture.

For the target `hppa[1-2]*-hp-hpux11*' gcc --target-help says:

- -mpa-risc-2-0 Generate PA2.0 code (requires binutils 2.10 or 
later)
- -mpa-risc-1-1 Generate PA1.1 code
- -mpa-risc-1-0 Generate PA1.0 code

which produces executables as follows for example:

file gcc
gcc:  PA-RISC1.1 shared executable dynamically linked -not stripped

or

file gcc
gcc: PA-RISC2.0 shared executable dynamically linked -not stripped

these are 32bit.

For the target `hppa64-hp-hpux11*' it's completly different:

file gcc
gcc:   ELF-64 executable object file - PA-RISC 2.0 (LP64)
this is 64bit.


So what I see, the `hppa64-hp-hpux11*' target implies PA-RISC 2.0 architecture.
But I think it's not true the other way. The `hppa[1-2]*-hp-hpux11*' target does
not imply 64bit.

curios enough gcc build for target `hppa64-hp-hpux11*' has the same output for
- --target-help

- -mpa-risc-2-0 Generate PA2.0 code (requires binutils 2.10 or 
later)
- -mpa-risc-1-1 Generate PA1.1 code
- -mpa-risc-1-0 Generate PA1.0 code


So, what I did in the past:

I set CC="gcc -mpa-risc-2-0".
This forces gcc and all drivers to be built for PA-RISC2.0.
Runtime libraries are built for PA-RISC1.1, because gcc defaults to build
PA-RISC1.1 code for target hppa2.0w-hp-hpux11.00, that's also curios.
This works for all languages except ada, as you can see at
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00897.html


Perhaps somebody may enlight me, if I'm wrong.

Rainer

- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD16Zs3s6elE6CYeURAoYoAKDemWfq7KMjc2JaJk2b3lPC4rAYUwCgk7VM
6x7who5BqwJaoTxfDnx3d40=
=8Zoh
-END PGP SIGNATURE-

Re: Option to print word size, alignment on the target platform

[Igor Bukanov]

On 1/25/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> Autoconf already has tests for things like this. Something along the lines of:
>
> const char D_P_S_4[sizeof(void *) == 4 : -1 : 1];
> const char D_P_S_8[sizeof(void *) == 8 : -1 : 1];
>
> Then see which compiles, or grep the error messages.

Right, but are there any way to learn about endianess of the paltform
or the direction of stack growth just from knowing that program
compiles or not? GCC nows about this and it would be nice if there is
a way to expose these.

Regards, Igor

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[Eric Botcazou]

> Ok, I did a bootstrap and testsuite run without passing -mpa-risc-2-0 to
> the boostrap compiler. Testresults including configure options and
> environment at
>
> http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01297.html
>
> the only acats test that failed: c52103x

Expected failure on all platforms (PR ada/20548).

Thanks for testing the Ada compiler!

-- 
Eric Botcazou

Re: RTL alias analysis

[Alexandre Oliva]

On Jan 22, 2006, Richard Guenther <[EMAIL PROTECTED]> wrote:

> On 1/22/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> I don't think it is any different.  GCC's exception for unions only
>> applies if the object is accessed using the union type.  So they are
>> indeed equivalent.  The scary thing is that I don't think they
>> actually violate the ISO C strict aliasing rules, but they might still
>> be mis-optimized by GCC, assuming I understand correctly what GCC
>> does.

> ISO C says that the following violates aliasing rules:

> int foo(float f) { union { int i; float f; } u; i.f = f; return i.i; }

Yes, but this was not what the example I quoted from Richard Sandiford
was about.  The example only accessed a memory region using its
effective type:

> int ii; double dd; void foo (int *ip, double *dp) {
>   *ip = 15; ii = *ip; *dp = 1.5; dd = *dp; }
> void test (void) { union { int i; double d; } u;
>   foo (&u.i, &u.d); }

So it is perfectly valid, but if GCC reorders the read from *ip past
the store to *dp, it turns the valid program into one that misbehaves.

Unless the undefined behavior is taking the address of both u.i and
u.d, when only one of them is well-defined at that point.  I don't
think taking the address of a member of a union counts as accessing
the stored value of the object, since if the member is volatile, a
read from memory is not expected.

> The correct solution for converting
> a float to an integer (bit-representation) as in the expample is to use
> two different memory locations and memcpy (which avoids aliasing
> issues by means of using the special rules for access through 'char').

It does avoid aliasing issues, but it does not avoid the propagation
of the effective type (see 6.5/6), so accessing the result of the copy
using a different type still invokes undefined behavior.  It's just
that current compilers don't take advantage of this fact.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Kaveh R. Ghazi]

 > The appended patch (superseding the earlier one, Kaveh) should fix
 > both these issues.  I have to run off to school and won't be able to
 > do anything more till this evening, but please let me know how it
 > goes.
 > zw

Zack - using your latest genconditions.c patch plus this one:
http://gcc.gnu.org/ml/gcc/2006-01/msg00951.html
was sufficient to get a C-only bootstrap working on solaris2.10 using
cc for stage1.

I'm going to run a full test, but that'll take many many hours
longer.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Option to print word size, alignment on the target platform

[Robert Dewar]

Igor Bukanov wrote:

On 1/25/06, Paul Brook <[EMAIL PROTECTED]> wrote:


Autoconf already has tests for things like this. Something along the lines of:

const char D_P_S_4[sizeof(void *) == 4 : -1 : 1];
const char D_P_S_8[sizeof(void *) == 8 : -1 : 1];

Then see which compiles, or grep the error messages.



Right, but are there any way to learn about endianess of the paltform
or the direction of stack growth just from knowing that program
compiles or not? GCC nows about this and it would be nice if there is
a way to expose these.


A convenient way to get the endianness is to use
the System.Bit_Order attribute in Ada. Here is
a little function you can use in your program,
easily called from C

   function is_little_endian return int;
   pragma Export (C, is_little_endian);
   -- returns 1 if LE, 0 if BE

   with System; use System;
   function is_little_endian return int is
   begin
  return Boolean'Pos (Default_Bit_Order = Low_Order_First);
   end;

or, if you don't mind being GNAT specific

   function is_little_endian return int is
   begin
  return Standard'Default_Bit_Order;
   end;

It would be nice to have this query more directly
available in C (perhaps there is a way, but I don't
know it, of course you can rig up some trick code
that tests it).



Regards, Igor

Program konferencji dla gcc@gcc.gnu.org

[Program konferencji]

Program konferencji: http://210.1.7.185/lvov.html  11-12 lutego 2006 r. 
Ukraina, Lwow, Hotel "Sputnik"

Program konferencji dla [EMAIL PROTECTED]

[Program konferencji]

Program konferencji: http://210.1.7.185/lvov.html  11-12 lutego 2006 r. 
Ukraina, Lwow, Hotel "Sputnik"

Re: Option to print word size, alignment on the target platform

[Igor Bukanov]

On 1/25/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
> A convenient way to get the endianness is to use
> the System.Bit_Order attribute in Ada.

But this requires to run the program on the target which is not
possible with a cross-compiler. Or is there a trick to declare
something in Ada that would force the program to miscompile depending
on the target endianness?

Regards, Igor

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[John David Anglin]

> Ok, I did a bootstrap and testsuite run without passing -mpa-risc-2-0 to the
> boostrap compiler. Testresults including configure options and environment at
> 
> http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01297.html
> 
> the only acats test that failed: c52103x

Your results are better than mine.  I suspect that "--disable-shared"
versus "--enable-shared" is the difference.  There might still be some
issues unwinding through shared libraries with the new dwarf2 exception
support.

These failures need looking at:

FAIL: gcc.c-torture/execute/20010122-1.c execution,  -O0
FAIL: gcc.c-torture/execute/20010122-1.c execution,  -O1
FAIL: gcc.c-torture/execute/20010122-1.c execution,  -O2
FAIL: gcc.c-torture/execute/20010122-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/20010122-1.c execution,  -Os
FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)

> For the target `hppa[1-2]*-hp-hpux11*' gcc --target-help says:
> 
> - -mpa-risc-2-0 Generate PA2.0 code (requires binutils 2.10 or 
> later)
> - -mpa-risc-1-1 Generate PA1.1 code
> - -mpa-risc-1-0 Generate PA1.0 code
> 
> which produces executables as follows for example:
> 
> file gcc
> gcc:  PA-RISC1.1 shared executable dynamically linked -not stripped

There is a bug in gas 2.16.1 which almost always causes the promotion
of PA 1.0 to PA 1.1.  This should be fixed in cvs binutils.

> For the target `hppa64-hp-hpux11*' it's completly different:
> 
> file gcc
> gcc:   ELF-64 executable object file - PA-RISC 2.0 (LP64)
> this is 64bit.

The wide mode bit is in the PSW for 64-bit executables.  This changes
the addressing model and the behavior of some instructions.

> So what I see, the `hppa64-hp-hpux11*' target implies PA-RISC 2.0 
> architecture.

Yes.

> But I think it's not true the other way. The `hppa[1-2]*-hp-hpux11*' target 
> does
> not imply 64bit.

Correct.  The runtime for `hppa[1-2]*-hp-hpux11*' is the 32-bit SOM runtime
(HP linker required).  The general registers are 64 bits in PA 2.0.  However,
only the least significant 32 bits of the call-saved registers are saved
and restored by the prologue and epilogue of functions.   The kernel will
save the full 64 bits on context switches if it's a wide-mode kernel (also
required for hppa64).  Thus, it's possible to use the full 64 bits of the
general registers between calls in the 32-bit runtime when using a wide-mode
kernel.  However, GCC doesn't attempt to use this capability.

> So, what I did in the past:
> 
> I set CC="gcc -mpa-risc-2-0".

This only is used in stage1 of a bootstrap.  To add "-mpa-risc-2-0"
to CFLAGS in later stages, you need to add something like
BOOT_CFLAGS="-g -O2 -mpa-risc-2-0" to the make bootstrap command.

> Runtime libraries are built for PA-RISC1.1, because gcc defaults to build
> PA-RISC1.1 code for target hppa2.0w-hp-hpux11.00, that's also curios.

Right.  I think the PA-RISC1.1 default is ok.  It's the base for almost
all applications in linux as it works on all supported hardware.  The main
benefit in using PA 2.0 in the 32-bit runtime arises in floating point
intensive applications.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: Option to print word size, alignment on the target platform

[Robert Dewar]

Igor Bukanov wrote:

On 1/25/06, Robert Dewar <[EMAIL PROTECTED]> wrote:


A convenient way to get the endianness is to use
the System.Bit_Order attribute in Ada.



But this requires to run the program on the target which is not
possible with a cross-compiler. Or is there a trick to declare
something in Ada that would force the program to miscompile depending
on the target endianness?

Regards, Igor


System'Bit_Order is a static constant so you can
do

   Verify_LE : constant :=
   1 / Boolean'Pos (System.Default_Bit_Order =  
Low_Order_First);

which will give a compile time error (division by zero in
a static expression, if you are big endian)

Yes, I think the word "trick" is appropriate here.

In GNAT, you can use something nicer

  pragma Compile_Time_Warning
   (System.Default_Bit_Order = High_Order_First,
"wrong endianness, program requires little endian target");

and then can if you set the switch to treat warnings as errors.

Re: bootstrap broken on solaris8

[Richard Henderson]

On Wed, Jan 25, 2006 at 08:07:34AM +0100, Andreas Tobler wrote:
>   * genautomata.c (main): Add insn-config.h and recog.h to the
>   include list.
>   * Makefile.in (insn-automata.o): Adjust dependencies for the above
>   includes.

Ok.


r~

Re: bootstrap broken on solaris8

[Steve Ellcey]

> 2006-01-25  Andreas Tobler  <[EMAIL PROTECTED]>
> 
> * genautomata.c (main): Add insn-config.h and recog.h to the
> include list.
> * Makefile.in (insn-automata.o): Adjust dependencies for the above
> includes.

Andreas,

I don't know if you have checked this in yet (you sent it to gcc instead
of gcc-patches) but for IA64 Linux and HP-UX this isn't quite enough.

I still get implicitly declared errors for a couple of functions declared
in ia64-protos.h.  I think the patch needs to be expanded to include
tm_p.h in addition to tm.h.  I am testing that now.

Steve Ellcey
[EMAIL PROTECTED]

Re: bootstrap broken on solaris8

[Zack Weinberg]

On Wed, Jan 25, 2006 at 10:17:40AM -0800, Steve Ellcey wrote:
> > 2006-01-25  Andreas Tobler  <[EMAIL PROTECTED]>
> > 
> > * genautomata.c (main): Add insn-config.h and recog.h to the
> > include list.
> > * Makefile.in (insn-automata.o): Adjust dependencies for the above
> > includes.
> 
> Andreas,
> 
> I don't know if you have checked this in yet (you sent it to gcc instead
> of gcc-patches) but for IA64 Linux and HP-UX this isn't quite enough.
> 
> I still get implicitly declared errors for a couple of functions declared
> in ia64-protos.h.  I think the patch needs to be expanded to include
> tm_p.h in addition to tm.h.  I am testing that now.

Perhaps best to just clone the complete list of headers from insn-attrtab.c?
I can't remember anymore why I didn't do that in the first place.

zw

Re: Patch: Boehm GC 6.6 merge

[Bryce McKinlay]

Andrew Haley wrote:

Ranjit Mathew writes:
 > -BEGIN PGP SIGNED MESSAGE-
 > Hash: SHA1
 > 
 > Bryce McKinlay wrote:
 > > This patch merges the GC 6.6 sources into the libgcj trunk. Two patches 
 > [...]
 > 
 > This little bit in "boehm-gc/include/private/gcconfig.h" (line 306):

 > - - 8< -
 > > +# else
 > > +#if defined(__i386__)
 > > +#  define I386
 > >   --> Not really supported, but at least we recognize it.
 > > +#endif
 > - - 8< -
 > causes a bootstrap failure for me on i686-pc-linux-gnu.
 > Note that the "Not really" bit is not inside a comment.

The differences between our gcconfig.h and the stock Boehm 6.6 version
are hard for me to understand.  Bryce, what are the reasons for them?
I understand why we want to define USE_MMAP for Linux, but the rest
look spurious.
  


Some of these come from changes for darwin/PPC64 support that are in our 
tree but not yet in the upstream GC sources -  I believe the "Not really 
supported" bit is supposed to refer to Darwin/x86. I'm investigating and 
will check in a fix shortly.


Most of the other diffs look like whitespace changes and can be stripped 
out.


Bryce

Re: Problem with gfortran or did I messsed up GMP installation?

[Aleksandar Milivojevic]

Quoting Eric Botcazou <[EMAIL PROTECTED]>:


Please make sure every bit of the hacked GMP has been wiped out on Solaris 9.


Should I file bug on bugzilla?


Sure, if you can reproduce it after cleaning up the Solaris 9 machine.


To confirm things, I did following:

Install gcc 2.8.1 binary (from 
gnat-3.15p-sparc-sun-solaris2.5.1-bin.tar.gz) into /gcc-test (empty 
directory).  I used this one, since I guess anybody starting from 
scratch (fresh clean system) would use a binary like this (and this one 
can also bootstrap Ada compiler if needed).  /usr/local on this system 
does not conatin any include or library files.


Place /gcc-test/bin first in my path and define LD_RUN_PATH:

 $ export PATH=/gcc-test/bin:$PATH
 $ hash -r
 $ export LD_RUN_PATH=/gcc-test/lib:/gcc-test/lib/sparcv9

Install binutils 2.16:

 $ ../configure  --prefix=/gcc-test --disable-nls \
   --enable-64-bit-bfd

Compile GMP 4.1.4:

 $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr

Bootstrap GCC 4.0.2 with c and f95:

 $ ../configure --prefix=/gcc-test --with-local-prefix=/gcc-test \
   --enable-languages=c,f95 --disable-nls \
   --with-as=/gcc-test/bin/as --with-ld=/gcc-test/bin/ld \
   --with-gnu-as --with-gnu-ld \
   --with-mpfr=/gcc-test --with-gmp=/gcc-test

Prior to compilation, I removed all sources (binutils, GMP, and GCC), 
and untarred them from original tar archives.  Would this be clean 
enough?  I don't see anything wrong in the way I created this test 
environment.  If there is something wrong, please let me know.


After doing all this, the problem is still there.  So I would say I can 
reproduce it.




This message was sent using IMP, the Internet Messaging Program.

Re: Problem with gfortran or did I messsed up GMP installation?

[Eric Botcazou]

> Compile GMP 4.1.4:
>
>   $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr

Would you mind trying as documented in
  http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2
i.e. with --build=sparc-sun-solaris2.9 instead of ABI=32?

Thanks in advance.

-- 
Eric Botcazou

Re: x86-64 linux, gomp ICE in trunk

[Diego Novillo]

tbp wrote:
> src/raytrace_packet.cpp:1411: internal compiler error: Segmentation fault
> Please submit a full bug report
>   
You'll need to do what this message suggests.  http://gcc.gnu.org/bugzilla/

Re: Problem with gfortran or did I messsed up GMP installation?

[Aleksandar Milivojevic]

Quoting Eric Botcazou <[EMAIL PROTECTED]>:


Compile GMP 4.1.4:

  $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr


Would you mind trying as documented in
 http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2
i.e. with --build=sparc-sun-solaris2.9 instead of ABI=32?


I'll try it.  The only difference (AFAIK) should be that GMP will use 
only sparcv7 optimized assembler code.


I'll also try it out on Solaris 2.11 beta (just for the kicks, and 
because it is the only virgin Solaris box I have).




This message was sent using IMP, the Internet Messaging Program.

Future possible stack based optimization

[Frediano Ziglio]

Hi,
  I saw that stack instructions on Intel platform are not used that
much. I think this is a pity cause stack operations are small (size
optimization) and usually fast (from Pentium two consecutive push/pop
are executed together -> speed optimization). Consider this small piece
of code

extern int foo1(int *a);

int foo2(int a)
{
int b = a + 2;
return foo1(&b);
}

compiling with 

$ gcc -O2 -mpreferred-stack-boundary=2 -fomit-frame-pointer  -S optim1.c

$ gcc --version
gcc (GCC) 4.2.0 20060107 (experimental)

produce following code

foo2:
subl$8, %esp
movl12(%esp), %eax
addl$2, %eax
movl%eax, 4(%esp)
leal4(%esp), %eax
movl%eax, (%esp)
callfoo1
addl$8, %esp
ret

compiled with

$ gcc -Os -mpreferred-stack-boundary=2 -fomit-frame-pointer  -S optim1.c

foo2:
subl$4, %esp
movl8(%esp), %eax
addl$2, %eax
movl%eax, (%esp)
movl%esp, %eax
pushl   %eax
callfoo1
popl%edx
popl%ecx
ret

this is worst than 4.0.2

$ gcc -O2 -mpreferred-stack-boundary=2 -fomit-frame-pointer  -S optim1.c

$ gcc --version
gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)

foo2:
pushl   %eax
movl8(%esp), %eax
addl$2, %eax
movl%eax, (%esp)
movl%esp, %eax
pushl   %eax
callfoo1
addl$8, %esp
ret

(note pushl %eax size optimization instead of subl $4, %esp)

Would it possible instead of allocating memory with subl/pushl to
allocate and set memory with pushl only? Something like

foo2:
movl4(%esp), %eax
addl$2, %eax
pushl   %eax
pushl   %esp
callfoo1
popl%edx
popl%ecx
ret

(note that first pushl allocate and set variable on stack)

Is anyone working in this direction?

bye
  Frediano Ziglio

Re: bootstrap broken on solaris8

[Andreas Tobler]

Steve Ellcey wrote:

2006-01-25  Andreas Tobler  <[EMAIL PROTECTED]>

* genautomata.c (main): Add insn-config.h and recog.h to the
include list.
* Makefile.in (insn-automata.o): Adjust dependencies for the above
includes.


Andreas,

I don't know if you have checked this in yet (you sent it to gcc instead
of gcc-patches) but for IA64 Linux and HP-UX this isn't quite enough.


No, I do not have done the ci, was away. And sorry for posting this to 
gcc. Webmail crap :(




I still get implicitly declared errors for a couple of functions declared
in ia64-protos.h.  I think the patch needs to be expanded to include
tm_p.h in addition to tm.h.  I am testing that now.


Shall I help? I have a fast sunfire here where I can cross check.

I wait until you come up, then we can put it in together, ok?

Andreas

Re: bootstrap broken on solaris8

[Steve Ellcey]

> > I still get implicitly declared errors for a couple of functions declared
> > in ia64-protos.h.  I think the patch needs to be expanded to include
> > tm_p.h in addition to tm.h.  I am testing that now.
> 
> Shall I help? I have a fast sunfire here where I can cross check.
> 
> I wait until you come up, then we can put it in together, ok?
> 
> Andreas

I took Zack's advice and put all the includes from insn-attrtab.c into
insn-automata.c.  My current problem is that I get:

| insn-automata.c: In function 'print_reservation':
| insn-automata.c:22466: warning: string length '669' is greater than the 
length '
| 509' ISO C89 compilers are required to support
| make[3]: *** [insn-automata.o] Error 1
| make[3]: Target `all' not remade because of errors.

Here is the patch I used:

Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 110102)
+++ gcc/varasm.c(working copy)
@@ -1860,12 +1860,9 @@ assemble_name_raw (FILE *file, const cha
 void
 assemble_name (FILE *file, const char *name)
 {
-  const char *real_name;
   tree id;
 
-  real_name = targetm.strip_name_encoding (name);
-
-  id = maybe_get_identifier (real_name);
+  id = maybe_get_identifier (name);
   if (id)
 {
   tree id_orig = id;
Index: gcc/testsuite/gcc.target/ia64/asm-decl.c
===
--- gcc/testsuite/gcc.target/ia64/asm-decl.c(revision 0)
+++ gcc/testsuite/gcc.target/ia64/asm-decl.c(revision 0)
@@ -0,0 +1,13 @@
+/* Make sure a function with __asm__ name gets declared properly. */
+/* { dg-do compile { target ia64*-*-hpux* } } */
+/* { dg-final { scan-assembler "\\.global.*foobar" } } */
+/* { dg-final { scan-assembler "\\.type.*foobar.*function" } } */
+
+extern double bar (void);
+extern double bar (void) __asm__ ("foobar");
+
+double
+foo (void)
+{
+  return bar ();
+}

Re: Future possible stack based optimization

[Marcel Cox]

>   I saw that stack instructions on Intel platform are not used that
> much. I think this is a pity cause stack operations are small (size
> optimization) and usually fast (from Pentium two consecutive push/pop
> are executed together -> speed optimization). Consider this small
> piece of code


whether push(pop instructions or mov instructions are faster depends on
the type of processor used. GCC is well aware of this. If you specify
the desired processor with -mtune then GCC will use whatever is best
for that processor. For example if you optimize for old Pentium
processors, use -mtune=pentium and you will see that the compiler uses
push/pop instructions even when not using -Os
-- 
Marcel Cox 

Re: bootstrap broken on solaris8

[Zack Weinberg]

On Wed, Jan 25, 2006 at 01:01:17PM -0800, Steve Ellcey wrote:
> 
> I took Zack's advice and put all the includes from insn-attrtab.c into
> insn-automata.c.  My current problem is that I get:
> 
> | insn-automata.c: In function 'print_reservation':
> | insn-automata.c:22466: warning: string length '669' is greater than the 
> length '
> | 509' ISO C89 compilers are required to support
> | make[3]: *** [insn-automata.o] Error 1
> | make[3]: Target `all' not remade because of errors.

Odd.  I don't see how my changes could possibly have triggered that.

> Here is the patch I used:

Um. I think you sent the wrong patch.

zw

Re: bootstrap broken on solaris8

[Andreas Tobler]

Zack Weinberg wrote:

On Wed, Jan 25, 2006 at 01:01:17PM -0800, Steve Ellcey wrote:

I took Zack's advice and put all the includes from insn-attrtab.c into
insn-automata.c.  My current problem is that I get:

| insn-automata.c: In function 'print_reservation':
| insn-automata.c:22466: warning: string length '669' is greater than the 
length '
| 509' ISO C89 compilers are required to support
| make[3]: *** [insn-automata.o] Error 1
| make[3]: Target `all' not remade because of errors.


Odd.  I don't see how my changes could possibly have triggered that.


Well, I do not see this on sparc-sol8, even with the patch you attached 
plus all the includes applied in genautomata.c

I'm in building the runtimes now.



Here is the patch I used:


Um. I think you sent the wrong patch.


Hm, probably.

Andreas

Re: bootstrap broken on solaris8

[Steve Ellcey]

> On Wed, Jan 25, 2006 at 01:01:17PM -0800, Steve Ellcey wrote:
> > 
> > I took Zack's advice and put all the includes from insn-attrtab.c into
> > insn-automata.c.  My current problem is that I get:
> > 
> > | insn-automata.c: In function 'print_reservation':
> > | insn-automata.c:22466: warning: string length '669' is greater than the 
> > length '
> > | 509' ISO C89 compilers are required to support
> > | make[3]: *** [insn-automata.o] Error 1
> > | make[3]: Target `all' not remade because of errors.
> 
> Odd.  I don't see how my changes could possibly have triggered that.

It seems to be coming from the reservation_names array set up in
print_reservation.  One of the entries is:

"(1_0m_bs,1_m_cont)|(1_0mi_bs,1_mi_cont|nothing)|(1_0mm_bs,1_mm_cont)|(1_0mf_bs,1_mf_cont|nothing)|(1_0b_bs,1_b_cont|nothing)|(1_0bb_bs,1_bb_cont|nothing)|(1_0mb_bs,1_mb_cont|nothing)|(1_1m_bs,1_m_cont)|(1_1mi_bs,1_mi_cont|nothing)|(1_1mm_bs,1_mm_cont)|(1_1mf_bs,1_mf_cont|nothing)|(1_1b_bs,1_b_cont|nothing)|(1_1bb_bs,1_bb_cont|nothing)|(1_1mb_bs,1_mb_cont|nothing)|(1_m_cont_only,1_m_cont|nothing)|(1_b_cont_only,1_b_cont|nothing)|(1_mi_cont_only,1_mi_cont|nothing)|(1_mm_cont_only,1_mm_cont|nothing)|(1_mf_cont_only,1_mf_cont|nothing)|(1_mb_cont_only,1_mb_cont|nothing)|(1_bb_cont_only,1_bb_cont|nothing)|(1_m_stop,1_0mmi_cont|nothing)|(1_mi_stop,1_0mii_cont|nothing)"

This in turn seems to be coming from config/ia64/itanium1.md:

(define_insn_reservation "1_pre_cycle" 0
   (and (and (eq_attr "cpu" "itanium")
 (eq_attr "itanium_class" "pre_cycle"))
(eq (symbol_ref "bundling_p") (const_int 0)))
 "(1_0m_bs, 1_m_cont) \
  | (1_0mi_bs, (1_mi_cont|nothing))   \
  | (1_0mm_bs, 1_mm_cont) \
  | (1_0mf_bs, (1_mf_cont|nothing))   \
  | (1_0b_bs, (1_b_cont|nothing)) \
  | (1_0bb_bs, (1_bb_cont|nothing))   \
  | (1_0mb_bs, (1_mb_cont|nothing))   \
  | (1_1m_bs, 1_m_cont)   \
  | (1_1mi_bs, (1_mi_cont|nothing))   \
  | (1_1mm_bs, 1_mm_cont) \
  | (1_1mf_bs, (1_mf_cont|nothing))   \
  | (1_1b_bs, (1_b_cont|nothing)) \
  | (1_1bb_bs, (1_bb_cont|nothing))   \
  | (1_1mb_bs, (1_mb_cont|nothing))   \
  | (1_m_cont_only, (1_m_cont|nothing))   \
  | (1_b_cont_only,  (1_b_cont|nothing))  \
  | (1_mi_cont_only, (1_mi_cont|nothing)) \
  | (1_mm_cont_only, (1_mm_cont|nothing)) \
  | (1_mf_cont_only, (1_mf_cont|nothing)) \
  | (1_mb_cont_only, (1_mb_cont|nothing)) \
  | (1_bb_cont_only, (1_bb_cont|nothing)) \
  | (1_m_stop, (1_0mmi_cont|nothing)) \
  | (1_mi_stop, (1_0mii_cont|nothing))")

I am not sure why this long string was not a problem before but is now.

> > Here is the patch I used:
> 
> Um. I think you sent the wrong patch.

Woops, I meant to include:

Index: Makefile.in
===
--- Makefile.in (revision 110226)
+++ Makefile.in (working copy)
@@ -2640,7 +2640,8 @@ insn-attrtab.o : insn-attrtab.c $(CONFIG
   $(TM_H) $(RTL_H) $(REGS_H) real.h output.h $(INSN_ATTR_H)\
   insn-config.h toplev.h $(RECOG_H) $(TM_P_H) $(FLAGS_H)
 insn-automata.o : insn-automata.c $(CONFIG_H) $(SYSTEM_H) coretypes.h  \
-  $(TM_H) $(RTL_H) $(INSN_ATTR_H)
+  $(TM_H) $(RTL_H) $(REGS_H) real.h output.h $(INSN_ATTR_H)\
+  insn-config.h toplev.h $(RECOG_H) $(TM_P_H) $(FLAGS_H)
 insn-emit.o : insn-emit.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H)  \
   $(RTL_H) $(EXPR_H) real.h output.h insn-config.h $(OPTABS_H) \
   reload.h $(RECOG_H) toplev.h $(FUNCTION_H) $(FLAGS_H) hard-reg-set.h \

Index: genautomata.c
===
--- genautomata.c   (revision 110226)
+++ genautomata.c   (working copy)
@@ -9255,7 +9257,16 @@ main (int argc, char **argv)
"#include \"coretypes.h\"\n"
"#include \"tm.h\"\n"
"#include \"rtl.h\"\n"
-   "#include \"insn-attr.h\"\n");
+   "#include \"tm_p.h\"\n"
+   "#include \"insn-config.h\"\n"
+   "#include \"recog.h\"\n"
+   "#include \"regs.h\"\n"
+   "#include \"real.h\"\n"
+   "#include \"output.h\"\n"
+   "#include \"insn-attr.h\"\n"
+   "#include \"toplev.h\"\n"
+   "#include \"flags.h\"\n"
+   "#include \"function.h\"\n");
 
   if (VEC_length (decl_t, decls) > 0)
 {

Re: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

[Bradley Lucier]

On Jan 23, 2006, at 8:07 PM, Shantonu Sen wrote:

I've posted a new version of odcctools (based on Apple's cctools  
and ld64 source) which should fix a few thousand of the failures.  
Instructions are at:




This is based on cctools-590.18 and ld64-26.0.81, which should be  
substantially similar to what you have, and since you can use -- 
prefix, you don't need to overwrite the Apple-provided tools.


Can you report how this changes things?


The results are much better, thanks:

http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01316.html

So what are you recommending people do?  Use the OpenDarwin version  
of cctools instead of relying on Apple's official version?


Brad

Re: bootstrap broken on solaris8

[Andreas Tobler]

Steve Ellcey wrote:

On Wed, Jan 25, 2006 at 01:01:17PM -0800, Steve Ellcey wrote:

I took Zack's advice and put all the includes from insn-attrtab.c into
insn-automata.c.  My current problem is that I get:

| insn-automata.c: In function 'print_reservation':
| insn-automata.c:22466: warning: string length '669' is greater than the 
length '
| 509' ISO C89 compilers are required to support
| make[3]: *** [insn-automata.o] Error 1
| make[3]: Target `all' not remade because of errors.

Odd.  I don't see how my changes could possibly have triggered that.




Hm, then I suggest at first to propose your patch to resolve the implict 
declarations. ( I have the applied the same on sparc-solaris. )


Andreas

Re: bootstrap broken on solaris8

[Zack Weinberg]

On Wed, Jan 25, 2006 at 02:10:33PM -0800, Steve Ellcey wrote:
> 
> It seems to be coming from the reservation_names array set up in
> print_reservation.  One of the entries is:
> 
> "(1_0m_bs,1_m_cont)|(1_0mi_bs,1_mi_cont|nothing)|(1_0mm_bs,1_mm_cont)|(1_0mf_bs,1_mf_cont|nothing)|(1_0b_bs,1_b_cont|nothing)|(1_0bb_bs,1_bb_cont|nothing)|(1_0mb_bs,1_mb_cont|nothing)|(1_1m_bs,1_m_cont)|(1_1mi_bs,1_mi_cont|nothing)|(1_1mm_bs,1_mm_cont)|(1_1mf_bs,1_mf_cont|nothing)|(1_1b_bs,1_b_cont|nothing)|(1_1bb_bs,1_bb_cont|nothing)|(1_1mb_bs,1_mb_cont|nothing)|(1_m_cont_only,1_m_cont|nothing)|(1_b_cont_only,1_b_cont|nothing)|(1_mi_cont_only,1_mi_cont|nothing)|(1_mm_cont_only,1_mm_cont|nothing)|(1_mf_cont_only,1_mf_cont|nothing)|(1_mb_cont_only,1_mb_cont|nothing)|(1_bb_cont_only,1_bb_cont|nothing)|(1_m_stop,1_0mmi_cont|nothing)|(1_mi_stop,1_0mii_cont|nothing)"

/me makes a note to get back to the -Wno-overlength-strings patch sooner.

> Woops, I meant to include:
[...]

This patch looks good to me.

zw

Re: bootstrap broken on solaris8

[Steve Ellcey]

> Hm, then I suggest at first to propose your patch to resolve the implict 
> declarations. ( I have the applied the same on sparc-solaris. )
> 
> Andreas

Andreas,

I think that is a good idea.  It gets us a bit further.  Since my patch
is just an extension of yours why don't you go ahead and submit it when
your testing is done.  If you don't want to submit it, I can do it.

Steve Ellcey
[EMAIL PROTECTED]

Re: bootstrap broken on solaris8

[Andreas Tobler]

Steve Ellcey wrote:
Hm, then I suggest at first to propose your patch to resolve the implict 
declarations. ( I have the applied the same on sparc-solaris. )



I think that is a good idea.  It gets us a bit further.  Since my patch
is just an extension of yours why don't you go ahead and submit it when
your testing is done.  If you don't want to submit it, I can do it.


Well, my testing is done so far, including test suite runs for -m32/64 
solaris. But the important thing is, that _your_ implict declarations 
are fixed. Mine are.


Another thing, the day is going to an end here and I'll be not able to 
fix any issues immediatley if they pop up.


So, Steve, if you do not mind, would you please commit if you get the 
approval?


Thanks
Andreas

Re: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

[Shantonu Sen]

I'm not recommending anything, I'm trying to help you verify whether  
GCC's testsuite is failing because of testsuite bugs, gcc bugs, tools  
bugs, or OS bugs. This should help you focus on the legitimate  
problems with gcc.


In this case, the thousands of failures were an interaction between  
how the testsuite runs the linker with -L paths relative to the  
bootstrapped compiler in the local build directory, and wouldn't be  
seen, typically, if you ran the testsuite against an installed compiler.


As a GCC developer and/or bleeding edge user, it's fairly common to  
require a newer toolchain to support new features in gcc than is  
being officially shipped by Apple. Running the testsuite successfully  
counts as a "feature" in this case. In those cases, you can either  
use binaries posted by members of Apple's compiler team, or build  
odcctools from source. I don't see this as significantly different.


If your concern is that you don't trust the modifications that have  
been made, you can view them and apply only the fixes you want:  



Shantonu

On Jan 25, 2006, at 2:12 PM, Bradley Lucier wrote:



On Jan 23, 2006, at 8:07 PM, Shantonu Sen wrote:

I've posted a new version of odcctools (based on Apple's cctools  
and ld64 source) which should fix a few thousand of the failures.  
Instructions are at:




This is based on cctools-590.18 and ld64-26.0.81, which should be  
substantially similar to what you have, and since you can use -- 
prefix, you don't need to overwrite the Apple-provided tools.


Can you report how this changes things?


The results are much better, thanks:

http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01316.html

So what are you recommending people do?  Use the OpenDarwin version  
of cctools instead of relying on Apple's official version?


Brad

Re: bootstrap broken on solaris8

[Steve Ellcey]

> Well, my testing is done so far, including test suite runs for -m32/64 
> solaris. But the important thing is, that _your_ implict declarations 
> are fixed. Mine are.

Yes, my implicit declarations are fixed.

> Another thing, the day is going to an end here and I'll be not able to 
> fix any issues immediatley if they pop up.
> 
> So, Steve, if you do not mind, would you please commit if you get the 
> approval?

OK, I will submit this (with a ChangeLog) to gcc-patches and commit
it if/when approved.

Steve Ellcey
[EMAIL PROTECTED]

Attribute data structure rewrite?

[Giovanni Bajo]

Hi Geoff,

re this mail:
http://gcc.gnu.org/ml/gcc/2004-09/msg01357.html

do you still have the code around? Are you still willing to contribute it?
Maybe you could upload it to a branch just to have it around in case someone is
willing to update/finish it.

Thanks!
Giovanni Bajo

Re: bootstrap broken on solaris8

[Steve Ellcey]

> > It seems to be coming from the reservation_names array set up in
> > print_reservation.  One of the entries is:
> > 
> > "(1_0m_bs,1_m_cont)|(1_0mi_bs,1_mi_cont|nothing)|(1_0mm_bs,1_mm_cont)|(1_0mf_bs,1_mf_cont|nothing)|(1_0b_bs,1_b_cont|nothing)|(1_0bb_bs,1_bb_cont|nothing)|(1_0mb_bs,1_mb_cont|nothing)|(1_1m_bs,1_m_cont)|(1_1mi_bs,1_mi_cont|nothing)|(1_1mm_bs,1_mm_cont)|(1_1mf_bs,1_mf_cont|nothing)|(1_1b_bs,1_b_cont|nothing)|(1_1bb_bs,1_bb_cont|nothing)|(1_1mb_bs,1_mb_cont|nothing)|(1_m_cont_only,1_m_cont|nothing)|(1_b_cont_only,1_b_cont|nothing)|(1_mi_cont_only,1_mi_cont|nothing)|(1_mm_cont_only,1_mm_cont|nothing)|(1_mf_cont_only,1_mf_cont|nothing)|(1_mb_cont_only,1_mb_cont|nothing)|(1_bb_cont_only,1_bb_cont|nothing)|(1_m_stop,1_0mmi_cont|nothing)|(1_mi_stop,1_0mii_cont|nothing)"
> 
> /me makes a note to get back to the -Wno-overlength-strings patch sooner.

I see, in an older GCC build output I see a compilation of
insn-attrtab.c and I get the messages:

/proj/opensrc/sje/svn/gcc.patch/trunk/gcc/config/ia64/itanium2.md: In function 
'print_reservation':
/proj/opensrc/sje/svn/gcc.patch/trunk/gcc/config/ia64/itanium2.md:127585: 
warning: string length '669' is greater than the length '509' ISO C89 compilers 
are required to support

But the build does not abort because after the -Werror option we also have
-Wno-error.

In the newest build I get:

cc1: warnings being treated as errors
insn-automata.c: In function 'print_reservation':
insn-automata.c:22466: warning: string length '669' is greater than the length 
'509' ISO C89 compilers are required to support
make[3]: *** [insn-automata.o] Error 1

And when I look at the options used to compile insn-automata.c I see
-Werror but no subsequent -Wno-error.

Steve Ellcey
[EMAIL PROTECTED]

Re: bootstrap broken on solaris8

[Zack Weinberg]

On Wed, Jan 25, 2006 at 04:13:02PM -0800, Steve Ellcey wrote:
> 
> I see, in an older GCC build output I see a compilation of
> insn-attrtab.c and I get the messages:
> 
> /proj/opensrc/sje/svn/gcc.patch/trunk/gcc/config/ia64/itanium2.md: In 
> function 'print_reservation':
> /proj/opensrc/sje/svn/gcc.patch/trunk/gcc/config/ia64/itanium2.md:127585: 
> warning: string length '669' is greater than the length '509' ISO C89 
> compilers are required to support
> 
> But the build does not abort because after the -Werror option we also have
> -Wno-error.

Ah.  Add

insn-automata.o-warn = -Wno-error

somewhere in the makefile (search for -Wno-error to see where the other
files with this treatment are).

zw

Re: Attribute data structure rewrite?

[Geoffrey Keating]

On 25/01/2006, at 4:09 PM, Giovanni Bajo wrote:


Hi Geoff,

re this mail:
http://gcc.gnu.org/ml/gcc/2004-09/msg01357.html

do you still have the code around? Are you still willing to  
contribute it?
Maybe you could upload it to a branch just to have it around in  
case someone is

willing to update/finish it.


It's on the stree-branch, I think.  Yes, I'm still willing to  
contribute it and would be very happy to see someone else update &  
commit it.




smime.p7s
Description: S/MIME cryptographic signature

issue with references to weak symbols in PIEs

[Mike Frysinger]

before people dismiss this as a Gentoo-specific issue, the code fails with 
Redhat and Debian toolchains as well.  tested gcc 3.4.5, 4.0.3, and a snap of 
4.1.x dated 20060120.

we were playing with arrays of pointers to weak functions in a utility program 
when we noticed the code started crashing whenever built with a Gentoo 
hardened toolchain.  Gentoo vanilla toolchains would produce code that ran 
nicely and as expected.  tracing it back, the references to the undefined 
weak functions were not being set to NULL as they should have been.  then we 
reproduced the issue with a Gentoo vanilla toolchain by simply building the 
test code as a PIE.  i'm not sure if this is an issue in gcc or glibc ldso or 
a bug at all (i'm pretty sure it's a bug), so i'm starting with gcc :)

ive attached the test code we are playing with ... here's some example runs on 
my Gentoo amd64 box:
$ gcc-4.1.0-beta20060120 -pie -fPIE weak-test.c -DOK1 && ./a.out
this should be null: (nil)
$ gcc-4.1.0-beta20060120 -pie -fPIE weak-test.c -DOK2 && ./a.out
this should be null: (nil)
this should be null: (nil)
$ gcc-4.1.0-beta20060120 -pie -fPIE weak-test.c -DBROKEN && ./a.out
this should be null: 0xe23bc395000
$ gcc-4.1.0-beta20060120 weak-test.c -DBROKEN && ./a.out
this should be null: (nil)
-mike
#include 

extern int undef_func (void) __attribute__((weak));
int (*ptr_to_func)(void) = undef_func;

int main()
{
#ifdef BROKEN
	printf("this should be null: %p\n", ptr_to_func);
#endif
#ifdef OK1
	printf("this should be null: %p\n", undef_func);
#endif
#ifdef OK2
	printf("this should be null: %p\n", undef_func);
	printf("this should be null: %p\n", ptr_to_func);
#endif
	return 0;
}

Re: issue with references to weak symbols in PIEs

[Andrew Pinski]

On Jan 25, 2006, at 8:49 PM, Mike Frysinger wrote:
we were playing with arrays of pointers to weak functions in a utility 
program

when we noticed the code started crashing whenever built with a Gentoo
hardened toolchain.  Gentoo vanilla toolchains would produce code that 
ran
nicely and as expected.  tracing it back, the references to the 
undefined
weak functions were not being set to NULL as they should have been.  
then we
reproduced the issue with a Gentoo vanilla toolchain by simply 
building the
test code as a PIE.  i'm not sure if this is an issue in gcc or glibc 
ldso or

a bug at all (i'm pretty sure it's a bug), so i'm starting with gcc :)


Well please look at the code generation that GCC does.  It is correct.
movqptr_to_func(%rip), %rsi

-- Pinski

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Kaveh R. Ghazi]

 > Zack - using your latest genconditions.c patch plus this one:
 > http://gcc.gnu.org/ml/gcc/2006-01/msg00951.html
 > was sufficient to get a C-only bootstrap working on solaris2.10 using
 > cc for stage1.
 > 
 > I'm going to run a full test, but that'll take many many hours
 > longer.

Ok, I've now completed a full bootstrap and testsuite run with the two
patches on sparc-solaris2.10.  There are many java failures so we're
not out of the woods.  But at least we're back to bootstrapping.

http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01332.html

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Problem with gfortran or did I messsed up GMP installation?

[Aleksandar Milivojevic]

Eric Botcazou wrote:

Compile GMP 4.1.4:

  $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr


Would you mind trying as documented in
  http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2
i.e. with --build=sparc-sun-solaris2.9 instead of ABI=32?


Done.  I got same thing (32-bit hello world doesn't work, 64-bit hello 
world works).  It could still be something with my local configuration. 
 After all, 32-bit hello world works on my 2.6 box.  However, I don't 
see anything obvious...  I did builds (the ones I'm now using) in 
exactly same way on both 2.6 and 2.9.


The Solaris 2.11 build is still running (building all languages on an 
older box).  Hopefully it will be done sometime tomorrow ;-)

Re: Attribute data structure rewrite?

[Giovanni Bajo]

Geoffrey Keating <[EMAIL PROTECTED]> wrote:

>> re this mail:
>> http://gcc.gnu.org/ml/gcc/2004-09/msg01357.html
>> 
>> do you still have the code around? Are you still willing to
>> contribute it?
>> Maybe you could upload it to a branch just to have it around in
>> case someone is
>> willing to update/finish it.
> 
> It's on the stree-branch, I think.  Yes, I'm still willing to
> contribute it and would be very happy to see someone else update &
> commit it.

svn log --stop-on-copy svn://gcc.gnu.org/svn/gcc/branches/stree-branch

shows me only stree-related commits, but not anything about attributes.

Giovanni Bajo