[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-06-30 
07:01:01 UTC ---
More complete testcase, which should be adjusted to do runtime checking of the
variable content based on what we decide, and add whatever options will be
needed to disable the errors when compiling it.

block data
  common /a/ i(5,5)
  data i /4, 23 * 5, 6/
  data i(:,2) /1, 3 * 2, 3/
  common /b/ j(5,5)
  data j(2,:) /1, 3 * 2, 3/
  data j /4, 23 * 5, 6/
  common /c/ k(5,5)
  data k(:,2) /1, 3 * 2, 3/
  data k /4, 23 * 5, 6/
  common /d/ l(5,5)
  data l /4, 23 * 5, 6/
  data l(2,:) /1, 3 * 2, 3/
end block data

[Bug c++/49587] New: Code generation error with dynamic libraries.

[jarrydb at cse dot unsw.edu.au]

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

   Summary: Code generation error with dynamic libraries.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jarr...@cse.unsw.edu.au


I have a rather large piece of code (about 20,000 lines) which doesn't appear
to be compiled correctly. I can't reproduce the error, but I have found the
revision that breaks it, and I can describe roughly what the error is.

The last revision that works is 175340, it is broken in 175341.

Initially the bug surfaced as the instruction pointer trying to execute address
0x0. After further digging (with gdb, running instruction by instruction) I
discovered that at a function call, which was in a dynamic library, upon trying
to resolve the address of the function, it found that the function was at
address zero. It got to the particular function call, went through the dynamic
library lookup table, then it dies.

[Bug tree-optimization/38752] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4817

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-06-30 
08:44:23 UTC ---
Author: rguenth
Date: Thu Jun 30 08:44:18 2011
New Revision: 175684

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175684
Log:
2011-06-30  Richard Guenther  

PR tree-optimization/38752
* gcc.c-torture/compile/pr38752.c: New testcase.

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

[Bug tree-optimization/38752] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4817

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-06-30 
08:49:37 UTC ---
Author: rguenth
Date: Thu Jun 30 08:49:30 2011
New Revision: 175685

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175685
Log:
2011-06-30  Richard Guenther  

PR tree-optimization/38752
* gcc.c-torture/compile/pr38752.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr38752.c
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/38752] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4817

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-06-30 
08:51:27 UTC ---
Author: rguenth
Date: Thu Jun 30 08:51:23 2011
New Revision: 175686

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175686
Log:
2011-06-30  Richard Guenther  

PR tree-optimization/38752
* gcc.c-torture/compile/pr38752.c: New testcase.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr38752.c
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug fortran/49588] New: DATA statement with vector sections rejected (ICE: TODO)

[burnus at gcc dot gnu.org]

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

   Summary: DATA statement with vector sections rejected (ICE:
TODO)
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Depends on: 49540


Follow up to PR 49540:

The following program never worked in gfortran, but it is valid. NAG and ifort
print:

 1 2 1 3 1 2

while gfortran just has:

END BLOCK DATA
 1
 Internal Error at (1):
 TODO: Vector sections in data statements


BLOCK DATA
  integer :: A(6)
  DATA A(::2)/3*1/
  DATA A([2,6])/2*2/
  DATA A([4])/3/
  COMMON /com/A
END BLOCK DATA

PROGRAM TEST
  integer :: A(6)
  COMMON /com/A
  print *, A
END PROGRAM TEST

[Bug tree-optimization/38752] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4817

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2011-06-30 
08:56:04 UTC ---
Author: rguenth
Date: Thu Jun 30 08:56:02 2011
New Revision: 175687

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175687
Log:
2011-06-30  Richard Guenther  

PR tree-optimization/38752
* gcc.c-torture/compile/pr38752.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr38752.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/38752] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4817

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2011-06-30 
09:00:28 UTC ---
Oops.  Fixed.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  2011-06-30 
09:01:00 UTC ---
> After tuplification, DOM records the type of the LHS of assignment statements
> as the type of the expression.  And then it tests the compatibility of these
> types.

Maybe DOM could use the type of the RHS instead in the GIMPLE_SINGLE_RHS case.

On the 4.4 branch, the code generated for the testcase at -O2 is pessimized:

--- old//20030709-2.s   2011-06-30 10:41:30.0 +0200
+++ new/20030709-2.s2011-06-29 12:01:55.0 +0200
@@ -8,7 +8,8 @@
movl%esp, %ebp
movl8(%ebp), %eax
popl%ebp
-   cmpl$1, (%eax)
+   movl(%eax), %eax
+   cmpl$1, %eax
sbbl%eax, %eax
ret
.size   get_alias_set, .-get_alias_set

but it isn't on the other branches.  But DOM is hindered on all branches.

[Bug c++/49589] New: [C++0x] Internal compile error at decltype

[jarrydb at cse dot unsw.edu.au]

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

   Summary: [C++0x] Internal compile error at decltype
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jarr...@cse.unsw.edu.au
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


Created attachment 24643
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24643
ICE with decltype

The attached code causes the compiler to exit with a segmentation fault at a
use of decltype.

g++ --std=gnu++0x decltype_error_2.ii
decltype_error_2.cpp:45:31: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

output of gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jarrydb/current/soft/install-latest/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jarrydb/current/soft/src/gcc-svn/configure
--prefix=/home/jarrydb/current/soft/install-latest --disable-multilib
--enable-languages=c,c++,go
Thread model: posix
gcc version 4.7.0 20110630 (experimental) (GCC)

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  
2011-06-30 09:54:49 UTC ---
On Thu, 30 Jun 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49572
> 
> Eric Botcazou  changed:
> 
>What|Removed |Added
> 
>  CC||rguenth at gcc dot gnu.org
> 
> --- Comment #8 from Eric Botcazou  2011-06-30 
> 09:01:00 UTC ---
> > After tuplification, DOM records the type of the LHS of assignment 
> > statements
> > as the type of the expression.  And then it tests the compatibility of these
> > types.
> 
> Maybe DOM could use the type of the RHS instead in the GIMPLE_SINGLE_RHS case.

For loads yes.

[Bug c++/49587] Code generation error with dynamic libraries.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.30 09:58:10
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-06-30 
09:58:10 UTC ---
We need a testcase and more information like used compile flags and compiler
version.

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[ro at gcc dot gnu.org]

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

--- Comment #26 from Rainer Orth  2011-06-30 10:02:48 
UTC ---
Author: ro
Date: Thu Jun 30 10:02:45 2011
New Revision: 175689

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175689
Log:
2011-06-28  Dominique d'Humieres  
Iain Sandoe  

PR libobjc/36610
* objc.dg/torture/forward-1.m: Remove dg-xfail-run-if.
Only skip on 64-bit *-*-darwin8* && !objc2.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/objc.dg/torture/forward-1.m

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  2011-06-30 10:04:54 UTC 
---
Author: ro
Date: Thu Jun 30 10:04:52 2011
New Revision: 175690

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175690
Log:
PR ada/49511
* ada/acats/run_acats (which): Use last field of type -p output.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/ada/acats/run_acats

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Guenther  2011-06-30 
10:05:34 UTC ---
There seem to be two NULL fixincludes, one for openBSD and one for AIX, both
look suspicious (though I'd have to lookup the exact working of
fixincludes/inclhack.def):

/*
 * Fix OpenBSD's NULL definition.
 */
fix = {
  hackname  = openbsd_null_definition;
  mach  = "*-*-openbsd*";
  files = locale.h, stddef.h, stdio.h, string.h,
  time.h, unistd.h, wchar.h, sys/param.h;
  select= "__GNUG__";
  c_fix = format;
  c_fix_arg = "#ifndef NULL\n"
  "#ifdef __cplusplus\n"
  "#ifdef __GNUG__\n"
  "#define NULL\t__null\n"
  "#else\t /* ! __GNUG__  */\n"
  "#define NULL\t0L\n"
  "#endif\t /* __GNUG__  */\n"
  "#else\t /* ! __cplusplus  */\n"
  "#define NULL\t((void *)0)\n"
  "#endif\t /* __cplusplus  */\n"
  "#endif\t /* !NULL  */";

  c_fix_arg = "^#ifndef[ \t]*NULL\n"
  "^#ifdef[ \t]*__GNUG__\n"
  "^#define[ \t]*NULL[ \t]*__null\n"
  "^#else\n"
  "^#define[ \t]*NULL[ \t]*0L\n"
  "^#endif\n"
  "^#endif";
  test_text =
"#ifndef NULL\n"
"#ifdef  __GNUG__\n"
"#define NULL__null\n"
"#else\n"
"#define NULL0L\n"
"#endif\n"
"#endif\n";
};

and

/*
 *  AIX and Interix headers define NULL to be cast to a void pointer,
 *  which is illegal in ANSI C++.
 */
fix = {
hackname  = void_null;
files = curses.h;
files = dbm.h;
files = locale.h;
files = stdio.h;
files = stdlib.h;
files = string.h;
files = time.h;
files = unistd.h;
files = sys/dir.h;
files = sys/param.h;
files = sys/types.h;
/* avoid changing C++ friendly NULL */
bypass= __cplusplus;
select= "^#[ \t]*define[ \t]+NULL[ \t]+\\(\\(void[ \t]*\\*\\)0\\)";
c_fix = format;
c_fix_arg = "#define NULL 0";
test_text = "# define\tNULL \t((void *)0)  /* typed NULL */";
};

maybe they work against each other somehow.

Can you attach the un-fixed string.h?

[Bug bootstrap/49584] [4.4 regression] bootstrap failure on m68k-linux: segfault compiling _muldi3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.7
Summary|[4.4.7 regression]  |[4.4 regression] bootstrap
   |bootstrap failure on|failure on m68k-linux:
   |m68k-linux: segfault|segfault compiling _muldi3
   |compiling _muldi3   |

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  2011-06-30 10:06:46 UTC 
---
Author: ro
Date: Thu Jun 30 10:06:44 2011
New Revision: 175692

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175692
Log:
PR ada/49511
* ada/acats/run_acats (which): Use last field of type -p output.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ada/acats/run_acats

[Bug target/49583] Reloading stack operands in the wrong order, so needs to insert fxch

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-06-30 
10:07:40 UTC ---
Reload doesn't really know how to deal with the register stack.

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  2011-06-30 10:05:46 UTC 
---
Author: ro
Date: Thu Jun 30 10:05:43 2011
New Revision: 175691

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175691
Log:
PR ada/49511
* ada/acats/run_acats (which): Use last field of type -p output.

Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ada/acats/run_acats

[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg02209.htm
   ||l
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #8 from Rainer Orth  2011-06-30 10:11:49 UTC 
---
Fixed for 4.5.4, 4.6.2, 4.7.0.

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[jsg at openbsd dot org]

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

--- Comment #14 from Jonathan Gray  2011-06-30 10:13:20 
UTC ---
Created attachment 24644
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24644
unfixed string.h

[Bug c++/49587] Code generation error with dynamic libraries.

[jarrydb at cse dot unsw.edu.au]

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

--- Comment #2 from Jarryd Beck  2011-06-30 
10:16:58 UTC ---
I wish that I could give you a test case. I can't reproduce it on any small
piece of code. The only code that I can get it to break on is my project which
has about 20,000 lines of code. It has nearly 100 files and uses boost spirit.
It compiles into a library and several executables.

The compiler version I already stated. It's gcc svn, the first broken revision
is 175341 (maybe that wasn't clear).

The flags used for compiling are simply -fPIC for the library and nothing extra
for the executables.

Another thing to note is that I moved the function call in which the error
occurs to later in my code, and a different function bombed in exactly the same
way.

How would you like me to proceed?

[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-06-30 
10:25:43 UTC ---
Author: jakub
Date: Thu Jun 30 10:25:40 2011
New Revision: 175693

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175693
Log:
PR fortran/49540
* gfortran.h (gfc_constructor): Add repeat field.
* trans-array.c (gfc_conv_array_initializer): Handle repeat > 1.
* array.c (current_expand): Add repeat field.
(expand_constructor): Copy repeat.
* constructor.c (node_free, node_copy, gfc_constructor_get,
gfc_constructor_lookup): Handle repeat field.
(gfc_constructor_lookup_next, gfc_constructor_remove): New functions.
* data.h (gfc_assign_data_value): Add mpz_t * argument.
(gfc_assign_data_value_range): Removed.
* constructor.h (gfc_constructor_advance): Removed.
(gfc_constructor_lookup_next, gfc_constructor_remove): New prototypes.
* data.c (gfc_assign_data_value): Add REPEAT argument, handle it and
also handle overwriting a range with a single entry.
(gfc_assign_data_value_range): Removed.
* resolve.c (check_data_variable): Adjust gfc_assign_data_value
call.  Use gfc_assign_data_value instead of
gfc_assign_data_value_expr.

* gfortran.dg/pr49540-1.f90: New test.
* gfortran.dg/pr49540-2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr49540-1.f90
trunk/gcc/testsuite/gfortran.dg/pr49540-2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/constructor.c
trunk/gcc/fortran/constructor.h
trunk/gcc/fortran/data.c
trunk/gcc/fortran/data.h
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/49364] [4.7 regressions] Empty .debug_abbrev sections confuse SGI nm

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-06-30 
10:26:38 UTC ---
Author: jakub
Date: Thu Jun 30 10:26:32 2011
New Revision: 175694

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175694
Log:
PR debug/49364
* dwarf2out.c (output_abbrev_section): Don't return early
if abbrev_die_table_in_use is 1.
(dwarf2out_finish): Instead don't call output_abbrev_section
nor emit abbrev_section_label in that case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  2011-06-30 
10:30:28 UTC ---
> For loads yes.

OK, what's the right predicate to use on the RHS here?  !is_gimple_val?

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  
2011-06-30 10:42:21 UTC ---
On Thu, 30 Jun 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49572
> 
> --- Comment #10 from Eric Botcazou  2011-06-30 
> 10:30:28 UTC ---
> > For loads yes.
> 
> OK, what's the right predicate to use on the RHS here?  !is_gimple_val?

Do we ever end up with stores in that function?  I doubt so given
that expr->ops.single.rhs is set to RHS1.  ISTR DOM enters a load
for a store operation.  So just unconditionally use the type
of rhs1.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  2011-06-30 
11:00:09 UTC ---
> Do we ever end up with stores in that function?  I doubt so given
> that expr->ops.single.rhs is set to RHS1.  ISTR DOM enters a load
> for a store operation.  So just unconditionally use the type of rhs1.

Indeed, stores are turned into loads.  OK, I'm going to test the change.

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Guenther  2011-06-30 
11:13:13 UTC ---
Can you try deleting the AIX/Interix fix?  It seems to be broken (and your
original string.h doesn't seem to be prepared for C++ inclusion).

[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-06-30 
11:43:24 UTC ---
The order apparently changed with
http://gcc.gnu.org/viewcvs?view=revision&revision=114406
which doesn't change the order actually, but only wouldn't overwrite anything.
So, even back then the DATA stmts used to be traversed in wrong order.

[Bug c++/49587] Code generation error with dynamic libraries.

[jarrydb at cse dot unsw.edu.au]

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

--- Comment #3 from Jarryd Beck  2011-06-30 
11:52:52 UTC ---
Sorry I better get that function in the dynamic loading correct. It calls the
actual function which goes to _dl_runtime_resolve which calls _dl_fixup, then
it bombs at the end of _dl_runtime_resolve.

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[jsg at openbsd dot org]

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

--- Comment #16 from Jonathan Gray  2011-06-30 12:18:43 
UTC ---
Yes, it appears to be the AIX/Interix part which is causing the problem.  I
removed just the OpenBSD part and it still happened and then further removed
the AIX/Interix one and it was then fine.
I can now build 4.6.1 with lto/plugin (with some additional patches I'll submit
soon) and run the dragonegg LLVM plugin.

Can you expand on why you think the header isn't suitable for c++ inclusion?

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[thenlich at users dot sourceforge.net]

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

Thomas Henlich  changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #7 from Thomas Henlich  
2011-06-30 12:26:30 UTC ---
J3 subgroup has answered this:

http://j3-fortran.org/doc/meeting/195/11-201r1.txt

[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-06-30 
12:30:51 UTC ---
Created attachment 24645
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24645
gcc47-pr49586.patch

Untested fix for the order.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.30 12:33:12
 Ever Confirmed|0   |1

--- Comment #8 from Tobias Burnus  2011-06-30 
12:33:12 UTC ---
(In reply to comment #7)
> J3 subgroup has answered this:
> http://j3-fortran.org/doc/meeting/195/11-201r1.txt

Thanks. In a nutshell: It is invalid - the standard does not allow to combine
partial default-initialization with partial DATA initialization.

It is not a constraint, hence, the compiler is not required to diagnose it, but
I think it should - rather than ICEing ...

[Bug fortran/49590] New: ENTRY: Reject combining USE associated variable with RESULT variable

[burnus at gcc dot gnu.org]

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

   Summary: ENTRY: Reject combining USE associated variable with
RESULT variable
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


>From http://j3-fortran.org/doc/meeting/195/11-196r1.txt:

The following is invalid:

MODULE m
  REAL x
CONTAINS
  FUNCTION f()
f = 1
x = 2  ! <<< Use associated?
RETURN
  ENTRY e() RESULT(x)
x = 3  !  Result variable?
  END FUNCTION
END MODULE

Append new statement to 12.6.2.6p9 [310:23]
  "A name that appears as a  in an ENTRY statement
   shall not appear in the expression of a statement function that
   precedes the first RESULT clause with that name unless the name is
   also a dummy argument of that statement function."

[Bug fortran/49591] New: [OOP] Multiple identical specific procedures in type-bound generic not detected

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] Multiple identical specific procedures in
type-bound generic not detected
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


The first code ("module M1") is accepted without any error.
Expected: Diagnose that the generic operator (+) has two ambiguous specific
bindings, one to myadd_t the other to myadd_x.

Ditto for the second code ("M2"), which is also currently accepted.



  module M1
type T
  integer x
contains
  procedure :: MyAdd_t => myadd
  generic :: operator(+) => myAdd_t
end type T
type X
  real q
contains
  procedure, pass(b) :: MyAdd_x => myadd
  generic :: operator(+) => myAdd_x
end type X
  contains
integer function MyAdd ( A, B )
  class(t), intent(in) :: A
  class(x), intent(in) :: B
  myadd = a%x + b%q
end function MyAdd
  end module

  module M2
interface operator(+)
  procedure MyAdd
end interface
type T
  integer x
contains
  procedure :: MyAdd_t => myadd
  generic :: operator(+) => myAdd_t
end type T
  contains
integer function MyAdd ( A, B )
  class(t), intent(in) :: A
  real, intent(in) :: B
  myadd = a%x + b
end function MyAdd
  end module

[Bug fortran/49592] New: [OOP] Non-polymorphic ALLOCATE with polymorphic SOURCE= rejected

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] Non-polymorphic ALLOCATE with polymorphic
SOURCE= rejected
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


http://j3-fortran.org/doc/meeting/195/11-194r1.txt

According to the first round of interpretation requests (namely: J3, WG5 will
follow later), the following program is valid. gfortran rejects it with:

Allocate(y,Source=x)   ! (*)
 12
Error: Type of entity at (1) is type incompatible with source-expr at (2)


  Program m195_m1
Type t
  Real c
End Type
Type,Extends(t) :: t2
  Real d
End Type
Class(t),Allocatable :: x
Type(t),Allocatable :: y
Allocate(x,Source=t2(1.5,-1.5))
Allocate(y,Source=x)   ! (*)
!...
  End Program


Proposed edits:

[128:24] In 6.7.1.2p7, before "On successful", insert
  "If an  is not polymorphic and the  is
   polymorphic with a dynamic type that differs from its declared
   type, the value provided for that  is the ancestor
   component of the  that has the type of the
   ; otherwise, the value provided is the value of
   the ."
[128:25-26] Replace "that of " with "the value provided",
twice.

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther  2011-06-30 
12:57:10 UTC ---
#ifndef NULL
#ifdef  __GNUG__
#define NULL__null
#else
#define NULL((void *)0)
#endif
#endif

isn't providing a C++ conforming NULL for non-GCC C++ compilers (who
do not define __GNUG__).  A more conforming version would be

#ifdef __GNUG__
#define NULL __null
#else
#ifndef __cplusplus
#define NULL ((void *)0)
#else
#define NULL 0
#endif
#endif

[Bug tree-optimization/49516] SRA generates memory references into its replacements

[dnovillo at gcc dot gnu.org]

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

--- Comment #7 from Diego Novillo  2011-06-30 
13:24:06 UTC ---
Author: dnovillo
Date: Thu Jun 30 13:24:00 2011
New Revision: 175702

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175702
Log:
ChangeLog.google-4_6
2011-06-29  Diego Novillo  

Backport from gcc-4_6-branch

2011-06-29  Martin Jambor  
Backport from mainline
2011-06-24  Martin Jambor  

PR tree-optimizations/49516
* tree-sra.c (sra_modify_assign): Choose the safe path for
aggregate copies if we also did scalar replacements.

testsuite/ChangeLog.google-4_6
2011-06-29  Diego Novillo  

Backport from gcc-4_6-branch

2011-06-29  Martin Jambor  
Backport from mainline
2011-06-24  Martin Jambor  

PR tree-optimizations/49516
* g++.dg/tree-ssa/pr49516.C: New test.


Added:
branches/google/gcc-4_6/gcc/testsuite/g++.dg/tree-ssa/pr49516.C
  - copied unchanged from r175634,
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/tree-ssa/pr49516.C
Modified:
branches/google/gcc-4_6/   (props changed)
branches/google/gcc-4_6/gcc/ChangeLog.google-4_6
branches/google/gcc-4_6/gcc/config/rs6000/rs6000.c   (props changed)
branches/google/gcc-4_6/gcc/config/rs6000/rs6000.h   (props changed)
branches/google/gcc-4_6/gcc/testsuite/ChangeLog.google-4_6
branches/google/gcc-4_6/gcc/testsuite/gcc.target/powerpc/ppc-round.c  
(props changed)
branches/google/gcc-4_6/gcc/tree-sra.c
branches/google/gcc-4_6/libjava/classpath/   (props changed)

Propchange: branches/google/gcc-4_6/
('svn:mergeinfo' modified)

Propchange: branches/google/gcc-4_6/
('svnmerge-integrated' modified)

Propchange: branches/google/gcc-4_6/gcc/config/rs6000/rs6000.c
('svn:mergeinfo' modified)

Propchange: branches/google/gcc-4_6/gcc/config/rs6000/rs6000.h
('svn:mergeinfo' modified)

Propchange:
branches/google/gcc-4_6/gcc/testsuite/gcc.target/powerpc/ppc-round.c
('svn:mergeinfo' modified)

Propchange: branches/google/gcc-4_6/libjava/classpath/
('svn:mergeinfo' modified)

[Bug tree-optimization/49094] ARM aligned(1) attribute is sometimes dropped

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  2011-06-30 
13:24:23 UTC ---
Author: jamborm
Date: Thu Jun 30 13:24:19 2011
New Revision: 175703

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175703
Log:
2011-06-30  Martin Jambor  

PR tree-optimization/49094
* tree-sra.c (tree_non_mode_aligned_mem_p): New function.
(build_accesses_from_assign): Use it.

* testsuite/gcc.dg/tree-ssa/pr49094.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr49094.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug tree-optimization/46787] Does not vectorize loop with load from scalar variable

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-06-30 
13:27:47 UTC ---
Author: rguenth
Date: Thu Jun 30 13:27:43 2011
New Revision: 175704

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175704
Log:
2011-06-30  Richard Guenther  

PR tree-optimization/46787
* tree-data-ref.c (dr_address_invariant_p): Remove.
(find_data_references_in_stmt): Invariant accesses are ok now.
* tree-vect-stmts.c (vectorizable_load): Handle invariant
loads.
* tree-vect-data-refs.c (vect_analyze_data_ref_access): Allow
invariant loads.

* gcc.dg/vect/vect-121.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-121.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/46787] Does not vectorize loop with load from scalar variable

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Guenther  2011-06-30 
13:28:06 UTC ---
Fixed.

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  2011-06-30 
13:28:46 UTC ---
Author: gjl
Date: Thu Jun 30 13:28:43 2011
New Revision: 175705

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

PR target/34734
Backport from mainline
* config/avr/avr.c (avr_handle_progmem_attribute): Move warning 
about uninitialized data attributed 'progmem' from here...
(avr_encode_section_info): ...to this new function.
(TARGET_ENCODE_SECTION_INFO): New define.
(avr_section_type_flags): For data in ".progmem.data", remove
section flag SECTION_WRITE.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/avr/avr.c

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
 CC||gjl at gcc dot gnu.org
  Known to work||4.6.2
 Resolution||FIXED
   Target Milestone|--- |4.6.2
  Known to fail||4.6.1

--- Comment #8 from Georg-Johann Lay  2011-06-30 
13:39:18 UTC ---
Closed as resolved+fixed.

(In reply to comment #5)
> same problem in 4.5.2.
> Maybe importance of this bug should be increased? Imho it's a little bit
> embarrassing to keep this bug so long... (since 2008, over 3 yrs!)
> regards

Increasing importance won't help.  The only thing that would help is increasing
number of people that are inclined to improve avr-gcc.

regards

Note that progmem on types is not documented an not supposed to work at all.

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

[gjl at gcc dot gnu.org]

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

--- Comment #9 from Georg-Johann Lay  2011-06-30 
13:45:08 UTC ---
Author: gjl
Date: Thu Jun 30 13:45:04 2011
New Revision: 175706

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175706
Log:
PR target/34734
Backport from mainline
(avr_section_type_flags): For data in ".progmem.data", remove
section flag SECTION_WRITE.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/avr/avr.c

[Bug fortran/49540] [4.6 Regression] Memory-hog with large DATA stmt

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.7.0
Summary|[4.6/4.7 Regression]|[4.6 Regression] Memory-hog
   |Memory-hog with large DATA  |with large DATA stmt
   |stmt|
  Known to fail|4.7.0   |

--- Comment #12 from Jakub Jelinek  2011-06-30 
13:55:02 UTC ---
Fixed on the trunk, will backport to 4.6 soon.

[Bug tree-optimization/49442] [4.5/4.6/4.7 Regression] Misaligned store support pessimization

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-06-30 
13:56:46 UTC ---
__builtin_assume_aligned is now supported on the trunk.  Leaving this open even
there so that the default cost model is adjusted.

[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-06-30 
13:57:21 UTC ---
(In reply to comment #3)
> Untested fix for the order.

For the example of comment 0, gfortran + patch gives the gfortran 4.1 et al.
result.

For the example which is contained in the attachment, one gets the following
result, when printing (in that order) i, j, k, l.

gfortran 4.1-4.5: ICE in gfc_assign_data_value_range.

gfortran 4.7 (w/ patch) -- and pathf90 3.2.99, openf95 4.2 and sunf95 8.3:
4, 5, 5, 5, 5, 1, 2, 2, 2, 3, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 1, 5, 5, 5, 5, 2, 5, 5, 5, 5, 2, 5, 5, 5, 5, 2, 5, 5, 5, 5, 3, 5, 5, 6

ifort 11.1 and pgf90 10.1:
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 1, 0, 0, 0, 0, 2, 0, 0, 0, 0, 2, 0, 0, 0, 0, 2, 0, 0, 0, 0, 3, 0, 0, 6
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6

gfortran 4.6/4.7 (w/o patch):
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 1, 5, 5, 5, 5, 2, 5, 5, 5, 5, 2, 5, 5, 5, 5, 2, 5, 5, 5, 5, 3, 5, 5, 6
4, 5, 5, 5, 5, 1, 2, 2, 2, 3, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6

For comparison, the m and n lines are:
4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6
4, 5, 5, 5, 5, 1, 2, 2, 2, 3, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6

[Bug preprocessor/48532] Wrong location of namespaced pragma involving macros

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #4 from Georg-Johann Lay  2011-06-30 
14:52:54 UTC ---
(In reply to comment #2)
> Author: dodji

> gcc/testsuite/
> 
> * gcc.dg/cpp/pragma-3.c: New test case.
> 
> Added:
> trunk/gcc/testsuite/gcc.dg/cpp/pragma-3.c

Your testcase breaks if target do not support openmp.
Please put it in some gomp subdir or use a gate function like

./testsuite/lib/target-supports.exp::check_effective_target_fopenmp

Thanks, Johann

[Bug c++/49593] New: [C++0x] cannot use T{t}... as pack expansion

[redi at gcc dot gnu.org]

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

   Summary: [C++0x] cannot use T{t}... as pack expansion
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org


template
void f(T...)
{ }

template
static void
g(Args&&... args)
{
f( static_cast(args)... );

f( (Args)args... );

f( Args(args)... );

f( Args{args}... );   // ERROR
}

int main()
{
g(1, '2', 3.0);
}

The line marked ERROR fails, it should be equivalent to the previous statement

[Bug fortran/49590] ENTRY: Reject combining USE associated variable with RESULT variable

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-06-30 15:10:15 UTC ---
I believe that it is the other addendum that makes the
code invalid.

Append new statement to 12.6.2.6p8 [310:20],
  "A name that appears as a  in an ENTRY statement
   shall not appear in any executable statement that precedes the
   first RESULT clause with that name."

The part you quote concerns "statement functions".  There are
no statement functions in your example.

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #6 from Yukhin Kirill  2011-06-30 
15:11:41 UTC ---
I've looked into tail-call opt. Seems we need not call it at all if we have
new/old stack addresses for parameters overlap. BTW, I think it is to
conservative, anyway...
We have call to pointer and passing of 5 params. Last param is out of our
interest, but first 4 do. 
We have in expand:
  GIMPLE snippet:
D.172468_17 = MEM[(struct cons &)&arg_refs + 12].head;
D.172469_18 = MEM[(struct cons &)&arg_refs + 8].head;
D.172470_19 = MEM[(struct cons &)&arg_refs + 4].head;
D.172471_20 = MEM[(struct cons &)&arg_refs];
D.172462_21 = (sizetype) fun_ptr$__delta_26;
D.172463_22 = obj_3(D) + D.172462_21;
fun_ptr$__pfn_23 (D.172463_22, D.172471_20, D.172470_19, D.172469_18,
D.172468_17); [tail call]

And subsequently expanding it we have RTL:
(insn 19 18 20 4 (set (reg/f:SI 80)
(mem/s/f/j/c:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 28 [0x1c])) [0 MEM[(struct cons &)&arg_refs +
12].head+0 S4 A32])) include/base/thread_management.h:1534 -1
 (nil))

(insn 20 19 21 4 (set (mem:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 16 [0x10])) [0 S4 A32])
(reg/f:SI 80)) include/base/thread_management.h:1534 -1
 (nil))

(insn 21 20 22 4 (set (reg/f:SI 81)
(mem/s/f/j/c:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 24 [0x18])) [0 MEM[(struct cons &)&arg_refs +
8].head+0 S4 A32])) include/base/thread_management.h:1534 -1
 (nil))

(insn 22 21 23 4 (set (mem:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 12 [0xc])) [0 S4 A32])
(reg/f:SI 81)) include/base/thread_management.h:1534 -1
 (nil))

(insn 23 22 24 4 (set (reg/f:SI 82)
(mem/s/f/j/c:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 20 [0x14])) [0 MEM[(struct cons &)&arg_refs +
4].head+0 S4 A32])) include/base/thread_management.h:1534 -1
 (nil))

(insn 24 23 25 4 (set (mem:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 8 [0x8])) [0 S4 A32])
(reg/f:SI 82)) include/base/thread_management.h:1534 -1
 (nil))

(insn 25 24 26 4 (parallel [
(set (reg:SI 83)
(plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) step-14.cc:4271 -1
 (nil))

(insn 26 25 27 4 (set (reg/f:SI 84)   <
(mem/f/c:SI (reg:SI 83) [0 MEM[(struct cons &)&arg_refs]+0 S4 A32]))
include/base/thread_management.h:1534 -1 <
 (nil))

(insn 27 26 28 4 (set (mem:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 4 [0x4])) [0 S4 A32])
(reg/f:SI 84)) include/base/thread_management.h:1534 -1
 (nil))

(insn 28 27 29 4 (parallel [
(set (reg:SI 85)
(plus:SI (reg/v/f:SI 77 [ obj ])
(reg:SI 74 [ fun_ptr$__delta ])))
(clobber (reg:CC 17 flags))
]) include/base/thread_management.h:1534 -1
 (nil))

(insn 29 28 30 4 (set (mem:SI (reg/f:SI 53 virtual-incoming-args) [0 S4 A32])
(reg:SI 85)) include/base/thread_management.h:1534 -1
 (nil))

(call_insn/j 30 29 31 4 (call (mem:QI (reg/f:SI 59 [ fun_ptr$__pfn ]) [0
*fun_ptr$__pfn_23 S1 A8])
(const_int 20 [0x14])) include/base/thread_management.h:1534 -1
 (nil)
(expr_list:REG_DEP_TRUE (use (mem/f/i:SI (reg/f:SI 53
virtual-incoming-args) [0 S4 A32]))
(expr_list:REG_DEP_TRUE (use (mem/f/i:SI (plus:SI (reg/f:SI 53
virtual-incoming-args)
(const_int 4 [0x4])) [0 S4 A32]))
(expr_list:REG_DEP_TRUE (use (mem/f/i:SI (plus:SI (reg/f:SI 53
virtual-incoming-args)
(const_int 8 [0x8])) [0 S4 A32]))
(expr_list:REG_DEP_TRUE (use (mem/f/i:SI (plus:SI (reg/f:SI 53
virtual-incoming-args)
(const_int 12 [0xc])) [0 S4 A32]))
(expr_list:REG_DEP_TRUE (use (mem/f/i:SI (plus:SI (reg/f:SI
53 virtual-incoming-args)
(const_int 16 [0x10])) [0 S4 A32]))
(nil)))


You can see that calculation of address of 4-th param is performed in different
way. We calculate a sum, store it to register, load memory from that address
and the put it on the new stack.

BUT. Predicate which check for memory overlapping looks like this:
 static bool
  mem_overlaps_already_clobbered_arg_p (rtx addr, unsigned HOST_WIDE_INT size)
  {
HOST_WIDE_INT i;

if (addr == crtl->args.internal_arg_pointer)
  i = 0;
else if (GET_CODE (addr) == PLUS
 && XEXP (addr, 0) == crtl->args.internal_arg_pointer
 && CONST_INT_P (XEXP (addr, 1)))
  i = INTVAL (XEXP (addr, 1));
/* Return true for arg pointer based indexed addressing.  */
else if (GET_CODE (addr) == PLUS
  

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #7 from Yukhin Kirill  2011-06-30 
15:22:58 UTC ---
Expanding arguments in different ways occurs because corresponding GIMPLE
statements are of different types.
For 'good' case we have expression of type
  COMPONENT_REF

While for 'bad' one it is just a 
  MEM_REF

For that different kinds we have slightly different expanding.

The different expression types comes from front-end, at least in einline phase
accesses are different:

  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167199_17 =
MEM[(struct cons &)arg_list_2(D) + 12].head;
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167198_18 =
MEM[(struct cons &)arg_list_2(D) + 8].head;
  [include/boost/tuple/detail/tuple_basic.hpp : 130:14] D.167197_19 =
MEM[(struct cons &)arg_list_2(D) + 4].head;
  [step-14.cc : 4271:1] D.167196_20 = MEM[(struct cons &)arg_list_2(D)];
  [include/base/thread_management.h : 1534:13] D.167205_21 = (sizetype)
fun_ptr$__delta_7;
  [include/base/thread_management.h : 1534:13] D.167204_22 = obj_1(D) +
D.167205_21;
  [include/base/thread_management.h : 1534:13] iftmp.53_23 (D.167204_22,
D.167196_20, D.167197_19, D.167198_18, D.167199_17);
  [include/base/thread_management.h : 1826:5] return;

Having all that said I believe that the issue somewhat connected to fron-end
generation.

Jason, could you prompt me something? 

Your patch changes a line which has a comment:
 /* Do array-to-pointer, function-to-pointer conversion, and ignore
top-level qualifiers as required.  */
...

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #8 from Yukhin Kirill  2011-06-30 
15:26:36 UTC ---
If someone really need a quick fix, it may be done like this:
gcc/expor.s:

  static bool
  mem_overlaps_already_clobbered_arg_p (rtx addr, unsigned HOST_WIDE_INT size)
  {
HOST_WIDE_INT i;

if (addr == crtl->args.internal_arg_pointer)
  i = 0;
else if (GET_CODE (addr) == PLUS
 && XEXP (addr, 0) == crtl->args.internal_arg_pointer
 && CONST_INT_P (XEXP (addr, 1)))
  i = INTVAL (XEXP (addr, 1));
/* Return true for arg pointer based indexed addressing.  */
else if (GET_CODE (addr) == PLUS
 && (XEXP (addr, 0) == crtl->args.internal_arg_pointer
 || XEXP (addr, 1) == crtl->args.internal_arg_pointer))
  else if (GET_CODE(addr) == REG)   <---
return true;
  else
return false;

But we possibly will be to conservative doing so

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[kirill.yukhin at intel dot com]

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

--- Comment #9 from Yukhin Kirill  2011-06-30 
15:37:04 UTC ---
One more point for FE guys.
Function definition have no difference between 4 args. Here it is

include/base/thread_management.h:
template 
static inline void do_call (PFun fun_ptr,
C   &obj,
ArgList &arg_list,
internal::return_value &ret_val,
const int2type<4> &)
  {
ret_val.set ((obj.*fun_ptr) (arg_list.template get<0>(),
 arg_list.template get<1>(),
 arg_list.template get<2>(),
 arg_list.template get<3>()));
  }

[Bug libffi/49594] New: bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[fang at csl dot cornell.edu]

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

   Summary: bootstrap failure in libffi:darwin_closure for
powerpc-darwin8
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: f...@csl.cornell.edu
  Host: powerpc-apple-darwin8
Target: powerpc-apple-darwin8
 Build: powerpc-apple-darwin8


During build of gcc-4.6.1 on powerpc-darwin8 (after having disabled libquadmath
from PR 49582), I get a compilation error in libffi on
powerpc/darwin_closure.lo:

depbase=`echo src/powerpc/darwin_closure.lo | sed
's|[^/]*$|.deps/&|;s|\.lo$||'`
;\
/bin/sh ./libtool   --mode=compile
/Volumes/Mercedes2/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/./gcc/xgcc
-B/Volumes/Mercedes2/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/bin/
-B/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/lib/ -isystem
/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/include -isystem
/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/sys-include  -m64 -DHAVE_CONFIG_H -I.
-I../../../../gcc-4.6.1/libffi  -I.
 -I../../../../gcc-4.6.1/libffi/include -Iinclude
-I../../../../gcc-4.6.1/libffi/src  -I. -I../../../../gcc-4.6.1/libffi/include
-Iinclude -I../../../../gcc-4.6.1/libffi/src -g -O2 -MT
src/powerpc/darwin_closure.lo -MD -MP -MF $depbase.Tpo 
-c -o src/powerpc/darwin_closure.lo
../../../../gcc-4.6.1/libffi/src/powerpc/darwin_closure.S &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile: 
/Volumes/Mercedes2/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/./gcc/xgcc
-B/Volumes/Mercedes2/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/bin/
-B/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/lib/ -isystem
/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/include -isystem
/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/sys-include -m64 
-DHAVE_CONFIG_H -I. -I../../../../gcc-4.6.1/libffi -I.
-I../../../../gcc-4.6.1/libffi/include -Iinclude
-I../../../../gcc-4.6.1/libffi/src -I. -I../../../../gcc-4.6.1/libffi/include
-Iinclude -I../../../../gcc-4.6.1/libffi/src -g -O2 -MT
src/powerpc/darwin_closure.lo -MD -MP -MF src/powerpc/.deps/darwin_closure.Tpo
-c 
../../../../gcc-4.6.1/libffi/src/powerpc/darwin_closure.S  -fno-common -DPIC -o 
src/powerpc/.libs/darwin_closure.o
../../../../gcc-4.6.1/libffi/src/powerpc/darwin_closure.S:unknown:missing
indirect symbols for section (__DATA,__la_symbol_ptr)
make[7]: *** [src/powerpc/darwin_closure.lo] Error 1
make[6]: *** [all-recursive] Error 1
make[5]: *** [all] Error 2
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all] Error 2
make[1]: *** [all-target-libffi] Error 2
make[1]: *** Waiting for unfinished jobs

system compiler:
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)

hardware: powerpc7400 (dual G4)
OS: OS X 10.4.11 (powerpc)

[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)

[martin at decky dot cz]

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

--- Comment #2 from Martin Decky  2011-06-30 16:03:08 
UTC ---
Created attachment 24646
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24646
Initial proposed patch

The attached patch works as a temporary workaround and might also hint where
exactly the problem is.

Now, guys, please don't crucify me for this patch. I am well aware that this
patch is no more than a dirty hack and probably breaks other thinks. I present
it here only to provoke some reaction from somebody who knows GCC sources well
enough to propose a real solution.

I have just spent some 4 hours browsing the sources, analysing relevant
functions such as output_asm_insn(), ix86_print_operand(), print_reg() and
similar to figure out how to change the way the tail call instruction is
generated for this particular case. But I would really appreciate a little help
from a senior GCC developer who not only knows what and how, but also why.

Thanks in advance!

[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-06-30 
16:10:18 UTC ---
Unfortunately, this patch breaks gfortran.fortran-torture/execute/data.f90
compilation, it fails with a cryptic error.
No idea if it is a bug in the testcase that just relied on the older ordering,
or if my patch is buggy.  I guess I give up here.

[Bug target/49461] boehm-gc and gcj incompatible with pie

[mrs at gcc dot gnu.org]

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

--- Comment #11 from mrs at gcc dot gnu.org  2011-06-30 
16:14:36 UTC ---
Author: mrs
Date: Thu Jun 30 16:14:30 2011
New Revision: 175710

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175710
Log:
2011-06-30  Jack Howarth 

PR target/49461
* libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11.
* libjava/configure: Regenerate.

Modified:
branches/gcc-4_5-branch/libjava/ChangeLog
branches/gcc-4_5-branch/libjava/configure
branches/gcc-4_5-branch/libjava/configure.ac

[Bug target/49461] boehm-gc and gcj incompatible with pie

[mrs at gcc dot gnu.org]

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

--- Comment #12 from mrs at gcc dot gnu.org  2011-06-30 
16:21:44 UTC ---
Ok, the libjava problem is now fixed in 4.5.4.

[Bug other/42333] complex division failure on darwin10 with -lm

[mrs at gcc dot gnu.org]

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

--- Comment #58 from mrs at gcc dot gnu.org  2011-06-30 
16:31:29 UTC ---
Author: mrs
Date: Thu Jun 30 16:31:23 2011
New Revision: 175711

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175711
Log:
2011-06-30  Jack Howarth  

Backport from mainline
2011-02-07 Mike Stump  

PR target/42333
Add __ieee_divdc3 entry point.
* config/i386/darwin.h (DECLARE_LIBRARY_RENAMES): Retain ___divdc3
entry point.
(SUBTARGET_INIT_BUILTINS): Call darwin_rename_builtins.
* config/i386/i386.c (TARGET_INIT_LIBFUNCS): Likewise.
* config/darwin.c (darwin_rename_builtins): Add.
* config/darwin-protos.h (darwin_rename_builtins): Add.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/darwin-protos.h
branches/gcc-4_5-branch/gcc/config/darwin.c
branches/gcc-4_5-branch/gcc/config/i386/darwin.h
branches/gcc-4_5-branch/gcc/config/i386/i386.c

[Bug other/42333] complex division failure on darwin10 with -lm

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

  Known to work||4.5.4
  Known to fail||4.5.3

--- Comment #59 from mrs at gcc dot gnu.org  2011-06-30 
16:33:17 UTC ---
Fixed in 4.5.4.

[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.7.0

[Bug c++/49587] Code generation error with dynamic libraries.

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2011-06-30 
16:43:08 UTC ---
Most likely a dup of bug 49538.

[Bug c/49595] New: on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[sandals at crustytoothpaste dot net]

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

   Summary: on amd64, sizeof(__int128_t) > sizeof(intmax_t)
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sand...@crustytoothpaste.net


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

The C standard (as well as POSIX) requires that intmax_t "designates a signed
integer type capable of representing any value of any signed integer type" and
likewise for uintmax_t. However, on amd64, intmax_t is long, which is not big
enough to hold a 128-bit quantity.

A trivial preprocessed testcase is attached, not that you need one. I see this
behavior on 4.6 and 4.7:

lakeview ok % gcc -v 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-1) 

lakeview ok % /usr/lib/gcc-snapshot/bin/gcc -v 
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20110624-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,fortran,objc,obj-c++,go
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.7-snap
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --with-arch-32=i586 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.0 20110624 (experimental) [trunk revision 175388] (Debian
20110624-1) 

This is Debian bug #629137.

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[sandals at crustytoothpaste dot net]

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

brian m. carlson  changed:

   What|Removed |Added

  Attachment #24647|0   |1
is obsolete||

--- Comment #1 from brian m. carlson  
2011-06-30 17:26:35 UTC ---
Created attachment 24648
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24648
Unpreprocessed testcase

The preprocessed testcase hardcodes long int and so doesn't test the presence
of the bug correctly. In this case, only an unpreprocessed testcase will
demonstrate the problem.

[Bug fortran/49586] Multiple initialization with DATA: Warning and initialization order

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2011-06-30 
17:28:48 UTC ---
> Unfortunately, this patch breaks gfortran.fortran-torture/execute/data.f90
> compilation, it fails with a cryptic error.

Confirmed. A reduced test is

! Program to test data statement
program data
call sub1()
end
subroutine sub1()
integer i
type tmp
  integer, dimension(4)::a 
  real :: r 
end type
type tmp1
  type (tmp) t1(4)
  integer b
end type
type (tmp1) tmp2(2)
! Full array and scalar component initializer
data tmp2(2)%t1(2)%r, tmp2(1)%t1(3)%a,
tmp2(1)%b/220,136,137,138,139,10/
data tmp2(2)%t1(2)%a(3), tmp2(2)%t1(2)%a(1)/223,221/

end

The error is emitted in show_loci in gcc/fortran/error.c when
l1 == NULL || l1->lb == NULL

With gdb I get

Breakpoint 1, show_loci (l1=0x141d23260, l2=0x0) at
../../work/gcc/fortran/error.c:383
383  if (l1 == NULL || l1->lb == NULL)
(gdb) p l1
$1 = (locus *) 0x141d23260
(gdb) p *l1
$2 = {
  nextc = 0x0, 
  lb = 0x0
}
(gdb) bt
#0  show_loci (l1=0x141d23260, l2=0x0) at ../../work/gcc/fortran/error.c:383
#1  0x00010002832d in error_print (type=0x100a46df1 "Error:",
format0=0x100a63ad0 "non-constant initialization expression at %L",
argp=0x7fff5fbfd128) at ../../work/gcc/fortran/error.c:627
Previous frame inner to this frame (gdb could not unwind past this frame)

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-06-30 
17:42:59 UTC ---
sizeof(intmax_t) is fixed by various LP64 ABIs and cannot be changed

I believe the stock answer is that __int128 is not a C99 extended integer type,
so isn't one of the types that intmax_t can represent the value of

[Bug middle-end/49596] New: [4.7 Regression] FAIL: gcc.dg/torture/pr43879_1.c

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] FAIL: gcc.dg/torture/pr43879_1.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rgue...@gcc.gnu.org


On Linux/x86, revision 175707

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg01199.html

caused:

FAIL: gcc.dg/torture/pr43879_1.c  -O1  execution test
FAIL: gcc.dg/torture/pr43879_1.c  -O2  execution test
FAIL: gcc.dg/torture/pr43879_1.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/pr43879_1.c  -O3 -g  execution test
FAIL: gcc.dg/torture/pr43879_1.c  -Os  execution test

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[sandals at crustytoothpaste dot net]

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

--- Comment #3 from brian m. carlson  
2011-06-30 18:12:39 UTC ---
(In reply to comment #2)
> sizeof(intmax_t) is fixed by various LP64 ABIs and cannot be changed

That does sound potentially problematic.  I don't see how that solves the
standard conformance issue, though.  If intmax_t cannot be changed, then I
suppose the only appropriate behavior is not to provide any integer types
larger
than intmax_t with -std=c99.

> I believe the stock answer is that __int128 is not a C99 extended integer 
> type,
> so isn't one of the types that intmax_t can represent the value of

There are five *standard signed integer types* There may also be
*implementation-defined extended signed integer types*. The standard and
extended signed integer types are collectively called *signed integer types*.

Since the standard specifies intmax_t in terms of a "signed integer type", it
therefore includes any implementation-defined extended signed integer types,
including __int128_t.

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-06-30 
18:29:02 UTC ---
(In reply to comment #3)
> Since the standard specifies intmax_t in terms of a "signed integer type", it
> therefore includes any implementation-defined extended signed integer types,

Yes.

> including __int128_t.

You're assuming __int128 is an implementation-defined extended integer type.
If GCC chooses to call __int128 some other type that doesn't fall under the C99
definition of "implementation defined integer type" then intmax_t doesn't have
to be able to represent its values.

Of course this is cheating by playing wordgames, but sizeof(intmax_t) can't
change and people want to be able to use __int128

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-06-30 
18:33:27 UTC ---
(In reply to comment #3)
> suppose the only appropriate behavior is not to provide any integer types
> larger
> than intmax_t with -std=c99.

Use -pedantic-errors if you want to reject programs using __int128

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|regression  |tree-optimization

--- Comment #13 from Eric Botcazou  2011-06-30 
18:54:22 UTC ---
Recategorizing.

[Bug fortran/49597] New: gfortran namelist read bug

[david.sagan at gmail dot com]

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

   Summary: gfortran namelist read bug
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.sa...@gmail.com


Test program is:

program the_bug

implicit none

type example_struct
  logical logic
end type example_struct

integer readstatus
type(example_struct) fzz(3)
namelist /parameters/ fzz
!
open (unit= 10,file='the_bug.in')
read(10, nml = parameters,iostat=readstatus)
write(*,*) "iostat = ", readstatus
end program the_bug


Input file "the_bug.in" is:

¶meters 
fzz(1)%logic = .true.
fzz(2)%logic = .true.
/

bla bla bla


Running gives:

/lnx4103:~/dcs/bmad_distribution/test> gfortran --version
GNU Fortran (GCC) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

lnx4103:~/dcs/bmad_distribution/test> gfortran test.f90 ; ./a.out
 iostat = 5010


iostat should be 0. 
If you delete the "bla bla bla" line you get iostat = -1. 
If you change the name of the variable from "fzz" to, say, "zz" (2 places in
the program and 2 places in the_bug.in) you get iostat as 0 as it should be.
I have not tried extensively to test this but variable names beginning with "t"
and variable names beginning with "f" show the bug and other names do not.

[Bug bootstrap/49584] [4.4 regression] bootstrap failure on m68k-linux: segfault compiling _muldi3

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #3 from Mikael Pettersson  2011-06-30 
19:08:44 UTC ---
A bootstrap from scratch with a clean objdir succeeded.  Sorry about the noise.

[Bug fortran/49597] gfortran namelist read bug

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2011-06-30 
19:31:46 UTC ---
I see 'iostat = 5010' with gcc version 4.5.0 20100404 (experimental) [trunk
revision 157958] (GCC), but not (i.e., iostat = 0) with versions 4.4.6, 4.5.2
20101122 (prerelease) [gcc-4_5-branch revision 167027], 4.5.3, 4.6.0 20100413
(experimental) [trunk revision 158252], nor with 4.7.0 (trunk).

AFAICT this has been fixed and you should try a more recent version.

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  2011-06-30 
19:32:29 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:32:23 2011
New Revision: 175721

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175721
Log:
PR tree-optimization/49572
* tree-ssa-dom.c (initialize_hash_element) : Use the
type of the RHS instead of that of the LHS for the expression type.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[sch...@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab  2011-06-30 19:33:55 
UTC ---
By (directly) using an identifier starting with two underscores you are leaving
the territory of the C standard.

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  2011-06-30 
19:35:49 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:35:45 2011
New Revision: 175722

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175722
Log:
PR tree-optimization/49572
* tree-ssa-dom.c (initialize_hash_element) : Use the
type of the RHS instead of that of the LHS for the expression type.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa-dom.c

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  2011-06-30 
19:37:43 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:37:41 2011
New Revision: 175723

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175723
Log:
PR tree-optimization/49572
* tree-ssa-dom.c (initialize_hash_element) : Use the
type of the RHS instead of that of the LHS for the expression type.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/tree-ssa-dom.c

[Bug fortran/44589] Missing not-set diagnositic (as READ arguments are clobbered)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.30 19:39:04
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-06-30 
19:39:04 UTC ---
Still there at revision 175707 (trunk).

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  2011-06-30 
19:39:47 UTC ---
Author: ebotcazou
Date: Thu Jun 30 19:39:41 2011
New Revision: 175724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175724
Log:
PR tree-optimization/49572
* tree-ssa-dom.c (initialize_hash_element) : Use the
type of the RHS instead of that of the LHS for the expression type.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-dom.c

[Bug fortran/47425] Array constructor with type-spec: Fails with more complicated length type expr

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.30 19:41:43
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-06-30 
19:41:43 UTC ---
Still there at revision 175707 (trunk).

[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #3 from Jeffrey A. Law  2011-06-30 19:42:47 
UTC ---
Frankly, I'm just not able to wrap my head around the tree-ssa-uninit
implementation.  I understand the general concepts, but just can't seem to find
where in that code we handle certain things.  Perhaps it simply doesn't handle
them.

In this simpler sample code we have:

/* { dg-do compile } */
/* { dg-options "-Wuninitialized -O2" } */

int g;
void bar();
void blah(int);

int foo (int n, int l, int m, int r)
{
  int v;

  if (n < 10 || m > 100)
v = r;

  if (m) g++;

  if ( n < 10 ||  m > 100)
  blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */

  return 0;
}

Compiling with -O2 -Wuninitialized on cris-elf.

Someone who knows the code in tree-ssa-uninit.c really needs to chime in...
Reading that code just makes my head hurt.

>From the standpoint of the resulting CFG, the path 2->8->4->5->6 can never be
traversed, nor can 2->3->9->4->6.  2->3->9->4->5 is properly guarded as far as
I can tell, though I'm not convinced tree-ssa-uninit.c is computing the guards
correctly.

[Bug tree-optimization/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #18 from Eric Botcazou  2011-06-30 
19:45:11 UTC ---
Thanks for reporting the problem.

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[sandals at crustytoothpaste dot net]

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

--- Comment #7 from brian m. carlson  
2011-06-30 20:16:50 UTC ---
(In reply to comment #5)
> (In reply to comment #3)
> > suppose the only appropriate behavior is not to provide any integer types
> > larger
> > than intmax_t with -std=c99.
> 
> Use -pedantic-errors if you want to reject programs using __int128

I don't.  I want to compile using C99 mode (I use scoped for) on a variety of
different compilers, taking advantage of 128-bit integers whenever possible
(for performance reasons).  The portable way to do this with the preprocessor
is to see if UINTMAX_MAX is set to the proper value.  In fact, GCC as it is
currently provides no way to determine whether 128-bit integers are in fact
supported at all on the current hardware, which leads to compilation failures
on, say, 32-bit SPARC.

The conformance issue, while important, is secondary.  I do expect GCC to
comply with the standard in standards mode, and I do expect any deviation from
the standards behavior in standards mode to be considered a bug worth fixing. 
But it isn't the primary goal here.

I also see no mention of intmax_t in the SysV ABI for x86-64. Can you be more
specific about what specifically would cause ABI breakage if intmax_t were to
become 128-bit on x86_64-pc-linux-gnu?  According to
, as long as libc behaves
appropriately, it shouldn't be a problem.

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[sandals at crustytoothpaste dot net]

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

--- Comment #8 from brian m. carlson  
2011-06-30 20:22:37 UTC ---
(In reply to comment #6)
> By (directly) using an identifier starting with two underscores you are 
> leaving
> the territory of the C standard.

I don't agree.  The footnote to the text that I quoted states:
"Implementation-defined keywords shall have the form of an identifier reserved
for any use as
described in 7.1.3."  So the standard specifies that such
implementation-defined signed integer types (which it has just instructed
implementors must be implemented using double underscores) are part of the
signed integer types. I don't see another legitimate interpretation here.

As I said previously, I want to use 128-bit integers where possible. If
intmax_t were correctly and appropriately defined as to use 128-bit integers,
then the behavior would not only be standards-conforming with regard to C99,
but it would also be practically useful and I wouldn't have to use
double-underscored types at all.

[Bug c++/49598] New: Ice on lambda with implicit capture by value.

[3dw4rd at verizon dot net]

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

   Summary: Ice on lambda with implicit capture by value.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 3dw...@verizon.net


I have a brand new (r175707) 4.7 build on x86_64 GNU/Linux.

I saw an error with lambdas on stackoverflow:
---
#include 

using std::cout;
using std::endl;

int
main()
{
  int i = 10;
  int& ir = i;

  [=] // [i, ir] explicit capture works.
  {
  cout << "value capture" << endl
   << "i: " << i << endl
   << "ir: " << ir << endl
   << "&i: " << &i << endl
   << "&ir: " << &ir << endl
   << endl;
  }();
}
---

This is reduced somewhat.

I get:
---
[ed@localhost ~]$ ./bin/bin/g++ -std=c++0x -o lamb2 lamb2.cpp
lamb2.cpp: In function ‘int main()’:
lamb2.cpp:10:1: error: non-trivial conversion at assignment
int
int &
D.28407.__ir = ir;

lamb2.cpp:10:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
---

[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

[xinliangli at gmail dot com]

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

--- Comment #4 from davidxl  2011-06-30 20:37:36 
UTC ---
I can to reproduce the problem on x86-64 linux. Can you help provide the
following dump:

 -fdump-tree-uninit-blocks-details?

Thanks,

David



(In reply to comment #3)
> Frankly, I'm just not able to wrap my head around the tree-ssa-uninit
> implementation.  I understand the general concepts, but just can't seem to 
> find
> where in that code we handle certain things.  Perhaps it simply doesn't handle
> them.
> 
> In this simpler sample code we have:
> 
> /* { dg-do compile } */
> /* { dg-options "-Wuninitialized -O2" } */
> 
> int g;
> void bar();
> void blah(int);
> 
> int foo (int n, int l, int m, int r)
> {
>   int v;
> 
>   if (n < 10 || m > 100)
> v = r;
> 
>   if (m) g++;
> 
>   if ( n < 10 ||  m > 100)
>   blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
> 
>   return 0;
> }
> 
> Compiling with -O2 -Wuninitialized on cris-elf.
> 
> Someone who knows the code in tree-ssa-uninit.c really needs to chime in...
> Reading that code just makes my head hurt.
> 
> From the standpoint of the resulting CFG, the path 2->8->4->5->6 can never be
> traversed, nor can 2->3->9->4->6.  2->3->9->4->5 is properly guarded as far as
> I can tell, though I'm not convinced tree-ssa-uninit.c is computing the guards
> correctly.

[Bug c++/49598] Ice on lambda with implicit capture by value.

[3dw4rd at verizon dot net]

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

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-06-30 
20:43:39 UTC ---
Reduced testcase:
-
int
main()
{
  int i = 10;
  int& ir = i;

  [=] // [i, ir] explicit capture works.
  {
   i == ir;
  }();
}
-
With [=, ir] I get a warning:
lamb3.cpp:10:7: warning: explicit by-copy capture of ‘ir’ redundant with
by-copy capture default [enabled by default]
But it compiles.

With [=, i] I get the ICE.

[Bug c++/49587] Code generation error with dynamic libraries.

[jarrydb at cse dot unsw.edu.au]

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

--- Comment #5 from Jarryd Beck  2011-06-30 
20:56:32 UTC ---
Ah, yes I think it is.

[Bug c++/48481] C++ overloading memory hog

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-06-30 
21:10:07 UTC ---
Author: jason
Date: Thu Jun 30 21:10:03 2011
New Revision: 175732

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175732
Log:
PR c++/48481
* name-lookup.c (struct arg_lookup): Add fn_set.
(add_function): Check it.
(lookup_arg_dependent_1): Initialize it.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/g++.dg/template/crash37.C
trunk/gcc/testsuite/g++.dg/template/ptrmem4.C
trunk/gcc/testsuite/g++.old-deja/g++.other/pmf3.C

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2011-06-30 
21:23:55 UTC ---
(In reply to comment #7)
> The conformance issue, while important, is secondary.  I do expect GCC to
> comply with the standard in standards mode, and I do expect any deviation from
> the standards behavior in standards mode to be considered a bug worth fixing. 

What do you mean by standards mode?
It's clearly documented in the manual that -std=c99 does NOT mean non-standard
extensions are rejected, for that you need to use -pedantic-errors, and that
rejects __int128.

[Bug c++/49355] new T({""}) crashes G++ when struct T { std::string foobar };

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[sandals at crustytoothpaste dot net]

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

--- Comment #10 from brian m. carlson  
2011-06-30 21:47:15 UTC ---
(In reply to comment #9)
> What do you mean by standards mode?
> It's clearly documented in the manual that -std=c99 does NOT mean non-standard
> extensions are rejected, for that you need to use -pedantic-errors, and that
> rejects __int128.

My complaint is not even about __int128.  My complaint is about intmax_t.  With
-std=c99, intmax_t is not capable of representing all the values of all
implementation-defined signed integer types.  The C standard requires that it
is so capable.  If the implementation provides a type (however named (or
unnamed) or specified) that is an implementation-defined signed integer type,
intmax_t must be capable of expressing all the values that such a type may
hold.

I don't care how the type is specified or named.  It exists.  It happens to be
named in the standard-specified manner; that is convenient, but ultimately
irrelevant. It exists, therefore, intmax_t's behavior is specified in terms of
that type. Period.

Your only out here is if you claim that the type in question (however named,
unnamed, or specified) is not an implementation-defined signed integer type,
and in that case, you'll need to specify that in the documentation and specify
what it *is*.  You should probably document that it is a) not
implementation-defined, b) not signed (or unsigned, as appropriate), c) not
integral, or d) not a type.

[Bug c++/49569] -std=gnu++0x causes segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/49599] New: FRE/DSE not performing well on aggregates

[jamborm at gcc dot gnu.org]

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

   Summary: FRE/DSE not performing well on aggregates
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamb...@gcc.gnu.org


In the following testcase:

struct S
{
  int i;
  unsigned short f1;
  char f2;
  unsigned short f3[2], f4;
};

int foo (struct S *p)
{
  struct S l;

  l = *p;
  l.i++;
  *p = l;
}

in which SRA does not do total scalarization because of the array in
the aggregate (we do it only for structures), the optimized dump looks
like this:

foo (struct S * p)
{
  int l$i;
  struct S l;
  int D.1967;

:
  l = *p_1(D);
  l$i_6 = p_1(D)->i;
  D.1967_3 = l$i_6 + 1;
  *p_1(D) = l;
  p_1(D)->i = D.1967_3;
  return;
}

The loads and stores from and to l should be eliminated, probably by
FRE and DSE.

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  2011-06-30 22:27:57 UTC ---
On Thu, 30 Jun 2011, sandals at crustytoothpaste dot net wrote:

> Your only out here is if you claim that the type in question (however named,
> unnamed, or specified) is not an implementation-defined signed integer type,
> and in that case, you'll need to specify that in the documentation and specify
> what it *is*.  You should probably document that it is a) not
> implementation-defined, b) not signed (or unsigned, as appropriate), c) not
> integral, or d) not a type.

The implementation-defined extended integer types are documented alongside 
the other implementation-defined behavior in implement-c.texi: "GCC does 
not support any extended integer types.".

Note that "char" is a standard integer type that is not a signed or 
unsigned integer type although it behaves like one or the other; you could 
think of it as a "sui generis integer type".  And the right way to think 
of __int128 is as a "sui generis extended type", that is not an integer 
type although it shares some properties with them.  Maybe the __fpreg type 
supported on IA64 is more obviously a "sui generis extended type" given 
the restrictions on how it can be used - but the same category contains 
both those types (and ARM __fp16, for another example).

[Bug target/49600] New: Bad int->float split in i386.md

[hjl.tools at gmail dot com]

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

   Summary: Bad int->float split in i386.md
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com


There is

(define_split
  [(set (match_operand:MODEF 0 "register_operand" "")
(float:MODEF (match_operand:SI 1 "register_operand" "")))]
  "TARGET_SSE2 && TARGET_SSE_MATH
   && TARGET_USE_VECTOR_CONVERTS && optimize_function_for_speed_p (cfun)
   && reload_completed
   && (SSE_REG_P (operands[0])
   || (GET_CODE (operands[0]) == SUBREG
   && SSE_REG_P (operands[0])))"
  [(const_int 0)]
{
  rtx op1 = operands[1];

  operands[3] = simplify_gen_subreg (mode, operands[0],
 mode, 0);
  if (GET_CODE (op1) == SUBREG)
op1 = SUBREG_REG (op1);

  if (GENERAL_REG_P (op1) && TARGET_INTER_UNIT_MOVES)
{
  operands[4] = simplify_gen_subreg (V4SImode, operands[0], mode, 0);
  emit_insn (gen_sse2_loadld (operands[4],
  CONST0_RTX (V4SImode), operands[1]));
}
  /* We can ignore possible trapping value in the
 high part of SSE register for non-trapping math. */
  else if (SSE_REG_P (op1) && !flag_trapping_math)
operands[4] = simplify_gen_subreg (V4SImode, operands[1], SImode, 0);
  else
gcc_unreachable ();
  emit_insn
(gen_sse2_cvtdq2p (operands[3], operands[4]));
  DONE;   
})

When TARGET_USE_VECTOR_CONVERTS is true, TARGET_INTER_UNIT_MOVES
is false and GENERAL_REG_P (op1) is true. we will get gcc_unreachable.

[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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