Omar Torres wrote:
> I have a similar issue to what is reported here
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143):
> /Applications/avr/avr-src/gcc/unwind.h:59: error: unable to emulate 'DI'
>
> As you clearly expressed by Paul, the underline issue that the target
> only support data type
Omar Torres wrote:
> On Thu, Oct 16, 2008 at 10:02 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Omar Torres wrote:
>>> Hi Andrew,
>>> Looks like Paul did submitted a patch here:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
>>>
>&g
Paul Schlie wrote:
> Andrew Haley wrote:
>> Omar Torres wrote:
>>> Hi Andrew,
>>> Looks like Paul did submitted a patch here:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
>>>
>>> Can you or someone else take a look and comment on i
hyeron bosh wrote:
> I have a (probably naive) question about
> messing up the stack pointer.
>
> Here is the code produced by gcc
> for some function "X" (original source code is C/Obj-C)
>
> # function "X" entry point
> 0x82699 <>: push %ebp
> 0x8269a <+1>: mov%
`VL wrote:
> Hello, ALL.
>
> I recently started to actively program using C and found that tools like
> ctags or cscope do not work properly for big projects. Quite ofthen they
> can't find function or symbol definition. The problem here is that they don't
> use full code parsing, but just some s
Balaji V. Iyer wrote:
> I am trying to add new RTL into the GCC 4.0.2 OpenRISC port and I am
> trying to insert them into ccertain parts of the instruction stream. For
> testing, I am trying to insert it in the start of every basic block.Here
> is the code for what I am trying to do.
>
> rtx
Balaji V. Iyer wrote:
> This is what I am trying to achieve. I want to indicate to my processor
> at certain points of execution to do certain control behavior. I am
> trying to do this by inserting a specialized instruction that will do
> so.
>
> I am not using the unspec model. I created a new
-convert] Error 1
>> make[3]: *** Waiting for unfinished jobs
>>
>>
>> Last known build that worked was revision 141116.
>>
>> Thanks,
>> Andrew Pinski
>
> The last build I did on i686-apple-darwin9 was r141456 and it built libjava
> fine.
&g
Zhang Le wrote:
>
> The other would be make sure the destination register is different from
> source registers.
> I have read some docs, but still not sure how to do it.
That's just an earlyclobber. Search for that.
Andrew.
Dong Phuong wrote:
> I've declared some macros in my target description
> file to add more attributes to it.
>
> When I built it, everything was OK and file cc1.exe
> was created.
>
> But when I use attributes in my C source file. For
> example :
> int x __attribute__ ((model ("small)));
>
>
Brian Dessent wrote:
> Paul Brook wrote:
>
>> If you really want to solve this then you could always stop using PE/COFF.
>> The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates
>> how this can be done. Basically the toolchain generates ELF objects,
>> executables and DSOs,
Brendon Costa wrote:
> I want to use GCC to categorise "functional purity" in C++. My
> definition will differ from classic functional purity. In particular:
>
> A function is considered pure if it makes no changes to existing
> memory or program state. There may be a few exceptions to this rule
Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew, thanks for your quick reply.
>
> Andrew Haley schrieb:
>> Rainer Emrich wrote:
>>
>>> I try to build a cross compiler host x86_64-unknown-linux-gnu -> targ
Rainer Emrich wrote:
> I try to build a cross compiler host x86_64-unknown-linux-gnu -> target
> hppa64-hp-hpux11.00 using gcc trunk.
>
> Everything wents fine until building of the libraries.
> libssp is build, but libiberty fails in the configure step:
>
> checking for sys/types.h... yes
> che
This is a bug in gcc.
The string is hard coded in: gcc/config/pa/pa64-hpux.h
/* The libgcc_stub.a and milli.a libraries need to come last. */
#undef LINK_GCC_C_SEQUENCE_SPEC
#define LINK_GCC_C_SEQUENCE_SPEC "\
%G %L %G %{!nostdlib:%{!nodefaultlibs:%{!shared:-lgcc_stub}\
/usr/lib/pa20_64/mill
In this test case:
int fn () __attribute__ ((warn_unused_result));
int
foo ()
{
if (fn () < 0)
return -1;
(void) fn ();
return 0;
}
$ gcc -S -Wall ~/p.c
/home/aph/p.c: In function 'foo':
/home/aph/p.c:5: warning: ignoring return value of 'fn', declared with
attribute warn_unused_resul
Andrew Haley wrote:
> In this test case:
I now see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
Please ignore my earlier message.
Etienne Lorrain wrote:
> Hello,
>
> I did not find any documentation of a "rep ret" instruction, at
> http://www.intel.com/design/processor/manuals/253667.pdf
> they just say: "The behavior of the REP prefix is undefined when used with
> non-strings instructions".
>
> Any pointers?
http://g
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem with this is that it keeps the libtool test for dynamic
> linker characteristics from working properly, due to the undefined
> refe
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Andreas Schwab wrote:
>>> Why is the libjava directory configured with raw_cxx?
>>>
>>> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>>>
>>> The problem with this
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Andreas Schwab wrote:
>>> Andrew Haley writes:
>>>
>>>> Andreas Schwab wrote:
>>>>> Why is the libjava directory configured with raw_cxx?
>>>>>
>>>>> Makefi
Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Sure, but a generic link test shouldn't require a directory to be
>> configured in any special way.
>
> I don't see where that requirement is special. After all, RAW_CXX is
> definitely not a full C++ c
Andreas Schwab wrote:
> Ralf Wildenhues writes:
>
>> So I don't see how to avoid a test here, and hard-coding "yes" for
>> gentoo and "no" for most other distros sounds pretty ugly.
>
> And not very accurate either.
What is done to solve the same problem in libstdc++?
Andrew.
Sebastian Redl wrote:
> Michel Van den Bergh wrote:
>> That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
>> 8.10 (Intel core2 duo)
>> I get
>>
>> stest.c: In function ‘main’:
>> stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
>> has type ‘char[20]’
>>
>> The
Andrew Thomas Pinski wrote:
> C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
> arrays in C++98. Also this code is still undefined C99 but will most
> likely become valid C1x.
Ah, it's an rvalue array. Good point.
> Sent from my iPhone
Advertising on gcc list. Dear me...
VandeVondele Joost wrote:
> Current trunk fails for me with
>
> thats is on a standard linux (x86_64) box running opensuse 11.0, and a
> clean checkout. Is this a known problem?
You haven't installed the 32-bit glibc devel package.
Andrew.
VandeVondele Joost wrote:
>>> thats is on a standard linux (x86_64) box running opensuse 11.0, and a
>>> clean checkout. Is this a known problem?
>>
>> You haven't installed the 32-bit glibc devel package.
>
> Many thanks, that fixed it.
>
> Would be great if such a thing could be detected at con
Here's a strange case of poor code generation with -Os.
unsigned short foo2 (unsigned char on_off, unsigned short *puls)
{
return puls[on_off-1];
}
With -O2, it's fine:
movzbl %dil, %edi
movzwl -2(%rsi,%rdi,2), %eax
ret
With -Os it's really weird:
movzbl %d
Eric Botcazou wrote:
>> Thanks. Are you holding this because we're in Stage 3?
>
> The patch was written very recently so I wanted to let it go through a good
> deal of internal testing. Moveover I haven't measured its impact on anything
> else than Ada benchmarks (and on a patched 4.3 branch)
Zoltán Kócsi wrote:
> I have a question with regards to ARM interworking. The target is
> ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc,
> 4.3.1 with binutils maybe 3 months old.
>
> It seems that when interworking is enabled then when a piece of THUMB
> code calls an other p
Paolo Bonzini wrote:
Not for PTA though ;)
>>> Care to expand?
>> PTA tracks points-to-NULL as pointing to "nothing".
>> This probably should be conditional on -fdelete-null-pointer-checks.
>> Otherwise *NULL and *anything won't alias.
>
> Yes, you're right. I'll see if I can construct a tes
Sebastian Redl wrote:
> Laurent GUERBY wrote:
>> Just curious: is there a "portable" way to read from memory
>> address zero in C code? "portable" here means likely to work
>> on most compilers without exotic compile flags in 2009.
>>
> For C++, in *theory*, a reinterpret_cast(0) yields a pointe
Zoltán Kócsi wrote:
> On Tue, 27 Jan 2009 07:08:51 -0500
> Robert Dewar wrote:
>
>> James Dennett wrote:
>>
>>> I don't know how much work it would be to disable this optimization
>>> in gcc.
>> To me, it is always troublesome to talk of "disable this optimization"
>> in a context like this. The p
Zoltán Kócsi wrote:
>> No, this is since C90; nothing has changed in this area. NULL
>> doesn't mean "address 0", it means "nothing". The C statement
>>
>> if (ptr)
>>
>> doesn't mean "if ptr does not point to address zero", it means "if ptr
>> points to something".
>
> A question then:
>
> H
Erik Trulsson wrote:
> On Wed, Jan 28, 2009 at 04:39:39PM +0000, Andrew Haley wrote:
>> "6.3.2.3 Pointers
>>
>> If a null pointer constant is converted to a pointer type, the
>> resulting pointer, called a null pointer, is guaranteed to compare
>> unequal
rkarthi2k5 wrote:
> Hi Sir/Mam,
Do not post this to the gcc list, which is for the development of gcc.
I answered your question on the gcc-help list.
Andrew.
Uwe Kleine-König wrote:
> currently[1] __builtin_return_address for ARM only works with level == 0.
>
> For ftrace in the linux kernel it would be great to implement that for
> level > 0 (provided that framepointers or unwind information are
> available of course). On the linux-arm-kernel ML Mik
Paul Brook wrote:
As I understand it, the ARM kernel can now do something similar. So,
the only use for a __builtin_return_address(N) that used the frame
pointer chain would be if the code were compiled with nonstandard
options.
>>> Correct.
>> Well, but wouldn't it still be
Ian Lance Taylor wrote:
> Joel Sherrill writes:
>
>> Ian Lance Taylor wrote:
>>> I've put a project proposal for split stacks on the wiki at
>>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>>> of a single thread to be split into discontiguous segments, thus
>>> permitti
Julian Brown wrote:
> On Thu, 26 Feb 2009 15:54:14 +
> Andrew Haley wrote:
>
>> Paul Brook wrote:
>>>> Well, but wouldn't it still be nice if
>>>> __builtin_return_address(N) was implemented for N>0 by libcalling
>>>> int
Dave Korn wrote:
> Julian Brown wrote:
>
>> Unfortunately backtraces don't currently terminate cleanly if code
>> without unwind data is reached: CodeSourcery are currently working on
>> fixing the linker so that non-unwindable regions are marked properly,
>> which we consider essential to making
Seema Ravandale wrote:
> Hi.
>
> Given a function pointer in GIMPLE IR, is there any way to find
> address/offset to which function pointd to?
>
> e.g. I have written a code,
> /** C code **/
> void foo()
> {
> . . . .
> }
>
> void (*fptr)(void) = foo;
>
> int main()
> {
> . . . . .
> }
>
This patch:
2008-07-25 Jan Hubicka
* typeck.c (inline_conversion): Remove.
(cp_build_function_call): Do not use inline_conversion.
* decl.c (duplicate_decls): Do not insist on inline being declared
early.
(start_cleanup_fn): Do not assume that INLINE fla
Sylvain Pion wrote:
> Joseph S. Myers wrote:
>> On Mon, 9 Mar 2009, Sylvain Pion wrote:
>>
>>> Later, 1) started to be taken care of, and it was unfortunately
>>> added under the control of the same -frounding-math option.
>>> Which now, makes it harder to come back, since we want different
>>> def
Ralf Wildenhues wrote:
> Ping!
>
> * Ralf Wildenhues wrote on Sun, Mar 01, 2009 at 08:20:35AM CET:
>> I have a patch (accompanying those other ones on gcc-paches) to fix
>>
>> --- a/gcc/java/lang.opt
>> +++ b/gcc/java/lang.opt
>> @@ -209,212 +209,213 @@ Java
>>
>> ;
>> ; Warnings handled by ec
Bingfeng Mei wrote:
> I just updated our porting to include last 2-3 weeks of GCC
> developments. I noticed a large number of test failures at -O1 that
> use a user-defined data type (based on a special register file of
> our processor). All variables of such type are now spilled to memory
> which
Ralf Wildenhues wrote:
> * Andrew Haley wrote on Sat, Mar 14, 2009 at 11:05:03AM CET:
>> Ralf Wildenhues wrote:
>>> * Ralf Wildenhues wrote on Sun, Mar 01, 2009 at 08:20:35AM CET:
>>>> I have a patch (accompanying those other ones on gcc-paches) to fix
>&g
Peter Leist wrote:
> On Fri, Mar 20, 2009 at 4:54 PM, Ian Lance Taylor wrote:
>> Peter Leist writes:
>>
>>> How can I interpret the stack frame of the current_function? That
>>> means, how can
>>> I tell what is stored at the location FP+xxx. If that is not (easily)
>>> possible, it would
>>> hel
Dominique Dhumieres wrote:
>> BOSTON, Massachusetts, USA -- Tuesday, January 27, 2009 -- Today the Free
>> ^
>> Software Foundation (FSF), together with the GCC Steering Committee and the
>>^^
Chris Lattner wrote:
>
> On Mar 23, 2009, at 8:02 PM, Jeff Law wrote:
>
>> Chris Lattner wrote:
>
These companies really don't care about FOSS in the same way GCC
developers do. I'd be highly confident that this would still be a
serious issue for the majority of the companies
Kasper Bonne wrote:
>
> Since it hasn't been fixed maybe it's a bu..*ahem*..feature?
It's a feature. Look up "earlyclobber" in the Fine Manual.
Andrew.
Jan Hubicka wrote:
> current mainline is buggy in EH unwinding effectivly ignoring
> MUST_NOT_THROW regions when reached via RESX from local handlers.
> See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01285.html for details.
>
> Unfortunately this patch causes bootstrap failure when building lib
Jan Hubicka wrote:
> OK, pragma_java_exceptions variable is not there
It's in mainline now.
> does something like this work for you?
Yes.
Andrew.
Kirill Kononenko wrote:
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It seems to
> me that LLVM solves many goals that are already complete
> 2009/4/1 Andrew Haley :
>> Kirill Kononenko wrote:
>>
>>> I would like to ask your opinion about possibility for integration of
>>> the libJIT Just-In-Time compilation library and GCC. For example, the
>>> same way as libffi is integrated within gcc
Kirill Kononenko wrote:
>>> 2009/4/1 Andrew Haley :
>>>> Kirill Kononenko wrote:
>>>>
>>>>> I would like to ask your opinion about possibility for integration of
>>>>> the libJIT Just-In-Time compilation library and GCC. For exampl
Basile STARYNKEVITCH wrote:
> The second issue (which perhaps Kirill did not thought of) would be to
> accelerate some internal optimisations of GCC by using JIT-code
> generation techniques within the compiler itself. There are several
> occasions within GCC where complex internal processing happ
Dave Korn wrote:
> Kirill and Andrew wrote:
>
>>> "April Fool's joke"
>> "not your area of expertise"
>
> Maybe it would be for the best if you two started over, before this turns
> sour.
I'm out of here already! All I can say is that I hope my boss never finds
out that virtual machines and
Richard Guenther wrote:
>
> What I do find strange is the restriction to explicitly Java VM bytecode
> (not CIL or others).
I think I understand that one. Way back in time, when gcj was contributed
by Cygnus, the FSF had to be convinced that Java VM bytecode couldn't be
used to allow, e.g., an u
Fabrice Feray wrote:
> What version of Boehm's gc is best fit for the objc runtime? It seems
> that the one that comes with gcc is a special version meant for java. Am
> I wrong?
It's not substantially customized for Java, although it has some hooks that
make it work better on Java. I don't thin
Shobaki, Ghassan wrote:
> In some optimization passes it may be useful to know the programming
> language that we are compiling. Is there a way to get that information
> in the middle end and back end?
Hmm. I would rather that the amount of language-specific optimization
were kept to an absolute
Richard Guenther wrote:
> Branches will get confused. SVN does not really track file moves. So
> I think this is not a stage1 but more a stage3 thing.
>
> It also will make grepping even more painful than it is now (remember
> that ada change to introduce a 3rd directory level here ...).
>
> I
Dave Korn wrote:
> 1) Would this be a reasonable approach, specifically i) in adding a configure
> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
> construct to crudely subdivide the libraries like this?
At program startup the first library would be loaded, it would
Richard Guenther wrote:
> Is it not that maybe most of the exported symbols are not necessary and can
> be made hidden?
We already did that. This is the number of symbols in the public API.
Andrew.
Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>>
>>> 1) Would this be a reasonable approach, specifically i) in adding a
>>> configure
>>> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
>>> const
Manuel López-Ibáñez wrote:
> 2009/5/6 Paolo Bonzini :
>> It looks like a bunch of missing from
>> http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing. Anybody knows
>> what could be the cause?
>
> Relevant PRs 20336, 20588, 3119.
I'm pretty sure I have a complete set of the messages.
Andrew.
e...@sunnorth.com.cn wrote:
> Here is an optimization question about gcc compiler, we wonder whether it
> is a bug or not.
>
> A simple test program here:
> ===
> int *p;
>
> int main(void)
> {
> p++;
> __asm__ __volatile__ (""::);
>
Dave Korn wrote:
> Andrew Haley wrote:
>> eCos@ wrote:
>
>>> ===
>>> int *p;
>>>
>>> int main(void)
>>> {
>>>
Dave Korn wrote:
> Andrew Haley wrote:
>> eCos@ wrote:
>
>>> ===
>>> int *p;
>>>
>>> int main(void)
>>> {
>>>
Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>
>>> So, this is a real bug then - but it's a missed optimisation in the first
>>> case, not a bogus one in the second case?
>> Probably, but it's not a very interesting one. For what it&
Dave Korn wrote:
> Andrew Haley wrote:
>
>> Here's a starter list of non-core packages:
>>
>> gnu/CORBA
>
> By the time I got done annotating all those packages with "non-core" in
> makemake.tcl, it looked like the rule is "all packages
Dave Korn wrote:
> Ralf Wildenhues wrote:
>> * Dave Korn wrote on Wed, May 06, 2009 at 07:08:17PM CEST:
>>> Ralf Wildenhues wrote:
I don't yet see why you would need any kind of libtool hacking.
>>> Because of this:
>>>
You also have to ensure that the sub libraries are self-contained,
Dave Korn wrote:
> Andrew Haley wrote:
>
>> Did you try my list of things to lift out? I don't think there will be any
>> interdependencies; the only problem might be that the reduction is not
>> enough.
>
> Hi Andrew,
>
> I've had a qui
Dave Korn wrote:
> Ben Elliston wrote:
>> This patch silences the following warnings when building libgcc:
>>
>> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
>> strict-aliasing rules
>
>> - const _Unwind_Ptr x_ptr = *(const _Unwind_Ptr *) x->pc_begin;
>> - const _U
Dave Korn wrote:
> Dave Korn wrote:
>> Dave Korn wrote:
>>
>>> ELF GAS/LD seem happy enough when presented with a ".comm foo,0"
>>> directive,
>>> but PE does rather literally what you asked, and gives you no data object,
>>> leading to i0 in the above being an undefined reference at link time.
Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>>> Dave Korn wrote:
>>>> Dave Korn wrote:
>>>>
>>>>> ELF GAS/LD seem happy enough when presented with a ".comm foo,0"
>>>>> directive, but PE does rather
Dave Korn wrote:
> Dave Korn wrote:
>> Dave Korn wrote:
>>> I've read http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html about six
>>> times and can't see anywhere it even hints that you can use this syntax
>>> anywhere except as the trailing member of
Joseph S. Myers wrote:
> On Sun, 24 May 2009, Andrew Haley wrote:
>
>> Of course we have to fix the assembler output. For [any] two declarations
>> a and b, &a != &b, even when a is a zero-length array. So, you have to
>> allocate at least one byte.
>
>
Dave Korn wrote:
> Adding a "memory" clobber to the inline asm works around the problem,
> causing 4.3 series to generate the same assembly as head, but I think it's a
> sledgehammer approach. Am I asking too much of GCC to not sink the store, or
> is 4.3 doing something wrong? I /think/ that
Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>>
>>> Adding a "memory" clobber to the inline asm works around the problem,
>>> causing 4.3 series to generate the same assembly as head, but I think it's a
>>> sledgehammer app
Basile STARYNKEVITCH wrote:
> I am unfortunately not attending the GCC summit which happens right now
> in Montreal.
>
> But apparently, there seems to be a lack of code reviewers for GCC. The
> few people who do review code seems to have a lot of review in their
> batch queue.
>
> Perhaps could
Basile STARYNKEVITCH wrote:
> Andrew Haley wrote:
>> Basile STARYNKEVITCH wrote:
>>>
>>> Perhaps could be discussed at the summit some way to increase the set of
>>> reviewers, i.e. the set of people able to say Ok to a patch submitted on
>>> gcc-
Adam Nemet wrote:
> Andrew Haley writes:
>> We need something more like "I think Fred Bloggs knows gcc well enough
>> to approve patches to reload" or "I am Fred Bloggs and I know gcc well
>> enough to approve patches to reload."
>
> And whom should
Basile STARYNKEVITCH wrote:
> FWIW, I am not taking this question personally (I don't really claim
> that I could become any kind of reviewer; I believe in general that
> reviewing abilities should be evaluated by others.). I just think the
> set of reviewers should significantly grow.
But that ne
Basile STARYNKEVITCH wrote:
> Andrew Haley wrote:
>> Basile STARYNKEVITCH wrote:
>>
>> This is going to sound rude, but if you don't know what reload is
>> you're not able to talk about gcc maintenance.
>
> Reload is probably in the register allocator, w
Zachary Turner wrote:
> On Fri, Jun 12, 2009 at 11:32 AM, Paolo Bonzini
> wrote:
>>> This is one example, but it illustrates a general concept that I think
>>> is really useful and I personally have used numerous times for lots of
>>> other instructions than SCAS. If there is a way to achieve thi
Zachary Turner wrote:
> I guess the same reason people would want any asm functions in C
> source code. Sometimes it's just the best way to express something.
> Like in the example I mentioned, I could write 4 different functions
> in assembly, one for each size suffix, wrap them all up in a sepa
NightStrike wrote:
> On Thu, Jun 18, 2009 at 12:27 PM, David Daney
> wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gcj to work on Win64, the next step is
NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine. However, the garbage collector is in ter
NightStrike wrote:
> On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gc
Dave Korn wrote:
> Edward Peschko wrote:
>
>> 3. ecj not part of the build, hence causing at runtime:
>>
>> ld.so.1: ecj1: fatal: libgcc_s.so.1: version `GCC_4.2.0' not
>> found (required by file
>> /userdata/ebay/interface/FI/tools/beta/lib/libgcj.so.10)
>> ld.so.1: ecj1: fa
Till Straumann wrote:
> gcc-4.3.2 seems to produce bad code when
> accessing an array of small 'volatile'
> objects -- it may try to access multiple
> such objects in a 'parallel' fashion.
> E.g., instead of reading two consecutive
> 'volatile short's sequentially it reads
> a single 32-bit longwor
H.J. Lu wrote:
> On Mon, Jun 22, 2009 at 11:14 AM, Till
> Straumann wrote:
>> Andrew Haley wrote:
>>> Till Straumann wrote:
>>>
>>>> gcc-4.3.2 seems to produce bad code when
>>>> accessing an array of small 'volatile'
>>>&g
Till Straumann wrote:
> Andrew Haley wrote:
>> H.J. Lu wrote:
>>>
>>> That may be too old. Gcc 4.3.4 revision 148680
>>> generates:
>>>
>>> .L5:
>>> leaq(%rsi,%rdx), %rax
>>> movzbl(%rax), %eax
>>>
NightStrike wrote:
> On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> All that above said - do you expect us to carry both vec.h (for VEC in
>>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>>> for the alloca trick ...)? Or do you thin
g...@coreland.ath.cx wrote:
> Hello.
>
> I opened this issue a while back:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40310
>
> I was told that I needed to run the test suite in order for the patches
> to be accepted. I had trouble getting the test suite to run but have
> now managed (tu
Larry Evans wrote:
> On 06/30/09 12:59, Jonathan Wakely wrote:
>> 2009/6/30 Larry Evans:
>>> So... I read `man gcc` which claimed passing "CFLAGS=" on the
>>> command line is how to do this. Well, since in my case was
>>> '-g3 -O0' I had to pass it as CFLAGS='-g3 oO0'.
>>
>> http://gcc.gnu.org/in
Richard Guenther wrote:
> On Thu, Jul 2, 2009 at 11:19 AM, Dominique Dhumieres
> wrote:
>> In http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00038.html
>> Arnaud Charlet wrote:
>>> Can someone please fix or disable these runs? They are getting very
>>> irritating.
>> What I find extremely irritat
Andrew Stubbs wrote:
> On 02/07/09 14:34, Richard Guenther wrote:
>> No, that's invalid. You would have to do
>>
>> extern union {
>>void *foo;
>>short *bar;
>> };
>>
>> using the union for the double-indirect pointer doesn't help. Or
>> simply use memcpy to store to foo.
>
> Ah, I did n
On 04/25/2010 06:05 PM, Steven Bosscher wrote:
> On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten wrote:
>> On Sun, Apr 25, 2010 at 11:33, Richard Kenner
>> If I submit a patch to the GCC project---necessitating an assignment
>> of the copyright to the FSF---then can the people of the FSF decide
>>
501 - 600 of 1072 matches
Mail list logo
