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
Are Decimal operations are fully implemented/tested ?
Hey, I want to inquire about the state of decimal floating point operations at gcc low-level library. Does gcc fully implement IEEE 754-2008 standard ? I know that gcc support _Decimal64 / _Decimal128 as a decimal types and i did some simple operations on it. Also i want to be sure if the current implementation of decimal operations is fully tested and known to work well without any bugs or not. regards, Hesham
Re: GCC's Decimal Floating Point extension problem
On 2012-09-11 11:34:58 -0700, H.J. Lu wrote:
On Tue, Sep 11, 2012 at 11:31 AM, Mohamed Abou Samra
my_abousa...@yahoo.com 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)
If you cast the decimal64 value to double (whatever the method),
the printed value may be incorrect (see below).
#include stdio.h
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.
A double has 53 bits in general (always with GCC, AFAIK), so that
it doesn't have enough precision to guarantee that the output in
decimal (with the exact precision of _Decimal64) will be correct.
There has recently been a related discussion in the MPFR list.
See:
https://sympa.inria.fr/sympa/arc/mpfr/2012-08/msg00027.html
https://sympa.inria.fr/sympa/arc/mpfr/2012-08/msg00028.html
https://sympa.inria.fr/sympa/arc/mpfr/2012-09/msg00011.html
So, if long double has at least 55 bits, a solution would be to
cast the _Decimal64 to long double.
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Are Decimal operations are fully implemented/tested ?
On 2012-09-12 11:29:41 +0300, Hesham Moustafa wrote: I want to inquire about the state of decimal floating point operations at gcc low-level library. Does gcc fully implement IEEE 754-2008 standard ? No. Even for binary-only it doesn't (though it almost does). Also note that some parts of IEEE 754-2008 are (should be) implemented on the C library side (e.g. glibc). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Cgraph Modification Plan
On 2012-09-11 16:22 , Lawrence Crowl wrote: 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? Seems straightforward enough. And it doesn't seem like it will affect the longer term conversion. Diego.
Re: Are Decimal operations are fully implemented/tested ?
On Wed, Sep 12, 2012 at 1:29 PM, Vincent Lefevre vincent+...@vinc17.org wrote: On 2012-09-12 11:29:41 +0300, Hesham Moustafa wrote: I want to inquire about the state of decimal floating point operations at gcc low-level library. Does gcc fully implement IEEE 754-2008 standard ? No. Even for binary-only it doesn't (though it almost does). Also note that some parts of IEEE 754-2008 are (should be) implemented on the C library side (e.g. glibc). If exist, what are the known bugs in the current implementation of Decimal / IEEE 754-2008 standard ? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
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?
Yes, it seems sane.
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
I still do not gather why simple inheritance can't let me to write
node-whatever again...
If that is GTY limitation, I have no problem having this in short term and
update it later. symbol_node is really base of functions/variables and new
beasts we are going to get soon.
I implemented it as union only to make GTY happy.
should not need to add these
cgraph_node symtab_node_def::ref_cgraph()
{ gcc_assert (symbol.type == SYMTAB_FUNCTION);
I think checking_assert is enough in these cases. We are getting more
conversions back and forth and we don't really want to have asserts all around
code.
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; }
I think try_function/try_variable reads better than cgraph/varpool especially
with the
longer term plan to drop these names when cgraph/varpool no longer exists and
we have
symbol table.
Honza
Re: gfortran error: Statement order error: declaration after DATA
On 9/11/2012 5:46 PM, David N. Bradley wrote: -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- Surely someone has pointed out, you should require only to sort the file by placing the dimension statement ahead of the data statement, if you don't wish to adopt more modern syntax. -- Tim Prince
Re: variable tracking vs. delay slots question
On Tue, 2012-09-11 at 20:20 -0600, Jeff Law wrote: 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 bootstrap error. jeff The bootstrap error is caused by a stage2/stage3 comparison failure. Because the delay slot pass moved some instructions (but not their associated debug instructions) we no longer generate the same code with and without debug info. The change in code is due to a change in register allocation which is coming from build_insn_chain where it looks at all the instructions (debug and regular) to figure out register availability. My original fix for the bootstrap problem was to not have build_insn_chain look at debug instructions but Jakub Jelinek thought that that was not fixing the real bug but compensating for another problem. He was right and that other problem is the variable tracking / delay slot conflict. Steve Ellcey sell...@mips.com
Re: contrib/config-list.mk
On Tue, 11 Sep 2012, Ian Lance Taylor wrote: 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. contrib/config-list.mk is meant to be used with a (previously built) bootstrapped native compiler from the same version of the sources you are building (or at least a similar version), rather that with the system's own compiler at all. The sources are only expected to be -Werror clean when built using the same version of GCC, not some other version that may be a system compiler. -- Joseph S. Myers jos...@codesourcery.com
Re: GCC stack backtraces
On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote: Diego already loves it! Indeed I do! I'm making changes in VEC that will benefit from this. I am currently keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to the methods that want it. But it would be nice if we could get rid of these macros. Ian, do you expect to be adding this to libiberty so we can use it from GCC? Alternately, we could use Richi's approach I suppose (what happened to that patch, btw)? Thanks. Diego.
An interesting conversation or usual day without something new? I would rather choose the first one. What do u think?)
Hey gorgeous! My name is Jacklyn. If you looking forward about having great time in a company of smart, cute female then I am right before u! I liked your photo shots and that's why decided to create this message! I am thinking that u wouldn't stay indifferent after checking up mine too. So, I wait for you to answer this message and who knows we will go club, drink some vodka, talk about different subjects and who knows I gonna invite u to go to my appartment! ;)
Re: GCC stack backtraces
On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo dnovi...@google.com wrote: Alternately, we could use Richi's approach I suppose (what happened to that patch, btw)? I was under the impression that the patch was good to go in; Richard? -- Gaby
Re: GCC stack backtraces
Diego Novillo dnovi...@google.com wrote: On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote: Diego already loves it! Indeed I do! I'm making changes in VEC that will benefit from this. I am currently keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to the methods that want it. But it would be nice if we could get rid of these macros. Only of the checking parts, right? Not of the mem stat ones. Ian, do you expect to be adding this to libiberty so we can use it from GCC? Alternately, we could use Richi's approach I suppose (what happened to that patch, btw)? I have to get back to it. Maybe tomorrow ... Richard. Thanks. Diego. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: GCC stack backtraces
On Wed, Sep 12, 2012 at 2:31 PM, rguent...@suse.de wrote: Only of the checking parts, right? Not of the mem stat ones. Correct. I'm thinking mostly of operator[]. I have to get back to it. Maybe tomorrow ... Great, thanks. I will keep the macros around for now. They can be removed later. Diego.
Re: GCC stack backtraces
On Wed, Sep 12, 2012 at 9:50 AM, Diego Novillo dnovi...@google.com wrote: On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote: Diego already loves it! Indeed I do! I'm making changes in VEC that will benefit from this. I am currently keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to the methods that want it. But it would be nice if we could get rid of these macros. Ian, do you expect to be adding this to libiberty so we can use it from GCC? http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00754.html Ian
Re: Cgraph Modification Plan
On 9/12/12, Jan Hubicka hubi...@ucw.cz wrote:
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?
Yes, it seems sane.
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
I still do not gather why simple inheritance can't let me to write
node-whatever again...
If that is GTY limitation, I have no problem having this in
short term and update it later. symbol_node is really base of
functions/variables and new beasts we are going to get soon.
I implemented it as union only to make GTY happy.
It is a GTY limitation right now. We can do most of this work before
gengtype supports inheritance, and for that we need ref_symbol.
should not need to add these
cgraph_node symtab_node_def::ref_cgraph()
{ gcc_assert (symbol.type == SYMTAB_FUNCTION);
I think checking_assert is enough in these cases. We are getting
more conversions back and forth and we don't really want to have
asserts all around code.
The are untested conversions from base to derived. We should not
be using them, and hence they should be rare. I mention them only
because there might be places in the code where we get backed into
a corner. I've changed my notes to use gcc_checking_assert, and
we can revisit the decision whenever we need to.
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; }
I think try_function/try_variable reads better than cgraph/varpool
especially with the longer term plan to drop these names when
cgraph/varpool no longer exists and we have symbol table.
Okay, I will do that.
--
Lawrence Crowl
[Bug debug/54551] DF resets some DEBUG_INSNs unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-12 07:38:39 UTC --- Inefficient way to handle at least the single setter case would be at the start of the bb with non-empty debug uses bitmap (i.e. what is about to be reset) walk the immediate dominators up, looking for where DF_REG_DEF_COUNT (regno) == 1 pseudos (and perhaps with additional check that the single DF_REG_DEF_CHAIN (regno) insn's bb dominates the current bb) start to be live (and stop the walk at the setter bb). If it isn't live in lr at the end of some dominator bb but is live in lr at the start, then perhaps walk DF_REG_REF_CHAIN looking for refs inside of that bb, or walk the bb backwards looking for last non-debug use, insert before that), if it isn't live in lr at the start of a bb but is live in lr at the end of its immediate dominator, then insert debug temp before the end of that bb, and if it isn't live at the end of the setter bb, look also for the last non-debug use before the set.
[Bug c/54553] New: atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 Bug #: 54553 Summary: atribute optimize on function affects optimization for other functions Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ste...@gmail.com Created attachment 28175 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28175 tar.gz of files described in the case including sources We tried to use __attribute__((optimize(0))) on specific function for debug purposes while compiling code with -O2 and we encountered a strange behaviour. The function with attribute was not optimised, as expected but in addition all other functions in the c file that includes h file with that attribute were not optimised. My guess is that when compiler meets __attribute__ optimize - it just treats it as if it was #pragma thus not restoring the previous optimization state. Where are several files attached: 1) test1.i file with no __attribute__((optimize(0))) 2) test2.i file with __attribute__((optimize(0))) 3) test1.s assembly produced by test1 (f1, f2 and f3 are inlined) 4) test2.s assembly produced by test1 (none of the functions are inlined) 5) complier.out compiler output produced by x86_64-apple-darwin12-gcc-4.7.1 -v test2.c -o test2 -O2 --save P.S.: This dow not seems to be architecture dependent as we had a similar problem with mips cross-compiler on windows platform.
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-12 08:00:35 UTC --- This attribute is not very well tested
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 --- Comment #2 from Evgeny stelek at gmail dot com 2012-09-12 08:22:14 UTC --- Well, maybe it's time to test it. :-) (In reply to comment #1) This attribute is not very well tested
[Bug c/54554] New: Undetected use of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54554
Bug #: 54554
Summary: Undetected use of uninitialized variable
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dpapa...@gmail.com
Created attachment 28176
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28176
The output of the command line used to compile the snippet to stderr.
When compiling the snippet below:
---8--8--8--8--8--8--8--8---
extern int printf (__const char *__restrict __format, ...);
int main()
{
int j;
for (j = 0 ; j 10 ; j += 1) {
int i;
printf (%d\n, i);
i = 1;
}
return 0;
}
---8--8--8--8--8--8--8--8---
GCC fails to detect the use of an uninitialized variable. The command line
used to compile it is:
gcc -v -save-temps -Wall -Wextra -O0 -g -ansi -pedantic foo.c
Output to stderr has been attached. I won't attach the .i file as it simply
seems to contain a copy of the source. Let me know if you need it.
Bug 52523 seems to be related if not identical but I'm still submitting this as
this is C code not C++.
[Bug fortran/54387] [F03] Wrongly accepts non-proc result variable on the RHS of a proc-pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54387
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-09-12
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Summary|Proc-pointer: Wronlgy |[F03] Wrongly accepts
|accepts non-proc result |non-proc result variable on
|variable on the RHS of a|the RHS of a proc-pointer
|pointer assignment |assignment
Ever Confirmed|0 |1
--- Comment #2 from janus at gcc dot gnu.org 2012-09-12 09:17:36 UTC ---
Here is a draft patch which rejects the test case and is free of testsuite
regressions:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 190908)
+++ gcc/fortran/expr.c(working copy)
@@ -3430,6 +3430,14 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
gfc_resolve_intrinsic (sym, rvalue-where);
attr = gfc_expr_attr (rvalue);
}
+ /* Check for result of embracing function. */
+ if (sym == gfc_current_ns-proc_name
+ sym-attr.function sym-result == sym)
+{
+ gfc_error (Invalid proc-target in procedure pointer assignment
+ at %L, rvalue-where);
+ return FAILURE;
+}
}
if (attr.abstract)
{
[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 09:22:42 UTC --- Closing.
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-09-12
Ever Confirmed|0 |1
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12
09:33:25 UTC ---
Confirmed (I think we have a dup for this). -O0 (and switching opts) sets
flag_no_inline:
if (opts-x_optimize == 0)
{
/* Inlining does not work if not optimizing,
so force it not to be done. */
opts-x_warn_inline = 0;
opts-x_flag_no_inline = 1;
}
but restoring options does not restore this flag because it is not
among the options handled by cl_optimization_save/restore - it's not
an Optimization option:
; General flag to enable inlining. Specifying -fno-inline will disable
; all inlining apart from always-inline functions.
finline
Common Report Var(flag_no_inline,0) Init(0)
Enable inlining of function declared \inline\, disabling disables all
inlining
Index: gcc/common.opt
===
--- gcc/common.opt (revision 191209)
+++ gcc/common.opt (working copy)
@@ -1289,7 +1289,7 @@ Perform indirect inlining
; General flag to enable inlining. Specifying -fno-inline will disable
; all inlining apart from always-inline functions.
finline
-Common Report Var(flag_no_inline,0) Init(0)
+Common Report Var(flag_no_inline,0) Init(0) Optimization
Enable inlining of function declared \inline\, disabling disables all
inlining
finline-small-functions
might fix it.
[Bug rtl-optimization/54555] New: (set (REGX) (CONST_INT B)) - (set (STRICT_LOW_PART (REGX)) (CONST_INT B)) is pessimising
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54555
Bug #: 54555
Summary: (set (REGX) (CONST_INT B)) - (set (STRICT_LOW_PART
(REGX)) (CONST_INT B)) is pessimising
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
Target: m68k-*-*
Postreload (reload_cse_move2add) transforms
(set (REGX) (CONST_INT A))
...
(set (REGX) (CONST_INT B))
into
(set (REGX) (CONST_INT A))
...
(set (STRICT_LOW_PART (REGX)) (CONST_INT B))
which is a pessimisation on m68k if REGX is a data register and B is a small
constant in range for moveq which can no longer be used for the second SET;
instead moveb is used which is bigger and also slower on = m68030.
$ cat moveb.c
void foo (void);
void bar (int a)
{
if (a == 16 || a == 23) foo ();
if (a == -110 || a == -128) foo ();
}
$ gcc -O2 -S moveb.c
$ cat moveb.s
#NO_APP
.file moveb.c
.text
.align 2
.globl f
.type f, @function
f:
link.w %fp,#0
move.l %d2,-(%sp)
move.l 8(%fp),%d2
moveq #16,%d0
cmp.l %d2,%d0
jeq .L2
move.b #23,%d0 --- should be moveq #23,%d0
cmp.l %d2,%d0
jeq .L2
moveq #-110,%d0
cmp.l %d2,%d0
jeq .L4
.L13:
move.b #-128,%d0 --- should be moveq #-128,%d0
cmp.l %d2,%d0
jeq .L4
move.l -4(%fp),%d2
unlk %fp
rts
.L2:
jsr foo
moveq #-110,%d0
cmp.l %d2,%d0
jne .L13
.L4:
move.l -4(%fp),%d2
unlk %fp
jra bar
.size f, .-f
.ident GCC: (GNU) 4.8.0 20120912 (experimental)
.section.note.GNU-stack,,@progbits
This transformation was introduced in r68532 (gcc 3.4).
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 09:42:10 UTC --- Testing the patch.
[Bug c/54554] Undetected use of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54554 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-12 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 09:47:16 UTC --- By means of the assignment i becomes an induction variable and at -O0 we do not warn for maybe used uninitialized. With optimization the use is constant-propagated out. Thus, this is a known issue, not really the same as PR52523
[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 10:00:46 UTC --- This revision causes CP2K to produce wrong results at -O1 and above. I don't have a reduced testcase, other than compiling and building CP2K, but found this by bisection.
[Bug fortran/54225] [4.6/4.7/4.8 Regression] fortran compiler segfault processing ' print *, A(1,*) '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54225 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 10:05:28 UTC --- Author: burnus Date: Wed Sep 12 10:05:19 2012 New Revision: 191213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191213 Log: 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * array.c (match_subscript, gfc_match_array_ref): Fix diagnostic of coarray's '*'. 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * gfortran.dg/coarray_10.f90: Update dg-error. * gfortran.dg/coarray_28.f90: New. * gfortran.dg/array_section_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/array_section_3.f90 trunk/gcc/testsuite/gfortran.dg/coarray_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_10.f90
[Bug fortran/53306] [4.6/4.7/4.8 Regression] ICE on invalid 'array(*) =' statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53306 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 10:05:28 UTC --- Author: burnus Date: Wed Sep 12 10:05:19 2012 New Revision: 191213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191213 Log: 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * array.c (match_subscript, gfc_match_array_ref): Fix diagnostic of coarray's '*'. 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * gfortran.dg/coarray_10.f90: Update dg-error. * gfortran.dg/coarray_28.f90: New. * gfortran.dg/array_section_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/array_section_3.f90 trunk/gcc/testsuite/gfortran.dg/coarray_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_10.f90
[Bug c/54554] Undetected use of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54554 --- Comment #2 from Dimitris Papavasiliou dpapavas at gmail dot com 2012-09-12 10:19:20 UTC --- Specifying -O does indeed produce a warning if i is not assigned a constant value (for instance i = rand(); ). Omitting -O and specifying -Wmaybe-uninitialized does not produce anything though. Does that mean that warnings about possibly uninitialized variables are not supported at all, even if explicitly requested by the user when not optimizing? If that is the case then perhaps this should be documented in the manual. The latest version just mentions this for -Wmaybe-uninitialized: This warning is enabled by -Wall or -Wextra.
[Bug fortran/54556] New: [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 Bug #: 54556 Summary: [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: joost.vandevond...@mat.ethz.ch See PR 54389 and in particular PR 54389 comment 3. Joost writes there: This revision causes CP2K to produce wrong results at -O1 and above. Joost, if possible, can you nail down the file in which it occurs? That should be possible by looking at the .o files whether they change with or without the patch. I will try to come up with a scenario where implicit pure gets it wrong. Combining this with a failing test case is usually the best combination: One tends to find bugs both ways, but usually different ones. Besides having a bug in the implicit pure algorithm or in being unable to use it for this purpose, it might well be that the PURE handling in total has some bug, e.g. a slightly different semantic between Fortran and the middle end. If implicit pure is wrong, it will also affect other parts of the code. In any case, my working hypothesis is a bug in implicit pure. (With partial compilation, there might be also an issue when the .mod file claims implicit pure - and then the function gets changed to be no longer (implicitly) pure without recompilation of its users.) * * * Regarding the patch itself: http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-decl.c?r1=190757r2=190756pathrev=190757 The removal of || sym-attr.elemental fixes a bug. Thus, if you backout the patch, only remove || sym-attr.implicit_pure and do not re-add elemental.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 10:29:57 UTC --- (In reply to comment #0) Ian Harvey remarks there that Fortran 2008 removed a restriction regarding PURE. Dick Hendrickson asked at j3's mailing list (on 2012-09-05) whether that was intended; no reply so far.
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 10:33:53 UTC --- Author: rguenth Date: Wed Sep 12 10:33:47 2012 New Revision: 191215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191215 Log: 2012-09-12 Richard Guenther rguent...@suse.de PR middle-end/54553 * common.opt (finline): Mark with Optimization. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 10:33:53 UTC --- Author: rguenth Date: Wed Sep 12 10:33:47 2012 New Revision: 191215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191215 Log: 2012-09-12 Richard Guenther rguent...@suse.de PR middle-end/54553 * common.opt (finline): Mark with Optimization. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 10:34:18 UTC --- Fixed.
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 10:34:18 UTC --- Fixed.
[Bug middle-end/54553] atribute optimize on function affects optimization for other functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54553 --- Comment #7 from Evgeny Televitckiy stelek at gmail dot com 2012-09-12 10:37:33 UTC --- Thanks. Nice work guys!
[Bug c++/54557] New: [c++ lambda] error in assigning lambda expr though operator?: while catching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54557
Bug #: 54557
Summary: [c++ lambda] error in assigning lambda expr though
operator?: while catching
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
in this example
foo1 and foo2 do not compile, bar and foo3 do.
cat iflamda.cc
struct A {
int q;
bool sel;
bool bar(int i, int j) const;
bool foo1(int i, int j) const;
bool foo2(int i, int j) const;
bool foo3(int i, int j) const;
};
bool A:: bar(int i, int j) const {
auto f = sel ? [](int a, int b) { return ab;} :
[](int a, int b) { return ba;};
return f(i,j);
}
bool A::foo1(int i, int j) const {
auto f = sel ? [this](int a, int b) { return ab;} :
[this](int a, int b) { return ab+this-q;};
return f(i,j);
}
bool A::foo2(int i, int j) const {
int k = q;
auto f = sel ? [k](int a, int b) { return ab;} :
[k](int a, int b) { return ab+k;};
return f(i,j);
}
bool A::foo3(int i, int j) const {
auto f = sel ? [](int a, int b,int) { return ab;} :
[](int a, int b, int k) { return ab+k;};
return f(i,j,q);
}
Vincenzos-MacBook-Pro:ctest innocent$ c++ -O2 -std=gnu++11 -c iflamda.cc
iflamda.cc: In member function ‘bool A::foo1(int, int) const’:
iflamda.cc:24:60: error: no match for ternary ‘operator?:’ (operand types are
‘bool’, ‘A::foo1(int, int) const::__lambda2’, and ‘A::foo1(int, int)
const::__lambda3’)
[this](int a, int b) { return ab+this-q;};
^
iflamda.cc: In member function ‘bool A::foo2(int, int) const’:
iflamda.cc:33:51: error: no match for ternary ‘operator?:’ (operand types are
‘bool’, ‘A::foo2(int, int) const::__lambda4’, and ‘A::foo2(int, int)
const::__lambda5’)
[k](int a, int b) { return ab+k;};
^
Vincenzos-MacBook-Pro:ctest innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.1.0/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12.1.0
Configured with: ./configure --enable-languages=c,c++,fortran
--disable-multilib --disable-bootstrap --enable-lto -disable-libitm
Thread model: posix
gcc version 4.8.0 20120912 (experimental) [trunk revision 191215] (GCC)
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 11:41:12 UTC --- the two revisions lead to a lot of changes, all these files differ in their disassembled form: 1admm_methods.o Files f1 and f2 differ 2atom_fit.o Files f1 and f2 differ 3atom_pseudo.o Files f1 and f2 differ 9cp_ddapc_methods.o Files f1 and f2 differ 10cp_fm_basic_linalg.o Files f1 and f2 differ 11cp_ma_interface.o Files f1 and f2 differ 12cp_parser_inpp_methods.o Files f1 and f2 differ 13cp_parser_methods.o Files f1 and f2 differ 14dbcsr_dist_operations.o Files f1 and f2 differ 15dbcsr_example_3.o Files f1 and f2 differ 16dbcsr_index_operations.o Files f1 and f2 differ 17dbcsr_internal_operations.o Files f1 and f2 differ 18dbcsr_iterator_operations.o Files f1 and f2 differ 19dbcsr_operations.o Files f1 and f2 differ 20dbcsr_performance_multiply.o Files f1 and f2 differ 21dbcsr_test_add.o Files f1 and f2 differ 22dbcsr_test_methods.o Files f1 and f2 differ 23dbcsr_test_multiply.o Files f1 and f2 differ 24dbcsr_transformations.o Files f1 and f2 differ 25dbcsr_work_operations.o Files f1 and f2 differ 26efield_utils.o Files f1 and f2 differ 27et_coupling.o Files f1 and f2 differ 28f77_interface.o Files f1 and f2 differ 29fp_methods.o Files f1 and f2 differ 30helium_io.o Files f1 and f2 differ 31hfx_types.o Files f1 and f2 differ 32input_cp2k.o Files f1 and f2 differ 33lgrid_types.o Files f1 and f2 differ 34ma_affinity.o Files f1 and f2 differ 35mltfftsg.o Files f1 and f2 differ 36molsym.o Files f1 and f2 differ 37orbital_transformation_matrices.o Files f1 and f2 differ 38pair_potential.o Files f1 and f2 differ 39parallel_rng_types.o Files f1 and f2 differ 40paw_proj_set_types.o Files f1 and f2 differ 41preconditioner.o Files f1 and f2 differ 42pw_methods.o Files f1 and f2 differ 43pw_poisson_methods.o Files f1 and f2 differ 44pw_poisson_types.o Files f1 and f2 differ 45pw_pool_types.o Files f1 and f2 differ 46qs_gspace_mixing.o Files f1 and f2 differ 47qs_integrate_potential.o Files f1 and f2 differ 48qs_ks_methods.o Files f1 and f2 differ 49qs_neighbor_lists.o Files f1 and f2 differ 50qs_neighbor_list_types.o Files f1 and f2 differ 51qs_rho0_methods.o Files f1 and f2 differ 52qs_rho_methods.o Files f1 and f2 differ 53qs_scf_block_davidson.o Files f1 and f2 differ 54qs_scf_diagonalization.o Files f1 and f2 differ 55qs_scf.o Files f1 and f2 differ 56qs_vxc.o Files f1 and f2 differ 57restraint.o Files f1 and f2 differ 58rtp_admm_methods.o Files f1 and f2 differ 59rt_propagation_methods.o Files f1 and f2 differ 60sap_kind_types.o Files f1 and f2 differ 61scp_hartree_1center.o Files f1 and f2 differ 62se_core_matrix.o Files f1 and f2 differ 63se_fock_matrix_coulomb_ga.o Files f1 and f2 differ 64se_fock_matrix_coulomb_mpi.o Files f1 and f2 differ 65semi_empirical_expns3_methods.o Files f1 and f2 differ 66semi_empirical_par_utils.o Files f1 and f2 differ 67task_list_methods.o Files f1 and f2 differ 68thermostat_mapping.o Files f1 and f2 differ 69xc.o Files f1 and f2 differ
[Bug fortran/54225] [4.6/4.7/4.8 Regression] fortran compiler segfault processing ' print *, A(1,*) '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54225 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 12:15:52 UTC --- Author: burnus Date: Wed Sep 12 12:15:44 2012 New Revision: 191216 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191216 Log: 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * array.c (match_subscript, gfc_match_array_ref): Fix diagnostic of coarray's '*'. 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * gfortran.dg/coarray_10.f90: Update dg-error. * gfortran.dg/coarray_28.f90: New. * gfortran.dg/array_section_3.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/array_section_3.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/coarray_28.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/array.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/coarray_10.f90
[Bug fortran/53306] [4.6/4.7/4.8 Regression] ICE on invalid 'array(*) =' statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53306 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 12:15:54 UTC --- Author: burnus Date: Wed Sep 12 12:15:44 2012 New Revision: 191216 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191216 Log: 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * array.c (match_subscript, gfc_match_array_ref): Fix diagnostic of coarray's '*'. 2012-09-12 Tobias Burnus bur...@net-b.de PR fortran/54225 PR fortran/53306 * gfortran.dg/coarray_10.f90: Update dg-error. * gfortran.dg/coarray_28.f90: New. * gfortran.dg/array_section_3.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/array_section_3.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/coarray_28.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/array.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/coarray_10.f90
[Bug lto/54231] LTO generates code for the wrong CPU if different options used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231 --- Comment #14 from Thiago Macieira thiago at kde dot org 2012-09-12 13:02:23 UTC --- From GCC's own manual: (Node Function attributes): On the 386/x86_64 and PowerPC backends, the inliner will not inline a function that has different target options than the caller, unless the callee has a subset of the target options of the caller. For example a function declared with `target(sse3)' can inline a function with `target(sse2)', since `-msse3' implies `-msse2'.
[Bug middle-end/54493] -fguess-branch-probability takes ages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54493
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-09-12
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12
14:19:23 UTC ---
Because we accumulate gazillion predictors per BB and do linear scans over
them:
bool
gimple_predicted_by_p (const_basic_block bb, enum br_predictor predictor)
{
struct edge_prediction *i;
void **preds = pointer_map_contains (bb_predictions, bb);
if (!preds)
return false;
for (i = (struct edge_prediction *) *preds; i; i = i-ep_next)
if (i-ep_predictor == predictor)
return true;
return false;
}
Instrumenting gimple_predict_edge shows
Adding 22 to edge 2-13
Adding 22 to edge 2-3
Adding 22 to edge 2-4
Adding 22 to edge 2-5
Adding 22 to edge 2-6
Adding 22 to edge 2-7
Adding 22 to edge 2-8
Adding 22 to edge 2-9
Adding 22 to edge 2-10
Adding 22 to edge 2-11
Adding 22 to edge 2-12
Adding 22 to edge 2-13
Adding 22 to edge 2-14
Adding 22 to edge 2-15
Adding 22 to edge 2-16
Adding 22 to edge 2-17
Adding 22 to edge 2-18
Adding 22 to edge 2-19
Adding 22 to edge 2-20
Adding 22 to edge 2-21
Adding 22 to edge 2-22
...
Adding 22 to edge 2-17332
Adding 22 to edge 2-17333
Adding
(and continuing). 22 is the br_predictor (PRED_TREE_EARLY_RETURN).
It seems to me that we should have at most one predictor of each kind per
basic-block, no?
Testcase repeated:
int foo (int a, int b, int c)
{
int d;
switch (a)
{
#define X(N) \
case N ## 0: d = a + b; break; \
case N ## 1: d = a + b; break; \
case N ## 2: d = a + b; break; \
case N ## 3: d = a + b; break; \
case N ## 4: d = a + b; break; \
case N ## 5: d = a + b; break; \
case N ## 6: d = a + b; break; \
case N ## 7: d = a + b; break; \
case N ## 8: d = a + b; break; \
case N ## 9: d = a + b; break;
#define XX(N) \
X(N ## 0) X(N ## 1) X(N ## 2) X(N ## 3) X(N ## 4) X(N ## 5) X(N ## 6) X(N
## 7) X(N ## 8) X(N ## 9)
#define XXX(N) \
XX(N ## 0) XX(N ## 1) XX(N ## 2) XX(N ## 3) XX(N ## 4) XX(N ## 5) XX(N ##
6) XX(N ## 7) XX(N ## 8) XX(N ## 9)
#define (N) \
XXX(N ## 0) XXX(N ## 1) XXX(N ## 2) XXX(N ## 3) XXX(N ## 4) XXX(N ## 5)
XXX(N ## 6) XXX(N ## 7) XXX(N ## 8) XXX(N ## 9)
#define X(N) \
(N ## 0) (N ## 1) (N ## 2) (N ## 3) (N ## 4) (N ##
5) (N ## 6) (N ## 7) (N ## 8) (N ## 9)
X(1)
#if 0
X(2)
X(3)
X(4)
X(5)
X(6)
X(7)
X(8)
X(9)
#endif
}
return d;
}
[Bug middle-end/54493] -fguess-branch-probability takes ages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54493
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12
14:37:51 UTC ---
Something like
Index: gcc/predict.c
===
--- gcc/predict.c (revision 191222)
+++ gcc/predict.c (working copy)
@@ -525,8 +525,9 @@ void
gimple_predict_edge (edge e, enum br_predictor predictor, int probability)
{
gcc_assert (profile_status != PROFILE_GUESSED);
- if ((e-src != ENTRY_BLOCK_PTR EDGE_COUNT (e-src-succs) 1)
- flag_guess_branch_prob optimize)
+ if (flag_guess_branch_prob optimize
+ (e-src != ENTRY_BLOCK_PTR EDGE_COUNT (e-src-succs) 1)
+ !gimple_predicted_by_p (e-src, predictor))
{
struct edge_prediction *i = XNEW (struct edge_prediction);
void **preds = pointer_map_insert (bb_predictions, e-src);
of course that doesn't try to merge the predictors probability nor the
edge it is for. Why are the predictors stored per block and not per edge?
Another approach would be to fix this special case:
gimple_code (last) == GIMPLE_RETURN)
{
edge e1;
edge_iterator ei1;
if (single_succ_p (bb))
{
FOR_EACH_EDGE (e1, ei1, bb-preds)
if (!predicted_by_p (e1-src, PRED_NULL_RETURN)
!predicted_by_p (e1-src, PRED_CONST_RETURN)
!predicted_by_p (e1-src, PRED_NEGATIVE_RETURN))
predict_edge_def (e1, PRED_TREE_EARLY_RETURN, NOT_TAKEN);
which ends up adding all those (bogus?!) predications to the entry block.
Simplified we have
foo (int a, int b, int c)
{
int d;
bb 2:
switch (a_2(D)) default: L10, case 10: L0, ...
L0:
d_5 = a_2(D) + b_4(D);
goto bb 13 (L10);
...
L9:
d_14 = a_2(D) + b_4(D);
# d_1 = PHI d_3(D)(2), d_5(3), d_6(4), d_7(5), d_8(6), d_9(7), d_10(8),
d_11(9), d_12(10), d_13(11), d_14(12)
L10:
return d_1;
and we are adding the loads of !PRED_TREE_EARLY_RETURN to bb 2. Thus
as we are only adding PRED_TREE_EARLY_RETURN at this point we can also do
@@ -2113,13 +2113,15 @@ tree_estimate_probability_bb (basic_bloc
FOR_EACH_EDGE (e1, ei1, bb-preds)
if (!predicted_by_p (e1-src, PRED_NULL_RETURN)
!predicted_by_p (e1-src, PRED_CONST_RETURN)
-!predicted_by_p (e1-src, PRED_NEGATIVE_RETURN))
+!predicted_by_p (e1-src, PRED_NEGATIVE_RETURN)
+!predicted_by_p (e1-src, PRED_TREE_EARLY_RETURN))
predict_edge_def (e1, PRED_TREE_EARLY_RETURN, NOT_TAKEN);
}
else
if (!predicted_by_p (e-src, PRED_NULL_RETURN)
!predicted_by_p (e-src, PRED_CONST_RETURN)
-!predicted_by_p (e-src, PRED_NEGATIVE_RETURN))
+!predicted_by_p (e-src, PRED_NEGATIVE_RETURN)
+!predicted_by_p (e-src, PRED_TREE_EARLY_RETURN))
predict_edge_def (e, PRED_TREE_EARLY_RETURN, NOT_TAKEN);
}
(those predicted_by_p sequences are also inefficient as they repeat the
linear walk ...)
Honza?
[Bug tree-optimization/54489] tree FRE uses an excessive amount of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54489 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 14:46:35 UTC --- Author: rguenth Date: Wed Sep 12 14:46:22 2012 New Revision: 191225 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191225 Log: 2012-09-12 Richard Guenther rguent...@suse.de PR tree-optimization/54489 * tree-ssa-pre.c: Include domwalk.h. (in_fre): Remove. (sccvn_valnum_from_value_id): New function. (debug_bitmap_sets_for): Simplify. (get_representative_for): Properly initialize the SCCVN valnum. (create_expression_by_pieces): Likewise. (insert_into_preds_of_block): Likewise. (can_PRE_operation): Remove. (make_values_for_phi): Simplify. (compute_avail): Likewise. (do_SCCVN_insertion): Remove. (eliminate_avail, eliminate_push_avail, eliminate_insert): New functions. (eliminate): Split and perform a domwalk. (eliminate_bb): Former eliminate part that is now dom-enter. (eliminate_leave_block): New function. (fini_eliminate): Likewise. (init_pre): Simplify. (fini_pre): Likewise. (execute_pre): Fold into do_pre and do_fre. (do_pre): Consume execute_pre. (do_fre): Likewise. * Makefile.in (tree-ssa-pre.o): Add domwalk.h dependency. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/54489] tree FRE uses an excessive amount of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54489 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-12 14:48:22 UTC --- Fixed for GCC 4.8.
[Bug c/54558] New: get wrong answer in {static int a; a = 4; a += (a++);}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54558
Bug #: 54558
Summary: get wrong answer in {static int a; a = 4; a += (a++);}
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: soar...@foxmail.com
1. Code below should output a=9, however it output a=5
#include stdio.h
int main()
{
static int a;
a = 4;
a += (a++);
printf(a=%d\n, a);
return 0;
}
2. If omit static in static int a, compile and re-run, it output expected
result a=9
3. If omit ++ in a += (a++), compile and re-run, it output expected result
a=8
4. Using gcc -S code in 1, below is a segment of assembly code, hope that helps
movl $4, a.1817
movla.1817, %eax
movla.1817, %edx
addl%eax, %edx// %edx equals to 8
movl%edx, a.1817
addl$1, %eax// %eax equals to 5
movl%eax, a.1817
movla.1817, %eax
movl%eax, 4(%esp)
movl$.LC0, (%esp)
callprintf
movl$0, %eax
leave
5. information obtained by gcc -v -save-temps all-your-options source-file
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/src/gcc-4.7-20120721/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.1 20120721 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro'
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/cc1 -E -quiet -v app.c -mtune=generic
-march=pentiumpro -fpch-preprocess -o app.i
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/include
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro'
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/cc1 -fpreprocessed app.i -quiet -dumpbase
app.c -mtune=generic -march=pentiumpro -auxbase app -version -o app.s
GNU C (GCC) version 4.7.1 20120721 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 1.0
warning: MPC header version 1.0 differs from library version 1.0.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.7.1 20120721 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 1.0
warning: MPC header version 1.0 differs from library version 1.0.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b205659ec6a57a28c245e2c9c58a01b0
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro'
as -v --32 -o app.o app.s
GNU assembler version 2.22.0 (i686-pc-linux-gnu) using BFD version (GNU
Binutils) 2.22.0.20120323
COMPILER_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/:/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/:/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/:/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro'
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/collect2 --build-id --eh-frame-hdr
--hash-style=gnu -m elf_i386 -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.7.1
-L/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../.. app.o -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../crtn.o
[Bug c/54558] get wrong answer in {static int a; a = 4; a += (a++);}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54558 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2012-09-12 15:20:11 UTC --- Modifying an object twice between sequence points is undefined (use -Wall). See also http://c-faq.com/expr/seqpoints.html.
[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #9 from David Edelsohn dje at gcc dot gnu.org 2012-09-12 15:23:27 UTC --- Please add new testcases -- hopefully generic tests -- in the common part of the testsuite to cover this type of regression.
[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2012-09-12 15:29:26 UTC --- Please make sure to add a testcase to the testsuite.
[Bug preprocessor/54528] [4.8 Regression] system.h:288:78: error: integer overflow in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54528 --- Comment #3 from Mark Kettenis kettenis at gnu dot org 2012-09-12 15:48:34 UTC --- Created attachment 28177 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28177 Patch that fixes the problem
[Bug lto/54312] uniquify_nodes takes 12% of Mozilla LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54312 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-09-12 16:26:31 UTC --- Author: hubicka Date: Wed Sep 12 16:26:19 2012 New Revision: 191228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191228 Log: PR lto/54312 * lto.c (uniquify_nodes): Remove quadratic loop checking if the type is variant leader. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c
[Bug middle-end/54559] New: [4.7 Regression], ICE in gimplify_expr, at gimplify.c:7592
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54559
Bug #: 54559
Summary: [4.7 Regression], ICE in gimplify_expr, at
gimplify.c:7592
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
fails with r191092, worked with r190380 on the 4.7 branch, taken from a cython
testcase, with -O[0-3]:
$ gcc -c -g -O0 -I/usr/include/python2.7 pyx.c
pyx.c: In function '__pyx_t_long_double_complex_from_parts':
pyx.c:14:16: internal compiler error: in gimplify_expr, at gimplify.c:7592
Please submit a full bug report,
with preprocessed source if appropriate.
typedef struct {
double real;
double imag;
} Py_complex;
typedef struct _object {
unsigned int refcnt;
} PyObject;
typedef long double _Complex __pyx_t_long_double_complex;
static __inline__ __pyx_t_long_double_complex
__pyx_t_long_double_complex_from_parts(long double x, long double y)
{
return x + y*(__pyx_t_long_double_complex)(__extension__ 1.0iF);
}
static __pyx_t_long_double_complex
__Pyx_PyComplex_As___pyx_t_long_double_complex(PyObject* o) {
Py_complex cval;
return __pyx_t_long_double_complex_from_parts(
(long double)cval.real,
(long double)cval.imag);
}
[Bug other/54423] building trunk on Darwin 12.1 fails in building libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54423 --- Comment #1 from Nenad Vukicevic nenad at intrepid dot com 2012-09-12 17:27:24 UTC --- Has there been any attempt to confirm/resolve this bug? As it stands I am not able to build gcc on the latest Mountain Lion OS.
[Bug target/54445] TLS array lookup with negative constant is not combined into a single instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54445 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-09-12 18:09:08 UTC --- Author: hjl Date: Wed Sep 12 18:08:59 2012 New Revision: 191230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191230 Log: Allow negative offset for UNSPEC_DTPOFF/UNSPEC_NTPOFF gcc/ PR target/54445 * config/i386/predicates.md (x86_64_immediate_operand): Allow negative offset for UNSPEC_DTPOFF/UNSPEC_NTPOFF. gcc/testsuite/ PR target/54445 * gcc.target/i386/pr54445-1.c: New file. * gcc.target/i386/pr54445-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr54445-1.c trunk/gcc/testsuite/gcc.target/i386/pr54445-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug target/54445] TLS array lookup with negative constant is not combined into a single instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54445 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-09-12 18:09:08 UTC --- Author: hjl Date: Wed Sep 12 18:08:59 2012 New Revision: 191230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191230 Log: Allow negative offset for UNSPEC_DTPOFF/UNSPEC_NTPOFF gcc/ PR target/54445 * config/i386/predicates.md (x86_64_immediate_operand): Allow negative offset for UNSPEC_DTPOFF/UNSPEC_NTPOFF. gcc/testsuite/ PR target/54445 * gcc.target/i386/pr54445-1.c: New file. * gcc.target/i386/pr54445-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr54445-1.c trunk/gcc/testsuite/gcc.target/i386/pr54445-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-09-12 18:10:28 UTC --- Fixed for 4.8.0.
[Bug target/54445] TLS array lookup with negative constant is not combined into a single instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54445 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-09-12 18:10:28 UTC --- Fixed for 4.8.0.
[Bug c++/54560] New: g++ with --sysroot and -save-temps don't play nicely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54560 Bug #: 54560 Summary: g++ with --sysroot and -save-temps don't play nicely Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: i...@vmware.com We have a compiler built with a sysroot of /dev/null, thus it always requires a --sysroot argument. A developer noticed that g++'s -save-temps option doesn't work with this toolchain setup. What happens is it gets to the stage of turning the .ii file in to the asm file and cc1plus fails --- /usr/bin/../libexec/gcc/x86_64-vmk-linux-gnu/4.6.3/cc1plus -fpreprocessed foo.ii -quiet -dumpbase foo.cpp -m32 -march=i686 -auxbase-strip foo.o -g -O1 -Wall -Werror -Wno-unused-but-set-variable -Wno-conversion-null -Wno-non-virtual-dtor -version -fwrapv -fno-working-directory -funwind-tables -fasynchronous-unwind-tables -fstack-protector -fPIC -fno-strict-aliasing -o foo.s GNU C++ (GCC) version 4.6.3 (x86_64-vmk-linux-gnu) compiled by GNU C version 4.4.3, GMP version 5.0.4, MPFR version 2.4.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 cc1plus: error: /dev/null/usr/local/include: Not a directory cc1plus: error: /dev/null/usr/include: Not a directory GNU C++ (GCC) version 4.6.3 (x86_64-vmk-linux-gnu) compiled by GNU C version 4.4.3, GMP version 5.0.4, MPFR version 2.4.2, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 --- It's using the pre-processed source, so my feeling is that it doesn't require the sysroot argument here. Manually adding a -isysroot argument to *any* valid directory (doesn't have to be a directory with the correct sysroot hierarchy in it, e.g. /tmp) makes it work; so presumably the problem here is that /dev/null/usr/include doesn't exist. A quick search has not revealed to me where cc1plus is trying to access this directory... Another option might be to add a %I to the spec where this gets emitted [1] so that a valid -isysroot value gets passed? [1] http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/lang-specs.h;h=a73aba3cdc0dd970b068ce9172acdfeb20fbe7f5;hb=HEAD
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-09-12 19:52:55 UTC --- I'll take a look.
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-09-12 19:52:55 UTC --- I'll take a look. --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-09-12 19:53:30 UTC --- I'll take a look.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:11:24 UTC --- some progress.. the object file that leads to wrong results is parallel_rng_types.o. I'll see if I can get some further insight.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 20:22:58 UTC --- (In reply to comment #2) some progress.. the object file that leads to wrong results is parallel_rng_types.o. I'll see if I can get some further insight. It seems that - for some reason - IMPLICIT_PURE is only set for functions. (Or at least that's here the case for a simple test case.) If you produce a module, have a look at the .mod file and search for IMPLICIT_PURE. In my example I have something like: 3 's' 'm' '' 1 ((PROCEDURE [...] FUNCTION IMPLICIT_PURE) [...] where s is the name of my function and m is the name of the module. Then, check whether that procedure could be PURE or has to be IMPURE.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:26:49 UTC --- (In reply to comment #3) (In reply to comment #2) some progress.. the object file that leads to wrong results is parallel_rng_types.o. I'll see if I can get some further insight. It seems that - for some reason - IMPLICIT_PURE is only set for functions. (Or at least that's here the case for a simple test case.) If you produce a module, have a look at the .mod file and search for IMPLICIT_PURE. In my example I have something like: 3 's' 'm' '' 1 ((PROCEDURE [...] FUNCTION IMPLICIT_PURE) [...] where s is the name of my function and m is the name of the module. Then, check whether that procedure could be PURE or has to be IMPURE. yes, I think from looking at the optimized dumps, I can see that a function that is called twice in the correct version is called only once in the wrong version. I think I might be able to reduce it to a testcase. (If you care, the function is rn53 which calls rn32 only once, so I guess that's the issue).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #27 from Larry Baker baker at usgs dot gov 2012-09-12 20:42:22 UTC --- Created attachment 28178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28178 Patch for trunk version 2012-09-09 of libgcc/config.host To fix the same bug reported for GCC 4.7 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:46:05 UTC --- Created attachment 28179 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28179 testcase
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:50:40 UTC --- The testcase illustrates the issue, compiling as gfortran -c -O1 test.f90 -fdump-tree-optimized shows that rn32 is only called once from rn53, whereas the proper number would be 2 or 3. So I guess rn32 is incorrectly marked as pure.
[Bug c/54561] New: incorrect setjmp -Wclobber diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54561 Bug #: 54561 Summary: incorrect setjmp -Wclobber diagnostics Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: egg...@gnu.org Created attachment 28180 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28180 generates incorrect diagnostics with gcc -O2 -Wclobbered If I compile the attached program via the command gcc -S -Wclobbered -O2 w.i (GCC 4.7.1, x86-64, Fedora 17), the output is: w.i: In function 'png_load_body': w.i:37:13: warning: variable 'info_ptr' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered] w.i:38:9: warning: variable 'fp' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered] Both warnings are incorrect, because info_ptr and fp are not live across any possible longjmp. If longjmp munges these variables, setjmp must return a nonzero value, and no uses of these variables are reachable in that case. Like Bug#48968, I ran into this problem when building Emacs. This test case is much shorter, though (I whittled it down), so it should be easier to debug.
[Bug c++/54557] [c++ lambda] error in assigning lambda expr though operator?: while catching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54557
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-09-12 20:54:26 UTC ---
The compiler behaviour looks correct to me. The difference of the lambda
expressions in bar and foo3 compared to the other two is that these are
capture-free lambdas and thus have a conversion function to function pointer.
Each lambda expression corresponds to a unique class type, so what we have in
foo1 and foo2 can be compared with the following class-example:
struct A{};
struct B{};
void f() {
false ? A() : B();
}
This expression has no common type for the conditional operator and is
ill-formed.
What we have in bar and foo3 can be compared with the following class-example :
struct A{ typedef void (*F)(); operator F(); };
struct B{ typedef void (*F)(); operator F(); };
void f() {
false ? A() : B();
}
This is well-formed, because in the last step of the conditional operator
conversion attempts (5.16p5), more general conversions are attempted and these
find the common pointer to function.
The current compiler behaviour gives a correct diagnostics and I see nothing
wrong with it.
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #2 from Larry Baker baker at usgs dot gov 2012-09-12 20:55:00 UTC --- Same bug occurs fo GCC 4.8. Here's the patch I used to build a GCC 4.8 cross-compiler: --- gcc-4.8-20120909/libgcc/config.host +++ gcc-4.8-20120909-patched/libgcc/config.host @@ -704,3 +704,3 @@ m68k-*-uclinux*)# Motorola m68k/ColdFire running uClinux with uClibc -tmake_file=$tmake_file m68k/t-floatlib m68k/t-linux +tmake_file=$tmake_file m68k/t-floatlib md_unwind_header=m68k/linux-unwind.h
[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 --- Comment #8 from Carrot carrot at google dot com 2012-09-12 20:57:33 UTC --- (In reply to comment #7) This rings a bell. Maybe the patch mentioned below needs backporting given Carrot is reporting this against the 4.6 branch. What's not clear if this is reproducible on anything later though. http://old.nabble.com/-PATCH--Prevent-cselib-substitution-of-FP,-SP,-SFP-td33080657.html The patch can fix this bug.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:58:23 UTC --- (In reply to comment #6) So I guess rn32 is incorrectly marked as pure. which indeed is also visible in the .mod file: 'rn32' 'parallel_rng_types' '' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0 0 FUNCTION IMPLICIT_PURE ALWAYS_EXPLICIT)
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 21:00:32 UTC --- Test case: Compile in two files with -O0/-O1/-O2/ give the expected i == 5 but using -O3 hoists the i = s(x) out of the loop and thus gives i == 1. Question: Why is IMPLICIT_PURE set. For a PURE function, one gets: Variable 'x' can not appear in a variable definition context ! -- FILE 1 -- module m type t integer :: i = 0 end type t contains integer function s(x) type(t), pointer :: x x%i = x%i + 1 s = x%i end function s end module m ! --- FILE 2 -- use m type(t), pointer :: x integer :: i, j, k allocate(x) x%i = 0 do k = 1, 5 i = s(x) end do print *, i if (i /= 5) call abort () end
[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54561 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-12 21:02:37 UTC --- Both info_ptr and fp are alive across the setjmp. GCC does not do fancy detection of alive on one of branches of the result of setjmp. It just warns if it is alive across on either branch on setjmp.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12
21:11:54 UTC ---
Untested patch.
The first and second part allows VALUE for implicit_pure (in line with F2008
for PURE).
The third part is the crucial change: If there is a pointer, assume that the
procedure is not implicit_pure.
Note: A proper patch should also take BT_CLASS into account - and proc-pointer
arguments.
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -426,12 +426,16 @@ resolve_formal_arglist (gfc_symbol *proc)
}
else if (!sym-attr.pointer)
{
- if (proc-attr.function sym-attr.intent != INTENT_IN)
+ if (proc-attr.function sym-attr.intent != INTENT_IN
+ !sym-attr.value)
proc-attr.implicit_pure = 0;
- if (proc-attr.subroutine sym-attr.intent == INTENT_UNKNOWN)
+ if (proc-attr.subroutine sym-attr.intent == INTENT_UNKNOWN
+ !sym-attr.value)
proc-attr.implicit_pure = 0;
}
+ else
+ proc-attr.implicit_pure = 0;
}
if (gfc_elemental (proc))
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org 2012-09-12 21:51:21 UTC --- Author: hubicka Date: Wed Sep 12 21:51:14 2012 New Revision: 191232 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191232 Log: PR fortran/48636 * gcc.dg/ipa/inlinehint-2.c: New testcase. * ipa-inline-analysis.c (dump_inline_hints): Dump loop stride. (set_hint_predicate): New function. (reset_inline_summary): Reset loop stride. (remap_predicate_after_duplication): New function. (remap_hint_predicate_after_duplication): New function. (inline_node_duplication_hook): Update. (dump_inline_summary): Dump stride summaries. (estimate_function_body_sizes): Compute strides. (remap_hint_predicate): New function. (inline_merge_summary): Use it. (inline_read_section): Read stride. (inline_write_summary): Write stride. * ipa-inline.c (want_inline_small_function_p): Handle strides. (edge_badness): Likewise. * ipa-inline.h (inline_hints_vals): Add stride hint. (inline_summary): Update stride. Added: trunk/gcc/testsuite/gcc.dg/ipa/inlinehint-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-inline.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/54208] [4.6/4.7/4.8 Regression] compilation error for ubound construct in PARAMETER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54208 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org 2012-09-12 21:54:57 UTC --- Author: mikael Date: Wed Sep 12 21:54:50 2012 New Revision: 191233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191233 Log: fortran/ PR fortran/54208 * simplify.c (simplify_bound_dim): Resolve array spec before proceeding with simplification. testsuite/ PR fortran/54208 * gfortran.dg/bound_simplification_3.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/bound_simplification_3.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/simplify.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/54208] [4.6/4.7/4.8 Regression] compilation error for ubound construct in PARAMETER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54208 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org 2012-09-12 22:01:10 UTC --- Fixed for releases [4.6.4], [4.7.2], [4.8.0]. Thanks for the bug report.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-12 Ever Confirmed|0 |1 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-12 22:18:15 UTC --- In expr.c's gfc_check_vardef_context one calls: if (!pointer context gfc_implicit_pure (NULL) gfc_impure_variable (sym)) The problem is that the latter has (cf. resolve.c): if (sym-attr.dummy gfc_pure (proc) ((proc-attr.subroutine sym-attr.intent == INTENT_IN) || proc-attr.function)) The issue is gfc_pure. Draft patch (replaces the one in comment 9): --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -13567,6 +13572,5 @@ gfc_impure_variable (gfc_symbol *sym) proc = sym-ns-proc_name; - if (sym-attr.dummy gfc_pure (proc) -((proc-attr.subroutine sym-attr.intent == INTENT_IN) - || -proc-attr.function)) + if (sym-attr.dummy + ((proc-attr.subroutine sym-attr.intent == INTENT_IN) + || proc-attr.function)) return 1;
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #43 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-12 22:30:41 UTC --- Is bug #28831 a dup of this? Not exactly, PR middle-end/28831 is a generic problem while this one is specific to architectures that can return structures in registers.
[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890 --- Comment #10 from Pat Haugen pthaugen at gcc dot gnu.org 2012-09-12 23:04:55 UTC --- Created attachment 28181 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28181 Reduced testcase Martin, Have you done any more digging on this? I just discovered that cpu2006 benchmark 471.omnetpp suffers the same problem (8 byte loads turned in to sequence of byte loads/shifts/ors). It causes a 12% degradation on PowerPC, and also goes away when -fno-ipa-sra is added. I'm attaching a reduced testcase that can be compiled with g++ -S -O3 -m64 -mcpu=power7.
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #44 from Chip Salzenberg chip at pobox dot com 2012-09-12 23:21:21 UTC --- Note that the x86 target has been changed in svn to use TImode for 128-bit structures, and structures bigger than 128 bits may not be passed in registers, so triggering this bug may be quite different now.
[Bug middle-end/54561] incorrect setjmp -Wclobber diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54561 --- Comment #2 from eggert at gnu dot org 2012-09-12 23:39:16 UTC --- GCC ... warns if it is alive across on either branch on setjmp. OK, thanks, that's the bug then. GCC should warn only about the longjmp branch, not about the non-lonjmp branch. Can GCC model the longjmp branch as assigning garbage to all the nonvolatile locals, and then use the algorithm it's already using when it warns about use of uninitialized locals? Something like that should do the trick.
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #45 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-12 23:59:03 UTC --- Note that the x86 target has been changed in svn to use TImode for 128-bit structures, and structures bigger than 128 bits may not be passed in registers, so triggering this bug may be quite different now. That's largely orthogonal, not all structures can have an integer mode.
[Bug preprocessor/54528] [4.8 Regression] system.h:288:78: error: integer overflow in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54528 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-09-13 00:44:15 UTC --- (In reply to comment #3) Created attachment 28177 [details] Patch that fixes the problem Works for me. I believe the problem is the overflow detection in the new code.
[Bug libstdc++/54562] New: mutex and condition variable timers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562 Bug #: 54562 Summary: mutex and condition variable timers Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zol...@epochcapital.com.au Created attachment 28182 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28182 std::timed_mutex::try_lock_for test Hello, 1., When using std::timed_mutex::try_lock_for() with high precision timers enabled on Linux the method will return immediately, rather than after the given time duration has elapsed. This is because it uses the CLOCK_MONOTONIC clock (if available on the platform) to calculate the absolute time when it needs to return, which is incorrect as the POSIX pthread_mutex_timedlock() call uses the CLOCK_REALTIME clock, and on my platform the monotonic clock is way behind the real time clock. Please see the attached cpptest.cpp file to reproduce the problem: $ g++-4.7.1 -std=gnu++11 cpptest.cpp -o cpptest $ ./cpptest mutex locked delay: 0 It should have displayed delay: 3 instead. 2., std::condition_variable uses the std::chrono::system_clock for timed waits, I suggest changing that to std::chrono::high_resolution_clock which has the same precision as the POSIX pthread_cond_timedwait() function. My platform: # uname -a Linux epcau-srv-dev 2.6.33.7-rt29-0.5-rt #1 SMP PREEMPT RT 2010-08-25 19:40:23 +0200 x86_64 x86_64 x86_64 GNU/Linux # g++-4.7.1 -v Reading specs from /opt/epoch/lib64/gcc/x86_64-suse-linux/4.7.1/specs COLLECT_GCC=g++-4.7.1 COLLECT_LTO_WRAPPER=/opt/epoch/lib64/gcc/x86_64-suse-linux/4.7.1/lto-wrapper Target: x86_64-suse-linux Configured with: ../gcc-4.7.1-mutex/configure --build=x86_64-suse-linux --prefix=/opt/epoch --libdir=/opt/epoch/lib64 --libexecdir=/opt/epoch/lib64 --with-slibdir=/opt/epoch/lib64/gcc/x86_64-suse-linux/4.7.1/libgcc/lib64 --with-gxx-include-dir=/opt/epoch/include/c++/4.7.1 --program-suffix=-4.7.1 --enable-version-specific-runtime-libs --enable-languages=c++ --disable-nls --disable-libssp --enable-__cxa_atexit --with-system-zlib --enable-gold --with-plugin-ld=/usr/bin/gold --enable-lto --enable-libstdcxx-time=rt --enable-linux-futex --enable-libstdcxx-threads --enable-libstdcxx-debug --enable-libstdcxx-allocator=new Thread model: posix gcc version 4.7.1 (GCC)
[Bug libstdc++/54562] mutex and condition variable timers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562 --- Comment #1 from Zoltan Glozik zoltan at epochcapital dot com.au 2012-09-13 02:24:24 UTC --- Created attachment 28183 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28183 suggested patch
[Bug middle-end/54559] [4.7 Regression], ICE in gimplify_expr, at gimplify.c:7592
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54559 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-13 CC||jakub at redhat dot com Target Milestone|--- |4.7.2 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-09-13 03:42:17 UTC --- It was caused by revision 190899: http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00056.html
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #28 from tejohnson at gcc dot gnu.org 2012-09-13 04:59:18 UTC --- Author: tejohnson Date: Thu Sep 13 04:59:14 2012 New Revision: 191238 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191238 Log: This fixes PR gcov-profile/54487 where the gcda files were not locked by the profile-use read, enabling writes by other instrumented compiles to change the profile in the middle of the profile use read. The GCOV_LOCKED macro was not set because it was guarded by HOST_HAS_F_SETLKW, which was never set. The fix is to add a compile test in the configure to set it. 2012-09-12 Teresa Johnson tejohn...@google.com PR gcov-profile/54487 * configure.ac (HOST_HAS_F_SETLKW): Set based on compile test using F_SETLKW with fcntl. * configure, config.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac
[AARCH64] AArch64 backport to 4.7
[AARCH64] AArch64 backport to 4.7. This series of patches implements a back port of the AArch64 backend to gcc-4.7. This patch series is not intended to be applied directly to the gcc-4_7-branch branch. We have pushed a new branch into SVN to host this back port, located at: svn://gcc.gnu.org/gcc/branches/ARM/aarch64-4.7-branch This branch will track 4.7. Patches to this branch should be tagged [AARCH64-4.7] and must be approved by ARM personnel. The branch was constructed using the following steps: . Copied gcc-4_7-branch. . Copied the AArch64 port from ARM/aarch64-branch. . Applied the attached AArch64 backport patch. . Applied the attached backport patch to implement integer iterators. . Updated config.sub and config.guess from upstream gnuconfig. Thank you aarch64-backport.patch Description: Binary data aarch64-int-iterators-backport.patch Description: Binary data
[SH] Correct address cost estimations
Hello,
This corrects the address cost estimations for SH.
Tested on rev 191161 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
With this applied CSiBE shows a total size decrease of 4668 bytes for
'-O2 -m4-single -ml -mpretend-cmove'.
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.c (sh_rtx_costs): Add handling of MEM,
SIGN_EXTEND, ZERO_EXTEND and PARALLEL cases.
(sh_address_cost): Correct rtx parsing and tweak cost
estimations.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 191161)
+++ gcc/config/sh/sh.c (working copy)
@@ -3196,6 +3196,78 @@
}
return false;
+/* The cost of a mem access is mainly the cost of the address mode. */
+case MEM:
+ *total = sh_address_cost (XEXP (x, 0), GET_MODE (x), MEM_ADDR_SPACE (x),
+true);
+ return true;
+
+/* The cost of a sign or zero extend depends on whether the source is a
+ reg or a mem. In case of a mem take the address into acount. */
+case SIGN_EXTEND:
+ if (REG_P (XEXP (x, 0)))
+ {
+ *total = COSTS_N_INSNS (1);
+ return true;
+ }
+ if (MEM_P (XEXP (x, 0)))
+ {
+ *total = sh_address_cost (XEXP (XEXP (x, 0), 0),
+GET_MODE (XEXP (x, 0)),
+MEM_ADDR_SPACE (XEXP (x, 0)), true);
+ return true;
+ }
+ return false;
+
+case ZERO_EXTEND:
+ if (REG_P (XEXP (x, 0)))
+ {
+ *total = COSTS_N_INSNS (1);
+ return true;
+ }
+ else if (TARGET_SH2A MEM_P (XEXP (x, 0))
+ (GET_MODE (XEXP (x, 0)) == QImode
+ || GET_MODE (XEXP (x, 0)) == HImode))
+ {
+ /* Handle SH2A's movu.b and movu.w insn. */
+ *total = sh_address_cost (XEXP (XEXP (x, 0), 0),
+GET_MODE (XEXP (x, 0)),
+MEM_ADDR_SPACE (XEXP (x, 0)), true);
+ return true;
+ }
+ return false;
+
+/* mems for SFmode and DFmode can be inside a parallel due to
+ the way the fpscr is handled. */
+case PARALLEL:
+ for (int i = 0; i XVECLEN (x, 0); i++)
+ {
+ rtx xx = XVECEXP (x, 0, i);
+ if (GET_CODE (xx) == SET MEM_P (XEXP (xx, 0)))
+ {
+ *total = sh_address_cost (XEXP (XEXP (xx, 0), 0),
+ GET_MODE (XEXP (xx, 0)),
+ MEM_ADDR_SPACE (XEXP (xx, 0)), true);
+ return true;
+ }
+ if (GET_CODE (xx) == SET MEM_P (XEXP (xx, 1)))
+ {
+ *total = sh_address_cost (XEXP (XEXP (xx, 1), 0),
+ GET_MODE (XEXP (xx, 1)),
+ MEM_ADDR_SPACE (XEXP (xx, 1)), true);
+ return true;
+ }
+ }
+
+ if (sh_1el_vec (x, VOIDmode))
+ *total = outer_code != SET;
+ else if (sh_rep_vec (x, VOIDmode))
+ *total = ((GET_MODE_UNIT_SIZE (GET_MODE (x)) + 3) / 4
+ + (outer_code != SET));
+ else
+ *total = COSTS_N_INSNS (3) + (outer_code != SET);
+ return true;
+
case CONST_INT:
if (TARGET_SHMEDIA)
{
@@ -3271,7 +3343,10 @@
else
*total = 10;
return true;
+
case CONST_VECTOR:
+/* FIXME: This looks broken. Only the last statement has any effect.
+ Probably this could be folded with the PARALLEL case? */
if (x == CONST0_RTX (GET_MODE (x)))
*total = 0;
else if (sh_1el_vec (x, VOIDmode))
@@ -3339,15 +3414,6 @@
*total = COSTS_N_INSNS (20);
return true;
-case PARALLEL:
- if (sh_1el_vec (x, VOIDmode))
- *total = outer_code != SET;
- if (sh_rep_vec (x, VOIDmode))
- *total = ((GET_MODE_UNIT_SIZE (GET_MODE (x)) + 3) / 4
- + (outer_code != SET));
- *total = COSTS_N_INSNS (3) + (outer_code != SET);
- return true;
-
case FLOAT:
case FIX:
*total = 100;
@@ -3430,36 +3496,47 @@
/* Compute the cost of an address. */
static int
-sh_address_cost (rtx x, enum machine_mode mode ATTRIBUTE_UNUSED,
+sh_address_cost (rtx x, enum machine_mode mode,
addr_space_t as ATTRIBUTE_UNUSED, bool speed ATTRIBUTE_UNUSED)
{
+ /* Simple reg, post-inc, pre-dec addressing. */
+ if (REG_P (x) || GET_CODE (x) == POST_INC || GET_CODE (x) == PRE_DEC)
+return 1;
+
/* 'reg + disp' addressing. */
- if (satisfies_constraint_Sdd (x))
+ if (GET_CODE (x) == PLUS
+ REG_P (XEXP (x, 0)) CONST_INT_P (XEXP (x, 1)))
{
- const HOST_WIDE_INT offset = disp_addr_displacement (x);
- const enum machine_mode mode = GET_MODE (x);
+ const HOST_WIDE_INT offset = INTVAL (XEXP (x, 1));
- /* The displacement would fit into a 2 byte move insn. */
+ if (offset == 0)
+ return 1;
+
+ /* The displacement would fit into a 2 byte move insn.
+ HImode and QImode loads/stores with displacement put pressure on
+ R0 which will most likely require another reg copy. Thus account
+ a higher cost for that. */
if (offset 0 offset = max_mov_insn_displacement (mode, false))
- return 0;
+ return (mode == HImode || mode == QImode) ? 2 : 1;
/* The displacement would fit into a 4 byte move insn
Re: Obsolete picochip-* in 4.7.2+
On Tue, Sep 11, 2012 at 5:21 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
As discussed on IRC, the picochip-* port doesn't have an active maintainer
anymore, this patch adds it to deprecated ports for 4.7.2+ so that it can be
removed in
GCC 4.8 unless somebody steps up to maintain it.
Ok for trunk/4.7?
Ok.
Thanks,
Richard.
2012-09-11 Jakub Jelinek ja...@redhat.com
* config.gcc: Obsolete picochip-*.
--- gcc/config.gcc 2012-09-05 14:52:14.428548941 +0200
+++ gcc/config.gcc 2012-09-11 17:05:15.147522191 +0200
@@ -245,7 +245,8 @@ md_file=
# Obsolete configurations.
case ${target} in
- score-* \
+ picochip-* \
+ | score-* \
)
if test x$enable_obsolete != xyes; then
echo *** Configuration ${target} is obsolete. 2
--- gcc-4.7/changes.html10 Aug 2012 16:25:46 - 1.124
+++ gcc-4.7/changes.html11 Sep 2012 15:15:38 -
@@ -29,7 +29,14 @@
next release of GCC will have their sources permanently
strongremoved/strong./p
-p id=obsoletedThe following ports for individual systems on
+p id=obsoletedAll GCC ports for the following processor
+architectures have been declared obsolete:/p
+
+ul
+ lipicoChip (codepicochip-*/code)/li
+/ul
+
+pThe following ports for individual systems on
particular architectures have been obsoleted:/p
ul
Jakub
Re: [PATCH,mmix] convert to constraints.md
- Original Message - Nathan, again thanks. There are a few minor tweaks compared to your version: Thanks for fixing this up! - Keeping old layout of mmix_reg_or_8bit_operand. That looked like a spurious change and I prefer the ior construct to the if_then_else. ISTR without this change, there were lots of assembly changes like: set rx, 6 cmp rz, ry, rx instead of the previous and better: cmp rz, ry, 6 (apologies if the assembly syntax isn't correct; hopefully the intent is clear) but if you double-checked that the assembly didn't change after your changes, maybe something else that you tweaked fixed this. - Replacing undefined-constraint-H with I instead of removing it. It was either renamed early or a genuine typo. Good catch. Hard not to see it; the gen* machinery complains about undefined constraints. :) -Nathan
Re: [C++ Patch] Remove uses of ATTRIBUTE_UNUSED in the function parameters
On Tue, Sep 11, 2012 at 5:37 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Sep 11, 2012 at 05:29:12PM +0200, Paolo Carlini wrote: PS: slightly interesting, in a couple of cases - write_unnamed_type_name, wrap_cleanups_r - the parameters were actually used. Just a general comment, often an argument is only conditionally used, e.g. depending on some preprocessor macro (e.g. target hook). In that case unnamed parameter is not an option, but dropping ATTRIBUTE_UNUSED is not desirable either. And note that we have ARG_UNUSED for parameters - to cope with older compilers not handling attributes here too well (I run into this when using gcc 3.3 as host compiler). Richard. Jakub
Re: Backtrace library [3/3]
On 09/12/2012 12:55 AM, Ian Lance Taylor wrote:
I have finished the initial implementation of the backtrace library I
proposed at http://gcc.gnu.org/ml/gcc/2012-08/msg00317.html . I've
separated the work into three patches. These patches only implement the
backtrace library itself; actual use of the library will follow in
separate patches.
I'm trying to add a few comments below. I hope Thunderbird does not
garble them too much.
+backtrace_open (const char *filename, backtrace_error_callback
error_callback,
+ void *data)
+{
+ int descriptor;
+
+ descriptor = open (filename, O_RDONLY | O_CLOEXEC);
+ if (descriptor 0)
+{
+ error_callback (data, filename, errno);
+ return -1;
+}
+ if (O_CLOEXEC == 0)
+{
+ /* It doesn't matter if this fails for some reason. */
+ fcntl (descriptor, F_SETFD, FD_CLOEXEC);
+}
You should call fcntl unconditionally. O_CLOEXEC might be non-zero
during build, but could still be ignored by the kernel.
+static void
+fileline_initialize (backtrace_error_callback error_callback, void *data)
+{
...
+ if (executable_name != NULL)
+descriptor = backtrace_open (executable_name, error_callback, data);
+ else
+descriptor = backtrace_open (/proc/self/exe, error_callback, data);
You should try getauxval(AT_EXECFN) as well (needs recent glibc), so
that this works with a mounted /proc.
This library should only be used when getauxval(AT_SECURE) is zero, so
that the program doesn't try to read files with elevated privileges to
which the original user wouldn't have access. I don't think this has to
be addressed within the library itself.
Adding /usr/lib/debug support shouldn't be too hard, I will try to
figure out the required path transformations (which are somewhat
system-specific).
--
Florian Weimer / Red Hat Product Security Team
Re: [PATCH] Combine location with block using block_locations
On Tue, Sep 11, 2012 at 5:32 PM, Michael Matz m...@suse.de wrote: Hi, On Tue, 11 Sep 2012, Dehao Chen wrote: Looks like we have two choices: 1. Stream out block info, and use LTO_SET_PREVAIL for TREE_CHAIN(t) This will actually not work correctly in some cases. The problem is, if the prevailing decl is already part of another chain (say in another block_var list) you would break the current chain. Hence block vars need special handling in the lto streamer (another reason why tree_chain is not the most clever think to use for this chain). This problem area needs to be solved somehow if block info is to be preserved correctly. Well. The issue is that at present we stream BLOCKs in the function section via its DECL_INTIAL. Which means we _never_ should get a non-prevailing DECL in BLOCK_VARS. You need to debug why that doesn't work anymore. Possibly the BLOCK leaks into decls it should not leak to via the location mechanism? 2. Don't stream out block info for LTO, and still call LTO_NO_PREVAIL (TREE_CHAIN (t)). That's also a large hammer as it basically will mean no debug info after LTO :-/ Sigh, at this point I have no good solution that doesn't involve quite some work, perhaps your hack is good enough for the time being, though I hate it :) It hides a bug. If we replace anything in BLOCK_VARS then the risk is that you generate an infinite chain in some BLOCK_VARS list and thus get infinite loops somewhere in the compiler. So, no, that's not an option. Richard. Ciao, Michael.
Re: [PATCH] Combine location with block using block_locations
On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen de...@google.com wrote: Now I think we are facing a more complex problem. The data structure we use to store the location_adhoc_data are file-static in linemap.c in libcpp. These data structures are not guarded by GTY(()). Meanwhile, as we have removed the block data structure from gimple.gsbase as well as tree.exp (encoding them into an location_t). This could cause block being GCed and the LOCATION_BLOCK becoming dangling pointers. Uh. Note that it is quite important that we are able to garbage-collect unused BLOCKs, this is the whole point of removing unused BLOCK scopes in remove_unused_locals. So this indeed becomes much more complicated ... What would be desired is that the garbage collector can NULL an entry in the mapping table when it is not referenced in any other way (that other reference would be the BLOCK tree as stored in a FUNCTION_DECLs DECL_INITIAL). I tried to manipulate GTY to make it recognize the LOCATION_BLOCK from gimple.gsbase.location. However, neigher nested_ptr nor mark_hook can help me. Another approach would be guard the location_adhoc_data and related data structures in GTY(()). However, this is non-trivial because tree is not visible in libcpp. At the same time, my implementation heavily relies on hashtable to make the code efficient, thus it's quite tricky to make param_is and use_params work. The final approach, which I'll try tomorrow, would be move all my implementation from libcpp to gcc, and guard them with GTY(()). I still haven't thought of any potential problem of this approach. Any comments? I think moving the mapping to GC in a lazy manner as I described above would be the way to go. For hashtables GC already supports if_marked, not sure if similar support is available for arrays/vecs. Richard. Thanks, Dehao On Tue, Sep 11, 2012 at 9:00 AM, Dehao Chen de...@google.com wrote: I saw comments in tree-streamer-out.c: /* Do not stream BLOCK_SOURCE_LOCATION. We cannot handle debug information for early inlining so drop it on the floor instead of ICEing in dwarf2out.c. */ streamer_write_chain (ob, BLOCK_VARS (expr), ref_p); However, what the code is doing seemed contradictory with the comment. Or am I missing something? On Tue, Sep 11, 2012 at 8:32 AM, Michael Matz m...@suse.de wrote: Hi, On Tue, 11 Sep 2012, Dehao Chen wrote: Looks like we have two choices: 1. Stream out block info, and use LTO_SET_PREVAIL for TREE_CHAIN(t) This will actually not work correctly in some cases. The problem is, if the prevailing decl is already part of another chain (say in another block_var list) you would break the current chain. Hence block vars need special handling in the lto streamer (another reason why tree_chain is not the most clever think to use for this chain). This problem area needs to be solved somehow if block info is to be preserved correctly. 2. Don't stream out block info for LTO, and still call LTO_NO_PREVAIL (TREE_CHAIN (t)). That's also a large hammer as it basically will mean no debug info after LTO :-/ Sigh, at this point I have no good solution that doesn't involve quite some work, perhaps your hack is good enough for the time being, though I hate it :) I got it. Then I'll keep the patch as it is (remove the LTO_NO_PREVAIL), and work with Honza to resolve the issue he had, and then we should be good to check in? Thanks, Dehao Ciao, Michael.
[v3, build] Clear hardware capabilities on libstdc++.so with Sun as
Since the use of rdrand was introduced in src/c++11/random.cc, all execution tests involving libstdc++.so.6 fail on Solaris 10 and 11/x86 with a sufficiently recent native assembler that supports rdrand: either Solaris 10/x86 patch 119961-11 or Solaris 11.1 builds (haven't checked which one). The problem is that as tags src/c++11/random.o as needing RDRAND support: % file random.o random.o: ELF 32-bit LSB relocatable 80386 Version 1 [CMOV RDRAND] which is propagated to libstdc++.so.6 and causes the runtime linker to fail the execution if the hardware doesn't support that hardware capability, although rdrand is executed only if the cpuid indicates the support is present. The usual solution so far has been to clear the hardware capability using a linker map (as in libitm, cf. libitm/clearcap.map). Unfortunately, this doesn't work here: as can be seen with elfdump, RDRAND is set in a second mask (CA_SUNW_HW_2) since all bits in CA_SUNW_HW_1 are already used: % elfdump -H random.o Capabilities Section: .SUNW_cap Object Capabilities: index tag value [0] CA_SUNW_HW_1 0x20 [ CMOV ] [1] CA_SUNW_HW_2 0x1 [ RDRAND ] The old (v1) linker map syntax has no support for clearing that bit/mask, and while the v2 map syntax does, we cannot universally assume it's present on Solaris 10: while recent linker patches include it, older ones don't and ld and as can be updated independently. So I've settled for a different solution instead: Sun assemblers with hardware capability support also have a -nH switch to suppress their generation, thus I'm testing for that and use it if possible. This is exactly what the following patch does. Bootstrapped without regressions on i386-pc-solaris2.1[01] with affected versions of Sun as and gas 2.22. Results with gas are unchanged, with Sun as all failures are gone. x86_64-unknown-linux-gnu bootstrap is running to make sure nothing breaks there. Ok for mainline if that passes? Rainer 2012-09-11 Rainer Orth r...@cebitec.uni-bielefeld.de * acinclude.m4 (GLIBCXX_CHECK_ASSEMBLER_HWCAP): Define. * configure.ac: Call GLIBCXX_CHECK_ASSEMBLER_HWCAP. * fragment.am (CONFIG_CXXFLAGS): Add $(HWCAP_FLAGS). * configure: Regenerate. * Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. # HG changeset patch # Parent cc6aab46be72c37bfdfccd786ed5c332a7ce4cd9 Clear hardware capabilities on libstdc++.so with Sun as diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -169,6 +169,32 @@ AC_DEFUN([GLIBCXX_CHECK_COMPILER_FEATURE dnl +dnl Check if the assembler used supports disabling generation of hardware +dnl capabilities. This is only supported by Sun as at the moment. +dnl +dnl Defines: +dnl HWCAP_FLAGS='-Wa,-nH' if possible. +dnl +AC_DEFUN([GLIBCXX_CHECK_ASSEMBLER_HWCAP], [ + test -z $HWCAP_FLAGS HWCAP_FLAGS='' + + ac_save_CFLAGS=$CFLAGS + CFLAGS=$CFLAGS -Wa,-nH + + AC_MSG_CHECKING([for as that supports -Wa,-nH]) + AC_TRY_COMPILE([], [return 0;], [ac_hwcap_flags=yes],[ac_hwcap_flags=no]) + if test $ac_hwcap_flags = yes; then +HWCAP_FLAGS=-Wa,-nH $HWCAP_FLAGS + fi + AC_MSG_RESULT($ac_hwcap_flags) + + CFLAGS=$ac_save_CFLAGS + + AC_SUBST(HWCAP_FLAGS) +]) + + +dnl dnl If GNU ld is in use, check to see if tricky linker opts can be used. If dnl the native linker is in use, all variables will be defined to something dnl safe (like an empty string). diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -333,6 +333,9 @@ case $target in esac GLIBCXX_CONDITIONAL(GLIBCXX_LDBL_COMPAT, test $ac_ldbl_compat = yes) +# Check if assembler supports disabling hardware capability support. +GLIBCXX_CHECK_ASSEMBLER_HWCAP + # Check if assembler supports rdrand opcode. GLIBCXX_CHECK_X86_RDRAND diff --git a/libstdc++-v3/fragment.am b/libstdc++-v3/fragment.am --- a/libstdc++-v3/fragment.am +++ b/libstdc++-v3/fragment.am @@ -22,7 +22,7 @@ endif # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ + $(SECTION_FLAGS) $(HWCAP_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR_FLAG) -fdiagnostics-show-location=once -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Fortran, Patch] PR 54225 - Fix ice-on-invalid-code with * in array refs
On 11/09/2012 07:54, Tobias Burnus wrote: This patch fixes a GCC 4.7/4.8 regression for invalid code. Build and regtested on x86-64-linux. OK for the trunk and 4.7? Yes. PR 53306 is also fixed by your patch according to Dominique, so don't forget to include its testcase and to add the PR reference in the ChangeLogs. Thanks Mikael
