Re: Change x86 default arch for 4.5?

[Erik Trulsson]

On Fri, Feb 19, 2010 at 09:31:12AM -0800, Joe Buck wrote:
> On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote:
> > On 2/18/2010 4:54 PM, Joe Buck wrote:
> > >
> > > But maybe I didn't ask the right question: can any x86 experts comment on
> > > recently made x86 CPUs that would not function correctly with code
> > > produced by --with-arch=i486?  Are there any?
> > >
> > >
> > All CPUs still in production are at least SSE3 capable, unless someone 
> > can come up with one of which I'm not aware.  Intel compilers made the 
> > switch last year to requiring SSE2 capability for the host, as well as 
> > in the default target options, even for 32-bit.  All x86_64 or X64 CPUs 
> > for which any compiler was produced had SSE2 capability, so it is 
> > required for those 64-bit targets.
> 
> I'm sure that Intel and AMD haven't made any in ages,

Depends on what you mean by ages. Intel did not stop producing actual
80386 (and 80486) processors until as late as 2007 (for use in embedded
systems.)   Looking around at Intel's homepage for embedded processors
I find references to Pentium-MMX processors, but I am not sure about
the actual status of those.  (Those old CPUs probably haven't been used
for any new designs for quite a while, but older designs using them
might still be in prodcution.)
Amd seems to still be producing the Geode-LX series which do not seem
to support SSE at all (only MMX and 3dnow.)

However to answer the original question I believe that all x86
variants that are still actively developed for support at least the
full 80486 instruction set.


> I just wanted to
> make sure that there are no low-end third-party cores made recently (say,
> by Cyrix, VIA, or someone else) that lack atomics.  I guess that the
> answer is no.
> 

-- 

Erik Trulsson
ertr1...@student.uu.se

Re: Long paths with ../../../../ throughout

[Jon]

Hi Ian

Ian Lance Taylor wrote, On 04/02/10 00:48:

Jon  writes:

[.]

I've attached collect2 patch. Let me know what you think of it.


There is actually a GNU standard for --help output, and collect2 might
as well follow it.

http://www.gnu.org/prep/standards/html_node/_002d_002dhelp.html


That's good. Please find updated patch attached.


Do you have a copyright assignment/disclaimer with the FSF?


Just got email notification from FSF that they received my GCC
copyright assignment.

Cheers, Jon
Index: collect2.c
===
--- collect2.c	(revision 156482)
+++ collect2.c	(working copy)
@@ -174,7 +174,7 @@
   int number;
 };
 
-int vflag;/* true if -v */
+bool vflag;/* true if -v or --version */ 
 static int rflag;			/* true if -r */
 static int strip_flag;			/* true if -s */
 static const char *demangle_flag;
@@ -193,7 +193,8 @@
 /* Current LTO mode.  */
 static enum lto_mode_d lto_mode = LTO_MODE_NONE;
 
-int debug;/* true if -debug */
+bool debug;/* true if -debug */
+bool helpflag;			/* true if --help */
 
 static int shared_obj;			/* true if -shared */
 
@@ -1228,7 +1229,7 @@
 for (i = 1; argv[i] != NULL; i ++)
   {
 	if (! strcmp (argv[i], "-debug"))
-	  debug = 1;
+	  debug = true;
 else if (! strcmp (argv[i], "-flto") && ! use_plugin)
 	  {
 	use_verbose = true;
@@ -1458,7 +1459,7 @@
   if (use_verbose && *q == '-' && q[1] == 'v' && q[2] == 0)
 	{
 	  /* Turn on trace in collect2 if needed.  */
-	  vflag = 1;
+	  vflag = true;
 	}
 }
   obstack_free (&temporary_obstack, temporary_firstobj);
@@ -1588,7 +1589,7 @@
 
 	case 'v':
 	  if (arg[2] == '\0')
-		vflag = 1;
+		vflag = true;
 	  break;
 
 	case '-':
@@ -1619,6 +1620,10 @@
 		}
 	  else if (strncmp (arg, "--sysroot=", 10) == 0)
 		target_system_root = arg + 10;
+	  else if (strncmp (arg, "--version", 9) == 0)
+		vflag = true;
+	  else if (strncmp (arg, "--help", 9) == 0)
+		helpflag = true;
 	  break;
 	}
 	}
@@ -1720,6 +1725,20 @@
   fprintf (stderr, "\n");
 }
 
+  if (helpflag)
+{
+  fprintf (stderr, "Usage: collect2 [options]\n");
+  fprintf (stderr, " Wrap linker and generate constructor code if needed.\n");
+  fprintf (stderr, " Options:\n");
+  fprintf (stderr, "  -debug  Enable debug output\n");
+  fprintf (stderr, "  --help  Display this information\n");
+  fprintf (stderr, "  -v, --version   Display this program's version number\n");
+  fprintf (stderr, "Overview: http://gcc.gnu.org/onlinedocs/gccint/Collect2.html\n";);
+  fprintf (stderr, "Report bugs: http://gcc.gnu.org/\n";);
+
+  collect_exit (0);
+}
+
   if (debug)
 {
   const char *ptr;
Index: collect2.h
===
--- collect2.h	(revision 156482)
+++ collect2.h	(working copy)
@@ -38,7 +38,7 @@
 extern const char *c_file_name;
 extern struct obstack temporary_obstack;
 extern char *temporary_firstobj;
-extern int vflag, debug;
+extern bool vflag, debug;
 
 extern void error (const char *, ...) ATTRIBUTE_PRINTF_1;
 extern void notice (const char *, ...) ATTRIBUTE_PRINTF_1;

RE: If/When will GCC accept a compiler options file? -- please ignore, my mistake

[Anthony Wong]

Sorry, my mistake, I'm the one with the old compiler that doesn't support the 
@file option.

--Best regards,
Anthony

-Original Message-
From: Anthony Wong 
Sent: Friday, February 19, 2010 4:11 PM
To: 'gcc@gcc.gnu.org'
Subject: If/When will GCC accept a compiler options file?

Hi--
 
It seems that GCC does not have a facility for putting command line options 
into a separate file which can be passed to the GCC command.
 
For instance, the ARM compiler has the notion of a via file:
 
armcc --via 
 
And Microsoft has a similar mechanism:
 
cl @my_options_file
 
It seems that an earlier version of GCC supported this (3.4.5?).
 
Are there any plans to add this feature?
 
--Thanks,
Anthony Wong

If/When will GCC accept a compiler options file?

[Anthony Wong]

Hi--
 
It seems that GCC does not have a facility for putting command line options 
into a separate file which can be passed to the GCC command.
 
For instance, the ARM compiler has the notion of a via file:
 
armcc --via 
 
And Microsoft has a similar mechanism:
 
cl @my_options_file
 
It seems that an earlier version of GCC supported this (3.4.5?).
 
Are there any plans to add this feature?
 
--Thanks,
Anthony Wong

Re: Change x86 default arch for 4.5?

[Joel Dice]

On Fri, 19 Feb 2010, Florian Weimer wrote:


* Tim Prince:


All CPUs still in production are at least SSE3 capable, unless someone
can come up with one of which I'm not aware.


What about some of the AMD Geode processors?


These only support a subset of SSE1, according to 
http://wiki.laptop.org/go/Geode_instruction_set.


Here is an excerpt from /proc/cpuinfo on my Geode LX:

flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 
3dnowext 3dnow

Re: student internship & GCC

[Ludovic Courtès]

Hi Basile,

Basile Starynkevitch  writes:

> My intern will hopefully be "stagiaire" at my organisation CEA -
> according to my understandding, this is called "internship" in the
> USA.  In France, it means that he is very little paid (much less than
> the minimal work wage) and that for many but not all purposes he is
> considered as a temporary employee of CEA.
>
> In my understanding, as a CEA worker, the intern does not need any
> additional paper from CEA, since the RT306238 assignement of copyright
> in the GCC covers any contribution from any CEA employer.

Interns in France are the copyright holders of what they work on during
the internship, unless otherwise stated (conversely, the copyright
holder of works by regular employees is the employer, by default).  See, e.g.,
.

Thus the intern would have to sign a copyright assignment paper in their
own name and wouldn’t need anything from CEA.

Thanks,
Ludo’.

Re: Change x86 default arch for 4.5?

[Florian Weimer]

* Tim Prince:

> All CPUs still in production are at least SSE3 capable, unless someone
> can come up with one of which I'm not aware.

What about some of the AMD Geode processors?

Re: Adding a statement to statement list before pass_cfg_build

[Saleel Kudchadker]

Thank you Richard. I think I will try to add them on the edges once
the basic blocks are created.

On Fri, Feb 19, 2010 at 12:19 PM, Richard Guenther
 wrote:
> On Fri, Feb 19, 2010 at 8:07 PM, Saleel Kudchadker  wrote:
>> Hi
>>
>> I've been trying to add a statement before the statement list before
>> the basic blocks are created. I am planning to add a function call
>> statement before a user function is called and I use the instrument
>> function definition as a statement . The code and the pass compiles
>> properly but  no function is called when the actual program runs.
>>
>> Can someone hint me where I am going wrong?
>
> Before CFG creation we are in gimple and inserting trees to the
> tree stmt list is useless.
>
>>
>> static void spmm_init_function(tree *tp)
>> {
>> tree func_decl;
>> tree x,spmm_decl,bind;
>>  tree_stmt_iterator i = tsi_start (*tp);
>>  tree_stmt_iterator last_i;
>>  tree stmt=NULL;
>>  enum tree_code code;
>>while (!tsi_end_p (i))
>>{
>>  tree prev_stmt;
>>
>>  prev_stmt = stmt;
>>  stmt = tsi_stmt (i);
>>   code = TREE_CODE (stmt);
>>  switch (code)
>>  {
>>case CALL_EXPR:
>>print_
>>x = implicit_built_in_decls[BUILT_IN_PROFILE_FUNC_ENTER];
>>x = build_call_expr (x, 0);
>>tsi_link_after(&i,x,TSI_NEW_STMT);
>>break;
>>
>>default:
>>break;
>>}
>>tsi_next(&i);
>> }
>>
>> }
>>
>> --
>> Regards,
>>
>> Saleel Kudchadker
>> Graduate Student
>> School of Computing , Informatics and Decision Systems
>> Arizona State University
>>
>



-- 
Regards,

Saleel Kudchadker
Graduate Teaching Assistant
School of Computing , Informatics and Decision Systems
Arizona State University

Re: Adding a statement to statement list before pass_cfg_build

[Richard Guenther]

On Fri, Feb 19, 2010 at 8:07 PM, Saleel Kudchadker  wrote:
> Hi
>
> I've been trying to add a statement before the statement list before
> the basic blocks are created. I am planning to add a function call
> statement before a user function is called and I use the instrument
> function definition as a statement . The code and the pass compiles
> properly but  no function is called when the actual program runs.
>
> Can someone hint me where I am going wrong?

Before CFG creation we are in gimple and inserting trees to the
tree stmt list is useless.

>
> static void spmm_init_function(tree *tp)
> {
> tree func_decl;
> tree x,spmm_decl,bind;
>  tree_stmt_iterator i = tsi_start (*tp);
>  tree_stmt_iterator last_i;
>  tree stmt=NULL;
>  enum tree_code code;
>    while (!tsi_end_p (i))
>    {
>      tree prev_stmt;
>
>      prev_stmt = stmt;
>      stmt = tsi_stmt (i);
>           code = TREE_CODE (stmt);
>          switch (code)
>          {
>                case CALL_EXPR:
>                print_
>                x = implicit_built_in_decls[BUILT_IN_PROFILE_FUNC_ENTER];
>                x = build_call_expr (x, 0);
>                tsi_link_after(&i,x,TSI_NEW_STMT);
>                break;
>
>                default:
>                break;
>        }
>        tsi_next(&i);
> }
>
> }
>
> --
> Regards,
>
> Saleel Kudchadker
> Graduate Student
> School of Computing , Informatics and Decision Systems
> Arizona State University
>

Adding a statement to statement list before pass_cfg_build

[Saleel Kudchadker]

Hi

I've been trying to add a statement before the statement list before
the basic blocks are created. I am planning to add a function call
statement before a user function is called and I use the instrument
function definition as a statement . The code and the pass compiles
properly but  no function is called when the actual program runs.

Can someone hint me where I am going wrong?


static void spmm_init_function(tree *tp)
{
tree func_decl;
tree x,spmm_decl,bind;
  tree_stmt_iterator i = tsi_start (*tp);
  tree_stmt_iterator last_i;
  tree stmt=NULL;
  enum tree_code code;
while (!tsi_end_p (i))
{
  tree prev_stmt;

  prev_stmt = stmt;
  stmt = tsi_stmt (i);
   code = TREE_CODE (stmt);
  switch (code)
  {
case CALL_EXPR:
print_
x = implicit_built_in_decls[BUILT_IN_PROFILE_FUNC_ENTER];
x = build_call_expr (x, 0);
tsi_link_after(&i,x,TSI_NEW_STMT);
break;

default:
break;
}
tsi_next(&i);
}

}

-- 
Regards,

Saleel Kudchadker
Graduate Student
School of Computing , Informatics and Decision Systems
Arizona State University

Re: Change x86 default arch for 4.5?

[Joe Buck]

On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote:
> On 2/18/2010 4:54 PM, Joe Buck wrote:
> >
> > But maybe I didn't ask the right question: can any x86 experts comment on
> > recently made x86 CPUs that would not function correctly with code
> > produced by --with-arch=i486?  Are there any?
> >
> >
> All CPUs still in production are at least SSE3 capable, unless someone 
> can come up with one of which I'm not aware.  Intel compilers made the 
> switch last year to requiring SSE2 capability for the host, as well as 
> in the default target options, even for 32-bit.  All x86_64 or X64 CPUs 
> for which any compiler was produced had SSE2 capability, so it is 
> required for those 64-bit targets.

I'm sure that Intel and AMD haven't made any in ages, I just wanted to
make sure that there are no low-end third-party cores made recently (say,
by Cyrix, VIA, or someone else) that lack atomics.  I guess that the
answer is no.

Function versioning tests?

[Ian Bolton]

Hi there,

I've changed our private port of GCC to give versioned functions
better names (rather than T.0, T.1), and was wondering if there
are any existing tests that push function-versioning to the limit,
so I can test whether my naming scheme is sound.

Failing that, I'd appreciate some pointers on how I might make
such a test.  I know I need to be passing a constant in as a
parameter, but I don't know what other criteria are required to
make it trigger.

Cheers,
Ian

Re: Change x86 default arch for 4.5?

[Paolo Bonzini]

This will probably break building glibc, as problems building when __i686
is a predefined macro have been known since at least 2002 but none of the
many patches proposed since then have been accepted.


I imagine changing the default would help with that...and packagers can
work around it.


I think that many packagers already are.

Paolo

Re: [trans-mem] __sync_add_and_fetch_8 on ia32

[Paolo Carlini]

On 02/19/2010 01:07 PM, Paolo Carlini wrote:
> On 02/19/2010 12:38 PM, Aldy Hernandez wrote:
>   
>> Since the TM library on ia32 is built with -m486, which doesn't have
>> 64-bit atomic operations, should we...
>>
>>  a) Build with -m586 and above.
>>  b) Have _ITM_transactionId_t be 32-bit quantities.
>>  c) Come up with some locking solution for archs that don't have
>> 64-bit atomic operations.
>> 
> My personal opinion on this is that unless we are 100% sure that
> performance are decent anyway (thus 3), or 32-bits are certainly enough
> (thus 2), we should not waste time supporting anything older than -m586
> for the transactional memory work.
>   
... a slightly more sophisticated variant of b) would be using uint64_t
for 64-bit targets and uint32_t for 32-bit targets, should make
everybody happy.

Paolo.

Re: [trans-mem] __sync_add_and_fetch_8 on ia32

[Paolo Carlini]

On 02/19/2010 12:38 PM, Aldy Hernandez wrote:
> Since the TM library on ia32 is built with -m486, which doesn't have
> 64-bit atomic operations, should we...
>
>   a) Build with -m586 and above.
>   b) Have _ITM_transactionId_t be 32-bit quantities.
>   c) Come up with some locking solution for archs that don't have
>  64-bit atomic operations.
>   
My personal opinion on this is that unless we are 100% sure that
performance are decent anyway (thus 3), or 32-bits are certainly enough
(thus 2), we should not waste time supporting anything older than -m586
for the transactional memory work.

Paolo.

[trans-mem] __sync_add_and_fetch_8 on ia32

[Aldy Hernandez]

libitm.so won't build on ia32 because of an undefined reference to
__sync_add_and_fetch_8.

This is the build failure Pearly encountered here:

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01201.html

What happens is that we try to do a __sync_and_fetch() on global_tid,
which is of type _ITM_transactionId_t, a 64-bit quantity:

typedef uint64_t _ITM_transactionId_t;  /* Transaction identifier */

Since the TM library on ia32 is built with -m486, which doesn't have
64-bit atomic operations, should we...

a) Build with -m586 and above.
b) Have _ITM_transactionId_t be 32-bit quantities.
c) Come up with some locking solution for archs that don't have
   64-bit atomic operations.

??
Aldy

student internship & GCC

[Basile Starynkevitch]

HEllo All

I might have perhaps (this is a possibility, not certain) in june 2010 a 
student as an intern "stagiaire universitaire" (in French legalese), in 
"3eme annee de licence informatique" (that is, 3rd year of university, after 
high-school), 
he is 21 year old and student at http://www.univ-mlv.fr/

I hope he will be able to contribute to GCC MELT branch, and perhaps even a 
little bit to GCC trunk.

My own contributions are covered by a copyright assignement RT306238 
http://gcc.gnu.org/ml/gcc/2006-12/msg8.html from my employer, 
Commissariat a l'Energie Atomique (CEA, LIST) http://www.cea.fr/ & 
http://www-list.cea.fr/
(CEA is a French state-owned research entity of about 15000 people, 
approximately the French version of the DOE in the USA)
Getting this paper signed was very painful to me.

Could some people understanding the process of getting an SSH commiting account 
to GCC explain me how could he eventually get such an account.
Please understand that I am not a lawyer at all, and that both he and me (and 
CEA my employer) are under French laws.

My intern will hopefully be "stagiaire" at my organisation CEA - according to 
my understandding, this is called "internship" in the USA. 
In France, it means that he is very little paid (much less than the minimal 
work wage) and that for many but not all purposes 
he is considered as a temporary employee of CEA.

In my understanding, as a CEA worker, the intern does not need any additional 
paper from CEA, 
since the RT306238 assignement of copyright in the GCC covers any contribution 
from any CEA employer.

But it seems that an intern should also get a signed paper from his university 
(to get a write commit to the GCC MELT branch). 
Notice that French university are not like US ones,  in the sense that French 
students do not *buy* their education! I don't know the legal status
of student produced work in France.

Is my understanding correct?

In other words, what are the exact steps to get a write-commit account (to GCC 
MELT) for a student, intern, in France?

Regards.

PS. It may happen that the internship won't happen (for various reasons). I 
just want to settle such issues quickly as possible. 
I don't have the energy & incentive to get another assigment of copyright from 
CEA for him.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***