Re: PR 26792

On 09/06/2006, at 7:24 AM, Jack Howarth wrote: Geoff, I don't seem to have access to read... 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 other than to avoid the p

Re: Generator programs can only be built with optimization enabled?

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, ple

Re: Coroutines

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

Re: Boehm-gc performance data

"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

Re: Visibility and C++ Classes/Templates

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

Re: Visibility and C++ Classes/Templates

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 ma

Re: gcc visibility used by moz

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

Re: gcc visibility used by moz

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

Re: gcc visibility used by moz

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 exp

Re: gcc visibility used by moz

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 th

Re: gcc visibility used by moz

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 tran

Re: gcc visibility used by moz

ty framework prevent that from happening? > > Joe Buck <[EMAIL PROTECTED]> writes: > > > By a note in the documentation telling the user "don't do that". > > On Fri, Jul 14, 2006 at 11:34:18AM -0700, Geoffrey Keating wrote: > > No, there's no

Re: gcc visibility used by moz

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 =

Re: gcc visibility used by moz

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 i

Re: ld -shared -Bsymbolic and C++ shared library

"H. J. Lu" <[EMAIL PROTECTED]> writes: > ld -shared -Bsymbolic will reduce number of dynamic relocations in > a shared library. Unfortunately, it won't work correctly with C++ > exception and maybe other language features. > > However, I think it is possible to make -shared -Bsymbolic to work > f

Re: Building libstdc++ for powerpc-eabi

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

Re: ___divti3 and ___umodti3 missing on Darwin

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. The

Re: ___divti3 and ___umodti3 missing on Darwin

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

Re: ___divti3 and ___umodti3 missing on Darwin

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 [Ja

Re: How to GTYize a struct properly?

"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 hi

unwind, x86, DW_CFA_GNU_args_size

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 th

Re: unwind, x86, DW_CFA_GNU_args_size

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 w

Re: unwind, x86, DW_CFA_GNU_args_size

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 instr

Re: = {0} in bss?

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

Re: test for excess errors

[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

Re: linkage gcc.misc-tests

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 $native_c

Re: call dsymutil on darwin when compiling and linking in single step

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

Re: libgfortran build broken on Darwin ppc

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 Descr

Re: new libjava regression on darwin

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. C

Re: new libjava regression on darwin

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.

Re: new libjava regression on darwin

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, known,

Darwin as primary platform

Hi Mark, 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

Re: Darwin as primary platform

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? Wi

intermittent failures on Darwin using java.lang.Process.waitFor()

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 the

Re: Darwin as primary platform

"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.

Re: unwind-dw2-fde-darwin.c corrections

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 117

Re: unwind-dw2-fde-darwin.c corrections

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

Re: unwind-dw2-fde-darwin.c corrections

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 gcc-4.2-20061002/gcc/unwind-dw2-

Re: Darwin as primary platform

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 o

Re: unwind-dw2-fde-darwin.c changes

[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

Re: automatic --disable-multilib

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 w

Re: GCC 4.0 Status Report (2005-02-03)

Mark Mitchell <[EMAIL PROTECTED]> writes: > Steven Bosscher wrote: > > Or should the development plan beupdated to reflect your new way of > > working (ie. the projects info collecting thing) and the actual > > development schedule that we seem to be working on. > > It would probably be good if t

Re: Details for svn test repository

Daniel Berlin <[EMAIL PROTECTED]> writes: > I also plan on excluding merge tags I'd really rather that you didn't. Those tags are useful when you're looking at some old change on a branch.

Re: RFC: Make dllimport/dllexport imply default visibility

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 visibili

Re: RFC: Make dllimport/dllexport imply default visibility

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 o

Re: RFC: Make dllimport/dllexport imply default visibility

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

Re: RFA: upcoming testsuite disruptions

Janis Johnson <[EMAIL PROTECTED]> writes: > There's a testsuite patch that I submitted, but haven't yet > checked in, that will break test summary comparisons from before > and after that patch is applied: > > http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00834.html > http://gcc.gnu.org/ml/gcc-pat

Re: Test gcc.c-torture/execute/align-3.c

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. 2007-07-12

Re: RFH: GPLv3

Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Jul 13, 2007, Nicholas Nethercote <[EMAIL PROTECTED]> wrote: > > > One way to view it: the license is a feature. Therefore changing the > > license is changing a feature. > > Every release of GCC in the past decade (and then some) was GPLv2+. >

Re: RFH: GPLv3

[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

Re: AltiVec stack boundary

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 -

Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]

"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 compilin

Re: tgmath.h and newlib

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 co

Re: Preparsing sprintf format strings

[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

<    1   2