Re: Please support coo.h
I am familiar with C++, Do not recommend C++ to me.
gcc initial the first member of union now, This is not the C standard also.
I just want gcc initial the last member of union with some switch.
2010/6/11 Magnus Fromreide ma...@lysator.liu.se:
On Fri, 2010-06-11 at 08:44 +0800, yuanbin wrote:
typedef struct CBase { int i; } CBase;
typedef struct CT1 { EXTENDS(CBase) ... } CT1;
typedef struct CT2 { EXTENDS(CT1) ... } CT2;
...
typedef struct CTN { EXTENDS(CTN_1) ... } CTN;
CTN t;
t.i=1; //need not t.CTN_1CT2.CT1.CBase.i ---complex
CBase* p=t.CBase; //need not t.CTN_1CT2.CT1.CBase, need not
(CBase*)t ---not safe
struct CBase { int i; };
struct CT1 : CBase { ... };
struct CT2 : CT1 { ... };
struct CTN : CTN_1 { ... };
CTN t;
t.i = 1; // assumes this is in function scope
CBase* p = t; // Even simpler than your proposal and still safe.
Yep, this is valid C++. I think Dave is right, you really want C++.
/MF
2010/6/11 Dave Korn dave.korn.cyg...@gmail.com:
On 10/06/2010 18:07, yuanbin wrote:
This compiler's extension is valuable
No, it isn't very valuable, sorry to be blunt. I think you are following
a
really wrong path here. You are trying to implement a C++-alike
object-oriented system in C. That makes sense as far as it goes, but if
you
find yourself having to propose modifying the C compiler in a direction
that
basically makes it speak C++, you might as well just use C++ in the first
place. You want the compiler to automatically choose one of several
different
ways to initialise a union according to the data type of the argument you
use
to initialise it with; basically, that means you want overloaded
constructors.
So you should just use C++, which already is C with overloaded
constructors.
And it also already has all the other features that you'll discover you
need
in the compiler as you carry along this path.
By the time you get to the end of your journey, coo.h will be an empty
file and all the functionality will have been added to the C compiler
until it
turns into a C++ compiler. I think you need to choose a different plan.
cheers,
DaveK
Re: hot/cold pointer annotation
On Thu, Jun 10, 2010 at 10:26 PM, Andi Kleen a...@firstfloor.org wrote:
Hi Honza,
Here's an idea to make it easier to manually annotate
large C code bases for hot/cold functions where
it's too difficult to use profile feedback.
It's fairly common here to call function through
function pointers in manual method tables.
A lot of code is targetted by a few function pointers
(think like backends or drivers)
Some of these function pointers always point to cold
code (e.g. init/exit code) while others are usually
hot.
Now as an alternative to manually annotate the hot/cold
functions it would be much simpler to annotate the function
pointers and let the functions that get assigned to
inherit that.
So for example
struct ops {
void (*init)() __attribute__((cold));
void (*exit)() __attribute__((cold));
void (*hot_op)() __attribute__((hot));
};
void init_a(void) {}
void exit_a(void) {}
void hot_op(void) {}
const struct ops objecta = {
.init = init_a,
.exit = exit_a,
.hot_op = hot_op_a
};
/* lots of similar objects with struct ops method tables */
init_a, exit_a and their callees (if they are not
called by anything else) would automatically become all cold,
and hot_op_a (and unique callees) hot, because they
are assigned to a cold or hot function pointer.
Basically the hot/coldness would be inheritted from
a function pointer assignment too.
Do you think a scheme like this would be possible to implement?
Iff the inheritence is restricted to initializers like in the above example
it should be straight-forward to implement in the frontends.
If it should handle general assignments in code-fragments it would
be much harder (and a lot more fragile). So - would restricting
this to initializers be good enough?
Thanks,
Richard.
Thanks,
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
Re: hot/cold pointer annotation
Richard Guenther richard.guent...@gmail.com writes: Iff the inheritence is restricted to initializers like in the above example it should be straight-forward to implement in the frontends. Great. For best results would need some inheritance to callees too, if the callees are not called by other non annotated code (that would probably only work in whole-program mode, but that's fine) If it should handle general assignments in code-fragments it would be much harder (and a lot more fragile). So - would restricting this to initializers be good enough? Yes I think only handling it in initializers would be enough. There are some exceptions where function pointers are assigned directly, but they are relatively rare. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Issue with LTO/-fwhole-program
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by whole-program
optimizer,
and the other is global. I know I can add externally_visible in a.c to solve
the issue. But since compiler is not able to give any warning here, it could
make
program very tricky to debug.
What is the value to convert variables to static ones? I know unreferenced ones
can
be optimized out, but this can be achieved by -fdata-sections -gc-collection
as
well, I believe.
Cheers,
Bingfeng
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by whole-program
optimizer,
and the other is global. I know I can add externally_visible in a.c to solve
the issue. But since compiler is not able to give any warning here, it could
make
program very tricky to debug.
What is the value to convert variables to static ones? I know unreferenced
ones can
be optimized out, but this can be achieved by -fdata-sections
-gc-collection as
well, I believe.
You make inter-procedural/file data-flow operations possible.
Richard.
Cheers,
Bingfeng
Re: Issue with LTO/-fwhole-program
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by whole-program
optimizer,
and the other is global. I know I can add externally_visible in a.c to solve
the issue. But since compiler is not able to give any warning here, it
could make
program very tricky to debug.
What is the value to convert variables to static ones? I know unreferenced
ones can
be optimized out, but this can be achieved by -fdata-sections
-gc-collection as
well, I believe.
You make inter-procedural/file data-flow operations possible.
But this is a bug, isn't it?
Cheers,
Manuel.
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by whole-program
optimizer,
and the other is global. I know I can add externally_visible in a.c to solve
the issue. But since compiler is not able to give any warning here, it
could make
program very tricky to debug.
What is the value to convert variables to static ones? I know unreferenced
ones can
be optimized out, but this can be achieved by -fdata-sections
-gc-collection as
well, I believe.
You make inter-procedural/file data-flow operations possible.
But this is a bug, isn't it?
No, you lied to the compiler by specifying -fwhole-file.
Richard.
Cheers,
Manuel.
Re: Issue with LTO/-fwhole-program
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by whole-program
optimizer,
and the other is global. I know I can add externally_visible in a.c to
solve
the issue. But since compiler is not able to give any warning here, it
could make
program very tricky to debug.
What is the value to convert variables to static ones? I know unreferenced
ones can
be optimized out, but this can be achieved by -fdata-sections
-gc-collection as
well, I believe.
You make inter-procedural/file data-flow operations possible.
But this is a bug, isn't it?
No, you lied to the compiler by specifying -fwhole-file.
I don't understand. The final link was the whole program.
Manuel.
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by whole-program
optimizer,
and the other is global. I know I can add externally_visible in a.c to
solve
the issue. But since compiler is not able to give any warning here, it
could make
program very tricky to debug.
What is the value to convert variables to static ones? I know
unreferenced ones can
be optimized out, but this can be achieved by -fdata-sections
-gc-collection as
well, I believe.
You make inter-procedural/file data-flow operations possible.
But this is a bug, isn't it?
No, you lied to the compiler by specifying -fwhole-file.
I don't understand. The final link was the whole program.
GCC does not see the whole program if you didn't build all units
you are linking with -flto.
Richard.
Manuel.
Re: Please support coo.h
On 06/11/2010 10:15 AM, yuanbin wrote: gcc initial the first member of union now, This is not the C standard also. I just want gcc initial the last member of union with some switch. Why do you want the last one? Is there a compiler that does that (e.g. MSVC++)? If yes, it can be toggled by -fms-extensions. But if no, there's no reason why you or whoever wrote coo.h cannot just reorder the fields in the union. Paolo
Re: Issue with LTO/-fwhole-program
On 11 June 2010 14:40, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by whole-program
optimizer,
and the other is global. I know I can add externally_visible in a.c to
solve
the issue. But since compiler is not able to give any warning here, it
could make
program very tricky to debug.
What is the value to convert variables to static ones? I know
unreferenced ones can
be optimized out, but this can be achieved by -fdata-sections
-gc-collection as
well, I believe.
You make inter-procedural/file data-flow operations possible.
But this is a bug, isn't it?
No, you lied to the compiler by specifying -fwhole-file.
I don't understand. The final link was the whole program.
GCC does not see the whole program if you didn't build all units
you are linking with -flto.
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Manuel.
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 2:57 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:40, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:36 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:23, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Jun 11, 2010 at 2:22 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 11 June 2010 14:07, Richard Guenther richard.guent...@gmail.com
wrote:
On Fri, Jun 11, 2010 at 2:04 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include stdio.h
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf(v = %d\n, v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
If I compile as:
~/work/install-x86/bin/gcc a.c -O2 -c -save-temps -flto
~/work/install-x86/bin/gcc b.c -O2 -c -save-temps
~/work/install-x86/bin/gcc a.o b.o -O2 -fuse-linker-plugin -o f -flto
-fwhole-program
The output is:
v = 5
We get two copies of v here. One is converted to static by
whole-program optimizer,
and the other is global. I know I can add externally_visible in a.c to
solve
the issue. But since compiler is not able to give any warning here, it
could make
program very tricky to debug.
What is the value to convert variables to static ones? I know
unreferenced ones can
be optimized out, but this can be achieved by -fdata-sections
-gc-collection as
well, I believe.
You make inter-procedural/file data-flow operations possible.
But this is a bug, isn't it?
No, you lied to the compiler by specifying -fwhole-file.
I don't understand. The final link was the whole program.
GCC does not see the whole program if you didn't build all units
you are linking with -flto.
Ah, so the problem is the missing -flto in the second compilation
step? I think this is a bug in the compiler for not reporting this
somehow. Is there are PR open for this?
Well, we can't. We specifically support mixed LTO/non LTO objects
(think of shared libraries for example). With the linker-plugin and gold
we can do better, but with just GNU ld and collect2 we can't.
Richard.
Manuel.
Re: [Tinycc-devel] Please support coo.h
i have pushed the patch on mob
Coo: initial last member of union
Please change my name of patch: U-YUAN\Administrator - yuanbin
2010/6/11 grischka gris...@gmx.de:
Too all:
Please push patches on our mob branch:
http://repo.or.cz/w/tinycc.git
People who don't like/know git: at least base patches on latest
mob or master branch.
Also please give a short description of what the patch really
does. Otherwise it will be too hard for us other people.
Thanks,
--- grischka
yuanbin wrote:
Coo - C, Object Oriented
http://sourceforge.net/projects/coo/
-coo.h--
#ifndef __COO_H__
#define __COO_H__
typedef struct VTable /*root of virtual table class*/
{
long offset; /*servers for FREE*/
} VTable;
#define EXTENDS(s) \
union \
{ \
s s; \
s; \
};
#define VT(v) const v* vt;
#define EXTENDS2(s,v) \
union \
{ \
VT(v) \
s s; \
s; \
};
#ifndef offsetof
#define offsetof(s,m) ((long)((s*)0)-m)
#endif
#define SUPER(s,m,p) ((s*)((char*)(p)-offsetof(s,m)))
#define FREE(p,vt) free((char*)(p)-(vt)-offset)
#endif
--
initialization of the enum:
enum {
int i;
float f;
} t={1.5}; //t.f
because of EXTENDS2 in coo.h, compiler needs
to initialze last member of enum.
--tccgen.c--
static void decl_initializer(CType *type, Section *sec, unsigned long c,
int first, int size_only)
{
int index, array_length, n, no_oblock, nb, parlevel, i;
int size1, align1, expr_type;
Sym *s, *f;
CType *t1;
if (type-t VT_ARRAY) {
s = type-ref;
n = s-c;
array_length = 0;
t1 = pointed_type(type);
size1 = type_size(t1, align1);
no_oblock = 1;
if ((first tok != TOK_LSTR tok != TOK_STR) ||
tok == '{') {
skip('{');
no_oblock = 0;
}
/* only parse strings here if correct type (otherwise: handle
them as ((w)char *) expressions */
if ((tok == TOK_LSTR
#ifdef TCC_TARGET_PE
(t1-t VT_BTYPE) == VT_SHORT (t1-t VT_UNSIGNED)
#else
(t1-t VT_BTYPE) == VT_INT
#endif
) || (tok == TOK_STR (t1-t VT_BTYPE) == VT_BYTE)) {
while (tok == TOK_STR || tok == TOK_LSTR) {
int cstr_len, ch;
CString *cstr;
cstr = tokc.cstr;
/* compute maximum number of chars wanted */
if (tok == TOK_STR)
cstr_len = cstr-size;
else
cstr_len = cstr-size / sizeof(nwchar_t);
cstr_len--;
nb = cstr_len;
if (n = 0 nb (n - array_length))
nb = n - array_length;
if (!size_only) {
if (cstr_len nb)
warning(initializer-string for array is too
long);
/* in order to go faster for common case (char
string in global variable, we handle it
specifically */
if (sec tok == TOK_STR size1 == 1) {
memcpy(sec-data + c + array_length, cstr-data,
nb);
} else {
for(i=0;inb;i++) {
if (tok == TOK_STR)
ch = ((unsigned char *)cstr-data)[i];
else
ch = ((nwchar_t *)cstr-data)[i];
init_putv(t1, sec, c + (array_length + i) *
size1,
ch, EXPR_VAL);
}
}
}
array_length += nb;
next();
}
/* only add trailing zero if enough storage (no
warning in this case since it is standard) */
if (n 0 || array_length n) {
if (!size_only) {
init_putv(t1, sec, c + (array_length * size1), 0,
EXPR_VAL);
}
array_length++;
}
} else {
index = 0;
while (tok != '}') {
decl_designator(type, sec, c, index, NULL, size_only);
if (n = 0 index = n)
error(index too large);
/* must put zero in holes (note that doing it that way
ensures that it even works with designators) */
if (!size_only array_length index) {
init_putz(t1, sec, c + array_length * size1,
(index - array_length) * size1);
}
index++;
if (index array_length)
array_length = index;
/* special test for multi dimensional arrays (may not
be strictly correct if designators are used at
Re: Issue with LTO/-fwhole-program
On 11/06/2010 13:59, Richard Guenther wrote: Well, we can't. We specifically support mixed LTO/non LTO objects (think of shared libraries for example). With the linker-plugin and gold we can do better, but with just GNU ld and collect2 we can't. Well then shouldn't we warn if -fwhole-program is used with mixed LTO and non-LTO objects? Or disable it, or both? cheers, DaveK
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 3:21 PM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 11/06/2010 13:59, Richard Guenther wrote: Well, we can't. We specifically support mixed LTO/non LTO objects (think of shared libraries for example). With the linker-plugin and gold we can do better, but with just GNU ld and collect2 we can't. Well then shouldn't we warn if -fwhole-program is used with mixed LTO and non-LTO objects? Or disable it, or both? Hum. Maybe - currently we figure out whether an object is LTO or not in collect2, so that's where the warning should reside (but collect2 has no idea about compilation flags but just passes them through). Richard. cheers, DaveK
RE: Issue with LTO/-fwhole-program
Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly Application. Gold support for our target is still far away. I found -fwhole-program is very important for our size optimization. Bingfeng -Original Message- From: Dave Korn [mailto:dave.korn.cyg...@gmail.com] Sent: 11 June 2010 14:21 To: Richard Guenther Cc: Manuel López-Ibáñez; Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka Subject: Re: Issue with LTO/-fwhole-program On 11/06/2010 13:59, Richard Guenther wrote: Well, we can't. We specifically support mixed LTO/non LTO objects (think of shared libraries for example). With the linker-plugin and gold we can do better, but with just GNU ld and collect2 we can't. Well then shouldn't we warn if -fwhole-program is used with mixed LTO and non-LTO objects? Or disable it, or both? cheers, DaveK
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 3:04 PM, Bingfeng Mei b...@broadcom.com wrote: Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly Application. Gold support for our target is still far away. I found -fwhole-program is very important for our size optimization. True. Without symbol resolution information when using GNU ld it is hard to do anything reasonable though. How far has the idea of adding resolution output to GNU ld developed? Richard. Bingfeng -Original Message- From: Dave Korn [mailto:dave.korn.cyg...@gmail.com] Sent: 11 June 2010 14:21 To: Richard Guenther Cc: Manuel López-Ibáñez; Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka Subject: Re: Issue with LTO/-fwhole-program On 11/06/2010 13:59, Richard Guenther wrote: Well, we can't. We specifically support mixed LTO/non LTO objects (think of shared libraries for example). With the linker-plugin and gold we can do better, but with just GNU ld and collect2 we can't. Well then shouldn't we warn if -fwhole-program is used with mixed LTO and non-LTO objects? Or disable it, or both? cheers, DaveK
Re: Issue with LTO/-fwhole-program
On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com wrote: Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly Application. Gold support for our target is still far away. I found -fwhole-program is very important for our size optimization. But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. Manuel.
RE: Issue with LTO/-fwhole-program
-Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: 11 June 2010 14:08 To: Bingfeng Mei Cc: Dave Korn; Manuel López-Ibáñez; gcc@gcc.gnu.org; Jan Hubicka Subject: Re: Issue with LTO/-fwhole-program On Fri, Jun 11, 2010 at 3:04 PM, Bingfeng Mei b...@broadcom.com wrote: Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly Application. Gold support for our target is still far away. I found - fwhole-program is very important for our size optimization. True. Without symbol resolution information when using GNU ld it is hard to do anything reasonable though. How far has the idea of adding resolution output to GNU ld developed? Not much progress yet. I am not very familiar to structure of GNU LD, and need more time crack it. I applied Dave's patch and output l...@offset list from ld and hacked collect2. It can work if I annotate externally_visible attribute manually, but it seems quite error-prone process. So I also try to make sure resolution file is used for automatic annotation of externally_visible attribute. I will send an updated patch later. Richard. Bingfeng -Original Message- From: Dave Korn [mailto:dave.korn.cyg...@gmail.com] Sent: 11 June 2010 14:21 To: Richard Guenther Cc: Manuel López-Ibáñez; Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka Subject: Re: Issue with LTO/-fwhole-program On 11/06/2010 13:59, Richard Guenther wrote: Well, we can't. We specifically support mixed LTO/non LTO objects (think of shared libraries for example). With the linker-plugin and gold we can do better, but with just GNU ld and collect2 we can't. Well then shouldn't we warn if -fwhole-program is used with mixed LTO and non-LTO objects? Or disable it, or both? cheers, DaveK
RE: Issue with LTO/-fwhole-program
-Original Message- From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com] Sent: 11 June 2010 14:14 To: Bingfeng Mei Cc: Dave Korn; Richard Guenther; gcc@gcc.gnu.org; Jan Hubicka Subject: Re: Issue with LTO/-fwhole-program On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com wrote: Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly Application. Gold support for our target is still far away. I found - fwhole-program is very important for our size optimization. But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. Yes, very trick indeed. When I annotate externally_visible attribute to our application, I iteratively check linker map to find which symbols are accessed by non-LTO objects. Sometimes, I end up with one inlined copy and one original copy and compiler doesn't complain. That's why I am working to make the process automated assuming we have full resolution file. Bingfeng
Re: Issue with LTO/-fwhole-program
Ah, so the problem is the missing -flto in the second compilation step? I think this is a bug in the compiler for not reporting this somehow. Is there are PR open for this? Compiler can not report it because it does not see the other object files. It is really up to user to understand -fwhole-program and mark externally visible symbols. Your testcase is quite ugly in a way that it leads to miscopmilation rather than linktime error, but there is not much we can do about it I guess. Perhaps we can somehow poison the object names that are brought local with -fwhole-program so linking explode, but I am not sure there is way to do so. Honza
Re: Issue with LTO/-fwhole-program
On 11 June 2010 15:26, Jan Hubicka hubi...@ucw.cz wrote: Ah, so the problem is the missing -flto in the second compilation step? I think this is a bug in the compiler for not reporting this somehow. Is there are PR open for this? Compiler can not report it because it does not see the other object files. It does see the object files in the final compilation step (perhaps the compiler does not read them but it could). And files compiled with LTO or without LTO are clearly differentiable. So I don't see anything technical stopping the compiler to give a warning about such dubious setup. Should I open a PR? Cheers, Manuel.
Re: Issue with LTO/-fwhole-program
On 11/06/2010 14:26, Jan Hubicka wrote: Perhaps we can somehow poison the object names that are brought local with -fwhole-program so linking explode, but I am not sure there is way to do so. Could emit warning symbols, but, like the others, I don't see why collect2 can't spot this. cheers, DaveK
Re: Issue with LTO/-fwhole-program
On 11/06/2010 14:26, Jan Hubicka wrote: Perhaps we can somehow poison the object names that are brought local with -fwhole-program so linking explode, but I am not sure there is way to do so. Could emit warning symbols, but, like the others, I don't see why collect2 can't spot this. It doesn't know what symbol is declared externally_visible. Honza cheers, DaveK
Re: GCC porting questions
Thanks for the reply. I scrolled a lot through the i386 md and c files. I
notice that the i386 architecture has dedicated
instructions for comparing values and ALU instructions only specify
(clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify
the way ALU instructions affect the flags.
In order to set the flags, I am trying something like this:
(define_expand addsi3
[( parallel [(set (match_operand:SI 0 register_operand )
(plus:SI (match_operand:SI 1 register_operand )
(match_operand:SI 2 nonmemory_operand ))
)
(set (reg:CC FLAGS_REG) (compare:SI (match_dup
1) (match_dup 2)))]
)]
if(GET_CODE(operands[2])==CONST_INT INTVAL(operands[2])==1){
emit_insn(gen_inc(operands[0], operands[1]));
DONE;
}
)
and to use them:
(define_insn beq
[(set (pc)
(if_then_else (eq:SI (reg:CC FLAGS_REG) (const_int 0))
(label_ref
(match_operand 0 ))
(pc)
)
)]
jeq \\t%l0
)
but that does not look right. The carry and zero flags should be set after
the operation and the less than and equal, before the sum is done, since
the destination register can just as well be the same with one of the
sources. The parallel statement, afaik, tells the compiler to evaluate
the operands first, then execute both insns which means that all flags
will be set with the state of the operands before the operation.
I am probably a bit confused about the compiler behavior since I am
thinking more like in the way of machine execution. The compiler doesn't
know the values of the operands at compile time, so it doesn't really set
any flags in the condition register. How does it work then?
Sorry for the large text and thanks again for your time.
Radu Hobincu radu.hobi...@arh.pub.ro writes:
I have written here a few weeks ago regarding some tutorials on GCC
porting and got some very interesting replies. However, I seem to have
gotten stuck with a couple of issues in spite of my massive Googling, and
I was wondering if anyone could spare a couple of minutes for some
clarifications.
I am having troubles with the condition codes (cc_status). I have
looked
over a couple of architectures and I do not seem to understand how they
work.
The machine I am porting GCC for has 1 4bit status register for carry,
zero, less than and equal. I do not have explicit comparison
instructions,
all of the ALU instructions modify one or more flags.
What I figured out so far looking over AVR and Cris machine
descriptions
is that each instruction that modifies the flags contain an attr
declaration which specify what flags it is changing. Also, there is a
macro called NOTICE_UPDATE_CC which sets up the cc_status accordingly by
reading this attr. This is the part of the code I do not understand.
There
are certain functions for which I could not find any descriptions, like
single_set and macros like SET_DEST and SET_SRC. Also, looking over
conditions.h, I see that the CC_STATUS structure contains 2 rtx fields:
value1 and value2, and also an int called flags. What do they
represent? Is flags the contents of the machine's flag register?
For a new port I recommend that you avoid cc0, cc_status, and
NOTICE_UPDATE_CC. Instead, model the condition codes as 1 or 4
pseudo-registers. In your define_insn statements, include SET
expressions which show how the condition code is updated. This is how
the i386 backend works; see uses of FLAGS_REG in i386.md.
As far as things like single_set, SET_DEST, and SET_SRC, you have
reached the limits of the internal documentation. You have to open the
source code and look at the comments. Similarly, the description of the
CC_STATUS fields may be found in the comments above the
definition of CC_STATUS in conditions.h.
Ian
Re: Issue with LTO/-fwhole-program
Manuel López-Ibáñez lopeziba...@gmail.com writes: On 11 June 2010 15:26, Jan Hubicka hubi...@ucw.cz wrote: Ah, so the problem is the missing -flto in the second compilation step? I think this is a bug in the compiler for not reporting this somehow. Is there are PR open for this? Compiler can not report it because it does not see the other object files. It does see the object files in the final compilation step (perhaps the compiler does not read them but it could). And files compiled with LTO or without LTO are clearly differentiable. So I don't see anything technical stopping the compiler to give a warning about such dubious setup. Should I open a PR? Think about the case where the various objects are in an archive. To give this warning correctly in all cases you are essentially going to have to import the linker's symbol resolution mechanism into the compiler. The linker plugin mechanism was designed to precisely avoid doing that. Ian
Re: Issue with LTO/-fwhole-program
Manuel López-Ibáñez lopeziba...@gmail.com writes: On 11 June 2010 15:04, Bingfeng Mei b...@broadcom.com wrote: Well, mixed LTO/non-LTO is quite useful. For example, we have mixed C/assembly Application. Gold support for our target is still far away. I found -fwhole-program is very important for our size optimization. But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. As I understand it, that combination often can be correct. In this particular case it failed because there a common symbol appeared in one file compiled with -flto and in one file compiled without -flto. But mixing -flto/-fno-lto and common symbols in that way is not going to be typical. In general your program should be fine as long as you don't try to define the same symbol with both -flto and -fno-lto, which is exactly the case you will be in if statically linking with a typical C library which was not compiled with -flto. So while clearly we should diagnose this case, it's going to be difficult to implement without giving up something useful. It's going to require linker support. It works already with gold, so this means adding something to the GNU linker. Frankly I think the most straightforward approach would be to add plugin support to the GNU linker. There is nothing gold specific about the LTO linker plugin. Of course that approach wouldn't help on systems which can not use the GNU linker, but we're kind of stuck on those systems anyhow. Ian
Re: GCC porting questions
Radu Hobincu radu.hobi...@arh.pub.ro writes:
Thanks for the reply. I scrolled a lot through the i386 md and c files. I
notice that the i386 architecture has dedicated
instructions for comparing values and ALU instructions only specify
(clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify
the way ALU instructions affect the flags.
E.g.,
(define_insn *submode_2
[(set (reg FLAGS_REG)
(compare
(minus:SWI
(match_operand:SWI 1 nonimmediate_operand 0,0)
(match_operand:SWI 2 general_operand ri,rm))
(const_int 0)))
(set (match_operand:SWI 0 nonimmediate_operand =rm,r)
(minus:SWI (match_dup 1) (match_dup 2)))]
ix86_match_ccmode (insn, CCGOCmode)
ix86_binary_operator_ok (MINUS, MODEmode, operands)
sub{imodesuffix}\t{%2, %0|%0, %2}
[(set_attr type alu)
(set_attr mode MODE)])
In order to set the flags, I am trying something like this:
(define_expand addsi3
[( parallel [(set (match_operand:SI 0 register_operand )
(plus:SI (match_operand:SI 1 register_operand )
(match_operand:SI 2 nonmemory_operand ))
)
(set (reg:CC FLAGS_REG) (compare:SI (match_dup
1) (match_dup 2)))]
)]
if(GET_CODE(operands[2])==CONST_INT INTVAL(operands[2])==1){
emit_insn(gen_inc(operands[0], operands[1]));
DONE;
}
)
That doesn't look right, unless your machine is rather odd. You want
something like the above: set the FLAGS_REG to the comparison of the
sum with zero.
I am probably a bit confused about the compiler behavior since I am
thinking more like in the way of machine execution. The compiler doesn't
know the values of the operands at compile time, so it doesn't really set
any flags in the condition register. How does it work then?
You describe to the compiler what value the flags register will hold
after the operation is complete, in terms of the operands.
Ian
Re: Scheduling x86 dispatch windows
On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote: On the other hand, I'm not going to argue that it's a lot of work. Missing not ! When you say put assertions in the assembler output I understood it to mean in the assembly source code output by the compiler, not the output produced by the assembler. Yes. Does this qualify as a form of what you are suggesting? Because this is exactly what is being proposed: .balign 8 # start window insn op, op # 67 67 XX YY ZZ - padded with 2 prefixes to make 8 insn2 op, op# AA BB CC .padalign 8 # window boundary insn4 op . . . No, this is quite different. These are directives that tell the assembler to make changes. I'm talking about assertions, not directives. Something like this: mov r0, r1 @ [length 2] add ip, lr, ip @ [length 4] mov r0, r1 @ [length 4] -- assembler error 'insn has length 2' GCC can output length information, but it is never exact, and it is not in a form recognized by the assembler. On x86, I have no idea how this would work. -- Daniel Jacobowitz CodeSourcery
Re: Minor issue with recent code to twiddle costs of pseudos with invariant equivalents
On 06/10/10 14:44, Bernd Schmidt wrote: On 06/10/2010 10:37 PM, Jeff Law wrote: Compile the attached with -O2 on x86-unknown-linux-gnu and review the .ira dump for main() starting the processing of deferred insns ending the processing of deferred insns df_analyze called Building IRA IR starting the processing of deferred insns ending the processing of deferred insns df_analyze called init_insns for 59: (insn_list:REG_DEP_TRUE 5 (nil)) Reg 59 has equivalence, initial gains 4000 [...] r59: preferred NO_REGS, alternative NO_REGS, cover NO_REGS [...] Disposition: 0:r59 l0 mem Ultimately I think reload is cleaning this up, but it seems awful strange to have a pseudo/allocno which clearly should be allocated to a hard GPR preferring NO_REGS and from an allocation standpoint living in memory. From the above, I don't see the problem. Reg 59 is detected as reg_equiv_invariant, which means if we don't allocate a hard reg to it, we can substitute the invariant everywhere and save the initializing instruction. As far as I can tell this is working exactly as intended. But shouldn't having an invariant form just decrease the priority for pseudo 59 to get a hard register? The NO_REGS preferencing will totally disable register allocation for pseudo 59. Just because we have an invariant equivalent form doesn't mean we should totally disable allocation -- if a hard reg is available, we're sometimes going to be better off using a hard reg to hold the value rather than substituting the equivalent form at each use of the pseudo. Jeff Bernd
Re: Issue with LTO/-fwhole-program
* Jan Hubicka wrote on Fri, Jun 11, 2010 at 03:26:12PM CEST: Ah, so the problem is the missing -flto in the second compilation step? I think this is a bug in the compiler for not reporting this somehow. Is there are PR open for this? Compiler can not report it because it does not see the other object files. It is really up to user to understand -fwhole-program and mark externally visible symbols. Your testcase is quite ugly in a way that it leads to miscopmilation rather than linktime error, but there is not much we can do about it I guess. Perhaps we can somehow poison the object names that are brought local with -fwhole-program so linking explode, but I am not sure there is way to do so. The requirement to compile with -flto needs to be documented in the description of the -fwhole-program switch in invoke.texi. The text of the following -flto switch is long enough that the user will not by see that by chance, and it isn't very specific on this either. More generally, the description of -fwhole-program does not make it clear to me whether it is required at compile time or link time only, or both. Likewise, it is unclear whether the combination of -fwhole-program with -combine, -flto, or -fwhopr is to happen at compile time, link time, both, or one switch at compile time and another at link time, or one for some translation units at compile time, and another for others. The description refers to the current compilation unit but there may be more than one unit, or none at all if only objects and libraries were specified. I'm willing to improve the documentation if somebody explains the intended semantics to me. :-) Cheers, Ralf
Re: Minor issue with recent code to twiddle costs of pseudos with invariant equivalents
On 06/11/2010 06:32 PM, Jeff Law wrote: But shouldn't having an invariant form just decrease the priority for pseudo 59 to get a hard register? The NO_REGS preferencing will totally disable register allocation for pseudo 59. And that's intended, because from the costs we've concluded that it's better _not_ to allocate a hard reg to this pseudo. Just because we have an invariant equivalent form doesn't mean we should totally disable allocation -- if a hard reg is available, we're sometimes going to be better off using a hard reg to hold the value rather than substituting the equivalent form at each use of the pseudo. Please look at the testcases in the PRs referenced in my checkin - PR42500, 42502, 39871 and 40615. In each of these cases, we can improve allocation by not giving out a hard reg for the pseudo involved. The new code is intended to calculate the costs of not using a hard register, and uses these costs instead of generic memory costs in IRA. If they are lower than the costs for any register class, we prefer not to allocate the reg. Bernd
Re: Issue with LTO/-fwhole-program
Quoting Jan Hubicka hubi...@ucw.cz:
Perhaps we can somehow poison the object names that are brought
local with -fwhole-program
so linking explode, but I am not sure there is way to do so.
The linker will generally emit a diagnostic when the size or alignment
of a symbol increases, or the type changes.
Unfortunately, this makes the warnings dependent on the link order and type
of symbols; I see no way to make it warn about common symbols without
alignment which are linked after poisoned symbols.
[amyl...@meolyon symclash]$ tail a.c b.S c.c
== a.c ==
int i;
char c;
== b.S ==
.section .note.poison
.globl i
.type i, @function
i: .size i, 0
.globl c
.type c, @function
c: .size c, 43
== c.c ==
int main ()
{
return 0;
}
[amyl...@meolyon symclash]$ gcc a.c b.S c.c --save-temps
/usr/bin/ld: Warning: alignment 1 of symbol `i' in b.o is smaller than
4 in a.o
/usr/bin/ld: Warning: type of symbol `i' changed from 1 to 2 in b.o
/usr/bin/ld: Warning: size of symbol `c' changed from 1 in a.o to 43 in b.o
/usr/bin/ld: Warning: type of symbol `c' changed from 1 to 2 in b.o
[amyl...@meolyon symclash]$ gcc b.S a.c c.c -Wall --save-temps
/usr/bin/ld: Warning: alignment 1 of symbol `i' in b.o is smaller than
4 in a.o
Re: Minor issue with recent code to twiddle costs of pseudos with invariant equivalents
On 06/11/10 10:48, Bernd Schmidt wrote: On 06/11/2010 06:32 PM, Jeff Law wrote: But shouldn't having an invariant form just decrease the priority for pseudo 59 to get a hard register? The NO_REGS preferencing will totally disable register allocation for pseudo 59. And that's intended, because from the costs we've concluded that it's better _not_ to allocate a hard reg to this pseudo. OK. I wasn't aware that's how we marked a pseudo that shouldn't get a hard reg due to costing considerations. Thanks for explaining. Jeff
Dump final-most gimple (with ssa) using the plugin option
Hi,
I am trying to dump the final-most gimple (in ssa) file. My understanding is
that lto encodes GIMPLE IR in the bytestream of the object files and
accordingly I invoke PLUGIN_PASS_MANAGER_SETUP to embed my faux dummy pass
after 'pass_ipa_lto_finish_out'. Is ssa information available at the
'all_lto_gen_passes' stage?
Also, should I check for other properties (PROP_trees) and should I bother with
TODO_cleanup_cfg?
Error message:
cc1: fatal error: pass ‘ipa_lto_gimple_out’ not found but is referenced by new
pass ‘gimpleSSA_out’
Any help would be greatly appreciated.
Thank you.
Regards,
Karthik
------
------
#include gcc-plugin.h
#include config.h
#include system.h
#include coretypes.h
#include tree.h
#include intl.h
#include tm.h
#include gimple.h
#include tree-pass.h
#include string.h
int plugin_is_GPL_compatible;
struct ipa_opt_pass_d pass_dump_GSSA =
{
{
IPA_PASS,
gimpleSSA_out, /* name */
NULL, /* gate */
NULL, /* execute */
NULL, /* sub */
NULL, /* next */
0, /* static_pass_number - a nonzero
static_pass_number
indicates that the pass is
already in the list. */
0, /* tv_id */
PROP_ssa, /* properties_required */
0, /* properties_provided */
0, /* properties_destroyed */
0, /* todo_flags_start */
TODO_update_ssa_any
| TODO_dump_func /* todo_flags_finish */
},
NULL, /* generate_summary */
NULL, /* write_summary */
NULL, /* read_summary */
NULL, /* function_read_summary */
NULL, /* stmt_fixup */
0, /* TODOs */
NULL, /* function_transform */
NULL /* variable_transform */
};
int
plugin_init (struct plugin_name_args *plugin_info,
struct plugin_gcc_version *version)
{
/* if (!plugin_default_version_check (version, gcc_version))
return 1; */
struct register_pass_info pass_info;
const char *plugin_name = plugin_info-base_name;
int argc = plugin_info-argc;
struct plugin_argument *argv = plugin_info-argv;
pass_info.pass = pass_dump_GSSA.pass;
pass_info.reference_pass_name = ipa_lto_gimple_out;
/*Do it for every instance if it is 0. */
pass_info.ref_pass_instance_number = 0;
/* This pass can go almost anywhere as long as you're in SSA form */
pass_info.pos_op = PASS_POS_INSERT_AFTER;
/* Register this new pass with GCC */
register_callback (plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL,
pass_info);
/* Register the user attribute */
/*register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes,
NULL); */
return 0;
}
------
------
GCC=/usr/local/bin/gcc-4.5
PLUGIN_SOURCE_FILES= plugin_dumpGimpleSSA.c
PLUGIN_OBJECT_FILES= $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES))
GCCPLUGINS_DIR:= $(shell $(GCC) -print-file-name=plugin)
CFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -O2
dumpGimpleSSA_plugin.so: $(PLUGIN_OBJECT_FILES)
$(GCC) -shared $^ -o $@
------
/usr/local/bin/gcc-4.5 -v -O2 -o prova -fdump-tree-all
-fplugin=/home/karthik/Temp/dumpGimpleSSA_plugin.so ../../prova.c
------
_
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with
Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5
Re: Issue with LTO/-fwhole-program
But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. It's not only correct, it's essential. Whole Program doesn't mean that the compiler has to see all the IR for the whole program. Instead, the compiler has visibility over the whole program in the sense that it knows what variables and functions are referenced and defined by the non-LTO code. Linking your program with non-LTO code is inescapable unless we start shipping language and system libraries as archives of objects compiled with -flto (and remove all assembly code from such libraries). The plugin interface was designed to provide this essential information to the compiler about all the non-LTO code; until Gnu ld implements this or the collect2 interface provides something similar, you're simply working with an incomplete implementation, and you'll have to live with the limitations. -cary
Re: Issue with LTO/-fwhole-program
On 06/11/2010 03:26 PM, Jan Hubicka wrote: Ah, so the problem is the missing -flto in the second compilation step? I think this is a bug in the compiler for not reporting this somehow. Is there are PR open for this? Compiler can not report it because it does not see the other object files. It is really up to user to understand -fwhole-program and mark externally visible symbols. Your testcase is quite ugly in a way that it leads to miscopmilation rather than linktime error, but there is not much we can do about it I guess. Perhaps we can somehow poison the object names that are brought local with -fwhole-program so linking explode, but I am not sure there is way to do so. Define a common object of unreasonable size and -fgc-sections? Paolo
Re: Scheduling x86 dispatch windows
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz d...@codesourcery.com wrote: On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote: [snip] Does this qualify as a form of what you are suggesting? Because this is exactly what is being proposed: .balign 8 # start window insn op, op # 67 67 XX YY ZZ - padded with 2 prefixes to make 8 insn2 op, op # AA BB CC .padalign 8 # window boundary insn4 op . . . No, this is quite different. These are directives that tell the assembler to make changes. I'm talking about assertions, not directives. Something like this: mov r0, r1 @ [length 2] add ip, lr, ip @ [length 4] mov r0, r1 @ [length 4] -- assembler error 'insn has length 2' GCC can output length information, but it is never exact, and it is not in a form recognized by the assembler. On x86, I have no idea how this would work. -- Daniel Jacobowitz CodeSourcery I see. Currently GCC doesn't compute the current encoding offset (doesn't know mnemonic/opcode lengths), nor does it perform a relaxation pass (to resolve forward displacement/branch offsets). Without these it so cannot accurately formulate such assertions. Our proposal is to let the assembler itself (knowing best the details of the encoding stream, offsets, and the processor) aligns instructions, with hints about the structure (block starts, ends, instruction sets) using macros/assertions/tokens if needed. Another option would be to expose some subset of the assembler functionality as a plugin to GCC (similar to how gold is used) to extract the instruction sizes. Any comments on that approach? -- Quentin Neill
Re: Scheduling x86 dispatch windows
On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill quentin.neill@gmail.com wrote: On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz d...@codesourcery.com wrote: On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote: [snip] Does this qualify as a form of what you are suggesting? Because this is exactly what is being proposed: .balign 8 # start window insn op, op # 67 67 XX YY ZZ - padded with 2 prefixes to make 8 insn2 op, op # AA BB CC .padalign 8 # window boundary insn4 op . . . No, this is quite different. These are directives that tell the assembler to make changes. I'm talking about assertions, not directives. Something like this: mov r0, r1 @ [length 2] add ip, lr, ip @ [length 4] mov r0, r1 @ [length 4] -- assembler error 'insn has length 2' GCC can output length information, but it is never exact, and it is not in a form recognized by the assembler. On x86, I have no idea how this would work. -- Daniel Jacobowitz CodeSourcery I see. Currently GCC doesn't compute the current encoding offset (doesn't know mnemonic/opcode lengths), nor does it perform a relaxation pass (to resolve forward displacement/branch offsets). Without these it so cannot accurately formulate such assertions. Our proposal is to let the assembler itself (knowing best the details of the encoding stream, offsets, and the processor) aligns instructions, with hints about the structure (block starts, ends, instruction sets) using macros/assertions/tokens if needed. Another option would be to expose some subset of the assembler functionality as a plugin to GCC (similar to how gold is used) to extract the instruction sizes. Any comments on that approach? I would suggest generating object code directly, totally bypassing assembler. Many compilers do it. But it is a HUGE effort. -- H.J.
Re: Scheduling x86 dispatch windows
On Fri, Jun 11, 2010 at 02:09:33PM -0500, Quentin Neill wrote: Currently GCC doesn't compute the current encoding offset (doesn't know mnemonic/opcode lengths), That's not true, gcc for i?86/x86_64 actually calculates the length and for most of the commonly used insns correctly, I've spent some time fixing various bugs in it a year ago, see http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01808.html and the thread around it. Many of the remaining few issues (haven't tested bdver ISA additions for lengths) are fixable too, of course there is always inline asm where GCC can't know. Jakub
Re: Issue with LTO/-fwhole-program
On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote: But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. It's not only correct, it's essential. Whole Program doesn't mean that the compiler has to see all the IR for the whole program. Instead, the compiler has visibility over the whole program in the sense that it knows what variables and functions are referenced and defined by the non-LTO code. Linking your program with non-LTO code is inescapable unless we start shipping language and system libraries as archives of objects compiled with -flto (and remove all assembly code from such libraries). The plugin interface was designed to provide this essential information to the compiler about all the non-LTO code; until Gnu ld implements this or the collect2 interface provides something similar, you're simply working with an incomplete implementation, and you'll have to live with the limitations. This also means that linking your program with non-LTO+whole-program code may lead to miscompilations without any warning, which is really bad. I don't think it is a reasonable limitation and we will get bad press when programs start breaking for users. They won't care (and they won't even listen) about the reasons. The conclusion will be: LTO is broken in GCC, and just use another compiler. Manuel.
Re: Issue with LTO/-fwhole-program
On 11 June 2010 21:41, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote: But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. The plugin interface was designed to provide this essential information to the compiler about all the non-LTO code; until Gnu ld implements this or the collect2 interface provides something similar, you're simply working with an incomplete implementation, and you'll have to live with the limitations. Personally, I rather have GCC warn every time that using LTO (or any other option) may lead to miscompilation than find out later that my program is behaving strange. A warning is a limitation I can live with. Wrong results from perfectly valid programs, not so nice. Manuel.
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 12:50 PM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 11 June 2010 21:41, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote: But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. The plugin interface was designed to provide this essential information to the compiler about all the non-LTO code; until Gnu ld implements this or the collect2 interface provides something similar, you're simply working with an incomplete implementation, and you'll have to live with the limitations. Personally, I rather have GCC warn every time that using LTO (or any other option) may lead to miscompilation than find out later that my program is behaving strange. A warning is a limitation I can live with. Wrong results from perfectly valid programs, not so nice. What about issue an error during the final link when linker plugin is required for correctness, but not used? -- H.J.
Re: Issue with LTO/-fwhole-program
Manuel López-Ibáñez lopeziba...@gmail.com writes: This also means that linking your program with non-LTO+whole-program code may lead to miscompilations without any warning, which is really bad. I don't think it is a reasonable limitation and we will get bad press when programs start breaking for users. They won't care (and they won't even listen) about the reasons. The conclusion will be: LTO is broken in GCC, and just use another compiler. The limitation isn't all that bad. If you want to use -fwhole-program, I think the basic rule is this: compile all your code with -flto, and don't define variables or functions which are referenced by any code which is not yours. I think adding a warning for this case would be great, if we can figure out how to do it. But I also think that a clear statement in the documentation will avoid most user problems. Ian
Re: Scheduling x86 dispatch windows
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu hjl.to...@gmail.com wrote: [snip] x86 assembler isn't an optimizing assembler. -mtune only does instruction selection. What you are proposing sounds like an optimizing assembler to me. Are we going to support scheduling, macro, ...? -- H.J. Just to clarify, we are not doing scheduling or macros. The assembler already supported alignment and padding using .align and friends, which can be from the compiler and from hand-written assembly. Now we are seeing more complex alignment rules that are not as simple as it used to be for the older hardware. It will be almost impossible for an assembly programmer to insert the right directives, not to mention any change might invalidate previous alignments. Assembly programmers will be out of luck (that is, unless the compiler becomes the assembler). The essence is we want to insert prefixes (as well as nops) according to certain rules known at encoding time. The mechanism implementing these rules can be abstracted (table driven?) and could be applicable to any hardware having similar features. As gcc does not currently encode and/or generate object code, we are wary of introducing such assembler functionality and want to avoid if possible, instead leveraging the existing binutils infrastructure. -- Quentin Neill (with some input from Reza Yazdani)
Re: Issue with LTO/-fwhole-program
On Fri, Jun 11, 2010 at 9:41 PM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 11 June 2010 20:48, Cary Coutant ccout...@google.com wrote: But if I understand correctly, mixed LTO/non-LTO + whole-program is almost never correct. So we should really emit a warning for this specific combination. I think making this mistake would be quite easy but hard to debug. It's not only correct, it's essential. Whole Program doesn't mean that the compiler has to see all the IR for the whole program. Instead, the compiler has visibility over the whole program in the sense that it knows what variables and functions are referenced and defined by the non-LTO code. Linking your program with non-LTO code is inescapable unless we start shipping language and system libraries as archives of objects compiled with -flto (and remove all assembly code from such libraries). The plugin interface was designed to provide this essential information to the compiler about all the non-LTO code; until Gnu ld implements this or the collect2 interface provides something similar, you're simply working with an incomplete implementation, and you'll have to live with the limitations. This also means that linking your program with non-LTO+whole-program code may lead to miscompilations without any warning, which is really bad. I don't think it is a reasonable limitation and we will get bad press when programs start breaking for users. They won't care (and they won't even listen) about the reasons. The conclusion will be: LTO is broken in GCC, and just use another compiler. Thank you for this piece of FUD. Richard.
ld linking behaviour
All, When I link with a shared library, for example: env LD_RUN_PATH=/usr/lib /usr/bin/gcc -shared -fPIC -L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib /usr/lib/libconfig.so the ld command follows the version, and links to the specific version of the library, not the library itself. An ldd dump shows : prompt% ldd blib/arch/auto/Conf/Libconfig/Libconfig.so linux-gate.so.1 = (0xe000) libconfig.so.8 = /usr/lib/libconfig.so.8 (0xf7fe2000) libc.so.6 = /lib/tls/libc.so.6 (0xf7eb7000) /lib/ld-linux.so.2 (0x56555000) How can I make it so that the ld command instead links to the libconfig.so library itself (so that if a newer, binary compatible, version of libconfig comes out it can use it transparently)? I can do: env LD_PRELOAD=/usr/lib/libconfig.so ldd blib/arch/auto/Conf/Libconfig/Libconfig.so and get the desired result, but I'd rather not deal with extra environment settings.. Thanks much, Ed
Re: ld linking behaviour
Edward Peschko horo...@gmail.com writes: When I link with a shared library, for example: env LD_RUN_PATH=/usr/lib /usr/bin/gcc -shared -fPIC -L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib /usr/lib/libconfig.so the ld command follows the version, and links to the specific version of the library, not the library itself. An ldd dump shows : prompt% ldd blib/arch/auto/Conf/Libconfig/Libconfig.so linux-gate.so.1 = (0xe000) libconfig.so.8 = /usr/lib/libconfig.so.8 (0xf7fe2000) libc.so.6 = /lib/tls/libc.so.6 (0xf7eb7000) /lib/ld-linux.so.2 (0x56555000) How can I make it so that the ld command instead links to the libconfig.so library itself (so that if a newer, binary compatible, version of libconfig comes out it can use it transparently)? The version number that you see there comes from the DT_SONAME dynamic tag in the library. By convention, all binary compatible versions of libconfig.so.8 will have an SONAME of libconfig.so.8. This is normally implemented by providing a series of libraries libconfig.so.8.1, libconfig.so.8.2, etc., with a symlink libconfig.so.8 to the most recent one. Then, if there is a binary incompatible change, the new symlink will be libconfig.so.9. So, if libconfig.so.8 follows this pattern, you do not want to do what you are asking. If libconfig.so.8 does not follow this pattern, then they should not use a DT_SONAME tag. In short, this is not a change which should be made in the linker. Ian
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- Comment #1 from Denis dot Excoffier at airbus dot com 2010-06-11 08:05 --- The same applies to mpfr-3.0.0 (now official). The MPFR people have however added the following note in ./INSTALL: As gmp-impl.h and longlong.h are only in the GMP source directory, you first need to copy these files to the build directory if it is different (there may be other workarounds, such as setting $CPPFLAGS to search the GMP source directory). This may be a better workaround than the one i proposed first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug testsuite/25763] objc.dg/stubify-*.m, and obj-c++.dg/stubify-*.mm fail on i686-darwin
--- Comment #5 from iains at gcc dot gnu dot org 2010-06-11 08:32 --- closing as fixed after back-porting to the 4.5 release branch at r160482 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25763
[Bug libgomp/42828] OpenMP executes unreliably when used in pthread.
--- Comment #2 from iains at gcc dot gnu dot org 2010-06-11 08:36 --- is this now fixed? in 4.5 after r160526, and trunk after r160457 which should have made the detection of emulated TLS more reliable. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42828
[Bug libgomp/42829] TLS detection in ./configure is wrong.
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 08:37 --- closing as fixed by r160457 (trunk) and r160526 (4.5 release branch) -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42829
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #77 from iains at gcc dot gnu dot org 2010-06-11 08:38 --- no new issues having been reported by the regression testers, closing this as fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug fortran/32203] Support the vendor intrinsic function TIMEF
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-06-11 08:43 --- I remember discussing that a long while back, and I don't think people had strong opinions. WONTFIX seems good. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32203
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #17 from iains at gcc dot gnu dot org 2010-06-11 08:57 --- closing as fixed after back-ports to the current release branch (4.5) for various ObjC fixes including the ones listed here: r160482, r160541, r160546 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug c++/44499] New: No default constructor available
The following code:
class C {
};
class D : public C {
};
const D g_d;
fails to compile on trunk (rev. 160489) with the following message:
$ g++ test.cpp
test.cpp:11:9: error: uninitialized const 'g_d' [-fpermissive]
test.cpp:6:11: note: 'const class D' has no user-provided default constructor
--
Summary: No default constructor available
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 09:10 --- @r160568 (or earlier) this is no longer showing. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug c++/44499] No default constructor available
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-11 09:26 --- gcc is correct, accepting the code previously was a bug that was fixed recently You need to provide an initializer for g_d -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-11 10:27 --- A question: apart from quoting chapter and verse from the standard (8.5 [dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have been any clearer? It indicates you can use -fpermissive to relax the warning, and it includes a note telling you the type has no user-provided default constructor, which is true. Why would you assume this is a bug, when a developer has gone to the trouble of writing the note? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44500] New: Bogus narrowing conversion error
Compiling with g++ -std=c++0x, using gcc-4.5.0 :
struct A {
char x;
};
templatechar C void f() {
char y = 42;
A a = { y+C };
}
int main() {
f1();
}
yields an error: narrowing conversion of â(((int)y) + 8)â from âintâ
to âcharâ inside { }.
If I change the template parameter type from char C to int C the error
message persists, this seems wrong too, but I am not quite shre.
If I leave out the y, everything is fine.
--
Summary: Bogus narrowing conversion error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gpiez at web dot de
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug tree-optimization/44493] [4.6 Regression] ACATS cxg1004 unhandled expression in get_expr_operands at tree-ssa-operands.c:1020
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:47 --- Reduced testcase at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00131.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|ada |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 10:47:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44493
[Bug target/44494] [4.6 regression] Several SPARC testcases fail: invalid args to cas*
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:48 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 10:48:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44494
[Bug debug/42648] [4.5/4.6 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n 0
--- Comment #9 from aoliva at gcc dot gnu dot org 2010-06-11 10:49 --- Steve, lto and whopr seem to have been introduced in a way that broke VTA. This is not ia64-specific, and it's not what this bug is about. I guess what you're seeing are other cases of lossage, that we might have to look into, but it's better to open separate bugs for them, to avoid confusing the issue further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
[Bug c++/44499] No default constructor available
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-11 10:53 --- (In reply to comment #1) gcc is correct, accepting the code previously was a bug that was fixed recently You need to provide an initializer for g_d This sort of changes should be documented in the changes.html page or in porting_to.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-11 10:57 --- I wonder what the C++ standard said because we have the same issue in Wconversion and Joseph rejected my patch arguing that the operation was done in the larger type, so there was a narrowing conversion. I still believe that we should not warn for T = T op T, when T is the same type all the time. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c++/44499] No default constructor available
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-06-11 11:01 --- (In reply to comment #2) A question: apart from quoting chapter and verse from the standard (8.5 [dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have been any clearer? It indicates you can use -fpermissive to relax the warning, and it includes a note telling you the type has no user-provided default constructor, which is true. Why would you assume this is a bug, when a developer has gone to the trouble of writing the note? All the compilers I am aware of accept the aforementioned construction, so I blindly assumed that 4.6 is wrong in issuing a warning. The note's content was considered irrelevant, since no error was expected. But if the behaviour is OK, then it is OK no matter what a surprise it turns out to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-11 11:11 --- Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2 Copyright 1988-2008 Comeau Computing. All rights reserved. MODE:strict errors C++ C++0x_extensions ComeauTest.c, line 9: error: const variable g_d requires an initializer -- class D has no explicitly declared default constructor const D g_d; ^ ComeauTest.c, line 9: warning: variable g_d was declared but never referenced const D g_d; ^ 1 error detected in the compilation of ComeauTest.c. I think the error message of comeau is better (but our note is better). I will write a patch. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
-- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 11:11:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-11 11:13 --- LLVM is still using GCC in their demo, not Clang. So I cannot test their output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #2 from gpiez at web dot de 2010-06-11 11:34 ---
Sorry for the unicode mess. The error message is 'error: narrowing conversion
of (((int)y) + 1) from int to char inside { }'.
The same error happens with a non templated function, but if I use two template
parameters, the error disappears, even if they are to large. So this is at
least very inconsistent.
no error:
struct A {
--char x;
};
templatechar C, char Dvoid f() {
--A a = { C+D };
}
int main() {
--f1,2();
}
still no error:
struct A {
--char x;
};
templateint C, int Dvoid f() {
--A a = { C+D };
}
int main() {
--f1,2();
}
error:
struct A {
--char x;
};
void f(char C, char D) {
--A a = { C+D };
}
int main() {
--f(1,2);
}
I believe I should not get an error, even if the template parameter type is
larger than a char, as long as the template parameter value fits in in char, so
templateint C void f() {
char y = 42;
A a = { y+C };
}
should give no error, as long as C fits in a char. IMHO ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-11 11:37 --- 'y' and 'C' are both promoted to int and 'y' is not a constant, so the resulting value cannot be proven to fit in a char, so it's a narrowing conversion. If you make 'y' a const int then the value y+C is a constant and can be proven not to narrow. The fact that the optimiser knows y=42 is irrelevant, the language specifies that y is not a constant, and whether the code is valid or not has to be independent of optimisations such as value propagation. I think gcc is correct here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-11 11:42 ---
(In reply to comment #2)
Sorry for the unicode mess. The error I believe I should not get an error,
even if the template parameter type is
larger than a char, as long as the template parameter value fits in in char,
so
templateint C void f() {
char y = 42;
A a = { y+C };
}
should give no error, as long as C fits in a char. IMHO ;-)
Just to be extra clear: C is a constant and the narrowing is *not* due to C,
consider:
struct A {
char x;
};
templateint C void f() {
A a = { C };
}
int main() {
f1();
}
Here C is an int, but it's a constant and it is provable that no narrowing
takes palce.
The problem in your example is 'y' not 'C' because the value of 'y' is not a
constant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug debug/43222] two DEBUG i = 0 generated after loop copy header
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-06-11 11:45 --- Not a bug -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222
[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries
--- Comment #10 from ro at gcc dot gnu dot org 2010-06-11 11:46 --- Subject: Bug 44216 Author: ro Date: Fri Jun 11 11:45:59 2010 New Revision: 160602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160602 Log: Backport from mainline: 2010-05-25 Rainer Orth r...@cebitec.uni-bielefeld.de PR libgcj/44216 * configure.ac (libgcj_cv_exidx): Enable AC_LANG_WERROR. Save and restore werror flag. * configure: Regenerate. Modified: branches/gcc-4_5-branch/libjava/ChangeLog branches/gcc-4_5-branch/libjava/configure branches/gcc-4_5-branch/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44216
[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries
--- Comment #11 from ro at gcc dot gnu dot org 2010-06-11 11:49 --- Subject: Bug 44216 Author: ro Date: Fri Jun 11 11:49:16 2010 New Revision: 160603 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160603 Log: config: * override.m4 (AC_LANG_WERROR): Redefine to autoconf 2.62 version. libjava: Backport from mainline: 2010-05-25 Rainer Orth r...@cebitec.uni-bielefeld.de PR libgcj/44216 * configure.ac (libgcj_cv_exidx): Enable AC_LANG_WERROR. Save and restore werror flag. * configure: Regenerate. Modified: branches/gcc-4_4-branch/config/ChangeLog branches/gcc-4_4-branch/config/override.m4 branches/gcc-4_4-branch/libjava/ChangeLog branches/gcc-4_4-branch/libjava/configure branches/gcc-4_4-branch/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44216
[Bug fortran/44497] [4.6 Regression] gfortran.dg/maxlocval_2.f90
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
[Bug libgomp/44498] [4.6 Regression] Many libgomp failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44498
[Bug java/44495] [4.6 regression] ICE in java_mangle_resource_name, at java/mangle.c:658
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44495
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #5 from gpiez at web dot de 2010-06-11 12:09 --- So is it provable that for a T op T to be stored in T no narrowing takes place? If the answer for T == char is no and for T == int it is yes this is rather fishy ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug tree-optimization/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug tree-optimization/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 --- Created an attachment (id=20887) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20887action=view) Patch that fixes the problem Here's the patch I'm testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug tree-optimization/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 --- *** Bug 44247 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug middle-end/44247] -fcompare-debug failure with -O1 -fgraphite-identity
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 --- The patch for bug 44181 fixes this one as well. *** This bug has been marked as a duplicate of 44181 *** -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44247
[Bug fortran/44497] [4.6 Regression] gfortran.dg/maxlocval_2.f90
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-11 12:43 --- (In reply to comment #2) It could be a dup of PR 44498. It if does not turn out to be a dup of the bitmap work / PR 44498, we need a backtrace or valgrind trace (with minimal options, e.g. -O0 if possible). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-11 12:51 ---
(In reply to comment #5)
So is it provable that for a T op T to be stored in T no narrowing takes
place?
Yes, if the values are constants.
If the answer for T == char is no and for T == int it is yes this is rather
fishy ;-)
That's not what I said. Look:
#include climits
struct A {
char x;
};
templatechar C, char D void f() {
A a = { C+D };
}
templateint I, int J void g() {
A a = { I+J };
}
int main() {
f1, 1();// OK
g1, 1();// OK
fCHAR_MAX, CHAR_MAX(); // Error
}
f1,1() is ok, because C and D are constants. The type doesn't matter, the
result of C+D is known at compile time and fits in a char.
g1,1() is ok, because I and J are constants. The type doesn't matter, the
result of I+J is known at compile time and fits in a char.
fCHAR_MAX, CHAR_MAX() is not ok, because the result is known at compile time
and doesn't fit in a char.
See 8.5.4 [dcl.init.list]p6 in teh C++0x draft for the full rules
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug debug/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 --- *** Bug 43650 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug tree-optimization/43650] -fcompare-debug failure with -O2 -fpeel-loops -fgraphite-identity
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 --- Unlike PR43656, this one is also fixed by the patch proposed for PR44181. *** This bug has been marked as a duplicate of 44181 *** -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43650
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-11 13:07 ---
He is referring to a testcase like:
templatetypename T, T C void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
fint,1();
fchar,1();
}
So, we warn for T == char but not for T == int. I know that the standard
considers differently narrowing and overflow but the difference is still
surprising.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug fortran/30677] Intrinsics arguments evaluated multiple times
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-02 08:00:41 |2010-06-11 13:17:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30677
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-11 13:20 ---
(In reply to comment #7)
He is referring to a testcase like:
templatetypename T, T C void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
fint,1();
fchar,1();
}
So, we warn for T == char but not for T == int. I know that the standard
Note it's not a warning, it's an error, mandated by the standard.
considers differently narrowing and overflow but the difference is still
surprising.
In both cases, T+T has type int, so obviously it fits in an int. It doesn't
necessarily fit in an char, so is an error unless the values are constants and
the actual value can fit in a char.
This is mandated by the standard and the diagnostic is IMHO clear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- Comment #22 from jakub at gcc dot gnu dot org 2010-06-11 13:22 --- Created an attachment (id=20888) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20888action=view) gcc46-pr44492.patch Updated patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #20883|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug c/44501] New: Wrong register stored
Hello,
it seems if there is a bug in the avr 32 gcc compiler.
avr32-gcc: version 4.3.2
toolchain: avr32-gnu-toolchain-2.4.2-setup.exe
avr32studio: avr32studio-ide-installer-2.5.0.35-win32.win32.x86.exe
Both got from www.atmel.com
Device: UC3B0256
Compilerflags: -O2 -g2 -mpart=uc3b0256
When compiling the atached example whith optimation O2 the line:
telegramm[10] = 1;
won't be translated right.
In the listfile I see, that the wrong register will be stored to
telegramm[10].
Listfile:
telegramm[10] = 1;
811a: 30 1a mov r10,1
void test_func(u8_t port)
{
u8_t *telegramm = test_str[port].telegramm_tx;
telegramm[6] = 33;
811c: b8 e9 st.b r12[0x6],r9
telegramm[10] = 1;
811e: f9 68 00 0a st.b r12[10],r8
It will store r8 instead of r10, which has got the 1.
I don't know if you coult help me, because the gcc ported from Atmel?
I have attached the test code, the listfile and the output of
avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.o main.c.
(hope I can attach them after commit)
--
Summary: Wrong register stored
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland dot cassebohm at dh-partner dot com
GCC host triplet: i686-pc-cygwin
GCC target triplet: avr32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #9 from gpiez at web dot de 2010-06-11 13:27 ---
I understand now after the implicit promotion to int of a non constant value
the result of the narrowing operation can't be guaranteed to fit in the
original type. But I still think it shouldn't give an error, and if the
standard says so, I think it is flawed in this regard ;-)
Consider
gINT_MAX, INT_MAX(); // Warning, but no Error
despite it can be proven that the value will not fit and this is very likely an
error. Opposing to
char c,d;
A a = { c+d };
which is very likely not an error and would only require a mild warning. IMHO.
Manuel, in your testcase, you do not only warn, you error out if compiled with
-std=c++0x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c/44501] Wrong register stored
--- Comment #1 from roland dot cassebohm at dh-partner dot com 2010-06-11 13:27 --- Created an attachment (id=20889) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20889action=view) Test program This file could be compiled alone with avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.o main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c/44501] Wrong register stored
--- Comment #2 from roland dot cassebohm at dh-partner dot com 2010-06-11 13:29 --- Created an attachment (id=20890) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20890action=view) Listfile with resulted assembler Generated with: avr32-objdump.exe -S main.o main.lst -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c/44501] Wrong register stored
--- Comment #3 from roland dot cassebohm at dh-partner dot com 2010-06-11 13:31 --- Created an attachment (id=20891) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20891action=view) gcc output Output of avr32-gcc by using: avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.o main.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-11 13:33 ---
(In reply to comment #8)
In both cases, T+T has type int,
We know that, but I don't think most C/C++ programmers know about integer
promotion rules. We just disagree here. But since this is mandated by the
standard, you are right.
so obviously it fits in an int. It doesn't
For a strict-standard definition of fits, because it may overflow and a
layman wouldn't say that it fits in that case.
This is mandated by the standard and the diagnostic is IMHO clear.
I am not arguing against that (although, I think it is unfortunate). I would
prefer a bit longer message:
error: C++0x does not allow narrowing conversion of (((int)y) + 1) from int
to char inside { }
(BTW, I think those braces should be within quotes).
But since I guess I am in the minority here, we'll have to close this as
INVALID.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug target/44501] Wrong register stored
-- roland dot cassebohm at dh-partner dot com changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:38 --- (In reply to comment #2) Still true for gcc version 4.6.0 20100509 (experimental) (GCC) I don't know if it's worth the extra work, but this can be tackled in gfc_conv_substring() by checking whether start.expr and end.expr refer to the same var_decl (stripping conversions). If they do, the length is one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
[Bug fortran/42042] Symbol __x86_64__ no longer defined?
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 13:46:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42042
