Re: Processing global static (or const) variables

[Richard Guenther]

On Tue, Apr 6, 2010 at 5:50 AM, Ehren Metcalfe  wrote:
> (Apologies to Richard for sending this twice -- I forgot to cc the list)
>
>> At which point during the compilation does it not work?  I suppose
>> at the point where the qualified variants are already optimized away.
>
> I've had some difficulty walking the DECL_INITIAL from within a
> separate pass but I've added this code to the execute function of
> pass_ipa_function_and_variable_visibility which should be about as
> close to pass_build_cgraph_edges as I can get. Also the
> record_references callback in cgraphbuild.c exhibits the same
> behavior.

It should work there.

> I get the same results with 4.3.4 and a recent checkout.
>
> Is there a way to disable the optimizing away of qualified variants?
> This seems to be a bug, especially with regard to
> record_references_in_initializer and record_references in
> cgraphbuild.c
>
> On Mon, Apr 5, 2010 at 10:20 AM, Richard Guenther
>  wrote:
>> On Mon, Apr 5, 2010 at 3:50 PM, Ehren Metcalfe  wrote:
>>> Hello,
>>>
>>> I'm trying to develop a dead code finder using gcc and mozilla's
>>> treehydra but I've hit a wall processing certain initializations of
>>> global variables.
>>>
>>> In order to mark a function declaration whenever its address is held
>>> in a file scope variable/table/structure I use code like this:
>>>
>>> -
>>>
>>> static tree find_funcs_callback(tree *tp, int *walk_subtrees, void *data) {
>>>  tree t = *tp;
>>>
>>>  if (TREE_CODE(t) == FUNCTION_DECL) {
>>>    // dump function
>>>  }
>>>
>>>  return NULL_TREE;
>>> }
>>>
>>> static void find_funcs(tree decl) {
>>>  walk_tree(&decl, find_funcs_callback, NULL, NULL);
>>> }
>>>
>>> // elsewhere
>>> struct varpool_node *vnode;
>>> FOR_EACH_STATIC_VARIABLE(vnode)
>>>  find_funcs(DECL_INITIAL(vnode->decl));
>>>
>>> -
>>>
>>> Unfortunately this doesn't work for code like this:
>>>
>>> -
>>>
>>> int foo() {
>>>  return 0;
>>> }
>>>
>>> typedef struct {
>>>  int (*p) ();
>>> } Table;
>>>
>>> const /* or static, or const static */ Table t[] = {
>>>  { foo }
>>> };
>>>
>>> -
>>>
>>> If I remove the qualifiers from my table the initialization is
>>> detected. Is this a bug or is there some other way of recovering the
>>> FUNCTION_DECL? It doesn't need to be modular, I just have to find a
>>> way to dump the function.
>>
>> At which point during the compilation does it not work?  I suppose
>> at the point where the qualified variants are already optimized away.
>>
>> Richard.
>>
>>> Thanks,
>>>
>>> Ehren
>>>
>>
>

lower subreg optimization

[roy rosen]

Hi,

I have encountered several problems with lower subreg optimization in my port.
In some cases I noticed that insns are decomposed in subreg1 pass and
do not get recomposed later which causes at the end using two insns
instead of one.


For example I have the following dump before subreg1

(note 30 93 31 7 [bb 7] NOTE_INSN_BASIC_BLOCK)

(insn 31 30 32 7 a.c:25 (set (reg:V4HI 112)
(mem:V4HI (reg/f:SI 98 [ __vect_p_41 ]) [2 S8 A64])) 115
{*movv4hi_load} (nil))

(insn 32 31 33 7 a.c:25 (set (reg:V4HI 113)
(mem:V4HI (reg/f:SI 99 [ __vect_p_36 ]) [2 S8 A64])) 115
{*movv4hi_load} (nil))

(insn 33 32 34 7 a.c:25 (set (subreg:V2HI (reg:V4HI 114) 0)
(plus:V2HI (subreg:V2HI (reg:V4HI 112) 0)
(subreg:V2HI (reg:V4HI 113) 0))) 118 {addv2hi3} (nil))

(insn 34 33 35 7 a.c:25 (set (subreg:V2HI (reg:V4HI 114) 4)
(plus:V2HI (subreg:V2HI (reg:V4HI 112) 4)
(subreg:V2HI (reg:V4HI 113) 4))) 118 {addv2hi3} (nil))

(insn 35 34 36 7 a.c:25 (set (reg:V4HI 114)
(vec_concat:V4HI (subreg:V2HI (reg:V4HI 114) 0)
(subreg:V2HI (reg:V4HI 114) 4))) 119 {concat_v2hi_to_v4hi}
(expr_list:REG_EQUAL (plus:V4HI (reg:V4HI 112)
(reg:V4HI 113))
(nil)))

(insn 36 35 37 7 a.c:25 (set (mem:V4HI (reg/f:SI 97 [ __vect_p_47 ]) [2 S8 A64])
(reg:V4HI 114)) 116 {*movv4hi_store} (nil))

which turns into:

(note 30 93 94 7 [bb 7] NOTE_INSN_BASIC_BLOCK)

(insn 94 30 95 7 a.c:25 (set (reg:SI 142)
(mem:SI (reg/f:SI 98 [ __vect_p_41 ]) [2 S4 A64])) 62
{movsi_load} (nil))

(insn 95 94 96 7 a.c:25 (set (reg:SI 143 [+4 ])
(mem:SI (plus:SI (reg/f:SI 98 [ __vect_p_41 ])
(const_int 4 [0x4])) [2 S4 A32])) 62 {movsi_load} (nil))

(insn 96 95 97 7 a.c:25 (set (reg:SI 144)
(mem:SI (reg/f:SI 99 [ __vect_p_36 ]) [2 S4 A64])) 62
{movsi_load} (nil))

(insn 97 96 33 7 a.c:25 (set (reg:SI 145 [+4 ])
(mem:SI (plus:SI (reg/f:SI 99 [ __vect_p_36 ])
(const_int 4 [0x4])) [2 S4 A32])) 62 {movsi_load} (nil))

(insn 33 97 34 7 a.c:25 (set (subreg:V2HI (reg:V4HI 114) 0)
(plus:V2HI (subreg:V2HI (reg:SI 142) 0)
(subreg:V2HI (reg:SI 144) 0))) 118 {addv2hi3} (nil))

(insn 34 33 35 7 a.c:25 (set (subreg:V2HI (reg:V4HI 114) 4)
(plus:V2HI (subreg:V2HI (reg:SI 143 [+4 ]) 0)
(subreg:V2HI (reg:SI 145 [+4 ]) 0))) 118 {addv2hi3} (nil))

(insn 35 34 36 7 a.c:25 (set (reg:V4HI 114)
(vec_concat:V4HI (subreg:V2HI (reg:V4HI 114) 0)
(subreg:V2HI (reg:V4HI 114) 4))) 119 {concat_v2hi_to_v4hi} (nil))

(insn 36 35 98 7 a.c:25 (set (mem:V4HI (reg/f:SI 97 [ __vect_p_47 ]) [2 S8 A64])
(reg:V4HI 114)) 116 {*movv4hi_store} (nil))

notice that now the loads are being done in SI mode which is twice
expensive than in V4HI mode.

Can someone please help with that?
Should this code be decomposed and then composed (which it doesn't) or
should it not be decoposed at the first place.
What should I change in order to get at the end a load for v4hi.
Thanks, Roy.

GCC 4.5 Branch Created

[Jakub Jelinek]

The GCC 4.5 release branch has been finally created today.

We are now in Stage 1 on the mainline.  Please go ahead and begin
checking in approved patches.  Please try to coordinate so that we do
not have multiple overlapping radical changes.  Please announce your
intent to commit a major in advance of doing so, and avoid committing
two major changes within a day of each other.

Below is the WWW docs patch that has been committed, partly by Richard
and partly by myself.

From the branching.html checklist, 1-6 and 9-12 should be done now.

--- bugzilla/contrib/bug_email.pl   15 Oct 2009 13:14:45 -  1.54
+++ bugzilla/contrib/bug_email.pl   6 Apr 2010 09:19:26 -   1.55
@@ -37,7 +37,7 @@
 #
 # You need to work with bug_email.pl the MIME::Parser installed.
 # 
-# $Id: bug_email.pl,v 1.54 2009/10/15 13:14:45 jakub Exp $
+# $Id: bug_email.pl,v 1.55 2010/04/06 09:19:26 rguenth Exp $
 ###
 
 # 02/12/2000 (SML)
@@ -284,6 +284,12 @@ sub writeBugIntoDB
 {
$version = "unknown";
 }
+elsif ($release =~ /.*4\.6\.0.*/o) {
+   $version = "4.6.0";
+}
+elsif ($release =~ /.*4\.5\.1.*/o) {
+   $version = "4.5.1";
+}
 elsif ($release =~ /.*4\.5\.0.*/o) {
$version = "4.5.0";
 }
--- htdocs/c99status.html   30 Dec 2009 17:28:47 -  1.54
+++ htdocs/c99status.html   6 Apr 2010 11:34:44 -   1.55
@@ -21,6 +21,7 @@ paragraph 6) do not count as library iss
 
 This page describes the C99 support in mainline GCC, not in any
 particular release.  Information is also available on C99 support in GCC 4.5, C99 support in GCC 4.4, C99 support in GCC 4.3, C99 support in GCC 4.2, 
 
 
 Current release series:
-  GCC 4.4.3
-  (changes)
+  GCC 4.5.0
+  (changes)
 
   Status:
-  
-  http://gcc.gnu.org/ml/gcc/2010-01/msg00397.html";>2010-01-21
-  
-  (regression fixes and docs only).
+  
+  http://gcc.gnu.org/ml/gcc/2010-03/msg00477.html";>2010-03-31
+  
+  (all changes require release-manager approval).
   
   http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.4&target_milestone=4.3.5&target_milestone=4.4.4&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
+  
href="http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.5&target_milestone=4.3.5&target_milestone=4.4.4&target_milestone=4.5.1&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
   regressions.
   http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.4&target_milestone=4.3.5&target_milestone=4.4.4&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>All
+  
href="http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.5&target_milestone=4.3.5&target_milestone=4.4.4&target_milestone=4.5.1&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssub

Bad behavior of ce1 on arm

[Sergey Grechanik]

The first if-conversion pass causes performance drop on arm. For
example on this code:

int f(int c)
{
   int z = 0;
   if( c )
   z = 0x;
   else
   z = 0x;
   return z;
}

It tries to transform the conditional code to if_then_else using the
emit_conditional_move function. But emit_conditional_move decides that
doing it directly is a bad idea (because the constants are big for arm
and movsicc cannot accept them) so it creates two additional pseudos
and moves the assignments of constants out of the block producing the
following sequence of instructions:

  45 r137:SI=0x
  46 r138:SI=0x
  47 cc:CC=cmp(r135:SI,0x0)
  48 r133:SI={(cc:CC==0x0)?r137:SI:r138:SI}

Then split2 converts if_then_else to cond_exec:

  46 r3:SI=0x
 REG_EQUIV: 0x
  52 r2:SI=0x
 REG_EQUIV: 0x
  56 cc:CC=cmp(r0:SI,0x0)
  57 (!cc:CC) r0:SI=r2:SI
  58 (cc:CC) r0:SI=r3:SI

Then the assignments of constants are converted to ldr's (or movt and
movw on cortex-a8) that will be executed unconditionally. And there is
no pass to put them back under conditional execution (and on cortex-a8
it's even harder to do since there will be two instructions for each
load of a constant).

RTL after split2 on cortex-a8:

  53 r2:SI=0x
 REG_EQUAL: 0x
  56 r3:SI=0x
 REG_EQUAL: 0x
  54 zero_extract(r2:SI,0x10,0x10)=0x
  57 zero_extract(r3:SI,0x10,0x10)=0x
  63 cc:CC=cmp(r0:SI,0x0)
  64 (!cc:CC) r0:SI=r2:SI
  65 (cc:CC) r0:SI=r3:SI

So what can we do? We can make the if-conversion pass avoid emitting
conditional moves when it results in using additional registers. But
although we know it's good on arm, we cannot say the same for other
architectures. However we can add a flag and enable it on arm by
default. Alternatively we can add some peephole optimization. (Or may
be modify some pass  to put a pair of instructions under cond_exec).
So what would be the best solution?

--
Sergey.

Re: Where can I put the optimization of got for arm back end at?

[Carrot Wei]

It is the base of GOT that is loaded once in the function prologue.
But for individual global variable's access, the address of the global
variable is loaded from GOT every time the global variable is accessed
after expand pass. For example, compile the following function with
options -Os -fpic -mthumb

extern int i;
int foo(int j)
{

  int t = i;
  i = j;
  return t;
}

After expand pass I got
...

(insn 6 4 7 2 src/./static_pic.c:5 (set (reg:SI 136)
(unspec:SI [
(const:SI (unspec:SI [
(const:SI (plus:SI (unspec:SI [
(const_int 0 [0x0])
] 21)
(const_int 4 [0x4])))
] 24))
] 3)) -1 (nil))

(insn 7 6 8 2 src/./static_pic.c:5 (set (reg:SI 136)
(unspec:SI [
(reg:SI 136)
(const_int 4 [0x4])
(const_int 0 [0x0])
] 4)) -1 (nil))

(insn 8 7 2 2 src/./static_pic.c:5 (use (reg:SI 136)) -1 (nil))

(insn 2 8 3 2 src/./static_pic.c:3 (set (reg/v:SI 135 [ j ])
(reg:SI 0 r0 [ j ])) -1 (nil))

(note 3 2 5 2 NOTE_INSN_FUNCTION_BEG)

(note 5 3 9 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 9 5 10 3 src/./static_pic.c:5 (set (reg:SI 138)
(unspec:SI [
(symbol_ref:SI ("i") [flags 0xc0]  )
] 3)) -1 (nil))

(insn 10 9 11 3 src/./static_pic.c:5 (set (reg/f:SI 137)
(mem/u/c:SI (plus:SI (reg:SI 136)
(reg:SI 138)) [0 S4 A32])) -1 (expr_list:REG_EQUAL
(symbol_ref:SI ("i") [flags 0xc0]  )
(nil)))

(insn 11 10 12 3 src/./static_pic.c:5 (set (reg/v:SI 133 [ t ])
(mem/c/i:SI (reg/f:SI 137) [2 i+0 S4 A32])) -1 (nil))

(insn 12 11 13 3 src/./static_pic.c:6 (set (reg:SI 140)
(unspec:SI [
(symbol_ref:SI ("i") [flags 0xc0]  )
] 3)) -1 (nil))

(insn 13 12 14 3 src/./static_pic.c:6 (set (reg/f:SI 139)
(mem/u/c:SI (plus:SI (reg:SI 136)
(reg:SI 140)) [0 S4 A32])) -1 (expr_list:REG_EQUAL
(symbol_ref:SI ("i") [flags 0xc0]  )
(nil)))

(insn 14 13 15 3 src/./static_pic.c:6 (set (mem/c/i:SI (reg/f:SI 139)
[2 i+0 S4 A32])
(reg/v:SI 135 [ j ])) -1 (nil))

(insn 15 14 16 3 src/./static_pic.c:6 (set (reg:SI 134 [  ])
(reg/v:SI 133 [ t ])) -1 (nil))

...

Insn 9 and 10 load the address of global variable i for the first
access. Insn 12 and 13 load the address of i for the second access.

After cse1 pass I got

(insn 6 4 7 2 src/./static_pic.c:5 (set (reg:SI 136)
(unspec:SI [
(const:SI (unspec:SI [
(const:SI (plus:SI (unspec:SI [
(const_int 0 [0x0])
] 21)
(const_int 4 [0x4])))
] 24))
] 3)) 169 {pic_load_addr_thumb1} (nil))

(insn 7 6 8 2 src/./static_pic.c:5 (set (reg:SI 136)
(unspec:SI [
(reg:SI 136)
(const_int 4 [0x4])
(const_int 0 [0x0])
] 4)) 170 {pic_add_dot_plus_four} (nil))

(insn 8 7 2 2 src/./static_pic.c:5 (use (reg:SI 136)) -1 (nil))

(insn 2 8 3 2 src/./static_pic.c:3 (set (reg/v:SI 135 [ j ])
(reg:SI 0 r0 [ j ])) 167 {*thumb1_movsi_insn} (nil))

(note 3 2 9 2 NOTE_INSN_FUNCTION_BEG)

(insn 9 3 10 2 src/./static_pic.c:5 (set (reg:SI 138)
(unspec:SI [
(symbol_ref:SI ("i") [flags 0xc0]  )
] 3)) 169 {pic_load_addr_thumb1} (nil))

(insn 10 9 11 2 src/./static_pic.c:5 (set (reg/f:SI 137)
(mem/u/c:SI (plus:SI (reg:SI 136)
(reg:SI 138)) [0 S4 A32])) 167 {*thumb1_movsi_insn}
(expr_list:REG_EQUAL (symbol_ref:SI ("i") [flags 0xc0]  )
(nil)))

(insn 11 10 12 2 src/./static_pic.c:5 (set (reg/v:SI 133 [ t ])
(mem/c/i:SI (reg/f:SI 137) [2 i+0 S4 A32])) 167
{*thumb1_movsi_insn} (nil))

(insn 12 11 13 2 src/./static_pic.c:6 (set (reg:SI 140)
(reg:SI 138)) 167 {*thumb1_movsi_insn} (nil))

(insn 13 12 14 2 src/./static_pic.c:6 (set (reg/f:SI 139)
(reg/f:SI 137)) 167 {*thumb1_movsi_insn} (expr_list:REG_EQUAL
(symbol_ref:SI ("i") [flags 0xc0]  )
(nil)))

(insn 14 13 15 2 src/./static_pic.c:6 (set (mem/c/i:SI (reg/f:SI 137)
[2 i+0 S4 A32])
(reg/v:SI 135 [ j ])) 167 {*thumb1_movsi_insn} (nil))

(insn 15 14 19 2 src/./static_pic.c:6 (set (reg:SI 134 [  ])
(reg/v:SI 133 [ t ])) 167 {*thumb1_movsi_insn} (nil))

(insn 19 15 22 2 src/./static_pic.c:8 (set (reg/i:SI 0 r0)
(reg/v:SI 133 [ t ])) 167 {*thumb1_movsi_insn} (nil))

Now the address of global variable i is loaded once by insn 9 and 10.
The later access of i (insn 13) reuse the result of insn 10 (reg 137).

So we'd better do it after some cse/gcse passes.

On Mon, Apr 5, 2010 at 9:24 PM, Paul Yuan  wrote:
> I remember that the GOT address is loaded only once in the function
> prologue. 

Re: GCC 4.5 Branch Created

[Kirill A. Shutemov]

On Tue, Apr 6, 2010 at 3:16 PM, Jakub Jelinek  wrote:
> The GCC 4.5 release branch has been finally created today.

Please, add gcc-4_5-branch to git mirror.

GCC 4.5.0 release candidate available

[Richard Guenther]

A GCC 4.5.0 release candidate is available at:

ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.0-RC-20100406/

Please test the tarballs and report any problems to Bugzilla.
CC me on the bugs if you believe they are regressions from
previous releases severe enough to block the 4.5.0 release.

Thanks,
Richard.

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: GCC 4.5 Branch Created

[Jason Merrill]

On 04/06/2010 09:39 AM, Kirill A. Shutemov wrote:

On Tue, Apr 6, 2010 at 3:16 PM, Jakub Jelinek  wrote:

The GCC 4.5 release branch has been finally created today.


Please, add gcc-4_5-branch to git mirror.


Done.

Jason

Re: VTA/debugging vs reload-v2

[Jeff Law]

On 04/06/10 00:35, Jakub Jelinek wrote:

On Mon, Apr 05, 2010 at 05:18:35PM -0600, Jeff Law wrote:
   

2. When renaming references from P to P' in a region, do take debug
insns in the region into account, renaming references in debug insns as
you would in any other insn.

   

OK.  So presumably the 2nd argument in a VAR_LOCATION can be any rtl
expression?  Meaning I have to parse it looking for things that need
changing?Right?
 

   The problematic stuff is mainly when some RTL
with non-VOIDmode (REG, MEM etc.) needs to be replaced with a VOIDmode
constant - in that case simplify_replace_{,fn_}rtx needs to be used to
change the invalid RTL into valid.

These shouldn't be a problem.



But I guess for reload2 you'll be
changing just REGs and MEMs to other REGs and MEMs - in that case
just a replacement through say for_each_rtx is possible too.
   
Yea, we're going to have to walk down the expression with for_each_rtx 
searching for REGs, then see if the REG we found needs replacing.  
Handling narrowing SUBREGs makes this marginally more complex, but it's 
still manageable.  I just wanted to be sure there that there weren't any 
assumptions I could make to simplify the code :-)


jeff

Re: VTA/debugging vs reload-v2

[Jakub Jelinek]

On Tue, Apr 06, 2010 at 09:23:09AM -0600, Jeff Law wrote:
>> But I guess for reload2 you'll be
>> changing just REGs and MEMs to other REGs and MEMs - in that case
>> just a replacement through say for_each_rtx is possible too.
>>
> Yea, we're going to have to walk down the expression with for_each_rtx  
> searching for REGs, then see if the REG we found needs replacing.   
> Handling narrowing SUBREGs makes this marginally more complex, but it's  
> still manageable.  I just wanted to be sure there that there weren't any  
> assumptions I could make to simplify the code :-)

As soon as you start doing simplifications, I'd say simplify_replace_fn_rtx
is the way to go.  In its current implementation, the callback is called on
each of the rtxs like with for_each_rtx.  Whenever you need to replace
something, you just return the replacement, otherwise return NULL meaning
no changes are needed.  The result is gong to be simplified only
when some argument of a rtx has actually changed.

Jakub

Re: RFC: c++ diagnostics

[Chris Lattner]

On Apr 5, 2010, at 8:20 AM, Benjamin Kosnik wrote:

> 
> Hello all! 
> 
> I've put up a short diagnostics comparison between gcc, icc, and
> clang. It is my plan to update this with major revisions to individual
> compilers. 
> 
> Included are most of the outstanding bugzilla requests with the
> "diagnostic" keyword. However, I am looking for help! Please send me
> code samples that frustrate, obfuscate, and annoy. 
> 
> In particular, I am looking for template instantiation issues such as
> c++/41884, but hopefully something in a deliciously small snippet. No
> doubt other C++ hackers have particular annoyances.
> 

Hi Benjamin,

I wrote a little blog post that shows off some of the things that Clang can do. 
 It would be great to improve some of GCC/G++'s diagnostics in a similar way:

http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

-Chris

Re: RFC: c++ diagnostics

[Joe Buck]

On Tue, Apr 06, 2010 at 09:00:16AM -0700, Chris Lattner wrote:
> I wrote a little blog post that shows off some of the things that Clang can 
> do.  It would be great to improve some of GCC/G++'s diagnostics in a similar 
> way:
> 
> http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

Some of Chris's examples appear to be regressions, in that gcc's old
bison-based parser did a better job than the current parser.  In
particular, around the time of the 2->3 transition, a rule was added to
catch the fact that

foo bar;

where neither is defined as a type, almost certainly is because of a
missing definition of the type foo, or a mis-spelling (this is what is
going on in several of Chris's examples).  I pushed to get that rule
added because I tried a lot of "C++" code that had only been compiled
with g++ 2.9x, and it was filled with uses of STL without std:: because
back then, the standard library wasn't in a namespace and std:: was
magic that was ignored.

Re: GCC 4.5.0 release candidate available

[Jack Howarth]

On Tue, Apr 06, 2010 at 03:45:27PM +0200, Richard Guenther wrote:
> 
> A GCC 4.5.0 release candidate is available at:
> 
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.0-RC-20100406/
> 
> Please test the tarballs and report any problems to Bugzilla.
> CC me on the bugs if you believe they are regressions from
> previous releases severe enough to block the 4.5.0 release.
> 
> Thanks,
> Richard.
> 
> -- 
> Richard Guenther 
> Novell / SUSE Labs
> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus 
> Rex
> 

Richard,
   Any chance we can get r157822 reapplied on gcc 4.5 branch 
along with...

http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html

to fix emutls? As can be seen from the testsuite run on
x86_64-apple-darwin10...

http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00444.html

when all the "dg-require-effective-target tls_native" tests
are converted to "dg-require-effective-target tls", we only
see failures in...

FAIL: gcc.dg/tls/opt-4.c scan-assembler tcc1@
FAIL: gcc.dg/tls/opt-4.c scan-assembler tcc2@
FAIL: gcc.dg/tls/opt-4.c scan-assembler-not tcc...@]
FAIL: gcc.dg/tls/opt-4.c scan-assembler-not tcc...@]
FAIL: gcc.dg/tls/section-1.c conflict with user-defined section (test for 
errors, line 12)

at -m32 and...

FAIL: gcc.dg/tls/section-1.c conflict with user-defined section (test for 
errors, line 12)

at -m64. Iain thinks the gcc.dg/tls/opt-4.c failures are expected
but the gcc.dg/tls/section-1.c failure might be showing up a
previously unknown bug in emutls.
Jack

Re: RFC: c++ diagnostics

[Manuel López-Ibáñez]

On 6 April 2010 18:00, Chris Lattner  wrote:
>
> On Apr 5, 2010, at 8:20 AM, Benjamin Kosnik wrote:
>
>>
>> Hello all!
>>
>> I've put up a short diagnostics comparison between gcc, icc, and
>> clang. It is my plan to update this with major revisions to individual
>> compilers.
>>
>> Included are most of the outstanding bugzilla requests with the
>> "diagnostic" keyword. However, I am looking for help! Please send me
>> code samples that frustrate, obfuscate, and annoy.
>>
>> In particular, I am looking for template instantiation issues such as
>> c++/41884, but hopefully something in a deliciously small snippet. No
>> doubt other C++ hackers have particular annoyances.
>>
>
> Hi Benjamin,
>
> I wrote a little blog post that shows off some of the things that Clang can 
> do.  It would be great to improve some of GCC/G++'s diagnostics in a similar 
> way:
>
> http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

Unfortunately, you mix C and C++ examples. I know it is because clang
parses both with the same parser but this thread is only discussing
improving C++ diagnostics in GCC, and there is no plan or project for
C diagnostics. As it happens, some C++ diagnostics are better than the
same diagnostic for C and viceversa.

I love the merge conflict detector, btw. :-)  If I am allowed, I would
like to implement that one in C/C++ parsers. Joseph? Jason?

Cheers,

Manuel.

Re: lower subreg optimization

[Jim Wilson]

On 04/06/2010 02:24 AM, roy rosen wrote:

(insn 33 32 34 7 a.c:25 (set (subreg:V2HI (reg:V4HI 114) 0)
 (plus:V2HI (subreg:V2HI (reg:V4HI 112) 0)
 (subreg:V2HI (reg:V4HI 113) 0))) 118 {addv2hi3} (nil))


Only subregs are decomposed.  So use vec_select instead of subreg.  I 
see you already have a vec_concat to combine the two v2hi into one v4hi, 
so there is no need for the subreg in the dest.  You should try 
eliminating that first and see if that helps.  If that isn't enough, 
then replace the subregs in the source with vec_select operations.


Jim

Re: RFC: c++ diagnostics

[Chris Lattner]

On Apr 6, 2010, at 9:29 AM, Manuel López-Ibáñez wrote:
>> Hi Benjamin,
>> 
>> I wrote a little blog post that shows off some of the things that Clang can 
>> do.  It would be great to improve some of GCC/G++'s diagnostics in a similar 
>> way:
>> 
>> http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
> 
> Unfortunately, you mix C and C++ examples. I know it is because clang
> parses both with the same parser but this thread is only discussing
> improving C++ diagnostics in GCC, and there is no plan or project for
> C diagnostics. As it happens, some C++ diagnostics are better than the
> same diagnostic for C and viceversa.

I think all the C examples are also valid C++ code, they should apply equally 
well, but I admit that I didn't try those on g++ to see how it does.  I figured 
it also didn't matter much because there has surely been significant progress 
since gcc 4.2.

-Chris

Re: Help with an Wierd Error

[Jim Wilson]

On 04/02/2010 11:02 AM, balaji.i...@gtri.gatech.edu wrote:

/opt/or32/lib/gcc/or32-elf/4.2.2/../../../../or32-elf/lib/crt0.o: In function 
`loop':
(.text+0x64): undefined reference to `___bss_start'


It looks like a case of one-too-many underscores prepended to symbol 
names.  The default for ELF is to not prepend an underscore.  The 
default for COFF is to prepend an underscore.  Check USER_LABEL_PREFIX 
which should be empty for ELF (default definition in defaults.h file). 
Check ASM_OUTPUT_LABELREF which should use %U and not an explicit 
underscore (see defaults.h file).  Check for usage of the 
-fleading-underscores option (should not be used).  Check for header 
file inclusion to see if something is out of place, such as a use of 
svr3.h when svr4.h should be used.


Also check to make sure that gcc, gas, and gld all agree on whether a 
symbol is prepended with an underscore or not.  If gcc does it but gas 
doesn't, then C code calling assembly language code may fail because of 
the mismatch.


Jim

Re: lower subreg optimization

[Ian Lance Taylor]

roy rosen  writes:

> I have encountered several problems with lower subreg optimization in my port.
> In some cases I noticed that insns are decomposed in subreg1 pass and
> do not get recomposed later which causes at the end using two insns
> instead of one.

In the code the register is always accessed via a subreg, so the
lower-subregs pass thinks that it is OK to decompose the register.
Once it is decomposed, nothing is expected to put it back together.

To fix this, you should probably look at simple_move in
lower-subreg.c.  You will want it to return NULL_RTX for a vector load
or store.  Perhaps it should check costs, or perhaps it should never
decompose explicit vector modes.

Ian

Re: lower subreg optimization

[Nathan Froyd]

On Tue, Apr 06, 2010 at 09:58:23AM -0700, Ian Lance Taylor wrote:
> In the code the register is always accessed via a subreg, so the
> lower-subregs pass thinks that it is OK to decompose the register.
> Once it is decomposed, nothing is expected to put it back together.
> 
> To fix this, you should probably look at simple_move in
> lower-subreg.c.  You will want it to return NULL_RTX for a vector load
> or store.  Perhaps it should check costs, or perhaps it should never
> decompose explicit vector modes.

Compiling anything that uses doubles on powerpc e500v2 produces awful
code due in part to lower-subregs (the register allocator doesn't help,
either, but that's a different story).  Code that looks like:

  rY:DI = r:DI
  rX:DI = rY:DI
  (subreg:DF rZ:DI 0) = rX:DI

 is a hard register for argument passing; the code looks equally
awful inside of a function, too.  The above gets lowered to:

1:  r:SI = r:SI
2:  r:SI = r:SI
3:  (subreg:SI rX:DI 0) = r:SI
4:  (subreg:SI rX:DI 4) = r:SI
5:  (subreg:DF rZ:DI 0) = rX:DI

which usually results in two stores and a load against the stack, rather
than a single-instruction dealing entirely in registers.  I realize
e500v2 is not exactly a mainstream target, but perhaps a target hook is
appropriate here?  I suppose checking costs might achieve the same
thing.

-Nathan

Re: lower subreg optimization

[Steven Bosscher]

On Tue, Apr 6, 2010 at 7:12 PM, Nathan Froyd  wrote:
> I realize
> e500v2 is not exactly a mainstream target, but perhaps a target hook is
> appropriate here

Big hammer. Preferred tool for jobs in the real world.

>  I suppose checking costs might achieve the same
> thing.

Small hammer. Preferred tool for jobs in the GCC world.

I suppose the trouble will be that rtx_cost is not going to be
accurate enough for the job...

Ciao!
Steven

Re: Bootstrap failures on i386-pc-solaris2.10

[Rainer Orth]

Arthur Haas  writes:

> I'll update my repo shortly and replace the '--with-arch' and '--with-tune' 
> arguments as you suggest. As for the '--disable-libstdcxx-pch'
> argument, I had build problems months ago and this argument fixed the 
> problem, although now looking at the configure script for libstdc
> it looks like the correct argument should be '--enable-libstdcxx-pch=no' if 
> it is to be used. The '--enable-threads' argument is another configuration 
> option I added long ago as well. The script which configures and starts my 
> GCC builds needs some cleanup ...

No, --enable-=no and --disable- should be equivalent
everywhere, even if only one form is documented.

True: one you have something that works, you seldom revisit it ;-)

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Bad behavior of ce1 on arm

[Eric Botcazou]

> So what can we do? We can make the if-conversion pass avoid emitting
> conditional moves when it results in using additional registers. But
> although we know it's good on arm, we cannot say the same for other
> architectures. However we can add a flag and enable it on arm by
> default.

Ideally this should be parameterized purely by insn costs.

-- 
Eric Botcazou

Re: lower subreg optimization

[Ian Lance Taylor]

Nathan Froyd  writes:

> Compiling anything that uses doubles on powerpc e500v2 produces awful
> code due in part to lower-subregs (the register allocator doesn't help,
> either, but that's a different story).  Code that looks like:
>
>   rY:DI = r:DI
>   rX:DI = rY:DI
>   (subreg:DF rZ:DI 0) = rX:DI
>
>  is a hard register for argument passing; the code looks equally
> awful inside of a function, too.  The above gets lowered to:
>
> 1:  r:SI = r:SI
> 2:  r:SI = r:SI
> 3:  (subreg:SI rX:DI 0) = r:SI
> 4:  (subreg:SI rX:DI 4) = r:SI
> 5:  (subreg:DF rZ:DI 0) = rX:DI
>
> which usually results in two stores and a load against the stack, rather
> than a single-instruction dealing entirely in registers.  I realize
> e500v2 is not exactly a mainstream target, but perhaps a target hook is
> appropriate here?  I suppose checking costs might achieve the same
> thing.

I doubt that a target hook is required to avoid this.  Perhaps
simple_move_operand should reject a mode changing subreg when the two
modes are !MODE_TIEABLE_P.

This code is sort of weird, though; why the conversion from DImode to
DFmode?

Ian

Re: GCC 4.5.0 release candidate available

[Jerome Quinn]

I just downloaded the 20100406 snapshot and tried to build, however,
could not get cloog-ppl to build.  I know it's not mandatory, but
there's an issue here.

I pulled down both ppl and cloog-ppl from the same location as the
snapshot, so ppl-0.10.2 and cloog-ppl-0.15.9.  On a Centos 5.4 x86_64
system, I built ppl and installed it in a custom location.  This is
gcc 4.1.2-46.

./configure --prefix=/scratch/usr

Then I configured cloog-ppl:

./configure --with-ppl=/scratch/usr
make
...
make[1]: Entering directory `/scratch/usr/jlquinn/cloog-
ppl-0.15.9'
/bin/sh ./libtool --tag=CC --mode=link gcc -Wall -fomit-frame-pointer
-g -O2  -L/scratch/usr/lib  -o cloog  cloog.o libcloog.la -lgmp
-lppl_c -lppl -lgmpxx
libtool: link: gcc -Wall -fomit-frame-pointer -g -O2 -o .libs/cloog
cloog.o  -L/scratch/usr/lib ./.libs/libcloog.so
/scratch/usr/lib/libppl_c.so /scratch/usr/lib/libppl.so -lgmp -lgmpxx
-Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/scratch/usr/lib
./.libs/libcloog.so: undefined reference to `mp_get_memory_functions'
collect2: ld returned 1 exit status
make[1]: *** [cloog] Error 1

Am I missing something here?  The gcc install docs imply there's
nothing special needed to build these two items.  If there is, we
should probably include that.

Thanks,
Jerry

Re: RFC: c++ diagnostics

[Joe Buck]

> >> http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
> > 
> > ...As it happens, some C++ diagnostics are better than the
> > same diagnostic for C and viceversa.

On Tue, Apr 06, 2010 at 09:45:11AM -0700, Chris Lattner wrote:
> I think all the C examples are also valid C++ code, they should apply equally 
> well, but I admit that I didn't try those on g++ to see how it does.  I 
> figured it also didn't matter much because there has surely been significant 
> progress since gcc 4.2.

Yes, g++ does a better job for some of Chris's examples than gcc does.

For the second example we get

t.c:1: error: 'pid_t' has not been declared

For the third example:
t.c:2: error: 'int64' does not name a type

However, most of the criticisms do apply, and the spell checker is a
very good idea.

Re: lower subreg optimization

[Nathan Froyd]

On Tue, Apr 06, 2010 at 11:55:01AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd  writes:
> > Compiling anything that uses doubles on powerpc e500v2 produces awful
> > code due in part to lower-subregs (the register allocator doesn't help,
> > either, but that's a different story).
> 
> I doubt that a target hook is required to avoid this.  Perhaps
> simple_move_operand should reject a mode changing subreg when the two
> modes are !MODE_TIEABLE_P.

Ah, thanks for the pointer. I'll try poking at that.

> This code is sort of weird, though; why the conversion from DImode to
> DFmode?

Welcome to the wonderful world of e500, which has floating-point
instructions operating on the general purpose registers.

-Nathan

Re: lower subreg optimization

[Joseph S. Myers]

On Tue, 6 Apr 2010, Ian Lance Taylor wrote:

> This code is sort of weird, though; why the conversion from DImode to
> DFmode?

See  for 
discussion of the e500 subregs and their semantics.  I made them work 
reliably (for 4.3 and later, 4.4 and later when decimal floating-point 
modes are involved) - but not necessarily efficiently in all cases.

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

Re: GCC 4.5.0 release candidate available

[Marc Glisse]

On Tue, 6 Apr 2010, Jerome Quinn wrote:


undefined reference to `mp_get_memory_functions'


This means your version of GMP is too old. configure should probably catch 
this.


--
Marc Glisse

Re: GCC 4.5.0 release candidate available

[Jerome Quinn]

On Tue, Apr 6, 2010 at 3:29 PM, Marc Glisse
 wrote:
> On Tue, 6 Apr 2010, Jerome Quinn wrote:
>
>> undefined reference to `mp_get_memory_functions'
>
> This means your version of GMP is too old. configure should probably catch
> this.

What is the minimum gmp for cloog-ppl?  Is it the same as for gcc?  My
system gmp is too old for gcc so I've got gmp 4.3.2 placed in the gcc
source tree per the instructions.  It would be nice to have cloog use
the gmp that will be built as part of the gcc bootstrap.

Is there a clean way of making that happen?  If not, the gcc docs
should probably mention that this is an issue and how to work around
it - i.e. build gmp and install rather than making it part of the gcc
build.

thanks,
Jerry

Re: GCC 4.5.0 release candidate available

[Jonathan Wakely]

On 6 April 2010 21:10, Jerome Quinn wrote:
>
> What is the minimum gmp for cloog-ppl?  Is it the same as for gcc?  My
> system gmp is too old for gcc so I've got gmp 4.3.2 placed in the gcc
> source tree per the instructions.  It would be nice to have cloog use
> the gmp that will be built as part of the gcc bootstrap.
>
> Is there a clean way of making that happen?

Can't you just put the cloog sources in-tree as well?

Re: RFC: c++ diagnostics

[Laurent GUERBY]

On Tue, 2010-04-06 at 12:02 -0700, Joe Buck wrote:
> > >> http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
> > > 
> > > ...As it happens, some C++ diagnostics are better than the
> > > same diagnostic for C and viceversa.
> 
> On Tue, Apr 06, 2010 at 09:45:11AM -0700, Chris Lattner wrote:
> > I think all the C examples are also valid C++ code, they should apply 
> > equally well, but I admit that I didn't try those on g++ to see how it 
> > does.  I figured it also didn't matter much because there has surely been 
> > significant progress since gcc 4.2.
> 
> Yes, g++ does a better job for some of Chris's examples than gcc does.
> 
> For the second example we get
> 
> t.c:1: error: 'pid_t' has not been declared
> 
> For the third example:
> t.c:2: error: 'int64' does not name a type
> 
> However, most of the criticisms do apply, and the spell checker is a
> very good idea.

The Ada FE does it FWIW:

$ cat p.ads
pakage P is
  subtype My_Count is Intger
end P;
$ gcc -c -gnatq p.ads
p.ads:1:01: incorrect spelling of keyword "package"
p.ads:2:23: "Intger" is undefined
p.ads:2:23: possible misspelling of "Integer"
p.ads:2:29: missing ";"
$

The checker is in gcc/ada/g-spchge.adb

Laurent

Re: GCC 4.5.0 release candidate available

[Jerome Quinn]

On Tue, Apr 6, 2010 at 4:27 PM, Jonathan Wakely  wrote:
>> source tree per the instructions.  It would be nice to have cloog use
>> the gmp that will be built as part of the gcc bootstrap.
>>
>> Is there a clean way of making that happen?
>
> Can't you just put the cloog sources in-tree as well?

The install docs don't mention that possibility.  The last time I
tried to build with cloog, I think it wasn't supported in-tree.  I'll
try again...

Re: GCC 4.5.0 release candidate available

[Jonathan Wakely]

On 6 April 2010 22:02, Jerome Quinn wrote:
> On Tue, Apr 6, 2010 at 4:27 PM, Jonathan Wakely  wrote:
>>> source tree per the instructions.  It would be nice to have cloog use
>>> the gmp that will be built as part of the gcc bootstrap.
>>>
>>> Is there a clean way of making that happen?
>>
>> Can't you just put the cloog sources in-tree as well?
>
> The install docs don't mention that possibility.  The last time I
> tried to build with cloog, I think it wasn't supported in-tree.  I'll
> try again...

I think it works as long as the directory is called "cloog" not "cloog-ppl"

I don't see any other way to get cloog to use a gmp you haven't built yet.

Re: GCC 4.5.0 release candidate available

[Jerome Quinn]

On Tue, Apr 6, 2010 at 5:11 PM, Jonathan Wakely  wrote:
> On 6 April 2010 22:02, Jerome Quinn wrote:

>>>> Is there a clean way of making that happen?
>>>
>>> Can't you just put the cloog sources in-tree as well?
>>
>> The install docs don't mention that possibility.  The last time I
>> tried to build with cloog, I think it wasn't supported in-tree.  I'll
>> try again...
>
> I think it works as long as the directory is called "cloog" not "cloog-ppl"
>
> I don't see any other way to get cloog to use a gmp you haven't built yet.

If I try this the build still fails.  It's not picking up the ppl that is
in the gcc source tree.  The ppl dir is named ppl and the cloog dir is
named cloog.

It appears to be ignoring the ppl in the gcc source tree...


checking for sys/resource.h... yes
polylibgmp
Package gmp-include :
/scratch/usr/jlquinn/gcc-4.5.0-RC-20100406/host-x86_64-unknown-linux-gnu/gmp
Package gmp-library :
/scratch/usr/jlquinn/gcc-4.5.0-RC-20100406/host-x86_64-unknown-linux-gnu/gmp/.libs
checking whether gmp works... checking gmp.h usability... yes
checking gmp.h presence... yes
checking for gmp.h... yes
checking for __gmpz_init in -lgmp... yes
yes
checking for location of PolyLib... installed in standard location
checking for PolyhedronTSort in -lpolylibgmp... no
Can't find PolyLib.
checking for Parma Polyhedral Library (PPL)... installed at system prefix
checking ppl_c.h usability... no
checking ppl_c.h presence... no
checking for ppl_c.h... no
configure: error: Can't find PPL headers.
make[2]: *** [configure-stage1-cloog] Error 1
make[2]: Leaving directory `/scratch/usr/jlquinn/gcc-4.5.0-RC-20100406'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/scratch/usr/jlquinn/gcc-4.5.0-RC-20100406'
make: *** [all] Error 2

gcc-4.4-20100406 is now available

[gccadmin]

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

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

You'll find:

gcc-4.4-20100406.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20100406.tar.bz2 C front end and core compiler

gcc-ada-4.4-20100406.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20100406.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20100406.tar.bz2  C++ front end and runtime

gcc-java-4.4-20100406.tar.bz2 Java front end and runtime

gcc-objc-4.4-20100406.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20100406.tar.bz2The GCC testsuite

Diffs from 4.4-20100330 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.

Re: RFC: c++ diagnostics

[Robert Dewar]

Laurent GUERBY wrote:

On Tue, 2010-04-06 at 12:02 -0700, Joe Buck wrote:

http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

...As it happens, some C++ diagnostics are better than the
same diagnostic for C and viceversa.

On Tue, Apr 06, 2010 at 09:45:11AM -0700, Chris Lattner wrote:

I think all the C examples are also valid C++ code, they should apply equally 
well, but I admit that I didn't try those on g++ to see how it does.  I figured 
it also didn't matter much because there has surely been significant progress 
since gcc 4.2.

Yes, g++ does a better job for some of Chris's examples than gcc does.

For the second example we get

t.c:1: error: 'pid_t' has not been declared

For the third example:
t.c:2: error: 'int64' does not name a type

However, most of the criticisms do apply, and the spell checker is a
very good idea.


The Ada FE does it FWIW:

$ cat p.ads
pakage P is
  subtype My_Count is Intger
end P;
$ gcc -c -gnatq p.ads
p.ads:1:01: incorrect spelling of keyword "package"
p.ads:2:23: "Intger" is undefined
p.ads:2:23: possible misspelling of "Integer"
p.ads:2:29: missing ";"


The algorithm used in the Ada compiler is in
g-speche.ads and it seems to be just right for
use by the compiler.

$

The checker is in gcc/ada/g-spchge.adb

Laurent

why mult generated for unsigned int multiply on mips?

[Amker.Cheng]

Hi :
  I noticed that on mips, the signed form instruction of multiply is
generated for
unsigned integer multiply operation.
for example, mult is used, rather than multu for following codes:

unsigned int x, y, z;
x = y * z;

Is it reasonable to do so? Thanks.
-- 
Best Regards.