Hello,
I've proposed a patch [1] for condition coverage profiling in gcc,
implemented in the middle-end alongside the branch coverage. I've
written most of the tests for C and a few for C++ and finally got around
to try it with a toy example for D and go and noticed something odd
about Go's
upport ?
Does any of this sound practical ? If not, why not ? Does anyone have any good
suggestions as for what I might familiarize myself with for doing this ?
Best Regards,
J. Hart
It's nice that GCC has included a constructor attribute, but it
doesn't work in complex scenarios.
I was considering tinkering with adding a 'initializer' and '?exiter'
or maybe 'deinitializer'? (not sure what to name the other side) But
on to the primary...
__attribute((initializer(priority)))
Here's the gist of what I would propose...
https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
In C, there are two operators . and -> used to access members of struct and
union types. These operators are specified such that they are always paired
in usage; for example, if the left hand
); // 'wrong' operators...
}
int main( void ) {
f();
return 0;
}
```
I haven't built the testsuite...
On Mon, Dec 16, 2019 at 5:51 AM J Decker wrote:
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7e
On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote:
> * J. Decker:
>
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members
On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote:
>
>
> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote:
>
>> * J. Decker:
>>
>> > Here's the gist of what I would propose...
>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280d
On Fri, Dec 20, 2019 at 12:03 PM J Decker wrote:
>
>
> On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote:
>
>>
>>
>> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer
>> wrote:
>>
>>> * J. Decker:
>>>
>>> > Here&#
On Sat, Dec 21, 2019 at 11:11 AM Allan Sandfeld Jensen
wrote:
> On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two o
Somewhat like assembly meets c99 /javascript with maybe an extended
preprocessor macro system (#declr? )
pointers rarely contain a single value, they either reference an array, or
a group of values. In the case of the latter, the pointerVarName.FieldName
pair specifies to get the value, and then a
Hello
i have code:
void a(int i)
{
switch(i)
{
default:
switch(i) // exactly that same i
{
case 0:
f0();
break;
case 1:
f1();
break;
case 2:
f2();
break;
This is the code.
--
#define PointerA struct a *
void f( PointerA );
typedef struct a * PA;
struct a { int x; };
void f( PA a )
{
}
-
This is the output
warning: 'struct a' declared inside parameter list
warning: its scope is onl
On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
> On 16/07/2010 00:59, J Decker wrote:
>
>> --
>>
>> #define PointerA struct a *
>>
>> void f( PointerA );
>>
>> typedef struct a
created.
On Thu, Jul 15, 2010 at 5:21 PM, J Decker wrote:
> On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
>> On 16/07/2010 00:59, J Decker wrote:
>>
>>> --
>>>
>>> #define PointerA struct a *
>>>
>>> void f( P
On Thu, Jul 15, 2010 at 6:08 PM, Dave Korn wrote:
> On 16/07/2010 01:31, J Decker wrote:
>> Oh not so bad then, I can just add at the beginning...
>>
>> typedef struct a *NeverUsedDefinition;
>>
>> and now it's happy? And that makes good coding how?
&g
J-REIT.NETãâââââââââââââââââââââââââââ
ãâªâªãä¸åç£å£²è²·äºä¾æ¤ç´¢ç¨ã®ç¡æãã¼ã¿ãã¼ã¹ã®ãæ¡å
ãâ«â«
âââââââââââââââââââââââââââââââââ
J
Just out of curiosity - isn't this what C# does with objects? would
it perhaps be something like that in how mcs (mono) builds objects and
tracks their lifespan?
On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker wrote:
>
>> I am not sure that is easily feasible. I would believe it is impossible.
On Wed, Sep 15, 2010 at 11:15 PM, ir_idjit wrote:
>
> i've been writing bits of codes where it requires to have an array or
> "pointers to functions", so the decision of which function to execute is
> indexed... (i know, a lot of you will say "well, that's a VERY specific of a
> solution, there's
Can the severity of signed/unsigned comparisons be raised, since GCC
does not properly handle the comparisons.
Every example below is false compiled with gcc 4.5.0
int main()
{
int s = -2;
unsigned int u = 0xFFFDU;
if( s < u )
printf( "okay\n" );
> The standards did not leave this open. They define precisely what is
> supposed to happen.
>
Really? I'll have to drop this whole lobbying effort then. That
makes me sad that they didn't define it to be comparing of the numbers
where there are overlaps in signed and unsigned instead of causin
ed comparison.
>
> unsigned int x;
> int y;
> if ((int)x < y)
>
> -Rick
>
> -Original message-
>
> From: J Decker
> To: Ian Lance Taylor
> Cc: gcc@gcc.gnu.org
> Sent: Mon, Sep 27, 2010 05:51:56 GMT+00:00
> Subject: Re: signed/unsigned comparison warning leve
Posted in the Intel forums but this may be more of a GCC issue.
Please advise if I should post elsewhere.
Compiling a C module in with a large app (>2GB data) and getting
relocatable errors with GCC and
not ICC.
./classification_dpr_BB.o: In function `BB_detection_dpr':
/homedata/johnk/dpr/sr
Yes,
I replicated this on an Ubuntu 11 distro with GCC 4.6.x
On Thu, Feb 23, 2012 at 5:34 PM, Iyer, Balaji V wrote:
> Hello J. K.,
> Have you tried with a newer version of GCC? GCC 4.1 is pretty old
>
> Thanks,
>
> Balaji V. Iyer.
>
> -Original
I NEED A DRIVER FOR MY WIFE
>
> This looks fine. What is the call stack looks like? And how does the
> function calling ntdll looks like?
> I think, you should step on an "int 3". Because you simply debug the
> exception handling routine itself.
>
Hi, Kai:
I attach the stack in the following:
C:\temp\fortran>cdb gfo
Hi,
stack before and after segmentation fault is as:
..
..
ntdll!KiUserApcDispatcher+0x15:
`77ef30a5 488bcc mov rcx,rsp
0:000> p
ntdll!KiUserApcDispatcher+0x18:
`77ef30a8 b201mov dl,1
0:000> k
Child-SP RetAddr Call Site
0
Hi, Kai,
This is what you want, with -dH. If you need further information, please let me
know. Finch.
.
.
(8b8.8bc): Break instruction exception - code 8003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntdll.dll -
ntdll!DbgB
This is the beta release of binutils 2.17.50.0.6 for Linux, which is
based on binutils 2006 1020 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.6 release, the default output section LMA
(load memory address) has changed for allocatable sectio
On Tue, Oct 10, 2006 at 11:21:41AM -0500, Menezes, Evandro wrote:
> > H.J., do you have the i386 psABI in source form somewhere I could get
> > it, to make the corresponding changes?
>
> Actually, it's about an extension to the i386 psABI and it's an idea still in
> its infancy: http://sourcewar
On Sat, Nov 04, 2006 at 04:58:42PM -0800, Brooks Moses wrote:
> Daniel Jacobowitz wrote:
> >On Sat, Nov 04, 2006 at 10:57:14AM -0800, Brooks Moses wrote:
> >>I've been setting up a Debian box to do builds on, and make bootstrap on
> >>mainline is failing somewhere in the middle of Stage 1. The pr
Intel has published Core 2 Duo Optimization Reference Manual. I will
check in this patch to update wwwdocs.
H.J.
2006-11-10 H.J. Lu <[EMAIL PROTECTED]>
* readings.html: Update Intel64 and IA32 SDM website.
Index: readings.html
=
On Fri, Nov 10, 2006 at 09:36:59AM -0800, H. J. Lu wrote:
> Intel has published Core 2 Duo Optimization Reference Manual. I will
> check in this patch to update wwwdocs.
>
I checked it in. You can find Core 2 Duo Optimization Reference Manual
at
http://developer.intel.com/products/
On Fri, Nov 10, 2006 at 12:38:07PM -0800, Mike Stump wrote:
> How many hunks do we need, well, today I want 8 for 4.2 and 16 for
> mainline, each release, just 2x more. I'm assuming nice, equal sized
> hunks. For larger variations in hunk size, I'd need even more hunks.
>
> Or, so that is ju
On Sun, Nov 12, 2006 at 02:44:36PM -, Dave Korn wrote:
>
> I see this on linux but not on cygwin:
>
> make[3]: Leaving directory `/home/dk/gnu/obj'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o differs
> warning: ./cc1obj-checksum.o differs
>
Gcc 4.3 revision 118764 failed galgel in SPEC CPU 2000 with
-O2 -ffast-math on Linux/x86-64. I got
galgel_base.o2[30363]: segfault at 000b rip 000b rsp
007fb008 error 14
Gcc 4.3 revision 118723 passes SPEC CPU 2006 with -O2 -ffast-math on
Linux/x86-64. But it fail
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > Steve Kargl writes:
>
> Steve> I have not seen this failure, but that may be expected
> Steve> since SPEC CPU 2000 isn't freely available.
>
> No failure should be expected. It is a bug and a regression and
> should be
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> > >>>>> Steve Kargl writes:
> >
> > Steve> I have not seen this failure, but that may be expected
> > Steve> since SPEC
On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
> H. J. Lu wrote:
> >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
> >>> No failure should be expected. It is a bug and a
On Tue, Nov 14, 2006 at 12:03:39PM -0800, H. J. Lu wrote:
> On Tue, Nov 14, 2006 at 11:56:01AM -0800, Brooks Moses wrote:
> > H. J. Lu wrote:
> > >On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
> > >>On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edel
This is the beta release of binutils 2.17.50.0.7 for Linux, which is
based on binutils 2006 1020 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.7 release, the default output section LMA
(load memory address) has changed for allocatable sections f
On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> Currently, the way the native CPU detection code in driver-i386.c
> is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
> the correct setting for this
On Fri, Dec 01, 2006 at 06:43:46AM -0800, H. J. Lu wrote:
> On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> > Currently, the way the native CPU detection code in driver-i386.c
> > is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> > Core 2 Duo*)
FYI, I created an IA64 psABI discussion group:
http://groups-beta.google.com/group/ia64-abi
H.J.
This is the beta release of binutils 2.17.50.0.8 for Linux, which is
based on binutils 2006 1201 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.8 release, the default output section LMA
(load memory address) has changed for allocatable sections f
On Fri, Dec 01, 2006 at 03:37:22PM -0500, Andrew MacLeod wrote:
> On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
> > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wr
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
LOCKREP_PREFIX isn't fixed. Currently, gas generates
LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX
I will check in a patch:
http://sourceware.org/ml/binutils/2006-12/msg00054.html
tomorrow and change gas to generate
SEG_P
On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote:
> On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote:
>
> > On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
> > LOCKREP_PREFIX isn't fixed. Currently, gas generates
> >
> > LOC
On Wed, Dec 06, 2006 at 06:52:39PM +0100, Mikael Pettersson wrote:
>
> If hardware x86 decoders (i.e., Intel or AMD processors)
> get measurably faster with the new order, that would be
> a good reason to change it.
I was told that AMD processors had no preferences and Intel processors
preferred
Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
regressions on P4, Pentium M and Core Duo, comparing aganst
gcc 4.2 20060910. With -O2, the typical regressions look like
Gcc 4.2 Gcc 4.3
410.bwaves 9.899.14-7.58342%
41
On Fri, Dec 08, 2006 at 07:39:45PM +0100, Uros Bizjak wrote:
> H. J. Lu wrote:
>
> >Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
> >regressions on P4, Pentium M and Core Duo, comparing aganst
> >gcc 4.2 20060910. With -O2, the typical regressions lo
On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> Hey, by chance does the attached fix it?
>
Yes, it fixes 464.h264ref with the test input. I am running the real
input now.
Thanks.
H.J.
---
>
> On 12/10/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> &
On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote:
> On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> > Hey, by chance does the attached fix it?
> >
>
> Yes, it fixes 464.h264ref with the test input. I am running the real
> input now.
>
Do y
On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote:
> On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote:
> > Hey, by chance does the attached fix it?
> >
>
> Yes, it fixes 464.h264ref with the test input. I am running the real
> input now.
>
It wor
On Fri, Dec 08, 2006 at 01:02:27PM -0600, Menezes, Evandro wrote:
> HJ,
>
> I'll run the three worst offenders below and get back to y'all.
>
> The full results will take longer.
Hi Evandro,
I also saw similar issues on x86-64 with -O2 -ffast-math:
gcc-4.2 rev 116820 gcc
On Mon, Dec 11, 2006 at 11:35:27AM -0600, Menezes, Evandro wrote:
> HJ,
>
> > > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
> > > regressions on P4, Pentium M and Core Duo, comparing aganst
> > > gcc 4.2 20060910. With -O2, the typical regressions look like
> > >
> > >
i686-pc-linux-gnu
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /disk2/Downloads/gcc/gcc-4.1.1/configure
Thread model: posix
gcc version 4.1.1
Fedora Core release 5 (Bordeaux)
Kernel \r on an \m
Linux 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006 i686 i686 i386
GNU/Linux
On Wed, Jan 03, 2007 at 10:18:36AM -0800, Seongbae Park wrote:
> >In fact, by default, gcc for the i386 targets will call _mcount. gcc
> >for i386 GNU/Linux targets was changed to call mcount instead of
> >_mcount with this patch:
> >
> >Thu Mar 30 06:20:36 1995 H.J. Lu ([EMAIL PROTECTED])
> >
This is the beta release of binutils 2.17.50.0.9 for Linux, which is
based on binutils 2007 0103 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections f
Here is one implementation of ELF sharable section proposal:
http://groups-beta.google.com/group/generic-abi/browse_thread/thread/bca08f6560f61b0d
Several people have expressed interests. I post it here for comments.
I used OS specific values. If we get consensus, I can change those
values to gen
On Fri, Jan 05, 2007 at 08:53:07AM +, Christoph Hellwig wrote:
> On Thu, Jan 04, 2007 at 03:31:46PM -0800, H. J. Lu wrote:
> > Here is one implementation of ELF sharable section proposal:
> >
> > http://groups-beta.google.com/group/generic-abi/browse_thread/th
On Fri, Jan 05, 2007 at 09:27:35PM +0100, Magnus Fromreide wrote:
> On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote:
> > Magnus Fromreide writes:
> >
> > But it can't unless you use an architecture that has cmpxchgl.
> > cmpxchgl is a 486 instruction; if you compile for 386, we have to
> > g
On Sat, Jan 06, 2007 at 04:42:27PM +0100, Steven Bosscher wrote:
> Hi,
>
> We currently do not have an active maintainer for the i386 port. The
> only listed maintainer for the port is rth, and he hasn't been around
> to approve patches in a while. This situation is a bit strange for
> a port t
I am enclosing a patch to implement a new linker swicth,
--dynamic-list-data. It is -Bsymbolic for function symbols only.
I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64
and Linux/ia64. There are only a few regressions. The function calls
within the new resulting DSOs will bind
On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote:
> On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote:
> > I am enclosing a patch to implement a new linker swicth,
> > --dynamic-list-data. It is -Bsymbolic for function symbols only.
> > I tried it with C, C++
On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > I am enclosing a patch to implement a new linker swicth,
> > --dynamic-list-data. It is -Bsymbolic for function symbols only.
> > I tried it with C, C++, Java and Fortran on Linux/ia32,
On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > > I am enclosing a patch to implement a new linker swicth,
> > > >
On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > > On Tue, Jan 09, 2007 at 01:38:00PM +, Andrew Haley wrote:
> > > &
On Mon, Jan 08, 2007 at 08:23:39PM -0800, H. J. Lu wrote:
> On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote:
> > On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote:
> > > I am enclosing a patch to implement a new linker swicth,
> > > --dynamic-list-data. It
On Tue, Jan 09, 2007 at 04:42:41PM +0100, Paolo Bonzini wrote:
>
> >I am testing this patch now. It should fix the regresions when
> >libstdc++ is built with
> >
> >-Bsymbolic-functions --dynamic-list-cpp-new
I tested it on gcc 4.2 with C, C++, Java and Fortran on Linux/x86-64.
There is no regres
On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote:
> On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote:
> > H. J. Lu writes:
> > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Haley wrote:
> > > > H. J. Lu writes:
> > > > > On
With LTO, an object file may contain sections with IL, which
can be discarded when building DSO and executable. Currently we can't
mark such sections with gABI. With GNU linker, we can use a
linker script to discard such sections. But it will be more generic
to make a section to be discarded for DS
On Tue, Jan 09, 2007 at 10:09:35AM -0800, Ian Lance Taylor wrote:
>
> That is not strictly required for LTO as I see it. With LTO, the lto
> program is going to read the .o files with the IL information. It
> will then generate a new .s file to pass to the assembler. The IL
> information will n
On Tue, Jan 09, 2007 at 09:42:40AM -0800, H. J. Lu wrote:
> On Tue, Jan 09, 2007 at 06:18:19AM -0800, H. J. Lu wrote:
> > On Tue, Jan 09, 2007 at 02:01:53PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > > On Tue, Jan 09, 2007 at 01:51:00PM +, Andrew Ha
Does gcc support "delete (nothrow)"? I ran into 2 problems:
1. I had to call destructor directly since
A *p = new (std::nothrow) A;
delete (std::nothrow) p;
won't cpmpile. I had to use
A *p = new (std::nothrow) A;
...
operator delete (bb, std::nothrow);
2.
A *bb = new (std::nothrow) A [10];
On Tue, Jan 09, 2007 at 01:55:44PM -0800, H. J. Lu wrote:
> Does gcc support "delete (nothrow)"? I ran into 2 problems:
>
> 1. I had to call destructor directly since
>
> A *p = new (std::nothrow) A;
> delete (std::nothrow) p;
>
> won't cpmpile. I had t
On Tue, Jan 09, 2007 at 07:52:42AM -0800, H. J. Lu wrote:
> >
> > What about just --dynamic-list-cpp that enables the new behavior and
> > implies --dynamic-list-cpp-typeinfo (I know that it is useless in this
> > particular case, since C++ typeinfo is data, but in gen
With the new linker switches, -Bsymbolic-functions and
--dynamic-list-cpp-new, we can improve shared library
performance in gcc. This change will build libstdc++.so with
-Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it
to other libraries.
H.J.
--
--- gcc/libstdc++-v3/acinclude.m4.
On Wed, Jan 10, 2007 at 07:19:17AM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > With the new linker switches, -Bsymbolic-functions and
> > --dynamic-list-cpp-new, we can improve shared library
> > performance in gcc.
On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:
> >>>>> "H.J." == H J Lu <[EMAIL PROTECTED]> writes:
>
> H.J.> With the new linker switches, -Bsymbolic-functions and
> H.J.> --dynamic-list-cpp-new, we can improve shared library
&
Both AMD and Intel like to have BID as a configure time option
for DFP. Intel is planning to contribute a complete BID runtime
library, which can be used by executables generate by gcc.
As the first step, we'd like to contribute a BID<->DPD library so that
BID can be used with libdecnumber by exec
On Wed, Jan 10, 2007 at 02:10:58PM -0800, Janis Johnson wrote:
> On Wed, Jan 10, 2007 at 11:40:46AM -0800, H. J. Lu wrote:
> > Both AMD and Intel like to have BID as a configure time option
> > for DFP. Intel is planning to contribute a complete BID runtime
> > library,
On Thu, Jan 11, 2007 at 09:03:42AM +0100, Paolo Bonzini wrote:
> H. J. Lu wrote:
> >On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:
> >>>>>>>"H.J." == H J Lu <[EMAIL PROTECTED]> writes:
> >>H.J.> With the new linker switch
On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote:
>
> >config/
> >
> >2007-01-10 H.J. Lu <[EMAIL PROTECTED]>
> >
> > * ld-symbolic.m4: New.
>
> Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or
> ACX_PROG_LD_GNU_SYMBOLIC.
>
> >libgfortran/
> >
> >2007-01-10 H.J. Lu <[EM
On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote:
>
> >libjava will use -Bsymbolic on Linux, which is more aggresive than
> >-Bsymbol-functions. It will bind global data references locally in
> >additon to global function references. My patch will keep -Bsymbolic
> >for libjava if it
On Fri, Jan 12, 2007 at 12:13:11PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote:
> > >
> > > >config/
> > > >
> > > >2007-01-10 H.J. Lu <[EMAIL P
On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote:
> On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
> >Menezes, Evandro wrote:
> >> Though not as pronounced, definitely significant.
> >>
> >
> >Using binary search I've detected that 30% performance regression of
> >cpu2006/43
On Fri, Jan 12, 2007 at 09:30:27PM +0300, Grigory Zagorodnev wrote:
> Hi!
> GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and
> higher optimization level at x86_64-redhat-linux.
>
> reload1.c: In function 'reload':
> reload1.c:449: error: address taken, but ADDRESSABLE bit not
On Fri, Jan 12, 2007 at 06:38:56AM -0800, H. J. Lu wrote:
> On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote:
> >
> > >libjava will use -Bsymbolic on Linux, which is more aggresive than
> > >-Bsymbol-functions. It will bind global data references locall
On Fri, Jan 12, 2007 at 02:06:48PM -0500, Daniel Berlin wrote:
> On 1/12/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote:
> >> On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]>
> >wrote:
> >> &
process_pending_assemble_externals will be called at the end,
which calls assemble_external_real on all external symbols.
Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't
assemble_external_real handle it?
H.J.
On Mon, Jan 15, 2007 at 09:47:34PM +0100, Toon Moene wrote:
> Grigory,
>
> Calculix is a combined C/Fortran program. Did you try to compile the
> Fortran parts with --param max-aliased-vops= default 50> ?
>
> Diego up'd the default from 10 to 50 because one (or more) of the
> (Fortran) Polyhed
On Mon, Jan 15, 2007 at 07:35:22PM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > process_pending_assemble_externals will be called at the end,
> > which calls assemble_external_real on all external symbols.
> > Do we sti
On Mon, Jan 15, 2007 at 08:23:05PM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > > Look at, e.g., mcore_external_libcall in mcore.c, and at
> > > ASM_OUTPUT_EXTERNAL_LIBCALL in i386/cygming.h. You need to handle
> >
On Mon, Jan 15, 2007 at 08:33:28PM -0800, H. J. Lu wrote:
> > > TARGET_ASM_EXTERNAL_LIBCALL when there is ASM_OUTPUT_EXTERNAL?
> >
> > In the larger scheme of things, we don't.
> >
> I will open a bug report for enhancement.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30480
H.J.
Hi all,
I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.
I would be curious regarding this decision. I would think the
development of a C parser would be an almost unsurmountable task and
not very logic given the parser generators i
Hello all,
After reading the internals of gcc wikibooks some questions come up.
So, gcc has front end for C, C++, java, fortran, etc..
All these languages have a frontend which parse into AST and then
GIMPLE which is converted to RTX and then assembly. Now, my guess is
that GIMPLE is the _common_
Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire
Functions" by Jason Merrill it says there's a flag -fdump-tree-simple
to get the gimple tree (page 3). However, this doesn't exist in gcc
4.1:
$ gcc -fdump-tree-simple bigger3.c
cc1: error: unrecognized command line option "-fdu
Argh, forget it!
Found the answer in:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Debugging-Options.html#Debugging-Options
Regards,
Paulo Matos
On 1/18/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire
Function
On 18 Jan 2007 07:42:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> After reading the internals of gcc wikibooks some questions come up.
> So, gcc has front end for C, C++, java, fortran, etc..
> All these
On Tue, Jan 16, 2007 at 07:05:34PM +0300, Grigory Zagorodnev wrote:
> Toon Moene wrote:
> >Calculix is a combined C/Fortran program. Did you try to compile the
> >Fortran parts with --param max-aliased-vops= >default 50> ?
> Right, calculix is a combined program. Gprof says the regression is in
1 - 100 of 820 matches
Mail list logo
