GCC plugins problem
Hello, I have some questions about developing my own compiler plugin. I tried to develop it using riscv-gnu-toolchain(https://github.com/riscv/riscv-gnu-toolchain), but it couldn't find following header files. # include #if defined (ENABLE_PLUGIN) && defined (HAVE_DLFCN_H) /* If plugin support is enabled, we could use libdl. */ #include #endif /* Do not introduce a gmp.h dependency on the build system. */ #ifndef GENERATOR_FILE #include #endif #ifdef HAVE_SYS_MMAN_H # include #endif How to resolve this problem? I would be very grateful indeed for any help you could give me. Thank you so much! Sincerely, Yu
array type has incomplete element type
Hi,
What's wrong with this ? It is ok in gcc 3 not not ok with gcc4:
#define SERVICE_TYPE(type, val, state) SERVICE_##type = val,
typedef enum service_e {
SERVICE_TYPE(NONE, 0, false)
SERVICE_TYPE(FTP,1, true)
SERVICE_TYPE_MAX
} service_type_t;
Thanks
dave
Calling convention for "Routines for floating point emulation"
Hi, I'd like to ask what should be the calling convention/ABI for these routines on platforms with hardware floating point support (but somehow still want to generate a libcall for whatever reasons). In particular, it seems that on all the platforms with a arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h, debian armhf, fedora armv7hl) the __powidf2 function (and possibly many others) are compiled with the AAPCS VFP calling convention, which is also how it is used by gcc. However, LLVM dev (CC'd) claims that these routines are meant to be always using soft floating point calling convention even on platforms using hard floating point ABI. A breif google search doesn't show document supporting either so what exactly should be used? Is it documented anywhere or what's the default rule to decide the calling conventions for these functions? In either case I think it's be nice if the document is a little more explicit about this. Yichao Yu
Re: Calling convention for "Routines for floating point emulation"
On Wed, Sep 28, 2016 at 5:23 PM, Yichao Yu wrote: > Hi, > > I'd like to ask what should be the calling convention/ABI for these > routines on platforms with hardware floating point support (but > somehow still want to generate a libcall for whatever reasons). > > In particular, it seems that on all the platforms with a > arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h, > debian armhf, fedora armv7hl) the __powidf2 function (and possibly > many others) are compiled with the AAPCS VFP calling convention, which > is also how it is used by gcc. However, LLVM dev (CC'd) claims that > these routines are meant to be always using soft floating point > calling convention even on platforms using hard floating point ABI. > > A breif google search doesn't show document supporting either so what > exactly should be used? Is it documented anywhere or what's the > default rule to decide the calling conventions for these functions? In > either case I think it's be nice if the document is a little more > explicit about this. And see https://llvm.org/bugs/show_bug.cgi?id=30543 for some context. > > Yichao Yu
Re: Calling convention for "Routines for floating point emulation"
On Wed, Sep 28, 2016 at 7:39 PM, Joseph Myers wrote: > On Wed, 28 Sep 2016, Yichao Yu wrote: > >> In particular, it seems that on all the platforms with a >> arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h, >> debian armhf, fedora armv7hl) the __powidf2 function (and possibly >> many others) are compiled with the AAPCS VFP calling convention, which >> is also how it is used by gcc. However, LLVM dev (CC'd) claims that >> these routines are meant to be always using soft floating point >> calling convention even on platforms using hard floating point ABI. > > The RTABI functions should use the base AAPCS calling conventions. That > was something I dealt with when working on the implementation of the VFP > ABI variant <https://gcc.gnu.org/ml/gcc-patches/2009-05/msg00591.html>. > > Except where an external ABI defines things like that, the normal > expectation for libgcc functions is that they have the same ABI as for an > ordinary C function with the same prototype. That is, since libgcc.texi > gives a prototype for __powidf2 without saying anything special about its > ABI, and since it is not a function defined in RTABI, it can be taken to I guess other ppl on the list probably know this but what's the list of function in RTABI? Thanks. > use the VFP ABI when compiling for that ABI. > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: Calling convention for "Routines for floating point emulation"
On Wed, Sep 28, 2016 at 7:45 PM, Yichao Yu wrote: > On Wed, Sep 28, 2016 at 7:39 PM, Joseph Myers wrote: >> On Wed, 28 Sep 2016, Yichao Yu wrote: >> >>> In particular, it seems that on all the platforms with a >>> arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h, >>> debian armhf, fedora armv7hl) the __powidf2 function (and possibly >>> many others) are compiled with the AAPCS VFP calling convention, which >>> is also how it is used by gcc. However, LLVM dev (CC'd) claims that >>> these routines are meant to be always using soft floating point >>> calling convention even on platforms using hard floating point ABI. >> >> The RTABI functions should use the base AAPCS calling conventions. That >> was something I dealt with when working on the implementation of the VFP >> ABI variant <https://gcc.gnu.org/ml/gcc-patches/2009-05/msg00591.html>. >> >> Except where an external ABI defines things like that, the normal >> expectation for libgcc functions is that they have the same ABI as for an >> ordinary C function with the same prototype. That is, since libgcc.texi >> gives a prototype for __powidf2 without saying anything special about its >> ABI, and since it is not a function defined in RTABI, it can be taken to > > I guess other ppl on the list probably know this but what's the list > of function in RTABI? Is it http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf ? > > Thanks. > >> use the VFP ABI when compiling for that ABI. >> >> -- >> Joseph S. Myers >> jos...@codesourcery.com
Re: Calling convention for "Routines for floating point emulation"
On Wed, Sep 28, 2016 at 8:07 PM, Joseph Myers wrote: > On Wed, 28 Sep 2016, Yichao Yu wrote: > >> >> Except where an external ABI defines things like that, the normal >> >> expectation for libgcc functions is that they have the same ABI as for an >> >> ordinary C function with the same prototype. That is, since libgcc.texi >> >> gives a prototype for __powidf2 without saying anything special about its >> >> ABI, and since it is not a function defined in RTABI, it can be taken to >> > >> > I guess other ppl on the list probably know this but what's the list >> > of function in RTABI? >> >> Is it >> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf >> ? > > Yes, that's the right document. Specifically, section 4.1.2, which > defines the floating-point functions that always use the base ABI. I've just started reading 4.1.1 =) Got it. Thanks very much for the fast answer! Yichao Yu > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: Calling convention for "Routines for floating point emulation"
Ref https://llvm.org/bugs/show_bug.cgi?id=30543#c10 > > That should not be the case, for libgcc functions that are not in RTABI. > > They should use the ABI of the multilib they are compiled for, which may > > be base ABI or VFP ABI depending on the options used for compiling that > > multilib. > > Interesting, I wonder how multiple people came to the same conclusion (that > they use the base ABI) given the behavior of libgcc. (See link above) I've confirmed that the first version of gcc that supports vfp abi (4.5.0) and also the 4.6.3 shipped with debian 7 both use the vfp ABI for these functions. > > Functions such as __powidf2 and __mulsc3 are not part of the software > > floating-point library. They use the same ABI as any other C functions > > with their type. > > The fact that they are listed under "4.2.4 Other floating-point functions" of > the "Routines for floating point emulation" makes this rather confusing. > > Is there some other resource other than libgcc.texi that can be used to > determine the calling convention requirements? So I assume the convention is that > Except where an external ABI defines things like that, the normal > expectation for libgcc functions is that they have the same ABI as for an > ordinary C function with the same prototype. That is, since libgcc.texi > gives a prototype for __powidf2 without saying anything special about its > ABI, and since it is not a function defined in RTABI, it can be taken to > use the VFP ABI when compiling for that ABI. ? This seems to be at least self consistent. However, since it is apparently confusing for people who knows that some functions should use the base ABI, maybe it'll be helpful for future readers to explicitly state this in the doc?
Re: intrinsic function for the assembly x86 xchg command
On Fri, Apr 7, 2017 at 2:08 PM, fab10 <0xfa...@gmail.com> wrote: > It would be usefull to develop in gcc an intrinsic function for the assembly > x86 instruction xchg to implement a low level mutex. I believe that's what atomic_exchange is lowered to on x86?
GCC bug when using typeof
Hi,
I tried to compile the following program, but I got the following
error. Is it a bug of GCC? Has it been fixed in a newer version GCC?
g++ -Wall -W -pedantic -g -c -o main-g.o main.cc
main.cc:57: internal compiler error: in write_type, at cp/mangle.c:1651
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccEcnj4W.out file, please attach
this to your bugreport.
Currently, I'm using g++ of the following version.
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks,
Peng
#include
namespace A {
template
class X {
public:
X() { }
X(T t) : _t(t) { }
const T &the_t() const { return _t; }
private:
T _t;
};
template
struct multiply_traits;
template
struct multiply_traits, T2> {
typedef X result_type;
};
template
typename multiply_traits, T2>::result_type operator*(const
X &x, const T2 &t) {
return X(x.the_t() * t);
}
}
namespace B {
template
class Y {
public:
Y(T t) : _t(t) { }
const T &the_t() const { return _t; }
private:
T _t;
};
template
Y
operator*(const Y &y, const T2 &t) {
return Y(y.the_t() * t);
}
}
int main () {
A::X x(2);
B::Y > y(x);
std::cout << (x * 3).the_t() << std::endl;
std::cout << (y * 5).the_t().the_t() << std::endl;
}
Re: GCC bug when using typeof
On Mon, Oct 20, 2008 at 9:09 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Mon, Oct 20, 2008 at 7:04 PM, Peng Yu <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I tried to compile the following program, but I got the following >> error. Is it a bug of GCC? Has it been fixed in a newer version GCC? >> > > It is a bug in GCC but in later versions 4.3.0 and above, we get a > sorry message: > t.cc: In instantiation of 'B::Y<__typeof__ ((T1() * T2()))> > B::operator*(const B::Y&, const T2&) [with T1 = A::X, T2 = > int]': > t.cc:54: instantiated from here > t.cc:46: sorry, unimplemented: mangling typeof, use decltype instead > > Replacing typeof with __decltype (or decltype in c++0x/g++0x modes) > works in 4.3.0 and above. Hi, Could you please help explain what the difference between typeof and decltype are? What are c++0x/g++0x modes? Thanks, Peng
Re: GCC bug when using typeof
On Mon, Oct 20, 2008 at 9:09 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Mon, Oct 20, 2008 at 7:04 PM, Peng Yu <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I tried to compile the following program, but I got the following >> error. Is it a bug of GCC? Has it been fixed in a newer version GCC? >> > > It is a bug in GCC but in later versions 4.3.0 and above, we get a > sorry message: > t.cc: In instantiation of 'B::Y<__typeof__ ((T1() * T2()))> > B::operator*(const B::Y&, const T2&) [with T1 = A::X, T2 = > int]': > t.cc:54: instantiated from here > t.cc:46: sorry, unimplemented: mangling typeof, use decltype instead > > Replacing typeof with __decltype (or decltype in c++0x/g++0x modes) > works in 4.3.0 and above. Hi, Somebody replace __decltype with typeof and try to compile, he got the following error (with 4.3.0). Do you know why? main.cc:54: sorry, unimplemented: zero-operand casts cannot be mangled due to a defect in the C++ ABI main.cc:54: sorry, unimplemented: zero-operand casts cannot be mangled due to a defect in the C++ ABI Thanks, Peng
How to find out all the calling instance of a class member function?
Hi, Suppose I have a class B in namespace A, it has several overloaded member function doit. I'm wondering how to find all the lines where there is a statement that calls one particular overloaded doit member function? Is it possible to do so from g++ command line? Or I have to modify g++ to make it be able to do so? Thanks, Peng
Symbolic range analysis
Hi All, Does it perform symbolic range analysis or array section analysis in GCC-4.6 ? Thanks, Hongtao Yu Purdue University
Re: Question on building a variably modified type at parameter scope
I found this is a bug in my front end because I used the same type for the
parameters in different functions, so the references to the parameter in
the structure messed up.
The thing I want to implement is creating something like this pointers in
C++ of structure type whose variably modified fields depend on other
fields.
So the problem is the reference of this parameter differs from function to
function, and therefore, in the most straightforward solution, I have to
deep copy the whole structure for each function, so it can correctly refer
to the parameter.
However, I want to avoid the deep copy.
So, first, I guess it's not safe to share the same PARM_DECL among
different functions, is it true?
If true, is it possible to refer to the first parameter of whatever
functions in the same way, so I can use the same type built upon that
reference?
And if so, at which stage, I can build such a reference?
Thanks,
Chenkan
>> I believe this should be possible. I believe that Ada has constructs
>> like this. I think you will need to use a PLACEHOLDER_EXPR to get the
>> right thing to happen.
>
> In Ada, we indeed have the mechanism in its full generality, i.e.
>
> struct S { int a; int b[a]; };
>
> will work anywhere, and for this the PLACEHOLDER_EXPR machinery is needed.
>
> But it seems to me that the case at stake is more specific:
>
> void f (struct S { int a; int b[s.a]; } s) { }
>
> because struct S is defined at parameter scope and s.a is a known object,
> so
> perhaps the use of the (heavy) PLACEHOLDER_EXPR machinery could be
> avoided.
>
> --
> Eric Botcazou
>
Generating data at link time
Dear all, I'm trying to generate a (very simple) special data section at link-time. It seems that LTO is too heavy, though I'm also not quite familiar with it. I think that what I first need is a new output format which wraps the standard ELF, so can anyone help to point out where I can get started? Also if I want to generate data, is there any tool lighter than and compatible with GCC can be used to deal with the platform dependent stuff?
Question about local register variable
Hi,
I am wondering if the following piece of code is supposed to be valid.
void* reg_v13() {
register void* r __asm__ ("r13");
return r;
}
I did test with gcc on powerpc64, and confirmed that the function
really returns r13 (thread pointer) value.
However, LLVM issues a warning complaining that variable r is not
initialized. The argument is that per
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Explicit-Reg-Vars.html#Explicit-Reg-Vars:
"Local register variables in specific registers do not reserve the
registers, except at the point where they are used as input or output
operands in an asm statement and the asm statement itself is not
deleted."
It seems to mean that register variable does not have connection with
the register if the variable is not used in asm statement.
If the understanding correct?
I could not find an example on official gcc document to support that
the example code is valid, although gcc indeed treats r as alias of
r13.
Thanks,
Jing
RE: Joseph Myers joins GCC Steering Committee
Welcome Joseph. Wish everyone Happy Holidays and a wonderful 2014! Charlie -Original Message- From: gcc-announce-ow...@gcc.gnu.org [mailto:gcc-announce-ow...@gcc.gnu.org] On Behalf Of David Edelsohn Sent: Monday, December 09, 2013 3:28 AM To: gcc@gcc.gnu.org; gcc-annou...@gcc.gnu.org Subject: Joseph Myers joins GCC Steering Committee On behalf of the entire GCC Steering Committee, it gives me great pleasure to welcome Joseph Myers as the newest member of the GCC Steering Committee. We hope that everyone will join us to wish him all of the support and wisdom for this new challenge. We are grateful for the continued excellent guidance of Jakub Jelinek, Richard Biener and Joseph Myers as co-Release Managers. And we thank Mark Mitchell for his years of dedication, guidance, leadership and service, and wish him great success with his future endeavors. We wish everyone Happy Holidays and a prosperous new year! The GCC Steering Commitee David Edelsohn Kaveh Ghazi Jeffrey Law Marc Lehmann Jason Merrill David Miller Toon Moene Joseph Myers Gerald Pfeifer Joel Sherrill Jim Wilson
About new project
Hi All, How can I set up a new project under GCC and make it open-sourced? Thanks! Cheers, Hongtao
Re: About new project
On 1/27/2013 5:04 PM, Gerald Pfeifer wrote: On Sat, 26 Jan 2013, Hongtao Yu wrote: How can I set up a new project under GCC and make it open-sourced? Thanks! That depends on what you mean by "under GCC", I'd say. If you have improvements for GCC, submitting those as patches against GCC will be best, cf. http://gcc.gnu.org/contribute.html . If you want to work on an independent project, you can just go ahead and use one of those services like github, SourceForge etc. Actually, we have designed and implement a tentative demand-driven flow- and context-sensitive pointer analysis in GCC 4.7. This pointer analysis is used for pairwise data dependence checking for vectorization. Currently, it does not serve for optimizations directly, although it may do in the future. Do you think which way is best for releasing our code, to open a branch inside GCC or to release a plugin for GCC? Thanks! Hongtao (Note that the GNU project talks about free software, cf. https://www.gnu.org/philosophy/free-software-for-freedom.html ) Gerald
Question on building a variably modified type at parameter scope
HI,
I'm a newbie and I'm trying to modify the front end to extend C.
I know the following code can be accepted,
void f (struct S { int a; } s, int a[][s.a]) { } .
I'm wondering whether it is possible to build a structure which has a
variably modified array whose size depends on an other field in that
structure at parameter scopes,
i.e, something like this,
void f (struct S { int a; int b[s.a]; } s) { } .
This won't be compiled as s is not declared when build the struct S, but
by modifying the front end code, I can mimic this directly. However, the
assertion,
gcc_assert (SA.partition_to_pseudo[i]);
in the function gimple_expend_cfg in cfgexpand.c fails, and I've no idea
why.
I'm using 4.6.3.
Thanks,
Chenkan
[PATCH] Fix bug on soft emulation of float point in gcc/longlong.c
There are 2 bugs existing in __udiv_qrnnd_c:
1. remainder could not be counted correctly
__r1 and __r0 are not adding enough, so I use do..while to replace former if
2. the case of overflow of __m are not considered
so I add a couple of lines to handle it
I found the bugs from Linux kernel,
for PowerPC math-emu use __udiv_qrnnd_c to emulate float div.
I sent the patch to the maintainers of kernel, but they replied to me that
this code came from gcc and should better keep coincident.
So I think I should send patch to here.
I don't know how to trigger __udiv_qrnnd_c in gcc.
but if the argument of __udiv_qrnnd_c are like
0x07f8 0x07f8 0x00210fff 0xc000 0x07f8,
the bug will be reproduced.
Also, you can try the program below, I have test it on Linux kernel math-emu
but haven't test on gcc.
---
#include
union fu {
unsigned int u;
float f;
};
union fu fdiv(union fu a, union fu b, union fu expected)
{
union fu z;
z.f = a.f / b.f;
printf("fdiv %08x / %08x = %08x expected %08x %s\n",
a.u, b.u, z.u, expected.u,
(z.u == expected.u) ? "(PASS)" : "(FAIL)");
printf(" %e / %e = %e\n", a.f, b.f, z.f);
}
int main()
{
union fu fa,fb,fe;
fa.u = 0xc0843fff;
fb.u = 0x80ff;
fe.u = 0x7f044000;
fdiv(fa,fb,fe);
}
---
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
gcc/longlong.h | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/gcc/longlong.h b/gcc/longlong.h
index 6c24564..256399b 100644
--- a/gcc/longlong.h
+++ b/gcc/longlong.h
@@ -1368,12 +1368,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q1 = (n1) / __d1;
\
__m = (UWtype) __q1 * __d0;
\
__r1 = __r1 * __ll_B | __ll_highpart (n0); \
+if (__d0 && __q1 > __m / __d0) \
+ do {\
+ __q1--, __r1 += (d);\
+ } while (__r1 >= (d)); \
if (__r1 < __m)\
{
\
- __q1--, __r1 += (d);\
- if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1 */\
- if (__r1 < __m) \
+ do {\
__q1--, __r1 += (d);\
+ } while (__r1 >= (d) && __r1 < __m);\
}
\
__r1 -= __m; \
\
@@ -1381,12 +1384,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q0 = __r1 / __d1;
\
__m = (UWtype) __q0 * __d0;
\
__r0 = __r0 * __ll_B | __ll_lowpart (n0); \
+if (__d0 && __q0 > __m / __d0) \
+ do {\
+ __q0--, __r0 += (d);\
+ } while (__r0 >= (d)); \
if (__r0 < __m)\
{
\
- __q0--, __r0 += (d);\
- if (__r0 >= (d))\
- if (__r0 < __m) \
+ do {\
__q0--, __r0 += (d);\
+ } while (__r0 >= (d) && __r0 < __m);\
}
\
__r0 -= __m; \
\
--
1.5.2
[PATCH] Fix bug on soft emulation of float point in gcc/longlong.c
There are 2 bugs existing in __udiv_qrnnd_c:
1. remainder could not be counted correctly
__r1 and __r0 are not adding enough, so I use do..while to replace
former if
2. the case of overflow of __m are not considered
so I add a couple of lines to handle it
I found the bugs from Linux kernel,
for PowerPC math-emu use __udiv_qrnnd_c to emulate float div.
I sent the patch to the maintainers of kernel, but they replied to me
that
this code came from gcc and should better keep coincident.
So I think I should send patch to here.
I don't know how to trigger __udiv_qrnnd_c in gcc.
but if the argument of __udiv_qrnnd_c are like
0x07f8 0x07f8 0x00210fff 0xc000 0x07f8,
the bug will be reproduced.
Also, you can try the program below, I have test it on Linux kernel
math-emu but haven't test on gcc.
---
#include
union fu {
unsigned int u;
float f;
};
union fu fdiv(union fu a, union fu b, union fu expected)
{
union fu z;
z.f = a.f / b.f;
printf("fdiv %08x / %08x = %08x expected %08x %s\n",
a.u, b.u, z.u, expected.u,
(z.u == expected.u) ? "(PASS)" : "(FAIL)");
printf(" %e / %e = %e\n", a.f, b.f, z.f);
}
int main()
{
union fu fa,fb,fe;
fa.u = 0xc0843fff;
fb.u = 0x80ff;
fe.u = 0x7f044000;
fdiv(fa,fb,fe);
}
--
---
gcc/longlong.h | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/gcc/longlong.h b/gcc/longlong.h
index 6c24564..256399b 100644
--- a/gcc/longlong.h
+++ b/gcc/longlong.h
@@ -1368,12 +1368,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q1 = (n1) / __d1;
\
__m = (UWtype) __q1 * __d0;
\
__r1 = __r1 * __ll_B | __ll_highpart (n0);
\
+if (__d0 && __q1 > __m / __d0)
\
+ do {
\
+ __q1--, __r1 += (d);
\
+ } while (__r1 >= (d));
\
if (__r1 < __m)
\
{
\
- __q1--, __r1 += (d);
\
- if (__r1 >= (d)) /* i.e. we didn't get carry when adding to __r1
*/\
- if (__r1 < __m)
\
+ do {
\
__q1--, __r1 += (d);
\
+ } while (__r1 >= (d) && __r1 < __m);
\
}
\
__r1 -= __m;
\
\
@@ -1381,12 +1384,15 @@ UDItype __umulsidi3 (USItype, USItype);
__q0 = __r1 / __d1;
\
__m = (UWtype) __q0 * __d0;
\
__r0 = __r0 * __ll_B | __ll_lowpart (n0);
\
+if (__d0 && __q0 > __m / __d0)
\
+ do {
\
+ __q0--, __r0 += (d);
\
+ } while (__r0 >= (d));
\
if (__r0 < __m)
\
{
\
- __q0--, __r0 += (d);
\
- if (__r0 >= (d))
\
- if (__r0 < __m)
\
+ do {
\
__q0--, __r0 += (d);
\
+ } while (__r0 >= (d) && __r0 < __m);
\
}
\
__r0 -= __m;
\
\
--
RE: [PATCH] Fix bug on soft emulation of float point in gcc/longlong.c
Hi Ian, Thanks a lot for your detailed explanation. > -Original Message- > From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2008 1:45 PM > To: Liu Yu > Cc: gcc@gcc.gnu.org > Subject: Re: [PATCH] Fix bug on soft emulation of float point > in gcc/longlong.c > > Liu Yu <[EMAIL PROTECTED]> writes: > > > There are 2 bugs existing in __udiv_qrnnd_c: > > > > 1. remainder could not be counted correctly > > __r1 and __r0 are not adding enough, so I use do..while to replace > > former if > > > > 2. the case of overflow of __m are not considered so I add > a couple of > > lines to handle it > > > > I found the bugs from Linux kernel, > > for PowerPC math-emu use __udiv_qrnnd_c to emulate float div. > > Is the kernel code testing UDIV_NEEDS_NORMALIZATION and > implementing the normalization required before calling __udiv_qrnnd_c? > > > > I don't know how to trigger __udiv_qrnnd_c in gcc. > > gcc will use __udiv_qrnnd_c in -lgcc for division and modulos > of 64-bit values on processors which can't do that directly > and for which there is no alternate implementation in longlong.h. > > > > but if the argument of __udiv_qrnnd_c are like > > 0x07f8 0x07f8 0x00210fff 0xc000 0x07f8, the > bug will > > be reproduced. > > Those arguments to __udiv_qrnnd_c are not valid. For correct > operation, the most significant bit of the last argument is > required to be 1. UDIV_NEEDS_NORMALIZATION signals this > fact. In gcc the required normalization is implemented > before calling __udiv_qrnnd_c, in __udivmoddi4 in libgcc2.c. > > This normalization approach is taken, rather than introducing > while loops as you suggest, because the while loops can run > for quite a long time on small numbers. > > Ian >
Why g++ does not emit any information for a local variable in a template class member function?
Hi,
I have the following code. I try to print the variable temp in the
constructor of A. But gdb can not do that. The error message is shown
blow the C++ code.
According to the people from gdb mailing list, it is because that the
compiler (g++) does not generate information for such variable in the
debugging mode. Is it a bug of g++. BTW, I'm using g++ of the
following version
$ g++ --version
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks,
Peng
template
class A {
public:
A(int a) {
T temp = a + 1;
_a = temp + 1;
}
private:
T _a;
};
int main() {
A a(1);
}
$ gdb main
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".
(gdb) start
Breakpoint 1 at 0x400510: file main.cc, line 13.
main () at main.cc:13
13A a(1);
(gdb) s
A (this=0x7fff250d7080, a=1) at main.cc:5
5 T temp = a + 1;
(gdb) n
6 _a = temp + 1;
(gdb) p temp
No symbol "temp" in current context.
(gdb)
POSIX in g++
Hi, There is an options -ansi to make g++ ANSI compatible. I'm wondering if there is an option to make g++ POSIX compatible. Or g++ is already POSIX compatible without an option? Thanks, Peng
Re: POSIX in g++
On Tue, Jul 15, 2008 at 5:57 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Peng Yu" <[EMAIL PROTECTED]> writes: > >> There is an options -ansi to make g++ ANSI compatible. I'm wondering >> if there is an option to make g++ POSIX compatible. Or g++ is already >> POSIX compatible without an option? > > POSIX itself specifies features macros which you may define to compile > your source code in a strict POSIX environment. These are > _POSIX_SOURCE and _POSIX_C_SOURCE. These affect the header files > rather than the libraries. To get a strict POSIX compiler, use those > in conjunction with -ansi or -std. > > Ian >
Re: POSIX in g++
On Tue, Jul 15, 2008 at 5:57 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Peng Yu" <[EMAIL PROTECTED]> writes: > >> There is an options -ansi to make g++ ANSI compatible. I'm wondering >> if there is an option to make g++ POSIX compatible. Or g++ is already >> POSIX compatible without an option? > > POSIX itself specifies features macros which you may define to compile > your source code in a strict POSIX environment. These are > _POSIX_SOURCE and _POSIX_C_SOURCE. These affect the header files > rather than the libraries. To get a strict POSIX compiler, use those > in conjunction with -ansi or -std. Hi Ian, Isn't ANSI C++ a subset of POSIX C++. Why do I need to specify _POSIX_SOURCE, _POSIX_C_SOURCE and -ansi? Would you please let me know what is the difference between the option -ansi and -std? Thanks, Peng
Re: no symbol in current context problem when debug the program in gdb
On Mon, Sep 15, 2008 at 2:54 PM, Peng Yu <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have the following program. When I step in to test's constructor, I
> would be able to print the variable three. It says
> (gdb) n
> 7 T three = 3;
> (gdb) n
> 8 std::cout << three << std::endl;
> (gdb) p three
> No symbol "three" in current context.
>
> According to gdb mailing list, this is a bug in GCC. I'm wondering if
> this issue has been resolved in the later versions of GCC.
>
> Thanks,
> Peng
>
> #include
>
> template
> class test {
> public:
> test(const T &a) : _a(a) {
> T three = 3;
> std::cout << three << std::endl;
> }
> private:
> T _a;
> };
>
> int main() {
> test p(10);
> }
Can somebody take a look at this issue? As installing a new compiler
takes a lot of effort, I'd like to know if this has been solved in the
newer version of gcc. If this has not been solved in the newer version
of gcc, can somebody put this thing in the schedule?
Thanks,
Peng
Problem with commas in macro parameters
Hello!
That's probably an old problem, but I haven't found any notion of
it in GCC docs. So...
I need to have a macro which takes ONE argument, and either
ignores it or outputs a "=arg":
#ifdef __SOMEFILE_C
#define D
#define V(value) = value
#else
#define D extern
#define V(value)
#endif /* __SOMEFILE_C */
(The file itself is somefile.h, and it must either define variables if
included from somefile.c, or simply declare the same variables, when
included from other source files.)
This works fine, until I try to pass it some complex value:
D int some_array[2] V({4,5})
causes an error stating that I'm trying to pass two parameters when only
one is expected.
This looks like C preprocessor is slightly inadequate... What I'm
passing is a SIGNLE valid C expression, but, due to intentionally-ignorant
nature of CPP, curly braces aren't recognized and the expression is
treated as TWO separate arguments...
I've tried the "usual" trick -- adding extra braces:
D int some_array[2] V(({4,5}))
but that doesn't work either --
error: braced-group within expression allowed only inside a function
(this error is issued by both gcc-2.95 and gcc-3.4.4; haven't checked
gcc-4 yet).
Sure, I can "#define COMMA ," and write "V({4 COMMA 5})", but
that's ugly and leads to other undesired consequences.
The question is: the construct I'm trying to use is quite
reasonable -- is there any "good" solution for this problem?
Thanks in advance!
_
Dmitry Yu. Bolkhovityanov
The Budker Institute of Nuclear Physics
Novosibirsk, Russia
"Uninitialized array" warnings by c++ with -O2
Hello!
I have a code snippet (actually it is a part of larger project):
#include
#define UDP_PROTO_NUMBER 17
uint32_t calc_16bit_checksum_part(uint8_t* buf, int len, uint32_t ret) {
uint16_t *ptr = reinterpret_cast(buf);
int i;
for( i = 0; i < (len / 2); ++i) {
ret = ret + ptr[i];
}
if ( len%2) {
buf[len] = 0;
ret += ptr[len/2];
}
return ret;
}
uint32_t calc_ch_udp_pseudo(uint32_t src, uint32_t dst, uint16_t len) {
struct udp_pseudo {
uint32_t src;
uint32_t dst;
uint8_t z;
uint8_t proto;
uint16_t len;
};
uint8_t tbuf[sizeof(udp_pseudo)];
udp_pseudo* tmp=reinterpret_cast(tbuf);
tmp->src = src;
tmp->dst = dst;
tmp->z = 0;
tmp->proto = UDP_PROTO_NUMBER;
tmp->len = len;
return calc_16bit_checksum_part(tbuf, sizeof(tbuf), 0);
}
int main() {
return calc_ch_udp_pseudo(0x01020304, 0x12131415, 320);
}
When I try to compile it with -O2 and higher I got the following
#c++ -DHAVE_CONFIG_H -I. -I.././include -g -O3 -Wall -I../include/
-o snippet snippet.cc
snippet.cc: In function ‘uint32_t calc_ch_udp_pseudo(uint32_t, uint32_t,
uint16_t)’:
snippet.cc:10:34: warning: ‘tbuf’ is used uninitialized in this function
[-Wuninitialized]
ret = ret + ptr[i];
~^
snippet.cc:10:34: warning: ‘*((void*)& tbuf +2)’ is used uninitialized
in this function [-Wuninitialized]
snippet.cc:10:34: warning: ‘*((void*)& tbuf +4)’ is used uninitialized
in this function [-Wuninitialized]
snippet.cc:10:34: warning: ‘*((void*)& tbuf +6)’ is used uninitialized
in this function [-Wuninitialized]
snippet.cc: In function ‘int main()’:
snippet.cc:10:34: warning: ‘tbuf’ is used uninitialized in this function
[-Wuninitialized]
ret = ret + ptr[i];
~^
snippet.cc:10:34: warning: ‘*((void*)& tbuf +2)’ is used uninitialized
in this function [-Wuninitialized]
snippet.cc:10:34: warning: ‘*((void*)& tbuf +4)’ is used uninitialized
in this function [-Wuninitialized]
snippet.cc:10:34: warning: ‘*((void*)& tbuf +6)’ is used uninitialized
in this function [-Wuninitialized]
Compiler :
#gcc --versio
gcc (GCC) 7.1.1 20170528
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
My question is. Is this an expected behaviour or I must report a bug ?
Thank you!
Kirill
request for new a syntactic design for C/C++.
Hello ! I for the first time write to this list of dispatch. I would like to offer one expansion for C/C ++. It is quite well entered in an existing design of language. This expansion increases expressive power of language since preconditions for reduction of a role of macros and patterns are created. For some schemes in which it is necessary to carry out reductions of type to appear more logical alternative design. Now in essence. Some time back I did not like a situation with asymmetry dereferencing fields of structure. I.e. absolutely easily it is possible to receive the address of memory almost any element in structure (except for a bit field), but reversed transformation, i.e. to the address of a field to receive the beginning of all structure, is essentially more complex operation in which some assignments of types are made. Not strict typification in this case can arouse a mistake in a code. Reduction of type very frequent operation for structures at which in the beginning of structure appears other, heading structure. The first offer concerns additions of a symmetric design concerning syntax dereferencing an element. On an example dereferencing "init_ptr = *load_ptr-> field;" I shall describe reversed syntax. Current syntax C/C++: load_ptr = typeof(load_ptr)(((char *)init_ptr) - \ offsetof(typeof(init_ptr), field); The offered syntax: &load_ptr->field = init_ptr; Where `load_ptr' and `init_ptr' should be indexes. In the index `load_ptr' the address of the beginning of structure `typeof(load_ptr)` with which the field field is placed to the address of which specifies `init_ptr' will be placed. It is possible to combine with definition. The name of type is added only: struct some_struct &load_ptr->field = init_ptr; load_ptr->field = val; Definition is similar to existing syntax of definition in C++. But nevertheless syntax, and operation (I mean similarity of operation, that the symbol '&' is used to the left of a sign on giving) differs: Definition is similar to existing syntax of definition in C++. But differs both syntax, and action of operation. I mean similarity of operation, that the symbol '&' is used to the left of a sign '=' on giving. C++: struct some_struct &link = other; link.field = val; Assignment: link1 = &load_ptr->field = link2 = init_ptr; It should be interpreted from right to left: link2 = init_ptr; &load_ptr->field = init_ptr; link1 = init_ptr; If it is necessary to receive the beginning of structure on a field of other structure, enclosed in given these fields are specified through a symbol of a point: &load_ptr->substruct1.substruct2.field = init_ptr; Sense in that if simply to change places the right and left parts of operation of giving we receive operation, reversed given. At a physical level operation "init_ptr = &load_ptr-> field;" initializes a variable `init_ptr' which the beginnings of structure are defined by an increment to `load_ptr' sizes of shift of a field `field' concerning. Operation "*load_ptr-> field = init_ptr;" defines `load_ptr' by reduction `init_ptr' on size of shift of a field `field' concerning the beginning of structure. In my opinion, this opportunity will promote development of procedural programming. In some cases will make unnecessary use of dangerous assignment of type. Quite probably that the similar offer appeared earlier. If it so I ask me to excuse. Thanks.
Re: request for new a syntactic design for C/C++.
Ian Lance Taylor wrote:
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> writes:
Current syntax C/C++:
load_ptr = typeof(load_ptr)(((char *)init_ptr) - \
offsetof(typeof(init_ptr), field);
The offered syntax:
&load_ptr->field = init_ptr;
Interesting idea, but C/C++ programmers expect that an assignment sets
the entire expression on the left of the '='. So I don't think this
is a good syntax.
&load_ptr->field = init_ptr;
For given line only `load_ptr' variable will be changed. This changes based
on `init_ptr' variable and on the name of the field. Field name parameter is
static. May be it's not so dramatic ? Let me show you as example attached
file: "example1.c".
There is one another example. Many of interpretation languages have a
general
header in the element structure (and not only languages). Type definition is
very frequently uses operation just for transit pointer to the object over
C-API:
struct head_of_object {
int type;
...
};
struct one_type {
struct head_of_object head;
...
};
Currently syntactic design definition of function and a few lines in
the body is look like:
struct head_of_object *
function(struct head_of_object *ob_head) {
...
struct one_type *ob = (struct one_type *)ob_head;
...
return &ob->ob_head;
...
}
This is some asymmetrically. Type definition in this case is not required.
With given purposes it will be become to look like:
struct head_of_object *
function(struct one_type &ob->head) {
...
return &ob->ob_head;
...
}
For passed argument it is require pointer to a type of field `head'
(struct head_of_object *). In body of function pointer `ob' have
type "struct one_type". Magnitude this syntactic construction
is the same as in previous examples.
In fact you can already write what you want with a macro, one quite
similar to offsetof, so I don't think we need any new syntactic sugar
here.
It's really only syntactic changes. With this extension code become
more clear. Of course, it's not one way to do it. I just give one
clause.
And one more example:
type_to_find *one_ptr;
struct type2 {
type1field1;
type2field2;
type_to_find field3;
} *two_ptr = init_something;
#if 1
// case 1
one_ptr = &two_ptr->field3; // This is okay. Is it a really
syntactic sugar ?
#else
// case 2
one_ptr = typeof(one_ptr)(((char *)two_ptr) + \
sizeof(two_ptr->field1) + \
sizeof(two_ptr->field2)); // And this is okay.
// But nobody use it
// because it is
// heavily and
unsafe.
#endif
C++:
struct some_struct &link = other;
This already means something in C++: it means to create a reference.
Yes. I just want to point for similar syntax.
typedef union __genlink {
struct {
union __genlink *qcl_prev;
union __genlink *qcl_next;
} qcl; /* Queue/Cycle/List */
void*point[2];
union __genlink *link[2];
} genlink;
struct timeout_and_refresh_list {
int type;
genlink node_timeout;
genlink node_refresh;
time_t tm_start;
time_t tm_last;
char *str;
};
genlink timeout_root;
genlink refresh_root;
void
qcl_init(genlink *root) {
root->qcl.qcl_next = root;
root->qcl.qcl_prev = root;
}
void
qcl_insert_before(genlink *root, genlink *p) {
genlink *prev;
p->qcl.qcl_next = root;
p->qcl.qcl_prev = (prev = root->qcl.qcl_prev);
root->qcl.qcl_prev = prev->qcl.qcl_next = p;
}
void
example_init() {
qcl_init(&timeout_root);
qcl_init(&refresh_root);
}
bool
example_add(struct timeout_and_refresh_list *list, char *str, time_t tm) {
struct timeout_and_refresh_list *elem;
genlink *p;
for (p = &list->refresh_root;;) {
/*
* Walk on the `refresh' list.
*/
if ((p = p->qcl.qcl_next) == &list->refresh_root) {
/*
* Element is not found. Make a new one.
*/
if ((elem = malloc(sizeof(*elem))) == NULL)
goto failed;
elem->tm_start = elem->tm_last = tm;
elem->str = strdup(str);
qcl_insert_before(&refresh_root, elem);
qcl_insert_before(&timeout_root, elem);
break;
Re: request for new a syntactic design for C/C++.
Mike Stump wrote: On Jul 9, 2006, at 10:52 PM, Vladimir 'Yu' Stepanov wrote: I would like to offer one expansion for C/C++. Did you just reinvent downcasting in C++? If so, C++ already has that feature!? As for C, C, I'd claim C already has that feature[1], you merely have to put in a #define into your library to make it look pretty. In C, since this is a library issue, the compiler would be the wrong place to put the feature. Since it can be done with a macro, there is little need to change the grammar of the language. I cannot to understand. I think what this feature is misses on C and C++. Macros is not good choice. Just macros is exclusive method for now. Given expansion have more clear syntax and mostly it is shortly. Macros is inconstant and cannot do a type verification. > 1 - Contentious, should be decided by C committee IMHO. Of course. But it is may be not go so far. And I don't know about any email of theirs (joke). It is really not needed so often in existing style of programing. But this feature may be very usable for some other style of programing. Thanks.
Re: State of AutoFDO in GCC
Andi, thanks for pointing out the perf script issues. Can you please elaborate a bit on the exact issue you have seen? We’ve been using specific output of perf script such as mmap, LBR and callstack events filtered by process id. It works fine so far but may certainly hit issues in the future with extended uses. Thanks, Hongtao From: Xinliang David Li Date: Monday, April 26, 2021 at 11:05 AM To: Andi Kleen Cc: Jan Hubicka , gcc@gcc.gnu.org , Wei Mi , Eugene Rozenfeld , Wenlei He , Hongtao Yu Subject: Re: State of AutoFDO in GCC On Mon, Apr 26, 2021 at 11:00 AM Andi Kleen mailto:a...@linux.intel.com>> wrote: >There are multiple directional changes in this new tool: >1) it uses perf-script trace output (in text) as input profile data; I suspect this will break regularly too (I personally did numerous changes to perf script output, and also wrote a lot of parsing scripts) The perf script output has some bad problems, e.g. for file names or processes with spaces and some other issues. To make it handleable would need some redesign to actually generate in a machine friendly format. Andi, thanks for the input. +authors of the llvm-profgen tool for their experience with using perf script output. David A perf.data parser should be fine, just don't fill it up with asserts and "be liberal what you accept" and ignore unknown records. -Andi
