On Tue, Apr 13, 2010 at 07:18:12PM +0200, Paolo Bonzini wrote:
> On 04/13/2010 07:14 PM, Jack Howarth wrote:
>> Paolo,
>> I hope you don't think I was trolling in my initial post. Assuming
>> plugins will eventually be welcomed into the FSF gcc source tree in
&g
On Tue, Apr 13, 2010 at 12:21:09PM -0700, Andrew Pinski wrote:
> On Tue, Apr 13, 2010 at 10:22 AM, Steven Bosscher
> wrote:
> > There are already plugins in the FSF gcc source tree. Well, OK, just
> > one (lto-plugin) but there aren't very many plugins at the moment that
> > are suitable for incl
On Wed, Apr 14, 2010 at 12:57:41AM +0200, Steven Bosscher wrote:
> On Sun, Apr 11, 2010 at 4:17 PM, Jack Howarth
> wrote:
> > Rather than viewing dragon-egg as some sort
> > of lamprey which is feeding off of the FSF gcc project,
> > we should welcome the competition
On Wed, Apr 14, 2010 at 08:24:35AM +0200, Duncan Sands wrote:
> Hi Steven,
>
>> FWIW, this sounds great and all... but I haven't actually seen any
>> comparisons of GCC vs. LLVM with DragonEgg. A search with Google
>> doesn't give me any results.
>>
>> Can you point out some postings where people a
On Mon, Apr 19, 2010 at 11:23:35AM +0200, Basile Starynkevitch wrote:
>
...
> I am not a native english speaker, but something like the following
> paragraph [to be added after the paragraph: GCC 4.5.0 is now capable
> of "link-time optimization". ... and equally significant reductions in
> code
On Wed, Apr 21, 2010 at 05:52:03PM +0200, Paolo Bonzini wrote:
> On 04/19/2010 03:35 PM, Jack Howarth wrote:
>> The annoucement should probably note that targets which lack
>> objdump currently can't build plugins. I've had about as much
>> luck getting the
On Wed, Apr 21, 2010 at 07:22:47PM +0200, Steven Bosscher wrote:
> On Wed, Apr 21, 2010 at 7:09 PM, Jack Howarth
> wrote:
> > On Wed, Apr 21, 2010 at 05:52:03PM +0200, Paolo Bonzini wrote:
> >> On 04/19/2010 03:35 PM, Jack Howarth wrote:
> >>> The anno
On Wed, Apr 21, 2010 at 07:10:21PM +0200, Paolo Bonzini wrote:
>> Well your review does pretty much amount to "because darwin lacks
>> objdump like linux, the patch is rejected...".
>
> Please reread.
Paolo,
You say...
> The patch is not okay, it is if you use "nm -g" on Darwin only.
However
On Wed, Apr 21, 2010 at 07:48:36PM +0200, Paolo Bonzini wrote:
> On 04/21/2010 07:42 PM, Jack Howarth wrote:
>> However in the past when I submitted patches for areas outside
>> of the darwin specific source files, they were rejected*if* they
>> made the code too darwin-centr
On Wed, Apr 21, 2010 at 07:22:47PM +0200, Steven Bosscher wrote:
> On Wed, Apr 21, 2010 at 7:09 PM, Jack Howarth
> wrote:
> > On Wed, Apr 21, 2010 at 05:52:03PM +0200, Paolo Bonzini wrote:
> >> On 04/19/2010 03:35 PM, Jack Howarth wrote:
> >>> The anno
On Wed, Apr 21, 2010 at 08:07:48PM +0100, Jonathan Wakely wrote:
> On 3 April 2010 00:16, Jack Howarth wrote:
> >
> > Jonathan,
> > The test program when compiled as i386 randomly hangs under both the
> > 32-bit and 64-bit
> > kernels on Darwin 10.3.0. I
On Thu, Apr 22, 2010 at 12:44:42AM +0200, Paolo Bonzini wrote:
> On Thu, Apr 22, 2010 at 00:35, Andreas Schwab wrote:
> > Paolo Bonzini writes:
> >
> >> I'm not sure if "nm -g" would work under Linux, since
> >>
> >> $ nm -g /usr/lib64/libsqlite3.so
> >> nm: /usr/lib64/libsqlite3.so: no symbols
>
On Thu, Apr 22, 2010 at 01:39:21AM +0200, Paolo Bonzini wrote:
> > Paolo,
> > We don't have -D in our nm. How about the following change to
> > configure.ac?
>
> Ok. See? ;-)
>
> As a followup, if you have access to a Linux machine you can try
> removing the objdump requirement altogether.
>
I believe I have a fix for PR43839 (where the jni.exp
script doesn't honor --with-iconv as set during the build).
The following patch *almost* works...
Index: testsuite/Makefile.in
===
--- testsuite/Makefile.in (revision 1586
On Thu, Apr 22, 2010 at 10:38:18AM +0200, Rainer Orth wrote:
> Jack Howarth writes:
>
> > Index: configure.ac
> > ===
> > --- configure.ac(revision 158487)
> > +++ configure.ac(working
Looking at the results of the tests executed
by plugin.exp on x86_64 Fedora 10, I don't see
any evidence that -rdynamic is ever used. Can't
we reduce the tests performed as follow since
only -shared appears to be actually used? Removing
these tests would eliminate all of the problems
with not h
On Thu, Apr 22, 2010 at 07:38:04AM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> >Looking at the results of the tests executed
> > by plugin.exp on x86_64 Fedora 10, I don't see
> > any evidence that -rdynamic is ever used.
>
> On GNU/L
On Thu, Apr 22, 2010 at 05:12:19PM +0200, Richard Guenther wrote:
> On Thu, Apr 22, 2010 at 5:08 PM, Jack Howarth
> wrote:
> > On Thu, Apr 22, 2010 at 07:38:04AM -0700, Ian Lance Taylor wrote:
> >> Jack Howarth writes:
> >>
> >> > Looking at t
On Thu, Apr 22, 2010 at 08:44:32PM +0200, Rainer Orth wrote:
> Jack Howarth writes:
>
> >Have you built gcc trunk with --enable-plugin on either
> > Solaris or Irix? What is the expectation of which compiler is
>
> No need: plugins just work on both platforms, bo
I am wondering why we don't default on --enable-plugin
in gcc 4.6 (and perhaps 4.5.1) for those hosts that are
known to have working testsuite results of plugin.exp?
The additional overhead for building the plugin support is
close to nil and the user has to explicitly invoke the loading
of a com
On Fri, Apr 23, 2010 at 08:43:41AM -0700, Diego Novillo wrote:
> On 4/23/10 06:50 , Jack Howarth wrote:
> >I am wondering why we don't default on --enable-plugin
> > in gcc 4.6 (and perhaps 4.5.1) for those hosts that are
> > known to have working testsuite results o
On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote:
> Jack Howarth wrote:
> > Does anyone know why gdb appears to be unable to find the debug
> > information
> > for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported
> >
On Fri, Oct 03, 2008 at 08:29:40PM -0500, Peter O'Gorman wrote:
> Jack Howarth wrote:
> > On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote:
> >> Jack Howarth wrote:
> >>> Does anyone know why gdb appears to be unable to find the debug
>
The problem build was at r141079 so perhaps that change could be
at fault...
Author: hjl
Date: Sun Oct 12 21:44:33 2008
New Revision: 141079
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141079
Log:
2008-10-12 H.J. Lu <[EMAIL PROTECTED]>
Backport from mainline:
2008-
We have some new regressions on i686-apple-darwin9...
FAIL: gcc.target/i386/opt-1.c (internal compiler error)
FAIL: gcc.target/i386/opt-1.c (test for excess errors)
ERROR: gcc.target/i386/opt-1.c: error executing dg-final: couldn't open
"opt-1.s": no such file or directory
FAIL: gcc.target/i386
Current gcc trunk has a bootstrap failure on i686-apple-darwin9 with
a failure at...
gcc -I../../gcc-4.4-20081026/libcpp -I.
-I../../gcc-4.4-20081026/libcpp/../include
-I../../gcc-4.4-20081026/libcpp/include -g -fkeep-inline-functions -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-p
On Sun, Oct 26, 2008 at 09:51:44PM +0100, Andreas Tobler wrote:
> Geoff Keating wrote:
>
>> Does everyone really type --with-mpfr= on every build? Looking@
>> gcc-testresults, I see:
>>
>> Kaveh: yes
>> Joey Ye: no
>> HJ: no
>> Guerby: yes
>> Andreas Jaeger: no
>> Dave Anglin: no
>> Janis: yes
I am baffled by this regression in the stage 1 bootstrap of libcpp on
current gcc trunk. When I build gcc as we always have in fink using...
../gcc-4.4-20081026/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortra
n,objc
I am finding that if I explicitly set CPPFLAGS in my gcc trunk build,
the bootstrap failure disppears however I end up with three instances of
-I/sw/include in many compile lines. This requirement of setting CPPFLAGS
did not exist up to at least 20081016. I suspect this was caused by...
---
Can anyone explain if the recent change in Apple dropping their
NDA will have any impact on the GPLv3 issue with Apple and FSF?
http://www.macgeekery.com/column/eloquent_apathy/apple_removes_iphone_sdk_nda
The posted information here about FSF's views on GPLv3 and the iPhone SDK
seemed to focu
On Fri, Oct 31, 2008 at 02:30:25PM -0700, Andrew Pinski wrote:
> I get the following build failure on i386-apple-darwin8.11.1.
>
>
> libtool: link: /Users/apinski/src/local/gcc/objdir/gcc/gcj
> -B/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.11.1/libjava/
> -B/Users/apinski/src/local/gcc
On Sat, Nov 01, 2008 at 11:14:14AM +, Andrew Haley wrote:
> Jack Howarth wrote:
> > On Fri, Oct 31, 2008 at 02:30:25PM -0700, Andrew Pinski wrote:
> >> I get the following build failure on i386-apple-darwin8.11.1.
> >>
> >>
> >> libtool: link
What are the rules for porting patches back from the graphite
branch that fix ICEs when -fgraphite is used to compile code?
There doesn't seem to have been much movement of patches out of
the graphite branch lately.
Jack
On Tue, Nov 04, 2008 at 05:37:02PM +0100, Roberto Bagnara wrote:
>
> It has been released: see
>
> http://www.cs.unipr.it/pipermail/ppl-announce/2008/21.html
>
> All the best,
>
>Roberto
>
> --
> Prof. Roberto Bagnara
> Computer Science Group
> Department of Mathematics, University of Pa
The darwin-specific gcc.dg/cpp/subframework1.c -fno-show-column test case
is failing under gcc trunk for the excessive errors test because we now
get warnings...
warning: #import is a deprecated GCC extension
Is there a particular way to modify an excessive errors test case to
have a particula
On Thu, Nov 20, 2008 at 11:17:52AM +0100, Paolo Carlini wrote:
> Hi,
> > Should this be XFAILed on powerpc64-apple-darwin9?
> A patch doing that is essentially preapproved if you can confirm that in
> the meanwhile the malloc bug (Radar 3884894) has been fixed for
> i386-apple-darwin and not for po
On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote:
> hi,
>
> a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc.
> However, I'm finding a huge number of failures with g++ caused by the
> fact that __Unwind_GetIPInfo is not defined.
>
> When 'make checking', I conventiona
On Mon, Nov 24, 2008 at 11:59:03AM +, IainS wrote:
> Hello Jack,
> On 21 Nov 2008, at 18:35, Jack Howarth wrote:
>
>> On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote:
>>> When 'make checking', I conventionally move the built libgcc_s.
>>> 1.dy
On Wed, Nov 26, 2008 at 01:22:35PM -0800, Geoffrey Keating wrote:
> Jack Howarth <[EMAIL PROTECTED]> writes:
>
> > Iain,
> >The use of the system libgcc simply won't work on Mac OS X 10.4.
> > The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dy
Doug,
Is there a reason why prune.exp is loaded in lib/gcc.exp and lib/g++.exp
but never actually used? I need to prune a linker warning with..
regsub -all "(^|\n)ld: warning: can't make compact unwind encoding from dwarf
for \[^\n\]* in \[^\n\]*" $text "" text
on x86_64-apple-darwin10 to sup
When will gcc switch from autoconf 2.59 to
autoconf 2.61? Both darwin and the newer linux
releases have migrated to the newer autoconf.
Is that a change slated for gcc 4.5?
Jack
We seem to have developed a number of c++ regression on
powerpc-apple-darwin8.5.0 which weren't present in r142401...
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00311.html
...that are now present in r142425...
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00311.html
These new failur
On Thu, Dec 04, 2008 at 12:17:38PM -0500, Jack Howarth wrote:
>We seem to have developed a number of c++ regression on
> powerpc-apple-darwin8.5.0 which weren't present in r142401...
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00311.html
>
> ...that are
Under powerpc-apple-darwin9, these new failures appear as...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081204/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc44-4.3.999-20081204/darwin_objdir/gcc/testsuite/g+
+/../../
/sw/src/fink.build/gcc44-4.3.999-20081204/gc
On Wed, Dec 10, 2008 at 08:27:50AM +, IainS wrote:
> Hi all,
>
> ref: http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html, PR32765 and
> http://gcc.gnu.org/ml/fortran/2008-12/ msg00118.html
>
> NOTE to gurus: the whole libgcc_eh, libgcc_s.{10.x, 1} thing is quite
> hard to understand.
> I sear
On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote:
>
> On 10 Dec 2008, at 14:43, Jack Howarth wrote:
>
>> shipped by Apple with its OS releases. I think what you want to do
>> make sure you are using the FSF libgcc's and not the system ones
>
On Wed, Dec 10, 2008 at 06:23:18PM +, IainS wrote:
>
> On 10 Dec 2008, at 18:10, Mike Stump wrote:
>
>> On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
>>>> If I now understand correctly, the symbols present in updated
>>>> versions of
>>>&g
On Wed, Dec 10, 2008 at 07:39:35PM +, IainS wrote:
>
> On 10 Dec 2008, at 19:05, Jack Howarth wrote:
>
>> On Wed, Dec 10, 2008 at 06:23:18PM +, IainS wrote:
>>>
>>> On 10 Dec 2008, at 18:10, Mike Stump wrote:
>>>
>>>> On Dec 10,
On Wed, Dec 10, 2008 at 02:36:22PM -0800, Geoff Keating wrote:
>
> On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:
>
>> On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote:
>>>
>>> On 10 Dec 2008, at 14:43, Jack Howarth wrote:
>>>
>>>> s
On Wed, Dec 10, 2008 at 04:13:45PM -0800, Geoff Keating wrote:
>
> On Dec 10, 2008, at 3:24 PM, IainS wrote:
>
>> Thanks Geoff,
>> that's v. useful doc.
>>
>> On 10 Dec 2008, at 22:36, Geoff Keating wrote:
>>
>>>
>>> On Dec 10, 2008, at
On Wed, Dec 10, 2008 at 11:24:28PM +, IainS wrote:
> Thanks Geoff,
> that's v. useful doc.
>
> On 10 Dec 2008, at 22:36, Geoff Keating wrote:
>
>>
>> On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:
>>
>>> On Wed, Dec 10, 2008 at 02:55:11PM +,
On Thu, Dec 11, 2008 at 12:38:11PM +, IainS wrote:
...
>
> I have a hunch that this is, at least partially, the origin of sporadic
> failures in crayptr2 (which has been one of the very few tests using tls
> so far - because all the rest have been UNSUPPORTED by the fails in dg
> target supp
c 4.3 or 4.4 for
Snow Leopard.
Jack
On Thu, Dec 11, 2008 at 05:29:16PM +, IainS wrote:
>
> On 11 Dec 2008, at 13:51, Jack Howarth wrote:
>
>> On Thu, Dec 11, 2008 at 12:38:11PM +, IainS wrote:
>> ...
>>>
>>> I have a hunch
On Fri, Dec 12, 2008 at 12:01:07PM -0800, Mike Stump wrote:
> On Dec 10, 2008, at 3:24 PM, IainS wrote:
>> if one did -lgcc_s.10.x -lgcc_s.1 would that break it?
>> ... should it not pick up only the unresolved symbols from s.1
>
> I think this is the best long term solution. Things that can be
Between r142699 and r142726, we seemed to have broken the bootstrap
on i686-apple-darwin9. I now see a failure when linking the -m64 version
of libgfortran...
libtool: compile:
/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/gfortran
-B/sw/src/fink.build/gcc44-4.3.999-20081212/
I have narrowed the failure down a bit. Revision 142713 bootstraps
okay on i686-apple-darwin9 but revision 142715 fails at the same
place in the linkage of the -m64 version of libgfortran. I will
back up to revision 142714 next to confirm that the problem was
introduced with...
---
Well, I am baffled. Revision 142714 fails as well so that
revision 142715 can't be at fault for the bootstrap failure
of -m64 libgfortran on i686-apple-darwin9. The strange part
is that I don't see anything in the remaining revision 142714
which could possibly be interacting with the build of
lib
Manually executing make in gcc44-4.3.999-20081212/darwin_objdir after a
failed build of gcc trunk on i686-apple-darwin9 produces...
make[5]: Nothing to be done for `all'.
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/sw/src/fink.build/gcc44-4.3.999-20081212/darwin_objdir/./gcc/xgcc
-
At revision r142799 on i686-apple-darwin9, I am seeing a few
new regressions...
FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_
...at -m32 and -m64 as well as...
FAIL: abi/demangle/regression/cw-16.cc execution test
at -m32 in the libstdc++-v3 testsuite. Should we op
The regress tester for powerpc-apple-darwin8.5.0 has been failing...
FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess
Currently i686-apple-darwin9 appears in very good shape for
gcc 4.4 with the exception of one new set of testsuite failures
related to the new stackalignment changes. These all share the
commmon feature of only failing with the -O3 -g compiler option
flags...
FAIL: g++.dg/torture/stackalign/eh-a
On Tue, Jan 20, 2009 at 05:50:35PM -0800, H.J. Lu wrote:
> On Tue, Jan 20, 2009 at 3:29 PM, Jack Howarth
> wrote:
> > Currently i686-apple-darwin9 appears in very good shape for
> > gcc 4.4 with the exception of one new set of testsuite failures
> > related to the ne
On Wed, Jan 21, 2009 at 11:59:09AM -0800, Mike Stump wrote:
> On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote:
>>> Sure, in i386/darwin.h we have:
>>>
>>> /* Since we'll never want a stack boundary less aligned than 128 bits
>>> we need the extra work here otherwise bits of gcc get very grumpy
>>>
Is anyone seeing this on other targets? With the gcc trunk
from 20090219, I am finding that the gcc.c-torture/execute/va-arg-trap-1.c
testcase ICEs on the compilation. The exact error is...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20090219/darwin_objdir/gcc/xgcc
-B/sw/src/fink.buil
On Fri, Feb 20, 2009 at 06:08:36PM +, Joseph S. Myers wrote:
> My guess would be that some of the code for handling va_list being an
> array is needed in the case of generating a trap as well.
>
> if (TREE_CODE (have_va_type) == ARRAY_TYPE)
> {
> if (TREE_CODE (TREE_TYPE (
I noticed the following on darwin10, since it builds
with x86_64 as the default where appropriate. The
libiberty testsuite is building with the system compiler
instead of the one from gcc trunk...
make[2]: [check-objc] Error 1 (ignored)
make[2]: Nothing to be done for `check'.
make[2]: Nothing to
The same issue in the libiberty testsuite run can be seen with
the Apple regress server log at
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip.
If you search for test-demangle, you will find...
+ make -j2 -k check
autogen -T /Users/regress/tbox/svn-gcc/fixincludes/check.tpl
/Users/re
While compiling the current pymol svn with gcc trunk
I ran across a compilation warning...
Ortho.c: In function 'OrthoFree':
Ortho.c:1973: warning: array subscript is above array bounds
which doesn't seem to make sense. The reduced test case that
triggers it with -O3 -Wall is...
#define CMD_Q
On Thu, Mar 05, 2009 at 03:56:18AM +, Dave Korn wrote:
> Jack Howarth wrote:
>
> > Ortho.c: In function 'OrthoFree':
> > Ortho.c:1973: warning: array subscript is above array bounds
>
> > #define CMD_QUEUE_MASK 0x3
>
> >CQueue
On Thu, Mar 05, 2009 at 10:05:15AM +0100, Manuel López-Ibáñez wrote:
> 2009/3/5 Dave Korn :
> >
> > of an array that only has size[4] is going one past the end. So the bug is
> > the missing warning for the simplified testcase, not that the warning is
> > somehow incorrect in the more complex one.
I think we may have a regression in gcc trunk
on i686-apple-darwin9. We seem to be failing the
following testcase in current gcc trunk (r144825)...
Running
/sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-20090312/gcc/testsuite/gcc.dg/dg.exp
...
FAIL: gcc.dg/asm-b.c (test for excess errors)
What about allowing for more backports from the graphite
branch if this drags out for an extended period of time? In
particular, I am thinking of those changes in graphite branch
that might reduce those cases where -fgraphite-identity
degrades the performance of the resulting code.
Does anyone know why the gcc.gnu.org ftp site
is no longer available? Oddly it seems to have
also disappeared for at least one of the ftp
mirrors in the last day as well...
ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc
Are we supposed to access the gcc infrastructure
directories from
The gcc.gnu.org ftp server is back up. However, the newer
cloog-ppl-0.15.tar.gz in the infrastructure directory is broken
on darwin. The size is now much smaller which makes me suspect that
autogen.sh wasn't run before the tarball was created. On darwin,
the build fails with...
/bin/sh ./libtoo
sable-libjava-multilib
--build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10
--target=x86_64-apple-darwin10
The changes to make this work were checked in at...
r142370 | andreast | 2008-12-02 13:05:24 -0500 (Tue, 02 Dec 2008) | 5 lines
2008-12-02 Andreas Tobler
Jack Ho
I see one place where breakage may have occured...
http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/configure.ac?r1=144881&r2=144887
--- trunk/configure.ac 2009/03/16 13:23:13 144881
+++ trunk/configure.ac 2009/03/16 17:02:02 144887
@@ -446,11 +446,11 @@
*-*-chorusos)
nocon
On Thu, Apr 09, 2009 at 11:35:36AM +0200, Paolo Bonzini wrote:
> Jack Howarth wrote:
> >I see one place where breakage may have occured...
> >
> > http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/configure.ac?r1=144881&r2=144887
> >
> > --- trunk/
Paolo,
Mike Stump's view was that darwin1 and darwin2 should be
ignored since they can't build FSF gcc for other reasons.
The idea was to fix these cases for the foreseeable future
by using darwin[921]* as the match. I also tested the patch
with a build of i686-apple-darwin9 and the results are
Roberto,
I am finding the following when I build my ppl-10.1
packaging in fink...
Validating .deb dir /sw/src/fink.build/root-ppl-shlibs-0.10.1-1...
Error: Shlibs field says compatibility version for /sw/lib/libppl.7.dylib is
8.0.0, but it is actually 9.0.0.
Error: package contains the shared
On Wed, Apr 15, 2009 at 02:44:12PM +0200, Richard Guenther wrote:
> On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth
> wrote:
> > Roberto,
> > I am finding the following when I build my ppl-10.1
> > packaging in fink...
> >
> > Validating .deb dir /sw/src
On Wed, Apr 15, 2009 at 04:36:04PM +0200, Roberto Bagnara wrote:
> Jack Howarth wrote:
>> On Wed, Apr 15, 2009 at 02:44:12PM +0200, Richard Guenther wrote:
>>> On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth
>>> wrote:
>>>> [...]
>>>> It se
On Thu, Apr 16, 2009 at 02:08:32PM +0200, Roberto Bagnara wrote:
>
> All the problems of PPL 0.10.1 we are aware of have been
> fixed in the snapshot of PPL 0.10.2 available at
>
> ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
>
> In particular here is what has changed:
>
> - Correctly detect GMP 4.
A couple changes in gcc 4.4.0 were omitted for
the darwin target. The gcc 4.4.0 release now supports
a full multilib build on the x86_64-apple-darwin9 and
x86_64-apple-darwin10 targets. The gfortran compiler
is now capable of generating binaries linked against
the static libgfortran library usin
On Fri, Apr 24, 2009 at 08:30:37AM -0500, Sebastian Pop wrote:
> On Fri, Apr 24, 2...@08:12, Robert Dewar wrote:
> >> What would we have to do to make PPL and CLooG required to build GCC?
> >
> > Why would that be desirable? Seems to me the current situation is
> > clearly preferable.
>
> To enab
Janis,
Do you have any idea why powerpc-apple-darwin9 would be
seeing the tmpdir-gcc.dg-struct-layout-1 execution failures
that I reported in PR's 39912, 39913, 39915, 39916, 39917,
39918, 39919, 39920 and 39921 but not on powerpc64-*-linux?
Could this be specific to -fPIC?
Jack
Does anyone understand why Apple's gcc-4.2 compiler in
Xcode 3.1.2 accepts the following code...
typedef const struct __CFString * CFStringRef;
typedef struct __CFBundle *CFBundleRef;
extern
CFStringRef CFBundleCopyLocalizedString(CFBundleRef bundle, CFStringRef key,
CFStringRef value, CFStri
On Tue, May 05, 2009 at 09:35:58PM -0700, Mark Mitchell wrote:
>
> Status
> ==
>
> GCC 4.4.0 was released into the wild approximately two weeks ago, and
> so far few serious defects have been reported. That's great! There
> are, however, a copule of open P1s and a bevy of P2s -- most of whi
On Mon, Jun 01, 2009 at 12:07:56PM +0200, Tobias Schlüter wrote:
>
> Hi,
>
> I'm seeing this error:
>
> /Users/tobi/src/hggcc/build/./prev-gcc/xgcc
> -B/Users/tobi/src/hggcc/build/./prev-gcc/
> -B/usr/local/i386-apple-darwin8.11.1/bin/
> -B/usr/local/i386-apple-darwin8.11.1/bin/
> -B/usr/lo
On Fri, Jun 26, 2009 at 01:33:06AM -0500, Gabriel Dos Reis wrote:
> On Thu, Jun 25, 2...@5:47 PM, Joe Buck wrote:
> > On Thu, Jun 25, 2...@03:19:19PM -0700, Joseph S. Myers wrote:
> >> On Thu, 25 Jun 2009, Ian Lance Taylor wrote:
> >>
> >> > * Test starting the bootstrap with earlier versions of th
I am seeing a new failure on x86_64-apple-darwin10 in current gcc 4.4 branch
that wasn't present in the gcc 4.4.0 release. At -m32, the testsuite failure...
FAIL: gcc.c-torture/compile/2804-1.c -O0 (test for excess errors)
appears with the error logged as...
Executing on host:
/sw/src/
On Sun, Jul 12, 2009 at 09:55:13PM +0200, Richard Guenther wrote:
> On Sun, Jul 12, 2009 at 9:41 PM, Jack Howarth wrote:
> > I am seeing a new failure on x86_64-apple-darwin10 in current gcc 4.4
> > branch
> > that wasn't present in the gcc 4.4.0 release. At -m32,
On Sun, Apr 25, 2010 at 08:12:03PM -0400, Mark Mielke wrote:
...
> In some ways, I wish a group did fork GCC under GPL and drop the
> copyright assignment requirement. In other ways, this entire issue is
> just so minor to me that it isn't worth going beyond this thread. GCC
> works, but so d
On Thu, Apr 29, 2010 at 12:25:15PM -0400, Vladimir Makarov wrote:
>
> Currently Graphite gives small improvements on x86 (one exception is
> 2% for peak x86 SPECFP2000) and mostly degradation on x86_64 (with
> maximum one more than 10% for SPECFP2000 because of big degradations
> on mgrid and
On x86_64-apple-darwin10, we fail the lto testcase...
/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/ -O0 -fwhopr -c
-o c_lto_20081222_1.o
/sw/src/fink.build/gcc46-4.5.999-20100508/gcc-4.6-20100508/gcc/testsuite/gc
On Mon, May 10, 2010 at 04:17:26PM +0100, Dave Korn wrote:
> On 10/05/2010 14:30, Jack Howarth wrote:
>
> > Are there any standards in effect which would dictate that
> > the alias of a hidden function is valid?
>
> Visiblity doesn't apply to functions, it app
On Mon, May 10, 2010 at 05:20:22PM +0100, Dave Korn wrote:
> On 10/05/2010 17:16, Dave Korn wrote:
> > On 10/05/2010 16:19, Jack Howarth wrote:
> >
> >> Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
> >> 20081222_1.c:16: error: 'EXT
What is the current LTO design with regards to the
retention of compiler flags during the actual link
time optimization compilation steps. For example, if
one is linking mixed fortran and c object files which
have distinct flags passed in FFLAGS and CFLAGS, are
these embedded with the LTO inform
On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote:
>
> For example the C++ frontend sets flag_exceptions to 1 but the
> command-line does not contain -fexceptions. Or the Fortran
> frontend might set flag_no_signed_zeros but the command-line
> does not contain -fno-signed-zero
On Mon, May 17, 2010 at 03:34:26PM +0200, Richard Guenther wrote:
> On Mon, May 17, 2010 at 3:21 PM, Jack Howarth
> wrote:
> > On Mon, May 17, 2010 at 02:50:27PM +0200, Richard Guenther wrote:
> >
> >>
> >> For example the C++ frontend sets flag_excep
On Mon, Jun 28, 2010 at 02:59:39PM +0200, Richard Guenther wrote:
>
> The trunk is frozen for all changes starting this Wednesday, 20:00 UTC
> in preparation for merging the mem-ref2 branch. The freeze is expected
> to last until early Friday morning. An explicit un-freeze mail will
> be sent as
201 - 300 of 589 matches
Mail list logo
