On Sun, Mar 13, 2011 at 11:59:33AM -0700, Chris Lattner wrote:
> On Mar 13, 2011, at 11:55 AM, Chris Lattner wrote:
> > On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
> >
> >>> Yes, I agree that this is a better solution. This error was put into the
> >
On Sun, Mar 13, 2011 at 12:47:22PM -0700, Chris Lattner wrote:
>
> On Mar 13, 2011, at 12:05 PM, Jack Howarth wrote:
>
> > On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote:
> >>
> >> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
> >>
On Sun, Mar 13, 2011 at 08:42:58PM +0100, Steven Bosscher wrote:
> (sorry Chris, I forgot the list)
>
> On Mar 13, 2011,@11:59 AM, Chris Lattner wrote:
>
> > Sorry, I actually mean 255 of course, because of the NO_SECT
> > sentinel. Here are the relevant bits from nlist.h. I'm not
> > sure how
On Sun, Mar 13, 2011 at 09:38:06PM +0100, Steven Bosscher wrote:
> On Sun, Mar 13, 2011 at 9:03 PM, Jack Howarth
> wrote:
> > On Sun, Mar 13, 2011 at 08:42:58PM +0100, Steven Bosscher wrote:
> >> (sorry Chris, I forgot the list)
> >>
> >> On Mar
Chris,
Could you clarify the following question from PR48086?
(In reply to comment #11)
> (In reply to comment #10)
> > The easiest way to fix this is maybe to just have more than one GNU_LTO
> > segment. AFAIU the limit of 255 sections is a limit per segment. It is not
> > difficult to have mu
On Sun, Mar 13, 2011 at 09:43:07PM +0100, Steven Bosscher wrote:
> On Sun, Mar 13, 2011 at 9:41 PM, Jack Howarth
> wrote:
> > On Sun, Mar 13, 2011 at 09:38:06PM +0100, Steven Bosscher wrote:
> >> I agree it is probably better to re-code things, but that will be
> >>
Heh, so I guess it's my fault...
> I dug through radar and found the bug that triggered the change to as(1):
>
> possible assembler bug exposed by LTO
>
> The bug was written (ironically) by Jack Howarth! At the time 4/28/10),
> gcc's LTO was putting some LTO s
For clarity, the radar that I filed over which Apple has inflicted this
pain on us was...
--
Problem ID: 7920267possible linker bug exposed by LTO
28-Apr-2010 07:18 PM Jack Howarth:
The FSF gcc developers
bject to an accidentally upgrade to 3.2.6 via Software
Update
if they are careless. It is probably better to disable the lto now rather than
suffer the complaints from end-users later. We can just revert...
2010-09-03 Jack Howarth
* configure.ac: Enable LTO by default on Darwin.
*
Would someone please correct http://gcc.gnu.org/gcc-4.6/changes.html by
deleting
the reference to darwin LTO support. Specifically we should just kill the
line...
LTO-support.
Darwin has benefited from ongoing work on LTO; support for this is now stable
and enabled by default.
It doesn't me
On Sun, Mar 13, 2011 at 11:53:59AM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> > So lto-object.c needs a rewrite to use only a single section for GNU_LTO
> > with subsections.
> > Unfortunately I can't find any documentation for using subsections in
On Mon, Mar 14, 2011 at 02:08:47PM -0700, Ian Lance Taylor wrote:
>
> I think you are overthinking this. What LTO needs to do is really
> simple: store byte sequences with names. Anything which lets you do
> that will work. You need to write it out in a way that the assembler
> will accept; sim
Is anyone else having problems getting the FSF copyright
clerk to complete the FSF paperwork? I am going on six months
now and the revised disclaimer that UC sent them still hasn't cleared
the FSF copyright office. Worse yet, the clerk hasn't responsed to
emails in the past few months. No one s
On Tue, Mar 15, 2011 at 05:03:44PM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> >Is anyone else having problems getting the FSF copyright
> > clerk to complete the FSF paperwork? I am going on six months
> > now and the revised disclaimer that UC sent t
On Tue, Mar 15, 2011 at 08:05:37PM -0400, Robert Dewar wrote:
> On 3/15/2011 8:03 PM, Ian Lance Taylor wrote:
>> Jack Howarth writes:
>>
>>> Is anyone else having problems getting the FSF copyright
>>> clerk to complete the FSF paperwork? I am going on s
On Tue, Mar 15, 2011 at 08:37:38PM -0400, Robert Dewar wrote:
> On 3/15/2011 8:11 PM, Jack Howarth wrote:
>
>> FSF legal could solve these problems in a minute. Don't shove a blanket
>> dislaimer for all employees at the employer. Give them two options to
>> sign..
On Wed, Mar 16, 2011 at 01:52:37AM +, Dave Korn wrote:
> On 16/03/2011 00:54, Jack Howarth wrote:
> > On Tue, Mar 15, 2011 at 08:37:38PM -0400, Robert Dewar wrote:
> >> On 3/15/2011 8:11 PM, Jack Howarth wrote:
> >>
> >>> FSF legal could solve th
There was some discussion earlier of defaulting FSF gcc to
--enable-build-with-cxx
for the stage2 compiler (with the stage 1 bootstrap retaining the use of the
system c compiler).
Is this change planned for gcc 4.7? On x86_64-apple-darwin10, I have had few
problems
routinely bootstrapping x86
Currently the bootstrap with --enable-build-with-cxx is failing because of
the following warnings treated as errors...
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/./prev-gcc/g++
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc4.7/x86_64-apple-darwin10.7.0/bi
On Fri, May 27, 2011 at 11:30:44AM +0200, Paolo Carlini wrote:
> Hi,
>
> > Should I open a PR for them?
>
> What do they mean? It means that a linker script pattern matches something
> which can't be actually exported?
This error message may be coming from the following code...
http://www.open
I am seeing some non-fatal warnings when doing a
profiledbootstrap/ltobootstap on
x86_64 darwin. These are of the form...
profiling:/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/graphite-poly.gcda:Invocation
mismatch - some data files may have been
removedprofiling:/sw/src/fink.build
What is the current state of supporting hardened operating systems
that default to -fpie/-fPIE/-pie in gcc trunk? Do those releases still use
their own patches for gcc or has all of those changes been committed to gcc
trunk?
If so, does anyone recall the specific commits? In particular, I am i
On Fri, Jun 17, 2011 at 07:30:43AM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> > What is the current state of supporting hardened operating systems
> > that default to -fpie/-fPIE/-pie in gcc trunk? Do those releases still use
> > their own patches for
Why aren't the BOOT_LDFLAGS settings honored outside of the gcc build
subdirectory?
On darwin, we are now setting...
BOOT_LDFLAGS += `case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
in config/mh-darwin, and while the generated toplevel Makefile shows...
LDFLAGS="$(POS
On Fri, Jun 17, 2011 at 07:30:43AM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> > What is the current state of supporting hardened operating systems
> > that default to -fpie/-fPIE/-pie in gcc trunk? Do those releases still use
> > their own patches for
I have had a report of i386 darwin10 failing to build gcc 4.4.6 in fink
which I've reproduced
myself. The failure looks quite odd...
/usr/bin/install -c -m 644 ./libiberty.a
/sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgc
On Sat, Jul 16, 2011 at 04:40:22PM -0400, Jack Howarth wrote:
>I have had a report of i386 darwin10 failing to build gcc 4.4.6 in fink
> which I've reproduced
> myself. The failure looks quite odd...
>
> /usr/bin/install -c -m 644 ./libiberty.a
> /sw/src/fink.build/r
I am trying to test the proposed merge of the transactional memory branch on
x86_64-apple-darwin11. Since the posted patches on gcc-patches seem to have
malformed sections, I used the merge patches from
http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/
instead (with the adjustm
Are there plans to expand the number of targets for go in gcc 4.7?
In particular, PR46986 has had a proposed set of changes...
http://gcc.gnu.org/bugzilla/attachment.cgi?id=25196&action=diff
which should provide a starting point to identify the changes required
for go support on darwin.
On Thu, Dec 15, 2011 at 10:51:39AM -0500, Patrick Marlier wrote:
> Hi Guys!
>
> Transactional Memory will be released in 4.7 so even if it is
> experimental, I hope it will come with only few bugs in it. Users could
> be enthusiastic to test it so it could be great to offer them a great
> exp
On Mon, Jul 13, 2009 at 01:52:51AM +0100, Dave Korn wrote:
> 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&#
Is it known yet whether the changes in cloog/ppl will require
new soversions of those libraries or might the new cloog/ppl
libraries be backward compatible with current gcc 4.4.x (ie have
the same soversion number but a higher compatibility version)?
Jack
On Sun, Jul 05, 2009 at 02
12 Aug 2008 14:48:07 +0300
>X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February
>07, 2008) at
> 12/08/2008 14:43:23
>MIME-Version: 1.0
>Content-type: text/plain; charset=US-ASCII
>Status: RO
>X-Status: A
>Content-Length: 11751
>Lines: 335
>
&g
On Tue, Aug 04, 2009 at 12:35:15PM +0300, Dorit Nuzman wrote:
>
> Hi Jack,
> AFAIK this topic has not been addressed (closest thing is Richard
> Guenther's work on versioning unknown strides
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html) and I don't know
> about the prospects of this b
On Tue, Aug 04, 2009 at 12:35:15PM +0300, Dorit Nuzman wrote:
>
> Hi Jack,
> AFAIK this topic has not been addressed (closest thing is Richard
> Guenther's work on versioning unknown strides
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html) and I don't know
> about the prospects of this b
Sebastian,
With the current r150790 gcc trunk, I am not seeing any
particular improvements in the polyhedron benchmarks with the
available graphite loop optimizations...
Date & Time : 15 Aug 2009 13:41:47
Test
On Mon, Aug 24, 2009 at 03:40:54PM +0200, Tobias Grosser wrote:
> Hi Toon,
>
> did you build with the latest cloog-ppl package. It is 0.15.7 and
> availa...@ftp://gcc.gnu.org/pub/gcc/infrastructure/.
>
> Gcc should build without any problems using this package. Can you verify
> this?
>
> The pro
The mpfr 2.4.2-rc1 release builds fine on x86_64-apple-darwin10
and passes all of its testsuite. I do see a few warnings though...
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1
-DHAVE_STDARG=1 -DHAV
On Fri, Aug 28, 2009 at 03:45:38PM -0500, Sebastian Pop wrote:
> On Fri, Aug 28, 2009 at 13:25, Sebastian Pop wrote:
> > I am doing this right now. I will first merge trunk into graphite
> > branch and then commit all the changes from graphite to trunk (modulo
> > some changes that should remain i
Richard,
We have an analysis on the cause of the breakage of
exception handling at r147995 on x86_64-apple-darwin10 (PR41260)...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html
The additional epilog unw
FYI, to clarify for others who haven't been following
PR41260, the messages...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
explain the changes in libgcc handling as of darwin10. If I
understand thos
I can confirm that the second proposed solution of passing
-Wl,-no_compact_unwind
to the linkage of the g++.dg/torture/stackalign/eh-vararg-2.C test cases
eliminates
the execution error on x86_64-apple-darwin10 so that option works. This leads
to a
dejagnu question. I want to do a quick and d
On Sat, Sep 19, 2009 at 10:57:38PM +0200, Richard Guenther wrote:
>
> We've been accumulating quite a number of P1 bugs. Entering Stage 3
> should allow to improve considerably here in a short time.
>
Richard,
Will the graphite code be under strict stage 3 rules or will it
have more leeway u
On Mon, Sep 21, 2009 at 05:04:27PM +0100, Hariharan wrote:
> Hi Alexandre,
> I was having some trouble with dwarf sections in picochip port. I am not
> a dwarf expert, but when i loo...@the changes in r151312, file
> dwarf2out.c, function dwarf2out_var_location on line 17965, we have
>
>
On Mon, Sep 21, 2009 at 11:23:11AM -0700, Cary Coutant wrote:
> >> So aren't we now likely to lose the first few days of what little
> >> remains of
> >> stage 1 waiting for trunk to start working again, then have a mad rush of
> >> people falling all over each other to get their new features in
On Thu, Sep 24, 2009 at 03:01:12PM +0100, IainS wrote:
>
> So, this particular bug appears to be cleared at
>
> dwarfutils-66 or greater. (confir...@dwarfutils-70 as well)
>
> (It does not seem to affect powerpc-apple-darwin8 which only has
> dwarfutils-42,
> but I can't speak for i686-apple-d
On Thu, Sep 24, 2009 at 04:03:28PM +0100, IainS wrote:
>
> this bug - "fail in dwarfdump --debug-frame" for i686 target
>
> Is present in:
> XCode 3.1.2 dwarfutils-49 (IIRC)
>
> In not present in:
> XCode 3.1.3 dwarfutils-66 and XCode 3.1.4 dwarfutils-70
>
> --
> N.B. this is NOT the "orig_str" Ab
On Mon, Sep 28, 2009 at 11:58:30AM -0400, Diego Novillo wrote:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
>
> If anyone has free cycles I would appreciate results from
On Wed, Sep 30, 2009 at 10:49:40AM +0200, Richard Guenther wrote:
> >
> > Now, submitting a one liner as your first atte...@a new pass today
> > and then claiming the rest are just fixes, would be a stretch :-), but
> > for a patch like yours it does not seem unreasonable.
>
> Just to followup on
Silvius,
The ext/profile/mh.cc test case is failing to compile on *-*-darwin* due to
the error...
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:24:20:
fatal error: malloc.h: No such file or directory
This test case should be including std
On Sat, Oct 03, 2009 at 10:40:06PM -0400, Jack Howarth wrote:
> Silvius,
>The ext/profile/mh.cc test case is failing to compile on *-*-darwin* due
> to the error...
>
> /sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:24:20:
Janis,
We are seeing failures of the new decimal testcases on x86_64-apple-darwin10
which you committed into the libstdc++-v3 testsuite...
FAIL: decimal/binary-arith.cc (test for excess errors)
WARNING: decimal/binary-arith.cc compilation failed to produce executable
FAIL: decimal/cast_neg.cc (
On Tue, Oct 06, 2009 at 09:44:42AM -0700, Janis Johnson wrote:
> On Tue, 2009-10-06 at 09:10 -0700, Janis Johnson wrote:
> > On Tue, 2009-10-06 at 09:04 -0400, Jack Howarth wrote:
> > > Janis,
> > >We are seeing failures of the new decimal testcases on
> > &g
On Tue, Oct 06, 2009 at 03:30:34PM -0700, Janis Johnson wrote:
>
> Oh, maybe the libstdc++ tests don't support dg-require-effective-target.
>
> Janis
Janis,
Yes, doesn't it need something like...
# Skip these tests for targets that don't support this extension.
if { ![check_effective_target_
On Tue, Oct 06, 2009 at 03:40:29PM -0700, Janis Johnson wrote:
>
> I spoke too soon. I'm now building a compiler with decimal float
> disabled and will dig into this.
>
> Janis
Janis,
Don't you have to include something like
gcc/testsuite/lib/target-supports.exp
to be able to use check_effe
On Tue, Oct 06, 2009 at 03:34:30PM -0700, Benjamin Kosnik wrote:
>
> Why do we have a libstdc++ list? For questions like this...
>
Because this is a flaw in the libstdc++-v3 testsuite harness
which obviously the core gcc testsuite handles properly. The
other gcc developers might have an insight
While constructing a patch to resolve PR41313 on darwin, I noticed an oddity.
The problem in PR41313 is due to hot/cold partitioning not being understood by
darwin_emit_unwind_label() such that duplicate .eh symbols can be created. This
can be fixed by restoring the previous behavior for disabl
Interestingly, on darwin, it appears that the trigger for the generation
of the duplicate .eh symbols is not -freorder-blocks-and-partition but the
additional use of -fprofile-use -D_PROFILE_USE. When I drop the profiling
from gcc.dg/tree-prof/bb-reorg.c and gcc.dg/tree-prof/pr34999.c, they comp
On Thu, Oct 08, 2009 at 08:52:03PM +0200, Jakub Jelinek wrote:
> The first release candidate for GCC 4.4.2 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.2-RC-20091008
>
> and shortly its mirrors. It has been generated from SVN revision 152546.
>
> I have so far bootstrapped an
I am a tad confused by this thread. Is MPC going to be mandatory
along side of gmp/mpfr for the gcc 4.5 release or is this further
out into the future than that? Thanks in advance for any clarifications.
Jack
Are there any plans for further merges out of the
graphite branch before gcc 4.5 is branched? I was
under the impression that the graphite developers
originally intended to keep trunk more closely
synchronized with the graphite branch during the
gcc 4.5 release cycle and this doesn't seem to ha
On Thu, Nov 12, 2009 at 01:23:30PM -0500, David Edelsohn wrote:
>
> Yes, more Graphite merges are planned. The VTA merge broke Graphite
> and we are waiting for Alexandre's recent VTA fixes for Graphite to be
> updated based on the initial feedback from Sebastian and merged into
> the trunk. The
We have a clarification from Apple on the problem of
dsymutils asserting since the VTA merge changes...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c29
Does the code in gcc/dwarfout.c currently check if
any block form with zero length
On Wed, Dec 02, 2009 at 11:08:49PM +0100, Richard Guenther wrote:
> On Wed, 2 Dec 2009, Ralf Wildenhues wrote:
>
> > Hello Richard,
> >
> > * Richard Guenther wrote on Wed, Dec 02, 2...@01:32:24PM CET:
> > > The trunk is in regression and documentation fixes only mode,
> > > Stage 3 has ended yes
On Thu, Dec 03, 2009 at 09:32:38PM +0100, Ralf Wildenhues wrote:
>
> Do you need anything to test the patch before it is applied, or did you
> mean to test it when it has been applied? (To test this patch that does
> not include regenerated files, apply it, then
> find $srcdir -name configure |
On Thu, Dec 03, 2009 at 09:32:38PM +0100, Ralf Wildenhues wrote:
> * Jack Howarth wrote on Thu, Dec 03, 2009 at 03:22:56AM CET:
> > On Wed, Dec 02, 2009 at 11:08:49PM +0100, Richard Guenther wrote:
> > > On Wed, 2 Dec 2009, Ralf Wildenhues wrote:
> > > >
> >
Do we have any maintainers outside of the global reviewers and
the dwarf debugging code reviewer who can review changes to dwarf2out.c?
We have two outstanding patches that eliminate crashes in dsymutil on
darwin so that gcc trunk can generate complete debug code again on
that target. This does r
On Sun, Jan 24, 2010 at 08:26:04PM -0500, Olexa Bilaniuk wrote:
>
> I am on Mac OS X Snow Leopard. There has been some noise around the
> forums that GCC fails for various reasons. It turns out that despite
> having all the requirements to run 64-bit systems, including a 64-bit
> processor (an Int
On Thu, Feb 04, 2010 at 08:12:10PM +0100, jacob navia wrote:
> Hi
>
> I have developed a JIT for linux 64 bits. It generates exception
> handling information
> according to DWARF under linux and it works with gcc 4.2.1.
>
> I have recompiled the same code under the Macintosh and something has
>
On Fri, Feb 05, 2010 at 09:06:56PM +, Dave Korn wrote:
> On 05/02/2010 18:46, jacob navia wrote:
>
> > The build crashed in the java section by the way, there was a script that
> > supposed the object files in a .libs directory but the objects were in the
> > same directory as the source code
While looking at PR42308 and trying to understand why the make check
is leaky and starts to call the system compiler instead of the xgcc during
a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed
that we seem to build libiberty both at the toplevel and within the multil
On Mon, Mar 01, 2010 at 02:31:52AM +0100, Andreas Schwab wrote:
> Jack Howarth writes:
>
> >While looking at PR42308 and trying to understand why the make check
> > is leaky and starts to call the system compiler instead of the xgcc during
> > a make check on either
Toon,
I would suspect this boost is from the series of changes
to "Update default arch for x86" from HJ Lu. This should now
have -msse2 in use as the default (except on darwin where
we went to -msse3 since all of our processors support that).
Jack
On Sun, Mar 07, 2010 at 07:34:22P
On Sun, Mar 07, 2010 at 08:17:54PM +0100, Toon Moene wrote:
> Jack Howarth wrote:
>
>> Toon,
>>I would suspect this boost is from the series of changes
>> to "Update default arch for x86" from HJ Lu. This should now
>> have -msse2 in use as the defau
While testing a patch to update the minimum version
of cloog-ppl in gcc trunk...
Index: configure.ac
===
--- configure.ac(revision 157732)
+++ configure.ac(working copy)
@@ -1612,9 +1612,9 @@
if test "x$with_cloog"
This issue of reapplying the patch...
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html
to eliminate a race condition in indirect call value profiling
came up earlier this year after darwin was depreciated as a
primary target...
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01545.html
N
On Sat, Mar 27, 2010 at 07:56:14AM +0100, Ralf Wildenhues wrote:
> Hello Jack,
>
> * Jack Howarth wrote on Fri, Mar 26, 2010 at 01:13:16AM CET:
> >While testing a patch to update the minimum version
> > of cloog-ppl in gcc trunk...
>
> > --- config
ch, I'll apply it once we re-enter Stage 1.
>
> Cheers,
> Neil
>
> On Fri, Mar 26, 2...@10:57 AM, Jack Howarth wrote:
> >
> > This issue of reapplying the patch...
> >
> > http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html
> >
> > t
I've not seen any discussion of testing gcc trunk
against the newer gmp 5.0 or 5.0.1 releases. Has anyone
done significant testing with the newer gmp releases
and are there any long term plans for bumping the
required gmp (assuming that any of the new features
or fixes are useful for gcc)? Thank
What exactly is the expected behavior from invoking
-enable-tls in configure on a target that only has
emulated tls? In libgcc, we end up building tls support
in the compiler via emulated tls and I am wondering if
using -enable-tls would do the same across the whole
compiler.
Richard,
I apologize for the mix up in testing the race
condition patch for value profiling of the indirect
calls on darwin. We may need to regress that out for
gcc 4.5, but first I would like to try to get a PR
opened to define the scope of the problem that it causes.
In particular, it is very
On Wed, Mar 31, 2010 at 02:14:41PM +0200, Richard Guenther wrote:
> On Wed, 31 Mar 2010, Jack Howarth wrote:
>
> > Richard,
> >I apologize for the mix up in testing the race
> > condition patch for value profiling of the indirect
> > calls on darwin. We ma
On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
>
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
>>>
>>> I suppose they are not exported.
On Wed, Mar 31, 2010 at 05:54:52PM +0200, Richard Guenther wrote:
>
> Status
> ==
>
> We have reached the zero P1 GCC 4.5 regressions required for a
> release candidate build of GCC 4.5.0. To allow this state to
> prevail the trunk is frozen for non-documentation changes
> starting April 2nd
On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
>
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
>>>
>>> I suppose they are not exported.
I have noticed a tendency for timeouts to occur
in the 20_util/shared_ptr/thread/default_weaktoshared.cc...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/./gcc/g++
-shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/./gcc
-nostdinc++
-L/sw/s
On Fri, Apr 02, 2010 at 02:15:05PM +0200, Paolo Carlini wrote:
> On 04/02/2010 02:09 PM, Jack Howarth wrote:
> > Is there a PR related to this and if not shouldn't one be opened?
> >
> I never times out for me on x86 and x86_64-linux. Thus, if you want to
> open one, I
On Fri, Apr 02, 2010 at 06:10:29PM +0100, Jonathan Wakely wrote:
> On 2 April 2010 14:12, Jack Howarth wrote:
> >
> > Paolo,
> > I don't believe this occurs with the x86_64-apple-darwin10
> > target but only with i686-apple-darwin10 so it may well be
> >
On Tue, Apr 06, 2010 at 03:45:27PM +0200, Richard Guenther wrote:
>
> A GCC 4.5.0 release candidate is available at:
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.0-RC-20100406/
>
> Please test the tarballs and report any problems to Bugzilla.
> CC me on the bugs if you believe they are regression
What are the opinions here about merging
dragonegg into FSF gcc? It is in the odd position
of straddling two projects so perhaps it could
reside in both the LLVM and FSF gcc projects
with regularly remerging. Certainly it would be
an interesting addition to FSF gcc. For instance,
without even at
On Sun, Apr 11, 2010 at 01:19:06PM +0200, Steven Bosscher wrote:
> On Sat, Apr 10, 2...@3:03 PM, Duncan Sands wrote:
> > Hi Basile,
> >
> >> I tend to be quite happy with the idea of dragonegg being a good GCC
> >> plugin, since it is a good illustration of the plugin feature.
> >
> > I think Jack
Steven,
One other comment. I've felt for awhile that a major
strength of FSF gcc was the fact that its support for
so many targets insured that latent bugs tended to be
found in the compiler. Likewise graphite has recently
exposed certain latent bugs as well. Why should we not
expect the same t
On Sun, Apr 11, 2010 at 10:56:55AM -0400, David Edelsohn wrote:
> On Sun, Apr 11, 2010 at 10:30 AM, Jack Howarth
> wrote:
> > Steven,
> > One other comment. I've felt for awhile that a major
> > strength of FSF gcc was the fact that its support for
> > so ma
On Sun, Apr 11, 2010 at 06:02:38PM +0200, Duncan Sands wrote:
>> useful and effective, then work on it as well and give it credit; if
>> GCC is so bad, then why rely on it? The rhetoric is disconnected from
>> the actions.
>
> I'm not sure what you mean. Working on an LLVM middle-end/back-end for
On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
> On 12 April 2010 00:38, Dave Korn wrote:
> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
> >
> >> [ ... ] lack of test results in some platforms does not mean
> >> that GCC developers are uninterested on supporting those pl
On Mon, Apr 12, 2010 at 03:42:39PM +0200, Richard Guenther wrote:
> On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth
> wrote:
> > On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
> >> On 12 April 2010 00:38, Dave Korn wrote:
> >> > On 11/04/2010
On Mon, Apr 12, 2010 at 11:00:13AM -0400, Alfred M. Szmidt wrote:
> If the dragonegg and/or LLVM copyright was assigned to the FSF, which
> is a prerequisit for anything included in GCC and not what license the
> program is under currently, then I'm quite sure that the GCC
> maintainers would be mo
On Mon, Apr 12, 2010 at 05:45:52PM +0200, Steven Bosscher wrote:
> On Mon, Apr 12, 2010 at 3:52 PM, Jack Howarth
> wrote:
> >> Err, well. I do not see how most of the code is OS specific
> >> anyway - there is _very_ little code in GCC that is OS specific.
> >&
On darwin, we are missing a required header file
in the
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/plugin/include/config
installation directory. The file gcc/config/darwin-sections.def needs
to be installed in plugin/include/config. What is the 'correct' way
to achieve this (short of
On Tue, Apr 13, 2010 at 07:05:17PM +0200, Paolo Bonzini wrote:
> On 04/12/2010 04:18 PM, Dave Korn wrote:
>> Could anyone really believe that without being a grade A tinfoil-hat
>> wearing crazy? More precisely, could anyone capable of the kind of
>> rational thought processes that they'd need to
101 - 200 of 589 matches
Mail list logo
