[wwwdocs] PATCH for Re: Gfortran annual report for 2008

[Gerald Pfeifer]

On Wed, 2 Jan 2008, Paul Thomas wrote:
> Gfortran maintainers have kept up the momentum of 2006 and the number
> of known F95 bugs has gone down sharply, the diagnostic capability
> has increased and new F2003/8 features added.

Nice report, thanks!  Like last year I add a link to this message to
the News section on our main page. :)

Gerald

Add "Gfortran annual report for 2008" to News section.  Rotate news.

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.636
diff -u -3 -p -r1.636 index.html
--- index.html  9 Dec 2007 11:01:48 -   1.636
+++ index.html  2 Jan 2008 08:20:39 -
@@ -45,6 +45,10 @@ mission statement.
 
 
 
+January 2, 2008
+http://gcc.gnu.org/ml/gcc/2008-01/msg9.html";>Gfortran
+annual report for 2008
+
 October 7, 2007
 GCC 4.2.2 has been released.
 
@@ -68,28 +72,6 @@ mission statement.
 Fortran compiler. The code was contributed by Christopher D.
 Rickett of Los Alamos National Lab.
 
-June 2, 2007
-Experimental support for the upcoming ISO C++0x standard
-been added. Enabled
-with -std=gnu++0x or -std=c++0x, this offers
-a first look at upcoming C++0x
-features and will be available in GCC 4.3. Code was
-contributed by Douglas Gregor of Indiana University, Russell
-Yanofsky, Benjamin Kosnik of Red Hat and Paolo Carlini of Novell,
-and reviewed by Jason Merrill of Red Hat and Mark Mitchell and
-Nathan Sidwell of CodeSourcery. 
-
-May 13, 2007
-GCC 4.2.0 has been released.
-
-March 9, 2007
-All m68k targets now support ColdFire processors and offer the
-choice between ColdFire and non-ColdFire libraries at configure time.
-There have been several other
-significant changes to the m68k and ColdFire support.
-This work was contributed by Nathan Sidwell of CodeSourcery
-and others.
-
 
 
 
Index: news.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v
retrieving revision 1.109
diff -u -3 -p -r1.109 news.html
--- news.html   15 Oct 2007 08:02:52 -  1.109
+++ news.html   2 Jan 2008 08:20:39 -
@@ -14,6 +14,28 @@ home page.
 
 
 
+June 2, 2007
+Experimental support for the upcoming ISO C++0x standard
+been added. Enabled
+with -std=gnu++0x or -std=c++0x, this offers
+a first look at upcoming C++0x
+features and will be available in GCC 4.3. Code was
+contributed by Douglas Gregor of Indiana University, Russell
+Yanofsky, Benjamin Kosnik of Red Hat and Paolo Carlini of Novell,
+and reviewed by Jason Merrill of Red Hat and Mark Mitchell and
+Nathan Sidwell of CodeSourcery. 
+
+May 13, 2007
+GCC 4.2.0 has been released.
+
+March 9, 2007
+All m68k targets now support ColdFire processors and offer the
+choice between ColdFire and non-ColdFire libraries at configure time.
+There have been several other
+significant changes to the m68k and ColdFire support.
+This work was contributed by Nathan Sidwell of CodeSourcery
+and others.
+
 February 13, 2007
 GCC 4.1.2 has been released.
 

Re: Status of the DLX backend for GCC?

[nkavv]

Hi Gerald

> do you have a working download location for the latter?  Right now,
> http://www.gnu.org/software/gcc/extensions.html has a broken link
> and I'd like to address this if possible.

The dlx backend was in gcc-2.7.2.3 (it is a 2.7.2.3 actually :) distribution
from this site:
http://www2.ucsc.edu/courses/cmps111-elm/dlx/tarballs/dlx-gcc.tgz

While this was a publicly available download 3 or 4 years ago (from a previous
site of the same author), it seems that the author forbids access to third
parties.

I have my own copy and if appropriate, i could upload it to my academic webpage.

> > I coded my own DLX backend for GCC.
> > If there is interest, i can submit the backend...
>
> I'm not able to approve a change like this (that's left to some others
> here), but if you'd like to put this up for download somewhere and submit
> a patch against http://www.gnu.org/software/gcc/extensions.html to give
> it more exposure, that would a very good first step!

I will submit a patch for mentioning my external location (adding DLX support to
the gcc-3.4.3/4) to the extensions.html page.


Kind regards
Nikolaos Kavvadias

Re: MPFR 2.3.1 Release Candidate

[Vincent Lefevre]

On 2008-01-02 01:06:28 -0500, Kaveh R. GHAZI wrote:
> I'll poke around some more and see if I can find something.

See the new bug fixed in r5162 (for the 2.3 branch). mpfr_gamma on
-11.5 will give you -0 instead of +0.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Optimizations documentation

[Ira Rosen]

Hi,

[EMAIL PROTECTED] wrote on 01/01/2008 22:00:11:

> some time ago I listened that GCC supports vectorization,
> but still can't find anything about it, how can I use it in my programs.

Here is the link to the vectorizer's documentation:
http://gcc.gnu.org/projects/tree-ssa/vectorization.html

Ira

Does GIMPLE tree comprise ARRAY_REF/ARRAY_REF_RANGE node

[Qing Wei]

Hi,
I find that in the function expand_expr_real_1(), which translates the
GIMPLE tree nodes to RTL.
There are codes to process the ARRAY_REF/ARRAY_REF_RANGE node. I wrote a
test program in C such like this,

void f(int s1[], int s2[], int s3[])
{
int j;

for (j = 0; j < 16; j++)
s3[j] = s1[j] + s2[j];
}

I set a breakpoint at the codes to process ARRAY_REF node in
expand_expr_real_1(), However I found that GCC never goes there. I do
find that the ARRAY_REF nodes denoting S1[j]/S2[j]/S3[j] exist in
GENERIC tree for the program. After the gimplify_expr() called, they are
lowered to other nodes? If so, why the expand_expr_real_1() handle such
nodes. What is wrong.

Qing

Re: Does GIMPLE tree comprise ARRAY_REF/ARRAY_REF_RANGE node

[Richard Guenther]

On Jan 2, 2008 3:24 PM, Qing Wei <[EMAIL PROTECTED]> wrote:
> Hi,
> I find that in the function expand_expr_real_1(), which translates the
> GIMPLE tree nodes to RTL.
> There are codes to process the ARRAY_REF/ARRAY_REF_RANGE node. I wrote a
> test program in C such like this,
>
> void f(int s1[], int s2[], int s3[])
> {
> int j;
>
> for (j = 0; j < 16; j++)
> s3[j] = s1[j] + s2[j];
> }
>
> I set a breakpoint at the codes to process ARRAY_REF node in
> expand_expr_real_1(), However I found that GCC never goes there. I do
> find that the ARRAY_REF nodes denoting S1[j]/S2[j]/S3[j] exist in
> GENERIC tree for the program. After the gimplify_expr() called, they are
> lowered to other nodes? If so, why the expand_expr_real_1() handle such
> nodes. What is wrong.

Nothing is wrong.  Try

int s1[10];
int s2[10];
int s3[10];
void f()
{
   int i;
   for (i=0; i<10; ++i)
 s1[i] = s2[i] + s3[i];
}

Richard.

Re: Optimizations documentation

[Tim Prince]

Ira Rosen wrote:

Here is the link to the vectorizer's documentation:
http://gcc.gnu.org/projects/tree-ssa/vectorization.html


  
Thanks, but I take what it says there with some grains of salt.  Yes, 
-O3 implies -ftree-vectorize on x86_64, but I seem to have to specify 
the option on other targets.  Also, I have not understood the 
limitations of -freassociative-math.
Several gcc vectorization test cases currently throw FAIL on certain 
targets, but not on others.  I don't know if that is a significant issue.
g++-4.3 seems well ahead of other compilers in ability to vectorize STL 
iterators:

http://softwarecommunity.intel.com/Wiki/HighPerformanceComputing/688.htm

Re: What is a regression?

[Mark Mitchell]

Gerald Pfeifer wrote:
> On Tue, 23 Oct 2007, Mark Mitchell wrote:
>> [...]
> 
> I realized that the documentation we currently have up at
>   http://gcc.gnu.org/bugs/management.html
> was partly incorrect (only listing P1 to P2) and certainly
> quite incomplete, so I tried to cast my understanding and
> what I found in this thread into a documentation update.
> 
> Thoughts on the patch below (which I have not committed yet)?

I think that's an appropriate patch, for now.  I've had some offline
discussions about other changes we might want to make, but let's capture
the current state.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Restricted or no run time in Ada

[Luke A. Guest]

Hi,

I got a simple hello world style multiboot kernel working again recently
and it has got me thinking about how I should be using GNAT.

Basically, I built a cross compiler for binutils and gcc to target
i386-elf (I will be wanting to play with other targets in the future,
e.g. mips-elf, arm-elf, sparc-elf, etc.). This gives me the following
toolset:

i386-elf-addr2line i386-elf-gcc   i386-elf-gprof   i386-elf-ranlib
i386-elf-ari386-elf-gcc-4.2.2 i386-elf-ld  i386-elf-readelf
i386-elf-asi386-elf-gccbugi386-elf-nm  i386-elf-size
i386-elf-c++filt   i386-elf-gcov  i386-elf-objcopy i386-elf-strings
i386-elf-cpp   i386-elf-gnatbind  i386-elf-objdump i386-elf-strip

Which is fine enough as I can compile Ada sources with gcc.

Now to get my kernel to compile I originally used pragma No_Run_Time
which is now obsolete. I heard about the Zero Foot Print configurable
runtime but couldn't get it to compile some of the source files and I
couldn't figure out why.

I then tried to use the new Ada 2005 pragma Restrictions and put the
following in my gnat.adc:

-- Basic stuff.
pragma Restrictions(No_Obsolescent_Features);
pragma Restrictions(No_Exceptions);
pragma Restrictions(No_Recursion);

-- Memory management.
pragma Restrictions(No_Allocators);
pragma Restrictions(No_Local_Allocators);
pragma Restrictions(No_Unchecked_Deallocation);
--pragma Restrictions(No_);

-- Make sure we don't have tasking or any of it's features enabled.
pragma Restrictions(Max_Tasks => 0);
pragma Restrictions(No_Protected_Types);
pragma Restrictions(No_Delay);
pragma Restrictions(No_Task_Hierarchy);
pragma Restrictions(No_Abort_Statements);
pragma Restrictions(No_Implicit_Heap_Allocations);
pragma Restrictions(No_Asynchronous_Control);

I'm sure there are more I can use, I'm not sure about that.

Now, AFAIK I'm fairly sure I don't need to use the binder as that will
create a "main" including argc, argv, etc which you don't have in a
kernel (obviously), but I'm sure there are some elaborations that aren't
being done that I *should* have.

I basically want to develop a microkernel that doesn't use the Ada
runtime as an executive, I know this is the usual route, but I don't
want to do that. An Ada runtime on top of my kernel is fine though.

So, am I going the right way about this? Or is there something else I
should be doing? Am I missing pragma's or using them wrong? Should I
really be building a minimal runtime such that I can use Ada minus
exceptions, tasking, etc?

Thanks,
Luke.

Re: What is a regression?

[Gerald Pfeifer]

On Wed, 2 Jan 2008, Mark Mitchell wrote:
> I think that's an appropriate patch, for now.  I've had some offline 
> discussions about other changes we might want to make, but let's capture 
> the current state.

Exactly.  That was my thinking. :-)  If we want to make any updates to
our processes, I'll be happy to help update the docs accordingly then.

Gerald

PATCH: PR gas/5534: "XXX PTR" isn't checked properly in Intel syntax

[H.J. Lu]

If an instruction is marked with IgnoreSize, we don't check for
memory size in Intel mode. I am checking in this patch to create
the infrastructure to handle it properly. I will fix movq first
and work on others later. Eventually, the x86 assembler will check
memory size for all instructions in Intel mode.


H.J.

gas/

2008-01-02  H.J. Lu  <[EMAIL PROTECTED]>

PR gas/5534
* config/tc-i386.c (match_template): Handle XMMWORD_MNEM_SUFFIX.
Check memory size in Intel mode.
(process_suffix): Handle XMMWORD_MNEM_SUFFIX.
(intel_e09): Likewise.

* config/tc-i386.h (XMMWORD_MNEM_SUFFIX): New.

gas/testsuite/

2008-01-02  H.J. Lu  <[EMAIL PROTECTED]>

PR gas/5534
* gas/i386/intel.s: Use QWORD on movq instead of DWORD.

* gas/i386/inval.s: Add tests for movq.
* gas/i386/x86-64-inval.s: Likewise.

* gas/i386/inval.l: Updated.
* gas/i386/x86-64-inval.l: Likewise.

opcodes/

2008-01-02  H.J. Lu  <[EMAIL PROTECTED]>

PR gas/5534
* i386-gen.c (opcode_modifiers): Add No_xSuf, CheckSize,
Byte, Word, Dword, QWord and Xmmword.

* i386-opc.h (No_xSuf): New.
(CheckSize): Likewise.
(Byte): Likewise.
(Word): Likewise.
(Dword): Likewise.
(QWord): Likewise.
(Xmmword): Likewise.
(FWait): Updated.
(i386_opcode_modifier): Add No_xSuf, CheckSize, Byte, Word,
Dword, QWord and Xmmword.

* i386-opc.tbl: Add CheckSize|QWord to movq if IgnoreSize is
used.
* i386-tbl.h: Regenerated.

--- binutils/gas/config/tc-i386.c.ptr   2007-12-31 10:53:14.0 -0800
+++ binutils/gas/config/tc-i386.c   2008-01-02 12:24:58.0 -0800
@@ -3047,6 +3047,8 @@ match_template (void)
 suffix_check.no_qsuf = 1;
   else if (i.suffix == LONG_DOUBLE_MNEM_SUFFIX)
 suffix_check.no_ldsuf = 1;
+  else if (i.suffix == XMMWORD_MNEM_SUFFIX)
+suffix_check.no_xsuf = 1;
 
   for (t = current_templates->start; t < current_templates->end; t++)
 {
@@ -3077,6 +3079,18 @@ match_template (void)
  || (t->opcode_modifier.no_ldsuf && suffix_check.no_ldsuf)))
continue;
 
+  /* Check memory size in Intel mode if needed when it is provided
+and isn't ignored.  */
+  if (intel_syntax
+ && (i.suffix || !t->opcode_modifier.ignoresize)
+ && t->opcode_modifier.checksize
+ && !((t->opcode_modifier.byte && suffix_check.no_bsuf)
+  || (t->opcode_modifier.word && suffix_check.no_wsuf)
+  || (t->opcode_modifier.dword && suffix_check.no_lsuf)
+  || (t->opcode_modifier.qword && suffix_check.no_qsuf)
+  || (t->opcode_modifier.xmmword && suffix_check.no_xsuf)))
+   continue;
+
   for (j = 0; j < MAX_OPERANDS; j++)
operand_types [j] = t->operand_types [j];
 
@@ -3453,6 +3467,11 @@ process_suffix (void)
  if (!check_word_reg ())
return 0;
}
+  else if (i.suffix == XMMWORD_MNEM_SUFFIX)
+   {
+ /* Skip if the instruction has x suffix.  match_template
+should check if it is a valid suffix.  */
+   }
   else if (intel_syntax && i.tm.opcode_modifier.ignoresize)
/* Do nothing if the instruction is going to ignore the prefix.  */
;
@@ -3535,7 +3554,9 @@ process_suffix (void)
   /* Change the opcode based on the operand size given by i.suffix;
  We don't need to change things for byte insns.  */
 
-  if (i.suffix && i.suffix != BYTE_MNEM_SUFFIX)
+  if (i.suffix
+  && i.suffix != BYTE_MNEM_SUFFIX
+  && i.suffix != XMMWORD_MNEM_SUFFIX)
 {
   /* It's not a byte, select word/dword operation.  */
   if (i.tm.opcode_modifier.w)
@@ -8166,8 +8187,7 @@ intel_e09 (void)
 
  else if (prev_token.code == T_XMMWORD)
{
- /* XXX ignored for now, but accepted since gcc uses it */
- suffix = 0;
+ suffix = XMMWORD_MNEM_SUFFIX;
}
 
  else
--- binutils/gas/config/tc-i386.h.ptr   2007-11-01 11:48:52.0 -0700
+++ binutils/gas/config/tc-i386.h   2008-01-02 10:40:23.0 -0800
@@ -116,12 +116,14 @@ extern const char *i386_comment_chars;
 #define IMMEDIATE_PREFIX '$'
 #define ABSOLUTE_PREFIX '*'
 
-/* these are the instruction mnemonic suffixes.  */
+/* these are the instruction mnemonic suffixes in AT&T syntax or
+   memory operand size in Intel syntax.  */
 #define WORD_MNEM_SUFFIX  'w'
 #define BYTE_MNEM_SUFFIX  'b'
 #define SHORT_MNEM_SUFFIX 's'
 #define LONG_MNEM_SUFFIX  'l'
 #define QWORD_MNEM_SUFFIX  'q'
+#define XMMWORD_MNEM_SUFFIX  'x'
 /* Intel Syntax.  Use a non-ascii letter since since it never appears
in instructions.  */
 #define LONG_DOUBLE_MNEM_SUFFIX '\1'
--- binutils/gas/testsuite/gas/i386/intel.s.ptr 2006-12-29 13:48:59.0 
-0800
+++ binutils/gas/testsuite/gas/i386/intel.s 2008-01-02 11:25:07.0 
-0800
@@ -601,7 +601,7 @@ rot5:
 

gcc-4.2-20080102 is now available

[gccadmin]

Snapshot gcc-4.2-20080102 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080102/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 131263

You'll find:

gcc-4.2-20080102.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080102.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080102.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080102.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080102.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080102.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080102.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080102.tar.bz2The GCC testsuite

Diffs from 4.2-20071226 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

plugin help: Inserting a function call in gimple code?

[Rob Johnson]

I'm experimenting with the gimple plugin infrastructure and I'm having 
trouble instrumenting code in a way that is compatible with the 
optimizer.  Here's a simple example that is intended to insert the 
function call "__memcheck_register_argv(argc, argv)" at the beginning of 
main.  The code runs during pass_plugin_gimple (which comes right after 
pass_apply_inline in passes.c) and works great with -O0, but causes the 
compiler to crash with -O1 or higher.


-
tree argv_registrar_type;
tree argv_registrar;
tree argv_registrar_call;

argv_registrar_type = build_function_type_list (void_type_node,
integer_type_node,
build_pointer_type
(build_pointer_type
 (char_type_node)),
NULL_TREE);
argv_registrar = build_fn_decl ("__memcheck_register_argv",
argv_registrar_type);
argv_registrar_call = build_call_expr (argv_registrar, 2,
   DECL_ARGUMENTS (cfun->decl),
   TREE_CHAIN (DECL_ARGUMENTS
   (cfun->decl)));
bsi_insert_before (&iter, argv_registrar_call, BSI_SAME_STMT);
---

With -O1, I get the compiler failure

---
test.c: In function 'main':
test.c:2: error: expected an SSA_NAME object
test.c:2: error: in statement
__memcheck_register_argv (argc, argv);
test.c:2: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


when attempting to compile the code

-
int main(int argc, char **argv)
{
  return 0;
}
-


I've tried all kinds of combinations of gimplify_stmt, update_ssa, etc., 
but I just can't figure our the "correct" way to insert a function call 
into the gimple tree.  Any help would be greatly appreciated!


Best,
Rob

GCC 4.3.0 Status Report (2008-01-02)

[Mark Mitchell]

Status
==

We are in Stage 3.  When we reach 100 open regressions, we will go to
regression-only mode.  When we approach the 4.3.0 release, we will
create a branch, and open Stage 1 for 4.4.0.

Quality Data


We have approximately zero change in the quality data over the last
month.

Priority  # Change from Last Report
--- ---
P1   31 -  2
P2   98 +  1
P35 +  1
--- ---
Total   1340

It should be noted that 9 of the PRs shown above are in WAITING state.
(Perhaps I should change the search to automatically exlcude those.)

Issues
==

Clearly, to get the numers down, we need to fix problems at a faster
rate than we're finding and/or introducing them -- or we need to
decide to downgrade some of our current regressions.

In the latest batch, I did notice several bugs with relatively exotic
options (e.g., "-fopenmp", "-ftest-coverage", and "-fmudflap".)
However, if we're going to have those features in the compiler, they
have to work -- there's no point in having a compiler with a lot of
feature checkboxes if those don't work for real code.  

I think it's perfectly reasonable todisable some of these exotic
combinations if there are ways that they can't be easily made to work;
for example, if "-fprofile-arcs -fopenmp" just isn't going happen,
then let's just sorry().  Users (or distributors) sufficiently
motivated can comment out the sorry and try it, if they really want
to, but we won't trick users into thinking that we think this ought to
work.

Most of the P1s remaining are now ICEs, not wrong-code, which is
progress.  So, I think we've moved forward a bit more than the raw
numbers might indicate.

Previous Report
===

http://gcc.gnu.org/ml/gcc/2007-11/msg00109.html

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: [RFC/RFT] Improving SMS by data dependence export

[Revital1 Eres]

Hello Alexander,

> We would like to ask people interested in SMS performance on PowerPC and

> Cell SPU to conduct tests with this patch.  Any feedback is greatly
> appreciated.

The patch passed bootstrap with -fmodulo-sched
-fmodulo-sched-allow-regmoves flags on powerpc64-linux.
I am still testing it's impact on the performance.

Revital