Re: multiple definitions of symbol _locale_charset

[Jack Howarth]

Andrew,
Doesn't the proposed patch to intl/localcharset.c pretty
much fall under the obvious rule?
   Jack

Re: multiple definitions of symbol _locale_charset

[Jack Howarth]

Andrew,
Thanks for the hint. I make the patch as being only...

===
--- intl/localcharset.c (revision 116795)
+++ intl/localcharset.c (working copy)
@@ -23,6 +23,13 @@
 # include 
 #endif
 
+#if !HAVE_ICONV
+
+/* Provide our variant only if we don't use the systems iconv library.  This is
+* consistant with the usage in loadmsgcat.c and prevents us from relying on
+* link-time symbol resolution.
+*/
+
 /* Specification.  */
 #include "localcharset.h"
 
@@ -396,3 +403,4 @@
 
   return codeset;
 }
+#endif

...once all the garbage whitespace is removed.
   Jack

Re: multiple definitions of symbol _locale_charset

[Andrew Pinski]

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00667.html

-- Pinski

multiple definitions of symbol _locale_charset

[Jack Howarth]

I notice a warning in the Darwin PPC build of gcc trunk against
libiconv 1.10. There appears to be a duplicate symbol for _locale_charset
in both ./../intl/libintl.a(localcharset.o) and 
/sw/lib/libiconv.dylib(localcharset.o).
Shouldn't the presence of duplicate symbols in the linkage of cc1plus
be considered a bug?
  Jack
ps An example of this is...

gcc   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute 
-fno-common   -DHAVE_CONFIG_H  -o cc1plus \
  cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o 
cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o 
cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o 
cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o 
cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o 
cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o 
c-semantics.o c-lex.o c-dump.o darwin-c.o rs6000-c.o c-pretty-print.o c-opts.o 
c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o 
c-gimplify.o c-omp.o tree-inline.o cc1plus-checksum.o main.o tree-browser.o 
libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a 
../libcpp/libcpp.a ./../intl/libintl.a -L/sw/lib -liconv  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a

but it happens for other linkages (like xgcc) as well.

RE: libgfortran build broken on Darwin ppc

[Jack Howarth]

Okay. The problem with the libgfortran build failing is
unrelated to the remaining sections of the TImode patch.
I see the same failure with an unpatched version of current
gcc trunk. Time to file a PR.
Jack
ps I am currently building (for the last couple of days)
with --disable-bootstrap. I'll rebuild without that as
well but I don't see how that could come into play
(if anything I would think it would suppress certain
failures).

RE: libgfortran build broken on Darwin ppc

[Jack Howarth]

   I should add that the last good build I have is from last
night at revision r116774.
Jack

RE: libgfortran build broken on Darwin ppc

[Jack Howarth]

To correct the typo in the last message, I am now rebuilding
without the reduced TImode patch to confirm it is not at fault.
As I said, since the build craps out in the 32-bit sections, I
doubt it is the source of the libgfortran build failure.
  Jack

libgfortran build broken on Darwin ppc

[Jack Howarth]

I don't know if this is related to Eric's checkins tonight
but I can no longer build libgfortran on Darwin PPC. The build fails
at...

/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gc
c/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin
8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4
/powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2-200609
08/libgfortran -I.  -iquote../../../gcc-4.2-20060908/libgfortran/io -I../../../g
cc-4.2-20060908/libgfortran/../gcc -I../../../gcc-4.2-20060908/libgfortran/../gc
c/config -I../.././gcc -D_GNU_SOURCE  -std=gnu99 -Wall -Wstrict-prototypes -Wmis
sing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2  -c -o
 maxloc0_4_r16.lo `test -f 'generated/maxloc0_4_r16.c' || echo '../../../gcc-4.2
-20060908/libgfortran/'`generated/maxloc0_4_r16.c
/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/xgcc -B/sw/src/fink
.build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-d
arwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powe
rpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apc-4.2-20060908/libgfor
tran/../gcc -I../../../gcc-4.2-20060908/libgfortran/../gcc/config -I../.././gcc 
-D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-st
yle-definition -Wextra -Wwrite-strings -O2 -g -O2 -c ../../../gcc-4.2-20060908/l
ibgfortran/generated/maxloc0_4_r16.c  -fno-common -DPIC -o .libs/maxloc0_4_r16.o
/var/tmp//ccPhvheT.s:905:Unknown pseudo-op: .literal16

I was building with a reduced TImode patch so that I could test that 64-bit
support still worked in gfortran. This patch is...

diff -uNr gcc-4.2-20060816/gcc/config/rs6000/ppc64-fp.c 
gcc-4.2-20060816.timode/gcc/config/rs6000/ppc64-fp.c
--- gcc-4.2-20060816/gcc/config/rs6000/ppc64-fp.c   2006-08-13 
14:25:31.0 -0400
+++ gcc-4.2-20060816.timode/gcc/config/rs6000/ppc64-fp.c2006-08-16 
21:09:08.0 -0400
@@ -30,7 +30,7 @@
 Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
 02110-1301, USA.  */
 
-#if defined(__powerpc64__) || defined (__64BIT__)
+#if defined(__powerpc64__) || defined (__64BIT__) || defined(__ppc64__)
 #define TMODES
 #include "config/fp-bit.h"
 
diff -uNr gcc-4.2-20060816/gcc/config/rs6000/rs6000.h 
gcc-4.2-20060816.timode/gcc/config/rs6000/rs6000.h
--- gcc-4.2-20060816/gcc/config/rs6000/rs6000.h 2006-08-13 14:25:31.0 
-0400
+++ gcc-4.2-20060816.timode/gcc/config/rs6000/rs6000.h  2006-08-16 
21:09:08.0 -0400
@@ -178,7 +178,7 @@
 
 #ifdef IN_LIBGCC2
 /* For libgcc2 we make sure this is a compile time constant */
-#if defined (__64BIT__) || defined (__powerpc64__)
+#if defined (__64BIT__) || defined (__powerpc64__) || defined (__ppc64__)
 #undef TARGET_POWERPC64
 #define TARGET_POWERPC64   1
 #else
diff -uNr gcc-4.2-20060816/gcc/config/rs6000/t-darwin 
gcc-4.2-20060816.timode/gcc/config/rs6000/t-darwin
--- gcc-4.2-20060816/gcc/config/rs6000/t-darwin 2006-08-13 14:25:30.0 
-0400
+++ gcc-4.2-20060816.timode/gcc/config/rs6000/t-darwin  2006-08-16 
21:09:08.0 -0400
@@ -1,4 +1,6 @@
 LIB2FUNCS_EXTRA = $(srcdir)/config/rs6000/darwin-tramp.asm \
+   $(srcdir)/config/rs6000/ppc64-fp.c \
+   $(srcdir)/config/darwin-64.c \
$(srcdir)/config/rs6000/darwin-ldouble.c
 
 LIB2FUNCS_STATIC_EXTRA = \


I am not rebuilding without that patch. However I don't believe the build
problem I am seeing is related to that patch since it craps out in the -m32
sections of the libgfortran build. Not good this close to branching.
Jack

Re: 4.1 status?

[Mark Mitchell]

Kenny Simpson wrote:

What is the status of the 4.1 branch?  Any word on 4.1.2?


My current plan is to do a 4.1.2 along with 4.2.0.  My concern has been 
that with 4.2.0 moving slowly, trying to organize another release might 
just distract the developer community.


However, I realize that's a pretty wide gap between 4.1.1 and 4.1.2.  We 
could also do 4.1.2 sooner, and then do 4.1.3 along with 4.2.0.  (I want 
to do a 4.1.x release along with 4.2.0 so as to avoid the problems we 
have in past with quality "going backwards" between releases from 
different branches.)


I'm sure that, a priori, people would prefer a 4.1.2 release, but it 
does take effort.  On the other hand, many 4.1 bugs are also in 4.2.


Any thoughts?

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

Re: Linker scripts

[Michael Eager]

Andrew Pinski wrote:

On Wed, 2006-09-06 at 15:00 -0700, Michael Eager wrote:

GCC passes a linker script to the linker for some
targets (e.g., powerpc-eabi with -mads).  If you specify a
linker script using -Wl,-T,script.ld, you get both
passed to the linker and there may be conflicts.

Is there any option to GCC which says to not pass
the predefined linker script to the linker?


sysv4.h has "%{!Wl,-T*: %{!T*: %(link_start) }}" which should mean don't
do link_start (which contains the -T for -mads) when supplying -T or
-Wl,-T.  Now is it really working is different story.


This works for -Tsscript.ld, but not for -Wl,-Tscript.ld.
(I also noticed similar usage of %{Wa*:, in ASM specs which also
would have a problem but the special handling that removes assembler
options and passes them to the assembler does essentially
what the ASM spec would have done.)

Linker options specified by -Wl are moved to the file list
so that they are passed on to the linker after the files.
Other options for the linker (like -x) are moved
to a linker option list.  When the spec is processed, the
switches list doesn't contain "-Wl.-T", so the test always fails.

I can look for "-Wl,-T,script.ld" and "-Wl,-T -Wl,script.ld"
and translate them into "-Tscript.ld" in process_command().

This feel like a bit of a kludge, especially since -T is
undocumented.  Where %{T} is used, it is an assembler option
which doesn't take an argument.

Anyone have a different idea?

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

gcc-4.1-20060908 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20060908.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20060908.tar.bz2 C front end and core compiler

gcc-ada-4.1-20060908.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20060908.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20060908.tar.bz2  C++ front end and runtime

gcc-java-4.1-20060908.tar.bz2 Java front end and runtime

gcc-objc-4.1-20060908.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20060908.tar.bz2The GCC testsuite

Diffs from 4.1-20060901 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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: -T option

[Ian Lance Taylor]

Michael Eager <[EMAIL PROTECTED]> writes:

> GCC accepts the -T

Re: powerpc targets, long double implementation, and c++ programs

[Joseph S. Myers]

On Fri, 8 Sep 2006, Edmar Wienskoski wrote:

> Ok. I am starting to see the whole picture now.
> So the whole thing appears to work with --disable-shared, just because the way
> the linker
> loads symbols in presence of libgcc_s.so versus libgcc.a.
> 
> Follow up question:
> The e500 abi actualy defines long double to be 128bits floats.
> On rs6000.c, rs6000_init_libfuncs links to __gcc_qadd becasue of
> TARGET_HARD_FLOAT
> shouldn't that be TARGET_HARD_FLOAT && TARGET_FPRS
> and also have:
> diff -u t-fprules-softfp~ t-fprules-softfp
> --- t-fprules-softfp~   2006-08-09 14:20:24.0 -0500
> +++ t-fprules-softfp2006-09-06 12:39:17.0 -0500
> @@ -1,4 +1,4 @@
> -softfp_float_modes := sf df
> +softfp_float_modes := sf df tf
> softfp_int_modes := si di
> softfp_extensions := sfdf
> softfp_truncations := dfsf
> 
> Would that be right ?

No.

(a) The existing GNU/Linux ABIs use or are intended to use IBM long 
double, not IEEE long double, and the E500 GNU/Linux ABI should be 
compatible with the other ABIs in this regard.  The present formal ABI 
documents are not very relevant to the de facto GNU/Linux ABIs.

(b) To use IEEE long double with soft-fp you'll need to add sftf dftf to 
softfp_extensions and tfdf tfsf to softfp_truncations.

(c) If using IEEE long double on PowerPC, you should be using the standard 
_q_* functions defined in the psABI, and not the __*tf* functions at all.  
glibc does provide the _q_* functions (albeit with a typo meaning _q_utoq 
is missing), though since they don't get built with -mabi=ieeelongdouble 
they aren't actually usable.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: powerpc targets, long double implementation, and c++ programs

[Edmar Wienskoski]

Ok. I am starting to see the whole picture now.
So the whole thing appears to work with --disable-shared, just because 
the way the linker

loads symbols in presence of libgcc_s.so versus libgcc.a.

Follow up question:
The e500 abi actualy defines long double to be 128bits floats.
On rs6000.c, rs6000_init_libfuncs links to __gcc_qadd becasue of 
TARGET_HARD_FLOAT

shouldn't that be TARGET_HARD_FLOAT && TARGET_FPRS
and also have:
diff -u t-fprules-softfp~ t-fprules-softfp
--- t-fprules-softfp~   2006-08-09 14:20:24.0 -0500
+++ t-fprules-softfp2006-09-06 12:39:17.0 -0500
@@ -1,4 +1,4 @@
-softfp_float_modes := sf df
+softfp_float_modes := sf df tf
softfp_int_modes := si di
softfp_extensions := sfdf
softfp_truncations := dfsf

Would that be right ?

Thanks
Edmar



David Edelsohn wrote:


Soft-float implementation of long double support is in development
but not complete.  Long double requires double precision registers, so it
only will work with e500 double.  It also requires floating point
multiply-subtract (fmsub), which e500 double does not appear to
implement.  This is why long double has been disabled for e500 by testing
for __NO_FPRS__.  The soft-float support requires emulating fmsub, so it
might work on e500 as well at that point.

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01298.html is the
patch that disabled this.  This was in response to PR 26607 reported by
you.

The __lttf2 references occur similarly because the cmptf2 pattern
checks for TARGET_FPRS.  That could be relaxed for e500 double.

David


 

Re: powerpc targets, long double implementation, and c++ programs

[Joseph S. Myers]

On Fri, 8 Sep 2006, David Edelsohn wrote:

>   Soft-float implementation of long double support is in development
> but not complete.  Long double requires double precision registers, so it
> only will work with e500 double.  It also requires floating point
> multiply-subtract (fmsub), which e500 double does not appear to
> implement.  This is why long double has been disabled for e500 by testing
> for __NO_FPRS__.  The soft-float support requires emulating fmsub, so it
> might work on e500 as well at that point.
> 
>   http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01298.html is the
> patch that disabled this.  This was in response to PR 26607 reported by
> you.

Perhaps as an interim fix it should be more thoroughly disabled.  In 
particular, the ldblspecs

ldblspecs: specs
sed -e '/cc1_options/{ n; s/$$/ %{!msoft-float:-mlong-double-128}/; }' 
< specs > $@

are what causes the problematic references in the shared libgcc; E500 
targets may need different specs until the long double support is fixed.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

-T option

[Michael Eager]

GCC accepts the -T

Rebuild C code from GCC intermediate format

[Leonardo Mata]

Hello ALL!

I'm working in a project to automatic create parallel code for anthill
program model
http://homepages.dcc.ufmg.br/~dorgival/artigos/sbac2005.pdf

the goal is to translate a C uniq source into various C source files
that represent the parallelized code. I've been looking for a compiler
frontend to do that and i'm testing the SUIF compiler interface, but i
think gcc could be more powerfull and helpfull. I wish to use the
intermediate gcc format informations (cfg and SSA) to create the C
sources. I wish to know if there exists any plugin that translate
these intermediate format into C sources. I intent to modify these
intermediate formats and retranslate then into C source to anylise the
trasnsformations.

Thanks!

--

Leonardo Luiz Padovani da Mata
[EMAIL PROTECTED]

"May the force be with you, always" -   Obi-Wan Kenobi
"Nerd Pride... eu tenho. Voce tem?" - Rafael F. Alvarenga

Re: powerpc targets, long double implementation, and c++ programs

[David Edelsohn]

Soft-float implementation of long double support is in development
but not complete.  Long double requires double precision registers, so it
only will work with e500 double.  It also requires floating point
multiply-subtract (fmsub), which e500 double does not appear to
implement.  This is why long double has been disabled for e500 by testing
for __NO_FPRS__.  The soft-float support requires emulating fmsub, so it
might work on e500 as well at that point.

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01298.html is the
patch that disabled this.  This was in response to PR 26607 reported by
you.

The __lttf2 references occur similarly because the cmptf2 pattern
checks for TARGET_FPRS.  That could be relaxed for e500 double.

David

Re: powerpc targets, long double implementation, and c++ programs

[Joseph S. Myers]

On Fri, 8 Sep 2006, Edmar Wienskoski wrote:

> So the key questions are:
> 1 - What should I expect in regards to __lttf2 (and similar symbols).
> (like, when they should be defined, referenced, and when not)

They should not be defined or used at all.  IBM long double should use 
__gcc_*, and IEEE long double (not supported for Linux) should use _q_*.  
(Perhaps *tf* are appropriate for any functions for IEEE long double that 
don't have _q_ versions in the PowerPC SysV ABI.)

See .  As well as 
glibc patches, it includes a GCC patch from David Edelsohn to support IBM 
long double with soft-float.  For E500 single you'll need this patch, plus 
further changes to use the same helper functions for E500 single as for 
soft-float.  For E500 double you'll need to add machine description 
patterns like those that implement long double in terms of 6xx floating 
point.

> 2 - Why darwin-ldouble.c only generates code for __gcc_qadd if fp registers
> are present ?
> NOTE: The 8548 does have hardware instructions for implementing f.p. (s.p. and
> d.p.) but
> it uses the gp registers. So the definition of __NO_FPRS__ is correct for this
> target.

It requires fused multiply add instructions and has them hardcoded in an 
asm (two asms using fmsub).  To use with soft-float, fused multiply add 
support is needed in soft-fp, which shouldn't be hard to implement.  
Steven Munroe was working on this.  (Note that such patches would need to 
be accepted in glibc before new sources are imported into GCC, in 
accordance with the policy on imported sources.  As soft-fp maintainer for 
GCC I can only approve changes to soft-fp build support, not to the core 
code.)  It appears E500 double doesn't include fused multiply add support, 
so you'd need to use soft-fp for this case as well.

> 3 - Is the use of configuration option --disable-shared required for this
> target (because hardware differences
> like the lack of fp registers)  or am I just avoiding a problem that should be
> fixed ?

It's avoiding a problem.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

powerpc targets, long double implementation, and c++ programs

[Edmar Wienskoski]

I am confused with gcc configuration, and I cannot determine if I have a bug
or if I am misconfiguring the compiler. Here is the situation:

gcc sources: 4.2 snapshot of 20060905

If compiler is configured with:
--target=powerpc-*-linux-gnualtivec

then I have the following libraries and everything works fine:
/powerpc-unknown-linux-gnualtivec/lib/libgcc_s.so
   Defined __gcc_qadd (from darwin-ldouble.c) but no undefined references
   No references to __lttf2
/lib/gcc/powerpc-unknown-linux-gnualtivec/4.2.0/libgcc.a
   Defined __gcc_qadd (from darwin-ldouble.c) AND undefined references
   No references to __lttf2

If compiler is configured with:
--target=powerpc-*-linux-gnuspe --enable-e500_double --disable-shared

then I have the following libraries and everything still (!!) works fine:
No libgcc_s.so
/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/libgcc.a
   Only undefined references to __gcc_qadd (because this target defines 
__NO_FPRS__)

   Only undefined references to __lttf2 (why ?)

If compiler is configured with:
--target=powerpc-*-linux-gnuspe --enable-e500_double

then I have the following libraries, and most c++ and fortran code fails
to link with undefined symbols (among then, __gcc_qadd and __lttf2)
/lib/libgcc_s.so
   Only undefined references to __gcc_qadd
   Only undefined references to __lttf2

So the key questions are:
1 - What should I expect in regards to __lttf2 (and similar symbols).
(like, when they should be defined, referenced, and when not)
2 - Why darwin-ldouble.c only generates code for __gcc_qadd if fp 
registers are present ?
NOTE: The 8548 does have hardware instructions for implementing f.p. 
(s.p. and d.p.) but
it uses the gp registers. So the definition of __NO_FPRS__ is correct 
for this target.
3 - Is the use of configuration option --disable-shared required for 
this target (because hardware differences
like the lack of fp registers)  or am I just avoiding a problem that 
should be fixed ?


Any comments are welcome.
Thanks
Edmar

Re: Potential fix for rdar://4658012

[Josh Conner]

Sorry for my own slow response -- I've been doing more digging through
code, and didn't want to respond without a reasonable understanding...

Richard Kenner wrote:

>> However, in the case where we're passing the address of a temp slot to a
>> function, it doesn't make sense to me that this is the same as other
>> "address-of" operations on a stack slot.  The function call (at least in
>> C and C++) cannot preserve this address, and it is reasonable to say
>> that attempts to access this address after the caller is done with the
>> location, are invalid.
> 
> Here's where I disagree.  The issue isn't what the front-ends (and especially
> not a *subset* of the front-ends) do, but what they *are allowed* to do.
> 
> Going back to 3.4 for a moment, the question is whether you could
> create a valid tree where the address would survive.  And I think you can.
> All it would take is a machine like Sparc that passes all aggregates by
> reference is to have a CALL_EXPR with two operands that are each CALL_EXPRs
> of aggregate types.

Yes, this makes perfect sense.  I can envision a tree where removing
this code would create an invalid reuse of the stack slot.  However, we
are doing two things to preserve this temp -- marking it with
"addr_taken" and creating it with the "keep" bit set.  The former says
"promote this temp one level up", and the latter "keep this temp around
for the lifetime of the current block".  This still seems redundant.  I
think marking the temp as addr_taken is sufficient to handle the case
where the address is used as the input to a function call (see attached
patch).

Note that since Jason's recent change to the frontend here:

  http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00202.html

This change would be sufficient to address the remaining issues in
pr25505.  I'd like to hear your opinion of this, though, before
submitting it for approval.

> We never had a precise specification of what trees were valid then (which
> is precisely the set of valid GENERIC, and hence is similarly not very
> precisely defined), but I think almost everybody working on the 3.4 compiler
> would say that the above is valid whether or not C or C++ could generate it.
> Therefore, the middle-end had to properly support it.
> 
> However, in GCC 4, with tree-ssa, the RTL expanders receive a much smaller
> subset of trees, namely those defined in GIMPLE.  I *believe*, but aren't
> sure, that the above is not valid GIMPLE.
> 
> That would make the change safe.  But:
> 
> (1) The code we generate is pretty inefficient in the current case, since we
> copy the entire aggregate.  If we try to fix that, we *will* be preserving
> the address for later, though perhaps in a temporary more properly allocated.
> 
> (2) I suspect that we can rip out much more of this code than just this line
> and I'd prefer to do it that way.
> 
>> Hopefully this is enough of an explanation to reveal whether my
>> understanding is consistent or inconsistent with the experts, and can
>> move the discussion forward.
> 
> As I said once before, this code didn't change between 3.4 and 4.x, so
> something else is the cause of the regression.  I'd like to understand
> what that was.  I think you posted the changes you propose for the C
> and C++ front ends, but I don't remember what they were.

To help address your concerns about fixing the regression closest to its
point of change, I've also been looking into how this was handled in
3.4.  In that version of the compiler, a TARGET_EXPR was surviving all
the way until the expander, where the function expand_expr_real was
recognizing TARGET_EXPRs and generating a reusable temp.  Unfortunately,
I don't see an obvious correlation in 4.x, as the TARGET_EXPR never
reaches the expander, since gimplification has already converted it into
a CALL_EXPR.

Thanks again for taking the time to look into this.

- Josh


Index: gcc/calls.c
===
--- gcc/calls.c (revision 116642)
+++ gcc/calls.c (working copy)
@@ -1985,7 +1985,7 @@ expand_call (tree exp, rtx target, int i
/* For variable-sized objects, we must be called with a target
   specified.  If we were to allocate space on the stack here,
   we would have no way of knowing when to free it.  */
-   rtx d = assign_temp (TREE_TYPE (exp), 1, 1, 1);
+   rtx d = assign_temp (TREE_TYPE (exp), 0, 1, 1);
 
mark_temp_addr_taken (d);
structure_value_addr = XEXP (d, 0);

Re: gcc-4.2.0-20060906 stops compiling jikes-1.22 too.

[Andrew Pinski]

On Fri, 2006-09-08 at 15:40 +0200, Anny Blackyew wrote:
> The snapshot gcc-4.2.0-20060902 stops compiling jikes-1.22.tar.bz2.
> The snapshot gcc-4.2.0-20060906 stops compiling jikes-1.22.tar.bz2 too.

I think I just fixed this last night.  Can you try again?

Thanks,
Andrew Pinski

gcc-4.2.0-20060906 stops compiling jikes-1.22 too.

[Anny Blackyew]

The snapshot gcc-4.2.0-20060902 stops compiling jikes-1.22.tar.bz2.
The snapshot gcc-4.2.0-20060906 stops compiling jikes-1.22.tar.bz2 too.

It doesn't ocurr with gcc-3.3.6, gcc-4.1.2-20060901 and
gcc-4.0.4-20060831, they are OK.


$ gcc -v
Using built-in specs.
Target: i486-slackware-linux
Configured with: ./configure --prefix=/tools/gcc42 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking
--with-gnu-ld --verbose --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 4.2.0 20060906 (experimental)


export CFLAGS="-Os -fomit-frame-pointer -march=i486 -Wall -pipe"
export LDFLAGS="-Xlinker -s"
export LD_LIBRARY_PATH=/tools/gcc42/lib
./configure CC=gcc CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS"
--prefix=/tools/jikes
make && make install


set.cpp:17: error: variable-sized object 'SymbolSet::primes' may not
be initialized
set.cpp:17: error: storage size of 'SymbolSet::primes' isn't constant
set.cpp:191: error: variable-sized object 'SymbolMap::primes' may not
be initialized
set.cpp:191: error: storage size of 'SymbolMap::primes' isn't constant
make[2]: *** [set.o] Error 1
make[2]: Leaving directory .
make[1]: *** [all] Error 2
make[1]: Leaving directory .
make: *** [all-recursive] Error 1



Good good good bye


Obtenga su E-mail GRATUITO en http://www.clanomega.com
___
Get your own Web-based E-mail Service at http://www.zzn.com

Re: GCJ on Darwin/i386 patches

[Jack Howarth]

It is probably too late to get this resolved before gcc trunk branches
but we have an outstanding patch for building gcj on Darwin/386 awaiting
on Sandro Tolaini's paperwork being processed. He told me that he scanned
the form back to [EMAIL PROTECTED] but still hasn't heard back yet.
The reference number is [gnu.org #284334]. Could someone please check if
this can be cleared up so that we can proceed with pushing the patches
proposed in http://gcc.gnu.org/ml/java-patches/2006-q1/msg00347.html
into gcc trunk?
Jack

Re: Documentation for loop infrastructure

[Sebastian Pop]

Ira Rosen wrote:
> 
> > Here is the documentation for the data dependence analysis.
> 
> I can add a description of data-refs creation/analysis if it is useful.
> 

That's a good idea, thanks.

Sebastian

Re: New binutil target PE+ vista & xp64 and COFF format for cpu x86_64

[Roland Schwingel]

Hi...

[EMAIL PROTECTED] wrote on 08.09.2006 10:33:04:

> Hallo,
>
> I sent to binutils the patch for the new x86_64-pc-mingw64 as cross
> target.I was asked to post about this patch also to you. May this new
> target is of some interest to you and you can help me to verify this
> patch, because at the binutils there are not much windows users :|
>
> Best regards,
>  i.A. Kai Tietz
>
> PS: You can find the patch in the thread "Re: PE+ and new COFF format 
for

> x86_64 target for XP64 and Vista binaries"
> (I tested it with cygwin and linux environment)
The patch to binutils is posted here

http://sourceware.org/ml/binutils/2006-09/msg00036.html

We started to prepare the gnu toolchain to allow building 64bit windows
applications. This so affects binutils, gcc, mingw and also cygwin.

We have a bunch of this already running allowing to build native
64bit windows apps (mingw) so it is getting time to contribute our changes
back to the mainline, so other people can use it for their projects.

Kai Tietz is acting as lead developer for the changes to the gnu tool chain.
So main discussion will go over him. We are also in the phase of signing all
needed FSF assignments so all changes could safely be taken, if you are 
satisfied

with the way they were made.

As of the fact the changes are covering a big range and several projects 
it will

for sure take a considerable amount of time and needs to be coordinated.

i.A. Roland Schwingel

New binutil target PE+ vista & xp64 and COFF format for cpu x86_64

[Kai Tietz]

Hallo,

I sent to binutils the patch for the new x86_64-pc-mingw64 as cross 
target.I was asked to post about this patch also to you. May this new 
target is of some interest to you and you can help me to verify this 
patch, because at the binutils there are not much windows users :|

Best regards,
 i.A. Kai Tietz

PS: You can find the patch in the thread "Re: PE+ and new COFF format for 
x86_64 target for XP64 and Vista binaries"
(I tested it with cygwin and linux environment)

  Kai Tietz - Software engineering
  OneVision Software Entwicklungs GmbH & Co KG
  Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
  Phone: +49-941-78004-0
  FAX:   +49-941-78004-489
  WWW:   http://www.OneVision.com