[Bug fortran/51056] [4.7 Regression][OOP] Bogus "Unused module variable '__vtab_domain_Domain_container'"

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2012-01-20 
08:07:06 UTC ---
Author: burnus
Date: Fri Jan 20 08:06:53 2012
New Revision: 183326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183326
Log:
2012-01-20  Tobias Burnus  
Janus Weil  

PR fortran/51056
* module.c (load_needed, read_module): Don't mark __vtab etc.
as use_only.

2012-01-20  Tobias Burnus  
Janus Weil  

PR fortran/51056
* gfortran.dg/use_21.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/use_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51056] [4.7 Regression][OOP] Bogus "Unused module variable '__vtab_domain_Domain_container'"

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Tobias Burnus  2012-01-20 
08:07:47 UTC ---
FIXED on the trunk (4.7).

[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets

[aurelien.buhrig.gcc at gmail dot com]

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

--- Comment #4 from Aurelien Buhrig  
2012-01-20 09:00:38 UTC ---
After modifying this patch for 4.6.1 this patch doesn't work (bitfld-3.c
testcase).

It doesn't affect the value subword offset computation (wordnum) when calling
operand_subword_force.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2012-01-20 
09:07:54 UTC ---
(In reply to comment #10)
> > I wonder why it does this, instead of just using type S, and if it really 
> > has
> > to for some reason, why it can't at least make sure it has the same 
> > TYPE_MODE.
> > Changing a TImode argument to a BLKmode argument doesn't look at least like 
> > a
> > good optimization.
> 
> I concur, BLKmode means spilling to memory at some point, so this looks like a
> clear pessimization to me.

Sure, but I believe just that eipa_sra is what is causing this pessimization by
doing a bad decision.
Anyway, if you prefer one of the other 3 patches (for now?), which one it is? 
Or some other place to handle it?

[Bug target/50313] ARM: PIC code references a non-existant label

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  2012-01-20 
09:22:21 UTC ---
Author: ramana
Date: Fri Jan 20 09:22:14 2012
New Revision: 183328

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183328
Log:

Fix PR target/50313


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md

[Bug fortran/51913] New: bug when submitting a class pointer to a subroutine

[nagl46 at web dot de]

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

 Bug #: 51913
   Summary: bug when submitting a class pointer to a subroutine
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nag...@web.de


Created attachment 26390
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26390
buggy program

When I declare a pointer in main routine:
>> CLASS(sparseMatrix_t), pointer :: sparseMatrix

Then I pass this pointer to a subroutine
>> call test(sparseMatrix)

I get a compiler error message:
>> Error: Actual argument to 'matrix' at (1) must have the same declared type

Please find attached a small program that does not work and fails compiling
with this error. I find this fault in gfortran-4.6.1 and gfortran-4.7.0
20111210.
I compiled with 'gfortran main.f90'.

[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  2012-01-20 
09:37:25 UTC ---
Right now I think cc1/cc1plus/etc. would be happy even with an empty
libstdc++.a (they are compiled with -fno-exceptions -fno-rtti, so shouldn't
need even libsupc++) and go1 I think uses just the c++98 stuff and libsupc++.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  2012-01-20 
09:41:41 UTC ---
> Sure, but I believe just that eipa_sra is what is causing this pessimization 
> by
> doing a bad decision.

Precisely, so why not change that?

> Anyway, if you prefer one of the other 3 patches (for now?), which one it is? 

Yours looks less hackish for sure. :-)

[Bug tree-optimization/51914] New: [4.7] All vect-intfloat-conversion tests fail for arm-linux-gnueabi

[ramana at gcc dot gnu.org]

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

 Bug #: 51914
   Summary: [4.7] All vect-intfloat-conversion tests fail for
arm-linux-gnueabi
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
CC: i...@gcc.gnu.org
Target: arm-*
 Build: x86*


All the vect-intfloat-conversion tests fail for arm-linux-gnueabi with an ICE
in vectorizable_store . 


FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c (internal compiler error)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c (test for excess errors)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c (internal compiler error)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c (test for excess errors)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c -flto (internal compiler error)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c -flto (test for excess errors)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c -flto scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c -flto (internal compiler error)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c -flto (test for excess errors)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c -flto scan-tree-dump-times vect
"vectorized 1 loops" 1



#1  0x006320bc in vectorizable_store (stmt=0x405cd8a0, gsi=0x4, vec_stmt=0x2,
slp_node=0x2) at ../../gcc-git-trunk/gcc/tree-vect-stmts.c:3892
3892  gcc_assert (useless_type_conversion_p (vectype,
(gdb) bt
#0  fancy_abort (file=0xa38948 "../../gcc-git-trunk/gcc/tree-vect-stmts.c",
line=3893, function=0xa3870c "vectorizable_store") at
../../gcc-git-trunk/gcc/diagnostic.c:898
#1  0x006320bc in vectorizable_store (stmt=0x405cd8a0, gsi=0x4, vec_stmt=0x2,
slp_node=0x2) at ../../gcc-git-trunk/gcc/tree-vect-stmts.c:3892
#2  0x0063d6d0 in vect_transform_stmt (stmt=0x407f6900, gsi=0x4080a000,
strided_store=0xbefff43f, slp_node=0x0, slp_node_instance=0x0) at
../../gcc-git-trunk/gcc/tree-vect-stmts.c:5474
#3  0x0064cd7c in vect_transform_loop (loop_vinfo=0x0) at
../../gcc-git-trunk/gcc/tree-vect-loop.c:5415
#4  0x0065b0ec in vectorize_loops () at
../../gcc-git-trunk/gcc/tree-vectorizer.c:214
#5  0x00400040 in execute_one_pass (pass=0xbc3400) at
../../gcc-git-trunk/gcc/passes.c:2081
#6  0x00400404 in execute_pass_list (pass=0xbc3400) at
../../gcc-git-trunk/gcc/passes.c:2136
#7  0x0040041c in execute_pass_list (pass=0xbc3504) at
../../gcc-git-trunk/gcc/passes.c:2137
#8  0x0040041c in execute_pass_list (pass=0xbc2db4) at
../../gcc-git-trunk/gcc/passes.c:2137
#9  0x00517838 in tree_rest_of_compilation (fndecl=0x407e3c80) at
../../gcc-git-trunk/gcc/tree-optimize.c:421
#10 0x001e9b78 in cgraph_expand_function (node=0x405ce540) at
../../gcc-git-trunk/gcc/cgraphunit.c:1818
#11 0x001ebb4c in cgraph_expand_all_functions () at
../../gcc-git-trunk/gcc/cgraphunit.c:1885
#12 cgraph_optimize () at ../../gcc-git-trunk/gcc/cgraphunit.c:2199
#13 0x001ec214 in cgraph_finalize_compilation_unit () at
../../gcc-git-trunk/gcc/cgraphunit.c:1327
#14 0x000daf08 in c_write_global_declarations () at
../../gcc-git-trunk/gcc/c-decl.c:10031
#15 0x004a8a58 in compile_file () at ../../gcc-git-trunk/gcc/toplev.c:573
#16 do_compile () at ../../gcc-git-trunk/gcc/toplev.c:1938
#17 toplev_main (argc=0, argv=0xd38a70) at
../../gcc-git-trunk/gcc/toplev.c:2014
#18 0x40429c3a in __libc_start_main () from /lib/arm-linux-gnueabi/libc.so.6
#19 0x000be8a2 in _start ()

[Bug tree-optimization/51914] [4.7] vect-intfloat-conversion4a/b tests fail for arm-linux-gnueabi

[ramana at gcc dot gnu.org]

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

--- Comment #1 from Ramana Radhakrishnan  2012-01-20 
09:50:52 UTC ---
arch specific command line options used:

-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp

[Bug target/51907] SIGSEGV in _Unwind_GetIP

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-20
 Ever Confirmed|0   |1

--- Comment #1 from Kai Tietz  2012-01-20 09:52:58 
UTC ---
Confirmed.  It happens for 32-bit and 64-bit targets

[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  2012-01-20 
10:04:50 UTC ---
> After modifying this patch for 4.6.1 this patch doesn't work (bitfld-3.c
> testcase).

What do you mean exactly?  That gnat.dg/bitfld-3.c fails with the patch?

[Bug tree-optimization/51903] [4.7 Regression] ICE: in gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196 with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-01-20 
10:10:54 UTC ---
Author: rguenth
Date: Fri Jan 20 10:10:46 2012
New Revision: 183329

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183329
Log:
2012-01-20  Richard Guenther  

PR tree-optimization/51903
* tree-ssa-pre.c (eliminate): Properly purging of EH edges
when removing stmts.

* g++.dg/torture/pr51903.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr51903.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/51903] [4.7 Regression] ICE: in gimple_purge_all_dead_eh_edges, at tree-cfg.c:7196 with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2012-01-20 
10:11:49 UTC ---
Fixed.

[Bug rtl-optimization/34283] Non-optimal reload register used

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org
  Known to fail||4.7.0

--- Comment #4 from Uros Bizjak  2012-01-20 10:15:32 
UTC ---
Still present on x86_64. -O2 -march=corei7:

movd%rsi, %xmm1
pinsrq  $1, %rdi, %xmm1
movdqa  %xmm1, %xmm0
ret

GCC: (GNU) 4.7.0 20120118 (experimental) [trunk revision 183277]

Re-confirmed and added CC.

[Bug c++/38610] local objects not hidden with -fvisibility=hidden.

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-01-20 
10:23:15 UTC ---
Oops, Ok.

[Bug c++/41233] Templated conversion operator produces symbol name that won't demangle

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |iant at google dot com

--- Comment #7 from Paolo Carlini  2012-01-20 
10:28:27 UTC ---
Ian, are you aware of this standing issue? Thanks in advance.

[Bug tree-optimization/34011] Memory load is not eliminated from tight vectorized loop

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

   Last reconfirmed|2009-09-12 20:02:13 |2012-01-20 20:02:13
  Known to fail||4.7.0

--- Comment #8 from Uros Bizjak  2012-01-20 10:29:54 
UTC ---
Reconfirmed with

"GCC: (GNU) 4.7.0 20120118 (experimental) [trunk revision 183277]"

[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets

[aurelien.buhrig.gcc at gmail dot com]

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

--- Comment #6 from Aurelien Buhrig  
2012-01-20 10:32:22 UTC ---

(In reply to comment #5)
> > After modifying this patch for 4.6.1 this patch doesn't work (bitfld-3.c
> > testcase).
> 
> What do you mean exactly?  That gnat.dg/bitfld-3.c fails with the patch?

I mean the patch was likely done for 4.7, and I made very small adjustments to
enable patching on 4.6.1.

The testcase that fails is gcc.c-torture/execute/bitfld-3.c. Both with and
without (4.6.1 release) the patch. 
The patch I posted fixes the problem, but I don't know if it is general enough.

[Bug middle-end/41256] ICE with -ftree-parallelize-loops=2 in locator_location at cfglayout.c:517

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Uros Bizjak  2012-01-20 10:39:57 
UTC ---
The ICE is gone with 4.5.4+.

[Bug target/50813] gcc.dg/torture/vshuf-{v4di,v8si}.c fail on AVX target

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #4 from Uros Bizjak  2012-01-20 10:41:52 
UTC ---
Fixed.

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #26385|0   |1
is obsolete||

--- Comment #2 from Jakub Jelinek  2012-01-20 
10:46:29 UTC ---
Created attachment 26391
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26391
gcc47-pr51902.patch

This updated patch does that (I actually managed to implement it without
any sort of extra hash table or array).  Fixes up the testcase, I wonder if I
can find a testcase where the supercontext doesn't have completely identical
range, but only tail of it (i.e. that nested block/inlined subroutine could
refer to a couple of tail elements in supercontext's range).
Mark, can you please look at this if it does the right thing you want from it?

[Bug target/49257] -mfpmath=sse generates x87 instructions on 32 bits OS

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX

--- Comment #18 from Uros Bizjak  2012-01-20 11:06:16 
UTC ---
The only way this could work is to put __builtin_ia32_emms into the loop, after
__builtin_ia32_movntq. -mfpmath=sse does not mean that x87 is disabled, only
that equivalent arithmetic instructions use SSE instructions. If there is no
equivalent SSE insn, x87 insn is used.

IIRC, even Intel's Instruction set reference suggests to group FP and MMX insn
together and put emms after MMX block.

Since a substantial effort would be needed to fix this questionable corner
case, and the test is violating recommended practice, I'm marking this PR as
WONTFIX.

[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2012-01-20 
11:28:26 UTC ---
> The testcase that fails is gcc.c-torture/execute/bitfld-3.c. Both with and
> without (4.6.1 release) the patch. 
> The patch I posted fixes the problem, but I don't know if it is general 
> enough.

OK, what are the values of the various parameters you have upon entering the
problematic block of code in store_bit_field_1?  Note that this code has been
working fine for years on 32-bit big-endian targets so this is unexpected.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[burnus at gcc dot gnu.org]

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

--- Comment #23 from Tobias Burnus  2012-01-20 
11:28:23 UTC ---
Created attachment 26392
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26392
Small test case for polymorphic optional dummies

(In reply to comment #22)
> Updated patch.
> This passes the full comment #13 test fixed as follows:

Truly awesome! Will you submit the patch?

 * * *

Related, but a bit separate issue: OPTIONAL CLASS dummies. See attached test
case. It seems to mostly work with the patch below, except for one ICE and one
SEGV at run time. (And - out-commented part - I'm hitting an ICE which might be
the same as PR 46356 comment 2.)

TODO: In the fixed-up test case of comment 13, copy sub_t and change "type" to
"class" - copy all calls to sub_t - and modify those to call the new function.
See what will break ...

TODO2: Call both the original sub_t and the new function with polymorphic
components of derived types.

--- trans-expr.c(revision 183328)
+++ trans-expr.c(working copy)
@@ -576,8 +576,16 @@ gfc_conv_expr_present (gfc_symbol * sym)
   gcc_assert (sym->attr.dummy);

   decl = gfc_get_symbol_decl (sym);
-  if (TREE_CODE (decl) != PARM_DECL)
+
+  if (sym->ts.type == BT_CLASS)
 {
+  decl = gfc_class_data_get (decl);
+  if (CLASS_DATA (sym)->attr.dimension
+ || CLASS_DATA (sym)->attr.codimension)
+   decl = gfc_build_addr_expr (NULL_TREE, decl);
+}
+  else if (TREE_CODE (decl) != PARM_DECL)
+{
   /* Array parameters use a temporary descriptor, we want the real
  parameter.  */
   gcc_assert (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (decl))

[Bug tree-optimization/51914] [4.7] vect-intfloat-conversion4a/b tests fail for arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-20
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2012-01-20 
11:31:18 UTC ---
Created attachment 26393
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26393
gcc47-pr51914.patch

Untested fix.

[Bug libfortran/51899] [4.7 Regression] libgfortran's chmod.c fails to build on MinGW

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-01-20 
11:32:55 UTC ---
Author: burnus
Date: Fri Jan 20 11:32:52 2012
New Revision: 183335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183335
Log:
2012-01-20  Tobias Burnus  

PR libgfortran/51899
* configure.ac: Check whether umask is available.
* intrinsics/chmod.c (chmod_func): Make compile with MinGW.
* configure: Regenerate.
* config.h.in: Regenerate.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/intrinsics/chmod.c

[Bug libfortran/51899] [4.7 Regression] libgfortran's chmod.c fails to build on MinGW

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Tobias Burnus  2012-01-20 
11:36:56 UTC ---
FIXED on the trunk (4.7).

[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #2 from Paolo Carlini  2012-01-20 
11:50:56 UTC ---
On it.

[Bug target/50887] [avr] Support ACCUMULATE_OUTGOING_ARGS

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2012-01-20 
12:31:59 UTC ---
Author: gjl
Date: Fri Jan 20 12:31:46 2012
New Revision: 183336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183336
Log:
PR target/49868
PR target/50887
* doc/extend.texi (Named Address Spaces): Split into subsections.
(AVR Named Address Spaces): New subsection.
(M32C Named Address Spaces): New subsection.
(RL78 Named Address Spaces): New subsection.
(SPU Named Address Spaces): New subsection.
(Variable Attributes): New anchor "AVR Variable Attributes".
(AVR Variable Attributes): Rewrite and avoid wording
"address space" in this context.
* doc/invoke.texi (AVR Options): Rewrite and add documentation
for -maccumulate-args, -mbranch-cost=, -mrelax, -mshort-calls.
(AVR Built-in Macros): New subsubsection therein.
* doc/md.texi (AVR constraints): Remove "C04", "R".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/md.texi

[Bug target/49868] Implement named address space to place/access data in flash memory

[gjl at gcc dot gnu.org]

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

--- Comment #12 from Georg-Johann Lay  2012-01-20 
12:31:59 UTC ---
Author: gjl
Date: Fri Jan 20 12:31:46 2012
New Revision: 183336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183336
Log:
PR target/49868
PR target/50887
* doc/extend.texi (Named Address Spaces): Split into subsections.
(AVR Named Address Spaces): New subsection.
(M32C Named Address Spaces): New subsection.
(RL78 Named Address Spaces): New subsection.
(SPU Named Address Spaces): New subsection.
(Variable Attributes): New anchor "AVR Variable Attributes".
(AVR Variable Attributes): Rewrite and avoid wording
"address space" in this context.
* doc/invoke.texi (AVR Options): Rewrite and add documentation
for -maccumulate-args, -mbranch-cost=, -mrelax, -mshort-calls.
(AVR Built-in Macros): New subsubsection therein.
* doc/md.texi (AVR constraints): Remove "C04", "R".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/md.texi

[Bug target/50887] [avr] Support ACCUMULATE_OUTGOING_ARGS

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|documentation   |
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Georg-Johann Lay  2012-01-20 
12:33:45 UTC ---
Closed with its documentation

[Bug target/49868] Implement named address space to place/access data in flash memory

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|documentation   |
 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Georg-Johann Lay  2012-01-20 
12:34:37 UTC ---
Clodes with the documentation

[Bug middle-end/45273] [4.4/4.5/4.6/4.7 Regression] The compiler depends on the host double (-fprofile-corection only)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.4.7   |4.8.0

--- Comment #7 from Richard Guenther  2012-01-20 
12:38:42 UTC ---
OTOH, nowadays all(?) host platforms we support have IEEE enough compliant
HW floating-point (well, details like signed zeros and NaNs/Infs are not
really relevant for GCC) that a hwfloat.h could provide a mapping to
a 32bit / 64bit IEEE float format?

Else the patch certainly looks good to me, but lets queue it for 4.8
(I remembered you posted patches to remove sreal.c, did you?)

[Bug target/51915] New: [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

 Bug #: 51915
   Summary: [4.7 Regression] ICE in output_move_double
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ram...@gcc.gnu.org
Target: arm-linux-gnueabi


The following testcase started ICEing probably with PR50022 change:
./xgcc -B ./ -march=armv7-a -mfloat-abi=hard -O2 rh783334.c
rh783334.c: In function ‘bar’:
rh783334.c:12:1: internal compiler error: in output_move_double, at
config/arm/arm.c:13951
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

/* { dg-do compile } */
/* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */

struct S { int s1; void *s2; };
struct T { struct S t1; unsigned long long t2; };
struct S *foo (unsigned long long);

struct S *
bar (struct S *x)
{
  return foo (((struct T *) x)->t2);
}

[Bug lto/51916] New: FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[dominiq at lps dot ens.fr]

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

 Bug #: 51916
   Summary: FAIL: gcc.dg/lto/trans-mem-3
c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link,
-flto (internal compiler error)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
  Host: *-apple-darwin*
Target: *-apple-darwin*
 Build: *-apple-darwin*


The test for gcc.dg/lto/trans-mem-3* fails on *-apple-darwin*  as

[macbook] f90/bug% gcc47 /opt/gcc/work/gcc/testsuite/gcc.dg/lto/trans-mem-3_0.c
-c -o obj_0.o -flto
[macbook] f90/bug% gcc47 /opt/gcc/work/gcc/testsuite/gcc.dg/lto/trans-mem-3_1.c
-c -o obj_1.o -flto -fgnu-tm
[macbook] f90/bug% gcc47 obj_0.o obj_1.o -flto
lto1: internal compiler error: in streamer_get_builtin_tree, at
tree-streamer-in.c:1077
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: gcc47 returned 1 exit status
collect2: error: lto-wrapper returned 1 exit status

The internal compiler error disappears if I add -fgnu-tm:

[macbook] f90/bug% gcc47 obj_0.o obj_1.o -flto -fgnu-tm
[macbook] f90/bug%

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-01-20 
13:16:42 UTC ---
Created attachment 26394
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26394
gcc47-pr51915.patch

Untested fix.

output_move_double (sometimes intentionally) modifies the operands array,
because it returns a pattern that should be emitted by the caller in some
cases.
But if that is done already when !emit, when just counting the insns, when
output_move_double is called with emit=true, we ICE.

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-20
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2012-01-20 
13:17:49 UTC ---
Ramana, if this patch looks ok to you, can you please bootstrap/regtest it? 
Thanks.

[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  2012-01-20 
13:24:53 UTC ---
Author: ramana
Date: Fri Jan 20 13:24:47 2012
New Revision: 183338

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183338
Log:

Fix PR target/51819 


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Ramana Radhakrishnan  2012-01-20 
13:26:14 UTC ---
Fixed. .

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[mark at gcc dot gnu.org]

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

--- Comment #3 from Mark Wielaard  2012-01-20 13:31:04 
UTC ---
(In reply to comment #2)
> Mark, can you please look at this if it does the right thing you want from it?

Yes, this seems to do what I was thinking of. And it works on my testcases.

It does a bit more by searching up the block supercontext and by trying to find
a partial range. I think it would be fine to look for and pick the first block
supercontext and only check the chains are equal (but haven't tried that yet).

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-01-20 
13:37:50 UTC ---
We could go just to the immediate supercontext if BLOCK_SAME_RANGE (both when
the fragment count is the same and when it is smaller in the child), but we'd
lose all the verification (we couldn't test ranges_table[something].num against
BLOCK_NUM).
So perhaps we could do that, and only if ENABLE_CHECKING do the additional
verification afterwards, in the normal code just verify that the start of the
range has > 0 num (so it isn't one ranged by labels).

[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #15 from Richard Guenther  2012-01-20 
14:16:25 UTC ---
Created attachment 26395
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26395
other candidate patch

I'm testing the following patch instead, which avoids changing access types
for all-scalar across-link propagations (we're going to create proper V_C_Es
later).  I also remove the fancy code that tries to avoid adding V_C_Es,
it looks it will cause more trouble than missed-optimizations.

That way we completely avoid needing to care for alignment at that particular
places.  Whether the aggregate copy across-link propagation is affected in
a similar way remains to be seen.

I'll see if I run into the same issue as you and investigate that.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #13 from Richard Guenther  2012-01-20 
14:18:45 UTC ---
I'll look at the IPA-SRA issue.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|powerpc64-linux |powerpc64-linux, i?86-*-*

--- Comment #14 from Richard Guenther  2012-01-20 
14:20:17 UTC ---
Same ICE on i?86-linux btw.

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-20
 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |4.6.3
Summary|bug when submitting a class |[4.6/4.7 Regression][OOP]
   |pointer to a subroutine |bug when submitting a class
   ||pointer to a subroutine
 Ever Confirmed|0   |1

--- Comment #1 from Tobias Burnus  2012-01-20 
14:27:04 UTC ---
Conformed. Works with NAG f95 and ifort. And works with GCC 4.5. (Probably
because the valid but not correctly working check was not yet implemented.)


The failing check (in interface.c's compare_parameter; cf. PR46161, Rev.
166018) is:

  /* F2003, 12.5.2.5.  */
  if (formal->ts.type == BT_CLASS
  && (CLASS_DATA (formal)->attr.class_pointer
  || CLASS_DATA (formal)->attr.allocatable))
{
...
  if (CLASS_DATA (actual)->ts.u.derived
  != CLASS_DATA (formal)->ts.u.derived)
gfc_error ("Actual argument to '%s' at %L must have the same "
   "declared type", formal->name, &actual->where);


Thus, the question is why 
  CLASS_DATA (actual)->ts.u.derived ! = CLASS_DATA (formal)->ts.u.derived
or in other words why do we have two different symbols in the symtree? We have:

(gdb) p formal->ts.u.derived->name
$4 = 0x2cf45000 "__class_m_sparsematrix_Sparsematrix_t_p"
(gdb) p actual->ts.u.derived->name
$5 = 0x2cf45000 "__class_m_sparsematrix_Sparsematrix_t_p"


What I find a bit odd is:
(gdb) p formal->ts.u.derived->module
$9 = 0x2ce25fc0 ""  ! <<< pointer to empty string
(gdb) p actual->ts.u.derived->module
$8 = 0x0  ! <<< NULL pointer

Otherwise, the two belong (unsurprisingly) to different namespaces:
(gdb) p actual->ts.u.derived->ns->proc_name->name
$13 = 0x2ce25fa8 "main"
(gdb) p formal->ts.u.derived->ns->proc_name->name
$14 = 0x2ce25fb0 "test"

Thus, having a different symbol - and hence a different pointer address - is
not too surprising.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth  2012-01-20 
14:35:52 UTC ---
(In reply to comment #4)
> On x86_64-darwin10 (Xcode 3.2.6) r183290 is OK.
> On powerpc-apple-darwin9 (Xcode 3.1.4) 183218 is OK.

This issue doesn't occur on x86_64-darwin10 with Xcode 4.2 so the problem
seems to be darwin11 specific.

[Bug c++/37798] unaligned memory access with multiple inheritance

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #7 from Jason Merrill  2012-01-20 
14:37:08 UTC ---
This seems like another example of the same underlying problem as bug 22488,
and should be fixed by the same change I proposed there.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Guenther  2012-01-20 
14:40:09 UTC ---
Testing

@@ -3891,6 +3853,8 @@ decide_one_param_reduction (struct acces
 {
   by_ref = false;
   agg_size = cur_parm_size;
+  if (DECL_MODE (parm) != BLKmode)
+return 0;
 }

   if (dump_file)

as passing a parameter by value in non-BLKmode (on the PARM_DECL) should
be good evidence to not split it down further (in this case we have
TYPE_SIZE != MODE_SIZE as well, but that's another story).

Hopefully DECL_MODE on the PARM_DECL is good enough and reflects actual
argument passing closely enough ... ?

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-01-20 
14:40:44 UTC ---
(In reply to comment #0)
> Created attachment 26390 [details]
> buggy program

Work around: Swap the USE statements in the main program.


(In reply to comment #1)
>   /* F2003, 12.5.2.5.  */
The reference is wrong, it should be F2008.

[Bug c++/45690] broken debuginfo with dwarf4?

[tromey at gcc dot gnu.org]

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

--- Comment #7 from Tom Tromey  2012-01-20 14:59:51 
UTC ---
gdb doesn't read .debug_pubtypes.
So the problem must be something else.

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #1 from Aldy Hernandez  2012-01-20 
15:29:45 UTC ---
I don't have a Darwin machine on which to test the link sequence.  Do you mind
finding out which is the fcode in question?  It is a matter of setting a gdb
breakpoint on the assert and typing "print fcode".

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

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

--- Comment #24 from Mikael Morin  2012-01-20 
15:31:58 UTC ---
(In reply to comment #23)
> Created attachment 26392 [details]
> Small test case for polymorphic optional dummies
> 
> (In reply to comment #22)
> > Updated patch.
> > This passes the full comment #13 test fixed as follows:
> 
> Truly awesome! Will you submit the patch?
> 
Yes, I plan to polish it a bit, test, and submit.

[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Guenther  2012-01-20 
15:46:40 UTC ---
(In reply to comment #15)
> Created attachment 26395 [details]
> other candidate patch
> 
> I'm testing the following patch instead, which avoids changing access types
> for all-scalar across-link propagations (we're going to create proper V_C_Es
> later).  I also remove the fancy code that tries to avoid adding V_C_Es,
> it looks it will cause more trouble than missed-optimizations.
> 
> That way we completely avoid needing to care for alignment at that particular
> places.  Whether the aggregate copy across-link propagation is affected in
> a similar way remains to be seen.
> 
> I'll see if I run into the same issue as you and investigate that.

gcc.dg/torture/pr47228.c shows that we rely on the build-ref-for-model
path in sra_modify_assign as we scalarize

struct S4
{
  unsigned f0:24;
} __attribute__((__packed__));

to unsigned int : 24, which is of different size, so we refuse to
VIEW_CONVERT the SImode register to BLKmode.  I'm not entirely sure
what's the best cause of action here, but certainly either detecting
the size-mismatch issue at analysis phase or papering over the issue
with build-ref-for-model (which might not always suceed?!).

Other FAILs this patch causes are

Running target unix/
FAIL: gcc.dg/tree-ssa/pr45144.c scan-tree-dump optimized " =
VIEW_CONVERT_EXPR\\(a\\);"

Running target unix/-m32
FAIL: gcc.dg/torture/pr45678-2.c  -Os  execution test
FAIL: gcc.dg/tree-ssa/pr45144.c scan-tree-dump optimized " =
VIEW_CONVERT_EXPR\\(a\\);"

Running target unix/
FAIL: 20_util/hash/chi2_quality.cc execution test
FAIL: 23_containers/forward_list/capacity/resize_size.cc execution test
FAIL: 23_containers/forward_list/modifiers/2.cc execution test
FAIL: 23_containers/list/operations/3.cc execution test
FAIL: 23_containers/list/operations/3_c++0x.cc execution test
FAIL: ext/pb_ds/example/basic_map.cc execution test
FAIL: ext/pb_ds/example/basic_multiset.cc execution test
FAIL: ext/pb_ds/example/basic_set.cc execution test
FAIL: ext/pb_ds/example/erase_if.cc execution test
FAIL: ext/pb_ds/example/tree_intervals.cc execution test
FAIL: ext/pb_ds/example/tree_join.cc execution test
FAIL: ext/pb_ds/example/tree_order_statistics.cc execution test
FAIL: ext/pb_ds/regression/associative_containers.cc execution test
FAIL: ext/pb_ds/regression/tree_map_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_set_rand.cc execution test

Running target unix//-m32
FAIL: 23_containers/list/operations/3_c++0x.cc execution test
FAIL: 25_algorithms/nth_element/2.cc execution test

I'm going to test the two parts of the patch separately now.

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|avr |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-20
 CC||ebotcazou at gcc dot
   ||gnu.org
   Target Milestone|--- |4.5.4
Summary|renaming of a volatile  |[4.5/4.6/4.7 regression]
   |variable generates wrong|wrong code for renaming of
   |code|packed array with address
   ||clause
 Ever Confirmed|0   |1

--- Comment #5 from Eric Botcazou  2012-01-20 
15:50:30 UTC ---
This looks more related to the address clause on the packed array though.

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org

--- Comment #6 from Eric Botcazou  2012-01-20 
15:52:34 UTC ---
Investigating.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  
2012-01-20 15:54:14 UTC ---
On x86_64-apple-darwin10, the patch in comments #22 breaks most of the tests I
have for extends_type_of (3 out of 5) and in the test suite (only
gfortran.dg/extends_type_of_2.f03 passes the two other tests
gfortran.dg/extends_type_of_(1.f03|3.f90) fails):

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

I have also another test without extends_type_of which fails:

[macbook] f90/bug% cat oop_14.f90
module realloc
  implicit none

  type :: base_type
 integer :: i =2
  contains
procedure :: assign
generic :: assignment(=) => assign   ! define generic assignment
  end type base_type

  type, extends(base_type) :: extended_type
 integer :: j =3
  end type extended_type

contains

  elemental subroutine assign (a, b)
class(base_type), intent(out) :: a
class(base_type), intent(in) :: b
a%i = b%i
  end subroutine assign

  subroutine reallocate (a)
class(base_type), dimension(:), allocatable, intent(inout) :: a
class(base_type), dimension(:), allocatable :: tmp

allocate (tmp (2 * size (a))) ! how to alloc b with same type as a ?

! This is one way how!
!select type (a)
!  type is (base_type);  allocate (base_type :: tmp (2 * size (a)))
!  type is (extended_type);  allocate (extended_type :: tmp (2 * size (a)))
!end select

call print_type ("tmp", tmp)
tmp(:size(a)) = a ! polymorphic l.h.s.
!call move_alloc (from=tmp, to=a) ! remains to be sorted out
  end subroutine reallocate

  subroutine print_type (name, a)
character(*), intent(in) :: name
class(base_type), dimension(:), intent(in) :: a
select type (a)
type is (base_type);  print *, name // " is base_type", a
type is (extended_type);  print *, name // " is extended_type", a
end select
  end subroutine print_type

end module realloc

program main
  use realloc
  implicit none
  class(base_type), dimension(:), allocatable :: a

!  allocate (a(10), source = extended_type(1,2)) ! this works
  allocate (extended_type::a(10))
  call print_type ("a", a)
  call reallocate (a)
  call print_type ("a", a)
end program main
[macbook] f90/bug% gfc oop_14.f90
[macbook] f90/bug% a.out 
 a is extended_type   2   3   2   3   2
  3   2   3   2   3   2
  3   2   3   2   3   2   3
  2   3

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-01-20 
16:09:11 UTC ---
> I don't have a Darwin machine on which to test the link sequence.  Do you mind
> finding out which is the fcode in question?  It is a matter of setting a gdb
> breakpoint on the assert and typing "print fcode".

No luck!-(I get 'No symbol "fcode" in current context.' and if not '').
The only things I have been to print stepping through 
streamer_get_builtin_tree (ib=, data_in=)
are

(gdb) s
streamer_read_uhwi (ib=0x7fff5fbfd820) at ../../work/gcc/data-streamer-in.c:93
93{
(gdb) p *ib
$4 = {data = 0x142090d84 "\037", p = 1432, len = 1621}

[Bug target/10901] non-local goto's don't work on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #26 from Dominique d'Humieres  
2012-01-20 16:24:34 UTC ---
I have done a clean bootstrap of r183305 on  powerpc-apple-darwin9 with the
patch in comment #25.
Regtesting in progress (allow for ~20 more hours), but gcc at -m32 has only 28
failures (including 16 for gcc.dg/simulate-thread/atomic-* instead of usually
12: I cannot say presently if it is due to some slow down due to the patch or
because I am using the machine while usually it is only devoted to the test
suite).

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[aldyh at redhat dot com]

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

--- Comment #3 from Aldy Hernandez  2012-01-20 
16:25:19 UTC ---
> No luck!-(I get 'No symbol "fcode" in current context.' and if not ' optimized out>').
> The only things I have been to print stepping through
> streamer_get_builtin_tree (ib=, data_in= out>)

Try building the compiler without optimization (-O0).

[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c

[lucier at math dot purdue.edu]

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

--- Comment #2 from lucier at math dot purdue.edu 2012-01-20 16:26:26 UTC ---
I found a PPC64 machine, so I'll test it.

Brad

[Bug rtl-optimization/51856] [4.7 Regression] ICE in reload_cse_simplify_operands

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  2012-01-20 
16:29:11 UTC ---
Author: krebbel
Date: Fri Jan 20 16:29:01 2012
New Revision: 183341

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183341
Log:
2012-01-20  Andreas Krebbel  

PR rtl-optimization/51856
* reload.c (find_reloads_subreg_address): Set the address_reloaded
flag to reloaded.

2012-01-20  Andreas Krebbel  

* gcc.c-torture/compile/pr51856.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr51856.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2012-01-20 
16:49:52 UTC ---
Created attachment 26396
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26396
l.ii

Note that the BLKmode MEM_REF with non-BLKmode base expansion can be triggered
also without SRA, e.g. this (distilled from locale-inst.cc) reaches the code
on i?86-linux with -m32 -O2 -fno-ipa-sra -fno-tree-sra.

[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2012-01-20 17:21:27 UTC ---
Author: paolo
Date: Fri Jan 20 17:21:19 2012
New Revision: 183345

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183345
Log:
/cp
2012-01-20  Paolo Carlini  

PR c++/51402
* pt.c (lookup_template_class_1): Check context returned by
tsubst for error_mark_node.

/testsuite
2012-01-20  Paolo Carlini  

PR c++/51402
* g++.dg/template/crash110.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/crash110.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.6.3   |4.7.0

--- Comment #4 from Paolo Carlini  2012-01-20 
17:23:04 UTC ---
Fixed for 4.7.0.

[Bug c++/51917] New: [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51917
   Summary: [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: sparc-sun-solaris*, mips-sgi-irix6.5
Target: sparc-sun-solaris*, mips-sgi-irix6.5
 Build: sparc-sun-solaris*, mips-sgi-irix6.5


Between 20120113 and 20120117, the g++.old-deja/g++.abi/vmihint.C test started
to FAIL on Solaris/SPARC and IRIX 6.5:

FAIL: g++.old-deja/g++.abi/vmihint.C -std=c++98 execution test
FAIL: g++.old-deja/g++.abi/vmihint.C -std=c++11 execution test

The test exits with 1.

This is a regression from gcc 4.6.

  Rainer

[Bug c++/51917] [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|sparc-sun-solaris*, |sparc-sun-solaris*,
   |mips-sgi-irix6.5|mips*-*-*
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2012-01-20
   Host|sparc-sun-solaris*, |sparc-sun-solaris*,
   |mips-sgi-irix6.5|mips*-*-*
 Ever Confirmed|0   |1
   Target Milestone|--- |4.7.0
  Build|sparc-sun-solaris*, |sparc-sun-solaris*,
   |mips-sgi-irix6.5|mips*-*-*

--- Comment #1 from Andrew Pinski  2012-01-20 
17:37:44 UTC ---
Fails on MIPS64-linux-gnu also.

And reported to fail on other targets too:

 +FAIL: g++.old-deja/g++.abi/vmihint.C -std=c++98 execution test
 on mips64-linux-gnu
 pinskia: it fails on s390-linux and ppc-linux too (32-bit in both
cases, 64-bit is fine)

[Bug c++/51918] New: [4.7 regression] g++.old-deja/g++.pt/ptrmem6.C FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51918
   Summary: [4.7 regression] g++.old-deja/g++.pt/ptrmem6.C FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


Since at least 20111216 (the port didn't bootstrap for almost 3 months before
that),
the g++.old-deja/g++.pt/ptrmem6.C test FAILs on IRIX 6.5:

FAIL: g++.old-deja/g++.pt/ptrmem6.C -std=c++11  (test for errors, line 28)

This happens for both N32 and N64 ABIs, but only for C++11, -std=c++98 is fine.

This is a regression from 4.6.

  Rainer

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-01-20 
17:44:50 UTC ---
The patch breaks g++.dg/guality/redeclaration1.C on i?86 -m32 -Os -g.
The supercontext range has 3 elements, the same range child range has 2
elements, same as the first and last of the supercontext.
So, either we'd need to stop optimizing if thiscount != supercount, or tweak
somehow reorder_blocks_1 so that it clears BLOCK_SAME_RANGE even when it didn't
show up adjacent to supercontext's NOTE_INSN_BLOCK_BEGIN resp. END.

[Bug testsuite/51919] New: g++.dg/pch/mangle1.* test FAILs without LTO

[ro at gcc dot gnu.org]

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

 Bug #: 51919
   Summary: g++.dg/pch/mangle1.* test FAILs without LTO
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
  Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
 Build: alpha-dec-osf5.1b


The new g++.dg/pch/mangle1.* test FAILs on Tru64 UNIX, which has no LTO
support:

FAIL: ./mangle1.H  -g (test for excess errors)
FAIL: g++.dg/pch/mangle1.C -g
FAIL: g++.dg/pch/mangle1.C -g assembly comparison
FAIL: ./mangle1.H  -O2 -g (test for excess errors)
FAIL: g++.dg/pch/mangle1.C -O2 -g
FAIL: g++.dg/pch/mangle1.C -O2 -g assembly comparison
FAIL: ./mangle1.H  -O2 (test for excess errors)
FAIL: g++.dg/pch/mangle1.C -O2
FAIL: g++.dg/pch/mangle1.C -O2 assembly comparison

Compiling mangle1.H gives

FAIL: ./mangle1.H  -g (test for excess errors)
Excess errors:
cc1plus: error: LTO support has not been enabled in this configuration

This one can be avoided with dg-require-effective-target lto.

The next two failures

pch file 'mangle1.H.gch' missing
FAIL: g++.dg/pch/mangle1.C -g
assembly file 'mangle1.s' missing

can not, unfortunately.  It seems that dg-pch.exp doesn't check for dg- 
directives in mangle1.C.

FAIL: g++.dg/pch/mangle1.C -g assembly comparison

[Bug target/51920] New: 64-bit gcc.target/sparc/vec-init-1-vis1.c FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51920
   Summary: 64-bit gcc.target/sparc/vec-init-1-vis1.c FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: da...@davemloft.net, ebotca...@gcc.gnu.org
  Host: sparc-sun-solaris2*
Target: sparc-sun-solaris2*
 Build: sparc-sun-solaris2*


Between 20120103 and 20120113, the 64-bit 64-bit
gcc.target/sparc/vec-init1-vis1.c
test started to FAIL:

FAIL: gcc.target/sparc/vec-init-1-vis1.c (test for excess errors)
WARNING: gcc.target/sparc/vec-init-1-vis1.c compilation failed to produce
executable

FAIL: gcc.target/sparc/vec-init-1-vis1.c (test for excess errors)
Excess errors:
/usr/bin/as: "/var/tmp//ccA.aOvn.s", line 24: error: invalid (misaligned)
register

On line 24, there is

fpmerge %f9, %f9, %f9

Using gas instead, I get

Excess errors:
/var/tmp//cc_NaqYA.s:24: Error: Illegal operands

  Rainer

[Bug target/51921] New: [4.7 regression] EH unwinding support is broken on Solaris 11

[ro at gcc dot gnu.org]

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

 Bug #: 51921
   Summary: [4.7 regression] EH unwinding support is broken on
Solaris 11
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11


The recent changes to libgcc/config/sparc/sol2-unwind.h have completely broken
Solaris 11 support, leading to many ada and java testsuite failues.  This is a
regression from 4.6.  There's still no real justification for reverting to the
old 4.5 code.

  Rainer

[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |

[Bug c++/51922] New: g++.dg/ext/attrib42.C FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51922
   Summary: g++.dg/ext/attrib42.C FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
  Host: i386-pc-solaris2.1[01], i686-unknown-linux-gnu
Target: i386-pc-solaris2.1[01], i686-unknown-linux-gnu
 Build: i386-pc-solaris2.1[01], i686-unknown-linux-gnu


The new g++.dg/ext/attrib42.C FAILs on Solaris 10 and 11/x86 and in a 32-bit
Linux/x86 compiler with -m64:

FAIL: g++.dg/ext/attrib42.C -std=c++98  (test for errors, line 11)
FAIL: g++.dg/ext/attrib42.C -std=c++98 (test for excess errors)
FAIL: g++.dg/ext/attrib42.C -std=c++11  (test for errors, line 11)
FAIL: g++.dg/ext/attrib42.C -std=c++11 (test for excess errors)

FAIL: g++.dg/ext/attrib42.C -std=c++98  (test for errors, line 11)
FAIL: g++.dg/ext/attrib42.C -std=c++98 (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/ext/attrib42.C:5:10: warning:
'fastcall' attribute ignored [-Wattributes]

  Rainer

[Bug c++/51923] New: cxa_atexit test changed outcome with gld 2.22

[ro at gcc dot gnu.org]

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

 Bug #: 51923
   Summary: cxa_atexit test changed outcome with gld 2.22
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: i386-pc-solaris2*
Target: i386-pc-solaris2*
 Build: i386-pc-solaris2*


When I switched from gld 2.21.1 to 2.22 on Solaris/x86, I suddenly got a couple
of new testsuite failures:

FAIL: g++.dg/init/cleanup3.C scan-assembler-not _tcf
FAIL: g++.dg/init/cleanup3.C scan-assembler-not _tcf
FAIL: g++.old-deja/g++.other/init5.C -std=c++98 execution test
FAIL: g++.old-deja/g++.other/init5.C -std=c++11 execution test

The first test was UNSUPPORTED with gld 2.21.1, and now FAILs because Solaris
libc doesn't have __cxa_atexit (yet).

The second test was

PASS: g++.old-deja/g++.other/init5.C (test for excess errors)
XFAIL: g++.old-deja/g++.other/init5.C execution test

It turns out that the dg-require-effective-target cxa_atexit test in
target-supports.exp (check_cxa_atexit_available) suddenly passes when
gld 2.22 is in use, while it failed with gld 2.21.1.  It seems that almost all
tests guarded with cxa_atexit now pass, with the two exceptions above.

  Rainer

[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |tromey at redhat dot com
   |gnu.org |

--- Comment #8 from Tom Tromey  2012-01-20 18:39:27 
UTC ---
Testing a patch.

[Bug debug/45682] missing namespace parent die when using -gdwarf-4

[ccoutant at gcc dot gnu.org]

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

--- Comment #4 from Cary Coutant  2012-01-20 
18:57:49 UTC ---
Author: ccoutant
Date: Fri Jan 20 18:57:44 2012
New Revision: 183348

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183348
Log:
2012-01-19   Cary Coutant  
 Dodji Seketeli  

gcc/

PR debug/45682
* dwarf2out.c (copy_declaration_context): Return ref to parent
of declaration DIE, if necessary.
(remove_child_or_replace_with_skeleton): Add new parameter; update
caller.  Place skeleton DIE under parent DIE of original declaration.
Move call to copy_declaration_context to here ...
(break_out_comdat_types): ... from here.

gcc/testsuite/

PR debug/45682
* g++.dg/debug/dwarf2/nested-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug target/51920] 64-bit gcc.target/sparc/vec-init-1-vis1.c FAILs

[davem at gcc dot gnu.org]

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

davem at gcc dot gnu.org changed:

   What|Removed |Added

 CC||davem at gcc dot gnu.org

--- Comment #1 from davem at gcc dot gnu.org 2012-01-20 18:59:11 UTC ---
Strange, I would expect a compiler error rather then it emitting an invalid odd
register.

The output operand of all insns generating 'fpmerge' only accept the proper 'e'
constraint.

[Bug debug/45682] missing namespace parent die when using -gdwarf-4

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
 AssignedTo|dodji at gcc dot gnu.org|ccoutant at gcc dot gnu.org

--- Comment #5 from Cary Coutant  2012-01-20 
19:02:26 UTC ---
Fixed for GCC 4.7.

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2012-01-20 
19:15:08 UTC ---
> Try building the compiler without optimization (-O0).

I have never done that!-(I guess I have to pass something like CFLAGS and
CXXFLAGS in configure or make). What is the official way to do it?

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-20
   Target Milestone|--- |4.6.3
Summary|[4.7 regression] EH |[4.6/4.7 regression] EH
   |unwinding support is broken |unwinding support is broken
   |on Solaris 11   |
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2012-01-20 
19:15:14 UTC ---
With this line of reasoning, there was no real justification for rewriting it
from scratch either...  This code is used in Ada (I don't count Java here, as
nobody uses GCJ on SPARC/Solaris) and the emphasis in Ada is robustness; we
cannot afford introducing gratuitous regressions (and I certainly don't want to
maintain a separate code for AdaCore's compiler) so we need to find a modus
vivendi.

[Bug middle-end/45273] [4.4/4.5/4.6/4.7 Regression] The compiler depends on the host double (-fprofile-corection only)

[stevenb.gcc at gmail dot com]

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

--- Comment #8 from stevenb.gcc at gmail dot com  
2012-01-20 19:17:53 UTC ---
Is there already a meta bug for patches queued for 4.8?

[Bug c++/51885] g++ compiler options -O2 and -O3 modifies program results

[laurentlouis.maurin at wanadoo dot fr]

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

--- Comment #4 from Laurent MAURIN  
2012-01-20 19:18:13 UTC ---
i am quite sure there is something strange : reinterpret_cast is used to cast a
float pointer to a uint32_t pointer

these two types have the same size (4 bytes)

therefore, the swap function (following the reinterpret_cast) should work
properly ...

maybe the -O2 and -O3 compiler optimisation flags have an influence on the
binary code generated for the swap function in this example

[Bug c++/51885] g++ compiler options -O2 and -O3 modifies program results

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-01-20 
19:31:48 UTC ---
(In reply to comment #4)
> i am quite sure there is something strange : reinterpret_cast is used to cast 
> a
> float pointer to a uint32_t pointer
> 
> these two types have the same size (4 bytes)
> 
> therefore, the swap function (following the reinterpret_cast) should work
> properly ...

No, the C++ standard says your code has undefined behaviour.

Please read the section "Casting does not work as expected when optimization is
turned on" at http://gcc.gnu.org/bugs/#nonbugs_c and the article it links to,
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-01-20 
19:39:53 UTC ---
Author: jakub
Date: Fri Jan 20 19:39:48 2012
New Revision: 183349

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183349
Log:
PR target/51915
* config/arm/arm.c (arm_count_output_move_double_insns): Call
output_move_double on a copy of operands array.

* gcc.target/arm/pr51915.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr51915.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51922] g++.dg/ext/attrib42.C FAILs

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2012-01-20 
20:03:19 UTC ---
Author: jason
Date: Fri Jan 20 20:03:11 2012
New Revision: 183351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183351
Log:
PR c++/51922
* g++.dg/ext/attrib42.C: Require ilp32.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/attrib42.C

[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  2012-01-20 
20:04:39 UTC ---
Patch posted to http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01025.html

[Bug c++/51922] g++.dg/ext/attrib42.C FAILs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-01-20
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jason Merrill  2012-01-20 
20:03:57 UTC ---
Does that fix the problem?

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[aldyh at redhat dot com]

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

--- Comment #5 from Aldy Hernandez  2012-01-20 
20:03:09 UTC ---
> I have never done that!-(I guess I have to pass something like CFLAGS and
> CXXFLAGS in configure or make). What is the official way to do it?

 From the Debugging GCC wiki (http://gcc.gnu.org/wiki/DebuggingGCC):

To build a debuggable compiler, configure the compiler normally and then

make STAGE1_CFLAGS="-g -O0" all-stage1

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-01-20 
20:03:50 UTC ---
Fixed.

[Bug target/51659] [4.7 regression] ICE in function output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #5 from Jakub Jelinek  2012-01-20 
20:08:39 UTC ---
Dup of PR51915.

*** This bug has been marked as a duplicate of bug 51915 ***

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||carrot at google dot com

--- Comment #5 from Jakub Jelinek  2012-01-20 
20:08:39 UTC ---
*** Bug 51659 has been marked as a duplicate of this bug. ***

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of volatile packed array with address clause

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/51918] [4.7 regression] g++.old-deja/g++.pt/ptrmem6.C FAILs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  2012-01-20 
20:06:46 UTC ---
Are you sure this is a regression?  We didn't run the testsuite in C++0x mode
in 4.6.

[Bug rtl-optimization/51924] New: [4.7 Regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[zsojka at seznam dot cz]

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

 Bug #: 51924
   Summary: [4.7 Regression] wrong code with -O -free
-fno-rename-registers -ftree-vectorize -funroll-loops
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 26397
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26397
reduced testcase

Output:
$ gcc -O -free -fno-rename-registers -ftree-vectorize -funroll-loops testcase.c
$ ./a.out
Aborted


In the output assembly when comparing output with -free and -fno-ree, this
often happens:
*** bn_sub_words:
*** 152,159 
mov QWORD PTR [rdi+rcx], r10
cmp r9, r8
setbr10b
cmp r9, r8
!   cmovne  rax, r10
add rcx, 8
cmp rcx, r11
jne .L5
--- 156,164 
mov QWORD PTR [rdi+rcx], r10
cmp r9, r8
setbr10b
+   movzx   r10d, r10b
cmp r9, r8
!   cmovne  eax, r10d
add rcx, 8
cmp rcx, r11
jne .L5

With -fno-ree (bottom), the value is extended as r10b -> r10d -> eax (-> rax
before ret)
With -free (top), the value is extended r10d -> rax (where only r10b is valid -
it is missing the r10b->r10d step)

Tested revisions:
r183324 - fail
4.6 - doesn't know -free, but -free is included in -O2

[Bug rtl-optimization/51924] [4.7 Regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2012-01-20 21:00:21 
UTC ---
> With -free (top), the value is extended r10d -> rax (where only r10b is valid 
> -
it is missing the r10b->r10d step)

The value is just moved from r10, not extended from r10d, but the effect is the
same...

[Bug rtl-optimization/51924] [4.7 Regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
   Severity|normal  |major

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  2012-01-20 
21:51:12 UTC ---
It's triggered by Joseph Myers' "Table-based default_options_optimization"
change in r165823:
http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01009.html
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01849.html

Lots of targets were updated there, but not m68k.  I'll investigate tomorrow.

There were other build problems that prevented me from finding this sooner. 
First it appears that the jar script that gcc provides if there's no fastjar or
gjar in $PATH is broken: in my native m68k environment it produces bogus zip
files that cause null pointer exceptions way later in the libjava build.  Fixed
by building fastjar.  Has anyone else seen this issue?

When I found the above rev. I wanted to check current trunk with a cross, and
then it turns out that 4.7 has broken cross builds of libjava, at least for
m68k; libtool-driven compilation attempts in ../native/fdlibm/ fail with some
libtool message about not being configured to build any library, whatever that
means.  So now I'm bisecting that mess as well.