[Bug libfortran/51119] MATMUL slow for large matrices

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat
   ||dot ethz.ch

--- Comment #8 from Joost VandeVondele  
2012-06-29 07:19:03 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > Janne, have you had a chance to look at this ? For larger matrices MATMMUL 
> > is
> > really slow. Anything that includes even the most basic blocking scheme 
> > should
> > be faster. I think this would be a valuable improvement.
> 
> I implemented a block-panel multiplication algorithm similar to GOTO BLAS and
> Eigen, but I got side-tracked by other things and never found the time to fix
> the corner-case bugs and tune performance. IIRC I reached about 30-40 % of 
> peak
> flops which was a bit disappointing.

I think 30% of peak is a good improvement over the current version (which
reaches 7% of peak (92% for MKL) for a double precision 8000x8000 matrix
multiplication) on a sandy bridge.

In addition to blocking, is the Fortran runtime being compiled with a set of
compile options that enables vectorization ? In the ideal world, gcc would
recognize the loop pattern in the runtime library code, and do blocking,
vectorization etc. automagically.

[Bug lto/53768] [4.7 Regression] Undefined references with boost 1.46/1.48/1.49

[vincenzo.innocente at cern dot ch]

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

--- Comment #7 from vincenzo Innocente  
2012-06-29 07:25:35 UTC ---
It HAS a side effect I observed also in 4.8 and had no time to reduce yet
something pretty weird
plenty of 
error:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/MulticoreRunLumiEventChecker.o:
multiple definition of
'edm::WorkerT::implDoBegin(edm::EventPrincipal&,
edm::EventSetup const&, edm::CurrentProcessingContext const*)::{lambda(ed
m::Worker*)#1}::operator void (*)(edm::Worker*)() const'
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/EventContentAnalyzer.o:
previous definition he
re
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: error:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/Prescaler.o:
multiple definition of 'ed
m::WorkerT::implDoBegin(edm::EventPrincipal&, edm::EventSetup
const&, edm::CurrentProcessingContext const*)::{lambda(edm::Worker*)#1}::_FUN(
edm::Worker*)'
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/LogErrorFilter.o:
previous definition here

ld is 
GNU gold (GNU Binutils 2.22.52.20120515) 1.11

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  
2012-06-29 07:39:02 UTC ---
The patch  HAS a side effect that I observed also in 4.8 and had no time to
reduce yet.
(At least now I know the origin of it)
something pretty weird
plenty of 
error:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/MulticoreRunLumiEventChecker.o:
multiple definition of
'edm::WorkerT::implDoBegin(edm::EventPrincipal&,
edm::EventSetup const&, edm::CurrentProcessingContext const*)::{lambda(ed
m::Worker*)#1}::operator void (*)(edm::Worker*)() const'
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/EventContentAnalyzer.o:
previous definition he
re
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld: error:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/Prescaler.o:
multiple definition of 
'edm::WorkerT::implDoBegin(edm::EventPrincipal&, edm::EventSetup
const&, edm::CurrentProcessingContext const*)::{lambda(edm::Worker*)#1}::_FUN(
edm::Worker*)'
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/bin/ld:
tmp/slc5_amd64_gcc470/src/FWCore/Modules/src/FWCoreModules/LogErrorFilter.o:
previous definition here

ld is 
GNU gold (GNU Binutils 2.22.52.20120515) 1.11

[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #11 from Jonathan Wakely  2012-06-29 
08:17:21 UTC ---
Ruben, any chance you could test trunk with clang?

I'm not putting untested changes on the 4.6 and 4.7 release branches, so unless
someone tests it on an affected platform and confirms it's fixed then it stays
broken.

[Bug tree-optimization/53802] New: Spurious 'may be used uninitialized' related to shifts

[lukeocamden at gmail dot com]

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

 Bug #: 53802
   Summary: Spurious 'may be used uninitialized' related to shifts
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lukeocam...@gmail.com


Trivial changes in the following program suppress the warning:

inline void foo(const unsigned char* mem_, unsigned int* value_)
{
  unsigned int value = *mem_;
  value <<= 8;
  value |= *++mem_;
  value <<= 8;
  value |= *++mem_;
  value <<= 8;
  value |= *++mem_;
  value <<= 8;
  value |= *++mem_;
  *value_ = value;
}

inline void bar(unsigned char* dest_, unsigned int value_)
{
  if (!value_)
return;
  dest_[0] = 0;
  dest_[1] = value_ >> 24;
  dest_[2] = value_ >> 16;
  dest_[3] = value_ >> 8;
  dest_[4] = value_;
}

int main()
{
  for (unsigned int number = 0x; number; number >>= 1)
  {
unsigned char buf[5];
bar(buf, number);
unsigned int val;
foo(buf, &val);
if (number != val)
  return 0;
  }
}

$ gcc main.cpp -O -Wall
main.cpp: In function 'int main()':
main.cpp:6:19: warning: '*((void*)& buf +1)' may be used uninitialized in this
function [-Wmaybe-uninitialized]
main.cpp:31:19: note: '*((void*)& buf +1)' was declared here
main.cpp:12:19: warning: '*((void*)& buf +4)' may be used uninitialized in this
function [-Wmaybe-uninitialized]
main.cpp:31:19: note: '*((void*)& buf +4)' was declared here
main.cpp:10:19: warning: '*((void*)& buf +3)' may be used uninitialized in this
function [-Wmaybe-uninitialized]
main.cpp:31:19: note: '*((void*)& buf +3)' was declared here
main.cpp:8:19: warning: '*((void*)& buf +2)' may be used uninitialized in this
function [-Wmaybe-uninitialized]
main.cpp:31:19: note: '*((void*)& buf +2)' was declared here

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  2012-06-29 
09:55:43 UTC ---
IIRC recl is an unsigned integer?  I will look further on this one.

[Bug tree-optimization/53802] Spurious 'may be used uninitialized' related to shifts

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-29
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-06-29 
09:57:17 UTC ---
Confirmed.  Reason is a missed "jump-threading" (peeling off one iteration):

:

:
  # number_59 = PHI 
  # buf$2_60 = PHI 
  # buf$3_61 = PHI 
  # buf$4_64 = PHI 
  # buf$1_65 = PHI 
  if (number_59 == 0)
goto ;
  else
goto ;

:
  D.2247_18 = number_59 >> 24;
  buf$1_19 = (unsigned char) D.2247_18;
  D.2245_20 = number_59 >> 16;
  buf$2_21 = (unsigned char) D.2245_20;
  D.2243_22 = number_59 >> 8;
  buf$3_23 = (unsigned char) D.2243_22;
  buf$4_24 = (unsigned char) number_59;

:
  # buf$1_46 = PHI 
  # buf$2_44 = PHI 
  # buf$3_2 = PHI 
  # buf$4_6 = PHI 
  D.2257_29 = (unsigned int) buf$1_46;

so we decide there is a path from entry to BB 5 where buf$1_46 is not
initialized.

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[clivegpage at gmail dot com]

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

--- Comment #4 from Clive Page  2012-06-29 
10:00:02 UTC ---
(In reply to comment #3)
> IIRC recl is an unsigned integer?  I will look further on this one.

But Fortran doesn't have unsigned integers.  If the intention is to indicate no
practical limit, then I guess the value to return is HUGE(0).

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-06-29 
10:07:10 UTC ---
(In reply to comment #4)
> But Fortran doesn't have unsigned integers.  If the intention is to indicate 
> no
> practical limit, then I guess the value to return is HUGE(0).

And we should fill an interpretation request regarding this issue - as
suggested by Richard Maine.

Regarding the limit: I have to admit that I do not understand how
GFORTRAN_DEFAULT_RECL is currently handled. Will it be the true upper bound,
will it be extended etc.?

There is a lot of special code, but that value seems to get only set for
STDIN/STDOUT/STDERR. Additionally, using a special value from the allowed range
askes (in principle) for trouble. Using a negative value internally for special
values might make more sense - though it might require additional conditional
checks (-> slower, potential sources for bugs).

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  2012-06-29 
10:13:13 UTC ---
Yes, I am talking about our internal representation.  I have to go look at the
code detail yet, I am just thinking out loud here on the bug report. It is one
possibility of what we are doing wrong if we set it to the max unsigned value.

There are still other possibilities of whats wrong here.  Give me a day or two.
;)

I believe it gets set in open.c, or it should.

[Bug target/53803] New: --enable-target-optspace gives undefined references to restgpr_*_x

[aldot at gcc dot gnu.org]

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

 Bug #: 53803
   Summary: --enable-target-optspace gives undefined references to
restgpr_*_x
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: al...@gcc.gnu.org
CC: dje@gmail.com, froy...@gcc.gnu.org,
geo...@geoffk.org
Target: powerpc


intermediate compiler (built with -Os) trying to link a userspace program gives

powerpc-oe-linux-uclibc-gcc -m32 -mhard-float -mcpu=603e
powerpc-oe-linux-uclibc/4.7.1/ld: getconf: hidden symbol `_restgpr_31_x' in 
/scratch/obj.x86_64/oe/build/tmp-uclibc/sysroots/x86_64-linux/usr/lib/ppc603e-oe-linux-uclibc.gcc-cross-intermediate/gcc/powerpc-oe-linux-uclibc/4.7.1/libgcc.a(crtresxgpr.o)
is referenced by DSO

Observations:
1) libgcc_s.so is a script: "GROUP ( libgcc_s.so.1 libgcc.a )"
2) There are libcalls emitted into my libc:
$ powerpc-oe-linux-uclibc-gcc  -m32 -mhard-float  -mcpu=603e
--sysroot=/scratch/obj.x86_64/oe/build/tmp-uclibc/sysroots/qemuppc-tcbootstrap
-Wl,-EB -shared -Wl,--warn-common -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro
-Wl,-z,now -Wl,--hash-style=gnu -Wl,-z,defs   -Wl,-init,__uClibc_init 
-Wl,-soname=libc.so.0 -nostdlib -o lib/libuClibc-0.9.34-git.so 
-Wl,--whole-archive libc/libc_so.a -Wl,--no-whole-archive ./lib/interp.os
./lib/ld-uClibc.so.0 ./lib/uclibc_nonshared.a 2>&1 >&1 | sed -e
's/.*uClibc/OBJTREE/'
libc/libc_so.a(fnmatch.os): In function `end_pattern':
OBJTREE/libc/misc/fnmatch/fnmatch_loop.c:1014: undefined reference to
`_restgpr_27_x'
libc/libc_so.a(fnmatch.os): In function `internal_fnmatch':
OBJTREE/libc/misc/fnmatch/fnmatch_loop.c:975: undefined reference to
`_restgpr_16_x'
libc/libc_so.a(fnmatch.os): In function `ext_match':
OBJTREE/libc/misc/fnmatch/fnmatch_loop.c:1189: undefined reference to
`_restgpr_14_x'
libc/libc_so.a(regex.os): In function `postorder':
OBJTREE/libc/misc/regex/regcomp.c:1167: undefined reference to `_restgpr_28_x'
libc/libc_so.a(regex.os): In function `check_dst_limits_calc_pos_1':
OBJTREE/libc/misc/regex/regexec.c:1914: undefined reference to `_restgpr_18_x'
libc/libc_so.a(regex.os): In function `re_node_set_alloc':
OBJTREE/libc/misc/regex/regex_internal.c:885: undefined reference to
`_restgpr_29_x'
libc/libc_so.a(regex.os): In function `duplicate_tree':
OBJTREE/libc/misc/regex/regcomp.c:3779: undefined reference to `_restgpr_26_x'
libc/libc_so.a(regex.os): In function `lower_subexp':
OBJTREE/libc/misc/regex/regcomp.c:1288: undefined reference to `_restgpr_24_x'
libc/libc_so.a(regex.os): In function `free_state':
OBJTREE/libc/misc/regex/regex_internal.c:1499: undefined reference to
`_savegpr_31'
libc/libc_so.a(regex.os): In function `re_string_destruct':
OBJTREE/libc/misc/regex/regex_internal.c:828: undefined reference to
`_restgpr_31_x'
libc/libc_so.a(regex.os): In function `re_dfa_add_node':
OBJTREE/libc/misc/regex/regex_internal.c:1360: undefined reference to
`_restgpr_22_x'
libc/libc_so.a(regex.os): In function `build_wcs_buffer':
OBJTREE/libc/misc/regex/regex_internal.c:257: undefined reference to
`_restgpr_23_x'
libc/libc_so.a(regex.os): In function `build_wcs_upper_buffer':
OBJTREE/libc/misc/regex/regex_internal.c:473: undefined reference to
`_restgpr_21_x'
libc/libc_so.a(regex.os): In function `re_compile_fastmap_iter':
OBJTREE/libc/misc/regex/regcomp.c:397: undefined reference to `_restgpr_17_x'
libc/libc_so.a(regex.os): In function `re_node_set_init_union':
OBJTREE/libc/misc/regex/regex_internal.c:1096: undefined reference to
`_restgpr_25_x'
libc/libc_so.a(regex.os): In function `sift_states_backward':
OBJTREE/libc/misc/regex/regexec.c:1561: undefined reference to `_restgpr_15_x'
libc/libc_so.a(regex.os): In function `expand_bkref_cache':
OBJTREE/libc/misc/regex/regexec.c:3212: undefined reference to `_restgpr_20_x'
libc/libc_so.a(regex.os): In function `re_compile_pattern':
OBJTREE/libc/misc/regex/regcomp.c:233: undefined reference to `_restgpr_30_x'
libc/libc_so.a(wordexp.os): In function `parse_arith':
OBJTREE/libc/misc/wordexp/wordexp.c:751: undefined reference to `_restgpr_19_x'
libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':
OBJTREE/libc/stdio/_fpmaxtostr.c:189: undefined reference to `_savefpr_22'
OBJTREE/libc/stdio/_fpmaxtostr.c:265: undefined reference to `__gcc_qdiv'
OBJTREE/libc/stdio/_fpmaxtostr.c:278: undefined reference to `__gcc_qmul'
OBJTREE/libc/stdio/_fpmaxtostr.c:375: undefined reference to `__gcc_qsub'
OBJTREE/libc/stdio/_fpmaxtostr.c:376: undefined reference to `__gcc_qadd'
OBJTREE/libc/stdio/_fpmaxtostr.c:748: undefined reference to `_restfpr_22_x'
libc/libc_so.a(lldiv.os): In function `lldiv':
OBJTREE/libc/stdlib/lldiv.c:30: undefined reference to `__divdi3'
OBJTREE/libc/stdlib/lldiv.c:31: undefined reference to `__moddi3'
libc

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

[vincenzo.innocente at cern dot ch]

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

--- Comment #4 from vincenzo Innocente  
2012-06-29 10:34:22 UTC ---
take back: (never do two updates at once)
in SOMETHING else committed between
gcc version 4.7.2 20120615 (prerelease) [gcc-4_7-branch revision 188650] (GCC) 
and
gcc-4_7-branch revision 189063

that causes the regression in comment 3

the patch above revision 188650 is ok and does not cause regression

[Bug tree-optimization/53804] New: branch reordering missed optimization

[steven at gcc dot gnu.org]

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

 Bug #: 53804
   Summary: branch reordering missed optimization
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@gcc.gnu.org


Consider this test case:

int
foo1 (int a, int b)
{
  if (a > 0)
return 1;
  else if (b > 0 && a < 0)
return -3;
  return 9;
}

int
foo2 (int a, int b)
{
  if (a > 0)
return 1;
  else if (a < 0 && b > 0)
return -3;
  return 9;
}


Ideally these two functions would be optimized to the same code, because they
are semantically equivalent. The ideal form is foo2 because the result of the
first comparison against "a" can be re-used for the second test, but GCC does
not perform this optimization. The .227r.final dump looks like this on
powerpc64-unknown-linux-gnu (all notes removed for readability):


;; Function foo1 (foo1, funcdef_no=0, decl_uid=1997, cgraph_uid=0)

   11 %7:CC=cmp(%3:SI,0)# r7 = cmp(a,0)
5 %9:DI=0x1# r9 = 1
   12 pc={(%7:CC<=0)?L74:pc}# if (r7 <= 0) goto L74
L20:
   26 %3:DI=%9:DI# r3 = r9
   29 use %3:DI# ..
   64 return# return r3
i  63: barrier
L74:
   14 %7:CC=cmp(%4:SI,0)# r7 = cmp (b,0)
8 %9:DI=0x9# r9 = 9
   15 pc={(%7:CC<=0)?L20:pc}# if (r7 <= 0) goto L20
   53 %9:DI=-%3:DI==0# r9 = -(r3==0)
   54 {%9:DI=%9:DI&0xc;clobber scratch;}# r9 = r9 & 12
   55 %9:DI=%9:DI-0x3# r9 = r9 - 3
   68 %3:DI=%9:DI# r3 = r9
   69 use %3:DI# ..
   70 return# return r3
i  73: barrier

;; Function foo2 (foo2, funcdef_no=1, decl_uid=2001, cgraph_uid=1)

   11 %7:CC=cmp(%3:SI,0)# r7 = cmp(a,0)
   12 pc={(%7:CC<=0)?L57:pc}# if (r7 <= 0) goto L57
5 %3:DI=0x1# r3 = 1
   29 use %3:DI# ..
   56 return# return r3
i  55: barrier
L57:
   14 %7:CC=cmp(%3:DI,0)# r7 = cmp(a,0) // ??? redundant
8 %3:DI=0x9# r3 = 9
   51 use %3:DI# ..
   15 pc={(%7:CC==0)?return:pc}# if (r7 == 0) return r3
   17 %7:CC=cmp(%4:SI,0)# r7 = cmp(b,0)
   52 use %3:DI# ..
   18 pc={(%7:CC<=0)?return:pc}# if (r7 <= 0) return r3
6 %3:DI=0xfffd# r3 = -3
   53 use %3:DI# ..
   54 return# return r3
i  47: barrier


Note how foo1 needs two branches whereas foo2 only needs 1. 
(I'm not sure why there is the redundant compare in foo2:insn 14)

[Bug lto/53768] [4.7 Regression] Undefined references with boost 1.46/1.48/1.49

[vincenzo.innocente at cern dot ch]

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

--- Comment #8 from vincenzo Innocente  
2012-06-29 10:36:46 UTC ---
take back: (never do two updates at once)
in SOMETHING ELSE committed between
gcc version 4.7.2 20120615 (prerelease) [gcc-4_7-branch revision 188650] (GCC) 
and
gcc-4_7-branch revision 189063

that causes the regression in comment 3

the patch above revision 188650 is ok and does not cause regression

[Bug tree-optimization/53804] branch reordering missed optimization

[steven at gcc dot gnu.org]

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

--- Comment #1 from Steven Bosscher  2012-06-29 
10:43:19 UTC ---
On x86_64-unknown-linux-gnu, this case is optimized because the second branch
condition is combined for both foo1 and foo2:

:
  D.1723_4 = b_3(D) > 0;
  D.1724_5 = a_2(D) < 0;
  D.1725_6 = D.1724_5 & D.1723_4;
  if (D.1725_6 != 0)
goto ;
  else
goto ;

=>

foo1:
testl   %edi, %edi
movl$1, %eax
jle .L9
rep
ret
.L9:
shrl$31, %edi
testb   %dil, %dil
jne .L10
.L4:
movl$9, %eax
ret
.L10:
testl   %esi, %esi
jle .L4
movl$-3, %eax
ret


foo2:
testl   %edi, %edi
movl$1, %eax
jle .L18
rep
ret
.L18:
shrl$31, %edi
testb   %dil, %dil
jne .L19
.L14:
movl$9, %eax
ret
.L19:
testl   %esi, %esi
jle .L14
movl$-3, %eax
ret

[Bug lto/53337] 4.7.1 lto produces warning: relocation refers to discarded section in linker (gold, binutil 2.22)

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from vincenzo Innocente  
2012-06-29 10:45:05 UTC ---
get rid of one,  move to 53768

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

[Bug lto/53768] [4.7 Regression] Undefined references with boost 1.46/1.48/1.49

[vincenzo.innocente at cern dot ch]

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

--- Comment #9 from vincenzo Innocente  
2012-06-29 10:45:05 UTC ---
*** Bug 53337 has been marked as a duplicate of this bug. ***

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-06-29 
10:50:48 UTC ---
Candidates are

+2012-06-19  Jason Merrill  
+
+   PR c++/52637
+   * dwarf2out.c (modified_type_die): Use scope_die_for.
+   (gen_type_die_with_usage, dwarf2out_finish): Likewise.
+   (uses_local_type_r, uses_local_type): New.
+   (scope_die_for): Keep a type that uses a local type in local scope.
+   Use get_context_die for namespace and type scope.


+2012-06-19  Richard Guenther  
+
+   PR middle-end/53470
+   * tree.c (free_lang_data_in_type): Do not clear TYPE_CONTEXT but
+   replace it with the first non-BLOCK context.

if you are using -g and all C++ changes.

[Bug libfortran/51119] MATMUL slow for large matrices

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #9 from Steven Bosscher  2012-06-29 
10:55:48 UTC ---
(In reply to comment #7)
> IIRC I reached about 30-40 % of peak
> flops which was a bit disappointing.

This sounds quite impressive to me, actually.

It would be interesting to investigate using the IFUNC mechanism to provide
optimized (e.g. vectorized) versions of some of the library functions.

[Bug tree-optimization/53805] New: combine_comparisons changes trapping behavior

[glisse at gcc dot gnu.org]

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

 Bug #: 53805
   Summary: combine_comparisons changes trapping behavior
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org


Hello,

int f(double a,double b){
  if(a>b) if(a

[Bug lto/53768] [4.7 Regression] Undefined references with boost 1.46/1.48/1.49

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  2012-06-29 11:49:53 
UTC ---
(In reply to comment #8)
> take back: (never do two updates at once)
> in SOMETHING ELSE committed between
> gcc version 4.7.2 20120615 (prerelease) [gcc-4_7-branch revision 188650] 
> (GCC) 
> and
> gcc-4_7-branch revision 189063
> 
> that causes the regression in comment 3
> 

Please open another bug since it also happens with 4.8.

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2012-06-29 
12:01:51 UTC ---
We do not try to preserve traps instead we only try to not produce new ones.

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  2012-06-29 12:19:07 
UTC ---
(In reply to comment #1)
> We do not try to preserve traps instead we only try to not produce new ones.

That would make a lot of sense, and assuming it is the official policy I am
happy to learn that, but then why don't we optimize this testcase:

int f(double a,double b){
  if(a>=b) if(a<=b) return 1;
  return 0;
}

to
  if(a==b) return 1;
?

The test in combine_comparisons seems to deliberately check for any change of
the trapping condition, not just false->true.

I am happy to relabel this bug (or file a new one if you prefer) as a missed
optimization.

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-06-29 
12:22:10 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > We do not try to preserve traps instead we only try to not produce new ones.
> 
> That would make a lot of sense, and assuming it is the official policy I am
> happy to learn that, but then why don't we optimize this testcase:
> 
> int f(double a,double b){
>   if(a>=b) if(a<=b) return 1;
>   return 0;
> }
> 
> to
>   if(a==b) return 1;
> ?

Good question.  I suppose that's a missed optimization then.

> The test in combine_comparisons seems to deliberately check for any change of
> the trapping condition, not just false->true.
> 
> I am happy to relabel this bug (or file a new one if you prefer) as a missed
> optimization.

I'd say open a new one.

[Bug tree-optimization/53806] New: Missed optimization (a<=b)&&(a>=b) with trapping

[glisse at gcc dot gnu.org]

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

 Bug #: 53806
   Summary: Missed optimization (a<=b)&&(a>=b) with trapping
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org


Hello,

int f(double a,double b){
  if(a>=b) if(a<=b) return 1;
  return 0;
}

is optimized to:

  if(a==b) return 1;

only if I specify the flag -fno-trapping-math, not by default.

The test in combine_comparisons checks for any change in trapping behavior,
whereas according to PR tree-optimization/53805 we are allowed to remove traps,
just not add new ones (as would happen with ORD && UNLT -> LT for instance).

[Bug lto/53768] [4.7 Regression] Undefined references with boost 1.46/1.48/1.49

[vincenzo.innocente at cern dot ch]

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

--- Comment #11 from vincenzo Innocente  
2012-06-29 12:43:03 UTC ---
ok.
II think somebody should start building boost and its test-suite  with lto:
many of these regressions are found "thanks" to boost after all… (I will when
they move to cmake).

[Bug tree-optimization/52589] VRP missed optimization

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #3 from Marc Glisse  2012-06-29 12:56:09 
UTC ---
This looks related to bug 30318 and seems to have been fixed by Richard's
recent VRP patches.

[Bug tree-optimization/52589] VRP missed optimization

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2012-06-29 
13:12:15 UTC ---
Indeed.  I'll add the testcase to the testsuite.

[Bug tree-optimization/52589] VRP missed optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-06-29 
13:17:49 UTC ---
Author: rguenth
Date: Fri Jun 29 13:17:44 2012
New Revision: 189073

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189073
Log:
2012-06-29  Richard Guenther  

PR tree-optimization/52589
* gcc.dg/tree-ssa/vrp70.c: New testcase.

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

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

[vincenzo.innocente at cern dot ch]

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

--- Comment #6 from vincenzo Innocente  
2012-06-29 13:20:31 UTC ---
the regression in comment 3 happens with 
gcc version 4.7.2 20120620 (prerelease) [gcc-4_7-branch revision 188811] (GCC) 
(and was a fix required by myself)
will open a new bug report  (btw no -g involved!)
is connected to "sigcpp": will try to reproduce with something small

[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #13 from Richard Guenther  2012-06-29 
13:23:15 UTC ---
(In reply to comment #5)
> Grrr:
> Visiting PHI node: i_3 = PHI ;
> Argument #0 (4 -> 12 executable)
> i_17
> Value: [1, 1]  EQUIVALENCES: { } (0 elements)
> 
> Argument #1 (13 -> 12 executable)
> i_13
> Value: [2, +INF]  EQUIVALENCES: { } (0 elements)
> 
> so we have [1,1] UNION [2, +INF] and we just get ~[0,0] bogus
> and it also means this is PR 23744.

This is now fixed but the rest still applies.

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2012-06-29 
13:29:36 UTC ---
I have now ask at http://j3-fortran.org/pipermail/j3/2012-June/005446.html

[Bug tree-optimization/32759] False "may be used uninitialized" (missed VRP optimization)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Guenther  2012-06-29 
13:39:47 UTC ---
Fixed at -O2 since GCC 4.4.

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Richard Guenther  2012-06-29 
13:45:50 UTC ---
Hmm.  Does

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 189046)
+++ gcc/tree.c  (working copy)
@@ -4852,7 +4852,15 @@ find_decls_types_r (tree *tp, int *ws, v
   fld_worklist_push (TYPE_MAIN_VARIANT (t), fld);
   /* Do not walk TYPE_NEXT_VARIANT.  We do not stream it and thus
  do not and want not to reach unused variants this way.  */
-  fld_worklist_push (TYPE_CONTEXT (t), fld);
+  if (TYPE_CONTEXT (t))
+   {
+ tree ctx = TYPE_CONTEXT (t);
+ /* We adjust BLOCK TYPE_CONTEXTs to the innermost non-BLOCK one.
+So push that instead.  */
+ while (ctx && TREE_CODE (ctx) == BLOCK)
+   ctx = BLOCK_SUPERCONTEXT (ctx);
+ fld_worklist_push (ctx, fld);
+   }
   /* Do not walk TYPE_CANONICAL.  We do not stream it and thus do not
 and want not to reach unused types this way.  */

fix it?

[Bug debug/16063] Debuggers need more information about enum types in C++

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #5 from Tom Tromey  2012-06-29 13:50:49 
UTC ---
DWARF 4 allows this:

The enumeration type entry may have a DW_AT_type attribute which refers to the
underlying
data type used to implement the enumeration.

I think this is definitely needed for "enum class", where the base
type can be specified by the user.
However, emitting it unconditionally wouldn't hurt.

[Bug tree-optimization/37541] VRP fails to optimize single-bit ranges

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-06-29 
13:57:04 UTC ---
Author: rguenth
Date: Fri Jun 29 13:56:51 2012
New Revision: 189075

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189075
Log:
2012-06-29  Richard Guenther  

PR tree-optimization/37541
* gcc.dg/tree-ssa/pr37508.c: Adjust and un-XFAIL.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr37508.c

[Bug tree-optimization/37541] VRP fails to optimize single-bit ranges

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2012-06-29 
13:57:53 UTC ---
Fixed.

[Bug middle-end/40194] fortran rules for optimizing

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #10 from Joost VandeVondele  
2012-06-29 14:14:16 UTC ---
this testcase now looks optimized (at least the optimized dump contains return
1; as expected). I guess this can be closed ?

[Bug tree-optimization/43768] VRP destroys loop form

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2012-06-29 
14:15:10 UTC ---
Indeed it is not.

[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions

[internet at 123gen dot com]

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

--- Comment #12 from Zouzou  2012-06-29 14:16:16 
UTC ---
applying the changes in rev 188646 to a MinGW with GCC 4.7.0 works fine and
doesn't reproduce the problem detailed in bug 46455.

[Bug tree-optimization/43965] Missed VRP and/or jump-threading

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #3 from Richard Guenther  2012-06-29 
14:20:24 UTC ---
More like predicated value-numbering should figure this out.

[Bug middle-end/40282] ICE with -fipa-type-escape

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #3 from Joost VandeVondele  
2012-06-29 14:22:34 UTC ---
ipa-type-escape has long been removed.

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2012-06-29 14:24:18 UTC ---
On Fri, 29 Jun 2012, rguenth at gcc dot gnu.org wrote:

> We do not try to preserve traps instead we only try to not produce new ones.

That's a bug.  -ftrapping-math should do both (as regards the set of 
exceptions raised between function calls or asms that might test them, not 
necessarily preserving the exact positive number of times an exception is 
raised).  If that's thought to be a performance issue maybe it should be 
split into separate options for the two cases.

[Bug tree-optimization/47061] VRP doesn't propagate through x<<=1, but it does for x*=2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2012-06-29 
14:25:38 UTC ---
Fixed by my simple LSHIFT_EXPR handling code.  I'll add the testcases.

[Bug middle-end/41453] use INTENT(out) for optimization

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2012-06-29

--- Comment #1 from Joost VandeVondele  
2012-06-29 14:25:46 UTC ---
still happens on  4.8 trunk

[Bug tree-optimization/47061] VRP doesn't propagate through x<<=1, but it does for x*=2

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-06-29 
14:27:34 UTC ---
Author: rguenth
Date: Fri Jun 29 14:27:24 2012
New Revision: 189076

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189076
Log:
2012-06-29  Richard Guenther  

PR tree-optimization/47061
* gcc.dg/tree-ssa/vrp71.c: New testcase.

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

[Bug libgomp/41737] [omp] missing error for undeclared variable in a parallel region with default(none)

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2012-06-29

--- Comment #3 from Joost VandeVondele  
2012-06-29 14:34:00 UTC ---
simplified testcase, for 4.8:

INTEGER :: ip,np
!$omp parallel do default(none)
  DO ip=0,np
  ENDDO
!$omp end parallel do
END 

while it is OK for ip to have no explicit attribute, I believe the standard
requires one for np. Intel ifort gives:

est.f90(3): error #6752: Since the OpenMP* DEFAULT(NONE) clause applies, the
PRIVATE, SHARED, REDUCTION, FIRSTPRIVATE, or LASTPRIVATE attribute must be
explicitly specified for every variable.   [NP]

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-06-29 
14:34:08 UTC ---
(In reply to comment #4)
> On Fri, 29 Jun 2012, rguenth at gcc dot gnu.org wrote:
> 
> > We do not try to preserve traps instead we only try to not produce new ones.
> 
> That's a bug.  -ftrapping-math should do both (as regards the set of 
> exceptions raised between function calls or asms that might test them, not 
> necessarily preserving the exact positive number of times an exception is 
> raised).  If that's thought to be a performance issue maybe it should be 
> split into separate options for the two cases.

We happily remove dead trapping statements:

void foo(double x, int y)
{
  1 / x;
  1 / y;
}

Eric recently (for the sake of Java) added fdelete-dead-exceptions (in Ada,
with -fnon-call-exceptions, you are allowed to remove the above statements).

We similarly happily remove dead indirect loads (that might trap).

I think it is preferable that we do all this, we can't always reasonably
prove that a path in the CFG is never reached.

[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo

[jamborm at gcc dot gnu.org]

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

--- Comment #65 from Martin Jambor  2012-06-29 
14:34:34 UTC ---
I have posted the patch to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01928.html

along with an equivalent one for the 4.6 branch:

http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01929.html

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  2012-06-29 14:43:30 UTC ---
On Fri, 29 Jun 2012, rguenth at gcc dot gnu.org wrote:

> We happily remove dead trapping statements:
> 
> void foo(double x, int y)
> {
>   1 / x;

Bug with -ftrapping-math.  Maybe a known bug - there are plenty of open 
bugs for ways in which -ftrapping-math -frounding-math fail to implement 
standard C semantics - but a bug.

>   1 / y;

Arguably a bug with -ftrapv (again, the option could reasonably be split 
into different cases), but not otherwise.

[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2012-06-29

--- Comment #4 from Joost VandeVondele  
2012-06-29 14:44:05 UTC ---
on 4.8 this still is not handled optimally. I get

4.3s for: gfortran -O2 -funroll-loops -ftree-vectorize -ffast-math
-march=native 
6.7s for: gfortran -O3 -funroll-loops -ftree-vectorize -ffast-math
-march=native

so more than 50% slowdown going from -O2 to -O3

on

-march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed|2008-01-23 11:27:01 |2012-06-29 11:27:01

--- Comment #15 from Joost VandeVondele  
2012-06-29 14:52:44 UTC ---
no inlining with 4.8 either

[Bug tree-optimization/53805] combine_comparisons changes trapping behavior

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2012-06-29 
14:54:21 UTC ---
(In reply to comment #6)
> On Fri, 29 Jun 2012, rguenth at gcc dot gnu.org wrote:
> 
> > We happily remove dead trapping statements:
> > 
> > void foo(double x, int y)
> > {
> >   1 / x;
> 
> Bug with -ftrapping-math.  Maybe a known bug - there are plenty of open 
> bugs for ways in which -ftrapping-math -frounding-math fail to implement 
> standard C semantics - but a bug.
> 
> >   1 / y;
> 
> Arguably a bug with -ftrapv (again, the option could reasonably be split 
> into different cases), but not otherwise.

All CPUs I know trap for 1 / 0, even in the integer division case.  -ftrapv
is a completely different story - for it we'd even have to preserve

void foo (int x, int y)
{
  x + y;
}

[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1

--- Comment #5 from Richard Guenther  2012-06-29 
15:01:28 UTC ---
The issue is we completely unroll the innermost loop at -O3 -funroll-loops.
We then vectorize the outer loop but have to peel for alignment (and are not
good at seeing we run at most once there).

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

[vincenzo.innocente at cern dot ch]

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

--- Comment #8 from vincenzo Innocente  
2012-06-29 15:03:17 UTC ---
NOT when applied on the top of
gcc version 4.8.0 20120629 (experimental) [trunk revision 189073] (GCC) 
svn diff
Index: gcc/tree.c
===
--- gcc/tree.c(revision 189073)
+++ gcc/tree.c(working copy)
@@ -4910,7 +4910,15 @@
   fld_worklist_push (TYPE_MAIN_VARIANT (t), fld);
   /* Do not walk TYPE_NEXT_VARIANT.  We do not stream it and thus
  do not and want not to reach unused variants this way.  */
-  fld_worklist_push (TYPE_CONTEXT (t), fld);
+  if (TYPE_CONTEXT (t))
+   {
+ tree ctx = TYPE_CONTEXT (t);
+ /* We adjust BLOCK TYPE_CONTEXTs to the innermost non-BLOCK one.
+So push that instead.  */
+ while (ctx && TREE_CODE (ctx) == BLOCK)
+   ctx = BLOCK_SUPERCONTEXT (ctx);
+ fld_worklist_push (ctx, fld);
+   }
   /* Do not walk TYPE_CANONICAL.  We do not stream it and thus do not
  and want not to reach unused types this way.  */

I'll try also with 4.7

did not manage yet to reproduce with simple examples using sigcpp...

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2012-06-29 
15:04:47 UTC ---
Steve Lionel points at the following:

"If an error condition occurs during execution of an INQUIRE statement, all of
the inquiry specier variables become undened, except for variables in the
IOSTAT= and IOMSG= speciers (if any)."

Thus, if the RECL of the connection is larger than huge(kind(recl_var)), one
has to raise an error.

The question is only how the default should be handled. As written, I do not
really understand the current algorithm. Namely, whether we effectively
implement huge(0_int64) by extending the chunks. Or whether we apply a lower
boundary by default.

Additionally, we have the problem that the internal IO descriptor is only of
kind int32 (cf. PR 44292).

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

[vincenzo.innocente at cern dot ch]

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

--- Comment #9 from vincenzo Innocente  
2012-06-29 15:31:12 UTC ---
in any case the "regression" disappear if I declare inline the template methods
in question
  template
+  inline
   bool 
   WorkerT::implDoBegin(EventPrincipal& ep, EventSetup const& c,
CurrentProcessingContext const* cpc) {

etc

so I would suggest not to touch anything until is not understood If it a real
compiler bug or a "user" code mistake…

v.



On 29 Jun, 2012, at 5:03 PM, vincenzo.innocente at cern dot ch wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53780
> 
> --- Comment #8 from vincenzo Innocente  
> 2012-06-29 15:03:17 UTC ---
> NOT when applied on the top of
> gcc version 4.8.0 20120629 (experimental) [trunk revision 189073] (GCC) 
> svn diff
> Index: gcc/tree.c
> ===
> --- gcc/tree.c(revision 189073)
> +++ gcc/tree.c(working copy)
> @@ -4910,7 +4910,15 @@
>   fld_worklist_push (TYPE_MAIN_VARIANT (t), fld);
>   /* Do not walk TYPE_NEXT_VARIANT.  We do not stream it and thus
>  do not and want not to reach unused variants this way.  */
> -  fld_worklist_push (TYPE_CONTEXT (t), fld);
> +  if (TYPE_CONTEXT (t))
> +   {
> + tree ctx = TYPE_CONTEXT (t);
> + /* We adjust BLOCK TYPE_CONTEXTs to the innermost non-BLOCK one.
> +So push that instead.  */
> + while (ctx && TREE_CODE (ctx) == BLOCK)
> +   ctx = BLOCK_SUPERCONTEXT (ctx);
> + fld_worklist_push (ctx, fld);
> +   }
>   /* Do not walk TYPE_CANONICAL.  We do not stream it and thus do not
>  and want not to reach unused types this way.  */
> 
> I'll try also with 4.7
> 
> did not manage yet to reproduce with simple examples using sigcpp...
>

[Bug target/53803] --enable-target-optspace gives undefined references to restgpr_*_x

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Alan Modra  2012-06-29 15:58:57 
UTC ---
In reply to question (1), if you get "hidden symbol _restgpr_31_x ... is
referenced by DSO" then the DSO (libc?) in question has been wrongly built. 
You can not have dynamic save/restore functions, so each shared library or
executable must use local copies of those functions.

In reply to observation (2) and (3), linking with -nostdlib means that you need
to really know what you're doing.  In this case you must link in some object or
static library that provides the save/restore functions if you use them (as in
-Os code), and, yes, linking against libgcc.a should do the trick.

In reply to question (2), it sounds like you need to write some more code, or
link against libgcc.a

In reply to question (3), the restgpr_*_x calls are a variant of the gpr
restore functions that tear down the stack frame and return, in addition to
restoring registers.

[Bug target/53803] --enable-target-optspace gives undefined references to restgpr_*_x

[amodra at gmail dot com]

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

--- Comment #2 from Alan Modra  2012-06-29 16:03:07 
UTC ---
Closed as invalid on the assumption that this is really a uclibc build bug.

[Bug fortran/53801] gfortran warning

[somenath.jalal at gmail dot com]

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

--- Comment #2 from somenath jalal  2012-06-29 
16:18:35 UTC ---
(In reply to comment #1)
> gcc 4.2.1 is really really old.  Please update to
> something much newer.  Try 4.5.4 or newer version.
> Also, note the warning is from ld not gfortran.


Thanks kargl.
I will update the gcc version. And from "ld" means what? That is the point I
did not understand. And importantly ifort is also giving same kind of warning.
Though both compilers giving me correct result when compiled.

ifort warning is

ld: warning: for symbol _matrix_ tentative definition of size 12944 from
/var/folders/uu/uuDNJbYHHwmD3218GxB09U+++TM/-Tmp-//ifort0cULUk.o is is smaller
than the real definition of size 288 from
/var/folders/uu/uuDNJbYHHwmD3218GxB09U+++TM/-Tmp-//ifortJyODzP.o

ifort Version 12.0.3

[Bug fortran/53801] gfortran warning

[somenath.jalal at gmail dot com]

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

--- Comment #3 from somenath jalal  2012-06-29 
16:20:28 UTC ---
Thanks kargl.
I will update the gcc version. And from "ld" means what? That is the point I
did not understand. And importantly ifort is also giving same kind of warning.
Though both compilers giving me correct result when I run the compiled code.

ifort warning is

ld: warning: for symbol _matrix_ tentative definition of size 12944 from
/var/folders/uu/uuDNJbYHHwmD3218GxB09U+++TM/-Tmp-//ifort0cULUk.o is is smaller
than the real definition of size 288 from
/var/folders/uu/uuDNJbYHHwmD3218GxB09U+++TM/-Tmp-//ifortJyODzP.o

ifort Version 12.0.3

[Bug fortran/45159] Unnecessary temporaries

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #24 from Mikael Morin  2012-06-29 
17:21:13 UTC ---
Anything left to be done?

[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #28 from Mikael Morin  2012-06-29 
17:31:19 UTC ---
Can this be closed?

[Bug tree-optimization/53807] New: FAIL: gcc.dg/vect/bb-slp-11.c scan-tree-dump-times slp "basic block vectorized using SLP" 1

[Greta.Yorsh at arm dot com]

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

 Bug #: 53807
   Summary: FAIL: gcc.dg/vect/bb-slp-11.c scan-tree-dump-times slp
"basic block vectorized using SLP" 1
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: greta.yo...@arm.com
CC: rguent...@suse.de
Target: arm-none-eabi


The test gcc.dg/vect/bb-slp-11.c fails to vectorize the basic block on
arm-none-eabi.

Caused by trunk r189012, which was fixing this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53774

./cc1 -D__USES_INITFINI__ /work/bisect/bb-slp-11.i -quiet -dumpbase bb-slp-11.c
-mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon -auxbase-strip ./bb-slp-11.s -O2
-fno-diagnostics-show-caret -ffast-math -ftree-vectorize -fno-vect-cost-model
-fno-common -fdump-tree-slp-details -o ./bb-slp-11.s

[Bug fortran/47844] Array stride ignored for pointer-valued function results

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mikael at gcc dot gnu.org
 Resolution||FIXED

--- Comment #12 from Mikael Morin  2012-06-29 
18:08:42 UTC ---
(In reply to comment #11)
> Is this fixed now?
> 
> From the comments, it seems that we can close this.

I assume we can. At least the original problem, comment #2 and #3 work fine
now.

[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin  2012-06-29 
18:19:56 UTC ---
Fixed?

[Bug lto/53808] New: Undefined symbol when building a library with lto

[rafael.espindola at gmail dot com]

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

 Bug #: 53808
   Summary: Undefined symbol when building a library with lto
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rafael.espind...@gmail.com


The gcc lto plugin can drop a symbol that another translation unit has an
undefined reference to.

This might also be a bug in gcc (>= 4.6, with and without lto) producing an
undefined reference, the ABI is not very clear.

$ cat test.h
struct foo {
 virtual ~foo();
};
struct bar : public foo {
 virtual void zed();
};
$ cat def.cpp
#include "test.h"
void bar::zed() {
}
$ cat undef.cpp
#include "test.h"
void f() {
 foo *x(new bar);
 delete x;
}

Compile with:

$ ~/gcc/build/gcc/xgcc -B ~/gcc/build/gcc/ -c undef.cpp -o undef.o -O3 -fPIC
$ nm undef.o | grep D0
U _ZN3barD0Ev

$ ~/gcc/build/gcc/xgcc -B ~/gcc/build/gcc/ -c def.cpp -o def.o -O3 -flto -fPIC
$ ~/gcc/build/gcc/xgcc -B ~/gcc/build/gcc/ def.o -o def.so -shared
-fuse-linker-plugin
$ readelf  -sDW def.so | grep bar
  12   7: 0931 5 OBJECT  WEAK   DEFAULT  13 _ZTS3bar
  11  10: 1ca040 OBJECT  WEAK   DEFAULT  24 _ZTV3bar
  13  14: 1cd024 OBJECT  WEAK   DEFAULT  24 _ZTI3bar
   8  15: 08b010 FUNCGLOBAL DEFAULT  11 _ZN3bar3zedEv


Note that we have the vtable, but no the destructor.

$ g++ -shared -o foo.so undef.o def.so -Wl,-z,defs
undef.o:undef.cpp:function f(): error: undefined reference to 'bar::~bar()'

[Bug libgomp/41737] [omp] missing error for undeclared variable in a parallel region with default(none)

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Joost VandeVondele  
2012-06-29 18:46:13 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46532

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

[Bug fortran/46532] [OMP] missing error for loop bounds missing an attribute

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #2 from Joost VandeVondele  
2012-06-29 18:46:13 UTC ---
*** Bug 41737 has been marked as a duplicate of this bug. ***

[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers

[matt at use dot net]

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

--- Comment #6 from Matt Hargett  2012-06-29 18:49:35 UTC 
---
Pinging on this again since this patch has been back ported to a couple of
4.6-based branches now. Anyone attempting to use a recent cloog release with
GCC 4.6 will run into this problem. It is incredibly low-risk in an of itself,
and I can verify that it works with both latest cloog and the previous release.

[Bug c++/53809] New: ice then Abort

[dcb314 at hotmail dot com]

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

 Bug #: 53809
   Summary: ice then Abort
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


I just tried to compile the package fife-0.3.3r3-1
on gcc-4.8 trunk dated 20120627 on an AMD x86_64 box.

The compiler said

bug79.cc:234229:1: internal compiler error: Aborted
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flags -g -O2 required.

[Bug c++/53809] ice then Abort

[dcb314 at hotmail dot com]

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

--- Comment #1 from dcb  2012-06-29 19:04:08 UTC ---
Created attachment 27717
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27717
gzipped C++ source code

[Bug c++/53809] ice then Abort

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-06-29
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2012-06-29 19:35:37 
UTC ---
This may be a dup of PR 53706.  Please try revision 189037 or newer.

[Bug c++/53810] New: template class static not defined

[ajrobb57 at gmail dot com]

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

 Bug #: 53810
   Summary: template class static not defined
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ajrob...@gmail.com


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure
--srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C
--datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v
--with-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static
--enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld
--with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava
--program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada
--enable-threads=posix --with-arch=i686 --with-tune=generic
--enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4
CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind
--with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.5.3 (GCC)





class Class {
public:
  static int const _n = n;
  int simple() const {
return _n;
  }
  int const & complex() const {
return _n;
  }
};

int main() {
  Class<4> const & obj = Class<4>();
#if 1
  // fail
  return obj.complex();
#else
  // OK
  return obj.simple();
#endif
}


$ g++ -Wall -Wextra template.cpp -o template
/tmp/ccxosym6.o:template.cpp:(.text$_ZNK5ClassILi4EE7complexEv[Class<4>::complex()
const]+0x4): undefined reference to `Class<4>::_n'
collect2: ld returned 1 exit status

[Bug c++/53810] template class static not defined

[ajrobb57 at gmail dot com]

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

--- Comment #1 from Andrew Robb  2012-06-29 20:41:08 
UTC ---
template < int n >
class Class {

[Bug c++/53811] New: ICE: in insn_default_length, at config/i386/i386.md:529 (unrecognizable insn) with -mcmodel=large

[tobias.han at gmx dot de]

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

 Bug #: 53811
   Summary: ICE: in insn_default_length, at
config/i386/i386.md:529 (unrecognizable insn) with
-mcmodel=large
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tobias@gmx.de
  Host: amd64
Target: x86_64-linux-gnu


I get this ICE with the Debian gcc revision 4.7.0-8.

g++ -I../Engine -I../Common -I../Common/libinclude -mcmodel=large
-DTHIS_IS_THE_ENGINE -DLINUX_VERSION -c -o ac.o ac.cpp

ac.cpp:29287:1: error: unrecognizable insn:
(call_insn/j 3 2 4 (call (mem:QI (symbol_ref:DI ("*.LTHUNK0") [flags 0x3]
) [0 S1 A8])
(const_int 0 [0])) -1
 (nil)
(nil))
ac.cpp:29287:1: internal compiler error: in insn_default_length, at
config/i386/i386.md:529
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccpP8zhz.out file, please attach this to
your bugreport.

[Bug c++/53811] ICE: in insn_default_length, at config/i386/i386.md:529 (unrecognizable insn) with -mcmodel=large

[tobias.han at gmx dot de]

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

--- Comment #1 from Tobias Hansen  2012-06-29 
21:32:47 UTC ---
Created attachment 27718
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27718
preprocessed source

[Bug fortran/45159] Unnecessary temporaries

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  
2012-06-29 21:44:56 UTC ---
> Anything left to be done?

I see

[macbook] f90/bug% gfc -Warray-temporaries pr45159_4_red.f90
pr45159_4_red.f90:7.15:

  a(-3:9:3) =  a(-6:18:6)
   1
Warning: Creating array temporary at (1)

which is an instance of

l_startmax(0,l_stride)

(see comment #19) for which there is no dependency.

[Bug c++/53810] template class static not defined

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-06-29 
22:01:07 UTC ---
GCC is having the correct behavior.  You don't have a definition for the static
const class variable, only the declaration.  You need the definition as you
implictly take the address of the variable (via a reference).

[Bug c++/53812] New: lower_stmt (4.6), verify_gimple_stmt (4.7.0, 4.7.1)

[0ezpz0 at gmail dot com]

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

 Bug #: 53812
   Summary: lower_stmt (4.6), verify_gimple_stmt (4.7.0, 4.7.1)
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 0ez...@gmail.com


Created attachment 27719
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27719
preprocessed source

The attached code causes internal compiler error for 4.6.3, 4.7.0, and 4.7.1.
Same reported location as #53356 but happening in 4.7.1. 

I was unable to reduce to a smaller example that would still expose the
problem.

Here is the full output of g++ -v -save-temps (for g++-4.7.1)


Using built-in specs.
COLLECT_GCC=g++-4.7.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.7.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -E -quiet -v
-D_GNU_SOURCE t.cc -mtune=generic -march=x86-64 -fpch-preprocess -o t.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -fpreprocessed
t.ii -quiet -dumpbase t.cc -mtune=generic -march=x86-64 -auxbase t -version -o
t.s
GNU C++ (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 5.0.5, MPFR version 3.1.0, MPC
version 0.9
warning: GMP header version 5.0.5 differs from library version 5.0.2.
warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 5.0.5, MPFR version 3.1.0, MPC
version 0.9
warning: GMP header version 5.0.5 differs from library version 5.0.2.
warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a7151d2778777271784da9f36a49699e
t.cc: In member function ‘long int Processor::execute(Program&)’:
t.cc:41:10: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4258
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/53539] Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  2012-06-29 
22:21:35 UTC ---
Author: hjl
Date: Fri Jun 29 22:21:30 2012
New Revision: 189085

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189085
Log:
Use int for WCHAR_TYPE only for TARGET_LP64

PR target/53539
* config/i386/gnu-user64.h (WCHAR_TYPE): Use "int" only for
TARGET_LP64.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/gnu-user64.h

[Bug middle-end/53813] New: [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:2016

[danglin at gcc dot gnu.org]

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

 Bug #: 53813
   Summary: [4.7 Regression] ICE in fold_convert_loc, at
fold-const.c:2016
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11


spawn /mnt/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/mnt/gnu/gcc/objdir/./gcc
-
nostdinc++ -L/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/nowhere/hppa64-hp-hpux
11.11/bin/ -B/nowhere/hppa64-hp-hpux11.11/lib/ -isystem
/nowhere/hppa64-hp-hpux1
1.11/include -isystem /nowhere/hppa64-hp-hpux11.11/sys-include
-B/mnt/gnu/gcc/ob
jdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT
-fmes
sage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR="." 
-nostdinc++
-I/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I
/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/mnt/gnu/gcc/gcc/libstdc++-v3/include/
backward -I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/mnt/gnu/gcc/gcc/libstdc
++-v3/testsuite/20_util/tuple/creation_functions/tuple_cat.cc -std=gnu++0x
./libtestc++.a -lm -o
./tuple_cat.exe/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/tuple/creation_functions/tuple_cat.cc:
In function 'int
main()':/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/tuple/creation_functions/tuple_cat.cc:131:1:
internal compiler error: in fold_convert_loc, at fold-const.c:2016

-bash-3.2$ ../../../gcc/xgcc -B../../../gcc/ -v
Reading specs from ../../../gcc/specs
COLLECT_GCC=../../../gcc/xgcc
COLLECT_LTO_WRAPPER=../../../gcc/lto-wrapper
Target: hppa64-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/nowhere --build=hppa64-hp-hpux11.11 --enable-threads=posix
--disable-nls --with-gmp=/opt/gnu64/gcc/gmp
--enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.7.2 20120629 (prerelease) [gcc-4_7-branch revision 189060] (GCC)

[Bug middle-end/53813] [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:2016

[dave.anglin at bell dot net]

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

--- Comment #1 from dave.anglin at bell dot net 2012-06-29 23:17:13 UTC ---
Attached preprocessed source.

--
John David Anglindave.ang...@bell.net

[Bug c++/53814] New: FAIL: g++.dg/cpp0x/nullptr28.C -std=c++11 execution test

[danglin at gcc dot gnu.org]

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

 Bug #: 53814
   Summary: FAIL: g++.dg/cpp0x/nullptr28.C -std=c++11 execution
test
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11


Executing on host: /mnt/gnu/gcc/objdir-test/gcc/testsuite/g++/../../g++
-B/mnt/g
nu/gcc/objdir-test/gcc/testsuite/g++/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/nullptr28.C   -nostdinc++
-I/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/mnt/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++11 
-pedantic-errors -Wno-long-long   
-L/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs 
-B/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs 
-L/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs  -lm  
-o ./nullptr28.exe(timeout = 300)
spawn /mnt/gnu/gcc/objdir-test/gcc/testsuite/g++/../../g++
-B/mnt/gnu/gcc/objdir-test/gcc/testsuite/g++/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/nullptr28.C -nostdinc++
-I/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/mnt/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++11
-pedantic-errors -Wno-long-long
-L/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-B/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -lm -o
./nullptr28.exe
PASS: g++.dg/cpp0x/nullptr28.C -std=c++11 (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/mnt/gnu/gcc/objdir/gcc:.:/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/mnt/gnu/gcc/objdir-test/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/mnt/gnu/gcc/objdir/gcc
spawn [open ...]
FAIL: g++.dg/cpp0x/nullptr28.C -std=c++11 execution test

# ../../../gcc/xgcc -B../../../gcc/ -v
Reading specs from ../../../gcc/specs
COLLECT_GCC=../../../gcc/xgcc
COLLECT_LTO_WRAPPER=../../../gcc/lto-wrapper
Target: hppa64-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/nowhere --build=hppa64-hp-hpux11.11 --enable-threads=posix
--disable-nls --with-gmp=/opt/gnu64/gcc/gmp
--enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.7.2 20120629 (prerelease) [gcc-4_7-branch revision 189060] (GCC)

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  2012-06-29 
23:43:23 UTC ---
We have more then one thing to fix here.

Try this variation:

integer(kind=8) :: s, r
open(unit=1, file='testsize.f90', status='old', recl=500)
inquire(unit=1, size=s, recl=r)
print *, 'size=', s, ' recl=', r
end

I will continue dabbling with this while we wait for the Comment #7 response.

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  2012-06-30 
00:32:29 UTC ---
For completeness, in the case I give in Comment #9, I get

Operating system error: Cannot allocate memory
Memory allocation failed

I have instrumented a few places to see what we are getting with the original
test case included here:

integer(kind=8) :: s, r
open(unit=1, file='testsize.f90', status='old')
inquire(unit=1, size=s, recl=r)
print *, 'size=', s, ' recl=', r
end

And I get:

$ ./a.out 
In init_units()
max_offset set to 4294967295
In newunit(): 4294967295
Ping! recl=4294967295
 size=  135  recl=   -1

This confirms that we are setting the unit recl to a large number which is
printed as -1 when using signed output, but unsigned is what we might expect.

max_offset is calculated at run time as follows:

  /* Calculate the maximum file offset in a portable manner.
 max will be the largest signed number for the type gfc_offset.
 set a 1 in the LSB and keep a running sum, stopping at MSB-1 bit.  */
  max_offset = 0;
  for (i = 0; i < sizeof (max_offset) * 8 - 1; i++)
max_offset = max_offset + ((gfc_offset) 1 << i);
  printf("max_offset set to %u\n", max_offset);

I think we can decide what to do differently after we get Comment #7 feedback.

In the meantime, I will be looking at what we are doing wrong in the case of
Comment #9, maybe a separate bug.

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  2012-06-30 
01:35:12 UTC ---
Maybe a new PR for this is in order.

gdb output with test case in Comment #9

(gdb) 
634  if (flags->form == FORM_FORMATTED)
(gdb) 
636  if ((opp->common.flags & IOPARM_OPEN_HAS_RECL_IN))
(gdb) 
637fbuf_init (u, u->recl);
(gdb) 
_gfortrani_fbuf_init (u=u@entry=0x6eea60, len=-1)
at ../../../trunk/libgfortran/io/fbuf.c:38
38{
(gdb) 
39  if (len == 0)
(gdb) 
38{
(gdb) 
39  if (len == 0)
(gdb) 
42  u->fbuf = xmalloc (sizeof (struct fbuf));
(gdb) 
_gfortrani_xmalloc (n=n@entry=24)
at ../../../trunk/libgfortran/runtime/memory.c:33
33{
(gdb) 

I need to peak at u-recl to see what it is here.
37n = 1;
(gdb) 
39  p = malloc (n);
(gdb) 
41  if (p == NULL)
(gdb) 
45}
(gdb) 
_gfortrani_fbuf_init (u=u@entry=0x6eea60, len=-1)
at ../../../trunk/libgfortran/io/fbuf.c:43
43  u->fbuf->buf = xmalloc (len);
(gdb) 
42  u->fbuf = xmalloc (sizeof (struct fbuf));
(gdb) 
43  u->fbuf->buf = xmalloc (len);
(gdb) 
_gfortrani_xmalloc (n=n@entry=18446744073709551615)
at ../../../trunk/libgfortran/runtime/memory.c:33
33{
(gdb) 
37n = 1;
(gdb) 
39  p = malloc (n);
(gdb) 
41  if (p == NULL)
(gdb) 
42os_error ("Memory allocation failed");
(gdb) 
_gfortrani_os_error (message=message@entry=0x4b6a6d "Memory allocation failed")
at ../../../trunk/libgfortran/runtime/error.c:294
294{
(gdb)

[Bug c++/53815] New: Explicit specialization of member enumeration of a class template

[potswa at mac dot com]

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

 Bug #: 53815
   Summary: Explicit specialization of member enumeration of a
class template
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com


C++11 quietly added a bullet point to the middle of the list of things that can
be explicitly specialized (14.7.3/1 [templ.expl.spec]):

  - member enumeration of a class template

So, this should compile:

template  struct Foo
{
int getX(x *p) { return(0); }
enum E12 { a };
};

template <> int Foo::getX(int*)
{
return(-15);
}

template <> enum Foo::E12
{
a, b, c
};

It fails with "redeclaration of ‘Foo::E12 Foo::a’". Deleting "a" from
the primary template results in "enumerator value 2 is too large for underlying
type ‘unsigned int’". Adding an explicit underlying type of "int" to the
specialization results in "underlying type mismatch in enum ‘enum
Foo::E12’".

Then, adding the same underlying type to the primary template results in
successful compilation. The enumerators of the specialization can be accessed
from outside the class scope, but the enumerators of the hidden primary
template are visible as well.

The feature is rather bizarre, IMHO. This was caught by a StackOverflow user,
although it's not clear he's even aware of C++11 but may have just always
expected it to be legal. http://stackoverflow.com/q/11271553/153285

[Bug c++/53810] template class static not defined

[ajrobb57 at gmail dot com]

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

--- Comment #3 from Andrew Robb  2012-06-30 06:23:28 
UTC ---
template<  int n>
class Class {
public:
   static int const _n = n;



I thought that _n was defined.



On 29/06/2012 23:01, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53810
>
> --- Comment #2 from Andrew Pinski  2012-06-29 
> 22:01:07 UTC ---
> GCC is having the correct behavior.  You don't have a definition for the 
> static
> const class variable, only the declaration.  You need the definition as you
> implictly take the address of the variable (via a reference).
>

[Bug c++/53816] New: internal compiler error: tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6419, with -std=c++11 option

[ai.azuma at gmail dot com]

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

 Bug #: 53816
   Summary: internal compiler error: tree check: expected
field_decl, have identifier_node in
fixed_type_or_null, at cp/class.c:6419, with
-std=c++11 option
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com


Created attachment 27721
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27721
preprocessed source file

The attached code looks innocent but causes ICE with GCC 4.8.0 20120624
(experimental) and `-std=c++11' option, although it doesn't rely on any C++11
feature. And without `-std=c++11' option, it successfully compiles.

Note that the attached code successfully compiles with GCC 4.6.4 20120622
(prerelease) and 4.7.2 20120623 (prerelease), regardless of whether
`-std=c++0x' option is used.

[Bug c++/53816] internal compiler error: tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6419, with -std=c++11 option

[ai.azuma at gmail dot com]

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

--- Comment #1 from Ai Azuma  2012-06-30 06:34:40 
UTC ---
Created attachment 27722
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27722
Output of -v option