Joseph S. Myers jos...@codesourcery.com writes:
2. If you put directories from the GCC repository into your build, you
should expect GCC and its libraries to be built; toplevel should not
disable GCC on the grounds that GCC does not support a given target.
I'd appreciate it if creating a
Jack Howarth [EMAIL PROTECTED] writes:
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.dylib
[EMAIL PROTECTED] (Ross Ridge) writes:
Ross Ridge writes:
The compiler can't in general know what encoding that printf, fprintf,
and sprintf will use to parse the string. It's locale dependent.
Paolo Bonzini writes:
It is undefined what happens if you run a program in a different charset
Daniel Jacobowitz [EMAIL PROTECTED] writes:
I'm sure this has come up before, but I don't understand how the
-maltivec definition of STACK_BOUNDARY can be right. We tell the
compiler that STACK_BOUNDARY == 128 if -maltivec, without telling it
that other people may ignore that, because
Dave Korn [EMAIL PROTECTED] writes:
On 23 August 2007 22:34, Mark Mitchell wrote:
I do think that generating the same code, independent of host system, is
a very important property of GCC's design, just like generating the same
code independent of whether or not we're compiling with -g.
Richard Sandiford [EMAIL PROTECTED] writes:
Sorry if this has been discussed before, but the c99-tgmath-* tests
are failing on most newlib targets. The problem is that tgmath.h
unconditionally includes complex.h, which non-linux newlibs don't
provide. What's the best fix? Including
[EMAIL PROTECTED] (Richard Kenner) writes:
Despite the lack of a relationship with anyone at FSF, many people do
download GPL software an use it, in accord with the license. They have
a legal right to use the software.
A license is not between the user of the software and the FSF, but
On 12/07/2007, at 8:30 AM, Steve Ellcey wrote:
Feel free to either (a) #ifdef out the first part of the test on
IA64,
or (b) delete the first part of the test altogether.
Since it fails on other platforms (b) seems like the better
alternative.
OK to checkin this patch?
OK.
On 03/07/2007, at 5:13 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
GCC's concept of visibility is very different to that of some other
compilers.
Yes, and that may be a problem. For some features, we want to have
GNU
semantics that are consistent that across platforms; for others
On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
Yes. __attribute__((visibility)) has consistent GNU semantics, and
other features (eg. -fvisibility-ms-compat, __dllspec) match other
compilers.
The only semantics that make sense on SymbianOS are the ones that
allow
Mark Mitchell [EMAIL PROTECTED] writes:
But, the visibility attribute is only specified in terms of its effects
on ELF symbols, not as having C++ semantics per se.
[Sorry I'm so late with this reply; I've been busy and am behind on reading
mailing lists.]
The documentation for the visibility
On 27/04/2007, at 2:50 AM, Joseph S. Myers wrote:
On Fri, 26 Apr 2007, Geoffrey Keating wrote:
This seems reasonable to me, but maybe it would be simpler to write
If there are one or more incomplete structure or union types which
cannot all be completed without producing undefined behaviour
Joseph S. Myers [EMAIL PROTECTED] writes:
Proposed amendment for C1x:
6.2.7 after paragraph 2 insert: There shall exist a partition of
all the structure and union types in the program into disjoint
classes such that (a) if two types are in the same class, then
they are
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++. The FSF libstdc++ is, I believe,
binary incompatible with the system one, and since system libraries
use the system one there is no
On 26/03/2007, at 3:12 PM, Zack Weinberg wrote:
Most of gengtype's hardwired kludges exist because it does not do
preprocessing, and therefore my recommendation is that we work toward
a state where gengtype can use libcpp to do that (we already have a
preprocessor library, let's use it :) If
On 04/03/2007, at 12:25 AM, FX Coudert wrote:
I'd like to ping these two problems :)
i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-
pc-mingw32 (latest released version) are still completely broken on
mainline, as they have been for more that three months.
I spent
were introduced by Geoffrey Keating
(http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a C99
extern inline patch. Fixincludes were then created for glibc
systems.
In both cases, I'm ready to debug (I attached the full preprocessed
source of minimal examples to both PR) and test patches
On 14/11/2006, at 3:13 AM, Dominique Dhumieres wrote:
In http://gcc.gnu.org/ml/gcc-help/2006-11/msg00058.html I reported the
following:
Building snapshot gcc4-4.3.0-20061104 on OSX 10.3.9 with
odcctools 590-20060413 using a modified Fink script (working
with the previous snapshot) failed
On 31/10/2006, at 12:28 AM, Mark Mitchell wrote:
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
I would strongly oppose downloading stuff during the build
process. We're not in the apt-get business; we can leave that to the
GNU/Linux distributions, the Cygwin distributors,
Greg Schafer [EMAIL PROTECTED] writes:
Mark Mitchell wrote:
I don't believe there's a serious problem with the concept, as long as
./configure; make; make install for GMP DTRT. If you can do it for
GCC, you can do it for a library it uses too.
Just another data point.
I tried
Hi Kaveh,
Since your patch
r117933 | ghazi | 2006-10-21 06:58:13 -0700 (Sat, 21 Oct 2006) | 16
lines
* configure.in: Require GMP-4.1+ and MPFR-2.2+. Don't check
need_gmp anymore.
I'm getting
On 30/10/2006, at 10:34 AM, Daniel Berlin wrote:
4. Are you aware that the GMP home page says
[2006-05-04] GMP does not build on MacInteltosh machines. No fix
planned for GMP 4.x.
and indeed it does not appear to build correctly when configured on
my MacBook Pro?
Errr, well,
I have
On 30/10/2006, at 1:24 PM, Kaveh R. GHAZI wrote:
On Mon, 30 Oct 2006, Geoffrey Keating wrote:
Also, although I experience no regressions, i'll point out that
there
is no automated tested for macintel darwin that posts to
gcc-testresults, which does not bode well for something you would
One more thing, I initially went down the road of including the GMP/
MPFR
sources in the gcc tree and building them as part of the bootstrap
process. But the consensus was not to do that:
http://gcc.gnu.org/ml/gcc/2006-10/msg00167.html
I think the problem is that Mark also said
I do think
On 30/10/2006, at 5:31 PM, Shantonu Sen wrote:
For what it's worth, I did a build on Mac OS X for Intel 10.4.8 last
week, and had no problems building GMP 4.2.1 and mprf-2.2.0, with no
special --target options. Maybe you have an old version of gmp in
your default linker search path
On 19/10/2006, at 9:17 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
For GCC, I've found it necessary to have a way to name local (that
is,
namespace-scope 'static') variables and functions which allows more
than one such symbol to be present and have distinct mangled names.
With my
that 'L' is reserved? Is there
some other character or syntax that I should use? I do see that 'v'
is available for 'vendor extended operator', but unfortunately it's
set up to be used only for an operator, not an arbitrary symbol.
--
- Geoffrey Keating [EMAIL PROTECTED]
On 19/10/2006, at 3:04 PM, Ian Lance Taylor wrote:
[EMAIL PROTECTED] (Geoffrey Keating) writes:
For GCC, I've found it necessary to have a way to name local (that
is,
namespace-scope 'static') variables and functions which allows more
than one such symbol to be present and have distinct
Mark Mitchell [EMAIL PROTECTED] writes:
IMA for C++ is another difficult case. This is unambiguously useful,
though duplicative of what we're trying to build with LTO.
Although there are some things you can do with LTO that you can also
do with IMA, there are many things that you can do with
On 17/10/2006, at 11:45 AM, Jack Howarth wrote:
Geoff,
I noticed that the automake maintainers
accepted your patch for fixing the multilib
issues in automake. However they also seemed
to indicate that there would be no more 1.9.x
automake releases.
Is the r117741 svn checkin related to
On 17/10/2006, at 1:39 PM, Andrew Pinski wrote:
On 17/10/2006, at 11:45 AM, Jack Howarth wrote:
Geoff,
I noticed that the automake maintainers
accepted your patch for fixing the multilib
issues in automake. However they also seemed
to indicate that there would be no more 1.9.x
automake
On 17/10/2006, at 3:27 PM, Jack Howarth wrote:
Geoff,
Should gcc/doc/install.texi be changed now to require
automake version 1.10 or later rather than the current
1.9.3?
No.
Jack
On Tue, Oct 17, 2006 at 12:36:21PM -0700, Geoffrey Keating wrote:
Hi Jack,
I believe
FX Coudert [EMAIL PROTECTED] writes:
Hi all,
For Fortran 2003 standard conformance, the Fortran front-end has to
know at compile-time what integer mode corresponds to some C99 types,
like intmax_t, intN_t, int_leastN_t, int_fastN_t.
For intN_t and int_leastN_t, I can see how to get them
Mark Mitchell [EMAIL PROTECTED] writes:
We have a number of C++ PRs open around problems with code like this:
struct S {
void f();
virtual void g();
};
typedef __attribute__((...)) struct S T;
If the attribute makes any substantive change to S (e.g., changes its
Jack Howarth [EMAIL PROTECTED] writes:
Shouldn't configure in gcc be made to
automatically test if -m64 is working on
the build machine in question and automatically
invoke --disable-multilib if not? Currently
on Darwin for example we have to explicitly
invoke --disable-multilib when
David Edelsohn [EMAIL PROTECTED] writes:
Bugzilla currently shows 64 open bugs with a darwin listed as the
target; another 5 Altivec bugs. I am concerned about the effect on
releases from increasing the priority of many of those bugs to P1 if
Darwin is a primary platform.
Which of
[EMAIL PROTECTED] (Jack Howarth) writes:
Geoff,
Can you explain why we don't have...
Index: unwind-dw2-fde-darwin.c
===
--- unwind-dw2-fde-darwin.c (revision 117350)
+++ unwind-dw2-fde-darwin.c (working copy)
@@
On 02/10/2006, at 3:37 PM, Jack Howarth wrote:
Geoff,
I made one typo in my original proposed patch for
unwind-dw2-fde-darwin.c. It should be...
Index: unwind-dw2-fde-darwin.c
===
--- unwind-dw2-fde-darwin.c (revision
On 02/10/2006, at 4:17 PM, Jack Howarth wrote:
Geoff,
So should we have...
#ifdef __ppc__
fde = getsectdatafromheader (image-mh, __DATA, __eh_frame,
sz);
#endif
#ifdef __ppc64__
fde = getsectdatafromheader_64 ((struct mach_header_64 *)image-
mh, __DATA, __eh_frame, sz);
#endif
On 02/10/2006, at 4:33 PM, Jack Howarth wrote:
Geoff,
Well removing the portions of my previous patch which weren't
being used, the effective change that I had (which eliminated the
failures under MacOS X 10.4.8 with the -m64 objc testsuite) was...
diff -uNr
Daniel Berlin [EMAIL PROTECTED] writes:
I really object to darwin being a primary platform until it is
actually possible to build it on a released darwin system without
passing extra configure flags, etc.
The regression tester routinely builds Darwin and uses no special
configure flags. What
The intermittent failures on Darwin are due to a kernel bug tripped by
java.lang.Process.waitFor().
The bug appears to be that if:
- the program is multithreaded
- it is blocking SIGCHLD
- it receives a SIGCHLD due to a process terminating
- later it calls sigsuspend (but not sigwait)
then
Hi Mark,
http://gcc.gnu.org/ml/gcc/2006-09/msg00368.html
On Darwin, the most common form of development is to compile the same
sources to target both powerpc-darwin and i386-darwin
simultaneously. It therefore seems unnatural to make a distinction
between the two. This also makes the
On 22/09/2006, at 1:54 PM, Jack Howarth wrote:
Geoff,
How would the powerpc-darwin -m64 support and x86_64 fit into this
scheme? Would they be considered variants of the powerpc-darwin and
i386-darwin architectures and thus primary platforms as well? Or
would they be secondary platforms?
I analysed this problem.
It appears that the pthread_cond_timedwait on at least darwin8
sometimes returns a few microseconds early; this may be related to
having ntpd running.
On darwin9 (and/or darwin8 with -D_APPLE_C_SOURCE defined), sometimes
this test hangs, due to a different,
On 11/09/2006, at 3:51 PM, Jack Howarth wrote:
Geoff,
Did you notice that a new libjava regression occured today on
Darwin
apparently after revision 116838 but by revision 116843? The
testcase...
FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode-
native test
now fails.
On 11/09/2006, at 3:59 PM, Andrew Pinski wrote:
Geoff,
Did you notice that a new libjava regression occured today on
Darwin
apparently after revision 116838 but by revision 116843? The
testcase...
FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode-
native test
now fails.
On 10/09/2006, at 6:48 AM, Jack Howarth wrote:
Eric,
You definitely want the autoconf patch added
in otherwise builds of libgfortran will crash
when older cctools are used (like Xcode 2.3).
Typically what we do is just say that GCC requires a later version of
cctools.
smime.p7s
On 02/09/2006, at 1:10 PM, Jack Howarth wrote:
Geoff,
Does the patch you propose in...
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00057.html
eliminate the can't find atom for N_GSYM stabs warnings
in ld64?
No. It does nothing at all with ld64, or linking in general, and it
has no
On 29/08/2006, at 5:27 PM, Jack Howarth wrote:
Geoff,
Isn't the gcc.misc-tests/linkage.c failing just because we don't
have
an entry in linkage.exp that defines the native flags for Darwin?
Yes.
Also,
this test look pretty dicey in that it uses...
catch { exec cc -c
Paul Brook [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 20:14, Mike Stump wrote:
I hate to even bring this up, but... should things like:
int m[1 27] = {0};
be put in .bss? I'm tempted to say no, if you want that, you have to
remove {0}.
What makes you say this?
[EMAIL PROTECTED] (Jack Howarth) writes:
Is it the expected behavior for dejagnu to always report warnings
as errors in the test for excess errors check? Is this a design
decision or just how dejagnu currently works? I ask because the
current output of test for excess errors when a FAIL
On 18/08/2006, at 6:39 PM, Ian Lance Taylor wrote:
Geoffrey Keating [EMAIL PROTECTED] writes:
On 18/08/2006, at 5:42 PM, Ian Lance Taylor wrote:
...
We could change CSA so that when it combines a prologue instruction
with a non-prologue instruction it sets a new flag on the
instruction
Hi Alexandre,
your patch,
r112170 | aoliva | 2006-03-16 22:08:49 -0800 (Thu, 16 Mar 2006) | 4
lines
* dwarf2out.c (dwarf2out_stack_adjust): Always track the stack
pointer, instead of assuming it is possible to derive
On 18/08/2006, at 5:42 PM, Ian Lance Taylor wrote:
...
We could change CSA so that when it combines a prologue instruction
with a non-prologue instruction it sets a new flag on the instruction,
and uses a table on the side to record the original values in the
instruction.
I guess that would
Laurynas Biveinis [EMAIL PROTECTED] writes:
../../gcc-boehm-custom-marking/gcc/value-prof.h:48: syntax error,
unexpected '*', expecting ')'
What should I do about it?
Have to typedef the pointer due to gengtype silliness, IIRC.
IE typedef struct histogram_value_t
On 07/08/2006, at 6:11 PM, Jack Howarth wrote:
Geoff,
I am still puzzled by your statement that .1.dylib files
should never be used
directly in a link. With both gcc trunk and Xcode 2.3, the
following...
[Jack-Howarths-Computer:~] howarth% gcc -O3 -m64 modulo.c -shared-
libgcc
On 06/08/2006, at 9:10 PM, Jack Howarth wrote:
David,
My understanding was that only libgcc_s.10.4.dylib and libgcc_s.
10.5.dylib
required the entries in their .ver files for exporting symbols. The
-m64
flag on Darwin causes libgcc_s_ppc64.1.dylib to be used for the linked
libgcc.
On 06/08/2006, at 8:11 PM, David Edelsohn wrote:
I believe that Andrew Pinski diagnosed the problem as divti3 and
modti3 not being listed in the symbol export file for Darwin when
64-bit
support was added.
It is unfortunate that these files cannot have comments, because it
seems
Michael Eager [EMAIL PROTECTED] writes:
I'm running into problems building libstdc++
for powerpc-eabi. It eventually fails with an
error message saying Link tests are not allowed
after GCC_NO_EXECUTABLES while it is checking
to see if libgcc_s exists.
Meanwhile, config.log for libstdc++
Mark Mitchell [EMAIL PROTECTED] writes:
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
I've gotten a little lost in this thread. Is there a clear proposal for
the semantics that we're leaning towards at this point?
One meta-note is that
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Jason Merrill [EMAIL PROTECTED] writes:
[...]
| | - I don't recall suggesting that
| | multiple types with the same name should be able to exist.
| then you have to consider that suggestion and come with an answer.
|
| I don't see why.
Tristan Wibberley [EMAIL PROTECTED] writes:
The types are defined in headers and are thus known
to exist - no visibility attributes will or should change that.
The question here is not whether the types exist, but which types are
the same as which other types.
I think that what you want is a
Jason Merrill [EMAIL PROTECTED] writes:
Benjamin Smedberg wrote:
Jason Merrill wrote:
Do you agree with implicitly giving template instantiations the
minimum visibility of the template and arguments unless explicitly
overridden?
This is not what I would naturally expect, coming from
Joe Buck [EMAIL PROTECTED] writes:
I wrote [for two classes S with visibility == hidden ]
| | We can have two distinct
| | classes named S, and no one can tell. Each bit of code will see one
| | definition of S.
Jason Merrill [EMAIL PROTECTED] writes:
| I think that Joe's point is
Jason Merrill [EMAIL PROTECTED] writes:
Gabriel Dos Reis wrote:
Jason Merrill [EMAIL PROTECTED] writes:
So, -concretely- what happens to a class S (e.g. associated type
info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units,
, 2006 at 11:34:18AM -0700, Geoffrey Keating wrote:
No, there's no such note. The answer is that the two typeids have
different addresses, so one will be before the other, depending on
where the shared libraries got loaded, just as if the classes had
different names.
We're in complete
On 14/07/2006, at 3:01 PM, Gabriel Dos Reis wrote:
First of all, thank you for seeing the problem I was trying to
communicate.
Geoffrey Keating [EMAIL PROTECTED] writes:
| Joe Buck [EMAIL PROTECTED] writes:
|
| I wrote [for two classes S with visibility == hidden ]
| | | We can have two
Laurynas Biveinis [EMAIL PROTECTED] writes:
Hi,
combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
(0.61) 4% (4%). User running time: 0m16 (0m14).
Are these with checking on or off? Normally checking is on, you have
to go out of your way to turn it off. If it were
Jason Merrill [EMAIL PROTECTED] writes:
Gabriel Dos Reis wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
| I'm just not comfortable with the idea of #pragmas affecting
| instantiations. (I'm OK with them affecting specializations, though; in
| that case, the original template has
On 28/06/2006, at 2:21 PM, Jason Merrill wrote:
Geoffrey Keating wrote:
[#pragma visibility affecting explicit instantiations]
A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure
Dustin Laurence [EMAIL PROTECTED] writes:
I'm pretty sure this is stepping into deep quicksand, but I'll ask
anyway...I'm interested in writing an FE for a language that has
stackable coroutines (Lua-style, where you can yield and resume
arbitrarily far down the call stack). I'm trying to
David Edelsohn [EMAIL PROTECTED] writes:
Daniel Jacobowitz writes:
Daniel On Mon, Jun 12, 2006 at 10:22:17AM -0400, David Edelsohn wrote:
Typing make in the gcc subdirectory does not do what I expect.
Daniel Then could you clarify what happens, and what you expect, please?
The
On 09/06/2006, at 7:24 AM, Jack Howarth wrote:
Geoff,
I don't seem to have access to read...
rdar://problem/4428696 a strong symbol in a dylib should not
override a weak private extern symbol
Does the radar report describe any workarounds?
As far as I know, there are no workarounds
On 08/06/2006, at 7:48 AM, Jack Howarth wrote:
Geoff,
I noticed PR 26792 last night. After reading that it became
clear what
was causing the massive c++ regressions when I built gcc trunk
under fink.
Fink sets MACOSX_DEPLOYMENT_TARGET to 10.4 when a package is built in
fink 10.4
On 07/06/2006, at 11:33 AM, Daniel Jacobowitz wrote:
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
And string does not answer localization issue, however for numbers
at least
there is one precedent to follow.
I think this discussion has gotten totally sidetracked. When I
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang DW_AT_APPLE.../DW_AT_GNU...
I read this. I'm not anywhere near an expert in dwarf or anything
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal radar numbers and replaces s/
Devang DW_AT_APPLE.../DW_AT_GNU...
I read
On 06/06/2006, at 5:11 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
Geoffrey Keating wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
Tom Tromey wrote:
Devang == Devang Patel [EMAIL PROTECTED] writes:
Devang This version removes internal
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said We control the debug output machinery
generating this, and can simply tell it to only deal in one
language. Here, you seem to be implying that the messages should be
localised in the language the compiler is going to output
On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
Right above, you said We control the debug output machinery
generating this, and can simply tell it to only deal in one
language. Here, you seem to be implying that the messages
should be
On 05/06/2006, at 1:44 PM, Jack Howarth wrote:
I noticed that Xcode 2.3 seems to have a cctools with a higher
version that that in the infrastructure directory at the gcc ftp
site. Should we be using the Xcode 2.3 version instead of that
20060413 copy for building gcc trunk?
Yes.
On 05/06/2006, at 2:58 PM, Jack Howarth wrote:
Geoff,
Would the ld64 in the cctools of Xcode 2.3 happen to resolve
PR 27121?
Jack
27121 was originally reported as a bug which can only be resolved by
cctools, not ld64 which is not part of cctools. I see there was some
On 05/06/2006, at 6:09 PM, Jack Howarth wrote:
Geoff,
Could you update the cctools (particularly the source version)
in infrastructure to the newer version?
I see no reason to do this.
You can get the last released version of cctools at
On 05/06/2006, at 6:55 PM, Jack Howarth wrote:
Geoff,
Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to
build
it using the same fink packaging script used for odcctools. However
I get
a build failure of...
cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp -
[EMAIL PROTECTED] (Jack Howarth) writes:
Mike,
Actually the problem appears unrelated to cxa_atexit as neither
-fuse-cxa-atexit nor -fno-use-cxa-atexit eliminates the problem
with the throw aborting the program.
I do believe I have found a work-around to the problem which
identifies
On 31/05/2006, at 4:59 PM, Jack Howarth wrote:
Geoff,
Nice call. If I relink xplor with 'gcc -shared-libgcc', the
program
no longer aborts on the throw in the c++ code. As before, if I remove
the '-shared-libgcc' and link with gcc, I get the abort on the throw.
Anything else can provide
On 09/05/2006, at 12:37 PM, Bradley Lucier wrote:
On May 3, 2006, at 7:50 PM, David Fang wrote:
FWIW, the 20060415 mainline (4.2) snapshot bootstrapped for me, using
odcctools-20060413 (odcctools-590.36od13). This machine is a dual G5
(ppc970) using OS X 10.3.9, and Apple's gcc-3.3 (build
Roberto Bagnara [EMAIL PROTECTED] writes:
Hi there,
I have read the files darwin-ldouble* in GCC 4.1.0.
What I would like do know is whether I can expect
long doubles on Darwin to comply with ISO C99 7.6
(Floating-point environment).
They can be made compliant with that section, but it
Mark Mitchell [EMAIL PROTECTED] writes:
However, the PowerPC GNU/Linux community seems to want this feature very
badly, and has suggested that failure to incorporate these patches in
GCC 4.1 would be very bad. My feeling is that it is the PowerPC
community which will be harmed if they get
On 25/01/2006, at 11:52 PM, Giovanni Bajo wrote:
svn log --stop-on-copy svn://gcc.gnu.org/svn/gcc/branches/stree-branch
I got my branches confused; it's on static-tree-branch. Revision 88377.
smime.p7s
Description: S/MIME cryptographic signature
On 25/01/2006, at 4:09 PM, Giovanni Bajo wrote:
Hi Geoff,
re this mail:
http://gcc.gnu.org/ml/gcc/2004-09/msg01357.html
do you still have the code around? Are you still willing to
contribute it?
Maybe you could upload it to a branch just to have it around in
case someone is
willing to
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
The difficulty is thread-safety. If we had some reliable way of allocating
memory whenever a new thread was created on platforms that don't have TLS,
it would be easy to fix.
On 23/01/2006, at 6:23 AM, Eric Botcazou wrote:
Attached is a patch to the 4.1 branch, I think it will apply to
mainline
too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada
enabled.
That's not sufficient: the compiler bootstraps fine, but all the
ACATS tests
fail to link:
On 23/01/2006, at 1:51 PM, Eric Botcazou wrote:
As I said before in this thread, the Ada driver should do what the
C++
driver does, which is to pass -shared-libgcc if it's going to need
EH support. Or, you could pass -fexceptions to the link, which has
the same effect.
That's not really
On 17/12/2005, at 10:08 AM, Jakub Jelinek wrote:
But there are dozens of other uses of TREE_PUBLIC in the backends, so
it wouldn't surprise me if something similar is not present on
other arches.
Normal aliases are usually declared through
extern __typeof (foo) bar __attribute__((alias
4.1 ships...
--
- Geoffrey Keating [EMAIL PROTECTED]
===File ~/patches/gcc-weakrefstatic-0.patch=
Index: gcc/ChangeLog
2005-12-01 Geoffrey Keating [EMAIL PROTECTED]
* doc/extend.texi (Function Attributes): Mention that an alias
attribute creates a definition
I've uploaded cctools-590.12 to
ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-590.12.dmg
and the source for it as
ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-590.12.tar.bz2
Their md5 checksums are:
410dd3c1471d31e24a193c674432a7f5 cctools-590.12.tar.bz2
Kean Johnston [EMAIL PROTECTED] writes:
Hi all,
After days spent trying to get a clean gmake check run, I am down to
the last few failures. They are all related to the PCH tests, and they
all
fail the same way: largefile.c:1: fatal error: had to relocate PCH.
Previously, *all* PCH tests
[EMAIL PROTECTED] (Ross Ridge) writes:
The POSIXy way to do that would be to refer to the LC_CHARSET
environment variable, but then consider
LC_CHARSET=UTF-16 c99 foo.c
where 'foo.c' is in UTF-16 and contains '#include stdio.h',
Not really a problem for a number of reasons. First,
1 - 100 of 137 matches
Mail list logo
