Re: GCC 4.1: Buildable on GHz machines only?

[Gabriel Dos Reis]

Ranjit Mathew <[EMAIL PROTECTED]> writes:

[...]

| PS: Surely this must be one of the longest threads in
| recent times on the GCC list!

:-)

| PPS: I do not see some of the messages, for example, a
| couple of messages from Robert Dewar that seem to be
| referenced in other messages.

same here.

-- Gaby

Re: GCC 4.1: Buildable on GHz machines only?

[Richard Sandiford]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> For example, "Results for 4.1.020050506(experimental) testsuite on 
> mips64-unknown-elf" with the components of the version number all run 
> together
> [...]
> Ensuring your test results 
> use the standard Subject header format makes it more likely they can 
> handled properly by sites processing the gcc-testresults postings into 
> databases of GCC test status on different targets (such as 
>  but other sites have 
> done this sort of thing before and may do so in future).

FWIW, those mips messages _were_ sent with test_summary.  I'm not
sure why they got mangled.  Are there any known issues that would
cause that?

Richard

genmddeps s390 bootstrap failure

[Andreas Krebbel]

Hi,

mainline bootstrap on s390 currently fails with:

build/genmddeps ../../gcc/config/s390/s390.md > tmp-mddeps
../../gcc/config/s390/s390.md:2041: undefined attribute 'DBL' used for mode
../../gcc/config/s390/s390.md:2041: following context is `'

DBL is a macro attribute defined as:

(define_mode_attr DBL [(DI "TI") (SI "DI")])

The pattern in question is:

(define_insn "*clrmem_long"
  [(clobber (match_operand: 0 "register_operand" "=d"))
   (set (mem:BLK (subreg:P (match_operand: 2 "register_operand" "0") 0))
(const_int 0))
   (use (match_dup 2))
   (use (match_operand: 1 "register_operand" "d"))
   (clobber (reg:CC CC_REGNUM))]
  ""
  "mvcle\t%0,%1,0\;jo\t.-4"
  [(set_attr "length" "8")
   (set_attr "type" "vs")])

I think the problem lies in genmddeps. genmddeps seems to randomly complain 
about
uses of the DBL attribute. Always with an again randomly appended character at 
the
end of the macro name in the error message.

At first glance it appears like a string null termination problem so I've added:

Index: gcc/read-rtl.c
===
RCS file: /cvs/gcc/gcc/gcc/read-rtl.c,v
retrieving revision 1.38
diff -p -c -r1.38 read-rtl.c
*** gcc/read-rtl.c  17 May 2005 12:50:32 -  1.38
--- gcc/read-rtl.c  18 May 2005 08:00:47 -
*** mode_attr_index (struct map_value **mode
*** 323,328 
--- 323,330 
obstack_grow (&string_obstack, string + 1, strlen (string) - 2);
p = (char *) obstack_finish (&string_obstack);

+   p[strlen (string) - 2] = 0;
+
mv = XNEW (struct map_value);
mv->number = *mode_maps == 0 ? 0 : (*mode_maps)->number + 1;
mv->string = p;


... which takes s390 back to bootstrap land. This is probably not the proper fix
but it maybe helps debugging that issue.

Any ideas what goes wrong here?!

Bye,

-Andreas-

Re: GCC 3.4.4

[Jonathan Wakely]

On Tue, May 17, 2005 at 02:11:24PM -0700, Mark Mitchell wrote:

> Jonathan Wakely wrote:
> >On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:
> >
> >
> >>I've very nearly ready to release GCC 3.4.4.  If you have objections or 
> >>high-priority fixes that you think will be required for this release, 
> >>please speak up within the next 24 hours.
> >
> >
> >Sorry for the last minute mail ...
> >
> >It occurs to me that although we're not fixing this in 3.4.4
> >
> >http://gcc.gnu.org/ml/libstdc++/2005-05/msg00105.html
> >
> >we could document it, which would be a safe change:
> 
> Great idea!  Go ahead, please.

Oops, I meant to send this to the libstdc++ list, sorry for that.

jon

Re: GCC 4.1: Buildable on GHz machines only?

[Richard Earnshaw]

On Tue, 2005-05-17 at 21:03, Paul Brook wrote:
[building of gfortran]
> It does require gmp/mpfr on the host, but in most cases the host is native, 
> and they are dead easy to cross compile anyway.

And it's long been my contention that we shouldn't even be doing that.  

I still feel these packages should be brought in-tree, especially since
specific minimum versions are needed.

R.

Re: GCC 4.1: Buildable on GHz machines only?

[Richard Earnshaw]

On Tue, 2005-05-17 at 23:33, Joseph S. Myers wrote:

> It's a de facto standard: don't modify your Subject header from that 
> test_summary generates; there are plenty of examples on gcc-testresults of 
> what the headers should look like.  You can rewrite the shell script 
> output by test_summary - all the test summaries sent by CodeSourcery 
> Automatic Testing System rewrite the script to control the From address - 
> but preserve the subject header when you do so or when you send the 
> summary manually.

In my experience, test_summary does the wrong thing if you build and
test a unified source tree, for example, I run it on a unified arm-elf
tree and the subject line comes out as:

Results for 6.3.50.20050330-cvs -nx testsuite on arm-unknown-elf

This number seems to come from one of the other packages in the source
tree (gdb?).  It certainly only changes when I update my binutils/gdb
sources, not when I update my gcc sources.

It would be good to get this fixed properly, but I was never much of a
shell wizard.

R.

libgcc_s.so.1 exception handling behaviour depending on glibc version

[Stephan Bergmann]

Hi all,
I experience the following problem on Linux x86:
I have one version of GCC, call it C1, compiled on a glibc 2.2 (plain 
2.2, that is) machine.  (It happens to be GCC 3.4.1, but the exact 
version is probably irrelevant.)  This build includes a version of 
libgcc_s.so.1.

Additionally, I have a second version of GCC, call it C2, compiled on a 
glibc 2.3 machine.  (For C2, I tested various versions of GCC, from 
3.3.x to 4.0.x, and again the exact version is probably irrelevant.) 
This build includes another version of libgcc_s.so.1.

Now, I have a C++ program consisting of an executable main, built from 
main.cc:

  void f();
  int main() { f(); }
and linked against a shared library libf.so, built from f.cc:
  void f() { try { throw 1; } catch (int) {} }
If I build both main and libf.so with C1, and execute the program so 
that it uses C1's libgcc_s.so.1, it works.

If I build main with C1, and libf.so with C2, and execute the program so 
that it uses C1's libgcc_s.so.1, it aborts.

If I build main with C1, and libf.so with C2, and execute the program so 
that it uses C2's libgcc_s.so.1, it works.

It appears that C1's libgcc_s.so.1 is not compatible with C2's.  I did 
not dig too deep into the code, but it appears that libgcc_s.so.1's 
_Unwind_Find_FDE (in gcc/unwind-dw2-fde-glibc.c) differs depending on 
whether or not [EMAIL PROTECTED] is available in glibc at the 
time the compiler is built; this leads to _Unwind_Find_FDE (called 
indirectly from _Unwind_RaiseException, from f.cc's throw 1) either 
returning null (and the process aborts) or returning non-null (and the 
program works ok).

In an earlier thread 
(), I learned that 
libgcc_s.so.1 changes incompatibly (though backwards compatibly) along 
the dimension of GCC versions (e.g., from GCC 3.2 to 3.3 to 4.0, etc.). 
 Can anybody confirm that it is known and intended that libgcc_s.so.1 
also changes incompatibly (though backwards compatibly, as it appears) 
along the dimension of glibc versions used to build GCC (e.g., from 
glibc 2.2 to 2.2.4 to 2.3 etc.)---or is what I describe above to be 
considered a bug?

Thanks,
-Stephan

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Andreas Schwab]

Stephan Bergmann <[EMAIL PROTECTED]> writes:

> If I build main with C1, and libf.so with C2, and execute the program so 
> that it uses C1's libgcc_s.so.1, it aborts.

Forward compatibility is never guaranteed.  If you want to execute on the
older system you need to build all parts on the older system.  Moving
objects built on the newer system to the older system is generally not
supported.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.

[Karel Gardas]

On Tue, 17 May 2005, Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
  refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
  of time is spent there
I think comptypes can be sped up by canonicalizing types better, and also 
adding a conservative hash and checking it first.
Perhaps, anyway this is box with 1GB RAM. Now, I've just for fun used:
0) compiler params used were:
   -I../include  --param ggc-min-expand=30 --param ggc-min-heapsize=4096
   -Wall -D_REENTRANT -D_GNU_SOURCE   -DPIC -fPIC  -c
and the picture at least for 4.1.0 is completely different, see below, 
which means that for machine with small memory gcc misses L2 cache much 
more, about 529 CLK per one miss, also the top cache misses provider seems 
to be GC, second comptypes.

Cheers,
Karel
CPU: AMD64 processors, speed 1802.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 10
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 
(No unit mask) count 1000
Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 
0x00 (No unit mask) count 1000
Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) 
with a unit mask of 0x1f (All cache states
) count 1000
CPU_CLK_UNHALT...|DATA_CACHE_MIS...|ICACHE_MISSES:...|DATA_CACHE_REF...|
  samples|  %|  samples|  %|  samples|  %|  samples|  %|

  5795921 100.000   3695597 100.000   2946594 100.000   1095111 100.000 cc1plus
CPU: AMD64 processors, speed 1802.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 10
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 
(No unit mask) count 1000
Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 
0x00 (No unit mask) count 1000
Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) 
with a unit mask of 0x1f (All cache states
) count 1000
samples  %samples  %samples  %samples  %symbol 
name
4428737.6411  2770957.4980  406   0.0138  210537   19.2252  
gt_ggc_mx_lang_tree_node
3577146.1718  2973938.0472  341   0.0116  92100 8.4101  
ggc_set_mark
2084843.5971  3643119.8580  48844 1.6576  88551 8.0860  
comptypes
1762843.0415  96291 2.6056  66753 2.2654  27903 2.5480  
ggc_alloc_stat
1580482.7269  1889485.1128  26549 0.9010  13119 1.1980  
lookup_fnfields_1
1207912.0841  17681 0.4784  12771 0.4334  1178  0.1076  
dfs_walk_all
1019001.7581  8530  0.2308  4541  0.1541  1293  0.1181  
record_reg_classes
97854 1.6883  28305 0.7659  9740  0.3306  5843  0.5336  
walk_tree
80856 1.3951  6314  0.1709  33168 1.1256  990   0.0904  
find_reloads
79626 1.3738  4311  0.1167  743   0.0252  640   0.0584  
_cpp_lex_direct
75468 1.3021  64101 1.7345  22   7.5e-04  20321 1.8556  
cp_tree_node_structure
60301 1.0404  7343  0.1987  6487  0.2202  2986  0.2727  
splay_tree_splay_helper
57714 0.9958  41027 1.1102  4436  0.1505  16364 1.4943  
ht_lookup_with_hash
56687 0.9780  7502  0.2030  313   0.0106  422   0.0385  
_cpp_clean_line
51682 0.8917  71809 1.9431  1513  0.0513  21801 1.9908  
compparms
51528 0.8890  65441 1.7708  10699 0.3631  4356  0.3978  
lookup_field_1
51470 0.8880  41211 1.1151  20647 0.7007  17549 1.6025  tsubst
50100 0.8644  43384 1.1739  19750 0.6703  18065 1.6496  
htab_find_slot_with_hash
49868 0.8604  91428 2.4740  2472  0.0839  41355 3.7763  
push_to_top_level
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Re: GCC 4.1: Buildable on GHz machines only?

[Karel Gardas]

On Mon, 16 May 2005, DJ Delorie wrote:

What I have problem understanding is the last sentence of this
paragraph in the light of your claim that it will results in
swapping especially when we consider developers' machines with
512MB/1GB RAM, i.e. machines where memory is not "tight".
Sigh, Linux works the same way.  Processes can exceed their HARD
ulimit if there happens to be memory available, making RLIMIT_RSS
basically useless.
Perhaps we can use --param ggc-min-expand=X --param ggc-min-heapsize=Y 
options? I've tried here:
http://gcc.gnu.org/ml/gcc/2005-05/msg00967.html

and got some interesting results which might be more similar to the 
machines with low memory.

Cheers,
Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Richard Guenther]

The following snippet

  /* Differs from default_conversion by not setting TREE_ADDRESSABLE
 (because calling an inline function does not mean the function
 needs to be separately compiled).  */
  fntype = build_type_variant (TREE_TYPE (function),
   TREE_READONLY (function),
   TREE_THIS_VOLATILE (function));
  fundecl = function;
  function = build1 (ADDR_EXPR, build_pointer_type (fntype),
function);

purposely builds an ADDR_EXPR tree with mismatched types:

 
readonly QI
   
readonly constant invariant
arg 0 
QI
   

why?  Do we (want to) allow this kind of mismatch in ADDR_EXPRs?

Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Bad type mismatch in ADDR_EXPR from cp/class.c:build_vtbl_initializer

[Richard Guenther]

If the following ever escapes the C++ frontend (who knows...)

/* Take the address of the function, considering it to be of an
   appropriate generic type.  */
init = build1 (ADDR_EXPR, vfunc_ptr_type_node, fn);

it'll be not nice.

(gdb) call debug_tree(t)
 
QI
   
constant invariant
arg 0 
QI size  unit size 
   


does it escape?  Would using convert on the ADDR_EXPR of the correct
type to vfunc_ptr_type_node work?

Thanks,
Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Richard Guenther]

On 5/18/05, Richard Guenther <[EMAIL PROTECTED]> wrote:
> 
> The following snippet
> 
>   /* Differs from default_conversion by not setting TREE_ADDRESSABLE
>  (because calling an inline function does not mean the function
>  needs to be separately compiled).  */
>   fntype = build_type_variant (TREE_TYPE (function),
>TREE_READONLY (function),
>TREE_THIS_VOLATILE (function));
>   fundecl = function;
>   function = build1 (ADDR_EXPR, build_pointer_type (fntype),
> function);
> 
> purposely builds an ADDR_EXPR tree with mismatched types:
> 
>   type  type 
> readonly QI
>
> readonly constant invariant
> arg 0  type 
> QI
>
> 
> why?  Do we (want to) allow this kind of mismatch in ADDR_EXPRs?

Allowing ADDR_EXPR with types that share the same TYPE_MAIN_VARIANT
makes these things in the C forntend a non-issue.  This may be one hint that
we do not want a (very) strict type system.

Richard.

[RFC] Fix ADDR_EXPR type mismatches in C++ frontend

[Richard Guenther]

With this patch we can build the C++ frontend and libraries
with an instrumented build1 that checks ADDR_EXPR types to
match as far as sharing the same TYPE_MAIN_VARIANT.

Comments?

Richard.


2005-05-18  Richard Guenther  <[EMAIL PROTECTED]>

* class.c (dfs_accumulate_vtbl_inits): Create ADDR_EXPR
with correct types.
(build_vtbl_initializer): Likewise.
* except.c (build_throw): Likewise.

* tree.c (build1_stat): Instrument for incorrectly typed
ADDR_EXPRs.


Index: cp/class.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/class.c,v
retrieving revision 1.717
diff -c -3 -p -r1.717 class.c
*** cp/class.c  8 May 2005 02:17:54 -   1.717
--- cp/class.c  18 May 2005 12:03:12 -
*** dfs_accumulate_vtbl_inits (tree binfo,
*** 7069,7075 

/* Figure out the position to which the VPTR should point.  */
vtbl = TREE_PURPOSE (l);
!   vtbl = build1 (ADDR_EXPR, vtbl_ptr_type_node, vtbl);
index = size_binop (PLUS_EXPR,
  size_int (non_fn_entries),
  size_int (list_length (TREE_VALUE (l;
--- 7069,7075 

/* Figure out the position to which the VPTR should point.  */
vtbl = TREE_PURPOSE (l);
!   vtbl = build_fold_addr_expr (vtbl);
index = size_binop (PLUS_EXPR,
  size_int (non_fn_entries),
  size_int (list_length (TREE_VALUE (l;
*** build_vtbl_initializer (tree binfo,
*** 7247,7253 
{
  fn = abort_fndecl;
  if (abort_fndecl_addr == NULL)
!   abort_fndecl_addr = build1 (ADDR_EXPR, vfunc_ptr_type_node, fn);
  init = abort_fndecl_addr;
}
  else
--- 7247,7254 
{
  fn = abort_fndecl;
  if (abort_fndecl_addr == NULL)
!   abort_fndecl_addr = convert (vfunc_ptr_type_node,
!build_fold_addr_expr (fn));
  init = abort_fndecl_addr;
}
  else
*** build_vtbl_initializer (tree binfo,
*** 7260,7266 
}
  /* Take the address of the function, considering it to be of an
 appropriate generic type.  */
! init = build1 (ADDR_EXPR, vfunc_ptr_type_node, fn);
}
}

--- 7261,7268 
}
  /* Take the address of the function, considering it to be of an
 appropriate generic type.  */
! init = convert (vfunc_ptr_type_node,
! build_fold_addr_expr (fn));
}
}

Index: cp/except.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/except.c,v
retrieving revision 1.182
diff -c -3 -p -r1.182 except.c
*** cp/except.c 23 Apr 2005 21:28:53 -  1.182
--- cp/except.c 18 May 2005 12:03:21 -
*** build_throw (tree exp)
*** 744,750 
  mark_used (cleanup);
  cxx_mark_addressable (cleanup);
  /* Pretend it's a normal function.  */
! cleanup = build1 (ADDR_EXPR, cleanup_type, cleanup);
}
else
cleanup = build_int_cst (cleanup_type, 0);
--- 744,751 
  mark_used (cleanup);
  cxx_mark_addressable (cleanup);
  /* Pretend it's a normal function.  */
! cleanup = convert (cleanup_type,
!build_fold_addr_expr (cleanup));
}
else
cleanup = build_int_cst (cleanup_type, 0);
Index: tree.c
===
RCS file: /cvs/gcc/gcc/gcc/tree.c,v
retrieving revision 1.479
diff -c -3 -p -r1.479 tree.c
*** tree.c  11 May 2005 16:25:29 -  1.479
--- tree.c  18 May 2005 12:05:56 -
*** build1_stat (enum tree_code code, tree t
*** 2560,2565 
--- 2560,2569 
  case ADDR_EXPR:
if (node)
recompute_tree_invarant_for_addr_expr (t);
+   if (TREE_CODE (TREE_TYPE (TREE_OPERAND (t, 0))) != ARRAY_TYPE
+ && TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (t)))
+!= TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (t, 0
+   gcc_unreachable ();
break;

  default:

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Mike Hearn]

On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
> If I build main with C1, and libf.so with C2, and execute the program so 
> that it uses C2's libgcc_s.so.1, it works.

Out of interest, what happens if you build main with C2 and libf with C1?
That would seem to be a more common situation for distributors of Linux
binaries than the other way around.

This policy of not supporting "build on newer, run on older" is a massive
pain for developers who distribute Linux binaries even though it's very
common: developers often use very new distributions but users often don't.
It requires all kinds of stupid hacks to work around. 

Could there please at some point be serious discussion of making this a
supported way of working? In this case dl_iterate_phdr is weak so could
the decision about whether to use it or not could be made at runtime, not
build time?

thanks -mike

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Joseph S. Myers]

On Wed, 18 May 2005, Richard Guenther wrote:

> The following snippet
> 
>   /* Differs from default_conversion by not setting TREE_ADDRESSABLE
>  (because calling an inline function does not mean the function
>  needs to be separately compiled).  */
>   fntype = build_type_variant (TREE_TYPE (function),
>TREE_READONLY (function),
>TREE_THIS_VOLATILE (function));
>   fundecl = function;
>   function = build1 (ADDR_EXPR, build_pointer_type (fntype),
> function);

If you want to avoid this then you need to arrange for const and noreturn 
attributes on functions always to be represented by qualifiers on the type 
and not on the decl.  This is part of bug 3481.

(a) Change handle_noreturn_attribute and handle_const_attribute to put the 
qualifiers on the type in addition to the decl.  This might be all you 
need to avoid the above code creating undesirable type variants, but I 
wouldn't be at all confident of that.

(b) You'll probably need to change the code that autodetects const 
functions to do the same, and if there's any code autodetecting noreturn 
functions then likewise.  Also any code generating built-in functions 
without going through the attribute handling (e.g. local_define_builtin in 
tree.c).

(c) Ideally find all places looking at qualifiers on the decl to ascertain 
these properties of functions and change them to look at properties of the 
type.  This should yield better results for calls through function 
pointers.

(d) At that point it should be possible to change const and noreturn to 
straight function type attributes.  Code like the above, expecting to find 
qualifiers on the decl, would however need to be changed.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

expand_main_function/PREFERRED_STACK_BOUNDARY on ppc

[Olivier Hainque]

Hello,

As mentioned in a previous discussion at
  http://gcc.gnu.org/ml/gcc/2005-04/msg01416.html

we have troubles with the expand_main_function code to adjust the stack
pointer to PREFERRED_STACK_BOUNDARY on entry points.

It currently aligns the stack pointer by applying explicit operations on it
and then resorts to allocate_dynamic_stack_space to "pick up the pieces", as
the comment says:

  /* Forcibly align the stack.  */
  [...]
  /* Enlist allocate_dynamic_stack_space to pick up the pieces.  */

We are using that code on an eabi ppc target to ensure
PREFERRED_STACK_BOUNDARY is honored. The current code badly interacts with the
ABI because the back-chain cannot be found at the address denoted by the stack
pointer after the first step above if it actually affects the register.

A possible way to address that is to have expand_main_function compute the
distance between the current and aligned values of the stack pointer (without
touching it), and resort to allocate_dynamic_stack_space to allocate exactly
that amount.

We have thought of slighlty updating the allocate_dynamic_stack_space
interface and code for the sake of this specific interaction.

I can provide more details as well as a tentative patch, and would be glad to
hear opinions on the overall issue and approach first, so ...

Thanks in advance for your help,

Olivier

Re: GCC 4.1: Buildable on GHz machines only?

[Joseph S. Myers]

On Wed, 18 May 2005, Richard Sandiford wrote:

> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> > For example, "Results for 4.1.020050506(experimental) testsuite on 
> > mips64-unknown-elf" with the components of the version number all run 
> > together
> > [...]
> > Ensuring your test results 
> > use the standard Subject header format makes it more likely they can 
> > handled properly by sites processing the gcc-testresults postings into 
> > databases of GCC test status on different targets (such as 
> >  but other sites have 
> > done this sort of thing before and may do so in future).
> 
> FWIW, those mips messages _were_ sent with test_summary.  I'm not
> sure why they got mangled.  Are there any known issues that would
> cause that?

What awk version are you using?  (The script tests for gawk, nawk, awk if 
$AWK is not set.)  Experimenting suggests that mawk is deficient in this 
regard: where the script extracts the version number

$2 == "version" { save = $0; $1 = ""; $2 = ""; version = $0; gsub(/^ */, 
"", version); gsub(/\r$/, "", version); $0 = save; }

mawk loses the spaces whereas gawk or nawk do not.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Problem with -ftree-ter and loop unrolling

[Zdenek Dvorak]

Hello,

I am just playing with loop unrolling on trees (for the purposes of
prefetching), and I encountered the following problem.  Consider loop

sum1 = 0;
sum2 = 0;
for (i = 0; i < n; i++)
  {
x_1 = a[i];
y_1 = b[i];
sum1 += x_1 * y_1;
sum2 += x_1 / y_1;
  }

Now after unrolling we get (with some handling for remaining iterations
of the loop)

sum1 = 0;
sum2 = 0;
for (i = 0; i < n; i+=4)
  {
x_1 = a[i];
y_1 = b[i];
sum1 += x_1 * y_1;
sum2 += x_1 / y_1;
x_2 = a[i+1];
y_2 = b[i+1];
sum1 += x_2 * y_2;
sum2 += x_2 / y_2;
x_3 = a[i+2];
y_3 = b[i+2];
sum1 += x_3 * y_3;
sum2 += x_3 / y_3;
x_4 = a[i+3];
y_4 = b[i+3];
sum1 += x_4 * y_4;
sum2 += x_4 / y_4;
  }

So far OK, but with ter, this becomes

sum1 = 0;
sum2 = 0;
for (i = 0; i < n; i+=4)
  {
x_1 = a[i];
y_1 = b[i];
x_2 = a[i+1];
y_2 = b[i+1];
x_3 = a[i+2];
y_3 = b[i+2];
x_4 = a[i+3];
y_4 = b[i+3];
sum1 += x_1 * y_1 + x_2 * y_2 + x_3 * y_3 + x_4 * y_4;
sum2 += x_1 / y_1 + x_2 / y_2 + x_3 / y_3 + x_4 / y_4;
  }

Now we need some 11 registers for the loop, instead of the original 5
(and the number of registers grows with the unroll factor).

This causes huge regressions (more than 60% on sixtrack from spec2000).
It might perhaps be a good idea to limit the size of expressions ter
produces, or in some other way restrict the way it increases the lives
of registers?

Zdenek

Re: GCC 4.1: Buildable on GHz machines only?

[Joseph S. Myers]

On Wed, 18 May 2005, Richard Earnshaw wrote:

> In my experience, test_summary does the wrong thing if you build and
> test a unified source tree, for example, I run it on a unified arm-elf
> tree and the subject line comes out as:
> 
> Results for 6.3.50.20050330-cvs -nx testsuite on arm-unknown-elf
> 
> This number seems to come from one of the other packages in the source
> tree (gdb?).  It certainly only changes when I update my binutils/gdb
> sources, not when I update my gcc sources.
> 
> It would be good to get this fixed properly, but I was never much of a
> shell wizard.

As test_summary is designed to summarize GCC logs it isn't obvious what is 
correct for it to do when presented with logs from other software as well 
- when the logs are for both GCC version x and GDB version y.

I think the right approach might be for more complete version information 
in a better defined format to go in the .sum files so the script can look 
just for GCC version information and distinguish it from GDB version 
information.  This should include the configure flags from gcc -v so that 
you don't need to keep config.status around from the build if you want to 
use test_summary on logs from an installed compiler test.  
(default_gcc_version in gcc/testsuite/lib/gcc.exp does run gcc -v but 
everything but the version string only goes in gcc.log not gcc.sum.)  If 
the .sum files had well-defined lines

GCC version: ...
GCC LAST_UPDATED: ...
(should be put in gcc -v so test_summary doesn't need the source 
 directory around)
GCC configure flags: ...
GCC BOOT_CFLAGS: ...
(getting this from the environment when running test_summary seems 
 like a kludge; should be in gcc -v)
GCC host: ...
GCC build: ...
GCC target: ...
GDB version: ...

then test_summary could process the .sum files more generally and reliably 
and without needing other information from the source or build trees.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Jakub Jelinek]

On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:
> Could there please at some point be serious discussion of making this a
> supported way of working? In this case dl_iterate_phdr is weak so could
> the decision about whether to use it or not could be made at runtime, not
> build time?

It can't, this decision must be done at compiler configuration time.
Compiler built in presence of dl_iterate_phdr creates binaries and shared
libraries, that rely on its presence in target glibc, as support code
for older glibc's is intentionally left out in that case.

BTW, all glibc versions are really only backwards compatible, not forward
compatible, new symbols are added through symbol versioning all the time.

You can always install into a chroot an older distribution and compile/link
programs in there if you want one library or binary to work with multiple
OS releases.

Jakub

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Daniel Berlin]

On Wed, 2005-05-18 at 12:42 +, Joseph S. Myers wrote:
> On Wed, 18 May 2005, Richard Guenther wrote:
> 

> (b) You'll probably need to change the code that autodetects const 
> functions to do the same, and if there's any code autodetecting noreturn 
> functions then likewise.  Also any code generating built-in functions 
> without going through the attribute handling (e.g. local_define_builtin in 
> tree.c).

This code has actually been rewritten on tree-profiling to be done at
the cgraph/tree level, and this patch will be submitted soon, so if you
plan on touching the auto-detection code, you are better off working
there.

Re: Problem with -ftree-ter and loop unrolling

[Steven Bosscher]

On May 18, 2005 03:06 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:

> So far OK, but with ter, this becomes
> 
> sum1 = 0;
> sum2 = 0;
> for (i = 0; i < n; i+=4)
>   {
> x_1 = a[i];
> y_1 = b[i];
> x_2 = a[i+1];
> y_2 = b[i+1];
> x_3 = a[i+2];
> y_3 = b[i+2];
> x_4 = a[i+3];
> y_4 = b[i+3];
> sum1 += x_1 * y_1 + x_2 * y_2 + x_3 * y_3 + x_4 * y_4;
> sum2 += x_1 / y_1 + x_2 / y_2 + x_3 / y_3 + x_4 / y_4;
>   }
> 
> Now we need some 11 registers for the loop, instead of the original 5
> (and the number of registers grows with the unroll factor).

The TER hack we settled on for PR17549 was supposed to prevent this kind
of thing, but it was already obvious at the time that a better fix is
needed in the general case.  You've find a pretty nasty one here.

> This causes huge regressions (more than 60% on sixtrack from spec2000).
> It might perhaps be a good idea to limit the size of expressions ter
> produces, or in some other way restrict the way it increases the lives
> of registers?

/me pretends to be surprised ;-)

There is really no easy measure for register pressure in tree-outof-ssa,
so fixing this may be hard.  Perhaps we should disallow TER to combine
things across loads, or limit the maximum number of expressions it is
allowed to combine...

Gr.
Steven

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Richard Guenther]

On 5/18/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-05-18 at 12:42 +, Joseph S. Myers wrote:
> > On Wed, 18 May 2005, Richard Guenther wrote:
> >
> 
> > (b) You'll probably need to change the code that autodetects const
> > functions to do the same, and if there's any code autodetecting noreturn
> > functions then likewise.  Also any code generating built-in functions
> > without going through the attribute handling (e.g. local_define_builtin in
> > tree.c).
> 
> This code has actually been rewritten on tree-profiling to be done at
> the cgraph/tree level, and this patch will be submitted soon, so if you
> plan on touching the auto-detection code, you are better off working
> there.

I won't touch this with a 10ft pole ;)

Richard.

Re: GCC 4.1: Buildable on GHz machines only?

[Robert Dewar]

Ralf Corsepius wrote:
ATM, I am experiencing objects being generated by GCC to increase in
size and forcing us to gradually abandon targets with tight memory
requirements. At least one cause of this seems to be GCC abandoning COFF
in favor of ELF, which seems to imply larger memory requirements.
I don't see at all why this should increase target memory requirements,
can you eludicate?

AIX bootstrap failure

[David Edelsohn]

LAST_UPDATED:
Wed May 18 00:10:41 EDT 2005
Wed May 18 04:10:41 UTC 2005

/tmp/powerpc-ibm-aix5.2.0.0-20050518/./gcc/xgcc 
-B/tmp/powerpc-ibm-aix5.2.0.0-20050518/./gcc/ 
-B/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050518/powerpc-ibm-aix5.2.0.0/bin/ 
-B/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050518/powerpc-ibm-aix5.2.0.0/lib/ 
-isystem 
/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050518/powerpc-ibm-aix5.2.0.0/include
 -isystem 
/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050518/powerpc-ibm-aix5.2.0.0/sys-include
 -DHAVE_CONFIG_H -I. -I/farm/dje/src/src/libgfortran -I. 
-iquote/farm/dje/src/src/libgfortran/io -std=gnu99 -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 
-c /farm/dje/src/src/libgfortran/runtime/main.c   -DPIC -o .libs/main.o
/farm/dje/src/src/libgfortran/runtime/main.c: In function 
'_GLOBAL__I_0__gfortrani_l8_to_l4_offset':
/farm/dje/src/src/libgfortran/runtime/main.c:119: internal compiler error: 
Segmentation fault

Re: GCC 4.1: Buildable on GHz machines only?

[Peter Barada]

>> ATM, I am experiencing objects being generated by GCC to increase in
>> size and forcing us to gradually abandon targets with tight memory
>> requirements. At least one cause of this seems to be GCC abandoning COFF
>> in favor of ELF, which seems to imply larger memory requirements.
>
>I don't see at all why this should increase target memory requirements,
>can you eludicate?

Perhaps it is that the ELF executables are larger in total size(not
code size) than the corresponding COFF executables, and if stored on
the target, then the footprint increases, causing "larger memory
requirements" of flash, not DRAM.

-- 
Peter Barada
[EMAIL PROTECTED]

Type mismatch in tree-ssa-loop-ivopts.c:5436 (rewrite_address_base)

[Richard Guenther]

Don't know how to fix this - nothing obvious.  But we create at

  *op = build1 (INDIRECT_REF, TREE_TYPE (*op), with);

an INDRECT_REF of the form

 
unit size 
align 8 symtab 1075593216 alias set -1 precision 8 min
 max 
pointer_to_this >

arg 0 
public unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1>
var  def_stmt 
version 38
ptr-info 0x4065b8ac>>

where we confuse type  and
type .  Testcase is compiling
with -O2 -g

/net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/unwind-dw2.c: In function
'__frame_state_for':
/net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/unwind-dw2.c:1036


Please fix / advice.

Thanks,
Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Re: genmddeps s390 bootstrap failure

[Ian Lance Taylor]

Andreas Krebbel <[EMAIL PROTECTED]> writes:

> mainline bootstrap on s390 currently fails with:
> 
> build/genmddeps ../../gcc/config/s390/s390.md > tmp-mddeps
> ../../gcc/config/s390/s390.md:2041: undefined attribute 'DBL' used for 
> mode
> ../../gcc/config/s390/s390.md:2041: following context is `'
> 
> DBL is a macro attribute defined as:
> 
> (define_mode_attr DBL [(DI "TI") (SI "DI")])
> 
> The pattern in question is:
> 
> (define_insn "*clrmem_long"
>   [(clobber (match_operand: 0 "register_operand" "=d"))
>(set (mem:BLK (subreg:P (match_operand: 2 "register_operand" "0") 0))
> (const_int 0))
>(use (match_dup 2))
>(use (match_operand: 1 "register_operand" "d"))
>(clobber (reg:CC CC_REGNUM))]
>   ""
>   "mvcle\t%0,%1,0\;jo\t.-4"
>   [(set_attr "length" "8")
>(set_attr "type" "vs")])
> 
> I think the problem lies in genmddeps. genmddeps seems to randomly complain 
> about
> uses of the DBL attribute. Always with an again randomly appended character 
> at the
> end of the macro name in the error message.
> 
> At first glance it appears like a string null termination problem so I've 
> added:

Sorry about that.  Braino on my part.  I'm committing this patch as
the obvious fix.  Please let me know if you still have trouble.

Ian


2005-05-18  Ian Lance Taylor  

* read-rtl.c (mode_attr_index): Use obstack_grow0, not
obstack_grow.


Index: read-rtl.c
===
RCS file: /cvs/gcc/gcc/gcc/read-rtl.c,v
retrieving revision 1.38
diff -p -u -r1.38 read-rtl.c
--- read-rtl.c  17 May 2005 12:50:32 -  1.38
+++ read-rtl.c  18 May 2005 13:42:28 -
@@ -320,7 +320,7 @@ mode_attr_index (struct map_value **mode
 
   /* Copy the attribute string into permanent storage, without the
  angle brackets around it.  */
-  obstack_grow (&string_obstack, string + 1, strlen (string) - 2);
+  obstack_grow0 (&string_obstack, string + 1, strlen (string) - 2);
   p = (char *) obstack_finish (&string_obstack);
 
   mv = XNEW (struct map_value);

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Paul Schlie]

> Joseph S. Myers writes:
>> Richard Guenther wrote:
>> The following snippet
>> 
>>   /* Differs from default_conversion by not setting TREE_ADDRESSABLE
>>  (because calling an inline function does not mean the function
>>  needs to be separately compiled).  */
>>   fntype = build_type_variant (TREE_TYPE (function),
>>TREE_READONLY (function),
>>TREE_THIS_VOLATILE (function));
>>   fundecl = function;
>>   function = build1 (ADDR_EXPR, build_pointer_type (fntype),
>> function);
>
> If you want to avoid this then you need to arrange for const and noreturn
> attributes on functions always to be represented by qualifiers on the type
> and not on the decl.  This is part of bug 3481.

I wonder if further a read-only 'literal' type qualifier should be added
as an implicitly declared type qualifier, thereby allowing implicitly
declared literal values/references to be effectively and reliably tracked,
without the complexity of relying on the use of READONLY_TREES, etc.

Thereby all literal values are implied to be qualified as a read-only
'literal' object/reference, which has the semantics, that it may not be
assigned/modified, but unlike 'const' may not be cast away; thereby for
example string (i.e. char array) literal references may be reliably passed
to and returned from functions and properly retain their read-only 'literal'
reference semantics. (i.e. allow _FUNCTION_() to return a reference to a
read-only 'literal char[]', and be able to reliably warn and/or prevent
const pointers to read-only 'literal's to be cast away).

Re: Problem with -ftree-ter and loop unrolling

[Andrew MacLeod]

On Wed, 2005-05-18 at 09:23, Steven Bosscher wrote:
> On May 18, 2005 03:06 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> 
> > So far OK, but with ter, this becomes
> > 
> > sum1 = 0;
> > sum2 = 0;
> > for (i = 0; i < n; i+=4)
> >   {
> > x_1 = a[i];
> > y_1 = b[i];
> > x_2 = a[i+1];
> > y_2 = b[i+1];
> > x_3 = a[i+2];
> > y_3 = b[i+2];
> > x_4 = a[i+3];
> > y_4 = b[i+3];
> > sum1 += x_1 * y_1 + x_2 * y_2 + x_3 * y_3 + x_4 * y_4;
> > sum2 += x_1 / y_1 + x_2 / y_2 + x_3 / y_3 + x_4 / y_4;
> >   }
> > 
> > Now we need some 11 registers for the loop, instead of the original 5
> > (and the number of registers grows with the unroll factor).
> 
> The TER hack we settled on for PR17549 was supposed to prevent this kind
> of thing, but it was already obvious at the time that a better fix is
> needed in the general case.  You've find a pretty nasty one here.

Why didn't it trigger?  I can't reproduce it by a bit of simple hacking
around, have you got a little testcase and options to turn on to produce
this? 

Andrew

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Gabriel Dos Reis]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

| On Wed, 18 May 2005, Richard Guenther wrote:
| 
| > The following snippet
| > 
| >   /* Differs from default_conversion by not setting TREE_ADDRESSABLE
| >  (because calling an inline function does not mean the function
| >  needs to be separately compiled).  */
| >   fntype = build_type_variant (TREE_TYPE (function),
| >TREE_READONLY (function),
| >TREE_THIS_VOLATILE (function));
| >   fundecl = function;
| >   function = build1 (ADDR_EXPR, build_pointer_type (fntype),
| > function);
| 
| If you want to avoid this then you need to arrange for const and noreturn 
| attributes on functions always to be represented by qualifiers on the type 
| and not on the decl.  This is part of bug 3481.
| 
| (a) Change handle_noreturn_attribute and handle_const_attribute to put the 
| qualifiers on the type in addition to the decl.  This might be all you 

if you're doing that and that code at some point would be used by the
C++ front-end, then you need to be very very careful because that is a
very sensitive area for C++ -- especially for the type of address of
functions, template argument deduction and the like.

-- Gaby

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Richard Guenther]

On 18 May 2005, Gabriel Dos Reis wrote:

> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
>
> | On Wed, 18 May 2005, Richard Guenther wrote:
> |
> | > The following snippet
> | >
> | >   /* Differs from default_conversion by not setting TREE_ADDRESSABLE
> | >  (because calling an inline function does not mean the function
> | >  needs to be separately compiled).  */
> | >   fntype = build_type_variant (TREE_TYPE (function),
> | >TREE_READONLY (function),
> | >TREE_THIS_VOLATILE (function));
> | >   fundecl = function;
> | >   function = build1 (ADDR_EXPR, build_pointer_type (fntype),
> | > function);
> |
> | If you want to avoid this then you need to arrange for const and noreturn
> | attributes on functions always to be represented by qualifiers on the type
> | and not on the decl.  This is part of bug 3481.
> |
> | (a) Change handle_noreturn_attribute and handle_const_attribute to put the
> | qualifiers on the type in addition to the decl.  This might be all you
>
> if you're doing that and that code at some point would be used by the
> C++ front-end, then you need to be very very careful because that is a
> very sensitive area for C++ -- especially for the type of address of
> functions, template argument deduction and the like.

Yup, I just noticed that trying to fix the bogous INDIRECT_REF
created in cp/cvt.c:convert_from_reference :/

Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Gabriel Dos Reis]

Paul Schlie <[EMAIL PROTECTED]> writes:

| > Joseph S. Myers writes:
| >> Richard Guenther wrote:
| >> The following snippet
| >> 
| >>   /* Differs from default_conversion by not setting TREE_ADDRESSABLE
| >>  (because calling an inline function does not mean the function
| >>  needs to be separately compiled).  */
| >>   fntype = build_type_variant (TREE_TYPE (function),
| >>TREE_READONLY (function),
| >>TREE_THIS_VOLATILE (function));
| >>   fundecl = function;
| >>   function = build1 (ADDR_EXPR, build_pointer_type (fntype),
| >> function);
| >
| > If you want to avoid this then you need to arrange for const and noreturn
| > attributes on functions always to be represented by qualifiers on the type
| > and not on the decl.  This is part of bug 3481.
| 
| I wonder if further a read-only 'literal' type qualifier should be added
| as an implicitly declared type qualifier, thereby allowing implicitly
| declared literal values/references to be effectively and reliably tracked,
| without the complexity of relying on the use of READONLY_TREES, etc.

As I already explained you, in C++ "const" does exactly that.
C adopted a different meaning when it adopted "const", but the
compiler is allowed -- after checking semantics restrictions -- to
internally do constant propagation. I'm agnostic of yet another type
qualifier. 

| Thereby all literal values are implied to be qualified as a read-only
| 'literal' object/reference, which has the semantics, that it may not be
| assigned/modified, but unlike 'const' may not be cast away; thereby for

If you cast away a const, you're still not allowed to modify the
object, so the compiler is still allowed to do the optimization.  
Notice any type qualifier can be casted away, so introducing one does
not solve the problem, it just adds another complexity,

-- Gaby

Re: GCC 4.1: Buildable on GHz machines only?

[Robert Dewar]

Peter Barada wrote:
Perhaps it is that the ELF executables are larger in total size(not
code size) than the corresponding COFF executables, and if stored on
the target, then the footprint increases, causing "larger memory
requirements" of flash, not DRAM.
Possibly, though I am surprised if the difference is significant,
assuming no debug information of course!

Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Ling-hua Tseng]

I saw the ARM's porting and knew that ARM have V8QI SIMD operation supporting.
I'm porting another platform, and the platform is also supporting SIMD 
operations.
Now I'm implementing the V4QI SIMD add operation.
(with gcc version 4.0.1 20050514)
I did the following steps:
   1. added VECTOR_MODES(INT, 4); to my -modes.def
   2. implemented the "movv4qi" and "addv4qi3" expander definitions and 
corresponding
   instruction patterns in the machine description file.
   3. let the hook "TARGET_VECTOR_MODE_SUPPORTED_P" is always return true if
   the mode is V4QImode (written in the .c)
And then I wrote the following test program:
=[top]===
typedef char v4qi __attribute__((vector_size(4)));
v4qi foo();
v4qi a = { 0x11, 0x22, 0x33, 0x44 };
int main()
{
   volatile v4qi x;
   x = foo();
   return 0;
}
v4qi foo()
{
   v4qi x = (v4qi)0xaabbccdd, y = a, z;
   z = x + y + a;
   return z;
}
=[end]===
It didn't work.
I passed the option '-fdump-tree-all' to gcc and got the following contents in 
".t13.cfg":
=[top]===
;; Function foo (foo)
Merging blocks 0 and 1
foo ()
{
 v4qi z;
 v4qi y;
 v4qi x;
 v4qi D.1238;
 v4qi a.0;
 v4qi D.1236;
 # BLOCK 0
 # PRED: ENTRY (fallthru)
 x = (vector char) 0aabbccdd;
 y = a;
 D.1236 = x + y;
 a.0 = a;
 z = D.1236 + a.0;
 D.1238 = z;
 return D.1238;
 # SUCC: EXIT
}
=[end]===
(I eliminated the 'main' function because we only need to concern with the 
function 'foo'.)
In the next optimization pass dump file, ".t14.oplower", I got:
=[top]===
;; Function foo (foo)
foo ()
{
 unsigned int D.1262;
 unsigned int D.1261;
 unsigned int D.1260;
 unsigned int D.1259;
 unsigned int D.1258;
 unsigned int D.1257;
 unsigned int D.1256;
 unsigned int D.1255;
 unsigned int D.1254;
 unsigned int D.1253;
 unsigned int D.1252;
 unsigned int D.1251;
 unsigned int D.1250;
 unsigned int D.1249;
 unsigned int D.1248;
 unsigned int D.1247;
 v4qi z;
 v4qi y;
 v4qi x;
 v4qi D.1238;
 v4qi a.0;
 v4qi D.1236;
:
 x = (vector char) 0aabbccdd;
 y = a;
 D.1247 = VIEW_CONVERT_EXPR(x);
 D.1248 = VIEW_CONVERT_EXPR(y);
 D.1249 = D.1247 ^ D.1248;
 D.1250 = D.1248 & 2139062143;
 D.1251 = D.1247 & 2139062143;
 D.1252 = D.1249 & 080808080;
 D.1253 = D.1251 + D.1250;
 D.1254 = D.1253 ^ D.1252;
 D.1236 = VIEW_CONVERT_EXPR(D.1254);
 a.0 = a;
 D.1255 = VIEW_CONVERT_EXPR(D.1236);
 D.1256 = VIEW_CONVERT_EXPR(a.0);
 D.1257 = D.1255 ^ D.1256;
 D.1258 = D.1256 & 2139062143;
 D.1259 = D.1255 & 2139062143;
 D.1260 = D.1257 & 080808080;
 D.1261 = D.1259 + D.1258;
 D.1262 = D.1261 ^ D.1260;
 z = VIEW_CONVERT_EXPR(D.1262);
 D.1238 = z;
 return D.1238;
}
=[end]===
The vector operations are expanded into many XOR, AND, and ADD operations,
so the RTL expansion pass is never generate any vector operations.
I modified the program to 'V8QI' version and compiled it by arm's iWMMXt 
porting.
The situation didn't appear.
So I guess that there are some miss-configured in my ports, but I can't find it.
(maybe I missed some settings of target machine hooks or macros)
Would anyone like to help me to solve the problem?
Thanks a lot.

Re: Problem with -ftree-ter and loop unrolling

[Zdenek Dvorak]

Hello,

> > > So far OK, but with ter, this becomes
> > > 
> > > sum1 = 0;
> > > sum2 = 0;
> > > for (i = 0; i < n; i+=4)
> > >   {
> > > x_1 = a[i];
> > > y_1 = b[i];
> > > x_2 = a[i+1];
> > > y_2 = b[i+1];
> > > x_3 = a[i+2];
> > > y_3 = b[i+2];
> > > x_4 = a[i+3];
> > > y_4 = b[i+3];
> > > sum1 += x_1 * y_1 + x_2 * y_2 + x_3 * y_3 + x_4 * y_4;
> > > sum2 += x_1 / y_1 + x_2 / y_2 + x_3 / y_3 + x_4 / y_4;
> > >   }
> > > 
> > > Now we need some 11 registers for the loop, instead of the original 5
> > > (and the number of registers grows with the unroll factor).
> > 
> > The TER hack we settled on for PR17549 was supposed to prevent this kind
> > of thing, but it was already obvious at the time that a better fix is
> > needed in the general case.  You've find a pretty nasty one here.
> 
> Why didn't it trigger?  I can't reproduce it by a bit of simple hacking
> around, have you got a little testcase and options to turn on to produce
> this? 

-O1 suffices.  The (sum? + 1) is needed to workaround the hack
introduced to fix PR17549 (and it is very close to what happens in
sixtrack, except that there the operation with the accumulated variable
is a bit more complicated).

Zdenek

int a[200], b[200];

void xxx(void)
{
  int i, sum1 = 0, sum2 = 0, x, y;

  for (i = 0; i < 200; i+=8)
{
  x = a[i];
  y = b[i];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;

  x = a[i+1];
  y = b[i+1];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;

  x = a[i+2];
  y = b[i+2];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;

  x = a[i+3];
  y = b[i+3];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;

  x = a[i+4];
  y = b[i+4];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;

  x = a[i+5];
  y = b[i+5];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;

  x = a[i+6];
  y = b[i+6];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;

  x = a[i+7];
  y = b[i+7];
  sum1 = (sum1 + 1) + x * y;
  sum2 = (sum2 + 1) + x / y;
}

  bla (sum1, sum2);
}

Re: Type mismatch in tree-ssa-loop-ivopts.c:5436 (rewrite_address_base)

[Zdenek Dvorak]

Hello,

> Don't know how to fix this - nothing obvious.  But we create at
> 
>   *op = build1 (INDIRECT_REF, TREE_TYPE (*op), with);
> 
> an INDRECT_REF of the form
> 
>   type  size 
> unit size 
> align 8 symtab 1075593216 alias set -1 precision 8 min
>  max 
> pointer_to_this >
> 
> arg 0  type  frame_state>
> public unsigned SI
> size 
> unit size 
> align 32 symtab 0 alias set -1>
> var  def_stmt  0x4066c1f8>
> version 38
> ptr-info 0x4065b8ac>>
> 
> where we confuse type  and
> type .  Testcase is compiling
> with -O2 -g
> 
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/unwind-dw2.c: In function
> '__frame_state_for':
> /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/unwind-dw2.c:1036
> 
> 
> Please fix / advice.

rewrite_address_base is a piece of hack needed to cheat the alias
representation system.  I would not worry about it much now, once the
TARGET_MEM_REF patch is approved, this whole function will be removed.

Zdenek

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Marcin Dalecki]

On 2005-05-18, at 14:36, Mike Hearn wrote:
On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
If I build main with C1, and libf.so with C2, and execute the  
program so
that it uses C2's libgcc_s.so.1, it works.

Out of interest, what happens if you build main with C2 and libf  
with C1?
That would seem to be a more common situation for distributors of  
Linux
binaries than the other way around.

This policy of not supporting "build on newer, run on older" is a  
massive
pain for developers who distribute Linux binaries even though it's  
very
common: developers often use very new distributions but users often  
don't.
It requires all kinds of stupid hacks to work around.
Like building on the system you are targeting?
Like cross building for the target system? 

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Jonathan Wakely]

On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:

> On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
> > If I build main with C1, and libf.so with C2, and execute the program so 
> > that it uses C2's libgcc_s.so.1, it works.
> 
> Out of interest, what happens if you build main with C2 and libf with C1?
> That would seem to be a more common situation for distributors of Linux
> binaries than the other way around.
> 
> This policy of not supporting "build on newer, run on older" is a massive
> pain for developers who distribute Linux binaries even though it's very
> common: developers often use very new distributions but users often don't.
> It requires all kinds of stupid hacks to work around. 

Such as compiling on an older system?
That's not a stupid hack, it's responsible library development IMHO.

Develop on your sexy new system, build releases on the old one
(which as Jakub points out, could be a chroot'd part of the same system)

> Could there please at some point be serious discussion of making this a
> supported way of working? In this case dl_iterate_phdr is weak so could
> the decision about whether to use it or not could be made at runtime, not
> build time?

How do you propose to make existing, installed libraries compatible with
all future versions that might exist at some point? :)

My favourite solution is to ship source, so users can compile it
themselves.  Problem "solved"  ;)

jon

-- 
"This Statement is False"
(Courtesy of POEE)

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Paolo Bonzini]

> Now I'm implementing the V4QI SIMD add operation.

Maybe there is no register that can store a V4QI.

Paolo

Re: unexpected hidden symbol in gcc 4.0.0

[Paul Koning]

> "Sam" == Sam Lauber <[EMAIL PROTECTED]> writes:

 >> > The documentation for -fvisibility=hidden suggets that this
 >> switch is > useful for shared libraries, to make things smaller
 >> and faster.  It > doesn't seem to be appropriate for object
 >> libraries.

 >> It's done *exactly* so that we catch this bug in your configury.

 Sam> I don't know about you, but forcing a link failure in good code
 Sam> just because someone screwed up GCC configuration is probably
 Sam> the of the most worst compiler hacker's sins.

In this case it's the same person being affected, so that's not such a
big deal.

What surprises me is that it's normally ok to mix static and shared
libs, but not here.  And the message is utterly uninformative about
what is wrong or why the restriction exists.

 paul

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Ling-hua Tseng]

On Wed, 18 May 2005 17:25:35 +0200, Paolo Bonzini wrote
> > Now I'm implementing the V4QI SIMD add operation.
> 
> Maybe there is no register that can store a V4QI.
> 
> Paolo
Doesn't the register allocation pass perform in the RTL optimization passes?
Could it affect the tree-level optimization pass?

BTW,
I have tried to adjust the constraints to 'r' (general registers) for 
the "movv4qi" and "addv4qi" insn patterns,
but I got the same problem.

Thanks.

powerpc64-linux bootstrap failure

[Janis Johnson]

Mainline bootstrap fails on powerpc64-linux with:

/home/gccbuild/gcc_mline_anoncvs/gcc/libjava/jni.cc: In function 'void* 
_Jv_LookupJNIMethod(java::lang::Class*, _Jv_Utf8Const*, _Jv_Utf8Const*, int)':
/home/gccbuild/gcc_mline_anoncvs/gcc/libjava/jni.cc:2141: error: Statement 
marked for throw, but doesn't.
#   VUSE ;
D.27155_71 = D.15057;

/home/gccbuild/gcc_mline_anoncvs/gcc/libjava/jni.cc:2141: internal compiler 
error: verify_stmts failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

A regression hunt (automatically kicked off for a bootstrap failure!)
identifies the following patch from hubicka:

  http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00805.html

Janis

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Paul Schlie]

> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>, 
> Subject: Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call
> 
> | Thereby all literal values are implied to be qualified as a read-only
> | 'literal' object/reference, which has the semantics, that it may not be
> | assigned/modified, but unlike 'const' may not be cast away; thereby for
> 
> If you cast away a const, you're still not allowed to modify the
> object, so the compiler is still allowed to do the optimization.
> Notice any type qualifier can be casted away, so introducing one does
> not solve the problem, it just adds another complexity,

Unless a 'literal' qualifier is defined as being sticky; never "cast away".
(Eliminating the complexity associated with having to track and maintain
READONLY tree attributes distinct from an object's declared qualified type?)

I apologize if I'm belabored this issue too much, but do so predominantly
resulting from observing that GCC's present inconsistent use of the tree
READONLY/unchanging attribute to track and maintain proper semantic
treatment of literal values and references, need not be distinct from an
object's qualified type, thereby also enabling more strictly correct
qualification semantics be applied to function arguments and return value
types then otherwise seemingly possible, thereby producing a more flexible
and consistent representation of objects/references and their semantics.

(I'll leave it be, but obviously wanted to try to plant another seed.)

Re: powerpc64-linux bootstrap failure

[David Edelsohn]

That might be related to the bootstrap failure on AIX as well.

Also, the commit modified files not listed in the ChangeLog:

gcc/tree-pass.h
gcc/cp/method.c

adding function tree_lowering_passes()

David

Re: unexpected hidden symbol in gcc 4.0.0

[Richard Henderson]

On Wed, May 18, 2005 at 11:32:51AM -0400, Paul Koning wrote:
> What surprises me is that it's normally ok to mix static and shared
> libs, but not here.  And the message is utterly uninformative about
> what is wrong or why the restriction exists.

It's been explained in detail many times before search the archives.


r~

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Ian Lance Taylor]

"Ling-hua Tseng" <[EMAIL PROTECTED]> writes:

> I have tried to adjust the constraints to 'r' (general registers) for 
> the "movv4qi" and "addv4qi" insn patterns,
> but I got the same problem.

What about HARD_REGNO_MODE_OK?

Ian

Re: unexpected hidden symbol in gcc 4.0.0

[Paul Koning]

> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:

 Richard> On Wed, May 18, 2005 at 11:32:51AM -0400, Paul Koning wrote:
 >> What surprises me is that it's normally ok to mix static and
 >> shared libs, but not here.  And the message is utterly
 >> uninformative about what is wrong or why the restriction exists.

 Richard> It's been explained in detail many times before search the
 Richard> archives.

Fine, but are GCC *users* expected to search the GCC list archives?

Error messages preferably should be self-explanatory; failing that,
there should be documentation in the info pages that provides the
explanation. 

 paul

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Gabriel Dos Reis]

Paul Schlie <[EMAIL PROTECTED]> writes:

| > From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| > <[EMAIL PROTECTED]>, 
| > Subject: Re: Mismatched types in ADDR_EXPR from 
c-typeck.c:build_function_call
| > 
| > | Thereby all literal values are implied to be qualified as a read-only
| > | 'literal' object/reference, which has the semantics, that it may not be
| > | assigned/modified, but unlike 'const' may not be cast away; thereby for
| > 
| > If you cast away a const, you're still not allowed to modify the
| > object, so the compiler is still allowed to do the optimization.
| > Notice any type qualifier can be casted away, so introducing one does
| > not solve the problem, it just adds another complexity,
| 
| Unless a 'literal' qualifier is defined as being sticky; never "cast away".

Then, it is not a type qualifier.  It is something else, like
reference or pointer.  But not a type qualifier.

| (Eliminating the complexity associated with having to track and maintain
| READONLY tree attributes distinct from an object's declared qualified type?)

I dunno.  I have the impression that you're moving the problem from one
place to another, without reducing complexity.

[...]

| (I'll leave it be, but obviously wanted to try to plant another seed.)

:-)

-- Gaby

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Ling-hua Tseng]

On 18 May 2005 12:54:03 -0400, Ian Lance Taylor wrote
> "Ling-hua Tseng" <[EMAIL PROTECTED]> writes:
> 
> > I have tried to adjust the constraints to 'r' (general registers) for 
> > the "movv4qi" and "addv4qi" insn patterns,
> > but I got the same problem.
> 
> What about HARD_REGNO_MODE_OK?
> 
> Ian
If the register number is less than FIRST_PSEUDO_REGISTER,
it will always return 1.

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Dan Kegel]

[EMAIL PROTECTED] wrote:
> [ Things break horribly when I compile them
>   with a compiler built against glibc-2.3.x
>   and try to run them on a glibc-2.2.x system. ]
This is expected and normal.  gcc and glibc have
circular dependencies.  A gcc tainted with a newer
glibc is expected to produce binaries that don't
work with older glibc's.
Mike Hearn wrote:
This policy of not supporting "build on newer, run on older" is a massive
pain for developers who distribute Linux binaries even though it's very
common: developers often use very new distributions but users often don't.
It requires all kinds of stupid hacks to work around. 
No hacks needed; you just have to embrace reality.
As Marcin Dalecki and others pointed out, one
way to ship software that needs to run on a range of
gcc and glibc versions is to build against the
lowest common denominator, either by cross-compiling
(in which case http://kegel.com/crosstool is your friend)
or by actually building on the older system
(in which case http://thomas.apestaart.org/projects/mach/
might be your friend; I haven't used it myself).
Another way will be LSB, once it makes the leap forward
to the gcc-3.4 ABI for C++.  (Did you know that gcc-4.0
uses the gcc-3.4 ABI for C++, too?  That's right, there is hope!)
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: unexpected hidden symbol in gcc 4.0.0

[Richard Henderson]

On Wed, May 18, 2005 at 01:04:15PM -0400, Paul Koning wrote:
> Fine, but are GCC *users* expected to search the GCC list archives?

If they want to know the answer to "why", as opposed to being
satisfied with "don't do that", then yes.



r~

Re: unexpected hidden symbol in gcc 4.0.0

[Paul Koning]

> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:

 Richard> On Wed, May 18, 2005 at 01:04:15PM -0400, Paul Koning wrote:
 >> Fine, but are GCC *users* expected to search the GCC list
 >> archives?

 Richard> If they want to know the answer to "why", as opposed to
 Richard> being satisfied with "don't do that", then yes.

In this case, "don't do that" was entirely adequate -- the problem is
the absence of any statement of what "that" is.

paul

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

[Richard Henderson]

On Wed, May 18, 2005 at 01:25:05PM +0200, Richard Guenther wrote:
> 
> The following snippet
> 
>   /* Differs from default_conversion by not setting TREE_ADDRESSABLE
>  (because calling an inline function does not mean the function
>  needs to be separately compiled).  */
>   fntype = build_type_variant (TREE_TYPE (function),
>TREE_READONLY (function),
>TREE_THIS_VOLATILE (function));
>   fundecl = function;
>   function = build1 (ADDR_EXPR, build_pointer_type (fntype),
> function);
> 
> purposely builds an ADDR_EXPR tree with mismatched types:

Well, no, the only thing it purposfully does (according to the comment)
is not set TREE_ADDRESSABLE.  No idea why we're building a type variant.


r~

Re: [RFC] Fix ADDR_EXPR type mismatches in C++ frontend

[Richard Henderson]

On Wed, May 18, 2005 at 02:08:02PM +0200, Richard Guenther wrote:
> !   vtbl = build_fold_addr_expr (vtbl);

No convert.

And I'm pretty sure you never want to use convert, as that'll 
emit warnings.  Use fold_convert.



r~

Re: expand_main_function/PREFERRED_STACK_BOUNDARY on ppc

[Richard Henderson]

On Wed, May 18, 2005 at 02:46:33PM +0200, Olivier Hainque wrote:
> A possible way to address that is to have expand_main_function compute the
> distance between the current and aligned values of the stack pointer (without
> touching it), and resort to allocate_dynamic_stack_space to allocate exactly
> that amount.

Sure, if it works.


r~

Re: [RFC] Fix ADDR_EXPR type mismatches in C++ frontend

[Richard Guenther]

Richard Henderson wrote:
> On Wed, May 18, 2005 at 02:08:02PM +0200, Richard Guenther wrote:
> 
>>!   vtbl = build_fold_addr_expr (vtbl);
> 
> 
> No convert.

It will break later if I use convert here - the frontend chokes on
the unexpected NOP_EXPR.

> And I'm pretty sure you never want to use convert, as that'll 
> emit warnings.  Use fold_convert.

Ah ok, nice to know.

I guess I wont touch the frontends if possible for now.

Richard.

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Richard Henderson]

On Wed, May 18, 2005 at 11:10:42PM +0800, Ling-hua Tseng wrote:
> So I guess that there are some miss-configured in my ports, but I can't 
> find it.

Put a breakpoint at tree-complex.c line 962.  Examine the conditions
leading up to 

  if ((GET_MODE_CLASS (compute_mode) == MODE_VECTOR_INT
   || GET_MODE_CLASS (compute_mode) == MODE_VECTOR_FLOAT)
  && op != NULL
  && op->handlers[compute_mode].insn_code != CODE_FOR_nothing)
return;

to find out why the return isn't taken.  There aren't really very
many options.

The one that jumps first to my mind is that the "addv4qi3" instruction
pattern doesn't actually exist because you have a typo in the name.


r~

LLVM 1.5 is out

[Chris Lattner]

Hi All,
This is just some quick spam to announce the LLVM 1.5 release:
http://mail.cs.uiuc.edu/pipermail/llvm-announce/2005-May/16.html
http://llvm.cs.uiuc.edu/releases/1.5/docs/ReleaseNotes.html#whatsnew
Among other things, this release adds beta IA64 and Alpha backends, 
support for general proper tail calls (as often requested by the 
functional language community), a new interprocedural sparse constant 
propagation pass, a new instruction selection framework, and many other 
nice new features.

-Chris
--
http://nondot.org/sabre/
http://llvm.org/

Re: Bootstrap failure in libobjc

[Mike Stump]

On May 17, 2005, at 11:35 PM, Andreas Jaeger wrote:
On x86_64-linux-gnu I get with current CVS the following bootstrap  
error:

/cvs/gcc/libobjc/Object.m: In function '-[Object name]':
/cvs/gcc/libobjc/Object.m:101: internal compiler error: in  
tree_node_structure,
at tree.c:1815
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
This was a fallout from some changes Mark and Geoff wanted.  :-(  I  
didn't get hit by it because I have too much ram.

Anyway, easy enough to fix:
2005-05-18  Mike Stump  <[EMAIL PROTECTED]>

PR objc/21641
* objc-act.c (struct interface_tuple): Mark it up for GC.
(interface_htab): It is really a struct interface_tuple.

Doing diffs in .:
--- ./objc/objc-act.c.~1~   2005-05-17 09:40:56.0 -0700
+++ ./objc/objc-act.c   2005-05-18 12:34:05.0 -0700
@@ -3045,13 +3045,14 @@ objc_generate_write_barrier (tree lhs, e
   return result;
 }
 
-static GTY ((param_is (union tree_node))) htab_t interface_htab;
-
-struct interface_tuple {
+struct interface_tuple GTY(())
+{
   tree id;
   tree class_name;
 };
 
+static GTY ((param_is (struct interface_tuple))) htab_t interface_htab;
+
 static hashval_t
 hash_interface (const void *p)
 {
--

Re: powerpc64-linux bootstrap failure

[Jan Hubicka]

>   That might be related to the bootstrap failure on AIX as well.

Hopefully this is fixed now by Jeff's patch.
> 
>   Also, the commit modified files not listed in the ChangeLog:
> 
> gcc/tree-pass.h
> gcc/cp/method.c
> 
> adding function tree_lowering_passes()
Uhm, I apparently cut&pasted changelog somehow incomplette.  I guess all
I can do now is to fix them with next commit?

Honza
> 
> David

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Mike Hearn]

On Wed, 18 May 2005 15:13:41 +0200, Jakub Jelinek wrote:
> Compiler built in presence of dl_iterate_phdr creates binaries and shared
> libraries, that rely on its presence in target glibc, as support code
> for older glibc's is intentionally left out in that case.

Why is that? Is the support code for older glibcs really that large?
 
> BTW, all glibc versions are really only backwards compatible, not forward
> compatible, new symbols are added through symbol versioning all the time.

Yes I know, I don't think this versioning system works very well to be
honest - it has a lot of problems (I think this was discussed on
fedora-devel-list some time ago).

It's possible to work around this using problem using auto-generated
headers with .symver directives in though.

> You can always install into a chroot an older distribution and
> compile/link programs in there if you want one library or binary to work
> with multiple OS releases.

Well, maintaining a separate build box (which is what this chroot thing is
equivalent to) is very painful:

- Old system == old libs that maybe your users no longer have, for
  instance your binary may end up depending on an old libncurses.so.4
  file when 99% of your users actually have libncurses.so.5, so you 
  have to manually upgrade bits of the system which breaks package
  management and you end up with a frankenstein box where you aren't
  sure what's on it. 

  For any complex app with lots of dependencies you need good testing
  to ensure this sort of "accidental dependency" doesn't become a problem.

- No security updates for old systems

- Old system means old compilers and headers that maybe can't compile your
  new code

The biggest problem really is that this sort of thing is a lot of effort
for your average evenings-and-weekends open source hacker who wants to
distribute Linux binaries to his end users. Setting up and maintaining a
dedicated build box or chroot is an awful lot of work for these people,
even if it's do-able by commercial developers.

It's also something Windows and Mac developers don't have to do, and
therefore don't expect (and they don't understand what they did wrong when
the problems inevitably appear).

I'd really love to see a proper debate on the merits of this
backwards-compatible-only policy. It seems many of the things that cause
binaries built on new systems to not work on older ones are just the
toolchain automatically enabling optimisations and new features. That's
fine for people who compile everything themselves or use only RPMs built
for their exact distro version, but it's a problem for developers who
would rather have easy binary portability than these optimisations and
features.

Even just a -frun-on-older switch would be great news for people like me
who distribute Linux binaries.

thanks -mike

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Mike Hearn]

On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote:
> No hacks needed; you just have to embrace reality.

The reality is that 95% of computers run Windows which is very good at
supporting developers who distribute binaries in this way. On Linux
there's all kinds of gotchas you just Have To Know which is silly and
unproductive - worse, people only find out about this stuff _after_ they
get burned by it. 

In the last few months I have been working with one commercial game
developer who actually did a Linux port but wasn't ever planning on
releasing it - it was done as a half-way stopping point to a MacOS X port.

Having done the work, why didn't they want to release it? Because they'd
heard from other people in the industry what a nightmare supporting Linux
was, and how ropey its binary compatibility is. They didn't want the
support costs. Linux has this reputation amongst those people entirely
because things like this are non-intuitive and poorly documented. So
developers find out by dealing with tech support requests, and they then
tell their friends not to bother.

Hopefully we can get this game released, but we'll have to wait and see.

Anyway, the point is I disagree that this policy is harmless or "just the
way it is". Linux is by far in the minority in lacking this feature. We
might as well accept _that_ reality.

thanks -mike

Re: powerpc64-linux bootstrap failure

[David Edelsohn]

> Jan Hubicka writes:

>> That might be related to the bootstrap failure on AIX as well.

Jan> Hopefully this is fixed now by Jeff's patch.

The libjava failure is fixed, but the patch will not affect the
AIX libgfortran failure.

I have verified that either the cgraph inlining patch or one of
the Zdenek's loop patches is the cause of the bootstrap failure.
Reverting patches and quickstrapping stage3 does not fix the problem, so
either some dependency is missing or cc1 itself is being miscompiled.

I am bootstrapping with the cgraph patches in place to try to
track down the specific commit that caused the failure.

>> Also, the commit modified files not listed in the ChangeLog:
>> 
>> gcc/tree-pass.h
>> gcc/cp/method.c
>> 
>> adding function tree_lowering_passes()

Jan> Uhm, I apparently cut&pasted changelog somehow incomplette.  I guess all
Jan> I can do now is to fix them with next commit?

Please fix the ChangeLogs *now*.

Thanks, David

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Ling-hua Tseng]

On Wed, 18 May 2005 12:19:47 -0700, Richard Henderson wrote
> On Wed, May 18, 2005 at 11:10:42PM +0800, Ling-hua Tseng wrote:
> > So I guess that there are some miss-configured in my ports, but I can't 
> > find it.
> 
> Put a breakpoint at tree-complex.c line 962.  Examine the conditions
> leading up to
> 
>   if ((GET_MODE_CLASS (compute_mode) == MODE_VECTOR_INT
>|| GET_MODE_CLASS (compute_mode) == MODE_VECTOR_FLOAT)
>   && op != NULL
>   && op->handlers[compute_mode].insn_code != 
> CODE_FOR_nothing)return;
> 
> to find out why the return isn't taken.  There aren't really very
> many options.
> 
> The one that jumps first to my mind is that the "addv4qi3" 
> instruction pattern doesn't actually exist because you have a typo 
> in the name.
> 
> r~
A very strange thing was happened.
I put the breakpoint there (in my tree-complex.c, that is line 904),
and find out it's always false in the first part of condition expression.
That's because the compute_mode is SImode. (I never modified any source code)

In order to confirm this, I put the line before the if statement:
printf("%s\n", GET_MODE_NAME(compute_mode));
So the part of program looks like the following:
===[top]
  if (compute_type == type)
{
  printf("%s\n", GET_MODE_NAME(compute_mode));
  if ((GET_MODE_CLASS (compute_mode) == MODE_VECTOR_INT
   || GET_MODE_CLASS (compute_mode) == MODE_VECTOR_FLOAT)
  && op != NULL
  && op->handlers[compute_mode].insn_code != CODE_FOR_nothing)
return;
  else
{
  /* There is no operation in hardware, so fall back to scalars.  */
  compute_type = TREE_TYPE (type);
  compute_mode = TYPE_MODE (compute_type);
}
}
===[end]

And then I re-compiled gcc, re-compiled my test program...
I got 4 lines "SI".
(In the ARM's iWMMXt V8QI testing, I got the message: "V8QI")

I used the GDB to put the breakpoint again,
and type "print (((rhs)->common.type)->common.code)".
I got '$1 = VECTOR_TYPE' and got '$2 = VECTOR_TYPE', '$3 = VECTOR_TYPE',
'$4 = VECTOR_TYPE' in the next 3 iterations.

I'm confused.
Are there any target machine macros or hooks setting the VECTOR_TYPE tree 
node to SImode?
I checked the .t13.cfg again and didn't find any difference with my 
earlier posted.

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Paul Brook]

On Wednesday 18 May 2005 21:33, Mike Hearn wrote:
> On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote:
> > No hacks needed; you just have to embrace reality.
>
> The reality is that 95% of computers run Windows which is very good at
> supporting developers who distribute binaries in this way. On Linux
> there's all kinds of gotchas you just Have To Know which is silly and
> unproductive - worse, people only find out about this stuff _after_ they
> get burned by it.

Rubbish. You've obviously never tried to install two third party windows 
applications that require two different revisions of msvcrt.dll, or even 
worse two random versions of an OCX control.
In my experience most windows applications work because they're either 
statically linked, or ship with a copy of every single library they need.

Paul

Re: powerpc64-linux bootstrap failure

[Jan Hubicka]

> > Jan Hubicka writes:
> 
> >> That might be related to the bootstrap failure on AIX as well.
> 
> Jan> Hopefully this is fixed now by Jeff's patch.
> 
>   The libjava failure is fixed, but the patch will not affect the
> AIX libgfortran failure.
> 
>   I have verified that either the cgraph inlining patch or one of
> the Zdenek's loop patches is the cause of the bootstrap failure.
> Reverting patches and quickstrapping stage3 does not fix the problem, so
> either some dependency is missing or cc1 itself is being miscompiled.
> 
>   I am bootstrapping with the cgraph patches in place to try to
> track down the specific commit that caused the failure.
> 
> >> Also, the commit modified files not listed in the ChangeLog:
> >> 
> >> gcc/tree-pass.h
> >> gcc/cp/method.c
> >> 
> >> adding function tree_lowering_passes()
> 
> Jan> Uhm, I apparently cut&pasted changelog somehow incomplette.  I guess all
> Jan> I can do now is to fix them with next commit?
> 
>   Please fix the ChangeLogs *now*.
OK, fixed thus...

Honza
> 
> Thanks, David
> 

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Paolo Carlini]

Paul Brook wrote:

>In my experience most windows applications work because they're either 
>statically linked, or ship with a copy of every single library they need.
>  
>
Well, sorry for contributing to the flame, but I have the very *same*
feeling. The only reason why I'm publically stating this is that it
makes me very nervous when people expect so much from *nix dynamic
libraries. They are right in so doing, but please let's not make
comparisons, ok? ;)

Paolo.

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Christoph Hellwig]

On Wed, May 18, 2005 at 09:27:50PM +0100, Mike Hearn wrote:
> The biggest problem really is that this sort of thing is a lot of effort
> for your average evenings-and-weekends open source hacker who wants to
> distribute Linux binaries to his end users. Setting up and maintaining a
> dedicated build box or chroot is an awful lot of work for these people,
> even if it's do-able by commercial developers.

So don't distribute binaries.  I'd much prefer binaries built either by
myself or a qulified distribution packager anyway, for various reasons.

> I'd really love to see a proper debate on the merits of this
> backwards-compatible-only policy. It seems many of the things that cause
> binaries built on new systems to not work on older ones are just the
> toolchain automatically enabling optimisations and new features. That's
> fine for people who compile everything themselves or use only RPMs built
> for their exact distro version, but it's a problem for developers who
> would rather have easy binary portability than these optimisations and
> features.

If want to to send around binaries use a non-GNU system.

just 2 assertive

[Mike Stump]

mrs bash[73] nm i586-pc-linux-gnu/libobjc/.libs/libobjc.so.1 | grep  
gcc_unre
 U gcc_unreachable

:-(
This is killing the Objective-C testsuite for me...

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Christoph Hellwig]

On Wed, May 18, 2005 at 09:33:35PM +0100, Mike Hearn wrote:
> On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote:
> > No hacks needed; you just have to embrace reality.
> 
> The reality is that 95% of computers run Windows which is very good at
> supporting developers who distribute binaries in this way. On Linux
> there's all kinds of gotchas you just Have To Know which is silly and
> unproductive - worse, people only find out about this stuff _after_ they
> get burned by it. 

And Linux is different.  Passing around binaries is a stupid idea anyway,
fortunately we don't need to do that anymore most of the time.

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Richard Henderson]

On Thu, May 19, 2005 at 04:58:32AM +0800, Ling-hua Tseng wrote:
> I got 4 lines "SI".
> (In the ARM's iWMMXt V8QI testing, I got the message: "V8QI")

Then you need to debug your targetm.vector_mode_supported_p.

Starting around stor-layout.c line 1609:

for (; mode != VOIDmode ; mode = GET_MODE_WIDER_MODE (mode))
  if (GET_MODE_NUNITS (mode) == nunits
  && GET_MODE_INNER (mode) == innermode
  && targetm.vector_mode_supported_p (mode))
break;

/* For integers, try mapping it to a same-sized scalar mode.  */
if (mode == VOIDmode
&& GET_MODE_CLASS (innermode) == MODE_INT)
  mode = mode_for_size (nunits * GET_MODE_BITSIZE (innermode),
MODE_INT, 0);

The compiler has passed through the first loop without finding
a supported vector mode that matches nunits=4 && inner=QImode.


r~

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Joe Buck]

On Wed, May 18, 2005 at 11:08:30PM +0200, Paolo Carlini wrote:
> Paul Brook wrote:
> 
> >In my experience most windows applications work because they're either 
> >statically linked, or ship with a copy of every single library they need.
> >  
> >
> Well, sorry for contributing to the flame, but I have the very *same*
> feeling. The only reason why I'm publically stating this is that it
> makes me very nervous when people expect so much from *nix dynamic
> libraries. They are right in so doing, but please let's not make
> comparisons, ok? ;)

These kinds of problems can be solved, but they are beyond the scope of
this list.  It's always been my experience that on any Unix-like system
it usually works to build on an older platform to run on a newer one,
but not vice versa.  And it's not so different on Windows; there are a
wide variety of flavors (98, 2000, NT, ME, XP) in use, and "DLL hell"
is a Windows term, not a Unix/BSD/GNU/Linux term, for a reason.

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Ling-hua Tseng]

On Wed, 18 May 2005 14:17:59 -0700, Richard Henderson wrote
> On Thu, May 19, 2005 at 04:58:32AM +0800, Ling-hua Tseng wrote:
> > I got 4 lines "SI".
> > (In the ARM's iWMMXt V8QI testing, I got the message: "V8QI")
> 
> Then you need to debug your targetm.vector_mode_supported_p.
> 
> Starting around stor-layout.c line 1609:
> 
> for (; mode != VOIDmode ; mode = GET_MODE_WIDER_MODE 
> (mode))  if (GET_MODE_NUNITS (mode) == nunits
>   && GET_MODE_INNER (mode) == innermode  && 
> targetm.vector_mode_supported_p (mode))break;
> 
> /* For integers, try mapping it to a same-sized scalar 
> mode.  */if (mode == VOIDmode&& 
> GET_MODE_CLASS (innermode) == MODE_INT)  mode = 
> mode_for_size (nunits * GET_MODE_BITSIZE (innermode),
> MODE_INT, 0);
> 
> The compiler has passed through the first loop without finding
> a supported vector mode that matches nunits=4 && inner=QImode.
> 
> r~
The targetm.vector_mode_supported_p is pointed to the genernal 
hook "hook_bool_mode_false".
But I have already put the following lines in my .c:
===[top]
...
#include "target-def.h"
...
static bool unicore_vector_mode_supported_p(enum machine_mode mode);
...
struct gcc_target targetm = TARGET_INITIALIZER;
...
#undef  TARGET_VECTOR_MODE_SUPPORTED_P
#define TARGET_VECTOR_MODE_SUPPORTED_P  unicore_vector_mode_supported_p
...
static bool unicore_vector_mode_supported_p(enum machine_mode mode)
{
switch(mode) {
case V4QImode:
case V2HImode:
return true;
default:
return false;
}
}
...
===[end]

Doesn't it enough to let the targetm.vector_mode_supported_p to be pointed to
my unicore_vector_mode_supported_p() ?

Re: libgcc_s.so.1 exception handling behaviour depending on glibc version

[Andreas Schwab]

Mike Hearn <[EMAIL PROTECTED]> writes:

> The reality is that 95% of computers run Windows which is very good at
> supporting developers who distribute binaries in this way.

Does it?  I constantly hear horror stories of apps delivering their own
version of system libraries that cause all kinds of nasty conflicts.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Richard Henderson]

On Thu, May 19, 2005 at 06:02:39AM +0800, Ling-hua Tseng wrote:
> struct gcc_target targetm = TARGET_INITIALIZER;
> ...
> #undef  TARGET_VECTOR_MODE_SUPPORTED_P
> #define TARGET_VECTOR_MODE_SUPPORTED_P  unicore_vector_mode_supported_p

This is your bug.  The TARGET_INITIALIZER needs to come last.


r~

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Neil Booth]

Ling-hua Tseng wrote:-

> struct gcc_target targetm = TARGET_INITIALIZER;
> ...
> #undef  TARGET_VECTOR_MODE_SUPPORTED_P
> #define TARGET_VECTOR_MODE_SUPPORTED_P  unicore_vector_mode_supported_p

TARGET_INITIALIZER has already been expanded above, so it's not seen
your macro definition below.

Neil.

gcc-3.3-20050518 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050518 

You'll find:

gcc-3.3-20050518.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.3-20050518.tar.bz2 C front end and core compiler

gcc-ada-3.3-20050518.tar.bz2  Ada front end and runtime

gcc-g++-3.3-20050518.tar.bz2  C++ front end and runtime

gcc-g77-3.3-20050518.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.3-20050518.tar.bz2 Java front end and runtime

gcc-objc-3.3-20050518.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.3-20050518.tar.bz2The GCC testsuite

Diffs from 3.3-20050511 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.3
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: gcc-3.3-20050518 is now available

[Joe Buck]

On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
> Snapshot gcc-3.3-20050518 is now available on
>   ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

Is there a reason why we are still generating and announcing snapshots on
the 3.3 branch?

I checked the diffs file: the only differences in this snapshot from the
previous one are documentation updates to BUGS and bugs.html, and a
change in the definition of __GLIBCPP__ from 20050511 to 20050518, which
is peculiar since there are no other changes to code at all.

Re: gcc-3.3-20050518 is now available

[Joseph S. Myers]

On Wed, 18 May 2005, Joe Buck wrote:

> On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
> > Snapshot gcc-3.3-20050518 is now available on
> >   ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
> > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
> 
> Is there a reason why we are still generating and announcing snapshots on
> the 3.3 branch?

Because review by Gaby of my patch 
<http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00368.html> to stop such 
snapshots (and to stop the c++config date updates on 3.3 branch) is still 
pending.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: gcc-3.3-20050518 is now available

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
| > Snapshot gcc-3.3-20050518 is now available on
| >   ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
| > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
| 
| Is there a reason why we are still generating and announcing snapshots on
| the 3.3 branch?

None.  A patch was sent but, I missed it.

-- Gaby

Re: gcc-3.3-20050518 is now available

[Gabriel Dos Reis]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

| On Wed, 18 May 2005, Joe Buck wrote:
| 
| > On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
| > > Snapshot gcc-3.3-20050518 is now available on
| > >   ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
| > > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
| > 
| > Is there a reason why we are still generating and announcing snapshots on
| > the 3.3 branch?
| 
| Because review by Gaby of my patch 

Because Gaby missed your mail :-(

-- Gaby

[rfc] mainline slush

[Richard Henderson]

After three days of sequential bootstrap breakage, I'd like to propose
that mainline go into slush, wherein all these bootstrap problems, and
all the new testsuites failures get fixed.  No other patches would be
allowed at all.

We'd unslush when the primary platforms have clean test results.

Thoughts?


r~

Re: [rfc] mainline slush

[Eric Christopher]

> We'd unslush when the primary platforms have clean test results.
> 
> Thoughts?

Aye :)

-eric

Re: [rfc] mainline slush

[Diego Novillo]

On Wed, May 18, 2005 at 05:31:29PM -0700, Richard Henderson wrote:

> After three days of sequential bootstrap breakage, I'd like to propose
> that mainline go into slush, wherein all these bootstrap problems, and
> all the new testsuites failures get fixed.  No other patches would be
> allowed at all.
> 
Agreed.


Diego.

Re: [rfc] mainline slush

[David Edelsohn]

> Richard Henderson writes:

Richard> After three days of sequential bootstrap breakage, I'd like to propose
Richard> that mainline go into slush, wherein all these bootstrap problems, and
Richard> all the new testsuites failures get fixed.  No other patches would be
Richard> allowed at all.

Richard> We'd unslush when the primary platforms have clean test results.

Richard> Thoughts?

Sounds like a fine idea.

David

Re: [rfc] mainline slush

[Joseph S. Myers]

On Wed, 18 May 2005, Richard Henderson wrote:

> After three days of sequential bootstrap breakage, I'd like to propose
> that mainline go into slush, wherein all these bootstrap problems, and
> all the new testsuites failures get fixed.  No other patches would be
> allowed at all.
> 
> We'd unslush when the primary platforms have clean test results.
> 
> Thoughts?

I'm not confident we know what clean results are for all the primary 
platforms, i.e. that anyone has tracked what failures are regressions and 
what aren't (which requires testing the FAILing tests with older 
compilers, not just presuming that a FAILing test not in a previous 
release isn't a regression).  I know what the mainline testsuite 
regressions are cross-platform (bug 21541), on i686-pc-linux-gnu (bugs 
21630 and 21653) and on hppa2.0w-hp-hpux11.11 (bug 21654) but not for the 
other platforms.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: [rfc] mainline slush

[Joe Buck]

On Thu, May 19, 2005 at 01:09:28AM +, Joseph S. Myers wrote:
> On Wed, 18 May 2005, Richard Henderson wrote:
> 
> > After three days of sequential bootstrap breakage, I'd like to propose
> > that mainline go into slush, wherein all these bootstrap problems, and
> > all the new testsuites failures get fixed.  No other patches would be
> > allowed at all.
> > 
> > We'd unslush when the primary platforms have clean test results.
> > 
> > Thoughts?
> 
> I'm not confident we know what clean results are for all the primary 
> platforms, i.e. that anyone has tracked what failures are regressions and 
> what aren't ...

While no one knows the full answer, we have people who know the answers
for the platforms they work on (e.g. David E. for AIX, Eric B. for
Solaris, etc).

Re: Proposed resolution to aliasing issue.

[Kenneth Zadeck]

> Mark Mitchell wrote:
> >
> >  struct A {...};
> >  struct B { ...; struct A a; ...; };
> >
> >
> >  void f() {
> >B b;
> >g(&b.a);
> >  }
> >
> >
> >does the compiler have to assume that "g" may access the parts of
> >"b" outside of "a". If the compiler can see the body of "g" than
> >it may be able to figure out that it can't access any other
> >parts, or figure out which parts it can access, and in that case
> >it can of course use that information. The interesting case,
> >therefore, is when the body of "g" is not available, or is
> >insufficient to make a conclusive determination.
> >
> 
> I attended a UK C++ panel meeting yesterday, and took the opportunity
> to solicit opinions on this.  The question I posed was
>   struct A {
>   ...
>   T1 a;
>   T2 b;
>   };
>   void g(T1 &a);
>   void Foo () {
>  A v;
>  v.b = 2;
>  g (v.a);
>  if (v.b == 2) ...
> }
> Does the compiler have a right to presume v.b does indeed == 2 in the if
> condition? -- assuming T2 is a suitable type for that :)
> 
> 
> After I explained the optimization (and the related structure splitting
> optimization), the general consensus was 'yes that would be a useful
> optimization'.  But no one was sufficiently confident of proving it
> was allowable.  The opinion was expressed that if it was not allowable,
> there was a bug in the std.
> 
> 
> The observation was made that if A is non-POD, one cannot play offsetof
> tricks to get from A::a to A::b, so the optimization is safe on non-PODs.
> (Of course one would have to prove the address of 'v' did not escape,
> so I guess the ctor and dtor would need to be trivial or visible.)
> 
> 
> One of the panel members is looking at C++'s memory model WRT
> multithreading.  This question has a direct impact there too, as
> separate threads might be operating on v.a and v.b.  He indicated
> he would consider the issue.
> 
> 
> I also outlined the approach gcc would take with a compile time
> switch and an attribute.  The preference was expressed that
> the attribute should be of the form
>   void badfunc (A & __I_AM_BAD__ m);
> rather than
>   void goodfunc (A & __I_AM_GOOD__ m);
> because (a) badfuncs are more than likely rare and (b) it would be a useful
> aid to the programmer.[1] Mark outlines an __I_AM_GOOD__ attribute,  I think
> it would be better to have both flavours and then the compiler switch can
> specify which way the default goes.
> 

I would like to point out some problems with this approach.  Consider
the case where you have three modules: A, B and C.  Each with a single
function a, b, and c respectively where a calls b and b calls c.  Also
assume that c has the __I_AM_BAD__ attribute.

What is known when compiling the A module?  Function a does not know
that b calls c.  Are you going to require that b's prototype also have
the __I_AM_BAD__ attribute because it calls c?  Where does this stop?

I believe that the only way to have this work is to have the attribute
be associated with the data type.  This attribute discriminates this
type from a similar type that does not have the attribute, i.e. you
cannot just assign a pointer to a bad int to a pointer to an int.

This will force the programmer to have separate versions of functions
that take the bad pointer and the good pointer but this lets the
compiler compiler the good functions in a manner that rewards the
good.  It is also easy to track thru the maze of separate compilation.

Kenny

Disclaimer:  I have never written a single line of C++ in my life nor
have I ever read any C++ books or specifications.   I am firmly rooted
in the ML, Modula-3 and Java school of strongly typed, well defined
languages.

> 
> nathan
> 
> [1] it was of course noted that that looked stunningly like 'restrict', and
> the suggestion that it be spelled 'noalias' was jokingly made :)
> 
> 
> --
> Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
> [EMAIL PROTECTED]::
> http://www.planetfall.pwp.blueyonder.co.uk

Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?

[Ling-hua Tseng]

On Wed, 18 May 2005 15:56:27 -0700, Richard Henderson wrote
> On Thu, May 19, 2005 at 06:02:39AM +0800, Ling-hua Tseng wrote:
> > struct gcc_target targetm = TARGET_INITIALIZER;
> > ...
> > #undef  TARGET_VECTOR_MODE_SUPPORTED_P
> > #define TARGET_VECTOR_MODE_SUPPORTED_P  unicore_vector_mode_supported_p
> 
> This is your bug.  The TARGET_INITIALIZER needs to come last.
> 
> r~
I'm sorry that I made the foolish mistake. 
I'll pay attention to it forever. 

Re: Bootstrap failure in libobjc

[Andreas Jaeger]

Bootstrap works now but the testresults (see
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01209.html) show that
we still have serious problem:

=== objc Summary for unix ===

# of expected passes418
# of unexpected failures558
# of unresolved testcases   532
# of unsupported tests  12

From objc.log:

UNRESOLVED: objc/execute/IMP.m execution,  -O0
set_ld_library_path_env_vars: 
ld_library_path=.::/builds/gcc/misc/gcc:/builds/gcc/misc/gcc/32:/builds/gcc/m
isc/gcc:/builds/gcc/misc/gcc/32:/builds/gcc/misc/x86_64-suse-linux-gnu/32/libobjc/.libs
Executing on host: /builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/ 
/cvs/gcc/gcc/testsuite/objc/execute/IM
P.m  -w  -O1  -I/cvs/gcc/gcc/testsuite/../../libobjc 
-L/builds/gcc/misc/x86_64-suse-linux-gnu/32/libobjc/.l
ibs  -lobjc -lm   -m32 -o /builds/gcc/misc/gcc/testsuite/IMP.x1(timeout = 
300)
/builds/gcc/misc/x86_64-suse-linux-gnu/32/libobjc/.libs/libobjc.so: undefined 
reference to `gcc_unreachable
'
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
/builds/gcc/misc/x86_64-suse-linux-gnu/32/libobjc/.libs/libobjc.so: undefined 
reference to `gcc_unreachable
'
collect2: ld returned 1 exit status


Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpwvFPrjT9Ut.pgp
Description: PGP signature

Bootstrap Times Improvements?

[Ranjit Mathew]

Hi,

  Between Tuesday and Wednesday (Indian time), something(s)
went into mainline that is showing me a dramatic decrease
in bootstrap times - a c,c++,java bootstrap on i686-pc-linux-gnu
now takes 51m for me compared to 65-66m earlier, which is
around 20% of savings over the course of a single day! So
who do I thank for it? :-)

I am not seeing bootstrap failures as others are, the Java
testsuite runs are clean and the ChangeLogs indicate that
my tree does have the latest changes...

Are others seeing similar savings in bootstrap times too?

FYI, I'm using 3.4.4 as a bootstrap compiler, binutils
2.16 (FSF) and configure with --disable-checking and
--with-arch=pentium4.

Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Re: [rfc] mainline slush

[Eric Botcazou]

> I'm not confident we know what clean results are for all the primary
> platforms, i.e. that anyone has tracked what failures are regressions and
> what aren't (which requires testing the FAILing tests with older
> compilers, not just presuming that a FAILing test not in a previous
> release isn't a regression).

I don't think we need to be that picky at this stage of the development 
process.  Results on 05/15 for SPARC/Solaris are pretty good:
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01061.html
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01060.html
and can be considered as a baseline for now.

-- 
Eric Botcazou