Re: shrink-wrap leads to ICE at dwarf2cfi.c
On 11 September 2012 03:37, Richard Henderson wrote: > On 09/10/2012 01:41 AM, Zhenqiang Chen wrote: >> In function maybe_record_trace_start, there is a check: >> >> /* We ought to have the same state incoming to a given trace no >> matter how we arrive at the trace. Anything else means we've >> got some kind of optimization error. */ >> gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row)); > > The assert is most definitely valid. > > The check makes certain that the unwind info as seen by any two paths > leading to a common location are the same. When this fails, typically > one of two things has happened: > > (1) The notes for the epilogue unwind info are incorrect, > (2) We have applied an invalid code transformation in some earler > optimization pass. > > We can't tell what the real problem is without more information. Thank you for the comments. I will do more check on the transformation of shrink-wrap. -Zhenqiang
Re: gcc-c-api
On Tue, Sep 11, 2012 at 3:10 AM, David Malcolm wrote:
> On Mon, 2012-09-10 at 17:20 +0200, Michael Matz wrote:
>> Hi David,
>>
>> On Mon, 10 Sep 2012, David Malcolm wrote:
>>
>> > Is it possible for you to post your work-in-progress code somewhere?
>>
>> Attached.
>
> Many thanks for posting this! Various comments inline below.
>
>> > I know that you don't feel it's ready for committing, but I would find
>> > it helpful - I'm interested in understanding the general approach,
>> > rather than seeing completeness or perfection.
>>
>> Some sort of brain dump follows:
>>
>> The idea is as follows: as first cut an introspection API that is tied to
>> compiler IR concepts rather than GCC specifics. As such it should be
>> implementable also for other compilers, at least the trivial things that
>> every traditional compiler will have. So, we have functions, basic
>> blocks, instructions, operands and operators. Nothing of that should
>> relate to tree or gimple or RTL.
>
> I see. So there's a terminology issue here: we shouldn't refer to
> "gimple" or "rtl", we should refer to "instructions" or "statements".
>
> [Possibly crazy idea: should the API actually refer to itself as GCC?
> (with "gcc_" prefixes etc) If it's implementable by other compilers,
> would another prefix be suitable? I don't think this is a good idea,
> but it makes for an interesting thought experiment]
I think the API shouldn't refer to GCC itself - in fact I was hoping
that someone
implemented the very same API for LLVM or Open64. At least introspection
should be compiler agnostic (in my tiny ideal world ;)).
I also think that we can easily backport plugin API changes (read: additions,
the API of course never "changes") to active release branches, so plugins
using this API should run against all released GCC versions (for additions
the API needs a way to identify its "version" though) and other compilers
without re-compiling the plugin itself.
>> Take for instance the (included) dump-plugin. The goal would be, that
>> depending on where you'd put that dumper in the pass pipeline it would
>> work _unchanged_ on GENERIC, on GIMPLE and on RTL. That goal isn't
>> reached yet, once because the internal iteration just isn't
>> implemented for e.g. RTL instruction stream, and once because the operand
>> iterator API isn't well suited to the tree-like nesting in GENERIC and
>> RTL currently.
>
> Interesting idea.
>
> I prefer having a little more type-safety, but it's a pain to achieve it
> in C. If you look at my proposed API [1], there are dozens of tiny
> casting functions. I like that it's typesafe, but it's somewhat
> inelegant.
I suppose one could wrap a more type-safe C++ interface around the
C API (well, or simply wrap a nice python API around it ;)).
>> [The intermediate goal was to redo the operand API to be tree-like at the
>> base, and possibly write small wrappers to again expose the nicer
>> interface that GIMPLE would provide (i.e. direct access to all read
>> operands of an instruction).]
>>
>> Another thing I want is simplicity. E.g. only the bare minimum of types
>> should be exposed. Note how the API itself for instance doesn't expose
>> different types of collections, only a general Range which can enumerate
>> all things, depending on how it's used (though the implementation has
>> runtime checks for wrong usage).
>
> I seem to remember from earlier mailing list discussion there being a
> preference for explicit iterator objects, rather than for_each functions
> taking callbacks (my API uses the latter approach).
Yes (I didn't look into Michas patch ... but I believe it uses iterators).
> FWIW I don't expose any iterators directly in my plugin, I simply
> generate a list of wrapper objects and return that. But I suppose
> others might.
>
>> There are some questions to be solved, e.g. memory management for those
>> objects that aren't directly tied to GCC objects, e.g. Ranges right now.
>> I do have a strong feeling about the relation of e.g. plugin Instructions
>> and GCC gimple/rtx, in the sense that plugin authors should _not_ be
>> required to manage memory for those things (same for BBs, functions,
>> operands).
>
> I'm not sure how to parse what you wrote above, so I'm not quite sure
> what your preference here is. I see that you have range-creation
> functions (e.g. "gcc_stmts"), which return a Range that's owned by the
> caller, together with a cleanup function ("gcc_free_range") that must be
> called exactly once assuming the Range was successfully created. The
> other entities (e.g. "Function") are in fact "really" just gcc structs
> internally (e.g.
>"Function" = "struct Function_*" = "cast to (struct function *)" )
> and those are GC-managed.
Yes, they are "handlers" that can be passed/returned by value and thus
need no memory management. That they relate to the internal GC pointer
is an implementation detail.
> Currently in my proposed API I assume that all objects are GC-managed,
> and
Libtool update for gcc-4.8 (slim-lto bootstrap)?
Is there any interest in updating the in-tree libtool to something newer? This update would allow to use a -fno-fat-lto-objects lto-bootstrap target, that should speed up the (lto) build time. If there is interest, when would be the best date for such an update? Thanks. -- Markus
Re: Libtool update for gcc-4.8 (slim-lto bootstrap)?
> Is there any interest in updating the in-tree libtool to something > newer? This update would allow to use a -fno-fat-lto-objects > lto-bootstrap target, that should speed up the (lto) build time. > > If there is interest, when would be the best date for such an update? There is definitely an interest. I still hope we will be able to switch to slim-lto by default in foreseeable future... Honza > > Thanks. > -- > Markus
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
Hi, On Mon, 10 Sep 2012, Gabriel Dos Reis wrote: > > You could also do this with an explicit pointer-to-context-struct > > parameter that's passed around (and that version of the patch I > > posted), but the class-based approached seems nicer to me. > > Are we talking about encapsulation or "looking nice"? In either case, I > respectfully disagree -- talking specifically about the patch posted. > Having a giant struct with a zillion of member functions defies any > reasonable notion of "looking nice", and of "encapsulation." Amen. Ciao, Michael.
GCC's Decimal Floating Point extension problem
Hi All,
I'm trying to write a small program to check the decimal floating point gcc
extension but I encountered some problems
The program just converts a _Decimal64 number to double to print it and I used
the function (double __bid_truncdddf (_Decimal64 a) as the gnu online docs show)
#include
int main ()
{
_Decimal64 d = 12.5DD;
printf ("%lf\n",__bid_truncdddf(d) );
return 0;
}
$ gcc test.c -Wall -g
test.c: In function ‘main’:
test.c:23: warning: implicit declaration of function ‘__bid_truncdddf’
test.c:23: warning: format ‘%lf’ expects type ‘double’, but argument 2 has type
‘int’
$ ./a.out
0.00
I don't know why the result is zero and why the second warning appears although
I wrote the function properly!
I'm using gcc version 4.4.3 on ubuntu 10.04
Finally, I suffer from lack of good docs about DFP gcc extension, Does anyone
know a good tutorial explaining the functions and give some examples
Best Regards,
M. Ahmed
Re: GCC's Decimal Floating Point extension problem
On Tue, Sep 11, 2012 at 11:31 AM, Mohamed Abou Samra
wrote:
> Hi All,
>
> I'm trying to write a small program to check the decimal floating point gcc
> extension but I encountered some problems
>
> The program just converts a _Decimal64 number to double to print it and I
> used the function (double __bid_truncdddf (_Decimal64 a) as the gnu online
> docs show)
>
> #include
>
> int main ()
> {
>_Decimal64 d = 12.5DD;
> printf ("%lf\n",__bid_truncdddf(d) );
>
> return 0;
> }
>
> $ gcc test.c -Wall -g
> test.c: In function ‘main’:
> test.c:23: warning: implicit declaration of function ‘__bid_truncdddf’
> test.c:23: warning: format ‘%lf’ expects type ‘double’, but argument 2 has
> type ‘int’
>
> $ ./a.out
> 0.00
>
> I don't know why the result is zero and why the second warning appears
> although I wrote the function properly!
>
>
,__bid_truncdddf is a libgcc internal function. Don't ever use it
in user programs. Just cast DFP to double.
--
H.J.
Re: Cgraph Modification Plan
We do not yet seem to have consensus on a long term plan.
Would it be reasonable to start on short term prepatory work?
In particular, I was think we could do
Add converters and testers.
Change callers to use those.
and maybe
Change callers to use type-safe parameters.
Where those mean what I earlier stated.
Comments?
CONVERTERS AND TESTERS ###
add
symtab_node_base &symtab_node_def::ref_symbol()
{ return symbol; }
symtab_node_base &cgraph_node::ref_symbol()
{ return symbol; }
symtab_node_base &varpool_node::ref_symbol()
{ return symbol; }
change
node->symbol.whatever
to
node->ref_symbol().whatever
should not need to add these
cgraph_node &symtab_node_def::ref_cgraph()
{ gcc_assert (symbol.type == SYMTAB_FUNCTION);
return x_function; }
varpool_node &symtab_node_def::ref_varpool()
{ gcc_assert (symbol.type == SYMTAB_VARIABLE);
return x_variable; }
add
symtab_node_base *symtab_node_def::try_symbol()
{ return &symbol; }
cgraph_node *symtab_node_def::try_cgraph()
{ return symbol.type == SYMTAB_FUNCTION ? &x_function : NULL; }
varpool_node *symtab_node_def::try_varpool()
{ return symbol.type == SYMTAB_VARIABLE ? &x_variable : NULL; }
change
if (symtab_function_p (node) && cgraph (node)->analyzed)
return cgraph (node);
to
if (cgraph_node *p = node->try_cgraph())
if (p->analyzed)
return p;
change
if (symtab_function_p (node) && cgraph (node)->callers)
to
if (cgraph_node *p = node->try_cgraph())
if (p->callers)
change
if (symtab_function_p (node))
{
struct cgraph_node *cnode = cgraph (node);
to
if (cgraph_node *cnode = node->try_cgraph ())
{
likewise "symtab_variable_p (node)" and "varpool (node)"
If there are any "symtab_function_p (node)" expressions left,
add
bool symtab_node_def::is_cgraph()
{ return symbol.type == SYMTAB_FUNCTION; }
bool symtab_node_def::is_varpool()
{ return symbol.type == SYMTAB_VARIABLE; }
change
symtab_function_p (node)
to
node->is_cgraph ()
likewise "symtab_variable_p (node)"
Though we would like to avoid doing so,
if there are any "cgraph (node)" or "varpool (node)" expressions left,
add
symtab_node_base *symtab_node_def::ptr_symbol()
{ return &symbol; }
cgraph_node *symtab_node_def::ptr_cgraph()
{ gcc_assert (symbol.type == SYMTAB_FUNCTION);
{ return &x_function; }
varpool_node *symtab_node_def::ptr_varpool()
{ gcc_assert (symbol.type == SYMTAB_VARIABLE);
{ return &x_variable; }
change
cgraph (node) => node->ptr_cgraph()
likewise "varpool (node)"
TYPE SAFETY ###
If a function asserts that its symtab_node parameter is symtab_function_p,
then convert the function to take a cgraph_node*
and change the callers to convert as above.
--
Lawrence Crowl
contrib/config-list.mk
The contrib/config-list.mk tool appears to be suffering from bitrot. The make failures for a limited subset of configurations consisted exclusively of: cc1: warnings being treated as errors ../../../../gcc/fixincludes/server.c: In function 'server_setup': ../../../../gcc/fixincludes/server.c:195: error: ignoring return value of 'getcwd', declared with attribute warn_unused_result The warning is correct. It is not clear what one should do upon testing the return value, as server_setup does not signal errors. Suggestions? Do we consider contrib/config-list.mk dead? -- Lawrence Crowl
variable tracking vs. delay slots question
I have a question about the the variable tracking and the delay slot passes. In some configuration files there is comment that says that the variable tracking pass should be run after all optimizations which change the order of instructions and that it requires a valid control flow graph to work. But my understanding of the delay slot pass is that it can change the order of instructions and that it can only be run after the control flow graph has been freed. These requirements seem to conflict. Am I right about this or are the comments wrong or am I confused? I think this problem is the basis of bug 54128, a bootstrap failure on MIPS, though the problem seems generic to any system with delay slots. Steve Ellcey sell...@mips.com
Re: contrib/config-list.mk
On Tue, Sep 11, 2012 at 3:18 PM, Lawrence Crowl wrote: > The contrib/config-list.mk tool appears to be suffering from bitrot. > The make failures for a limited subset of configurations consisted > exclusively of: > > cc1: warnings being treated as errors > ../../../../gcc/fixincludes/server.c: In function 'server_setup': > ../../../../gcc/fixincludes/server.c:195: error: ignoring return value > of 'getcwd', declared with attribute warn_unused_result > > The warning is correct. It is not clear what one should do upon > testing the return value, as server_setup does not signal errors. > > Suggestions? > > Do we consider contrib/config-list.mk dead? I don't know whether contrib/config-list.mk is dead or not. But I do know that you will only get that error on Debian or Ubuntu systems, which by default pass some rather aggressive warning options. It would be fine to have the program crash if getcwd somehow fails. There is nothing useful that it can do in that unlikely case. Ian
gfortran error: Statement order error: declaration after DATA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am trying to compile the cactuscode package and can not get past the error : Statement order error: declaration after DATA can you point me in the direction of a fix. I included offending file as an attachment. Dave kb9qhd Amateur Radio Service Technician class Licence Grid EN43 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQT9tfAAoJEIHvsckbl2dBLMIH/0LR4lA3w9W6lhaB3lkyX9WB dQJmYHAM59LsGmi+9fmhODG1KkoVfIMIqI8AaDHAFQiqkN2QCr1BNGTFgifFFcV9 BijJt4OtcZTzS0LwIzLTGOEbBJIT2xP1HQmVm/7gYr90HlWvLMHLoPJgqnNsJyNT mxWMEJojD/xeKaHE6yUIZxRlbnM/pC7UYSIruQ7YjsxC7gKpHfBeOM9Op4AkwJ0k H4IaKRDpYOKBbEHP6LLPZFTdosjQgWaFnTBILvLaHjSqa9mskU4yTDLdLHFNjUz9 i5hC2ihlIJBcQx1QVLwt/AvjSDtqPqLPKo3h2OBH0IJzlcS+kOkfeSQ+AvkWghU= =snlv -END PGP SIGNATURE- C Fast Fourier Transform subroutines C C Copyright (c) 1978 Clive Temperton (European Centre for Medium-Range C Weather Forecasts, Reading, UK) C Copyright (c) 1980 Russ Rew (National Center for Atmospheric Research, C Boulder, Colorado, USA) C C References: C -- CC. Temperton: ``Self-Sorting Mixed-Radix Fast Fourier C Transforms.'', Journal of Computational Physics 52, 1 (1983) CC. Temperton: ``Fast Mixed-Radix Real Fourier Transforms.'', C Journal of Computational Physics 52, 340 (1983) C C C $Id: fax.f,v 1.2 2004/10/04 19:22:00 e_gourgoulhon Exp $ C $Log: fax.f,v $ C Revision 1.2 2004/10/04 19:22:00 e_gourgoulhon C Added copyright and references. C C Revision 1.1.1.1 2001/11/20 15:19:30 e_gourgoulhon C LORENE C c Revision 1.3 2000/12/14 15:41:16 eric c subroutine VPASSM (ligne 152) : les DATA sont forces a la double c precision par l'ajout de D00 aux valeurs numeriques c (cela generait des erreurs double -> simple precision avec les c compilateurs g77 et NAG f95 sous Linux). c c Revision 1.2 1997/05/23 11:45:49 hyc c *** empty log message *** c C Revision 1.1 1997/03/17 20:05:32 hyc C Initial revision C C C $Header$ C C SUBROUTINE FAX(IFAX,N,MODE) IMPLICIT double PRECISION (A-H,O-Z) character*100 header data header/'$Header$'/ DIMENSION IFAX(*) NN=N IF (IABS(MODE).EQ.1) GO TO 10 IF (IABS(MODE).EQ.8) GO TO 10 NN=N/2 IF ((NN+NN).EQ.N) GO TO 10 IFAX(1)=-99 RETURN 10 K=1 C TEST FOR FACTORS OF 4 20 IF (MOD(NN,4).NE.0) GO TO 30 K=K+1 IFAX(K)=4 NN=NN/4 IF (NN.EQ.1) GO TO 80 GO TO 20 C TEST FOR EXTRA FACTOR OF 2 30 IF (MOD(NN,2).NE.0) GO TO 40 K=K+1 IFAX(K)=2 NN=NN/2 IF (NN.EQ.1) GO TO 80 C TEST FOR FACTORS OF 3 40 IF (MOD(NN,3).NE.0) GO TO 50 K=K+1 IFAX(K)=3 NN=NN/3 IF (NN.EQ.1) GO TO 80 GO TO 40 C NOW FIND REMAINING FACTORS 50 L=5 INC=2 C INC ALTERNATELY TAKES ON VALUES 2 AND 4 60 IF (MOD(NN,L).NE.0) GO TO 70 K=K+1 IFAX(K)=L NN=NN/L IF (NN.EQ.1) GO TO 80 GO TO 60 70 L=L+INC INC=6-INC GO TO 60 80 IFAX(1)=K-1 C IFAX(1) CONTAINS NUMBER OF FACTORS C IFAX(1) CONTAINS NUMBER OF FACTORS NFAX=IFAX(1) C SORT FACTORS INTO ASCENDING ORDER IF (NFAX.EQ.1) GO TO 110 DO 100 II=2,NFAX ISTOP=NFAX+2-II DO 90 I=2,ISTOP IF (IFAX(I+1).GE.IFAX(I)) GO TO 90 ITEM=IFAX(I) IFAX(I)=IFAX(I+1) IFAX(I+1)=ITEM 90 CONTINUE 100CONTINUE 110 CONTINUE RETURN END C SUBROUTINE FFTRIG(TRIGS,N,MODE) IMPLICIT double PRECISION (A-H,O-Z) DIMENSION TRIGS(*) X1=1 PI=2.*ASIN(X1) IMODE=IABS(MODE) NN=N IF (IMODE.GT.1.AND.IMODE.LT.6) NN=N/2 DEL=(PI+PI)/DFLOAT(NN) L=NN+NN DO 10 I=1,L,2 ANGLE=.5D00*DFLOAT(I-1)*DEL TRIGS(I)=COS(ANGLE) TRIGS(I+1)=SIN(ANGLE) 10 CONTINUE IF (IMODE.EQ.1) RETURN IF (IMODE.EQ.8) RETURN DEL=.5D00*DEL NH=(NN+1)/2 L=NH+NH LA=NN+NN DO 20 I=1,L,2 ANGLE=.5D00*DFLOAT(I-1)*DEL TRIGS(LA+I)=COS(ANGLE) TRIGS(LA+I+1)=SIN(ANGLE) 20 CONTINUE IF (IMODE.LE.3) RETURN DEL=.5D00*DEL LA=LA+NN IF (MODE.EQ.5) GO TO 40 DO 30 I=2,NN ANGLE=DFLOAT(I-1)*DEL TRIGS(LA+I)=2*SIN(ANGLE) 30 CONTINUE RETURN 40 CONTINUE DEL=.5D00*DEL DO 50 I=2,N ANGLE=DFLOAT(I-1)*DEL TRIGS(LA+I)=SIN(ANGLE) 50 CONTINUE RETURN END C C SUBROUTINE 'VPASSMD' - MULTIPLE VERSION OF 'VPASSA' C PERFORMS ONE PASS THROUGH DATA C AS PART OF MULTIPLE COMPLEX FFT ROUTINE C A IS FIRST REAL INPUT VECTOR C B IS FIRST IMAGINARY INPUT VECTOR C C IS FIRST REAL OUTPUT V
Re: contrib/config-list.mk
Quoting Ian Lance Taylor : On Tue, Sep 11, 2012 at 3:18 PM, Lawrence Crowl wrote: The contrib/config-list.mk tool appears to be suffering from bitrot. The make failures for a limited subset of configurations consisted exclusively of: cc1: warnings being treated as errors ../../../../gcc/fixincludes/server.c: In function 'server_setup': ../../../../gcc/fixincludes/server.c:195: error: ignoring return value of 'getcwd', declared with attribute warn_unused_result The warning is correct. It is not clear what one should do upon testing the return value, as server_setup does not signal errors. Suggestions? Do we consider contrib/config-list.mk dead? I don't know whether contrib/config-list.mk is dead or not. I certainly hope not. But I do know that you will only get that error on Debian or Ubuntu systems, which by default pass some rather aggressive warning options. So does that mean that bootstrap is broken there too? It would be fine to have the program crash if getcwd somehow fails. There is nothing useful that it can do in that unlikely case. However, less desirable would be if the program silently continues and makes the user think everything is fine when it isn't. Maybe even alter some files it isn't supposed to alter in the process. As buff is an automatic variable, it is likely it contains somethng that can be interpreted as a string. So calling abort / exit (1) or something similar when things go wrong would make sense.
Re: variable tracking vs. delay slots question
On 09/11/2012 04:33 PM, Steve Ellcey wrote: In some configuration files there is comment that says that the variable tracking pass should be run after all optimizations which change the order of instructions and that it requires a valid control flow graph to work. But my understanding of the delay slot pass is that it can change the order of instructions and that it can only be run after the control flow graph has been freed. It changes the order of instructions, but IIRC it leaves a little breadcrumb in the instruction's original position. No idea of var-tracking would utilize that breadcrumb. reorg clobbers the CFG as well. These requirements seem to conflict. Am I right about this or are the comments wrong or am I confused? I think this problem is the basis of bug 54128, a bootstrap failure on MIPS, though the problem seems generic to any system with delay slots. I haven't looked at 54128, but yes, I think you're generally right about the conflict. Not sure what the implications are in terms of the failure mode -- it would seem to me that we wouldn't get good debug info. However, I'm not sure offhand how it'd cause a boostrap error. jeff
Re: gfortran error: Statement order error: declaration after DATA
David N. Bradley wrote: I am trying to compile the cactuscode package and can not get past the error : Statement order error: declaration after DATA Somehow the whole is very odd. a) I tried your program with gfortran 4.1 to 4.8, g95 and g77 - and none of them prints this error - all compile the program even with -std=f95 without any error. b) The code looks perfectly valid to me - the Fortran standard doesn't mandate that after DATA no other declaration comes. (Even having DATA after the first execution statement is valid, albeit obsolescent.) Your email lacks important pieces of information, in particular, which compiler in which version you are using under which operating system. Note that GCC (gcc.gnu.org) only develops/supports gfortran but no other compiler. (g77 was the predecessor but is no longer maintained.) Additionally, gcc@ is the mailing list for GCC development, please send usage questions to gcc-help@ (or gfortran's fortran@) but not to gcc@. Tobias
