On Dec 14, 2005, at 12:52 PM, Paul Martinolich wrote:
I have built gcc-4.1-20051209 successfully and while using it to
try to
compile Python-2.4.2, I get this error:
/Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.3.0/bin/gcc -
c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mn
On Dec 14, 2005, at 3:31 PM, Andrija Radičević wrote:
I'm trying to port gcc and binutils to a new target and I hoped to
find
a brief procedure on that matter on the net, but was unsuccessful. OK,
the GCC internals is quite a resourceful document and one can learn a
lot by examining the source
On Dec 16, 2005, at 6:23 AM, Daniel Berlin wrote:
A simple summary would be very helpful in trying to figure out what i
want to do now.
I'm sure most of the functionality exists, i'm just not sure what it's
called anymore :)
A wiki page that has the mapping from the old style to the new style
On Dec 16, 2005, at 3:05 PM, Richard Guenther wrote:
$subject - since a day now.
Thanks, fixed.
On Jun 20, 2005, at 2:41 PM, Bradley Lucier wrote:
I can't seem to build any 64-bit shared library on powerpc-apple-
darwin8.1.0, although I can now run the test suite more
effectively; see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
and
http://gcc.gnu.org/ml/gcc-testresults/2005-06/m
On Dec 17, 2005, at 6:08 AM, FX Coudert wrote:
I'm trying to understand the gfortran failure large_real_kind_2.F90
on ppc-darwin7.9, which can be reduced to:
$ cat large_real_kind_2.F90
real(kind=16) :: x
real(8) :: y
x = 1
y = x
x = cos (x)
y = cos (y)
print *, x, y, y-x
end
On Dec 17, 2005, at 10:27 PM, Andrew Pinski wrote:
On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote:
Yes; to do this right, GCC's builtins need to know about the
different names.
If you're interested in fixing this, I can tell you what to do...
I figured out how to fix it and will be posti
On Dec 19, 2005, at 2:56 PM, Jim Blandy wrote:
Subversion provides an "opt-in" version of keyword substitution, and
provides a $Revision$ keyword.
But it doesn't do what people really want it to by design. :-(
On Dec 18, 2005, at 2:17 PM, Kevin Andrew Kaploe wrote:
are they telling the truth?
Simple answer, Yes. The long answer is off-topic for this list.
A hint at the long answer lies in dependencies. If those are
precisely in sync, then there is no point at recompilation. If they
are out of
On Dec 19, 2005, at 5:34 PM, Jim Blandy wrote:
On 12/19/05, Mike Stump <[EMAIL PROTECTED]> wrote:
But it doesn't do what people really want it to by design. :-(
And that would be?
http://subversion.tigris.org/faq.html#version-value-in-source
I would like something, that
On Dec 22, 2005, at 1:54 AM, Liu Haibin wrote:
I'd like to add some source and header files into gcc. I think I
probably need to make some change in Makefile.in. But the Makefile.in
looks very complicated. Could anyone give some advice on this?
google("make tutorial"). After that, you can just
On Dec 22, 2005, at 5:28 AM, Piotr Wyderski wrote:
I am trying to compile my low-level library, which contains
several inline assembly functions. It doesn't work, because
the compiler (4.0.1) does not replace local labels from the
assembly code (i.e. "0:", "1:", etc.) with their machine-specific
On Dec 28, 2005, at 8:49 PM, Domagoj D wrote:
Can anyone explain me the following gcc/c-decl.c code (4.0.2, seems to
be unchanged in 4.2)?
What part was unclear?
#define I_SYMBOL_BINDING(node) \
(((struct lang_identifier *)
IDENTIFIER_NODE_CHECK(node))->symbol_binding)
Yes, each identifie
On Dec 28, 2005, at 11:08 PM, [EMAIL PROTECTED] wrote:
Is there any options in converting assembly code to c using
gcc as u
convert c code to assmbly.
Yes, but they are all poor to very poor. see google("decompilers").
Anyway, this is off-topic for this list.
On Dec 29, 2005, at 12:38 AM, Domagoj D wrote:
Sorry, I didn't see that each identifier *is* a lang_identifier,
that's
a weird way to keep bindings. It's not that easy for someone new to
GCC
to get around the code. What was the design decision behind that hack
(instead of something like:
str
On Dec 29, 2005, at 8:37 AM, Andrew Pinski wrote:
As far as I can tell the -fobjc-exceptions flag is supposed to
work with the GNU runtime as of GCC 4.0. However, invoke.texi
still states that "Currently, this option is only available in
conjunction with the NeXT runtime on Mac OS X 10.3 and
On Dec 29, 2005, at 10:39 AM, Domagoj D wrote:
Also, not all identifiers in all languages have an ht_identifier,
again, for example, java doesn't.
Hmm... But tree_identifier in tree.h has an ht_identifier struct. So,
is gcc/tree.h C-specific?
Oops, uhm, I mean, just checking to make sure you'
On Dec 29, 2005, at 11:32 AM, Gabriel Dos Reis wrote:
I believe, but I'm not sure, that GCC is using type puning not
guaranteed to work (except "common sense" from "obvious model".)
I think the C family of language standards should think about the
issue and clarify their exact intent... I kn
On Dec 29, 2005, at 11:45 AM, Leif Ekblad wrote:
However, now I still get unresolved externals related to C++
exception-handling (_Unwind_resume
and so on).
mrs $ nm libgcc_s.1.dylib | grep Unwind_Re
8c24 T __Unwind_Resume
mrs $ nm libgcc/unwind-dw2.o | grep Unwind_Res
24c0 T __Unwind
On Dec 29, 2005, at 12:16 PM, Gabriel Dos Reis wrote:
| > I guess we just have to wait till GCC is miscompiled (probably by
| > itself) to see whether the Middle End would cite chapter and
verse :-)
I suspect that humor does not travel well through emails :-) Sorry.
As my 4 year old would
On Dec 29, 2005, at 1:01 PM, Leif Ekblad wrote:
OK, I found unwind-dw2.c in the GCC directory. I also found
the object files in the linux host directory, but not in the RDOS
cross
compilation directory. I cannot run the GCC configuration process
natively on RDOS (yet), so I must somehow build
On Dec 29, 2005, at 1:25 PM, Gabriel Dos Reis wrote:
I was actually referring to this case
This is well defined, save for possibly the fact that 4 is written as
4 and not offsetof () and uncontested.
The case I think you're thinking of was upcasting; - offsetof(). It
was decided. The d
On Dec 29, 2005, at 2:20 PM, Domagoj D wrote:
In the case anybody cares about code verifiability... It's
exteremely hard
to automatically prove the correctness of the code that uses pointer
arithmetic and casts as in the example above.
It is but a couple of trivial rules that one should have
On Dec 31, 2005, at 10:51 AM, Paul Schlie wrote:
As although C/C++ define some expressions as having undefined
semantics;
I'd rather it be called --do-what-i-mean. :-)
Could you give us a hint at what all the semantics you would want to
change with this option? Are their any code bases th
On Jan 1, 2006, at 9:26 AM, Frediano Ziglio wrote:
I noted that when PIC is enabled (-fpic, Linux Intel) ebx is
reserved to global pointer. However LzmaDecode do not access any
global data and do not call other functions (no relocations at all)
so why not use ebx register?
This is a known
On Dec 31, 2005, at 9:26 PM, Paul Schlie wrote:
be able define NULL as being some value other than 0.
Do you have a specific chip in mind you want to do this for? Why
would you want to do this? How many users would benefit from having
done this?
- enable the specification of arithmetic
On Jan 1, 2006, at 9:57 AM, Paul Schlie wrote:
- x[y] = 0;
if (x[y]) y = y+1;
And how does this differ from the portable code in which x points to
volatile data? If none, what are the advantages in being able to
write non-portable code that leaves the volatile out over standard
conform
On Jan 3, 2006, at 11:54 AM, Laurent GUERBY wrote:
To stop the annoying VM randomization you need to turn on
the old style VM layout in the kernel. Grrr.
I believe detailed instructions on the ways to disable VM
randomization
in the GCC wiki would be a welcomed addition by many GCC hackers
On Jan 8, 2006, at 3:11 PM, [EMAIL PROTECTED] wrote:
So can you tell me more about your experience with the Microchip
18F, if
somebody is currently working on this device,
Nope, don't think so.
or if the memory model of the PIC18 is definitively a problem to
gcc porting ?
Weird chips mak
On Jan 9, 2006, at 7:41 AM, [EMAIL PROTECTED] wrote:
I actually want to do coverage analysis on bootloader code from
YAMON (used mostly on MIPS board). Obviously, I cannot invoke
'gcov' on bootloader code and thus the conundrum.
Don't see why not, just arrange to save it out to memory somepl
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is
there
some reason why you can't do that?
I thought the point was that that option is temporary and will go
away.
Over my dead body. We will al
On Jan 9, 2006, at 10:46 AM, David Taylor wrote:
For a variety of reasons, we would like to be able to specify
individual compilation switches *within* individual files.
Dale added this to our gcc compiler, see the apple/trunk branch for
example, near APPLE LOCAL .* optimization pragmas lines
On Jan 17, 2006, at 1:19 PM, Daniel Jacobowitz wrote:
Someone's informed Richard Stallman that this (annoying) warning
will not be
enabled by default in GCC 4.1.
But, it currently seems to be. Should it be turned off before the
release?
The SC or Jim Wilson will know more than I.
If
On Jan 18, 2006, at 5:26 AM, Paolo Bonzini wrote:
MRS and Eric Botcazou objected strongly against not being able to
build a 1-stage GCC with --disable-bootstrap. And that's never
going to happen.
I tend to like long term stability in who things are done, but I'm
not stuck in the mud, the
On Jan 18, 2006, at 12:22 PM, Eric Lemings wrote:
Right now the infrastructure for it isn't there, but someday
it will be. But how would you indicate to the debugger what
constituted "uninteresting" headers?
I figure the responsibility for this would probably reside more
with the compiler than
On Jan 18, 2006, at 9:41 AM, Perry Smith wrote:
In the course of doing my work last week to get exception handling
working in my device driver, I learned that the exception
processing code calls malloc during the exception. This seems weak
to me. It seems like one of the most critical time
On Jan 18, 2006, at 10:24 PM, [EMAIL PROTECTED] wrote:
I thought some kind of that, yet moved to matrix approach. Reason?
The clarity.
Clarity is not an in-vogue reason for compiler code generation. Size
is, speed is. Sacrificing these two for clarity in generated code
limits the end res
On Oct 28, 2019, at 12:40 PM, Jeff Law wrote:
> I'd really like to see us move to C++11 or beyond. Sadly, I don't think
> we have any good mechanism for making this kind of technical decision
> when there isn't consensus.
I'll just point out that we do have good mechanisms in place. Consensus
On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
>> Maybe GCC-6 can bump the required
>> dejagnu version to allow for getting rid of all these superfluous
>> load_gcc_lib? *blink* :)
> I'd support that as a direction.
>
> Certainly dropping the 2001 version from our website in favor of 1.5 (which
>
On Sep 15, 2015, at 1:04 PM, Jeff Law wrote:
> Given we haven't updated the dejagnu reqs since ~2001, I think stepping
> forward would be appropriate and I'd support moving all the way to 1.5.3 with
> the expectation that we'll be on a cadence of no faster than 2 years going
> forward.
So, I a
On Sep 16, 2015, at 12:29 AM, Andreas Schwab wrote:
> Mike Stump writes:
>
>> The software presently works with 1.4.4 and there aren’t any changes
>> that require anything newer.
>
> SLES 12 has 1.4.4.
Would be nice to cover them as well, but their update schedule
On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan
wrote:
>
> Sorry about the obvious (possibly dumb) question.
> Can't we just import a copy of dejagnu each year and install it as part of
> the source tree?
TL;DR: No.
We could, and indeed, some people do engineering that way. We instead dep
On Sep 16, 2015, at 12:02 PM, Bernhard Reutner-Fischer
wrote:
> Where Joseph said he'd wait some more.. I had thought I asked longer ago than
> that, time flies if one has fun.
>
> I'd just require 1.5.3 just to avoid the time needed by folks to workaround
> those silly ordering gotchas and lo
On Jul 25, 2016, at 9:37 AM, Joseph Myers wrote:
>
> On Fri, 15 Jul 2016, Thomas Schwinge wrote:
>
>>> No, we want to have as little churn as possible in existing tests, the
>>> general policy is to add new tests (not just for OpenACC/OpenMP, but for
>>> all functionality).
>>
>> Hmm, that's so
On Sep 8, 2016, at 1:53 AM, Uros Bizjak wrote:
>
> On Mon, Sep 5, 2016 at 1:45 PM, Joseph Myers wrote:
>> On Sun, 4 Sep 2016, Uros Bizjak wrote:
>>
>>> It looks that different handling of _Complex char, _Complex short and
>>> _Complex float is there on purpose. Is (was?) there a limitation in a
On Dec 30, 2016, at 11:58 AM, Daniel Santos wrote:
>
> Still being pretty new to GCC and having never used dejagnu, expect or Tcl,
> I'm trying to determine how to best integrate my test program into GCC's test
> harness. I wrote this to help find breakages while working on optimizations
> fo
On Dec 31, 2016, at 11:18 AM, Daniel Santos wrote:
>
> The generated sources are 2MiB
Yeah, too big, better to have a generator.
> Also, I can't have the two generated .c files in the same translation unit
> (at least in their current form) because gcc's too smart with optimizations.
> :)
Yo
On Dec 31, 2016, at 2:13 PM, Daniel Santos wrote:
>
> Well I'm learning all sorts of new things; I wasn't aware that the testsuite
> was designed to run with other compilers! Does the Microsoft compiler
> support building functions using the System V ABI?
IDK. I kinda doubt it.
On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck wrote:
>
>>> While of course one hopes that there will be no issues with wide-int, a
>>> change of this size will have some pain no matter how well we have
>>> tested it. Having three reviewers will assure problems are resolved
>>> quickly.
>> Works f
I am seeing the below on wide-int. The go teststsuite violates one of the
principals of goo test suite hygiene, the names thought arbitrary, should be
stable. These names are not stable across differing build locations.
s,.*/testsuite/,,g is approximately what it needs. Thanks.
New tests t
On Feb 13, 2014, at 1:18 AM, Richard Sandiford
wrote:
> This patch tries to reduce that by providing an alternative single-script
> version.
> Python isn't yet required and I'm pretty sure this script needs 2.6
> or later.
> I'm also worried that the seek/tell stuff might not work on
> Windows.
On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
> please hold off on committing patches for the next couple of hours as we have
> a very large merge to do.
> thanks.
All done… It is in.
So, I was wondering about patterns like:
(define_insn_and_split "*setcc_di_1"
[(set (match_operand:DI 0 "register_operand" "=q")
(match_operator:DI 1 "ix86_comparison_operator"
[(reg FLAGS_REG) (const_int 0)]))]
"TARGET_64BIT && !TARGET_PARTIAL_REG_STALL"
"#"
"&& reload_c
On May 26, 2014, at 4:26 AM, FX wrote:
> Here’s a patch that removes all the casts on output operands in x86/x86_64
> code in longlong.h.
I’d love for someone to explain why the casts were there in the first place… I
like the idea of removing them.
On May 26, 2014, at 2:22 AM, FX wrote:
>> This causes GCC bootstrap to fail on Darwin systems (whose system compiler
>> is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
>> it’s the right call, see below), I’ve filed a separate report for the
>> bootstrap issue (https://
Ping?
Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated
that GMP removed the casts in 2005.
On May 26, 2014, at 4:26 AM, FX wrote:
>> So changing just 2 of them doesn't feel right to me…
>
> [Again, with the patch actually attached… sorry]
>
> Here’s a patch that rem
Gosh, https://gcc.gnu.org/projects/cxx0x.html and
https://gcc.gnu.org/gcc-4.8/cxx0x_status.html seem to old and dated now.
First, the standard before last has been published. Second, at some point, it
can’t be experimental anymore. Would be nice if someone could update the
content. The part
On Sep 5, 2014, at 4:05 AM, Thomas Schwinge wrote:
> Updating my GCC trunk working tree from r212389 (2014-07-09) to r214918
> (2014-09-04), I notice that (only) in libstdc++ testing, and only for the
> second multilib of »RUNTESTFLAGS='--target_board=unix\{,-m32\}'« (so, the
> 32-bit x86 one), a
On Sep 9, 2014, at 8:14 AM, VandeVondele Joost
wrote:
> Attached is a further revision of the patch, now dealing with check-c++.
So when last I played in this area, I wanted a command line tool that would
bin-pack from the command line. I would then grab the seconds per for each
.exp, and bin
On Sep 10, 2014, at 1:38 PM, David Malcolm wrote:
> Perhaps this is a silly question, but has anyone tried going the whole
> way and not having buckets, going to an extremely fine-grained approach
No, we fear the overhead, but do not know what it is.
On Sep 10, 2014, at 2:23 PM, Jakub Jelinek wrote:
> Seems file mkdir in tcl doesn't error on pre-existing directory,
shell mkdir will. :-)
On Sep 11, 2014, at 3:15 PM, Jakub Jelinek wrote:
> That is news to me, but given the amount of test -a/-o uses e.g. in
> gcc/configure and hundreds of places, I'd say what we care is what is more
> portable to old shells.
No, we can’t care about that. If that were true, the _ && _ in the compil
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
> Major changes since last version:
> 1) I've chang
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
I did a timing test:
Before:
real0m57.198s
user1m24.736s
sys 0m19.816s
after:
real0m28.224s
user1m27.823s
sys 0m22.374s
This is a -j70 run on a 64 core power7 of check-objc, I
On Sep 15, 2014, at 9:05 AM, Jakub Jelinek wrote:
All the updates sound good.
> Regtested on x86_64-linux, without the patch toplevel make -k check
> took 8hrs3minutes (don't have time data for that run),
This confuses me, but, no matter. Isn’t 8hrs time data? :-)
> patch toplevel make -j48
On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote:
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.
I endorse the change of default.
> The things I had to fix in the testsuite nicely reflect what we can expect
> in the real life:
A wiki page that
On Nov 23, 2014, at 4:06 PM, FX wrote:
> One question to build maintainers, and one patch submitted to top-level
> configure.ac
So, not sure who wants to review this. From the darwin perspective, Ok.
On Nov 25, 2014, at 12:15 PM, Jakub Jelinek wrote:
> On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
>> This patch fixes that by ensuring that we print that unsupported message
>> only once.
>>
>> The resulting test result comparison diff is:
>> 2014-11-25 Tom de Vries
>>
>>
On Dec 16, 2014, at 12:46 PM, Iain Sandoe wrote:
>
> On 16 Dec 2014, at 20:40, Dominique d'Humières wrote:
>>
>>> Another testsuite issue on darwin is that testsuite doesn’t clean up the
>>> .dSYM directories it generates. This gets really annoying on my autotester
>>> :(
>>
>> I have a patch
On Dec 16, 2014, at 1:24 PM, Dominique d'Humières wrote:
> My patch is different and I am attaching it (it is quite old, so it may not
> apply cleanly). The problem for more evolved form is that *.dSYM are
> directories and ASAICT there is no command in derange to remove them.
>
> At least my p
On Dec 17, 2014, at 2:21 AM, FX wrote:
>> Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
>> Would it be possible to apply the patch at
>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932
>> before 4.8.4 is released? Results with the patch are posted at
>> https:
On Dec 17, 2014, at 3:44 AM, Jakub Jelinek wrote:
> On Wed, Dec 17, 2014 at 11:16:18AM +0100, Dominique Dhumieres wrote:
>> Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
>
> Why has it not been pushed in earlier?
No good reason. No one checked it into the release
On Jan 10, 2017, at 9:13 PM, Daniel Santos wrote:
> I've gotten rid of the Makefile and everything is run now from msabi.exp.
> I've also gotten rid of the header file, now that I know how to define a
> "_noinfo" fn pointer, so it's down to just 4 files: msabi.exp, gen.cc,
> msabi.c and do_tes
On Jan 11, 2017, at 3:29 PM, Daniel Santos wrote:
> On 01/11/2017 12:25 PM, Joseph Myers wrote:
> Would this then be the correct test?
Yeah, looks good.
> On Apr 10, 2017, at 8:17 AM, David Edelsohn wrote:
>
> On Mon, Apr 10, 2017 at 10:58 AM, Simon Wright wrote:
>> I see that, in the GCC 7 Release Criteria, the Secondary Platforms list
>> includes i686-apple-darwin.
>>
>> Should this now be x86_64-apple-darwin? I've been building this since
On May 15, 2017, at 1:06 AM, Richard Biener wrote:
>
> Both SLE-11 and SLE-12 use dejagnu 1.4.4, so does openSUSE Leap 42.[12].
> Tumbleweed uses 1.6 so new SLE will inherit that. But I still do all
> of my testing on systems with just dejagnu 1.4.4.
So dejagnu is independent of most things and
On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote:
> The change I care about in 1.5.3
So, we haven't talked much about the version people want most. If we update,
might as well get something that more people care about. 1.5.3 is in ubuntu
LTS 16.04 and Fedora 24, so it's been around awhile.
On Aug 2, 2017, at 10:34 PM, Daniel Santos wrote:
>
> I'm working on a patch to modify the testsuite to obey the
> --load-average value if one is passed to make.
The code seems like a reasonable approach. Love to see numbers and test
scenarios so that others can tell if you've covered their us
The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me. The type of
the expression x.b << 8 has size 8, a size 8 integral type is a 64-bit type.
If the result is a 64-bit type, then it's argument (x.b) was a 64-bit type. In
C++, we observed what they meant in the C language standard
On Nov 14, 2017, at 3:21 PM, Joseph Myers wrote:
>
> On Tue, 14 Nov 2017, Mike Stump wrote:
>> The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me. The
>> type of the expression x.b << 8 has size 8, a size 8 integral type is a
>> 64-bit type. If the
On Aug 4, 2018, at 9:32 AM, Bernhard Reutner-Fischer
wrote:
> On Tue, 16 May 2017 at 21:08, Mike Stump wrote:
>>
>> On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote:
>>> The change I care about in 1.5.3
>>
>> So, we haven't talked much about the ve
So, in c-common.c we have:
targetm.init_builtins ();
build_common_builtin_nodes ();
and in f95-1.c we have:
build_common_builtin_nodes ();
targetm.init_builtins ();
I would like to change c-common.c to match fortran, so that the target hook can
slightly alter (rename) the linkage name
On Feb 7, 2011, at 2:51 AM, Richard Guenther wrote:
> I would say add a new hook that can be called from build_common_builtin_nodes
> instead.
Ok, thanks.
On Feb 15, 2011, at 2:47 PM, Gerald Pfeifer wrote:
> I am happy to announce that the steering committee has appointed
> Rainer Orth and Mike Stump testsuite maintainers.
Since I'm sure I can't figure out which patches are outstanding, could anyone
waiting on testsuite approval
On Feb 17, 2011, at 4:09 PM, Nicola Pero wrote:
> This patch is not me - it's by Iain Sandoe. :-)
Thanks for chipping in and helping out. I'm excited at having a Objective-C
compiler that works again on darwin.
That said, if people have any Objective-C codes, feel free to beat on them and
let
So, I was trying to debug some stuff with the top of the tree on a suse linux
x86_64 box and got:
(gdb) p mode
Unhandled dwarf expression opcode 0xf3
which I don't find entertaining. I know I _could_ install a new gdb, and most
likely this would fix the problem, but, I don't want to do that ri
So, I have a machine that has many styles of branches, among them, a normal
one, and a short version. The short version is cheaper (sometimes). The
regular one is 1 (predicted), 7 mis-predicted. The cost of mis-prediction can
be substantially higher depending upon what is in the cache. The s
On Jun 12, 2011, at 4:03 AM, Richard Guenther wrote:
> Btw, see tree.def which says
>
> /* Represents viewing something of one type as being of a second type.
> This corresponds to an "Unchecked Conversion" in Ada and roughly to
> the idiom *(type2 *)&X in C. The only operand is the value to
On Jul 20, 2011, at 1:25 PM, Ian Lance Taylor wrote:
> Interesting. I don't know why this doesn't happen on GNU/Linux.
It doesn't happen as the symbols in question are local on linux. collect2 runs
nm on public symbols looking for symbols of a particular form, it then builds
two lists, one for
On Aug 15, 2011, at 5:42 AM, Richard Guenther wrote:
> The argument still holds that no reasonable memcpy implementation
> will reject the src == dest case.
Hum... Sounds like if that's the case that we should document it in the manual
as something we expect (requirement) of the memcpy implement
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the "stock" system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
emutls ones
were not present causin
On Dec 10, 2008, at 10:23 AM, IainS wrote:
I wonder what a good long-term solution would be?
You can try something like:
#define
REAL_LIBGCC_SPEC \
"%{static-libgcc|static: -lgcc_eh -
lgcc;\
shared-l
On Dec 10, 2008, at 7:03 PM, Jack Howarth wrote:
I am confused. Assuming one builds FSF gcc configured with
--enable-threads, shouldn't that create a libgcc.a for FSF gcc
containing the ___emutls_get_address and ___emutls_get_address
symbols?
No, the people that wrote ___emutls_get_address de
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 found
from the system are, those that aren't, come from the newly
On Dec 19, 2008, at 6:24 PM, Jack Howarth wrote:
Could you comment on...
http://gcc.gnu.org/ml/gcc/2008-12/msg00310.html
Is there some specific reason it's done this way?
Yes, libgcc_s is carefully built with carefully controlled exports.
They are controlled by:
gcc/libgcc-std.ver
wh
On Jan 20, 2009, at 11:22 PM, Jack Howarth wrote:
Are there any observations that you could make concerning
the thread...
http://gcc.gnu.org/ml/gcc/2009-01/msg00297.html
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extr
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
when we ask for lower alignment. We could just reject values less
than 12
On Jan 21, 2009, at 3:43 PM, Jack Howarth wrote:
So that invalidates your previously proposed patch? Or should I
still test it?
No need to test, I was wrong about that being the bit that causes it.
The description I last posted should be about right however, one just
needs a bit of time i
On Jul 1, 2010, at 11:29 PM, Eric Siroker wrote:
> I'm getting the frontend for the Go programming language to work in
> Darwin. I encountered what looks like a bug in Darwin-specific gcc
> code.
You are obligated to spell the name of the section correctly...
$ cat t.s
.section __TEXT,__
On Sep 9, 2010, at 3:11 AM, Nicola Pero wrote:
> Can we (legally) merge Apple's Objective-C / Objective-C++ modifications to
> GCC into FSF GCC trunk ?
My take, you'd have to ask either the FSF lawyers or Apple, I'm neither. Chris
Lattner could provide an Apple answer, I'd recommend contacting
501 - 600 of 928 matches
Mail list logo
