ymm0 and xmm0 are the same register. xmm0 is the lower 128bit
of xmm0. I am not sure if we need separate XMM registers from
YMM registers.
Yes, I know that xmm0 is lower part of ymm0. I still think we ought to
be able to support varargs that do save ymm0 registers only when ymm
values are
On Fri, Jun 6, 2008 at 1:44 AM, Daniel Berlin [EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 5:57 AM, Jan Hubicka [EMAIL PROTECTED] wrote:
Jan Hubicka wrote:
Sure if it works, we should be lowering the types during gimplification
so we don't need to store all this in memory...
But C++ FE
Hello,
Working with putting together a Linux installer for an app (to work on
various Linux
versions), I got problems with libgcc_s.so (if distribution is not
based on gcc 4.x the app
won't start).
I wanted to remove dynamic linking to any C++ library (that is outside
of the installer).
The
6/6/2008, Arne Steinarson [EMAIL PROTECTED] napisał/a:
The shared libraries themselves still
have a dependency on libgcc_s.so:
$ ldd libwx_gtk2ud_fwb_core-2.9.so.0 | grep gcc
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb6ee8000)
you can use the -nodefaultlibs and manually add what you want.
On Fri, Jun 06, 2008 at 10:28:34AM +0200, Jan Hubicka wrote:
ymm0 and xmm0 are the same register. xmm0 is the lower 128bit
of xmm0. I am not sure if we need separate XMM registers from
YMM registers.
Yes, I know that xmm0 is lower part of ymm0. I still think we ought to
be able to
On Fri, Jun 6, 2008 at 4:28 PM, H.J. Lu [EMAIL PROTECTED] wrote:
On Fri, Jun 06, 2008 at 06:50:26AM -0700, H.J. Lu wrote:
On Fri, Jun 06, 2008 at 10:28:34AM +0200, Jan Hubicka wrote:
ymm0 and xmm0 are the same register. xmm0 is the lower 128bit
of xmm0. I am not sure if we need separate
On Fri, Jun 6, 2008 at 7:31 AM, Richard Guenther
[EMAIL PROTECTED] wrote:
On Fri, Jun 6, 2008 at 4:28 PM, H.J. Lu [EMAIL PROTECTED] wrote:
On Fri, Jun 06, 2008 at 06:50:26AM -0700, H.J. Lu wrote:
On Fri, Jun 06, 2008 at 10:28:34AM +0200, Jan Hubicka wrote:
ymm0 and xmm0 are the same
On Thu, Jun 05, 2008 at 07:31:12AM -0700, H.J. Lu wrote:
1. Extend the register save area to put upper 128bit at the end.
Pros:
Aligned access.
Save stack space if 256bit registers are used.
Cons
Split access. Require more split access beyond 256bit.
2. Extend the register
The shared libraries themselves still
have a dependency on libgcc_s.so:
$ ldd libwx_gtk2ud_fwb_core-2.9.so.0 | grep gcc
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb6ee8000)
you can use the -nodefaultlibs and manually add what you want.
e.g. you can link a static stlport with static gcc stuff
Hi all,
I was wondering if there is a configuration parameter for gcc that would
prevent it from using an assembler and linker. I have a port of
gcc 4.0.2 for an experimental architecture and I have my own assembler
and linker. Currently I am compiling gcc with binutils compiled for MIPS
but
I want to point out that the current implementation of lto is not
compatible with ln -r, and will need to be modified to support
cherry picking the function bodies.
In the current implementation, each lto section (such as what holds
a function body or the streamed information from an ipa pass)
I want to point out that the current implementation of lto is not
compatible with ln -r, and will need to be modified to support
cherry picking the function bodies.
I assume you mean ld -r, right ?
Arno
Arnaud Charlet wrote:
I want to point out that the current implementation of lto is not
compatible with ln -r, and will need to be modified to support
cherry picking the function bodies.
I assume you mean ld -r, right ?
Arno
yes, of course. Dennis Richie's curse: two letter commands.
Status
==
The GCC 4.3 branch is now again open for commits under normal release
branch rules.
GCC 4.3.1 has been tagged, tarballs and diffs are on gcc.gnu.org and
so far partly on ftp.gnu.org. The announcement will go out after the
weekend to let mirrors sync it up.
We got quite a lot of
2) LTO sections need to be able to find their index of decls and
types. By their index I mean the index that each section used to
reference the decls and types when the section was generated.
Can't you just put an ELF symbol (can be an unnamed local -- could
even just be a section symbol)
I think that one of the goals here is to not make that too dependent on elf.
For instance, we are in the process of getting rid of all of the dwarf.
After maddox does that, our only dependence on elf will be as a container
to hold all of the sections.
Given that gcc is not always an elf
Yep, my request to [EMAIL PROTECTED] just bounced, so I will live with a random
number.
Thanks,
Stephen
- Original Message
From: Michael Meissner [EMAIL PROTECTED]
To: Stephen Andieta [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Sent: Wednesday, June 4, 2008 7:44:30 AM
Subject: Re: How to
Let me second H.J.'s suggestion to post your request at
http://groups.google.com/group/generic-abi
In the absence of any SCO presence, that group now serves as the
closest thing we have to a standards forum for ELF and the gABI.
-cary
Snapshot gcc-4.4-20080606 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080606/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 6 Jun 2008, Stephen Andieta wrote:
Yep, my request to [EMAIL PROTECTED] just bounced, so I will live
with a random number.
caldera.com doesn't have an MX record whereas sco.com does, so maybe it's
a problem with that old domain. Try Dave Prosser [EMAIL PROTECTED] directly
-
he
I'm suggesting that there's no big difference between unsigned char and
unsigned int (and unsigned long...) in this case, and, therefore
compiler's behaviour should be consistent.
But there is a difference.
When x is an unsigned int, the expression x 0 is equivalent to
(unsigned int)
Hello all,
The 16bit target that i am porting to gcc4.1.2 doesn't have any
instructions for 32bit operations. But for addition and subtraction
there is
addc
subc
instructions that consider carry bit also. Presently i have patterns
for SImode addition and subtraction such that the template will
--- Comment #7 from jakub at gcc dot gnu dot org 2008-06-06 08:03 ---
Ok, I'll bootstrap/regtest patch 1).
To answer your question about 2), consider e.g.:
__attribute__((noinline))
void foo (int, int)
{
static int n = 0;
void *esp;
asm volatile (movl %%esp, %0 : =r (esp));
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-06-06 08:26 ---
Currently doing reghunt: r134936 works, r135050 fails.
Expect more results later ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
--- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de
2008-06-06 08:30 ---
Thanks!
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
--- Comment #3 from hutchinsonandy at aim dot com 2008-06-06 11:55 ---
Subject: Re: simplify_subreg ICE with right shift more than
length type AVR
Thanks for quick response,
I will give this a try and no doubt it will work.
I was trying to think of how the other case should be
--- Comment #10 from jakub at gcc dot gnu dot org 2008-06-06 12:14 ---
Doesn't --with-pic build just one set of *.o files? If yes, then you are out
of luck, either configure libstdc++ without symbol versioning, or you need to
use
a version script when linking --with-pic libstdc++.a
--- Comment #14 from joel at gcc dot gnu dot org 2008-06-06 13:16 ---
ChangeLog entry for gcc-svn-ada-hwint-20080606.diff. Patch does not
remove s-interr-vxworks.adb. As part of review please
diff -u s-interr-vxworks.adb s-interr-hwint.adb You should only
see changes to eliminate
--- Comment #7 from jakub at gcc dot gnu dot org 2008-06-06 13:23 ---
Subject: Bug 36362
Author: jakub
Date: Fri Jun 6 13:23:04 2008
New Revision: 136434
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136434
Log:
PR target/36362
* gimplify.c (gimplify_expr) case
--- Comment #8 from jakub at gcc dot gnu dot org 2008-06-06 13:25 ---
Subject: Bug 36419
Author: jakub
Date: Fri Jun 6 13:24:45 2008
New Revision: 136435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136435
Log:
PR rtl-optimization/36419
* except.c
Please refer to the attached example.
When the struct 'ZIP' in this example is enlarged by one word,
G++ silently generates incorrect code.
--
Summary: Incorrect code generated for access to a large struct
Product: gcc
Version: 4.1.2
Status:
--- Comment #1 from jjk at acm dot org 2008-06-06 13:28 ---
Created an attachment (id=15725)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15725action=view)
C++ code for reproducing the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36449
/there.pentium4/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc -c
libc/stdlib/strtod.c -o libc/stdlib/strtod.os -include ./include/libc-symbols.h
-Wall -Wstrict-prototypes -fno-strict-aliasing -Wnested-externs -Wshadow
-Wmissing-noreturn -Wmissing-format-attribute -Wformat=2
--- Comment #1 from aldot at gcc dot gnu dot org 2008-06-06 14:40 ---
Created an attachment (id=15726)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15726action=view)
original testcase from uClibc
ira-branch revision 136341
Works with -fno-ira
works with
--- Comment #5 from aldot at gcc dot gnu dot org 2008-06-06 14:44 ---
maybe provoking PR36450 although this one is about a slightly different thing
AFAICS?
I'm curious if you can build your distro with -O3 and -Os ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36028
--- Comment #7 from uros at gcc dot gnu dot org 2008-06-06 15:06 ---
Subject: Bug 36438
Author: uros
Date: Fri Jun 6 15:04:51 2008
New Revision: 136486
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136486
Log:
PR rtl-optimization/36438
* cse.c (fold_rtx)
Hi,
The links for the documentation for __mt_allocator and bitmap_allocator on
page:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt04ch11.html
point to:
http://gcc.gnu.org/onlinedocs/libstdc++/ext/mt_allocator.html
http://gcc.gnu.org/onlinedocs/libstdc++/ext/ballocator_doc.html
On i686-apple-darwin9, building libgomp fails with:
libtool: compile: /opt/gcc/i686-darwin/./gcc/xgcc
-B/opt/gcc/i686-darwin/./gcc/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem
--- Comment #2 from derek dot white at sun dot com 2008-06-06 16:08 ---
Not a duplicate of bug 5738 (?)
I don't think this can be handled by GCSE code hoisting. The previous example
have the common subexpression independent of anything else, so code could be
hoisted or delayed. But
testcase:
=== Cut ===
#if !defined(BOOST_PP_IS_ITERATING)
#elif BOOST_PP_ITERATION_DEPTH() == 1
#endif
=== Cut ===
error: missing binary operator before token (
from reading the PR36320, this behaviour doesn't seem to be intended. It was
intended to only add a check for non-null argument.
--- Comment #2 from davidxl at google dot com 2008-06-06 18:00 ---
(In reply to comment #1)
The failures disappear with the following patch:
--- /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/cdce3.C2008-06-05
08:50:23.0 +0200
+++
--- Comment #3 from dominiq at lps dot ens dot fr 2008-06-06 18:17 ---
I wonder why gcc.dg/cdce1.c and gcc.dg/cdce2.c do not fail in the same way?
Because the tests pass (as far as I can tell from the tests
oni686-apple-darwin9).
--
--- Comment #2 from eric dot weddington at atmel dot com 2008-06-06 19:24
---
Andy, I'm having a difficulty in trying to reproduce this bug. I use this
command line:
avr-gcc -O1 -mmcu=atmega128 -w -std=gnu99 -c memcpy-chk.c -o memcpy-chk.o
But I'm using WinAVR 20080512, which is
--- Comment #9 from jakub at gcc dot gnu dot org 2008-06-06 19:27 ---
Subject: Bug 36362
Author: jakub
Date: Fri Jun 6 19:26:53 2008
New Revision: 136495
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136495
Log:
PR target/36362
* gimplify.c (gimplify_expr) case
--- Comment #10 from jakub at gcc dot gnu dot org 2008-06-06 19:30 ---
Subject: Bug 36419
Author: jakub
Date: Fri Jun 6 19:29:28 2008
New Revision: 136496
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136496
Log:
PR rtl-optimization/36419
* except.c
--- Comment #10 from jakub at gcc dot gnu dot org 2008-06-06 19:41 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from hutchinsonandy at aim dot com 2008-06-06 19:42 ---
Subject: Re: ICE push_reload - psuedo reg_equiv_constant
O2
--
Sent from my Dingleberry wired device.
-Original Message-
From: eric dot weddington at atmel
--- Comment #4 from eric dot weddington at atmel dot com 2008-06-06 19:48
---
Test case passes with -O[0123s], with WinAVR 20080512 (patched 4.3.0).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36336
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at redhat dot com
OtherBugsDependingO|
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-06 20:07 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-06-06 20:07
---
Subject: Bug 36262
Author: rguenth
Date: Fri Jun 6 20:06:40 2008
New Revision: 136501
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136501
Log:
2008-06-06 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-06-06 20:07
---
Subject: Bug 34244
Author: rguenth
Date: Fri Jun 6 20:06:40 2008
New Revision: 136501
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136501
Log:
2008-06-06 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-06 20:13
---
Subject: Bug 36291
Author: rguenth
Date: Fri Jun 6 20:12:27 2008
New Revision: 136502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136502
Log:
2008-06-06 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from hutchinsonandy at aim dot com 2008-06-06 20:18 ---
Subject: Re: ICE push_reload - psuedo reg_equiv_constant
The patch for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
removes one problematic part of LEGITIMIZE_RELOAD_ADDRESS. This is
applied to WinAVR
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-06 20:21
---
See PR36291 for a slightly different testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
--- Comment #1 from tromey at gcc dot gnu dot org 2008-06-06 20:23 ---
By my reading of the standard, issuing an error here is correct.
The restrictions on #elif are only lifted if it is in a skipped group.
But, in this case, it is not.
--
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-06 20:26
---
Fixed. The remaining slowness is a dup of PR33237.
Memory usage on the branch is now down to ~700MB peak VM usage on a 3GB machine
at -O on x86_64. Compile time is down to
tree find ref. vars : 12.26 (10%)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36404
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36405
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
--- Comment #1 from andreast at gcc dot gnu dot org 2008-06-06 20:31
---
Subject: Bug 36452
Author: andreast
Date: Fri Jun 6 20:30:31 2008
New Revision: 136503
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136503
Log:
2008-06-06 Andreas Tobler [EMAIL PROTECTED]
PR
--- Comment #15 from eric dot weddington at atmel dot com 2008-06-06 20:39
---
This bug report is completely unclear. 'static const' will not be overloaded to
imply that a variable is stored in flash. The relevant C language draft
concerning mulitple memory spaces will have to be
--- Comment #5 from hjl dot tools at gmail dot com 2008-06-06 21:02 ---
From:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00350.html
the problem isn't limited to --disable-bootstrap.
--
hjl dot tools at gmail dot com changed:
What|Removed
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot
|dot org
--- Comment #2 from andreast at gcc dot gnu dot org 2008-06-06 21:07
---
Should be fixed now.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2008-06-06 21:09 ---
You only see it your system compiler is gcc 4.3 or above
[EMAIL PROTECTED] tmp]$ cat x.c
#include limits.h
[EMAIL PROTECTED] tmp]$ GCC_EXEC_PREFIX=/foo gcc -M x.c
In file included from x.c:1:
--- Comment #11 from dino at concisoft dot com 2008-06-06 21:13 ---
Created an attachment (id=15727)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15727action=view)
A relatively simple self contained piece of code that reproduces the problem.
Please see the comments in the
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-06 21:32
---
Looks more like one of the known alias related miscompilations of the 4.1
branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
It seems that the standard (or at least the standard literature) is not clear
on this one, but Sun and Intel compilers agree that it's good.
The problem we have is actually about a derived type that gets two different
alias names in USE/ONLY statements. In the end, it should be treated as two
--- Comment #1 from thomas dot orgis at awi dot de 2008-06-06 21:45 ---
Oh, btw: I reckon that this is independent of host system, but for reference: I
tested this on x86-64-linux (gfortran 4.1.2 or such) and x86-linux (4.2.3 and
4.3.0).
--
thomas dot orgis at awi dot de changed:
--- Comment #7 from mmitchel at gcc dot gnu dot org 2008-06-06 22:59
---
We set GCC_EXEC_PREFIX when testing in-tree GCC because we want the GCC we're
testing to search the right paths.
Note that in creating site.exp, we do:
@echo set GCC_EXEC_PREFIX \$(libdir)/gcc/\ ./tmp0
--- Comment #10 from dannysmith at gcc dot gnu dot org 2008-06-07 00:40
---
Subject: Bug 35921
Author: dannysmith
Date: Sat Jun 7 00:39:43 2008
New Revision: 136515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136515
Log:
PR target/35921
* optimize.c
--- Comment #11 from dannysmith at users dot sourceforge dot net
2008-06-07 00:46 ---
Fix backported to branch.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2008-06-07 01:06 ---
(In reply to comment #7)
We set GCC_EXEC_PREFIX when testing in-tree GCC because we want the GCC we're
testing to search the right paths.
How does gcc search the right paths when GCC_EXEC_PREFIX points
to
gcc 3.4.6 evaluates wrong size for dynamic size arrays (hence binaries compiled
with it can yield wrong results or even segfault)
In the example source code below, the second array is incorrectly interpreted
by the code generated by gcc 3.4.6 as if it were at a different location than
it actually
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-07 01:55 ---
Considering 3.4.x is no longer support and this works in 4.1.2, there is not
much todo here really as far as I can tell.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from ghazi at gcc dot gnu dot org 2008-06-07 04:02 ---
What remains to be done for this PR?
The generic FP classification implementations are all done, including builtin
fpclassify(). Perhaps some optabs still need to be finished? Or can we close
this one?
--
--- Comment #11 from cnstar9988 at gmail dot com 2008-06-07 04:04 ---
Ping...
I have attached config.log for a few days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
80 matches
Mail list logo