Sorry Tom, I find opening bugs often tedious..sign up an account, fill in a
bunch of fields..
I'll try to get more details "later" (if it repros consistently, callstack in a
debugger)
- Jay
> To: Jayk
> CC: gcc
> Subject: Re: gcj/sparc64?
> From: Tom
> Date: Thu, 24 Jul 2008 08:49:13 -
I think this one is an actual bug, somewhat "predictable" (easy to realize what
the problem is roughly),
easy for the appropriate folks to fix, easy for affected folks to workaround.
It goes *like* (this is a paraphrase!):
get a "working" system -- cygwin gcc 3.x in my case, but the problem
I dunno, this seems like a thing you could better figure out by
trying
it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no design, but that it would be better to
start with a design and iterate it than try to figure out per
* Ben Elliston <[EMAIL PROTECTED]> [2008-07-25 09:17]:
> OK, I give up. What is the point of your messages and why is it the
> GCC list that you've chosen to bother with them?
FWIW, he sent the same (at least) to debian-devel. I'd just ignore it.
--
Martin Michlmayr
http://www.cyrius.com/
OK, I give up. What is the point of your messages and why is it the GCC
list that you've chosen to bother with them?
Ben
Snapshot gcc-4.3-20080724 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080724/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I want to be with you http://209.62.250.161/
Le lundi 21 juillet 2008 à 15:37 +0200, Stelian Pop a écrit :
> I have a problem with the jump instructions: my direct jumps are very
> limited in displacements, and I want to always generate indirect jumps
> instead.
Ok, no answer yet.
Does this mean that my question is really dumb ?
Or does t
On Thu, Jul 24, 2008 at 12:48:30PM -0700, Daniel Berlin wrote:
> The easiest way to not delete trunk is to not delete trunk.
Yes of course, but mistakes do happen.
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
On Thu, Jul 24, 2008 at 09:35:26AM -0700, Steve Ellcey wrote:
>
> All of my bootstraps except x86 Linux failed last night. Both
> HP-UX builds and my IA64 Linux build. This was with version
> 138102. I tried to find out when the failure started and ran
> into some odd things. If I go back t
Arnaud Charlet wrote:
I do not know Fortran but from the description above, this is similar in Ada:
you cannot freely mix different pointers, and you cannot make a pointer out
of any variable, unless variables are marked 'aliased'. This semantic is
already expressed today in GCC trees, so I'm not
Daniel Berlin wrote:
On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
I thought the whole idea of the LTO project was to keep as much language
specific type information as late as possible. If you start stripp
>> I do not know Fortran but from the description above, this is similar in Ada:
>> you cannot freely mix different pointers, and you cannot make a pointer out
>> of any variable, unless variables are marked 'aliased'. This semantic is
>> already expressed today in GCC trees, so I'm not sure what m
On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
>>>
>>> I thought the whole idea of the LTO project was to keep as much language
>>> specific type information as late as possible. If you start stripping out
>>> useful
On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
I thought the whole idea of the LTO project was to keep as much
language specific type information as late as possible. If you
start stripping out useful information about types, it becomes
harder to do high level optimizations like devirt
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> >> Anyway, there must be other uses of types in either the existing middle end
> >> or that people have dreams of adding to the middle end in the future. Now
> >> is the time to raise your hand before the design has been started.
Hi,
for me its grea
On Thu, Jul 24, 2008 at 09:24:48PM +0100, Richard Sandiford wrote:
> > - I've dropped support for a non-fixed $gp. This is a handy
> > optimization, but it was getting in the way and it was the part of the
> > GCC patch Richard had the most comments on. I can resubmit it after
> > everything else
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> - Richard's ld -r support is an addition to the ABI, but does not
> conflict with anything else, so I included it. I discovered two
> potential problems:
>
> - If a symbol with STO_MIPS_PIC is localized using objcopy,
> binutils will ignore the f
On Thu, Jul 24, 2008 at 12:16:20PM -0400, Daniel Jacobowitz wrote:
> I have attached
Let's all pretend I attached this glibc patch, instead of the one in
my previous message, please.
--
Daniel Jacobowitz
CodeSourcery
2008-07-24 Mark Shinwell <[EMAIL PROTECTED]>
Daniel Jacobowitz <[EMAIL
The easiest way to not delete trunk is to not delete trunk.
On Thu, Jul 24, 2008 at 10:06 AM, Peter Bergner <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-07-24 at 18:48 +0200, Andreas Schwab wrote:
>> Definitely something fishy around that time. svn log says:
>>
>> --
Andrew Pinski wrote:
gcc -c -ohw.o hw.c
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11810 .
There was a patch posted here:
Thanks for the information. In looking at this further, I think I've
found a simple way to solve the problem.
In particular, we already have a macro SWITCH
Arnaud Charlet wrote:
In this same vein, I am very interested in using the gimple type
system as a way to start moving gcc from being a C compiler that
accommodates other languages to a compiler that handles different
languages on an equal footing. The freedom that C and C++ "enjoy" to
basically
Chris Lattner wrote:
On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote:
3) Generate the debugging for the types late. The problem here is
that we want the gimple type system to be stripped of the front end
specific information, so any front end specific info that is only
necessary for the
On Thu, Jul 24, 2008 at 1:03 AM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Dennis Clarke wrote:
>>The Sun Studio 12 compiler with Solaris 10 on AMD Opteron or
>>UltraSparc beats GCC in almost every single test case that I have
>>seen.
>
> This is memcpy on Solaris:
> http://src.opensolaris.org/source/
Joseph S. Myers wrote:
On Thu, 24 Jul 2008, Basile STARYNKEVITCH wrote:
At last, at the recent (july 2008) GCC summit, someone (sorry I forgot who,
probably someone from SuSE) proposed in a BOFS to have architecture and
machine specific hand-tuned (or even hand-written assembly) low level
libra
On Thu, 2008-07-24 at 18:48 +0200, Andreas Schwab wrote:
> Definitely something fishy around that time. svn log says:
>
>
> r138082 | meissner | 2008-07-23 13:18:03 +0200 (Mi, 23 Jul 2008) | 1 line
>
> Add missing ChangeLog
On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote:
3) Generate the debugging for the types late. The problem here is
that we want the gimple type system to be stripped of the front end
specific information, so any front end specific info that is only
necessary for the debugging, will both b
On Thu, Jul 24, 2008 at 06:48:56PM +0200, Andreas Schwab wrote:
> $ svn diff -c138078
> svn: Unable to find repository location for '' in revision 138077
> $ svn diff -c138077
> svn: The location for '' for revision 138077 does not exist in the repository
> or refers to an unrelated object
>
> Ap
Steve Ellcey <[EMAIL PROTECTED]> writes:
> I also tried updating to 138077 at one point and that version number
> doesnt' seem to exist:
>
> $ svn update -r138077
> svn: Target path does not exist
>
> At least I think that is what this error means.
>
> What is going on?
Definitely som
Hi Steve,
That is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
H.J.
On Thu, Jul 24, 2008 at 9:35 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
>
> All of my bootstraps except x86 Linux failed last night. Both
> HP-UX builds and my IA64 Linux build. This was with version
> 138102. I tried
> In this same vein, I am very interested in using the gimple type
> system as a way to start moving gcc from being a C compiler that
> accommodates other languages to a compiler that handles different
> languages on an equal footing. The freedom that C and C++ "enjoy" to
> basically take a pointe
All of my bootstraps except x86 Linux failed last night. Both
HP-UX builds and my IA64 Linux build. This was with version
138102. I tried to find out when the failure started and ran
into some odd things. If I go back to version 138070 and
then update my tree to 138076 I see a bunch of file
I have been working on a design for gimple types. The overall plan is
to gimplify the types, as we gimplify the executable code. Then we
can release the front end types and recover the space.
There are difficulties with this plan and most of them have to do with
the generation of debug informa
Basile STARYNKEVITCH wrote:
>At last, at the recent (july 2008) GCC summit, someone (sorry I forgot
who, probably someone from SuSE)
> proposed in a BOFS to have architecture and machine specific
hand-tuned (or even hand-written assembly) low
> level libraries for such basic things as memset et
Joseph S. Myers wrote:
>I don't know if it was proposed in this context, but the ARM EABI has
>various __aeabi_mem* functions for calls known to have particular
>alignment and the idea is relevant to other platforms if you provide such
>functions with the compiler. The compiler could also generat
Hello all,
I am involved in the porting of GCC 4.1.2 for a 16 bit target. The
target doenst have any SImode comparisons. Most of the time SImode
comparisons are synthesized using HImode comparisons. But some in some
instances SImode patterns are generated like that, where the code is
expanded in t
Hi,
I'm trying to compile and link a product that was already compiled and
linked successfully before, on AIX5.3 with gcc3.4.6, but I got the
following link err:
"collect2: ld returned 12 exit status"
Pls note that this happens to me only when not using the strip flag
(-s) since I need the symbol
> "Jay" == Jay <[EMAIL PROTECTED]> writes:
Jay> This is an incomplete bug report.
Jay> unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree:
Jay> -bash-3.00$ gcc -v
Jay> Using built-in specs.
Jay> Target: sparc-sun-solaris2.10
[...]
Jay> /.libs/HTML_401F.o
Jay> gcj: Internal err
On Thu, 24 Jul 2008, Basile STARYNKEVITCH wrote:
> At last, at the recent (july 2008) GCC summit, someone (sorry I forgot who,
> probably someone from SuSE) proposed in a BOFS to have architecture and
> machine specific hand-tuned (or even hand-written assembly) low level
> libraries for such basi
Say pieces on a board, make each piece a pair with another piece.
like...
|55|33|66|
|44|66|55|
|33|44|22|
|22|11|11|
a piece can only be figured out to move one way...
pick any piece, try to move it somewhere...
have the chosen piece move to another piece, it moves there and makes
the other
On Thu, Jul 24, 2008 at 3:28 PM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Basile STARYNKEVITCH wrote:
>>At last, at the recent (july 2008) GCC summit, someone (sorry I forgot who,
>> probably someone from SuSE)
That was me and Michael Matz.
Richard.
Hello all,
I have endian problems using the reference operator (&),
the deference operator (*) or the element deference operator (->)
together witch data structs which are compiled using pack(1).
The problems appear onlx if these data structs are located within
the litlle endian part of the mem
Basile STARYNKEVITCH wrote on 24 July 2008 11:28:
> On most Linux systems, in addition of using the package manager, the
> libc.so file is executable, and when executed, shows info, so on my
> Debian/Sid/AMD64 I'm getting
>
> % /lib/libc.so.6
> GNU C Library stable release version 2.7, by Rolan
Dave Korn wrote:
Agner Fog wrote on 24 July 2008 09:04:
Tim Prince wrote:
>you identify the library you tested only as "ubuntu g++ 4.2.3."
Where can I see the libc version?
Use whichever package manager ubuntu provides to check the version of the
glibc package. Here's an example fron a ce
The tuples branch is ready for merging to trunk if we can address a
few remaining issues. The branch currently bootstraps and tests
on i586-linux, x86_64-linux, ppc-linux, ppc64-linux, ia64-linux
and s390x-linux. It fails to bootstrap on s390-linux (it fails
during stage3 gcc configure, appearan
starting from build i686-pc-cygwin
build native
build host i686-pc-cygwin target sparc-sun-solaris2.10 -with-sysroot
and then host sparc-sun-solaris2.10 target sparc-sun-solaris2.10
installing with destdir = /usr/local/sparc-sun-solaris2.10/install
fixincludes took
d:\cygwin\u
Agner Fog wrote on 24 July 2008 09:04:
> Tim Prince wrote:
> >you identify the library you tested only as "ubuntu g++ 4.2.3."
> Where can I see the libc version?
Use whichever package manager ubuntu provides to check the version of the
glibc package. Here's an example fron a centos (using rpm
> [...]
> I have made a few optimized functions myself and published them as a
> multi-platform library (www.agner.org/optimize/asmlib.zip). It is
> faster than most other libraries on an Intel Core2 and up to ten
> times faster than gcc using builtin functions. My library is
> published with GPL
This is an incomplete bug report.
unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree:
-bash-3.00$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /home/jay/src/gcc/configure
Thread model: posix
gcc version 4.3.1 (GCC)
~/src/gcc/configure
Dennis Clarke wrote:
>The Sun Studio 12 compiler with Solaris 10 on AMD Opteron or
>UltraSparc beats GCC in almost every single test case that I have
>seen.
This is memcpy on Solaris:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/i386/gen/memcpy.s
It uses exactly the sam
50 matches
Mail list logo
