Re: GCC with formal testing docs
On Wed, Jul 25, 2007 at 02:29:26PM +1000, Ben Elliston wrote: > > If you build the compiler with coverage instrumentation and run the > testsuite, you might get a shock. It's not as well tested as you might > think. For example, several targets would build/bootstrap and regtest fine with reload's find_valid_class() implemented as gcc_abort(). And guess what, there seems to be an off-by-one error in the outer loop exit condition. -- Rask Ingemann Lambertsen
Re: dlopen() crash -gcc 3.4.6 20060404
On Thu, 2007-07-26 at 14:22 +0530, Gaurav Kheterpal wrote: > My apologies if this message doesn’t seem appropriate on this list. It's not appropriate for this list. This list is for discussing GCC development, not development with GCC. Cheers, Ben
Re: URGENT : elf_update - low performance with large files ? (fwd)
2007/7/26, Anitha Boyapati <[EMAIL PROTECTED]> wrote: Hello Pizarro, (hope I got the name correctly!). The central idea of patch is nice. Although it is obvious from the patch, just to say - you are printing out the elf data structure size by means of 'len' and the command mode Elf_Cmd 'cmd'. But I fail to understand the purpose of Elf * . It started off with some address and then went for another! The report quite clearly says the length is shooting off. I didnt have a heart to run it completely. Neverthless, I am not sure about attaching quite a big file after running it for 1 hour :-) I am giving a much more truncated version here - elf: 0x09DAD0D0 ; cmd_code: 2 len: 144 elf: 0x09DB9F40 ; cmd_code: 2 len: 208 elf: 0x09DB9F40 ; cmd_code: 0 len: 248 elf: 0x09DB9F40 ; cmd_code: 2 len: 272 elf: 0x09DB9F40 ; cmd_code: 0 len: 312 elf: 0x09DB9F40 ; cmd_code: 2 len: 336 elf: 0x09DB9F40 ; cmd_code: 0 len: 376 elf: 0x09DB9F40 ; cmd_code: 0 len: 412 elf: 0x09DB9F40 ; cmd_code: 2 len: 436 elf: 0x09DB9F40 ; cmd_code: 0 len: 476 elf: 0x09DB9F40 ; cmd_code: 0 len: 492 elf: 0x09DB9F40 ; cmd_code: 2 len: 516 ---> // After this no cmd_code = 2 is used elf: 0x09DB9F40 ; cmd_code: 0 len: 556 elf: 0x09DB9F40 ; cmd_code: 0 len: 572 elf: 0x09DB9F40 ; cmd_code: 0 len: 588 elf: 0x09DB9F40 ; cmd_code: 0 len: 604 elf: 0x09DB9F40 ; cmd_code: 0 len: 604 elf: 0x09DB9F40 ; cmd_code: 0 len: 604 elf: 0x09DB9F40 ; cmd_code: 0 len: 604 elf: 0x09DB9F40 ; cmd_code: 0 ... elf: 0x09DB9F40 ; cmd_code: 0 len: 218096 elf: 0x09DB9F40 ; cmd_code: 0 len: 218100 elf: 0x09DB9F40 ; cmd_code: 0 len: 218100 elf: 0x09DB9F40 ; cmd_code: 0 len: 218100 elf: 0x09DB9F40 ; cmd_code: 0 len: 218100 elf: 0x09DB9F40 ; cmd_code: 0 len: 218104 --> After 1 hour I am mostly a beginer to this elf thing. From the report above, I am not sure that I deduce anthing. Well my testcase is a series of .byte directives (its an image) Thanks for the response. Could you also throw some light on the findings -if any- from the above. On Wed, 25 Jul 2007, J.C. Pizarro wrote: > Patch it to investigate it a little bit more. > > After runned it, see "quickdirty.log" and post here your report's summary. > > ;) > -- Regards, Anitha B @S A N K H Y A 0 is ELF_C_NULL 1 is ELF_C_READ 2 is ELF_C_WRITE You can have an idea that the problem is not in the writing of files, but it's growing slow!!! No ELF_C_READ here!!!
Re: relocation truncated to fit
On 7/26/07, Canqun Yang <[EMAIL PROTECTED]> wrote:
Hi, all
Can anyone help me to resolve this problem?
When I compile a program with .bss segement larger than 2.0GB, I get the
following error message from GNU linker (binutils-2.15).
(.text+0x305): In function `sta_':
: relocation truncated to fit: R_X86_64_32S plot_
..
I upgrade the assembler and the linker from binutis-2.17, then get the
message below.
STA.o: In function `sta_':
STA.F:(.text+0x305): relocation truncated to fit: R_X86_64_32S against
symbol `plot_' defined in COMMON section in STA.o
So, I modified the binutils-2.17/bfd/elf64-x86-64.c and rebuild the linker
to ignore the relocation errors. Though the executable generated,
segementation fault occurred during execution.
Here is the configuration of my computer:
CPU: Intel(R) Xeon(R) CPU5150 @ 2.66GHz
OS: Linux mds 2.6.9-34.EL_lustre.1.4.6.1custom #3 SMP Fri Jul 13 15:27:27
CST 2007 x86_64 x86_64 x86_64 GNU/Linux
Compiler: Intel C++/Fortran compiler for linux 10.0
I also wrote a program with large uninitialized data -- more than 2.0GB.
It passes after linked with the modified linker. The source code is appended.
Try using -mcmodel=medium
Richard.
#define N 0x05fff
double a[N][N];
int
main ()
{
int i, j;
double sum;
for (i = 0; i < N; i+=5)
for (j = 0; j < N; j+=5)
a[i][j] = 2* i*j + i*i + j*j;
sum = 0.0;
for (i = 0; i < N; i+=5)
for (j = 0; j < N; j+=5)
sum += a[i][j];
printf ("%f\n", sum);
}
Best regards,
Canqun Yang
___
抢注雅虎免费邮箱3.5G容量，20M附件！
http://cn.mail.yahoo.com
relocation truncated to fit
Hi, all
Can anyone help me to resolve this problem?
When I compile a program with .bss segement larger than 2.0GB, I get the
following error message from GNU linker (binutils-2.15).
(.text+0x305): In function `sta_':
: relocation truncated to fit: R_X86_64_32S plot_
..
I upgrade the assembler and the linker from binutis-2.17, then get the
message below.
STA.o: In function `sta_':
STA.F:(.text+0x305): relocation truncated to fit: R_X86_64_32S against
symbol `plot_' defined in COMMON section in STA.o
So, I modified the binutils-2.17/bfd/elf64-x86-64.c and rebuild the linker
to ignore the relocation errors. Though the executable generated,
segementation fault occurred during execution.
Here is the configuration of my computer:
CPU: Intel(R) Xeon(R) CPU5150 @ 2.66GHz
OS: Linux mds 2.6.9-34.EL_lustre.1.4.6.1custom #3 SMP Fri Jul 13 15:27:27
CST 2007 x86_64 x86_64 x86_64 GNU/Linux
Compiler: Intel C++/Fortran compiler for linux 10.0
I also wrote a program with large uninitialized data -- more than 2.0GB.
It passes after linked with the modified linker. The source code is appended.
#define N 0x05fff
double a[N][N];
int
main ()
{
int i, j;
double sum;
for (i = 0; i < N; i+=5)
for (j = 0; j < N; j+=5)
a[i][j] = 2* i*j + i*i + j*j;
sum = 0.0;
for (i = 0; i < N; i+=5)
for (j = 0; j < N; j+=5)
sum += a[i][j];
printf ("%f\n", sum);
}
Best regards,
Canqun Yang
___
抢注雅虎免费邮箱3.5G容量，20M附件！
http://cn.mail.yahoo.com
Re: dlopen() crash -gcc 3.4.6 20060404
Hi,
On a quick look ---
>
> My apologies if this message doesnt seem appropriate on this list.
gcc-help list is appropriate for such issues.
> _handle = dlopen( "./libchrcv.so", RTLD_NOW | RTLD_GLOBAL );
Have you tried with any other library or only this ? I tried the entire
program with a small testcase. It appears to be running *fine* which
says any deviation (like segmentation fault) should be because of
libchrcv.so only.
Ofcourse I am assuming you compiled and linked well taking -ldl into
consideration and that you have defined LD_LIBRARY_PATH clearly without
which your program will not run at all.
Core dump file shows that libchrcv.so has relocation dependencies on
other modules. You might want to concentrate on those issues and check
your build options.
Btwn, use plain text format.
> if ( 0 == _handle )
> {
> printf("ShareableContentHandler::Load() - dlopen failed
> '%s'.\n", dlerror() );
> }
> else
> {
> printf("ShareableContentHandler::Load() - dlopen success
> '%s'.\n", dlerror() );
> }
> return 0;
> }
>
> libchrcv.so is a shared library which in turn links against 2 libraries
> librcvagent.so and libcontrolagent.so. I verified that both these .so files
> are present in the path specified in LD_LIBRARY_PATH.
>
> I compile this program using gcc test.c ldl & it compiles & links fine.
> However, when I execute it, I get a segmentation fault. The output is:-
>
> Starting now !!!
> Segmentation fault
>
> There is no core file generated. I capture the LD_DEBUG output & it is
> attached for reference.
>
> Ill be thankful if somebody can look at the attached file & guide me on
> what the problem is.
>
> Thanks in advance.
>
> Regards,
> Gaurav.
>
>
>
--
Regards,
Anitha B
@S A N K H Y A
Re: Enabling gcc optimization pass
Rohit Arul Raj wrote:
Hi all,
I have 3 functions- fun1, fun2, fun3 in the same source file and i
want to enable one or any of the gcc optimization pass to code in fun2
only,
1. Is it possible to implement this using function attributes or #pragms's?
I believe that currently, tuning optimisation levels at a function granularity (or perhaps even smaller, like blocks) is
impossible in current GCC. I heard at the GCC summit (18th july 2007 at Ottawa) that it would be a desirable feature,
but I am not sure that someone is actively working on it.
So currently, the answer seems to be no.
I believe that currently, tuning optimisation levels at a function granularity (or perhaps even smaller, like blocks) is
impossible in current GCC. I heard at the GCC summit (18th july 2007 at Ottawa) that it would be a desirable feature,
but I am not sure that someone is actively working on it.
2. What will be its side-effects?
Apparently, one of the issues is that some optimising passes (or their combination) rely on some global variable, so it
is not a trivial job to tune optimisations at the function level.
But I may be wrong on both points.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: C++ ABI: name mangling of operator new [bug 6057]
Richard Smith <[EMAIL PROTECTED]> writes:
| About five years ago, I reported a bug about an ICE when
| trying to mangle expressions involving operator new.
|
| http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
|
| A three line example exhibiting the ICE is:
|
| template struct helper {};
| template void check( helper* );
| int main() { check(0); }
|
| As I understand it, the reason that this has never been
| fixed is that a full fix requires either an extension/change
| to the ABI which presumably requires collaboration between
| the eight organisations that produced it.
|
| I'm wondering whether there's any prospect of this
| happening, and if not, whether GCC should use the vendor
| extension syntax (v ) to provide a fix?
|
| As it stands, the ABI's definition of mangling a new
| expression makes no sense as it has no way of folding the
| type into the mangled name. (It doesn't even say whether
| operator new is to be regarded as a unary operator, per the
| C++ standard, or binary or ternary. In terms of the
| information needed in the mangled name, it should be ternary
| as there are placement arguments, the type, and constructor
| arguments.)
|
| Although the bug only manifests in fairly arcane code, it
| can nevertheless occur in legal code: I've generally
| encountered it when developing type traits using template
| metaprogramming.
We discussed that issue again at that last ISO C++ meeting
in Toronto.
(1) while people usually refer to name mangling as a "blocking"
issue, it appears to me as bogus: Nowhere the C++ standard
talks of "name mangling".
(2) it is generally accepted in the ISO C++ Core Working sub-Group
that compiler writers will have to mangle general expressions.
(3) the real issue is deeper: during template argument deduction
and template instantiation, define what is a "hard error" and
what is "substitution failure is not error". The line is not
as clear cut as one might believe at fist sight.
(4) the record of the ISO C++ Core Issue #339 is not up-to-date and
does not reflect the current thinking of the CWG.
Finally, at the last meeting, I made the claim that if the
implementation detail issue (name mangling) is solved then, all of the
examples discussed so far in the record of the CWG issue #339 are
handled fine by GCC/g++ as of today -- with no modification to the
template or overload machinery. On Wednesday July 18, 2007 I brought
factual evidence to that claim by showing g++ behaviour on all of the
examples discussed (including those from the "decltype" proposal).
(All I did was to encode call expressions, new expressions and a few
other tree nodes).
Note also that GCC/g++ will not encode __typeof, but it would encode
__alignof -- which is a plain bug, not to be lumped with issue 339.
-- Gaby
Re: RFC: Rename Non-Autpoiesis maintainers category
On Thu, 26 Jul 2007, Diego Novillo wrote: > I've always found the term Non-Autopoiesis too pretentious and > unnecessarily complex. In a recent thread, Tobias Schluter proposed > Non-autonomous, which is at least more readily understandable. Disclaimer: I am writing this in my capacity as non-native speaker, not as SC member or doc maintainer. ;-) To me "non-autonomous" has connotations of being a child, or ill, or fragile. Unfortunately, I do not really have an alternate grand proposal. Some- thing like "Not self-approving Maintainers" or "Non-self-...", perhaps? > Is anyone violently opposed to changing the category name? Not so, though. Gerald
Re: GCC with formal testing docs
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: > On Wed, Jul 25, 2007 at 02:29:26PM +1000, Ben Elliston wrote: > > > > If you build the compiler with coverage instrumentation and run the > > testsuite, you might get a shock. It's not as well tested as you might > > think. > >For example, several targets would build/bootstrap and regtest fine with > reload's find_valid_class() implemented as gcc_abort(). And guess what, > there seems to be an off-by-one error in the outer loop exit condition. I think it is correct. According to the documentation in tm.texi, N_REG_CLASSES should always be one larger than the last valid register class. tm.texi does not require that NO_REGS == 0, so the loop is arguably wrong in that way. In practice all machine descriptions do define NO_REGS to be 0, and that should probably be documented as a requirement. Ian
Re: RFC: Rename Non-Autpoiesis maintainers category
> Diego Novillo writes: Diego> I've always found the term Non-Autopoiesis too pretentious and Diego> unnecessarily complex. In a recent thread, Tobias Schluter proposed Diego> Non-autonomous, which is at least more readily understandable. Diego> Would this patch be OK? Any other suggestions for a better category Diego> name? Is anyone violently opposed to changing the category name? Kenny discovered a different name, but he hasn't publicized the recommendation yet. I agree that non-autopoisis is too "cute". David
Re: GCC with formal testing docs
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> tm.texi does not require that NO_REGS == 0,
Um, yes? Unless you're assuming that the user could do NO_REGS=5 or
something in the enum, so that the enum starts with something other
than zero? If that's what you're thinking, perhaps we should change
tm.texi to clarify that you shouldn't do that, but IMHO the
documentation implies that NO_REGS==0.
@deftp {Data type} {enum reg_class}
An enumerated type that must be defined with all the register class names
as enumerated values. @code{NO_REGS} must be first. @code{ALL_REGS}
must be the last register class, followed by one more enumerated value,
@code{LIM_REG_CLASSES}, which is not a register class but rather
tells how many classes there are.
Perhaps we could add ", and no numerical overrides" to the end of the
first sentence?
Re: RFC: Rename Non-Autpoiesis maintainers category
David Edelsohn wrote: >> Diego Novillo writes: >> > > Diego> I've always found the term Non-Autopoiesis too pretentious and > Diego> unnecessarily complex. In a recent thread, Tobias Schluter proposed > Diego> Non-autonomous, which is at least more readily understandable. > > Diego> Would this patch be OK? Any other suggestions for a better category > Diego> name? Is anyone violently opposed to changing the category name? > > Kenny discovered a different name, but he hasn't publicized the > recommendation yet. I agree that non-autopoisis is too "cute". > > David > > I really do not like the current name either, but i do not have a better one. diego's suggestion is ok. i guess it at least satisfies the criteria of being a well known word. kenny
Re: C++ ABI: name mangling of operator new [bug 6057]
Doug Gregor wrote:
> Now, we're saying that any expressions are valid in
> sizeof, decltype, and constant expressions. If those
> expressions fail to type-check during substitution, it
> will be a SFINAE case.
Just to be sure we're not talking at cross purposes, can I
check that the current thinking on DR 339 is that type
traits such as the following should be legal (and do the
obvious thing):
template
class is_default_constructible {
template struct helper {};
typedef char no; typedef char yes[2];
static no fn(...);
static yes fn( helper* );
public:
static const bool value = sizeof(fn(0)) == sizeof(yes);
};
If so, that's excellent news.
Richard Smith
Re: Creating gcc-newbies mailing list
David Daney <[EMAIL PROTECTED]> writes: > Between gcc@ and gcc-help@ I think we have it pretty much covered. I > have not really seen anyone flamed on gcc@ when they ask newbie type > questions related to GCC development. I think the risk is not so much that people get flamed, as that they get non-responsive answers. And people get discouraged from joining the community. I think it may help to have a list for people who would like to be developers where they can ask simple questions. I agree that some people turn to asking questions on gcc-help, where simple questions are treated more kindly. gcc-newbies may not be the best name, I don't know. Ian
Re: C++ ABI: name mangling of operator new [bug 6057]
Gabriel Dos Reis wrote:
> On Wednesday July 18, 2007 I brought factual evidence to
> that claim by showing g++ behaviour on all of the examples
> discussed (including those from the "decltype" proposal).
> (All I did was to encode call expressions, new expressions
> and a few other tree nodes).
I'm curious as to how this works with overloaded functions.
The general philosophy in the current ABI would seem to be
that the expression is encoded in terms of its template
parameters, and not with the evaluated expression with the
subsituted argument. That is, for
template void fn( A<-I> );
the specialisation fn<1> would be mangled as
_Z2fnILi1EEv1AIXngT_EE void fn( A<-I> ) [with I=1]
instead of, say,
_Z2fnILi1EEv1AILin1EEvoid fn( A<-1> ) [with I=1]
This has the result that all specialisations of this
template have the mangled form
_Z2fnI{parameters}Ev1AIXngT_EE
(I'm not convinced this is absolutely necessary, even though
it seems a good idea. The oft-quoted example is
template A fn(A, A);
template A fn(A, A);
and then setting I=J=0. If you substuted the arguments,
you'd get _Z2fnILi0ELi0EE1AILi0EES0_ILi0EES0_ILi0EE for
both. However, by my reading of 14.5.5.1, these are
functionally equivalent but not equivalent and thus render
the program ill-formed; no diagnostic required.)
However, the obvious strategy for dealing with overloaded
functions is to perform overload resolution and then mangle
the selected overload. For example, if we make up the
syntax
::= ...
::= cl
_
::= + _
to mangle a function call, and you could mangle the
call to the non-overloaded function, foo:
template int foo(T);
template A {};
template void bar( A );
The obvious strategy is to encode bar as (I think)
_Z3barIiLi42EEv1AIXszclL_Z3fooIiEiT_ET0__EE
where _Z3fooIiEiT_ is the result of subsituting T=int into
the definition of foo. But this means that the template
parameters of bar are repeated and all the specialisations
of bar no longer have the form
_Z3barI{parameters}Ev1AIXszclL_Z3fooIiEiT_ET0__EE
... because the 'i' from T=int is repeated. (Again, this is
only a problem if one wants to mangle two 'functionally
equivalent' overloads.) An alernative is to propagate bar's
parameter into foo's argument:
_Z3barIiLi42EEv1AIXszclL_Z3fooIT_EiT_ET0__EE
But then extending this to an overloaded function call of
foo looks very hard, as you no longer know the function is
being called when you want to mangle the expression
'foo(V)'. Effectively, you have a choice: mangle the whole
of the candidate set (or enough information to regenerate
it); or mangle the name after overload resolution and loose
the ability to mangle 'functionally equivalent' expressions
accurately. The latter sounds far easier, but is contrary
to the spirit of the existing ABI.
Richard Smith
Re: Creating gcc-newbies mailing list
Joe Buck <[EMAIL PROTECTED]> writes: > I think that when we do steer someone to a different list, we could > take more care to be polite about it than we sometimes are. I agree. I also think we should all try harder to avoid flippant or non-responsive replies to new developers. I think it's important for the long-term growth of gcc for us to encourage new developers. The gcc-newbies proposal was Diego's idea, but it was, of course, based on the kernelnewbies list (see http://kernelnewbies.org/). Is anybody here able to comment on whether kernelnewbies seems to be useful or not? Certainly the kernel community is much larger than the gcc community. Ian
Re: Creating gcc-newbies mailing list
On 7/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote: > >I would like to propose the creation a new mailing list: > >[EMAIL PROTECTED] > > > >The purpose of this list is to attract and help new GCC developers who > >might feel lost and intimidated by the more arcane traffic at gcc and > >gcc-patches. In this list, no question regarding GCC development should > >be considered offtopic nor treated with "RTFM" responses. On Thu, Jul 26, 2007 at 02:05:50PM -0700, Andrew Pinski wrote: > I think this is the wrong aproach. I have not seen any "RTFM" > response for questions of developing of GCC on the gcc@ list. Agreed. Also, I think that the charter that Diego describes sounds a lot like the charter for gcc-help. And since everyone will read "GCC development" as "development using GCC as the compiler" it would quickly become a general Linux/BSD/Unix/GNU tools questions list. What would go to gcc-help, and what to gcc-newbies? I think it's good enough what we have now. Also, I don't see the point in tossing junior or beginner gcc developers off of the main list. I think that when we do steer someone to a different list, we could take more care to be polite about it than we sometimes are.
Re: Creating gcc-newbies mailing list
Diego Novillo <[EMAIL PROTECTED]> writes: > I would like to propose the creation a new mailing list: > [EMAIL PROTECTED] "Hi! I'm new at gcc. How do I compile C programs? Can I use it to write video games?" > The purpose of this list is to attract and help new GCC developers "Oh, is that what this list is for? Sorry!"
[tuples] meaning of DECL_SAVED_TREE while analyzing cgraph
Hi Jan.
What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
/* ??? It is possible to create extern inline function and later using
weak alias attribute to kill its body. See
gcc.c-torture/compile/2009-1.c */
if (!DECL_SAVED_TREE (decl))
{
cgraph_reset_node (node);
continue;
}
gcc_assert (!node->analyzed && node->reachable);
gcc_assert (DECL_SAVED_TREE (decl));
It was my understanding that DECL_SAVED_TREE was to be cleared after the
tree optimizers executed, and Diego is explicitly killing it now right
after gimplification-- at the end of gimplify_function_tree:
/* The tree body of the function is no longer needed, replace it
with the new GIMPLE body. */
set_gimple_body (fndecl, seq);
DECL_SAVED_TREE (fndecl) = NULL_TREE;
I also thought that after the CFG was built, DECL_SAVED_TREE had nothing
of value left.
So, what do you expect it to have? Can we use something in the tuple
body now, or do you are you overloading DECL_SAVED_TREE for somthing
else? Also, the assertion of DECL_SAVED_TREE above is unecessary, since
you've already checked for a lack of it, and looped.
Please let me know.
Thanks.
Aldy
Re: GCC with formal testing docs
DJ Delorie <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > tm.texi does not require that NO_REGS == 0,
>
> Um, yes? Unless you're assuming that the user could do NO_REGS=5 or
> something in the enum, so that the enum starts with something other
> than zero? If that's what you're thinking, perhaps we should change
> tm.texi to clarify that you shouldn't do that, but IMHO the
> documentation implies that NO_REGS==0.
>
> @deftp {Data type} {enum reg_class}
> An enumerated type that must be defined with all the register class names
> as enumerated values. @code{NO_REGS} must be first. @code{ALL_REGS}
> must be the last register class, followed by one more enumerated value,
> @code{LIM_REG_CLASSES}, which is not a register class but rather
> tells how many classes there are.
>
> Perhaps we could add ", and no numerical overrides" to the end of the
> first sentence?
Oh, sorry, I missed that bit of the docs. I stopped at the definition
of NO_REGS, which is earlier in tm.texi. I think we are OK. Thanks.
Ian
RFC: Rename Non-Autpoiesis maintainers category
I've always found the term Non-Autopoiesis too pretentious and unnecessarily complex. In a recent thread, Tobias Schluter proposed Non-autonomous, which is at least more readily understandable. Would this patch be OK? Any other suggestions for a better category name? Is anyone violently opposed to changing the category name? Thanks. Index: ../MAINTAINERS === --- ../MAINTAINERS (revision 126951) +++ ../MAINTAINERS (working copy) @@ -231,7 +231,7 @@ maintainers need approval to check in algorithmic changes or changes outside of the parts of the compiler they maintain. - Non-Autopoiesis Maintainers + Non-Autonomous Maintainers dataflow Daniel Berlin [EMAIL PROTECTED] dataflow Paolo Bonzini [EMAIL PROTECTED] @@ -252,7 +252,7 @@ Note that individuals who maintain parts of the compiler as -non-autopoiesis maintainers need approval changes outside of the parts +non-autonomous maintainers need approval changes outside of the parts of the compiler they maintain and also need approval for their own patches.
Re: C++ ABI: name mangling of operator new [bug 6057]
Hi Richard,
On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
About five years ago, I reported a bug about an ICE when
trying to mangle expressions involving operator new.
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
A three line example exhibiting the ICE is:
template struct helper {};
template void check( helper* );
int main() { check(0); }
As I understand it, the reason that this has never been
fixed is that a full fix requires either an extension/change
to the ABI which presumably requires collaboration between
the eight organisations that produced it.
I'm wondering whether there's any prospect of this
happening, and if not, whether GCC should use the vendor
extension syntax (v ) to provide a fix?
This kind of thing came up that the last C++ committee meeting, as
part of core issue 339:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
Name mangling is part of the problem, but not all of it. There is also
the issue of what happens when there is an error in the expression
"new T": is it part of the Substitution Failure Is Not An Error
(SFINAE) rule, meaning that the function would not enter the overload
set, or does it trigger an error immediately? That's actually the more
complicated issue.
As for GCC... I think we realize that we do have to fix these
problems. That means we'll need name mangling for all of the
expressions (and will have to extend the C++ ABI for this; vendor
extensions would not be useful), and we'll have to update a lot of the
type-checking for expressions in the C++ front end to propagate and
obey tsubst_flags_t.
- Doug
C++ ABI: name mangling of operator new [bug 6057]
About five years ago, I reported a bug about an ICE when
trying to mangle expressions involving operator new.
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
A three line example exhibiting the ICE is:
template struct helper {};
template void check( helper* );
int main() { check(0); }
As I understand it, the reason that this has never been
fixed is that a full fix requires either an extension/change
to the ABI which presumably requires collaboration between
the eight organisations that produced it.
I'm wondering whether there's any prospect of this
happening, and if not, whether GCC should use the vendor
extension syntax (v ) to provide a fix?
As it stands, the ABI's definition of mangling a new
expression makes no sense as it has no way of folding the
type into the mangled name. (It doesn't even say whether
operator new is to be regarded as a unary operator, per the
C++ standard, or binary or ternary. In terms of the
information needed in the mangled name, it should be ternary
as there are placement arguments, the type, and constructor
arguments.)
Although the bug only manifests in fairly arcane code, it
can nevertheless occur in legal code: I've generally
encountered it when developing type traits using template
metaprogramming.
Richard Smith
Re: Enabling gcc optimization pass
On 26/07/07, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 7/26/07 9:55 AM, Diego Novillo wrote: > > On 7/26/07 8:21 AM, Basile STARYNKEVITCH wrote: > > > >> So currently, the answer seems to be no. > > > > Right. It's a cool future feature, but so far nobody seems to be > > working on it. > > I have to retract this. On IRC I was pointed to various efforts in the > area to which I was totally ignorant of. Sorry folks. > I think you are referring to http://gcc.gnu.org/wiki/Function_Level_Control_of_Optimizations aren't you? I think it is one of the projects that didn't meet stage1 for 4.3, so perhaps it will be ready for 4.4! Cheers, Manuel.
Re: Enabling gcc optimization pass
On 7/26/07 9:55 AM, Diego Novillo wrote: > On 7/26/07 8:21 AM, Basile STARYNKEVITCH wrote: > >> So currently, the answer seems to be no. > > Right. It's a cool future feature, but so far nobody seems to be > working on it. I have to retract this. On IRC I was pointed to various efforts in the area to which I was totally ignorant of. Sorry folks.
Re: Enabling gcc optimization pass
On 7/26/07 8:21 AM, Basile STARYNKEVITCH wrote: > So currently, the answer seems to be no. Right. It's a cool future feature, but so far nobody seems to be working on it. Implementing the optimization pragmas at a function level should not be too hard, though we may need to tweak the callgraph code and the IPA passes. We could then implement block-based optimization options by outlining the affected blocks. Though that may be counterproductive as we'd be introducing more call sites.
Re: Enabling gcc optimization pass
On 7/26/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
Rohit Arul Raj wrote:
> Hi all,
>
> I have 3 functions- fun1, fun2, fun3 in the same source file and i
> want to enable one or any of the gcc optimization pass to code in fun2
> only,
>
> 1. Is it possible to implement this using function attributes or #pragms's?
I believe that currently, tuning optimisation levels at a function granularity
(or perhaps even smaller, like blocks) is
impossible in current GCC. I heard at the GCC summit (18th july 2007 at Ottawa)
that it would be a desirable feature,
but I am not sure that someone is actively working on it.
So currently, the answer seems to be no.
>
As of now,
a) I have added target dependent function attributes for all
optimization levels in the backend.
b) In function execute_pass_list() i am having a condition check for
those function attributes, if a valid optimization level is given
as a function attribute, the global variable optimize and
optimize_size are overridden for the current function. For other
functions, the global variables are restored to their initial values.
For a simple case- fun1, fun2, fun3, i gave function attribute O1 to
fun2, while the other 2 functions optimization was not enabled. The
only difference i found was that IPA passes were not run, other than
that the code was optimized for fun2.
I am yet to check how it affects other cases.
Is there any other better way of implementing this?
> 2. What will be its side-effects?
Apparently, one of the issues is that some optimising passes (or their
combination) rely on some global variable, so it
is not a trivial job to tune optimisations at the function level.
But I may be wrong on both points.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Regards,
Rohit
RE: Enabling gcc optimization pass
On 26 July 2007 08:30, Rohit Arul Raj wrote: > Hi all, > > I have 3 functions- fun1, fun2, fun3 in the same source file and i > want to enable one or any of the gcc optimization pass to code in fun2 > only, > > 1. Is it possible to implement this using function attributes or #pragms's? Nope. > 2. What will be its side-effects? Non-existence! cheers, DaveK -- Can't think of a witty .sigline today
RE: GCC 4.2.1 : bootstrap fails at stage 2. Anyone know why ?
On 26 July 2007 03:09, Dennis Clarke wrote: > The configure line for GCC 4.2.1 looks like so : > > bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/configure > --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld > --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local > --with-local-prefix=/export/home/dclarke/local --enable-shared > --with-libiconv-prefix=/opt/csw --enable-languages=c,c++,objc,fortran > --with-gmp=/export/home/dclarke/local --with-mpfr=/export/home/dclarke/local > --enable-bootstrap All looks reasonable so far. > The process seems to run fine and configure does what it does. I issue make > ( which is really GNU make that I built previously ) and things grind away > for a long long time until this appears : > > checking for msgmerge... no > checking for sparc-sun-solaris2.8-gcc... > /opt/build/gcc-4.2.1-build/./prev-gcc/xgcc > -B/opt/build/gcc-4.2.1-build/./prev-gcc/ > -B/export/home/dclarke/local/sparc-sun-solaris2.8/bin/ > checking for C compiler default output file name... a.out > checking whether the C compiler works... configure: error: cannot run C > compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details. > make[2]: *** [configure-stage2-intl] Error 1 > make[2]: Leaving directory `/opt/build/gcc-4.2.1-build' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/opt/build/gcc-4.2.1-build' > make: *** [all] Error 2 > bash-3.2$ > > see this for all the details that follow : > > http://www.blastwave.org/dclarke/gcc-4.2.1/gcc-4.2.1-failure-details.txt Alas, you appear to have shown us the wrong config.log, since it doesn't give any detail of that error. You need to figure out what went wrong with the test executable compiled by the stage1 compiler. Maybe try compiling a "Hello World" with it and see what happens. Since it went wrong in the intl/ subdir, I'd suspect some problem with the libiconv-prefix or disable-nls settings. cheers, DaveK -- Can't think of a witty .sigline today
Enabling gcc optimization pass
Hi all, I have 3 functions- fun1, fun2, fun3 in the same source file and i want to enable one or any of the gcc optimization pass to code in fun2 only, 1. Is it possible to implement this using function attributes or #pragms's? 2. What will be its side-effects? Regards, Rohit
Re: RFC: Rename Non-Autpoiesis maintainers category
Kenneth Zadeck <[EMAIL PROTECTED]> writes: > diego's suggestion is ok. i guess it at least satisfies the criteria of > being a well known word. I like "non-self-approving". I needed a dictionary to figure out what "autopoiesis" meant.
Re: Creating gcc-newbies mailing list
On 7/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote: I would like to propose the creation a new mailing list: [EMAIL PROTECTED] The purpose of this list is to attract and help new GCC developers who might feel lost and intimidated by the more arcane traffic at gcc and gcc-patches. In this list, no question regarding GCC development should be considered offtopic nor treated with "RTFM" responses. I think this is the wrong aproach. I have not seen any "RTFM" response for questions of developing of GCC on the gcc@ list. I think it is wrong to seerate newbies questions from normal development questions because some of other developers might not want to join that list just to answer questions and then learn that a question was being discussed on that list already. Also I think it was wrong to ask first on the overseers mailing list to create this list before discussing the pros/cons about the list. Or maybe this is not a good idea, but I have certainly seen some folks that complain about our less than friendly practices. Most of those are due to offtopic questions in the first place. If you look at the recent thread about libelf, well that was offtopic but it became unfriendly really after a person continued the thread after being asked once nicely to take the thread to the libelf mailing lists. Thanks, Andrew Pinski
Re: C++ ABI: name mangling of operator new [bug 6057]
On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote: Doug Gregor wrote: > This kind of thing came up that the last C++ committee meeting, as > part of core issue 339: > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339 > > Name mangling is part of the problem, but not all of it. There is also > the issue of what happens when there is an error in the expression > "new T": is it part of the Substitution Failure Is Not An Error > (SFINAE) rule, meaning that the function would not enter the overload > set, or does it trigger an error immediately? That's actually the more > complicated issue. Thanks for pointing DR 339 out to me; whilst I had read it before, it was before the note from the Apr 2007 meeting was added. Although the 'compromise proposal' appears to avoid all of these problems by making my example illegal, it would appear that N2235 'Generalized Constant Expressions' reintroduces many of them again. To give an example, I'm sorry, I should have read that DR text more carefully before pointing. We discussed DR 339 again last week in Toronto, and the resolution was different from the April 2007 resolution. Now, we're saying that any expressions are valid in sizeof, decltype, and constant expressions. If those expressions fail to type-check during substitution, it will be a SFINAE case. That's why we need both name mangling additions to the ABI and more work to obey tsubst_flags_t throughout a much larger part of the compiler. - Doug
Remove ARM AOF support
The arm backend has support for both gas assembly and the syntax used by proprietary arm assemblers (controlled by AOF_ASSEMBLER). I'm told that the only recent users of this feature were the riscos folks, and that they no longer care. The only target that uses this code in the FSF tree is arm-semi-aof. This also defines LINK_LIBGCC_SPECIAL which was poisoned in early 2005, so obviously hasn't built for two and a half years. Anyone object if I rip out the AOF assembler support? Technically we should probably deprecate it for a release, but IMHO it's bitrotten enough to skip that unless anyone expresses interest. The motivation for doing this is that the new ARM unified assembly syntax and other Thumb-2 improvements involve touching code with AOF_ASSEMBLER conditionals. Obviously it's easier to do if the conditionals aren't there. Without any way of testing the AOF support I can't guarantee it won't get broken in the process. Paul
Re: URGENT : elf_update - low performance with large files ? (fwd)
Wasn't there a discussion yesterday about the fact that this is off-topic for this mailing list? Please take this thread somewhere more appropriate. Thanks, Ben
Re: dlopen() crash -gcc 3.4.6 20060404
Friendly Gaurav Build it with the -ggdb2 option, and follow those steps: $ gdb a.out (gdb) start (gdb) stepi (gdb) backtrace (gdb) step (gdb) bt (gdb) stepi (gdb) bt (gdb) help It's funny ;)
Re: [tuples] meaning of DECL_SAVED_TREE while analyzing cgraph
> Hi Jan.
>
> What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
>
> /* ??? It is possible to create extern inline function and later using
>weak alias attribute to kill its body. See
>gcc.c-torture/compile/2009-1.c */
> if (!DECL_SAVED_TREE (decl))
> {
> cgraph_reset_node (node);
> continue;
> }
>
> gcc_assert (!node->analyzed && node->reachable);
> gcc_assert (DECL_SAVED_TREE (decl));
>
> It was my understanding that DECL_SAVED_TREE was to be cleared after the
> tree optimizers executed, and Diego is explicitly killing it now right
> after gimplification-- at the end of gimplify_function_tree:
>
> /* The tree body of the function is no longer needed, replace it
>with the new GIMPLE body. */
> set_gimple_body (fndecl, seq);
> DECL_SAVED_TREE (fndecl) = NULL_TREE;
>
>
> I also thought that after the CFG was built, DECL_SAVED_TREE had nothing
> of value left.
>
> So, what do you expect it to have? Can we use something in the tuple
Well, take a look at the testcase mentioned in comment - it is a bit
weird side case where frotend produces function with body, passes it to
cgraph and then take the body back before end of compilation unit.
The test there is sort of hack, I would just remove it at this stage and
we can work out better fix for that testcase later. I hope that with my
plans for declaration merging pass we can get round such weird side
effects of in place declaration replacement.
Honza
> body now, or do you are you overloading DECL_SAVED_TREE for somthing
> else? Also, the assertion of DECL_SAVED_TREE above is unecessary, since
> you've already checked for a lack of it, and looped.
>
> Please let me know.
>
> Thanks.
> Aldy
Re: Remove ARM AOF support
In message <[EMAIL PROTECTED]> Paul Brook <[EMAIL PROTECTED]> wrote: > The arm backend has support for both gas assembly and the syntax used by > proprietary arm assemblers (controlled by AOF_ASSEMBLER). > > I'm told that the only recent users of this feature were the riscos folks, > and > that they no longer care. As one of those folks, I can confirm that. Our latest AOF based release was for GCC 3.4.6 and currently we're porting gcc 4.1 for RISC OS based on ELF using binutils toolchain and we're no longer need any AOF support. FYI, our project page is at http://gccsdk.riscos.info/. Go ahead. John. -- John Tytgat, in his comfy chair at home BASS [EMAIL PROTECTED] ARM powered, RISC OS driven
Re: relocation truncated to fit
Hi, Guenther
It works. Thank you very much!
Canqun Yang
--- Richard Guenther <[EMAIL PROTECTED]>:
> On 7/26/07, Canqun Yang <[EMAIL PROTECTED]> wrote:
> > Hi, all
> >
> > Can anyone help me to resolve this problem?
> >
> > When I compile a program with .bss segement larger than 2.0GB, I get the
> > following error message from GNU linker (binutils-2.15).
> >
> > (.text+0x305): In function `sta_':
> > : relocation truncated to fit: R_X86_64_32S plot_
> > ..
> >
> > I upgrade the assembler and the linker from binutis-2.17, then get the
> > message below.
> >
> > STA.o: In function `sta_':
> > STA.F:(.text+0x305): relocation truncated to fit: R_X86_64_32S against
> > symbol `plot_' defined in COMMON section in STA.o
> >
> > So, I modified the binutils-2.17/bfd/elf64-x86-64.c and rebuild the linker
> > to ignore the relocation errors. Though the executable generated,
> > segementation fault occurred during execution.
> >
> > Here is the configuration of my computer:
> >
> > CPU: Intel(R) Xeon(R) CPU5150 @ 2.66GHz
> > OS: Linux mds 2.6.9-34.EL_lustre.1.4.6.1custom #3 SMP Fri Jul 13 15:27:27
> > CST 2007 x86_64 x86_64 x86_64 GNU/Linux
> > Compiler: Intel C++/Fortran compiler for linux 10.0
> >
> > I also wrote a program with large uninitialized data -- more than 2.0GB.
> > It passes after linked with the modified linker. The source code is
> > appended.
>
> Try using -mcmodel=medium
>
> Richard.
>
> > #define N 0x05fff
> >
> > double a[N][N];
> >
> > int
> > main ()
> > {
> > int i, j;
> > double sum;
> >
> > for (i = 0; i < N; i+=5)
> > for (j = 0; j < N; j+=5)
> > a[i][j] = 2* i*j + i*i + j*j;
> >
> >
> > sum = 0.0;
> > for (i = 0; i < N; i+=5)
> > for (j = 0; j < N; j+=5)
> > sum += a[i][j];
> >
> > printf ("%f\n", sum);
> > }
> >
> >
> > Best regards,
> >
> > Canqun Yang
___
抢注雅虎免费邮箱3.5G容量，20M附件！
http://cn.mail.yahoo.com
Re: Creating gcc-newbies mailing list
Diego Novillo wrote: [ Forgot to CC gcc@ in my initial message, thanks Andrew. ] I would like to propose the creation a new mailing list: [EMAIL PROTECTED] The purpose of this list is to attract and help new GCC developers who might feel lost and intimidated by the more arcane traffic at gcc and gcc-patches. In this list, no question regarding GCC development should be considered offtopic nor treated with "RTFM" responses. The idea is to give new developers a place where to hang out and ask all those questions they feel may be too silly for the main list. GCC has a reputation for being a difficult environment to work in and new developers are sometimes driven away by the terseness and/or perceived hostility in the main lists. The other goal of gcc-newbies is to provide a list of janitorial and relatively simple projects that are always floating around and nobody seems to get to. The GCC wiki already has a list of such projects, some of which should be a good start for anyone wanting to join. Or maybe this is not a good idea, but I have certainly seen some folks that complain about our less than friendly practices. Between gcc@ and gcc-help@ I think we have it pretty much covered. I have not really seen anyone flamed on gcc@ when they ask newbie type questions related to GCC development. Also many GCC developers post responses on gcc-help that I think would be appropriate for gcc@ I don't think adding more lists will simplify the lives of either GCC developers or those trying to learn about GCC development. My $0.02 would be to maintain the status quo. David Daney
Creating gcc-newbies mailing list
[ Forgot to CC gcc@ in my initial message, thanks Andrew. ] I would like to propose the creation a new mailing list: [EMAIL PROTECTED] The purpose of this list is to attract and help new GCC developers who might feel lost and intimidated by the more arcane traffic at gcc and gcc-patches. In this list, no question regarding GCC development should be considered offtopic nor treated with "RTFM" responses. The idea is to give new developers a place where to hang out and ask all those questions they feel may be too silly for the main list. GCC has a reputation for being a difficult environment to work in and new developers are sometimes driven away by the terseness and/or perceived hostility in the main lists. The other goal of gcc-newbies is to provide a list of janitorial and relatively simple projects that are always floating around and nobody seems to get to. The GCC wiki already has a list of such projects, some of which should be a good start for anyone wanting to join. Or maybe this is not a good idea, but I have certainly seen some folks that complain about our less than friendly practices. Thanks.
RE: GCC 4.2.1 : bootstrap fails at stage 2. Anyone know why ?
> On 26 July 2007 03:09, Dennis Clarke wrote:
>
>> The configure line for GCC 4.2.1 looks like so :
>>
>> bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/configure
>> --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
>> --enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local
>> --with-local-prefix=/export/home/dclarke/local --enable-shared
>> --with-libiconv-prefix=/opt/csw --enable-languages=c,c++,objc,fortran
>> --with-gmp=/export/home/dclarke/local
>> --with-mpfr=/export/home/dclarke/local
>> --enable-bootstrap
>
> All looks reasonable so far.
You know, I was hoping you would say that :-)
>> The process seems to run fine and configure does what it does. I issue
>> make
>> ( which is really GNU make that I built previously ) and things grind away
>> for a long long time until this appears :
>>
>> checking for msgmerge... no
>> checking for sparc-sun-solaris2.8-gcc...
>> /opt/build/gcc-4.2.1-build/./prev-gcc/xgcc
>> -B/opt/build/gcc-4.2.1-build/./prev-gcc/
>> -B/export/home/dclarke/local/sparc-sun-solaris2.8/bin/
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... configure: error: cannot run C
>> compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details.
>> make[2]: *** [configure-stage2-intl] Error 1
>> make[2]: Leaving directory `/opt/build/gcc-4.2.1-build'
>> make[1]: *** [stage2-bubble] Error 2
>> make[1]: Leaving directory `/opt/build/gcc-4.2.1-build'
>> make: *** [all] Error 2
>> bash-3.2$
>>
>> see this for all the details that follow :
>>
>> http://www.blastwave.org/dclarke/gcc-4.2.1/gcc-4.2.1-failure-details.txt
>
> Alas, you appear to have shown us the wrong config.log, since it doesn't
> give any detail of that error.
oh .. that explains why I see no error there :-(
> You need to figure out what went wrong with
> the test executable compiled by the stage1 compiler.
OKay ... that would be this guy :
bash-3.2$ pwd
/opt/build/gcc-4.2.1-build
bash-3.2$ prev-gcc/xgcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /export/home/dclarke/build/gcc-4.2.1/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local
--with-local-prefix=/export/home/dclarke/local --enable-shared
--with-libiconv-prefix=/opt/csw --enable-languages=c,c++,objc,fortran
--with-gmp=/export/home/dclarke/local --with-mpfr=/export/home/dclarke/local
--enable-bootstrap
Thread model: posix
gcc version 4.2.1
bash-3.2$ file prev-gcc/xgcc
prev-gcc/xgcc: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped
> Maybe try compiling a
> "Hello World" with it and see what happens. Since it went wrong in the
> intl/
> subdir, I'd suspect some problem with the libiconv-prefix or disable-nls
> settings.
Now that is excellent thinking.
Let me have a whirl at it :
bash-3.2$ cat /tmp/hello.c
#include
int
main(int argc, char *argv[])
{
printf ( "Hello World!\n" );
return (0);
}
I ran this for just the preprocessed compile stage first :
http://www.blastwave.org/dclarke/gcc-4.2.1/gcc-4.2.1-stage1-test.txt
Then I generate the assembly :
http://www.blastwave.org/dclarke/gcc-4.2.1/gcc-4.2.1-stage1-assembly.txt
And *that* also looks very good.
This does not look too good :
http://www.blastwave.org/dclarke/gcc-4.2.1/gcc-4.2.1-stage1-hello.txt
okay .. so that reveals some info. I think.
Dennis
Re: Creating gcc-newbies mailing list
On Thu, 2007-07-26 at 17:13 -0400, Diego Novillo wrote: > Or maybe this is not a good idea, but I have certainly seen some folks > that complain about our less than friendly practices. Alternative would be to keep gcc@ and document that emails with subject tag [BEGINNER] should not be answered by unfriendly developpers (who can filter them out easily) and should be answered as quickly and friendly as possible by those who care :). Laurent
Re: C++ ABI: name mangling of operator new [bug 6057]
Doug Gregor wrote:
> Hi Richard,
>
> On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
>
> > A three line example exhibiting the ICE is:
> >
> > template struct helper {};
> > template void check( helper* );
> > int main() { check(0); }
> >
[...]
>
> This kind of thing came up that the last C++ committee meeting, as
> part of core issue 339:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
>
> Name mangling is part of the problem, but not all of it. There is also
> the issue of what happens when there is an error in the expression
> "new T": is it part of the Substitution Failure Is Not An Error
> (SFINAE) rule, meaning that the function would not enter the overload
> set, or does it trigger an error immediately? That's actually the more
> complicated issue.
Thanks for pointing DR 339 out to me; whilst I had read it
before, it was before the note from the Apr 2007 meeting was
added.
Although the 'compromise proposal' appears to avoid all of
these problems by making my example illegal, it would appear
that N2235 'Generalized Constant Expressions' reintroduces
many of them again. To give an example,
constexpr long foo( long l ) { return l; }
constexpr int foo( int i ) { return i; }
template struct helper {};
template
void check( helper* );
int main() { check(0); }
In this case, I think we need to mangle the call to (the
candidate set for the unqualified name) foo before carrying
out overload resolution. (And it would be possible to
produce a similar example involving ADL of a type with a
constexpr constructor, we don't necessarily even know the
scope of foo.)
This resolution to DR 339 would remove the need to handle
the mangling of new, new[], delete, delete[], dynamic_cast
and throw, but as constructor calls (i.e. T()), and calls to
possibly-overloaded functions (including member functions
and template functions), and calls to operator() remain,
this seems like very little significant gain.
In any case, it seems hard to justify not compiling (with
-std=c++98) the example quoted at the top of this email as,
notwithstanding DR 339, it's hard to think of an
interpretation of the current standard under which it is
illegal. (Even if this was not the intention.)
Richard Smith
Re: C++ ABI: name mangling of operator new [bug 6057]
On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
template
class is_default_constructible {
template struct helper {};
typedef char no; typedef char yes[2];
static no fn(...);
static yes fn( helper* );
public:
static const bool value = sizeof(fn(0)) == sizeof(yes);
};
I believe that should work with the (new) proposed resolution to DR 339.
- Doug
RE: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
SUMMARY : the stage 2 compiler produces the wrong binary type for this machine
I did further digging and built my own libiconv and installed that into my
own isolated "local" directory at $HOME/local
then I destroyed my previous stage 1 work and started over again thus :
bash-3.2$ date
Thu Jul 26 21:20:30 EDT 2007
bash-3.2$
bash-3.2$ /export/home/dclarke/build/gcc-4.2.1/configure
--with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--enable-threads=posix --disable-nls --prefix=/export/home/dclarke/local
--with-local-prefix=/export/home/dclarke/ local --enable-shared
--enable-languages=c,c++,objc,fortran --with-gmp=/export/h ome/dclarke/local
--with-mpfr=/export/home/dclarke/local --enable-bootstrap
eventually I run make and hours later I see the same error as before :
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-stage2-intl] Error 1
make[2]: Leaving directory `/opt/build/gcc-4.2.1-build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/opt/build/gcc-4.2.1-build'
make: *** [all] Error 2
bash-3.2$ date
Fri Jul 27 01:02:05 EDT 2007
bash-3.2$ bash-3.2$
so this time I go hunting for that config.log with the non-zero exit status
and find it at ./intl/config.log
http://www.blastwave.org/dclarke/gcc-4.2.1/intl_config_log.txt
the devil is in the details and there we see :
configure:2121: /opt/build/gcc-4.2.1-build/./prev-gcc/xgcc
-B/opt/build/gcc-4.2.1-build/./prev-gcc/
-B/export/home/dclarke/local/sparc-sun-solaris2.8/bin/ -g -O2
-I/export/home/dclarke/local/include conftest.c >&5
configure:2124: $? = 0
configure:2170: result: a.out
configure:2175: checking whether the C compiler works
configure:2181: ./a.out
./a.out: syntax error at line 1: `(' unexpected
configure:2184: $? = 2
configure:2191: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
that error seems to scream to me that the output binary a.out can not be
executed because it is for the wrong processor target. This should create
output for Sparc V7 ( old old generic ) but the binary must be for sparcv8a
or similar.
In either case I think that the --host needs to be specified as well as
perhaps --with-cpu=foo or something like that in the ./configure line.
Now that I check http://gcc.gnu.org/install/configure.html there is no
--host option to give to configure so .. I am stumped again.
here is the proof of the problem. I run the compile of hello.c and we see
the error :
bash-3.2$ /opt/build/gcc-4.2.1-build/./prev-gcc/xgcc
-B/opt/build/gcc-4.2.1-build/./prev-gcc/
-B/export/home/dclarke/local/sparc-sun-solaris2.8/bin/ -g -O2
-I/export/home/dclarke/local/include -o /tmp/a.out /tmp/hello.c
bash-3.2$ file /tmp/a.out
/tmp/a.out: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, dynamically linked, not stripped
that is the wrong binary for these old Sparc processors.
bash-3.2$ /tmp/a.out
bash: /tmp/a.out: cannot execute binary file
Of course not.
The machine needs a plain old Sparc v7 binary and this will simply not work.
what options do I need to set on the configure line in order for this to
work? I don't see a --host option and I am not certain if setting CFLAGS
will enforce this during a bootstrap.
any help .. would be great now that I identified the symptoms of the problem.
Dennis
Re: RFC: Rename Non-Autpoiesis maintainers category
I really do not like the current name either, but i do not have a better one. Since the whole file is about MAINTAINERS, I would suggest changing the categories to: - Committers (i.e. committing maintainers) - Reviewers (i.e. reviewing maintainers) - Non-algorithmic committers Paolo
