On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
> while debugging the java failure Divide_1 on s390 I stumbled over
> some weird behaviour in the unwinding code.
>
> In the testcase a divide by zero is triggered intentionally. So that
> the java sigfpe handler is invoked in __divdi3:
>
> Divide_1::p
On 01/27/2012 05:14 PM, Dave Korn wrote:
> On 27/01/2012 17:01, Andrew Haley wrote:
>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>
>>> Starting with this IRA patch:
>>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html
>>> __divdi3 does *not* ne
On 01/27/2012 05:18 PM, Dave Korn wrote:
> On 27/01/2012 17:16, Andrew Haley wrote:
>> On 01/27/2012 05:14 PM, Dave Korn wrote:
>>> On 27/01/2012 17:01, Andrew Haley wrote:
>>>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>>>>> Starting with th
On 01/30/2012 05:26 PM, Jon Masters wrote:
>
> On Mon, 2012-01-30 at 08:50 +, Ramana Radhakrishnan wrote:
>
>> Therefore I'm assuming this is a breakage you face when building for
>> armv5te
>
> It is indeed. Thanks for noting that.
>
>>> The icu package contains a direct call to __sync_sy
On 02/02/2012 02:51 PM, Paul Richard Thomas wrote:
> Many thanks for the patch. This makes for a rather complete
> implementation of OOP.
Excellent! It used to be said that the determined Real Programmer can
write Fortran programs in any language; now it seems that they can
write any language in
Zachary Turner wrote:
> Hello, I've been trying to write a program that links to static
> libraries, and I've been having a lot of difficulties. Was wondering
> if someone can help me identify what's going wrong.
>
> The codebase is large, but is new to linux. It was originally
> developed on wi
On 07/16/2009 09:08 PM, Zachary Turner wrote:
>
> There's also much less to deal with from a Q/A and tech support
> perspective if you use static linking with a closed source
> application, since you can produce 1 binary which works across
> multiple distributions and kernels without the user comp
On 07/18/2009 07:27 PM, Dave Korn wrote:
> Kai Tietz wrote:
>
>> Yes, I agree to this as I said in the patch post. Can we assume that
>> any win32 target has a working wincrypt.h file?
>
> Hmmm... it is supported since win2k. I imagine DGJPP runs on 9x targets,
> and believe it or not there ar
On 07/19/2009 02:29 PM, Dave Korn wrote:
> Kai Tietz wrote:
>
>> There are a lot of issues about casting HANDLE values into jint types,
>> which is for x86 valid, but for x64 can lead potential to pointer
>> truncations. Those part need some review by libjava maintainers. My
>> patch simply casts
Richard Guenther wrote:
> On Thu, 16 Jul 2009, Andrew Haley wrote:
>
>> Jan Hubicka wrote:
>>>> Running target unix/
>>>> FAIL: StackTrace2 output - source compiled test
>>>> FAIL: StackTrace2 -findirect-dispatch output - source compiled test
>
Andrew Haley wrote:
> Richard Guenther wrote:
>> On Thu, 16 Jul 2009, Andrew Haley wrote:
>>
>>> Jan Hubicka wrote:
>>>>> Running target unix/
>>>>> FAIL: StackTrace2 output - source compiled test
>>>>> FAIL: StackTrace2 -findire
Andreas Schwab wrote:
> Zachary Turner writes:
>
>> So if a=5 before a function call, then foo(++a, ++a), might invoke
>> foo(6, 6), foo(6, 7), or foo(7, 6).
>
> Or even foo(42, 666).
Or demons might fly out of your nose.
Andrew.
okell...@freenet.de wrote:
> Working on the GNAT multi-source compile feature
>
> (see http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html),
>
> I am running into crashes in ggc_collect() on compiling
>
> the 2nd file in the compile job.
>
>
>
> Following the advice given in
> http://gcc.gnu.org/
Oliver Kellogg wrote:
> On Fri, 2009-08-14 at 10:41 +0100, Andrew Haley wrote:
>>> I am stuck here, i.e. I don't know how to find the code
>>> that is
>>> at fault.
>>> Is there some way to trace a pointer entered in
>>> G.free_object_list
&g
Dave Korn wrote:
> Not simple, but not so hard as to be impossible either; as it turns out, the
> internal structure of libgcj looks a lot like a turnip, with a bunch of skinny
> branchy foliage waving around on top, a few shallow roots spreading under the
> ground, and a big ball of hair in the
This seems to be an an old bug that has come back. We're generating
L1210:
jmp *%eax
.L4:
.L5:
...
jmp .L1210
.L1171:
.L1172:
...
jmp .L1210
.L1168:
.L1169:
...
jmp .L1210
instead of
.L1210:
jmp *%eax
.L4:
.L5:
Alex Turjan wrote:
> Dear all,
> Im writing to you regarding the dead store elimination (dse) which runs after
> register allocation. Apparently dse removes wrongly the following store
> (present in bb2):
>
> (insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15)
>
Ian Lance Taylor wrote:
> Andrew Haley writes:
>
>> This seems to be an an old bug that has come back. We're generating
>>
>> L1210:
>> jmp *%eax
>> .L4:
>> .L5:
>> ...
>> jmp .L1210
>> .L11
daniel tian wrote:
> /home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/xgcc
> -B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/
> -B/usr/local/cross/rice-elf/rice-elf/bin/
> -B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
> /usr/local/cross/rice-elf/rice-elf
daniel tian wrote:
> 2009/9/21 sumanth :
>> Hi ,
>>Follow this wiki " http://gcc.gnu.org/wiki/DebuggingGCC"; to know how to
>> debug gcc.
>>As far as I know compute_frame_pointer_to_fb_displacement is the
>> displacement between your
>> frame pointer and the frame base ( mostly stack po
daniel tian wrote:
> 2009/9/28 Basile STARYNKEVITCH :
>> daniel tian wrote:
>>> Thanks.
>>> But how to debug cc1. Because now I port the gcc to my RISC target.
>>> But when build the libgcc2.c. Some error occurred. So i have to debug
>>> it.
>>> Any advice about how to debug?
>>
>> Start gdb from
Matthias Klose wrote:
> --enable-plugin is used by classpath (part of libjava) and now by GCC
> itself. disabling the build of the gcjwebplugin now disables plugin
> support in GCC as well. Please could the option for enabling GCC plugin
> support be renamed to something like --enable-plugins,
> --
Ian Lance Taylor wrote:
> Andrew Haley writes:
>
>> Matthias Klose wrote:
>>> --enable-plugin is used by classpath (part of libjava) and now by GCC
>>> itself. disabling the build of the gcjwebplugin now disables plugin
>>> support in GCC as well. Please c
Matthias Klose wrote:
> On 19.10.2009 19:42, Andrew Haley wrote:
>> Ian Lance Taylor wrote:
>>> Andrew Haley writes:
>>>
>>>> Matthias Klose wrote:
>>>>> --enable-plugin is used by classpath (part of libjava) and now by GCC
>>>>>
Mark Cave-Ayland wrote:
So I'm really confused as to how adding a simply function pointer in the
global declaration section (without even adding any code to reference
it) suddenly incurs an extra 40% overhead? Can anyone explain why this
is, and/or point me to any suitable gcc optimisation gui
Mark Cave-Ayland wrote:
Andrew Haley wrote:
There are a few possibilities, such as changing the alignment of the
data,
but without seeing the code it's hard to say.
It's just a standard checkout from the OpenBIOS SVN with a patch I can
provide to implement the recursive Fibonacc
Thomas Gleixner wrote:
> On Thu, 19 Nov 2009, Thomas Gleixner wrote:
>
> Can the GCC folks please shed some light on this:
>
> standard function start:
>
>push %ebp
>mov%esp, %ebp
>
>call mcount
>
> modified function start on a handful of functions on
Thomas Gleixner wrote:
> On Thu, 19 Nov 2009, Andrew Haley wrote:
>> Thomas Gleixner wrote:
>>> There is no real obvious reason why the edi magic needs to be done
>>> _before_
>>>
>>> push %ebp
>>> mov%esp,%ebp
>> Sure t
Thomas Gleixner wrote:
> On Thu, 19 Nov 2009, Thomas Gleixner wrote:
>
> Can the GCC folks please shed some light on this:
>
> standard function start:
>
>push %ebp
>mov%esp, %ebp
>
>call mcount
>
> modified function start on a handful of functions on
Richard Guenther wrote:
> And
> you didn't provide us with a testcase either ... so please open
> a bugzilla and attach preprocessed source of a file that
> shows the problem, note the function it happens in and provide
> the command-line options you used for building.
I've got all that off-list.
Steven Rostedt wrote:
> On Thu, 2009-11-19 at 18:20 +0000, Andrew Haley wrote:
>
>> OK, I found it. There is a struct defined as
>>
>> struct entry {
>> ...
>> } __attribute__((__aligned__((1 << (4);
>>
>> and then in timer_stats_up
Thomas Gleixner wrote:
> While testing various kernel configs we found out that the problem
> comes and goes. Finally I started to compare the gcc command line
> options and after some fiddling it turned out that the following
> minimal deltas change the code generator behaviour:
>
> Bad: -march
Andrew Haley wrote:
> Thomas Gleixner wrote:
>
>> While testing various kernel configs we found out that the problem
>> comes and goes. Finally I started to compare the gcc command line
>> options and after some fiddling it turned out that the following
>> minimal de
Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc decides to do something crazy again, this patch will catch it.
>
> Should we try to get this in now?
I'm sure this makes sense, but a gcc test case would be even bett
H.J. Lu wrote:
> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
>> Steven Rostedt wrote:
>>> Ingo, Thomas and Linus,
>>>
>>> I know Thomas did a patch to force the -mtune=generic, but just in case
>>> gcc decides to do something crazy again, th
yunfeng zhang wrote:
> The idea I got is about removing .got section in ELF format totally.
>
> Before we go, let's see the limitation on the idea
> 1) It must be deployed on aligned segment model, such as Linux, which cs.start
> = ds.start.
> 2) Currently, I only know how to do on x86 ELF.
>
> H
H.J. Lu wrote:
> On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley wrote:
>> H.J. Lu wrote:
>>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley wrote:
>>>> Steven Rostedt wrote:
>>>>> Ingo, Thomas and Linus,
>>>>>
>>>>> I know
Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
>>> you should compile your code with -maccumulate-outgoing-args, and there's
>>> no need to use -mtune=generic. Is that right?
>> Seems to work. What other side effects has that ?
>
> Faster code, significant
Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:32:20PM +0000, Andrew Haley wrote:
>> Jakub Jelinek wrote:
>>> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
>>>>> you should compile your code with -maccumulate-outgoing-args, and there's
&g
Ross Ridge wrote:
> Andrew Haley writes:
>> Alright. So, it is possible in theory for gcc to generate code that
>> only uses -maccumulate-outgoing-args when it needs to realign SP.
>> And, therefore, we could have a nice option for the kernel: one with
>> (mostly)
H. Peter Anvin wrote:
> On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
>>> space for arguments of the callee with most arguments in the prologue, using
>>> subtraction from sp, then to pass a
Ehren Metcalfe wrote:
> I've recently come across a couple of issues trying to compile Firefox
> trunk with 4.5 (I have a very simple plugin that I need to run on
> mozilla-central). I've posted two bugs here
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139 and here
> http://gcc.gnu.org/bugzilla
H. Peter Anvin wrote:
> On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
>> If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
>> then certainly coming up with a new gcc switch and new profiling ABI is
>> desirable. -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
>>
Jeff Law wrote:
> Ultimately I think there are X issues here.
>
>1. What to do in the immediate term with the repo. I've got no
> strong opinions here.
>
>2. What to do longer term. I'd like to see us fix the whitespace
> stuff then use hooks or a cron job to make sure they don't com
H. Peter Anvin wrote:
> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>> Right now they are specified in the psABI, you suggested to remove that
>> specification.
>>
>
> The intent of H.J.'s proposal is to require bits <7:1> == 0 in a
H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley wrote:
>> H. Peter Anvin wrote:
>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>>>> Aren't bits in the _Bool byte of"bar" specified by the psABI
>>>> Right now t
Hi,
Michael Matz wrote:
> On Wed, 9 Dec 2009, Andrew Haley wrote:
>
>>> The intent of H.J.'s proposal is to require bits <7:1> == 0 in all cases
>>> (and higher bits as don't cares, the same way a char is passed), as
>>> opposed to the curre
H.J. Lu wrote:
> On Wed, Dec 9, 2009 at 7:51 AM, Andrew Haley wrote:
>> H.J. Lu wrote:
>>> On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley wrote:
>>>> H. Peter Anvin wrote:
>>>>> On 12/09/2009 06:56 AM, Michael Matz wrote:
>>>>>>
Jean Christophe Beyler wrote:
> Dear all,
>
> Found on http://gmplib.org/.
>
> "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem
> is specific to that very release; specifically gcc 4.3.1 and 4.3.3
> seem to work fine."
>
> Since porting to a newer version is difficult for me
[redir to gcc-help]
On 01/01/2010 05:44 AM, Andris Kalnozols wrote:
> If the bug was a basic programming error, one would expect a
> runtime failure (dereferencing a NULL pointer) no matter which
> compiler was used.
I would not expect that, and I have no idea whay you would. Undefined
behaviou
On 01/03/2010 10:53 AM, Richard Guenther wrote:
> GCC follows its own documentation here, not some random
> websites and maybe not the strict reading of the standard.
GCC is compatible with C99 in this regard.
Andrew.
On 01/03/2010 12:52 PM, Andreas Schwab wrote:
> Florian Weimer writes:
>
>> * Joshua Haberman:
>>
>>> To me this allows the following:
>>>
>>> int i;
>>> union u { int x; } *pu = (union u*)&i;
>>> printf("%d\n", pu->x);
>>
>> I think the cast on the secodn line is undefined,
>
> Only if un
On 01/03/2010 10:14 PM, Joshua Haberman wrote:
> Andrew Haley redhat.com> writes:
>> On 01/03/2010 10:53 AM, Richard Guenther wrote:
>>> GCC follows its own documentation here, not some random
>>> websites and maybe not the strict reading of the standard.
>>
&
On 01/04/2010 10:51 AM, Mark Colby wrote:
> This sounds like a dumb question I know. However the following code
> snippet results in many more machine instructions under 4.4.2 than under
> 2.9.5 (I am running a cygwin->PowerPC cross):
>
> typedef unsigned int U32;
> typedef union
> {
> U
On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
> On Mon, Jan 04, 2010 at 12:18:50PM +0100, Steven Bosscher wrote:
>>On Mon, Jan 4, 2010 at 12:02 PM, Andrew Haley wrote:
>>> This optimization is done by the first RTL cse pass. I can't understand
>>> why it's not
On 01/04/2010 04:17 PM, Nathan Froyd wrote:
> On Mon, Jan 04, 2010 at 04:08:17PM +0000, Andrew Haley wrote:
>> On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
>>> IMHO we really should have some late tree pass that converts adjacent
>>> bitfield operations into integral
On 01/05/2010 01:15 AM, Erik Trulsson wrote:
> On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
>> Andrew Haley redhat.com> writes:
>>> On 01/03/2010 10:14 PM, Joshua Haberman wrote:
>>>> Andrew Haley redhat.com> writes:
>>> "6.3
On 01/05/2010 02:09 AM, Joshua Haberman wrote:
> Erik Trulsson student.uu.se> writes:
>> On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
>>> The text you quoted does not contain any "shall not" language about
>>> dereferencing, so this conclusion does not follow.
>>
>> It doesn't
On 01/05/2010 03:23 PM, Vincent Lefevre wrote:
> On 2010-01-05 10:31:13 +0000, Andrew Haley wrote:
>> "An object shall have its stored value accessed only by an lvalue
>> expression that has one of the following types:
>>
>> but
>>
>> (union u*)&
On 01/05/2010 07:58 PM, Joshua Haberman wrote:
> Andrew Haley redhat.com> writes:
>> but
>>
>> (union u*)&i
>>
>> is not a legal lvalue expression because the dereference is undefined
>> behaviour.
>
> Your example does not contain a dere
On 01/05/2010 07:38 PM, Joshua Haberman wrote:
> Robert Dewar adacore.com> writes:
>> In any case the gcc interpretation is clearly what's
>> intended in my view, so if it can be argued that the
>> standard is inconsistent with this interpretation (I
>> am unconvinced that this burden has been met
On 01/06/2010 04:09 AM, Joshua Haberman wrote:
> Erik Trulsson student.uu.se> writes:
>> On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
>>> The aliasing policies that GCC implements seem to be more strict than
>>> what is in the C99 standard. I am wondering if this is true or wh
On 01/06/2010 09:59 AM, Mark Colby wrote:
Yabbut, how come RTL cse can handle it in x86_64, but PPC not?
>>>
>>> Probably because the RTL on x86_64 uses and's and ior's, but PPC uses
>>> set's of zero_extract's (insvsi).
>>
>> Aha! Yes, that'll probably be it. It should be easy to fix cse to
On 01/06/2010 07:24 PM, Joshua Haberman wrote:
> In the notes that Nick referenced it says:
>
> Is there anybody that thinks the rules are clear enough? No one is
> really able to interpret them. So it seems that they are not
> clear enough. The problem is how to state them.
>
> [...
On 01/07/2010 11:42 AM, Richard Guenther wrote:
> On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley wrote:
>> On 01/06/2010 07:24 PM, Joshua Haberman wrote:
>>
>> The response I think you may get is that this is already settled.
>> I've seen this same argument man
On 01/10/2010 10:30 AM, Andreas Schwab wrote:
> Dave Korn writes:
>
>> Is that really right? The type of the pointer (in6->__s6_addr) that we're
>> casting is unsigned char *, so shouldn't it already alias everything anyway
>> and dereferencing it be allowed, like it is for the casted (a)? I'
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
> Andrew Haley writes:
>
>> Why do you say the effective type is different?
>
> The object type is uint8_t, but accessed as uint32_t. That is
> undefined.
Unless uint8_t is a character type, as I understand it. That is
clea
On 01/10/2010 02:39 PM, Paul Koning wrote:
>> ...
>> typedef unsigned char uint8_t;
>> typedef unsigned int uint32_t;
>>
>> struct in6_addr
>> {
>> uint8_t __s6_addr[16];
>> };
>>
>> static inline int
>> address_in_use (unsigned char *a, struct in6_addr *in6)
>> {
>> if const uint32_t *)(a
On 01/10/2010 04:58 PM, Patrick Horgan wrote:
> Andrew Haley wrote:
>> On 01/10/2010 12:39 PM, Andreas Schwab wrote:
>>
>>> Andrew Haley writes:
>>>
>>>> Why do you say the effective type is different?
>>>>
>>> The object
On 01/25/2010 02:42 PM, Erik Trulsson wrote:
> On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
>> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
>> wrote:
>>> I have a hash function hash(T v) overloaded for all integral
>>> types. I want to provide a variant for float and doubl
On 01/28/2010 04:01 PM, Paulo J. Matos wrote:
> On Thu, Jan 28, 2010 at 2:58 PM, Andrew Haley wrote:
>>
>> dladdr()
>>
>
> Thanks Andrew but this answer seems to assume I am trying to obtain
> this in a C program from a previously compiled function.
>
> Howe
On 02/17/2010 04:50 AM, dib.cool...@gmail.com wrote:
> hi...
> I am a student of b.sc first yr in comp.science
> can you tell me
>
> which parsing technique is used in ANSI c language and in gcc?
A hand-written recursive descent parser. It's in gcc/c-parse.c.
> and how the parse tree is ge
On 02/21/2010 12:13 PM, Richard Guenther wrote:
> On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch wrote:
>>
>> On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
>>> My point: gcc may fail to attract users (and/or may be losing users)
>>> when it tries to tailor to the needs of minorities.
>>>
>>> IMH
On 02/22/2010 12:29 AM, Erik Trulsson wrote:
> On Sun, Feb 21, 2010 at 11:35:11PM +, Dave Korn wrote:
>> On 21/02/2010 22:42, Erik Trulsson wrote:
>>
>>> Yes, it does if the user is using binaries compiled by somebody else,
>>> and that somebody else did not explicitly specify any CPU-flags.
>>
On 03/02/2010 08:55 AM, Alain Ketterlin wrote:
>
> It looks like gcc sometimes produces "useless" conditional branches.
> I've found code like this:
>
> xor%edx,%edx
> ; code with no effect on edx (see full code below)
> test %edx,%edx
> jne
>
> The branch on the last line is n
On 03/02/2010 09:38 AM, Peter Kourzanov wrote:
> I have the following variation on Duff's device that seems to
> mis-compile on all GCC versions I can access within a minute (that
> is gcc-3.{3,4}, gcc-4.{1,2,3,4} on x86 and gcc-4.3.2 on x86_64). The
> symptoms are as follows:
>
> $ gcc-4.4
On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
>> int duff4_fails(char * dst,const char * src,const size_t n)
>> {
>> const size_t rem=n % 4, a=rem + (!rem)*4;
>> char * d=dst+=a;
>> const char * s=src+=a;
>> /* gcc bug? dst+=n; */
>>
>> switch (rem) {
>> case 0: for(dst+=n;d>
On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote:
> I am highly interestd in implementing C compiler for EFI Byte Code in
> gcc and participate in Google Summer Code.
>
> EFI is a much larger, more complex,OS-like replacement for the older BIOS
> firmware interface present in all IBM PC-compati
On 03/03/2010 10:53 AM, Tristan Gingold wrote:
>
> On Mar 3, 2010, at 11:36 AM, Andrew Haley wrote:
>
>> On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote:
>>
>>> I am highly interestd in implementing C compiler for EFI Byte Code in
>>> gcc and participat
On 03/04/2010 07:27 PM, b95705...@ntu.edu.tw wrote:
> 引述 Andrew Haley :
>
>> There is no reason in principle this shouldn't be part of gcc.
>>
>> I think no-one has responded yet because they don't know what it would
>> be for, and how much work it would
On 03/06/2010 04:43 AM, John Regehr wrote:
> The question is, what should C and C++ compilers do with this code?
>
> volatile int x;
>
> void foo (void) {
> x;
> }
>
> This question is not totally stupid: embedded systems use code like this
> when reading a hardware register has a usef
On 06/03/10 15:54, John Regehr wrote:
>> I'm not sure this follows. It's stated explicitly that "The
>> expression is evaluated and its value is discarded." How can you
>> evaluate the expression without reading the volatle?
>
> I'm certainly not an expert on this material but I wouldn't think y
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
> On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
> wrote:
>> Note, that many hash tables are computed by the modulus operation, which is
>> often fairly expensive (and on machines without a hardware divide unit,
>> requiring a function call). I woul
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
> On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
> wrote:
>> Note, that many hash tables are computed by the modulus operation, which is
>> often fairly expensive (and on machines without a hardware divide unit,
>> requiring a function call). I woul
On 03/22/2010 12:43 PM, Robert Dewar wrote:
> the code for computing the hash has to be taken into account, but
> nothing else than actual benchmarks will give an accurate
> comparison.
I agree. I'd also like to point out that as it is not very difficult
to do these benchmarks, the proponent(s)
On 28/03/10 15:45, Carrot Wei wrote:
> Hi
>
> The detailed description of the optimization is at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129. This is an ARM
> specific optimization.
>
> This optimization uses one less register (the register hold the GOT
> base), to get this beneficial the
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
> Hello,
> One of our engineers requested a feature so that
> compiler can avoid to re-load variables after a function
> call if it is known not to write to memory. It should
> slash considerable code size in our applications. I found
> the existing "pur
On 04/12/2010 07:22 PM, Dave Korn wrote:
> On 12/04/2010 17:33, Andrew Haley wrote:
>> On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
>>> Hello,
>>> One of our engineers requested a feature so that
>>> compiler can avoid to re-load variables after a function
>
On 04/13/2010 10:45 AM, Richard Guenther wrote:
> On Tue, Apr 13, 2010 at 10:55 AM, Bingfeng Mei wrote:
>> Something like printf (Though I read somewhere glibc extension of printf
>> make it non-pure).
>
> Surely printf writes to global memory (it clobbers the stdout FILE*)
I suppose a system ca
On 04/15/2010 12:57 PM, Basile Starynkevitch wrote:
>
> Of course I do know about gcj. But I never met any person using it,
> and I don't know about any person or project really using it (as an
> example, I am not sure than any Debian or Fedora package is compiled
> with gcj into a native executab
On 04/15/2010 01:07 PM, Steven Bosscher wrote:
> On Thu, Apr 15, 2010 at 2:03 PM, Andrew Haley wrote:
>> On 04/15/2010 12:57 PM, Basile Starynkevitch wrote:
>>>
>>> Of course I do know about gcj. But I never met any person using it,
>>> and I don't know ab
On 04/21/2010 06:35 PM, Chris Lattner wrote:
>
> On Apr 21, 2010, at 3:32 AM, Tomohiro Matsuyama wrote:
>
>> Hi, all
>>
>> I have been working on implementing a tool-set of code assistance
>> called GCCSense, which enables code-completion for C/C++ in editors
>> or a terminal.
>>
>> http://cx4a.o
I have some broken code, compiled from Java source.
It looks like:
D.843 = &java.text.Collator.class$$;
_Jv_InitClass (D.843);
D.845 = &_CD_java_text_Collator;
is being turned into:
D.843 = &java.text.Collator.class$$;
D.845 = &_CD_java_text_Collator;
_Jv_InitClass (D.84
Richard Guenther wrote:
> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> I have some broken code, compiled from Java source.
>>
>> It looks like:
>>
>>D.843 = &java.text.Collator.class$$;
>>_Jv_InitClass (D.843)
Andrew Pinski wrote:
> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>>> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>>> I have some broken code, compiled from Java sourc
Andrew Pinski wrote:
> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>>> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>>> I have some broken code, compiled from Java sourc
Richard Guenther wrote:
> On Mon, Oct 13, 2008 at 4:38 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Andrew Pinski wrote:
>>> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>>> Richard Guenther wrote:
>>>>&
Daniel Berlin wrote:
>> It's a field in the class$ structure. class$ is initialized by creating a
>> CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field. The
>> DECL_INITIAL of class$ points to the CONSTRUCTOR tree.
>>
>> _CD_pp is an array of void*. These are initialized by DECL_
Daniel Berlin wrote:
>> It's a field in the class$ structure. class$ is initialized by creating a
>> CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field. The
>> DECL_INITIAL of class$ points to the CONSTRUCTOR tree.
>>
>> _CD_pp is an array of void*. These are initialized by DECL_
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 it?
Oh my goodness, that is a huge patch. It's also incorrect, as
far as I can see: LONG_LONG_TYPE_SIZE is nev
401 - 500 of 1072 matches
Mail list logo
