[Bug fortran/41539] [OOP] Calling function which takes CLASS: Rank comparison does not work

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41539

Tobias Burnus  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Tobias Burnus  2011-12-12 
07:53:11 UTC ---
FIXED on the 4.7 trunk

[Bug testsuite/47013] FAIL: gcc.dg/sms-*.c scan-rtl-dump-times sms "SMS succeeded" *

[revitale at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47013

--- Comment #12 from revitale at gcc dot gnu.org 2011-12-12 07:32:31 UTC ---
Author: revitale
Date: Mon Dec 12 07:32:25 2011
New Revision: 182219

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182219
Log:
Fix PR testsuite/47013

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/sms-2.c
trunk/gcc/testsuite/gcc.dg/sms-3.c
trunk/gcc/testsuite/gcc.dg/sms-4.c
trunk/gcc/testsuite/gcc.dg/sms-5.c
trunk/gcc/testsuite/gcc.dg/sms-6.c
trunk/gcc/testsuite/gcc.dg/sms-7.c
trunk/gcc/testsuite/gcc.dg/sms-8.c
trunk/gcc/testsuite/gcc.dg/sms-9.c

[Bug target/51509] New: Inefficient neon intrinsic code sequence

[carrot at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51509

 Bug #: 51509
   Summary: Inefficient neon intrinsic code sequence
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-androideabi


Compile the following code with options -march=armv7-a -mfloat-abi=softfp
-mfpu=neon -mthumb -O2 -Wall -fpic

#include 
void simple_vld_intrin(uint8_t *src, uint8_t *dst)
{
  uint8x8x4_t x;
  uint8x8x2_t y;

  x = vld4_lane_u8(src, x, 0);

  y.val[0][0] = x.val[1][0];
 y.val[1][0] = x.val[2][0];

 vst2_lane_u8(dst, y, 0);
}

gcc 4.7 generates:


.LC0:
.word0
.word0
.word0
.word0
.word0
.word0
.word0
.word0
.text
.align2
.globalsimple_vld_intrin
.thumb
.thumb_func
.typesimple_vld_intrin, %function
simple_vld_intrin:
@ args = 0, pretend = 0, frame = 32
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrr2, .L2
subsp, sp, #32
.LPIC0:
addr2, pc
vldmiar2, {d18-d21}
vmov.i32d19, #0  @ v8qi
vmovd20, d19  @ v8qi
vmovq11, q9  @ ti
vmovq12, q10  @ ti
vmovd16, d19  @ v8qi
vmovd17, d19  @ v8qi
vld4.8{d22[0], d23[0], d24[0], d25[0]}, [r0]
vstmiasp, {d22-d25}
ldrbr2, [sp, #8]@ zero_extendqisi2
vmov.8d16[0], r2
vmov.u8r3, d24[0]
vmov.8d17[0], r3
vst2.8{d16[0], d17[0]}, [r1]
addsp, sp, #32
bxlr
.L3:
.align2
.L2:
.word.LC0-(.LPIC0+4)


An ideal result should be:

vld4.8{d16[0], d17[0], d18[0], d19[0]}, [r0]
vmovd20, d17  @ v8qi
vmovd21, d18  @ v8qi
vst2.8{d20[0], d21[0]}, [r1]
bxlr

[Bug middle-end/51508] New: Test vect.exp/fast-math-mgrid-resid.f fails when compiled with -mavx2.

[michael.v.zolotukhin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51508

 Bug #: 51508
   Summary: Test vect.exp/fast-math-mgrid-resid.f fails when
compiled with -mavx2.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.v.zolotuk...@gmail.com


This test checks work of predictive commoning phase, which fails when AVX2 is
available.

[Bug c++/51507] New: [C++0x] Function parameter pack doesn't use in template-argument-list

[digital-ghost_tsundere at hotmail dot co.jp]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51507

 Bug #: 51507
   Summary: [C++0x] Function parameter pack doesn't use in
template-argument-list
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: digital-ghost_tsund...@hotmail.co.jp


Following code cannot compile with gcc:

  template
  struct foo { typedef void type; };
  template
  auto g(Ts ...ts)->
  typename foo::type
  {}
  int main() {
  g(42);
  }

Error:

  test1.cpp: In function 'int main()':
  test1.cpp:8:9: error: expansion pattern 'int' contains no argument packs
  test1.cpp:8:9: error: no matching function for call to 'g(int)'
  test1.cpp:8:9: note: candidate is:
  test1.cpp:4:6: note: template typename foo::type g(Ts ...)

I think decltype(fs()) is a valid template-argument pattern for foo.

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[oleg.e...@t-online.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751

--- Comment #20 from Oleg Endo  2011-12-12 02:11:12 UTC 
---
(In reply to comment #19)
> The results look way better now.  I've tested your latest patch for
> sh4-unknown-linux-gnu and found no new regressions for gcc testsuite.
> CSiBE with "-O2 -fpic" on that target shows that 144 improvements and
> 28 dis-improvements for size on 896 files.  The worst case is
> -4.34783 net/ipv4/ip_forward 704 736
> which looks the case of the high r0 register pressure.  The best one is
> 25.7426 arch/testplatform/kernel/traps 10160 8080
> which looks to be very impressive.

That looks nice!  Thanks for checking it out!
I haven't ran CSiBE with "-O2 -fpic", only with "-Os -mpretend-cmove
-mfused-madd -freg-struct-return".  I will use your params and try to see what
is happening in those cases where it gets worse.  Maybe it can be "fixed" with
a peephole.

> 
> >   /* We want to enable the use of SUBREGs as a means to
> >  VEC_SELECT a single element of a vector.  */
> >+
> >+  /* This effectively disallows using GENERAL_REGS for SFmode vector 
> >subregs.
> >+ This can be problematic when SFmode vector subregs need to be accessed
> >+ on the stack with displacement addressing, as it happens with -O0.
> >+ Thus we allow the mode change for -O0.  */
> >   if (to == SFmode && VECTOR_MODE_P (from) && GET_MODE_INNER (from) == 
> > SFmode)
> >-return (reg_classes_intersect_p (GENERAL_REGS, rclass));
> >+return optimize ? (reg_classes_intersect_p (GENERAL_REGS, rclass)) : 
> >false;


> >+ Thus we allow the mode change for -O0.  */

.. should be _disallow_ of course... 
Another note that should have went into the comment:

As far as I could observe it, this is mainly triggered by the following in
sh_legitimate_index_p:

+  if (mode == QImode && (unsigned) INTVAL (op) < 16)
+return true;

.. probably because this makes the generic "m" constraint match QImode
displacement addressing and then it tries using it.

> Rather than that, I guess that the QI/HImode disp addressing would
> be an optimization unneeded for -O0 in the first place.  Perhaps
> something like -mpreferdisp option and TARGET_PREFER_DISP macro
> which are enable by default but disable at -O0 might be help.

Yeah, could also be an option. 

> It'll also help some unfortunate anormallies for which those optimizations
> will generate worse codes.

You mean, by giving the user the option to turn off displacement addressing for
e.g. some specific files / modules by specifying -mno-preferdisp or something
like that?  By anomalies do you mean code that gets worse because of too much
pressure on R0 and all the reloads around it, or do you have any other bad use
cases?

BTW, the vector mode handling seems a bit unfinished (see also PR13423).  I was
planning to address that at a later point...


> Maybe.  Implementing it with predicates and constraints would be
> smarter if possible but may be difficult because the register
> allocator handles the "m" constraint specially.

Yes, the "m" constraint is an obstacle in this case.
What I've tried out is splitting it into a memory constraint that allows
displacement addressing and another memory constraint that disallows it ("Snd",
"Sdd" - they are added by the patch) and use those in the move / sign extend
insns instead of the generic "m" constraint.  For example something like that:

(define_insn "*extendqisi2"
  [(set (match_operand:SI 0 "arith_reg_dest" "=z,r,r")
(sign_extend:SI
 (match_operand:QI 1 "general_movsrc_operand" Sdd,Snd,r")))]
  "TARGET_SH1"
  "@
mov.b%1,%0
mov.b%1,%0
exts.b%1,%0"
  [(set_attr "type" "load,load,arith")])

This basically seems to work. But when there are consecutive loads, reload
would use displacement addressing for the first load, but not for the following
loads because R0 will be already allocated at that point.  Ideally, reload
should take into account that "reloading around R0" is in most cases more
efficient than other strategies, especially on SH4.  However, I'm not sure
whether changing reload for this issue is a good idea ;)

Another thing I could try out is to have load/store insns that allow arbitrary
operands in displacement addressing like on SH2A, and split them into two insns
of one load/store and one reg-reg move after reload.  But that would probably
require the R0 clobber in the expander which could make worse code in cases
where displacement addressing is not used, I guess.
Do you think this approach could make sense?

> I think so, though we are in stage 3 and have to wait the trunk returns
> to stage 1 or 2 for committing such changes.

I was afraid you might say something like this :T

> You have the time for implementing HImode support.

Yep, sure.  I've noticed that the latest version of the patch seems to fix some
more testsuite failures.  I will investigate which hunk is responsible for the
fixes so that could be pulled out from the patch.  OK?

> BTW, th

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751

--- Comment #19 from Kazumoto Kojima  2011-12-11 
23:57:13 UTC ---
(In reply to comment #18)
The results look way better now.  I've tested your latest patch for
sh4-unknown-linux-gnu and found no new regressions for gcc testsuite.
CSiBE with "-O2 -fpic" on that target shows that 144 improvements and
28 dis-improvements for size on 896 files.  The worst case is
-4.34783 net/ipv4/ip_forward 704 736
which looks the case of the high r0 register pressure.  The best one is
25.7426 arch/testplatform/kernel/traps 10160 8080
which looks to be very impressive.

>   /* We want to enable the use of SUBREGs as a means to
>  VEC_SELECT a single element of a vector.  */
>+
>+  /* This effectively disallows using GENERAL_REGS for SFmode vector subregs.
>+ This can be problematic when SFmode vector subregs need to be accessed
>+ on the stack with displacement addressing, as it happens with -O0.
>+ Thus we allow the mode change for -O0.  */
>   if (to == SFmode && VECTOR_MODE_P (from) && GET_MODE_INNER (from) == SFmode)
>-return (reg_classes_intersect_p (GENERAL_REGS, rclass));
>+return optimize ? (reg_classes_intersect_p (GENERAL_REGS, rclass)) : 
>false;

Rather than that, I guess that the QI/HImode disp addressing would
be an optimization unneeded for -O0 in the first place.  Perhaps
something like -mpreferdisp option and TARGET_PREFER_DISP macro
which are enable by default but disable at -O0 might be help.  It'll
also help some unfortunate anormallies for which those optimizations
will generate worse codes.

> There are probably smarter ways of doing what the patch does.  I have also
> tried out implementing it with predicates and constraints, few load/store 
> insns
> and lots of alternatives in the insns.  However, reload would refuse to select
> the displacement addressing due to pressure on R0 in many cases.

Maybe.  Implementing it with predicates and constraints would be
smarter if possible but may be difficult because the register
allocator handles the "m" constraint specially.

> Would something like the attached patch be acceptable (after some cleanups)? 
> If so, I'd also start adding HImode displacement addressing support.

I think so, though we are in stage 3 and have to wait the trunk returns
to stage 1 or 2 for committing such changes.  You have the time for
implementing HImode support.
BTW, the changes for white spaces, spells and other clean-ups which
are not essential for this work should be separated into another patch.

[Bug tree-optimization/51506] New: Function cloning misses constant struct

[peteraward+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51506

 Bug #: 51506
   Summary: Function cloning misses constant struct
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: peteraward+...@gmail.com


The actual problem I’m dealing with is with avr-gcc, so the goal is to achieve
a small code size. I’m trying to write my code like this:
lcd_init(lcd_t l, ...)
where the first parameter is passed a *constant* struct which contains the
memory addresses of each of the pins for the LCD. Thus, I want the compiler to
note that all calls have the same first argument, clone the function, and
propagate the constant.

However, it doesn’t seem to be working in practice.
In trying to build this test case, I found the compiler would just inline all
the functions, which defeats the point (in the actual code, the cost of
inlining is too high). So, I’ve added the noinline attribute, which I don’t
think should stop this optimisation, but apologies if it does.

Anyhow, here’s the testcase.
(using gcc version 4.6.2 (Debian 4.6.2-5), on 64-bit Linux)

$ cat test.c
typedef struct {
int a;
int b;
} dint;

__attribute__((noinline))
static int compute_int(int x, int var) {
int y = 0;
for (int i = 0; i < x; i++)
y += i * x;
return y + var;
}

__attribute__((noinline))
static int compute_dint(dint x, int var) {
int z = x.a + x.b;
int y = 0;
for (int i = 0; i < z; i++)
y += i * z;
return y + var;
}

int main() {
int rv;
rv += compute_dint((dint) {6, 1}, 1);
rv += compute_dint((dint) {6, 1}, 2);
rv += compute_dint((dint) {6, 1}, 3);
rv += compute_int(5, 1);
rv += compute_int(5, 2);
rv += compute_int(5, 3);
return rv;
}
$ gcc -fdump-ipa-all -fipa-cp -fipa-cp-clone -Os -std=c99 test.c

Expected result:
both compute_int and compute_dint should be optimised to versions where "x" is
constant.

Actual reslut:
only compute_int is optimised.

[Bug fortran/50923] [4.4/4.5/4.6/4.7 Regression] No warning if function return value is not set

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50923

--- Comment #4 from Tobias Burnus  2011-12-11 
21:37:58 UTC ---
Author: burnus
Date: Sun Dec 11 21:37:55 2011
New Revision: 182213

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182213
Log:
2011-12-11  Tobias Burnus  

PR fortran/50923
* trans-decl.c (generate_local_decl): Set TREE_NO_WARNING only
if the front end has printed a warning.
(gfc_generate_function_code): Fix unset-result warning.

2011-12-11  Tobias Burnus  

PR fortran/50923
* gfortran.dg/warn_function_without_result_2.f90: New.


Added:
   
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/warn_function_without_result_2.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/trans-decl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/51505] New: [4.5/4.6/4.7 Regression] ICE: in form_sum, at reload.c:5349 with -O --param max-cse-insns=1

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505

 Bug #: 51505
   Summary: [4.5/4.6/4.7 Regression] ICE: in form_sum, at
reload.c:5349 with -O --param max-cse-insns=1
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 26050
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26050
reduced testcase

Compiler output:
$ gcc -O --param max-cse-insns=1 testcase.c
testcase.c: In function 'foo':
testcase.c:16:1: internal compiler error: in form_sum, at reload.c:5345
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) list
5340form_sum (enum machine_mode mode, rtx x, rtx y)
5341{
5342  rtx tem;
5343
5344  gcc_assert (GET_MODE (x) == mode || GET_MODE (x) == VOIDmode);
5345  gcc_assert (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode);
5346
5347  if (CONST_INT_P (x))
5348return plus_constant (y, INTVAL (x));
5349  else if (CONST_INT_P (y))
(gdb) bt
#0  fancy_abort (file=0x12886d0 "/mnt/svn/gcc-trunk/gcc/reload.c", line=5345,
function=0x1289340 "form_sum")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898
#1  0x00942b5e in form_sum (mode=DImode, x=,
y=) at /mnt/svn/gcc-trunk/gcc/reload.c:5345
#2  0x0095a94e in eliminate_regs_1 (x=0x7569ae70, mem_mode=QImode,
insn=0x7569ade0, may_use_invariant=Unhandled dwarf expression opcode 0xf3
)
at /mnt/svn/gcc-trunk/gcc/reload1.c:2685
#3  0x0095a898 in eliminate_regs_1 (x=0x7569ae58, mem_mode=QImode,
insn=0x7569ade0, may_use_invariant=Unhandled dwarf expression opcode 0xf3
)
at /mnt/svn/gcc-trunk/gcc/reload1.c:2663
#4  0x0095ac85 in eliminate_regs_1 (x=0x7569ae40,
mem_mode=VOIDmode, insn=0x7569ade0, may_use_invariant=Unhandled dwarf
expression opcode 0xf3
)
at /mnt/svn/gcc-trunk/gcc/reload1.c:2886
#5  0x0095aab2 in eliminate_regs_1 (x=0x7569ae28,
mem_mode=VOIDmode, insn=0x7569ade0, may_use_invariant=Unhandled dwarf
expression opcode 0xf3
)
at /mnt/svn/gcc-trunk/gcc/reload1.c:2743
#6  0x0095b2da in eliminate_regs_1 (x=0x7569ae10,
mem_mode=VOIDmode, insn=0x7569ade0, may_use_invariant=Unhandled dwarf
expression opcode 0xf3
)
at /mnt/svn/gcc-trunk/gcc/reload1.c:2755
#7  0x0095b1e3 in eliminate_regs_1 (x=0x7569adf8,
mem_mode=VOIDmode, insn=0x7569ade0, may_use_invariant=Unhandled dwarf
expression opcode 0xf3
)
at /mnt/svn/gcc-trunk/gcc/reload1.c:2780
#8  0x0095b1e3 in eliminate_regs_1 (x=0x7569ade0,
mem_mode=VOIDmode, insn=0x7569ade0, may_use_invariant=Unhandled dwarf
expression opcode 0xf3
)
at /mnt/svn/gcc-trunk/gcc/reload1.c:2780
#9  0x00966965 in eliminate_regs_in_insn (insn=0x7555bdc8,
replace=0) at /mnt/svn/gcc-trunk/gcc/reload1.c:3623
#10 0x00967ddd in calculate_needs_all_insns (global=1) at
/mnt/svn/gcc-trunk/gcc/reload1.c:1523
#11 0x00968c85 in reload (first=0x75693340, global=1) at
/mnt/svn/gcc-trunk/gcc/reload1.c:945
#12 0x0087c670 in ira () at /mnt/svn/gcc-trunk/gcc/ira.c:3725
#13 rest_of_handle_ira () at /mnt/svn/gcc-trunk/gcc/ira.c:3798
#14 0x008f8ac5 in execute_one_pass (pass=0x17be800) at
/mnt/svn/gcc-trunk/gcc/passes.c:2079
#15 0x008f8e65 in execute_pass_list (pass=0x17be800) at
/mnt/svn/gcc-trunk/gcc/passes.c:2134
#16 0x008f8e77 in execute_pass_list (pass=0x17beee0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2135
#17 0x00a5a5ee in tree_rest_of_compilation (fndecl=0x75672c00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:421
#18 0x006ad84a in cgraph_expand_function (node=0x755636c0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1818
#19 0x006af5ec in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1885
#20 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2198
#21 0x006afd5a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#22 0x0058d620 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:10026
#23 0x009edc94 in compile_file (argc=15, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:573
#24 do_compile (argc=15, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1928
#25 toplev_main (argc=15, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2004
#26 0x761570ed in __libc_start_main () from /lib64/libc.so.6
#27 0x00570df1 in _start ()


The testcase was reduced from gcc.target/i386/sse2-pandn-1.c, which needs more
flags:
$ gcc -O -fno-tree-loop-optimize -funroll-loops --param=max-cse-insns=1
gcc.target/i386/sse2-pandn-1.c
In file in

[Bug tree-optimization/51485] [4.6/4.7 Regression] ICE in vectorizable_assignment

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51485

--- Comment #2 from Jakub Jelinek  2011-12-11 
21:01:03 UTC ---
Author: jakub
Date: Sun Dec 11 21:01:00 2011
New Revision: 182212

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182212
Log:
PR tree-optimization/51485
* tree-vect-data-refs.c (vect_analyze_data_refs): Give up on
DRs in call stmts.

* g++.dg/vect/pr51485.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr51485.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug fortran/51502] [4.6/4.7 Regression] Potentially wrong code generation due to wrong implict_pure check

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51502

--- Comment #2 from Thomas Koenig  2011-12-11 
20:56:54 UTC ---
The problem occurs in expr.c:


  if (!pointer && gfc_implicit_pure (NULL) && gfc_impure_variable (sym))
gfc_current_ns->proc_name->attr.implicit_pure = 0;

assumes that gfc_current_ns points to the current procedure, which
is wrong in the case of blocks.

Maybe it would make sense to have a global gfc_proc_name?

Also, the logic in gfc_implicit_pure() appears to be wrong
because it does not look for parent namespaces.

[Bug fortran/50923] [4.4/4.5/4.6/4.7 Regression] No warning if function return value is not set

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50923

--- Comment #3 from Tobias Burnus  2011-12-11 
20:44:32 UTC ---
Author: burnus
Date: Sun Dec 11 20:44:30 2011
New Revision: 182211

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182211
Log:
2011-12-11  Tobias Burnus  

PR fortran/50923
* trans-decl.c (generate_local_decl): Set TREE_NO_WARNING only
if the front end has printed a warning.
(gfc_generate_function_code): Fix unset-result warning.

2011-12-11  Tobias Burnus  

PR fortran/50923
* gfortran.dg/warn_function_without_result_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_function_without_result_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/44568] [OOP] ICE with TBP of polymorphic derived type array

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44568

--- Comment #3 from Paul Thomas  2011-12-11 20:42:30 
UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  
Tobias Burnus  

PR fortran/41539
PR fortran/43214
PR fortran/43969
PR fortran/44568
PR fortran/46356
PR fortran/46990
PR fortran/49074
* interface.c(symbol_rank): Return the rank of the _data
component of class objects.
(compare_parameter): Also compare the derived type of the class
_data component for type mismatch.  Similarly, return 1 if the
formal and _data ranks match.
(compare_actual_formal): Do not compare storage sizes for class
expressions. It is an error if an actual class array, passed to
a formal class array is not full.
* trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
gfc_vtable_extends_get, gfc_vtable_def_init_get,
gfc_vtable_copy_get): New functions for class API.
(gfc_conv_derived_to_class): For an array reference in an
elemental procedure call retain the ss to provide the
scalarized array reference. Moved in file.
(gfc_conv_class_to_class): New function.
(gfc_conv_subref_array_arg): Use the type of the
class _data component as a basetype.
(gfc_conv_procedure_call): Ensure that class array expressions
have both the _data reference and an array reference. Use 
gfc_conv_class_to_class to handle class arrays for elemental
functions in scalarized loops, class array elements and full
class arrays. Use a call to gfc_conv_subref_array_arg in order
that the copy-in/copy-out for passing class arrays to derived
type arrays occurs correctly.
(gfc_conv_expr): If it is missing, add the _data component
between a class object or component and an array reference.
(gfc_trans_class_array_init_assign): New function.
(gfc_trans_class_init_assign): Call it for array expressions.
* trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
class scalars since their size will depend on the dynamic type.
(build_class_array_ref): New function.
(gfc_conv_scalarized_array_ref): Call build_class_array_ref.
(gfc_array_init_size): Add extra argument, expr3, that represents
the SOURCE argument. If present,use this for the element size.
(gfc_array_allocate): Also add argument expr3 and use it when
calling gfc_array_init_size.
(structure_alloc_comps): Enable class arrays.
* class.c (gfc_add_component_ref): Carry over the derived type
of the _data component.
(gfc_add_class_array_ref): New function.
(class_array_ref_detected): New static function.
(gfc_is_class_array_ref): New function that calls previous.
(gfc_is_class_scalar_expr): New function.
(gfc_build_class_symbol): Throw not implemented error for
assumed size class arrays.  Remove error that prevents
CLASS arrays.
(gfc_build_class_symbol): Prevent pointer/allocatable conflict.
Also unset codimension.
(gfc_find_derived_vtab): Make 'copy' elemental and set the
intent of the arguments accordingly.: 
* trans-array.h : Update prototype for gfc_array_allocate.
* array.c (gfc_array_dimen_size): Return failure if class expr.
(gfc_array_size): Likewise.
* gfortran.h : New prototypes for gfc_add_class_array_ref,
gfc_is_class_array_ref and gfc_is_class_scalar_expr.
* trans-stmt.c (trans_associate_var): Exclude class targets
from test. Move the allocation of the _vptr to an earlier time
for class objects.
(trans_associate_var): Assign the descriptor directly for class
arrays.
(gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
Convert array element references into sections. Do not invoke
gfc_conv_procedure_call, use gfc_trans_call instead.
* expr.c (gfc_get_corank): Fix for BT_CLASS.
(gfc_is_simply_contiguous): Exclude class from test.
* trans.c (gfc_build_array_ref): Include class array refs.
* trans.h : Include prototypes for class API functions that are
new in trans-expr. Define GFC_DECL_CLASS(node).
* resolve.c (check_typebound_baseobject ): Remove error for
non-scalar base object.
(resolve_allocate_expr): Ensure that class _data component is
present. If array, call gfc_expr_to_intialize.
(resolve_select): Remove scalar error for SELECT statement as a
temporary measure.
(resolve_assoc_var): Update 'target' (aka 'selector') as
needed. Ensure that the target expression has the right rank.
(resolve_select_type): Ensure that target expressions have a
valid locus.
(resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
* trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
appropriate.
(gfc_trans_deferred_vars): Get class arrays right.
* match.c(s

[Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990

--- Comment #8 from Paul Thomas  2011-12-11 20:42:32 
UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  
Tobias Burnus  

PR fortran/41539
PR fortran/43214
PR fortran/43969
PR fortran/44568
PR fortran/46356
PR fortran/46990
PR fortran/49074
* interface.c(symbol_rank): Return the rank of the _data
component of class objects.
(compare_parameter): Also compare the derived type of the class
_data component for type mismatch.  Similarly, return 1 if the
formal and _data ranks match.
(compare_actual_formal): Do not compare storage sizes for class
expressions. It is an error if an actual class array, passed to
a formal class array is not full.
* trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
gfc_vtable_extends_get, gfc_vtable_def_init_get,
gfc_vtable_copy_get): New functions for class API.
(gfc_conv_derived_to_class): For an array reference in an
elemental procedure call retain the ss to provide the
scalarized array reference. Moved in file.
(gfc_conv_class_to_class): New function.
(gfc_conv_subref_array_arg): Use the type of the
class _data component as a basetype.
(gfc_conv_procedure_call): Ensure that class array expressions
have both the _data reference and an array reference. Use 
gfc_conv_class_to_class to handle class arrays for elemental
functions in scalarized loops, class array elements and full
class arrays. Use a call to gfc_conv_subref_array_arg in order
that the copy-in/copy-out for passing class arrays to derived
type arrays occurs correctly.
(gfc_conv_expr): If it is missing, add the _data component
between a class object or component and an array reference.
(gfc_trans_class_array_init_assign): New function.
(gfc_trans_class_init_assign): Call it for array expressions.
* trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
class scalars since their size will depend on the dynamic type.
(build_class_array_ref): New function.
(gfc_conv_scalarized_array_ref): Call build_class_array_ref.
(gfc_array_init_size): Add extra argument, expr3, that represents
the SOURCE argument. If present,use this for the element size.
(gfc_array_allocate): Also add argument expr3 and use it when
calling gfc_array_init_size.
(structure_alloc_comps): Enable class arrays.
* class.c (gfc_add_component_ref): Carry over the derived type
of the _data component.
(gfc_add_class_array_ref): New function.
(class_array_ref_detected): New static function.
(gfc_is_class_array_ref): New function that calls previous.
(gfc_is_class_scalar_expr): New function.
(gfc_build_class_symbol): Throw not implemented error for
assumed size class arrays.  Remove error that prevents
CLASS arrays.
(gfc_build_class_symbol): Prevent pointer/allocatable conflict.
Also unset codimension.
(gfc_find_derived_vtab): Make 'copy' elemental and set the
intent of the arguments accordingly.: 
* trans-array.h : Update prototype for gfc_array_allocate.
* array.c (gfc_array_dimen_size): Return failure if class expr.
(gfc_array_size): Likewise.
* gfortran.h : New prototypes for gfc_add_class_array_ref,
gfc_is_class_array_ref and gfc_is_class_scalar_expr.
* trans-stmt.c (trans_associate_var): Exclude class targets
from test. Move the allocation of the _vptr to an earlier time
for class objects.
(trans_associate_var): Assign the descriptor directly for class
arrays.
(gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
Convert array element references into sections. Do not invoke
gfc_conv_procedure_call, use gfc_trans_call instead.
* expr.c (gfc_get_corank): Fix for BT_CLASS.
(gfc_is_simply_contiguous): Exclude class from test.
* trans.c (gfc_build_array_ref): Include class array refs.
* trans.h : Include prototypes for class API functions that are
new in trans-expr. Define GFC_DECL_CLASS(node).
* resolve.c (check_typebound_baseobject ): Remove error for
non-scalar base object.
(resolve_allocate_expr): Ensure that class _data component is
present. If array, call gfc_expr_to_intialize.
(resolve_select): Remove scalar error for SELECT statement as a
temporary measure.
(resolve_assoc_var): Update 'target' (aka 'selector') as
needed. Ensure that the target expression has the right rank.
(resolve_select_type): Ensure that target expressions have a
valid locus.
(resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
* trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
appropriate.
(gfc_trans_deferred_vars): Get class arrays right.
* match.c(s

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49074

--- Comment #8 from Paul Thomas  2011-12-11 20:42:31 
UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  
Tobias Burnus  

PR fortran/41539
PR fortran/43214
PR fortran/43969
PR fortran/44568
PR fortran/46356
PR fortran/46990
PR fortran/49074
* interface.c(symbol_rank): Return the rank of the _data
component of class objects.
(compare_parameter): Also compare the derived type of the class
_data component for type mismatch.  Similarly, return 1 if the
formal and _data ranks match.
(compare_actual_formal): Do not compare storage sizes for class
expressions. It is an error if an actual class array, passed to
a formal class array is not full.
* trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
gfc_vtable_extends_get, gfc_vtable_def_init_get,
gfc_vtable_copy_get): New functions for class API.
(gfc_conv_derived_to_class): For an array reference in an
elemental procedure call retain the ss to provide the
scalarized array reference. Moved in file.
(gfc_conv_class_to_class): New function.
(gfc_conv_subref_array_arg): Use the type of the
class _data component as a basetype.
(gfc_conv_procedure_call): Ensure that class array expressions
have both the _data reference and an array reference. Use 
gfc_conv_class_to_class to handle class arrays for elemental
functions in scalarized loops, class array elements and full
class arrays. Use a call to gfc_conv_subref_array_arg in order
that the copy-in/copy-out for passing class arrays to derived
type arrays occurs correctly.
(gfc_conv_expr): If it is missing, add the _data component
between a class object or component and an array reference.
(gfc_trans_class_array_init_assign): New function.
(gfc_trans_class_init_assign): Call it for array expressions.
* trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
class scalars since their size will depend on the dynamic type.
(build_class_array_ref): New function.
(gfc_conv_scalarized_array_ref): Call build_class_array_ref.
(gfc_array_init_size): Add extra argument, expr3, that represents
the SOURCE argument. If present,use this for the element size.
(gfc_array_allocate): Also add argument expr3 and use it when
calling gfc_array_init_size.
(structure_alloc_comps): Enable class arrays.
* class.c (gfc_add_component_ref): Carry over the derived type
of the _data component.
(gfc_add_class_array_ref): New function.
(class_array_ref_detected): New static function.
(gfc_is_class_array_ref): New function that calls previous.
(gfc_is_class_scalar_expr): New function.
(gfc_build_class_symbol): Throw not implemented error for
assumed size class arrays.  Remove error that prevents
CLASS arrays.
(gfc_build_class_symbol): Prevent pointer/allocatable conflict.
Also unset codimension.
(gfc_find_derived_vtab): Make 'copy' elemental and set the
intent of the arguments accordingly.: 
* trans-array.h : Update prototype for gfc_array_allocate.
* array.c (gfc_array_dimen_size): Return failure if class expr.
(gfc_array_size): Likewise.
* gfortran.h : New prototypes for gfc_add_class_array_ref,
gfc_is_class_array_ref and gfc_is_class_scalar_expr.
* trans-stmt.c (trans_associate_var): Exclude class targets
from test. Move the allocation of the _vptr to an earlier time
for class objects.
(trans_associate_var): Assign the descriptor directly for class
arrays.
(gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
Convert array element references into sections. Do not invoke
gfc_conv_procedure_call, use gfc_trans_call instead.
* expr.c (gfc_get_corank): Fix for BT_CLASS.
(gfc_is_simply_contiguous): Exclude class from test.
* trans.c (gfc_build_array_ref): Include class array refs.
* trans.h : Include prototypes for class API functions that are
new in trans-expr. Define GFC_DECL_CLASS(node).
* resolve.c (check_typebound_baseobject ): Remove error for
non-scalar base object.
(resolve_allocate_expr): Ensure that class _data component is
present. If array, call gfc_expr_to_intialize.
(resolve_select): Remove scalar error for SELECT statement as a
temporary measure.
(resolve_assoc_var): Update 'target' (aka 'selector') as
needed. Ensure that the target expression has the right rank.
(resolve_select_type): Ensure that target expressions have a
valid locus.
(resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
* trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
appropriate.
(gfc_trans_deferred_vars): Get class arrays right.
* match.c(s

[Bug fortran/46356] [OOP] Erroneous procedure/intent error and ICE for class dummy argument

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46356

--- Comment #3 from Paul Thomas  2011-12-11 20:42:32 
UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  
Tobias Burnus  

PR fortran/41539
PR fortran/43214
PR fortran/43969
PR fortran/44568
PR fortran/46356
PR fortran/46990
PR fortran/49074
* interface.c(symbol_rank): Return the rank of the _data
component of class objects.
(compare_parameter): Also compare the derived type of the class
_data component for type mismatch.  Similarly, return 1 if the
formal and _data ranks match.
(compare_actual_formal): Do not compare storage sizes for class
expressions. It is an error if an actual class array, passed to
a formal class array is not full.
* trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
gfc_vtable_extends_get, gfc_vtable_def_init_get,
gfc_vtable_copy_get): New functions for class API.
(gfc_conv_derived_to_class): For an array reference in an
elemental procedure call retain the ss to provide the
scalarized array reference. Moved in file.
(gfc_conv_class_to_class): New function.
(gfc_conv_subref_array_arg): Use the type of the
class _data component as a basetype.
(gfc_conv_procedure_call): Ensure that class array expressions
have both the _data reference and an array reference. Use 
gfc_conv_class_to_class to handle class arrays for elemental
functions in scalarized loops, class array elements and full
class arrays. Use a call to gfc_conv_subref_array_arg in order
that the copy-in/copy-out for passing class arrays to derived
type arrays occurs correctly.
(gfc_conv_expr): If it is missing, add the _data component
between a class object or component and an array reference.
(gfc_trans_class_array_init_assign): New function.
(gfc_trans_class_init_assign): Call it for array expressions.
* trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
class scalars since their size will depend on the dynamic type.
(build_class_array_ref): New function.
(gfc_conv_scalarized_array_ref): Call build_class_array_ref.
(gfc_array_init_size): Add extra argument, expr3, that represents
the SOURCE argument. If present,use this for the element size.
(gfc_array_allocate): Also add argument expr3 and use it when
calling gfc_array_init_size.
(structure_alloc_comps): Enable class arrays.
* class.c (gfc_add_component_ref): Carry over the derived type
of the _data component.
(gfc_add_class_array_ref): New function.
(class_array_ref_detected): New static function.
(gfc_is_class_array_ref): New function that calls previous.
(gfc_is_class_scalar_expr): New function.
(gfc_build_class_symbol): Throw not implemented error for
assumed size class arrays.  Remove error that prevents
CLASS arrays.
(gfc_build_class_symbol): Prevent pointer/allocatable conflict.
Also unset codimension.
(gfc_find_derived_vtab): Make 'copy' elemental and set the
intent of the arguments accordingly.: 
* trans-array.h : Update prototype for gfc_array_allocate.
* array.c (gfc_array_dimen_size): Return failure if class expr.
(gfc_array_size): Likewise.
* gfortran.h : New prototypes for gfc_add_class_array_ref,
gfc_is_class_array_ref and gfc_is_class_scalar_expr.
* trans-stmt.c (trans_associate_var): Exclude class targets
from test. Move the allocation of the _vptr to an earlier time
for class objects.
(trans_associate_var): Assign the descriptor directly for class
arrays.
(gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
Convert array element references into sections. Do not invoke
gfc_conv_procedure_call, use gfc_trans_call instead.
* expr.c (gfc_get_corank): Fix for BT_CLASS.
(gfc_is_simply_contiguous): Exclude class from test.
* trans.c (gfc_build_array_ref): Include class array refs.
* trans.h : Include prototypes for class API functions that are
new in trans-expr. Define GFC_DECL_CLASS(node).
* resolve.c (check_typebound_baseobject ): Remove error for
non-scalar base object.
(resolve_allocate_expr): Ensure that class _data component is
present. If array, call gfc_expr_to_intialize.
(resolve_select): Remove scalar error for SELECT statement as a
temporary measure.
(resolve_assoc_var): Update 'target' (aka 'selector') as
needed. Ensure that the target expression has the right rank.
(resolve_select_type): Ensure that target expressions have a
valid locus.
(resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
* trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
appropriate.
(gfc_trans_deferred_vars): Get class arrays right.
* match.c(s

[Bug fortran/41539] [OOP] Calling function which takes CLASS: Rank comparison does not work

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41539

--- Comment #6 from Paul Thomas  2011-12-11 20:42:29 
UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  
Tobias Burnus  

PR fortran/41539
PR fortran/43214
PR fortran/43969
PR fortran/44568
PR fortran/46356
PR fortran/46990
PR fortran/49074
* interface.c(symbol_rank): Return the rank of the _data
component of class objects.
(compare_parameter): Also compare the derived type of the class
_data component for type mismatch.  Similarly, return 1 if the
formal and _data ranks match.
(compare_actual_formal): Do not compare storage sizes for class
expressions. It is an error if an actual class array, passed to
a formal class array is not full.
* trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
gfc_vtable_extends_get, gfc_vtable_def_init_get,
gfc_vtable_copy_get): New functions for class API.
(gfc_conv_derived_to_class): For an array reference in an
elemental procedure call retain the ss to provide the
scalarized array reference. Moved in file.
(gfc_conv_class_to_class): New function.
(gfc_conv_subref_array_arg): Use the type of the
class _data component as a basetype.
(gfc_conv_procedure_call): Ensure that class array expressions
have both the _data reference and an array reference. Use 
gfc_conv_class_to_class to handle class arrays for elemental
functions in scalarized loops, class array elements and full
class arrays. Use a call to gfc_conv_subref_array_arg in order
that the copy-in/copy-out for passing class arrays to derived
type arrays occurs correctly.
(gfc_conv_expr): If it is missing, add the _data component
between a class object or component and an array reference.
(gfc_trans_class_array_init_assign): New function.
(gfc_trans_class_init_assign): Call it for array expressions.
* trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
class scalars since their size will depend on the dynamic type.
(build_class_array_ref): New function.
(gfc_conv_scalarized_array_ref): Call build_class_array_ref.
(gfc_array_init_size): Add extra argument, expr3, that represents
the SOURCE argument. If present,use this for the element size.
(gfc_array_allocate): Also add argument expr3 and use it when
calling gfc_array_init_size.
(structure_alloc_comps): Enable class arrays.
* class.c (gfc_add_component_ref): Carry over the derived type
of the _data component.
(gfc_add_class_array_ref): New function.
(class_array_ref_detected): New static function.
(gfc_is_class_array_ref): New function that calls previous.
(gfc_is_class_scalar_expr): New function.
(gfc_build_class_symbol): Throw not implemented error for
assumed size class arrays.  Remove error that prevents
CLASS arrays.
(gfc_build_class_symbol): Prevent pointer/allocatable conflict.
Also unset codimension.
(gfc_find_derived_vtab): Make 'copy' elemental and set the
intent of the arguments accordingly.: 
* trans-array.h : Update prototype for gfc_array_allocate.
* array.c (gfc_array_dimen_size): Return failure if class expr.
(gfc_array_size): Likewise.
* gfortran.h : New prototypes for gfc_add_class_array_ref,
gfc_is_class_array_ref and gfc_is_class_scalar_expr.
* trans-stmt.c (trans_associate_var): Exclude class targets
from test. Move the allocation of the _vptr to an earlier time
for class objects.
(trans_associate_var): Assign the descriptor directly for class
arrays.
(gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
Convert array element references into sections. Do not invoke
gfc_conv_procedure_call, use gfc_trans_call instead.
* expr.c (gfc_get_corank): Fix for BT_CLASS.
(gfc_is_simply_contiguous): Exclude class from test.
* trans.c (gfc_build_array_ref): Include class array refs.
* trans.h : Include prototypes for class API functions that are
new in trans-expr. Define GFC_DECL_CLASS(node).
* resolve.c (check_typebound_baseobject ): Remove error for
non-scalar base object.
(resolve_allocate_expr): Ensure that class _data component is
present. If array, call gfc_expr_to_intialize.
(resolve_select): Remove scalar error for SELECT statement as a
temporary measure.
(resolve_assoc_var): Update 'target' (aka 'selector') as
needed. Ensure that the target expression has the right rank.
(resolve_select_type): Ensure that target expressions have a
valid locus.
(resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
* trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
appropriate.
(gfc_trans_deferred_vars): Get class arrays right.
* match.c(s

[Bug fortran/43969] [OOP] ALLOCATED() with polymorphic arrays

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43969

--- Comment #10 from Paul Thomas  2011-12-11 20:42:29 
UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  
Tobias Burnus  

PR fortran/41539
PR fortran/43214
PR fortran/43969
PR fortran/44568
PR fortran/46356
PR fortran/46990
PR fortran/49074
* interface.c(symbol_rank): Return the rank of the _data
component of class objects.
(compare_parameter): Also compare the derived type of the class
_data component for type mismatch.  Similarly, return 1 if the
formal and _data ranks match.
(compare_actual_formal): Do not compare storage sizes for class
expressions. It is an error if an actual class array, passed to
a formal class array is not full.
* trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
gfc_vtable_extends_get, gfc_vtable_def_init_get,
gfc_vtable_copy_get): New functions for class API.
(gfc_conv_derived_to_class): For an array reference in an
elemental procedure call retain the ss to provide the
scalarized array reference. Moved in file.
(gfc_conv_class_to_class): New function.
(gfc_conv_subref_array_arg): Use the type of the
class _data component as a basetype.
(gfc_conv_procedure_call): Ensure that class array expressions
have both the _data reference and an array reference. Use 
gfc_conv_class_to_class to handle class arrays for elemental
functions in scalarized loops, class array elements and full
class arrays. Use a call to gfc_conv_subref_array_arg in order
that the copy-in/copy-out for passing class arrays to derived
type arrays occurs correctly.
(gfc_conv_expr): If it is missing, add the _data component
between a class object or component and an array reference.
(gfc_trans_class_array_init_assign): New function.
(gfc_trans_class_init_assign): Call it for array expressions.
* trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
class scalars since their size will depend on the dynamic type.
(build_class_array_ref): New function.
(gfc_conv_scalarized_array_ref): Call build_class_array_ref.
(gfc_array_init_size): Add extra argument, expr3, that represents
the SOURCE argument. If present,use this for the element size.
(gfc_array_allocate): Also add argument expr3 and use it when
calling gfc_array_init_size.
(structure_alloc_comps): Enable class arrays.
* class.c (gfc_add_component_ref): Carry over the derived type
of the _data component.
(gfc_add_class_array_ref): New function.
(class_array_ref_detected): New static function.
(gfc_is_class_array_ref): New function that calls previous.
(gfc_is_class_scalar_expr): New function.
(gfc_build_class_symbol): Throw not implemented error for
assumed size class arrays.  Remove error that prevents
CLASS arrays.
(gfc_build_class_symbol): Prevent pointer/allocatable conflict.
Also unset codimension.
(gfc_find_derived_vtab): Make 'copy' elemental and set the
intent of the arguments accordingly.: 
* trans-array.h : Update prototype for gfc_array_allocate.
* array.c (gfc_array_dimen_size): Return failure if class expr.
(gfc_array_size): Likewise.
* gfortran.h : New prototypes for gfc_add_class_array_ref,
gfc_is_class_array_ref and gfc_is_class_scalar_expr.
* trans-stmt.c (trans_associate_var): Exclude class targets
from test. Move the allocation of the _vptr to an earlier time
for class objects.
(trans_associate_var): Assign the descriptor directly for class
arrays.
(gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
Convert array element references into sections. Do not invoke
gfc_conv_procedure_call, use gfc_trans_call instead.
* expr.c (gfc_get_corank): Fix for BT_CLASS.
(gfc_is_simply_contiguous): Exclude class from test.
* trans.c (gfc_build_array_ref): Include class array refs.
* trans.h : Include prototypes for class API functions that are
new in trans-expr. Define GFC_DECL_CLASS(node).
* resolve.c (check_typebound_baseobject ): Remove error for
non-scalar base object.
(resolve_allocate_expr): Ensure that class _data component is
present. If array, call gfc_expr_to_intialize.
(resolve_select): Remove scalar error for SELECT statement as a
temporary measure.
(resolve_assoc_var): Update 'target' (aka 'selector') as
needed. Ensure that the target expression has the right rank.
(resolve_select_type): Ensure that target expressions have a
valid locus.
(resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
* trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
appropriate.
(gfc_trans_deferred_vars): Get class arrays right.
* match.c(

[Bug fortran/43214] [OOP] TBP with non-scalar PASS

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43214

--- Comment #2 from Paul Thomas  2011-12-11 20:42:28 
UTC ---
Author: pault
Date: Sun Dec 11 20:42:23 2011
New Revision: 182210

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182210
Log:
2011-12-11  Paul Thomas  
Tobias Burnus  

PR fortran/41539
PR fortran/43214
PR fortran/43969
PR fortran/44568
PR fortran/46356
PR fortran/46990
PR fortran/49074
* interface.c(symbol_rank): Return the rank of the _data
component of class objects.
(compare_parameter): Also compare the derived type of the class
_data component for type mismatch.  Similarly, return 1 if the
formal and _data ranks match.
(compare_actual_formal): Do not compare storage sizes for class
expressions. It is an error if an actual class array, passed to
a formal class array is not full.
* trans-expr.c (gfc_class_data_get, gfc_class_vptr_get,
gfc_vtable_field_get, gfc_vtable_hash_get, gfc_vtable_size_get,
gfc_vtable_extends_get, gfc_vtable_def_init_get,
gfc_vtable_copy_get): New functions for class API.
(gfc_conv_derived_to_class): For an array reference in an
elemental procedure call retain the ss to provide the
scalarized array reference. Moved in file.
(gfc_conv_class_to_class): New function.
(gfc_conv_subref_array_arg): Use the type of the
class _data component as a basetype.
(gfc_conv_procedure_call): Ensure that class array expressions
have both the _data reference and an array reference. Use 
gfc_conv_class_to_class to handle class arrays for elemental
functions in scalarized loops, class array elements and full
class arrays. Use a call to gfc_conv_subref_array_arg in order
that the copy-in/copy-out for passing class arrays to derived
type arrays occurs correctly.
(gfc_conv_expr): If it is missing, add the _data component
between a class object or component and an array reference.
(gfc_trans_class_array_init_assign): New function.
(gfc_trans_class_init_assign): Call it for array expressions.
* trans-array.c (gfc_add_loop_ss_code): Do not use a temp for
class scalars since their size will depend on the dynamic type.
(build_class_array_ref): New function.
(gfc_conv_scalarized_array_ref): Call build_class_array_ref.
(gfc_array_init_size): Add extra argument, expr3, that represents
the SOURCE argument. If present,use this for the element size.
(gfc_array_allocate): Also add argument expr3 and use it when
calling gfc_array_init_size.
(structure_alloc_comps): Enable class arrays.
* class.c (gfc_add_component_ref): Carry over the derived type
of the _data component.
(gfc_add_class_array_ref): New function.
(class_array_ref_detected): New static function.
(gfc_is_class_array_ref): New function that calls previous.
(gfc_is_class_scalar_expr): New function.
(gfc_build_class_symbol): Throw not implemented error for
assumed size class arrays.  Remove error that prevents
CLASS arrays.
(gfc_build_class_symbol): Prevent pointer/allocatable conflict.
Also unset codimension.
(gfc_find_derived_vtab): Make 'copy' elemental and set the
intent of the arguments accordingly.: 
* trans-array.h : Update prototype for gfc_array_allocate.
* array.c (gfc_array_dimen_size): Return failure if class expr.
(gfc_array_size): Likewise.
* gfortran.h : New prototypes for gfc_add_class_array_ref,
gfc_is_class_array_ref and gfc_is_class_scalar_expr.
* trans-stmt.c (trans_associate_var): Exclude class targets
from test. Move the allocation of the _vptr to an earlier time
for class objects.
(trans_associate_var): Assign the descriptor directly for class
arrays.
(gfc_trans_allocate): Add expr3 to gfc_array_allocate arguments.
Convert array element references into sections. Do not invoke
gfc_conv_procedure_call, use gfc_trans_call instead.
* expr.c (gfc_get_corank): Fix for BT_CLASS.
(gfc_is_simply_contiguous): Exclude class from test.
* trans.c (gfc_build_array_ref): Include class array refs.
* trans.h : Include prototypes for class API functions that are
new in trans-expr. Define GFC_DECL_CLASS(node).
* resolve.c (check_typebound_baseobject ): Remove error for
non-scalar base object.
(resolve_allocate_expr): Ensure that class _data component is
present. If array, call gfc_expr_to_intialize.
(resolve_select): Remove scalar error for SELECT statement as a
temporary measure.
(resolve_assoc_var): Update 'target' (aka 'selector') as
needed. Ensure that the target expression has the right rank.
(resolve_select_type): Ensure that target expressions have a
valid locus.
(resolve_allocate_expr, resolve_fl_derived0): Fix for BT_CLASS.
* trans-decl.c (gfc_get_symbol_decl): Set GFC_DECL_CLASS, where
appropriate.
(gfc_trans_deferred_vars): Get class arrays right.
* match.c(s

[Bug libstdc++/51504] Data race hunting instructions in manual do not work

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51504

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Paolo Carlini  2011-12-11 
20:36:01 UTC ---
You didn't read carefully the second paragraph, which clearly explain that you
have to rebuild the .so. In other terms, this is a known limitation.

[Bug fortran/51502] [4.6/4.7 Regression] Potentially wrong code generation due to wrong implict_pure check

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51502

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-11
 CC||tkoenig at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Thomas Koenig  2011-12-11 
20:29:39 UTC ---
Nitpick: A pure procedure could access the variable, but
it could assign a value to it.

Because

module m
  integer :: i
contains
  pure subroutine foo(x)
integer, intent(inout) :: x
outer: block
  block
i = 5
  end block
end block outer
  end subroutine foo
end module m

gives the error

Error: Variable 'i' can not appear in a variable definition context
(assignment) at (1) in PURE procedure

the fix should be straightforward.

[Bug libstdc++/51504] Data race hunting instructions in manual do not work

[bart.vanassche at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51504

--- Comment #1 from Bart Van Assche  
2011-12-11 20:26:47 UTC ---
Created attachment 26049
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26049
Detailed DRD output for the test program

[Bug libstdc++/51504] New: Data race hunting instructions in manual do not work

[bart.vanassche at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51504

 Bug #: 51504
   Summary: Data race hunting instructions in manual do not work
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bart.vanass...@gmail.com


Created attachment 26048
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26048
Test program that allows to reproduce the bug

According to the instructions in the "Data Race Hunting" paragraph
(http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html), the following
should be sufficient to avoid false positive data race reports on multithreaded
programs:

#include 
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(addr) \
  ANNOTATE_HAPPENS_BEFORE(addr)
#define _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(addr) \
  ANNOTATE_HAPPENS_AFTER(addr)
#define _GLIBCXX_EXTERN_TEMPLATE -1

Unfortunately that's not sufficient. The output I obtained for a small test
program is:

$ ./vg-in-place --tool=drd drd/tests/std_thread 2>&1 | grep -E 'Confl|SUMMARY'
==18629== Conflicting store by thread 1 at 0x0433e02c size 4
==18629== Conflicting store by thread 1 at 0x0433e02c size 4
==18629== Conflicting load by thread 1 at 0x0433e034 size 4
==18629== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 16 from 6)

After digging around a little I found out that in the created thread the 
reference count of the _Impl object is decremented from inside libstdc++. So no
matter which macros are defined in the code that includes , that
reference count decrementing code won't be annotated. Moving the implementation
of the function execute_native_thread_routine() from src/thread.cc to
include/std/thread might fix this (haven't tried this).

Detailed information:
$ uname -a
Linux f16 3.1.4-1.fc16.i686.PAE #1 SMP Tue Nov 29 12:23:00 UTC 2011 i686 i686
i386 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.6.2/lto-wrapper
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i686
--build=i686-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)

This bug can be reproduced by running the following commands on a system with
gcc 4.6.x:
svn co -r12291 svn://svn.valgrind.org/valgrind/trunk valgrind
cd valgrind
./autogen.sh
./configure
make -s
make -s check
./vg-in-place --tool=drd drd/tests/std_thread

[Bug tree-optimization/50569] [4.6/4.7 regression] unaligned memory accesses generated for memcpy

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569

--- Comment #12 from Mikael Pettersson  2011-12-11 
20:11:14 UTC ---
Eric's proposed patch applied on top of gcc-4.7-20111210 fixes both test cases
for me on sparc-linux and arm-linux-gnueabi.

[Bug fortran/51338] [4.6/4.7 Regression] seg fault in gfc_dep_compare_expr with -O2

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Thomas Koenig  2011-12-11 
20:04:39 UTC ---
Fixed on trunk and 4.6, closing.

[Bug fortran/51338] [4.6/4.7 Regression] seg fault in gfc_dep_compare_expr with -O2

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338

--- Comment #10 from Thomas Koenig  2011-12-11 
20:03:47 UTC ---
Author: tkoenig
Date: Sun Dec 11 20:03:43 2011
New Revision: 182209

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182209
Log:
2011-12-11  Thomas Koenig  

PR fortran/51338
Backport from trunk
* dependency.c (are_identical_variables):  Handle case where
end fields of substring references are NULL.

2011-12-11  Thomas Koenig  

PR fortran/51338
Backport from trunk
* gfortran.dg/assumed_charlen_substring_1.f90:  New test.


Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/dependency.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #18 from Iain Sandoe  2011-12-11 20:01:37 
UTC ---
(In reply to comment #17)
> Hello,
> 
> Here comes gcc-4.7.20111203 with (not unexpectedly) exactly the same symptoms
> (see Description above). I tried the patches provided in Comments #4 and #5
> with no success:
> 11 out of 13 hunks FAILED -- saving rejects to file gcc/dwarf2out.c.rej
> 1 out of 3 hunks FAILED -- saving rejects to file gcc/config/darwin.c.rej
> 1 out of 1 hunk FAILED -- saving rejects to file gcc/config/darwin10.h.rej

The mechanism in dwarf2out changed between 4.6 and 4.7 - so the code actually
needs changing.

> The two patches have been working successfully for all 4.6.x versions. Can we
> expect an update  of them for GCC 4.7?

I guess... the thing is that this is not really the 'ideal' solution -
 since by holding the unwinder of Darwin at the 4.4 flavor -  the behavior of
Darwin will start to diverge (more than usual) from that of other systems... 

... so...  I've been investigating other ways of resolving the problem (in
amongst all the other things to be done)...

> P.S.
> Am i the only one needing this patch? As far as i am concerned, i can live 
> with
> the above workaround.

no - you are not - the compiler is essentially broken without a working
unwinder ...

However, Darwin10+ are not affected by this (unless you try to use the unwind
compacter) - so the screaming is not so loud as it might otherwise be ;)

...  I am considering a more radical Darwin-9-only solution (that allows us to
keep track of the current unwinder)
 - time is, as always, the killer ...

[Bug gcov-profile/51361] [4.7 Regression] 471.omnetpp of SPEC2006 fails to build with -fprofile-generate

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51361

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[g...@denis-excoffier.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

Denis Excoffier  changed:

   What|Removed |Added

Version|4.6.0   |4.7.0

--- Comment #17 from Denis Excoffier  2011-12-11 
19:45:48 UTC ---
Hello,

Here comes gcc-4.7.20111203 with (not unexpectedly) exactly the same symptoms
(see Description above). I tried the patches provided in Comments #4 and #5
with no success:
11 out of 13 hunks FAILED -- saving rejects to file gcc/dwarf2out.c.rej
1 out of 3 hunks FAILED -- saving rejects to file gcc/config/darwin.c.rej
1 out of 1 hunk FAILED -- saving rejects to file gcc/config/darwin10.h.rej

The two patches have been working successfully for all 4.6.x versions. Can we
expect an update
of them for GCC 4.7?

You must know that i also tried the same as before:
sed -e 's|^ifeq (/usr/lib,|ifneq (/usr/lib,|g' libgcc/config/t-slibgcc-darwin
and of course it works.

Regards,

Denis Excoffier.

P.S.
Am i the only one needing this patch? As far as i am concerned, i can live with
the above workaround.

[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Thomas Koenig  2011-12-11 
17:48:40 UTC ---
Fixed (finally), closing.

[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690

--- Comment #8 from Thomas Koenig  2011-12-11 
17:43:26 UTC ---
Author: tkoenig
Date: Sun Dec 11 17:43:22 2011
New Revision: 182208

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182208
Log:
2011-12-11  Thomas Koenig  

PR fortran/50690
* frontend-passes.c (in_omp_workshare):  New variable.
(cfe_expr_0):  Don't eliminiate common function if it would put
the variable immediately into a WORKSHARE construct.
(optimize_namespace):  Set in_omp_workshare.
(gfc_code_walker):  Keep track of OMP PARALLEL and OMP WORKSHARE
constructs.

2011-12-11  Thomas Koenig  

PR fortran/50690
* gfortran.dg/gomp/workshare2.f90:  New test.
* gfortran.dg/gomp/workshare3.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/gomp/workshare2.f90
trunk/gcc/testsuite/gfortran.dg/gomp/workshare3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51502] [4.6/4.7 Regression] Potentially wrong code generation due to wrong implict_pure check

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51502

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.3
Summary|[4.6/4.7 Regression]|[4.6/4.7 Regression]
   |Potentially wrong code due  |Potentially wrong code
   |to wrong implict_pure check |generation due to wrong
   ||implict_pure check

[Bug rtl-optimization/51495] [4.7 Regression] ICE: in force_nonfallthru_and_redirect, at cfgrtl.c:1171 with computed goto

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51495

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-11
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43289

--- Comment #4 from Tobias Burnus  2011-12-11 
17:17:18 UTC ---
Created attachment 26047
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26047
Draft patch w/ test case

Patch TODO: Handle implicit pure, cf. PR 51502.

The error location is not ideal, but finding the expression locus requires
adding this check at every place where sym->referenced.

[Bug bootstrap/51503] New: [4.7 Regression] Failure to build (non-bootstrap) gcc libitm if only building C

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51503

 Bug #: 51503
   Summary: [4.7 Regression] Failure to build (non-bootstrap) gcc
libitm if only building C
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@gcc.gnu.org


Non-bootstrap builds currently fail on the CompileFarm's gcc17:

stevenb@gcc17:~/devel/build$ make CFLAGS="-O0 -g2"
...
libtool: compile:  g++ -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unkn
own-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../../../trunk/libitm -I../../../trunk/
libitm/config/linux/x86 -I../../../trunk/libitm/config/linux
-I../../../trunk/libitm/config/x86 -I../../../trunk/libitm/config/posix -I../..
/../trunk/libitm/config/generic -I../../../trunk/libitm -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -Wall -pthread -Werror -fabi-
version=4 -g -O2 -D_GNU_SOURCE -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c
../../../trunk/libitm/aatree.cc  -fPIC -DPIC -o .libs/aatree.o
cc1plus: warnings being treated as errors
In file included from ../../../trunk/libitm/libitm_i.h:32,
 from ../../../trunk/libitm/aatree.cc:28:
../../../trunk/libitm/libitm.h:154: error: â?~transaction_pureâ?T attribute
directive ignored
../../../trunk/libitm/libitm.h:157: error: â?~transaction_pureâ?T attribute
directive ignored
../../../trunk/libitm/libitm.h:160: error: â?~transaction_pureâ?T attribute
directive ignored
../../../trunk/libitm/libitm.h:162: error: â?~transaction_pureâ?T attribute
directive ignored
...
make[4]: *** [aatree.lo] Error 1
make[4]: Leaving directory
`/home/stevenb/devel/build/x86_64-unknown-linux-gnu/libitm'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/stevenb/devel/build/x86_64-unknown-linux-gnu/libitm'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/stevenb/devel/build/x86_64-unknown-linux-gnu/libitm'
make[1]: *** [all-target-libitm] Error 2
make[1]: Leaving directory `/home/stevenb/devel/build'
make: *** [all] Error 2
stevenb@gcc17:~/devel/build$ cat gcc/configargs.h
/* Generated automatically. */
static const char configuration_arguments[] = "../trunk/configure
--with-mpfr=/opt/cfarm/mpfr-2.4.1/ --with-gmp=/opt/cfarm/gmp-4.2.4/ --with
-mpc=/opt/cfarm/mpc-0.8/ --enable-languages=c --disable-libmudflap
--disable-libssp --disable-werror --disable-bootstrap";
static const char thread_model[] = "posix";

static const struct {
  const char *name, *value;
} configure_default_options[] = { { "cpu", "generic" }, { "arch", "x86-64" } };
stevenb@gcc17:~/devel/build$ g++ --version
g++ (Debian 4.3.2-1.1) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

stevenb@gcc17:~/devel/build$
Note the "--enable-languages=c". The host g++ is used, and it doesn't know the
attributes used in libitm.

As with PR51388, I put this in the "bootstrap" category because there is no
category for non-bootstrap build failures.

[Bug fortran/51502] New: [4.6/4.7 Regression] Potentially wrong code due to wrong implict_pure check

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51502

 Bug #: 51502
   Summary: [4.6/4.7 Regression] Potentially wrong code due to
wrong implict_pure check
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


The following code has a procedure which is not PURE as it accesses a
host-associated variable. However, this is not detected and thus the procedure
is marked as IMPLICIT_PURE as "grep _PURE m.mod" shows:
  0 0 SUBROUTINE IMPLICIT_PURE) (UNKNOWN 0 0 0 0 UNKNOWN ()) 3 0 (4) () 0


module m
  integer :: i
contains
  subroutine foo(x)
integer, intent(inout) :: x
outer: block
  block
i = 5
  end block
end block outer
  end subroutine foo
end module m

[Bug gcov-profile/51361] [4.7 Regression] 471.omnetpp of SPEC2006 fails to build with -fprofile-generate

[venkataramanan.kumar.gnu at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51361

--- Comment #5 from Venkataramanan Kumar  2011-12-11 16:58:21 UTC ---
The defect does not occur now. I checked in revision 182206.

[Bug tree-optimization/51499] vectorizer missing simple case

[fb.programming at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51499

--- Comment #7 from fb.programming at gmail dot com 2011-12-11 14:55:13 UTC ---
(In reply to comment #5)

> > (3) If I change all double's into float's in the code above it seems to

> I think you are looking at the scalar epilogue. The number of iterations is
> unknown, so we need an epilogue loop for the case that number of iterations is
> not a multiple of 4.

Yes you're right. Sorry about that, my mistake.


> > (1) In this case it should work without -funsafe-math-optimizations but
> > it doesn't. gcc 4.7 requires -fno-signed-zeros -fno-trapping-math
> >-fassociative-math to make it work.
> > 
> 
> It's reduction, when we vectorize we change the order of computation. In order
> to be able to do that for floating point we need flag_associative_math.

In some cases it might be necessary but not here:

 sum1+=a;
 sum2+=a;

gives exactly the same result as

 (sum1, sum2) += (a, a);

Lets take a more applied example, say calculating the sum of 1/i:

   double harmon(int n) {
  double sum=0.0;
  for(int i=1; i

[Bug tree-optimization/51499] vectorizer missing simple case

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51499

--- Comment #6 from Dominique d'Humieres  2011-12-11 
14:14:01 UTC ---
> I think you are looking at the scalar epilogue. The number of iterations is
> unknown, so we need an epilogue loop for the case that number of iterations is
> not a multiple of 4.

While investigating pr51597, I have found that vectorized loops in programs as
simple as

subroutine spmmult(x,b,ad)
implicit none
integer, parameter :: nxyz=1008315
real(8),dimension(nxyz):: x,b,ad
b = ad*x
end subroutine spmmult   !=

has always an additional non-vectorized loop, i.e. a vectorized one

L3:
movsd   (%r9,%rax), %xmm1
addq$1, %rcx
movapd  (%r10,%rax), %xmm0
movhpd  8(%r9,%rax), %xmm1
mulpd   %xmm1, %xmm0
movlpd  %xmm0, (%r8,%rax)
movhpd  %xmm0, 8(%r8,%rax)
addq$16, %rax
cmpq$504156, %rcx
jbe L3

and a non-vectorized one

L5:
movsd   -8(%rdi,%rax,8), %xmm0
mulsd   -8(%rdx,%rax,8), %xmm0
movsd   %xmm0, -8(%rsi,%rax,8)
addq$1, %rax
cmpq%rcx, %rax
jne L5

even when the above loops are unrolled. How can the loop L5 be unrolled if it
is only there for a "scalar epilogue"?

[Bug lto/51497] [4.7 Regression] The run time for the polyhedron test nf.f90 is ~10% slower with -flto after revision 182107

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51497

--- Comment #2 from Dominique d'Humieres  2011-12-11 
14:07:59 UTC ---
Upon further looking at the assembly, I have found that the seven loops in
spmmult are all vectorized without -flto, while none of them are with -flto. 

For nf2dprecon after trisolve inlining, the code looks like

subroutine NF2DPrecon(x,gi,au1,au2,i1,i2,nx)   ! 2D NF Preconditioning
matrix
implicit none
integer :: i1,i2,nx
real(8),dimension(i2)::x,t,gi,au1,au2
integer :: i,j
do i = i1 , i2 , nx
   if ( i>i1 ) x(i:i+nx-1) = x(i:i+nx-1) - au2(i-nx:i-1)*x(i-nx:i-1)
   x(i) = gi(i)* x(i)
   do j = i+1 , i+nx-1
  x(j) = gi(j)*(x(j)-au1(j-1)*x(j-1))
   enddo
   do j = i+nx-2 , i , -1
  x(j) = x(j) - gi(j)*au1(j)*x(j+1)
   enddo
enddo 
do i = i2-2*nx+1 , i1 , -nx
   t(i:i+nx-1) = au2(i:i+nx-1)*x(i+nx:i+2*nx-1)
   t(i) = gi(i)* t(i)
   do j = i+1 , i+nx-1
  t(j) = gi(j)*(t(j)-au1(j-1)*t(j-1))
   enddo
   do j = i+nx-2 , i , -1
  t(j) = t(j) - gi(j)*au1(j)*t(j+1)
   enddo
   x(i:i+nx-1) = x(i:i+nx-1) - t(i:i+nx-1)
enddo
end subroutine NF2DPrecon!=

where none of the explicit 'do j' loops are vectorized ("possible dependence
between data-refs") while the three implicit loops are vectorized without
-flto, while only the last two are with -flto. Note that the first loop not
vectorized with -lflto:

x(i:i+nx-1) = x(i:i+nx-1) - au2(i-nx:i-1)*x(i-nx:i-1)

is vectorized without it with "created 1 versioning for alias checks." (alias
between au2 and x? if yes, valid Fortran codes guarantee that there is no
aliasing).

[Bug target/51445] g++ sometimes miscompiles code for the avr target

[dhowells at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51445

dhowe...@redhat.com  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from dhowells at redhat dot com  
2011-12-11 13:56:37 UTC ---
The problem appears to be fixed in gcc-4.6.2.

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #11 from Marc Glisse  2011-12-11 
13:51:20 UTC ---
(In reply to comment #10)
> I haven't really thought about it either, but one advantage of depending on
> is_empty is that it prevents using the EBO for polymorphic classes, where
> derivation could have undesirable effects.

Ah, right, the set of types that can safely be derived from is rather
restricted: non-builtin, non-final, non-virtual (and possibly more
constraints). And to benefit from additional packing: non-C++03-POD. Probably
not worth the trouble...

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #10 from Jonathan Wakely  2011-12-11 
13:39:20 UTC ---
I haven't really thought about it either, but one advantage of depending on
is_empty is that it prevents using the EBO for polymorphic classes, where
derivation could have undesirable effects.  That *shouldn't* be a problem as
long as user-defined types don't have virtual functions using reserved names
such as _M_get.

Another problem could be user-defined types with a virtual base, if the tuple
node type (which would be the most-derived type) doesn't know how to construct
the virtual base.

struct A { A(int) { } };

struct B : virtual A { B() : A(1) { } };

std::tuple t;

If tuple derived from B it couldn't construct the A subobject correctly.

[Bug tree-optimization/51499] vectorizer missing simple case

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51499

--- Comment #5 from Ira Rosen  2011-12-11 13:30:41 UTC 
---
(In reply to comment #4)
> Looks like there has been some great progress in gcc 4.7!
> 
> Still I think it behaves slightly buggy.
> 
> (1) In this case it should work without -funsafe-math-optimizations but
> it doesn't. gcc 4.7 requires -fno-signed-zeros -fno-trapping-math
>-fassociative-math to make it work.
> 

It's reduction, when we vectorize we change the order of computation. In order
to be able to do that for floating point we need flag_associative_math.

> (2) The prediction:
>7: not vectorized: vectorization not profitable.
> is just wrong. Forcing it with -fno-vect-cost-model shows it speeds up
> by factor of 2.
> 
> (3) If I change all double's into float's in the code above it seems to
> work without forcing it (-fno-vect-cost-model):
> 
> 
>g++-4.7 -S -Wall -O2  -ftree-vectorize -ftree-vectorizer-verbose=2 \
>-funsafe-math-optimizations test.cpp
> 
>Analyzing loop at test.cpp:7
> 
> 
>Vectorizing loop at test.cpp:7
> 
>7: vectorizing stmts using SLP.
>7: LOOP VECTORIZED.
>test.cpp:4: note: vectorized 1 loops in function.
> 
> 
> However, it hasn't vectorized it at all as the assembly shows:
> 
> .L11:
> addq$1, %rax
> addss%xmm0, %xmm3
> cmpq%rax, %rdi
> addss%xmm0, %xmm4
> addss%xmm0, %xmm7
> addss%xmm0, %xmm6
> addss%xmm0, %xmm5
> addss%xmm0, %xmm1
> ja.L11


I think you are looking at the scalar epilogue. The number of iterations is
unknown, so we need an epilogue loop for the case that number of iterations is
not a multiple of 4.

[Bug fortran/51284] [OOP] CLASS and VALUE attribute: No copy to temporary done

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51284

--- Comment #3 from Tobias Burnus  2011-12-11 
12:54:29 UTC ---
(In reply to comment #2)
> - Handle the "copy in" for derived types and class (both scalar and array)

For derived types: The arguments are passed by value thus it works. However, no
copying is done for allocatable components. Note: Also "( )" (=
INTRINSIC_PARENTHESES) does not work for DT w/ allocatable components.

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #9 from Marc Glisse  2011-12-11 
12:12:29 UTC ---
Hello,

the recent discussion "Structure alignment changes when a constructor or
destructor is added" on gcc-help made me wonder whether it would make sense to
not only derive for empty classes, but actually derive by default and use
members only when necessary (builtin types, final classes). The advantage would
be that derivation allows for a slightly more compact representation in some
cases with the g++ ABI. I really haven't thought much about the consequences.

Sorry for hijacking this bug with this wild idea, but in case it makes sense it
might change slightly the way you want to fix it.

[Bug tree-optimization/51499] vectorizer missing simple case

[fb.programming at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51499

--- Comment #4 from fb.programming at gmail dot com 2011-12-11 11:52:30 UTC ---
Looks like there has been some great progress in gcc 4.7!

Still I think it behaves slightly buggy.

(1) In this case it should work without -funsafe-math-optimizations but
it doesn't. gcc 4.7 requires -fno-signed-zeros -fno-trapping-math
   -fassociative-math to make it work.

(2) The prediction:
   7: not vectorized: vectorization not profitable.
is just wrong. Forcing it with -fno-vect-cost-model shows it speeds up
by factor of 2.

(3) If I change all double's into float's in the code above it seems to
work without forcing it (-fno-vect-cost-model):


   g++-4.7 -S -Wall -O2  -ftree-vectorize -ftree-vectorizer-verbose=2 \
   -funsafe-math-optimizations test.cpp

   Analyzing loop at test.cpp:7


   Vectorizing loop at test.cpp:7

   7: vectorizing stmts using SLP.
   7: LOOP VECTORIZED.
   test.cpp:4: note: vectorized 1 loops in function.


However, it hasn't vectorized it at all as the assembly shows:

.L11:
addq$1, %rax
addss%xmm0, %xmm3
cmpq%rax, %rdi
addss%xmm0, %xmm4
addss%xmm0, %xmm7
addss%xmm0, %xmm6
addss%xmm0, %xmm5
addss%xmm0, %xmm1
ja.L11

[Bug c++/51501] decltype over-agressive SFINAE

[dave at boostpro dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501

--- Comment #3 from Dave Abrahams  2011-12-11 
10:32:25 UTC ---
(In reply to comment #2)
> Could this be related to Bug 45873?

Not if your explanation in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45873#c2
is correct, I think.  This is a straightforward pack expansion with no change
in the number of arguments.

[Bug libstdc++/44436] [C++0x] Implement emplace* in associative containers

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |fdumont at gcc dot gnu.org
Summary|[C++0x] Implement emplace*  |[C++0x] Implement emplace*
   |in associative and  |in associative containers
   |unordered containers|

--- Comment #31 from Paolo Carlini  2011-12-11 
10:31:11 UTC ---
Unordered containers done with this patch:

2011-12-09  François Dumont 

PR libstdc++/44436 (unordered containers emplace, emplace_hint bits)
* include/bits/hashtable.h (_Hashtable<>::emplace,
_Hashtable<>::emplace_hint): Add.
...

[Bug c++/51501] decltype over-agressive SFINAE

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #2 from Marc Glisse  2011-12-11 
09:41:00 UTC ---
Could this be related to Bug 45873?

[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43289

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  2011-12-11 
09:04:58 UTC ---
Also invalid:

module foo
  implicit none
  real, volatile:: vol
contains
  pure subroutine bar(a)
real, intent(out) :: a
a = vol
  end subroutine bar
end module foo

F2008 has

"C1282 A designator of a variable with the VOLATILE attribute shall not
appear in a pure subprogram."

[Bug tree-optimization/51499] vectorizer missing simple case

[irar at il dot ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51499

--- Comment #3 from Ira Rosen  2011-12-11 08:48:24 UTC 
---
It gets vectorized with 4.7.
I guess, due to this 4.7 patch
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00620.html.

[Bug tree-optimization/51499] vectorizer missing simple case

[fb.programming at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51499

--- Comment #2 from fb.programming at gmail dot com 2011-12-11 08:33:40 UTC ---
(In reply to comment #1)

g++-4.6.2 -S -Wall -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 \
  -ffast-math  -fno-vect-cost-model

gives me exactly the same assembly code as above (which I'm surprised
a bit as -funsafe-math-optimizations might as well have eliminated the
loop completely).

The optimal assembly, however, I would expect to be something like:

.L3:
addq$1, %rax
addpd%xmm0, %xmm3
cmpq%rdi, %rax
addpd%xmm0, %xmm2
addpd%xmm0, %xmm1
jne.L3

Where the vector (sum1,sum2) is stored in xmm1, (sum3,sum4) stored in
xmm2, etc and (a,a) stored in xmm0. This speeds it up by a factor of 2
and is completely equivalent to the scalar case so I don't see why
-ffast-math (which implies -funsafe-math-optimizations) should be
necessary in this case, either.

[Bug ada/49084] [4.7 regression] bootstrap failure with Ada enabled

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49084

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #17 from Eric Botcazou  2011-12-11 
08:29:01 UTC ---
> The culprit is the struct Flag_Word (gcc/ada/atree.h:116), included in Node,
> which increased from 4 bytes to 6 bytes:
> 
> struct Flag_Word
> {
>   Boolean  flag73:  1;
>   Boolean  flag74:  1;
>   Boolean  flag75:  1;
>   Boolean  flag76:  1;
>   Boolean  flag77:  1;
>   Boolean  flag78:  1;
>   Boolean  flag79:  1;
>   Boolean  flag80:  1;
>   Boolean  flag81:  1;
>   Boolean  flag82:  1;
>   Boolean  flag83:  1;
>   Boolean  flag84:  1;
>   Boolean  flag85:  1;
>   Boolean  flag86:  1;
>   Boolean  flag87:  1;
>   Boolean  flag88:  1;
>   Boolean  flag89:  1;
>   Boolean  flag90:  1;
>   Boolean  flag91:  1;
>   Boolean  flag92:  1;
>   Boolean  flag93:  1;
>   Boolean  flag94:  1;
>   Boolean  flag95:  1;
>   Boolean  flag96:  1;
>   Shortconvention   :  8;
> };
> 
> On MinGW, the bitfield packing convention has changed in GCC 4.7: it now
> follows the Microsoft compiler (-mms-bitfields). Since the size of the
> "convention" field (16 bit short) is different from the previous one (8 bit
> unsigned char), padding is added until it starts on a new 16 bit boundary.

Nice work!

> Indeed, rebuilding GCC with make 'BOOT_CFLAGS=-g -O2 -mno-ms-bitfields' allows
> the build to proceed to completion. Changing Short to Byte in Flag_Word also
> works.

Let's do the latter.  Would you mind posting a patch on gcc-patches?  TIA.