Daniel,
Thanks for the answer.
You need to show us your configure arguments to be sure. I bet
you're specifying just --host.
You are right, the configure I am using since some time is:
ConfigureParams: --prefix=%p/lib/gcc4 --disable-multilib
--enable-languages=c,c++,fortran,objc,java
I have written:
Would something like
--build=%m-apple-darwin`uname -r|cut -f1 -d.`
work?
Apparently it works.
Thanks
Dominique
Hi,
Am Donnerstag, 8. Februar 2007 13:18 schrieben Sie:
Thank you very much. After reading the abstract, I'm highly
interested in this work, because they also use GCC and SPEC CPU2000,
as I'm planning to do...
Which benchmarks did you test on?
I testet it on freebench-1.03, nbench-byte-2.2.2
Joe Buck writes:
On Sat, Feb 10, 2007 at 12:49:56AM -0500, David Edelsohn wrote:
Tom Tromey writes:
Tom David probably knows this, but for others, Jakub and Andrew put in a
Tom patch for this today. I think it is only on trunk, not any other
Tom branches.
Should this
On Fri, 2007-02-09 at 13:36 -0800, Mark Mitchell wrote:
GCC 4.1.2 RC2 is now available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070208
and its mirrors.
On a recent ubuntu x86_64 system, with c,ada,c++,fortran,java,objc:
http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00377.html
Ian Lance Taylor wrote:
Jie Zhang [EMAIL PROTECTED] writes:
But now gcc seems to optimize it away. For the following function:
$ cat t.c
#include limits.h
void foo (int rc)
{
int x = rc / INT_MAX;
x = 4 / x;
}
I believe we still keep division by zero in general. In your example
it gets
On 2/10/07, Robert Dewar [EMAIL PROTECTED] wrote:
Ian Lance Taylor wrote:
Jie Zhang [EMAIL PROTECTED] writes:
But now gcc seems to optimize it away. For the following function:
$ cat t.c
#include limits.h
void foo (int rc)
{
int x = rc / INT_MAX;
x = 4 / x;
}
I believe we still
On 2/10/07, Jie Zhang [EMAIL PROTECTED] wrote:
The code I posted in my first email is from libgloss/libnosys/_exit.c.
It's used to cause an exception deliberately. From your replies, it
seems it should find another way to do that.
Maybe you can use __builtin_trap() ?
Gr.
Steven
Jie Zhang wrote:
The code I posted in my first email is from libgloss/libnosys/_exit.c.
It's used to cause an exception deliberately. From your replies, it
seems it should find another way to do that.
Any code that tries to raise an exception deliberately is certainly
depending on undefined
On 2/10/07, Robert Dewar [EMAIL PROTECTED] wrote:
Jie Zhang wrote:
The code I posted in my first email is from libgloss/libnosys/_exit.c.
It's used to cause an exception deliberately. From your replies, it
seems it should find another way to do that.
Any code that tries to raise an
On 2/10/07, Steven Bosscher [EMAIL PROTECTED] wrote:
On 2/10/07, Jie Zhang [EMAIL PROTECTED] wrote:
The code I posted in my first email is from libgloss/libnosys/_exit.c.
It's used to cause an exception deliberately. From your replies, it
seems it should find another way to do that.
Maybe
Michael Gong [EMAIL PROTECTED] writes:
I don't know about inserting call at the basic block level, but I am
quite sure inserting calls at the function level could be done by
aspect-oriented-programming (AOP). [...]
Another possibility, coming soon[1], is to use systemtap[2] probes:
% stap
if test ${build} != ${host}; then
some defaults
else
AC_PROG_CC
fi
AC_TRY_COMPILE
ac_objext is set at the expansion of AC_PROG_CC and if you take the if
branch, it never gets set.
Does anyone reading this know what the right thing to do is? Is there
anything in the autoconf
I'm going to use an asm ().
Yeah, an asm volatile ( : : r (x) : ) should please GCC and still be
portable to different platforms.
Paolo
On Sat, Feb 10, 2007 at 05:08:10PM +0100, Paolo Bonzini wrote:
if test ${build} != ${host}; then
some defaults
else
AC_PROG_CC
fi
AC_TRY_COMPILE
ac_objext is set at the expansion of AC_PROG_CC and if you take the if
branch, it never gets set.
Does anyone reading this know what
Did I miss anything? What are the relative advantages of each
solutions? Do you think that I overlooked other options? Would using
an exiting virtual machine be a good option? Except for Nice, this
option doesn't seem to be popular; there must be a catch.
You might want to have a look at
This seems horribly wrong somehow. Aren't we intested in the ${build}
- ${host} compiler at this point anyway? So shouldn't we be testing
it? I think the whole block can go.
Hmm, it says indeed this is going to change when we autoconfiscate.
Something like this?
Index: configure.ac
- Original Message -
From: Frank Ch. Eigler [EMAIL PROTECTED]
To: Michael Gong [EMAIL PROTECTED]
Cc: GERIN Patrice [EMAIL PROTECTED]; Jan Hubicka
[EMAIL PROTECTED]; gcc@gcc.gnu.org
Sent: Saturday, February 10, 2007 10:21 AM
Subject: Re: Inserting profiling function calls
Michael
On Sat, Feb 10, 2007 at 06:59:35PM +0100, Paolo Bonzini wrote:
This seems horribly wrong somehow. Aren't we intested in the ${build}
- ${host} compiler at this point anyway? So shouldn't we be testing
it? I think the whole block can go.
Hmm, it says indeed this is going to change when
The discussion is becoming to technical for me.
Let me just say that adding --build=%m-apple-darwin`uname -r|cut -f1 -d.`
to config allowed me to build gcc without further glitch.
I guess it will do no harm to keep this addition even if it
becomes no longer necessary.
Thanks for the help
On 02/09/2007 12:18 PM, Larry Evans wrote:
[snip]
compiler. When just using --enable-checking=yes, I was able to
use gdb to find that the value of __FILE__ was corrupted:
(gdb) up
#1 0x0809e6eb in tsubst (t=0x4034f8a0, args=0x40351ca8, complain=3,
in_decl=0x4032eea0) at
On 2/11/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
I'm going to use an asm ().
Yeah, an asm volatile ( : : r (x) : ) should please GCC and still be
portable to different platforms.
I thought using an asm () for each port to cause an exception specific
for that port. Such that divide-by-zero
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-10 09:16 ---
*** This bug has been marked as a duplicate of 15179 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-02-10 09:16
---
*** Bug 28182 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-10 09:17 ---
*** This bug has been marked as a duplicate of 15179 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-02-10 09:17
---
*** Bug 30754 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-10 09:27 ---
When I see PASS: gcc.dg/tree-ssa/loop-25.c (test for excess errors)
I wonder what is the extra message because I think that warning/error is most
likely the issue with this testcase.
--
There is a daily bump in
branches/gcc-4_0-branch/libstdc++-v3/include/bits/c++config
This not neccessary, because the 4_0-branch is closed
--
Summary: Daily bump in branches/gcc-4_0-branch/libstdc++-
v3/include/bits/c++config
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-10 09:40 ---
*** This bug has been marked as a duplicate of 18754 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-02-10 09:40
---
*** Bug 30697 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hp at gcc dot gnu dot org 2007-02-10 10:46 ---
I don't understand comment #1. There *are* no excess errors or extra
messages. That's why that part says PASS. That's also out of scope for this
PR: the reason for it, is the two FAILs. See the test. It still fails
--- Comment #6 from aph at gcc dot gnu dot org 2007-02-10 11:01 ---
Definitely a 32-bit only issue:
zorro:/tmp/Fail $
~/gcc/trunk/obj-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/gij
-cp main.jar F
class Z
[EMAIL PROTECTED]
zorro:/tmp/Fail $
--- Comment #7 from aph at gcc dot gnu dot org 2007-02-10 11:50 ---
Created an attachment (id=13029)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13029action=view)
It's a patch!
This is the correct patch. The key here is that it is never correct for one
VMStackWalker method to
--- Comment #2 from hans dot buchmann at fhso dot ch 2007-02-10 12:17
---
Inserting the line
const unsigned Class::MAX_LEN=16;
results in the message
const-test.cc:13: error: duplicate initialization of 'Class::MAX_LEN'
When I place the declaration outside the class the Symbol
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-10 12:28 ---
Fixed by Zdenek.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Recent gcc snapshots fail with the following testcase:
cat bug.c
double log(double x);
void f() { unsigned char a = log(0); }
gcc -march=athlon-xp -mfpmath=sse bug.c
bug.c: In function 'f':
bug.c:2: error: unrecognizable insn:
(insn 11 10 12 3 (set (reg:SI 61)
(fix:SI (reg:DF 58 [
--- Comment #2 from debian-gcc at lists dot debian dot org 2007-02-10
13:21 ---
the testcase is from the debian package csound, which builds fine with current
4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25588
--- Comment #8 from aph at gcc dot gnu dot org 2007-02-10 14:23 ---
Subject: Bug 30742
Author: aph
Date: Sat Feb 10 14:22:54 2007
New Revision: 121798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121798
Log:
2007-02-10 Andrew Haley [EMAIL PROTECTED]
PR java/30742
--- Comment #9 from aph at gcc dot gnu dot org 2007-02-10 14:36 ---
Subject: Bug 30742
Author: aph
Date: Sat Feb 10 14:36:28 2007
New Revision: 121799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121799
Log:
2007-02-10 Andrew Haley [EMAIL PROTECTED]
PR java/30742
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-02-10 15:07
---
the testcase is from the debian package csound, which builds fine with current
4.1.
The 4.0 branch is now closed. Reopen if you can reproduce with 4.x x=1.
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2007-02-10 15:10
---
Fixed in upcoming 4.1.2, the 4.0 branch is now closed.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2007-02-10 15:17
---
Not user-visible in 4.1.x.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-10 15:49 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2007-02-10 16:20
---
(In reply to comment #21)
Here's a much cleaner patch, which makes us give slightly worse error messages
than before.
Thanks for taking care of this, Tobias. I'm not sure I think the second patch
is cleaner,
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-10 16:22
---
Would you have time to backport it? I don't know if it was approved for 4.2
also, but if it applies cleanly and regtest OK, I don't see a reason to hold
it.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-02-10 16:23
---
Fixed, don't you think?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-10 16:38
---
(In reply to comment #5)
Please feel free to backport this and (eventually) all other i left unfixed
for
non-trunk versions that you may want to fix. Thank you very much for your
time!
PS: Also, feel
--- Comment #29 from fxcoudert at gcc dot gnu dot org 2007-02-10 17:24
---
Hi Dominique,
Patch posted (http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00927.html), so you
look how it's done. Patches in PR tend to not get reviewed, so we need people
to post them to the list. Yes, it takes
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Target Milestone|--- |4.3.0
--- Comment #3 from aldot at gcc dot gnu dot org 2007-02-10 19:01 ---
Created an attachment (id=13030)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13030action=view)
add gcov-iov.h to the prerequisited of libbackend.o
Patch against the gcc-4_2-branch
--
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-02-10 19:08
---
I have the backport ready and i am testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24783
gcc 4.3 svn version 10/02/2007
when running make check I get 2 ICE
Same result when compiling manually:
/opt/gcc43/bin/gcc -O3 -g -o maya mayalias-2.c
mayalias-2.c:2: erreur interne du compilateur: dans splice_child_die, à
dwarf2out.c:5584
no problem without the -g option
same thing with
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-10 19:23 ---
*** This bug has been marked as a duplicate of 28834 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-02-10 19:23
---
*** Bug 30758 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from danglin at gcc dot gnu dot org 2007-02-10 19:51
---
Subject: Bug 30634
Author: danglin
Date: Sat Feb 10 19:51:40 2007
New Revision: 121802
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121802
Log:
PR target/30634
* pa.md (movdf): For 64-bit
--- Comment #14 from danglin at gcc dot gnu dot org 2007-02-10 19:54
---
Subject: Bug 30634
Author: danglin
Date: Sat Feb 10 19:54:33 2007
New Revision: 121803
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121803
Log:
PR target/30634
* pa.md (movdf): For 64-bit
Current GCC accepts the following
struct A {
A(int) { }
};
int main()
{
A a = { 6 };
}
which is invalid.
This is a regression from GCC-3.3.x
--
Summary: initializer-list accepted for object of non-POD type
Product: gcc
Version: 4.3.0
Status:
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-02-10 19:57 ---
sum is also missing:
$ cat sum.f90
program main
integer(kind=1), dimension(2,2) :: a
a = 1
print *,sum(a,dim=2)
end program main
$ gfortran sum.f90
/tmp/ccQgrJa3.o: In function `MAIN__':
--- Comment #15 from rakdver at gcc dot gnu dot org 2007-02-10 20:07
---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00931.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
the parisc constraints cannot be found in the Machine Constraints page:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Machine-Constraints.html
from gcc/config/pa/:
#define REG_CLASS_FROM_LETTER(C) \
((C) == 'f' ? FP_REGS : \
(C) == 'y' ? FPUPPER_REGS : \
--- Comment #15 from danglin at gcc dot gnu dot org 2007-02-10 20:24
---
Fixed by patch on 4.2 and trunk.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from patchapp at dberlin dot org 2007-02-10 20:25 ---
Subject: Bug number PR30478
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00933.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-10 21:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-10 21:12 ---
The definition have to be not inialized if it was already initialized in the
declaration
The declaration is the one which is inside the class, the definition which is
the one which defines the memory space is the
--- Comment #4 from patchapp at dberlin dot org 2007-02-10 21:15 ---
Subject: Bug number PR30319
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00939.html
--
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-10 21:18
---
Paul, I take it you are aware of PR21881 (Array descriptors limit derived type
sizes)... I don't fully grasp the way array descriptor work for derived types,
but I wanted to mention that PR to you... just in
--- Comment #30 from dominiq at lps dot ens dot fr 2007-02-10 22:12 ---
Subject: Re: ICE in LOGICAL(8) functions
Francois-Xavier,
Thanks for the work. In order to improve future contributions,
I have a few questions:
(1) do you need a regtesting of the patch on 4.2 and OSX 10.4?
--- Comment #31 from fxcoudert at gcc dot gnu dot org 2007-02-10 22:21
---
(In reply to comment #30)
(1) do you need a regtesting of the patch on 4.2 and OSX 10.4?
Will 4.2.0 20070124 good enough or should I upgrade to a more
recent version?
It's OK. The change is simple and that
--- Comment #32 from pinskia at gcc dot gnu dot org 2007-02-10 22:42
---
This was on my list of patches to submit today really, I finally actually got
time to able to submit patches today. I was able to submit two other patches
today and I have another one in testing right now.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-10 22:43 ---
Testing the fix right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30433
--- Comment #33 from dominiq at lps dot ens dot fr 2007-02-10 22:44 ---
Subject: Re: ICE in LOGICAL(8) functions
Thanks for the advice, I'll try to follow it next time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-02-10 23:26
---
Subject: Bug 24783
Author: jvdelisle
Date: Sat Feb 10 23:25:55 2007
New Revision: 121804
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121804
Log:
2007-02-10 Bernhard Fischer [EMAIL PROTECTED]
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-02-10 23:30
---
Subject: Bug 24783
Author: jvdelisle
Date: Sat Feb 10 23:30:38 2007
New Revision: 121806
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121806
Log:
2007-02-10 Bernhard Fischer [EMAIL PROTECTED]
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-02-11 00:25
---
Subject: Bug 24783
Author: jvdelisle
Date: Sun Feb 11 00:25:44 2007
New Revision: 121812
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121812
Log:
2007-02-10 Bernhard Fischer [EMAIL PROTECTED]
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-02-11 00:27
---
Subject: Bug 24783
Author: jvdelisle
Date: Sun Feb 11 00:26:56 2007
New Revision: 121813
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121813
Log:
2007-02-10 Bernhard Fischer [EMAIL PROTECTED]
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-02-11 00:28
---
Fixed on 4.1 and 4.2 now. Backported
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ggiordano at verizon dot net 2007-02-11 01:44 ---
Subject: Re: Error when trying to compile under DOS on a Vista
machine
I had already installed DJGPP at work and it worked fine (Windows 2K). I
installed it at home on my XP system and it didn't work. I installed
--- Comment #1 from bangerth at dealii dot org 2007-02-11 03:51 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2007-02-11 03:55 ---
As one data point: if it indeed finds the local function foo, then one
could think that declaring the friend as
friend T ::foo(const CTest test);
might work (note the explicit global scope on the function name). Alas:
--- Comment #1 from bangerth at dealii dot org 2007-02-11 03:56 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bangerth at dealii dot org 2007-02-11 03:57 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2007-02-11 04:07 ---
I also can't reproduce this with
bangerth/x /tmp/bangerth/bin/bin/c++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../svn/configure --enable-checking --enable-languages=c,c++
--- Comment #2 from bangerth at dealii dot org 2007-02-11 04:11 ---
As Andrew said: this is a violation of the C++ standard. You can have
only one definition of a name and if you have more then your program is
in error. The fact that you mark your functions inline doesn't change
this:
--- Comment #1 from bangerth at dealii dot org 2007-02-11 04:12 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #3 from bangerth at dealii dot org 2007-02-11 04:16 ---
(In reply to comment #2)
I thought (according to the ARM) that all functions of a template class were
implicitly function templates.
No, you confuse class member templates with class template members :-)
--- Comment #6 from rwgk at yahoo dot com 2007-02-11 05:30 ---
I immediately believe that Andrew's and Wolfgang's findings are accurate, but I
never claimed that the mainline has a problem. I never even tried it.
My interest it to make sure that our code works with any new gcc release,
--- Comment #4 from igodard at pacbell dot net 2007-02-11 06:04 ---
Thank you. Is that obscure or what :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30624
--- Comment #14 from grgoffe at yahoo dot com 2007-02-11 06:13 ---
Subject: Re: build of gcc midi-dssi fails
Tom,
Thanks for your help and the info.
Any time you need to test something just let me know, I'll help if I can.
Regards,
George...
--- tromey at gcc dot gnu dot org
--- Comment #5 from bangerth at math dot tamu dot edu 2007-02-11 06:22
---
Subject: Re: ignores explicit qualification
--- Comment #4 from igodard at pacbell dot net 2007-02-11 06:04 ---
Thank you. Is that obscure or what :-)
No, I think that was pretty straightforward!
89 matches
Mail list logo
