[Bug fortran/49296] New: [4.6/4.7 Regression] Wrong I/O END OF FILE

[burnus at gcc dot gnu.org]

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

   Summary: [4.6/4.7 Regression] Wrong I/O END OF FILE
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org


Reported by Reinhold Bader (LRZ). The following program prints with gfortran
4.5 (and ifort 11, NAG 5.1, g95, pathf95):
 OK

With gfortran 4.6/4.7, it prints:

At line 11 of file read_listdir_01_pos.f90 (unit = 20, file = 'read.dat')
Fortran runtime error: End of file


- C part of the test program ---

#include stdio.h

void genfil() {
FILE *fp;

fp = fopen(read.dat, w+);
fprintf(fp, abcd efgh);
fclose(fp);
}


- Fortran part of the test program ---

program read_listdir_01_pos
  implicit none
  integer, parameter :: strmx = 255
  character(len=strmx) :: s1, s2
  interface
 subroutine genfil() bind(c)
 end subroutine genfil
  end interface
  call genfil()
  open(unit=20, file='read.dat', form='FORMATTED', action='READ', status='OLD')
  read(20, fmt=*) s1, s2
  if (trim(s1) == abcd .and. trim(s2) == efgh) then
 write(*, *) 'OK'
  else
 write(*, *) 'FAIL'
  end if
  close(20)
end program read_listdir_01_pos

[Bug fortran/49296] [4.6/4.7 Regression] Wrong I/O END OF FILE

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.5.0
   Target Milestone|--- |4.6.1
  Known to fail||4.6.0, 4.7.0

[Bug libstdc++/49293] 22_locale/time_get/get_weekday/char/38081-[12].cc fail with glibc 2.14

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
06:17:14 UTC ---
Yeah, the locale changed:
http://sources.redhat.com/git/?p=glibc.git;a=commitdiff;h=f49839299a085505eb673544744b61d2d9cdd1db
I think it is a mistake to use variable length abmon, especially if some abmon
names are 5 characters long which isn't really abbreviation anymore, and to add
a useless dot to make it even longer, but ru_RU isn't the first locale to make
such a change.

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

[revital.eres at linaro dot org]

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

revital.eres at linaro dot org changed:

   What|Removed |Added

 CC||revital.eres at linaro dot
   ||org

--- Comment #9 from revital.eres at linaro dot org 2011-06-06 06:28:53 UTC ---
(In reply to comment #8)
 Is there any reason (beside reviewing) for not having committed the patch in
 http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01175.html ?

My recent patchs for SMS (i.e.,
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01341.html), which are not
approved yet, require some adjustments for this testsuite patch. So that's why
I thought it will be better to wait for a approval for the new patches before
pinging for the testsuite patch, avoiding the need to submit a follow-up fix
for it. Also, currently trunk bootstrap is broken on ARM with SMS flags and I'm
trying to figure out the problem... so once I'll locate this problem I'll go
back to these patches and push them forward to trunk.

[Bug fortran/49297] New: Errors during execution of make command when installing molcas7.6

[shekhar88 at chem dot iitb.ac.in]

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

   Summary: Errors during execution of make command when
installing molcas7.6
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shekha...@chem.iitb.ac.in


Dear Sir,

The errors during the installation of molcas7.6 are given below. Kindly, solve
these problems.


fmm_aux_qlm_builder.f90: In function 'get_rhs_data':
fmm_aux_qlm_builder.f90:154: internal compiler error: in
gfc_conv_component_ref, at fortran/trans-expr.c:268
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
gmake[2]: *** [fmm_aux_qlm_builder.o] Error 1
gmake[1]: *** [.stamp] Error 2
make: *** [fmm_util] Error 2


with regards,
Shekhar Hansda
Ph.D Student
IIT-Bombay

[Bug fortran/49297] ICE gfc_conv_component_ref, at fortran/trans-expr.c:268 when compiling molcas7.6

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
Summary|Errors during execution of  |ICE gfc_conv_component_ref,
   |make command when   |at fortran/trans-expr.c:268
   |installing molcas7.6|when compiling molcas7.6

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-06 
07:54:23 UTC ---
It might get a bit difficult to debug this issue as MOLCAS
(http://www.molcas.org/) is not freely downloadable but commercial.

Which version of gfortran are you using (cf. gfortran -v)?

The bug looks similar to PR 18783 or PR 15181, which were fixed in 4.0.0
(before 2004-11-29 - 7 years and 7 releases ago).

In case you have GCC/gfortran 4.0: I strongly urge you to upgrade. 4.0 was the
first GCC version with gfortran and it was rather buggy. You should at least
use GCC/gfortran 4.1.2 but better 4.3 or newer. Recommended released versions
are 4.5 or 4.6 - or the developer version 4.7, which is typically also quite
stable.

An overview about the latest releases and the currently maintained version is
given at http://gcc.gnu.org/ (right column)

There could (should?) be newer GCCs available from your Linux distribution
(assuming you are using Linux), but you could also try the build listed at
http://gcc.gnu.org/wiki/GFortranBinaries


If the internal compiler error still occurs with a newer GCC version, we can
still start the tedious debugging work.

[Bug fortran/49278] internal compiler error: Segmentation fault

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-06 
08:22:53 UTC ---
(In reply to comment #2)
 The following aborts.  Note sure if it is conforming.

* ifort (also w/ -stand f03 -warn all) and PGI accept it - and have the
expected value

* NAG 5.1 and g95 have %d == 0, i.e. the explicit DATA initialization prevents
the default initialization of trlkold.

* pathf95/openf95/crayftn/sunf95 reject the DATA because there is a default
initialization


It's actually a difficult to see whether it is invalid or not. However, I think
the code is valid (taking the side of NAG and g95): One does not do any double
initialization. From the F2008 standard:

If a nonpointer object has default initialization, it shall not appear in a
data-stmt-object-list. (5.4.7 DATA statement) -- Does not seem to apply as
trlkold%v is not default initialized.

5.2.3 Initialization:
Explicit initialization alternatively may be specified in a DATA statement
unless the variable is of a derived type for which default initialization is
specified. -- Ditto.
A variable, or part of a variable, shall not be explicitly initialized more
than once in a program. -- Also this is not violated.


Hence, it seems to be valid, but I wouldn't mind if someone could cross check,
given that most compilers don't generate the expected result - and given that
reading the standard can be difficult. [Even J3/WG5 members might read it
differently.]

[Bug libfortran/48906] Wrong rounding results with -m32

[thenlich at users dot sourceforge.net]

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

--- Comment #24 from Thomas Henlich thenlich at users dot sourceforge.net 
2011-06-06 08:38:13 UTC ---
(In reply to comment #23)
 Patch submitted to list for approval.

For a scale factor 0, we are done. Good work, thank you!

A scale factor != 0 does not work yet, you wrote you are still working on it,
is that correct?

print (-2pg12.3), 0.02 ! 0.200E-01 expected 0.002E+01
print (-1pg12.3), 0.02 ! 0.200E-01 expected 0.020E+00
print (0pg12.3), 0.02 ! 0.200E-01
print (1pg12.3), 0.02 ! 0.200E-01 expected 2.000E-02
print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03

--- gcc/testsuite/gfortran.dg/pr20755.f(revision 174320)
+++ gcc/testsuite/gfortran.dg/pr20755.f(working copy)
@@ -5,8 +5,8 @@
   character*30 s

   write (s,2000) 0.0, 0.02
-  if (s .ne. 0.00   2.000E-02) call abort
+  if (s .ne. 0.00   0.200E-01) call abort
   write (s,2000) 0.01, 0.02
-  if (s .ne.1.000E-02   2.000E-02) call abort
+  if (s .ne.0.100E-01   0.200E-01) call abort
  2000 format (1PG12.3,G12.3)
   end

I don't agree with the changes to this testcase, since the scale factor does
not work yet, and the test was correct before.

--- gcc/testsuite/gfortran.dg/fmt_g0_6.f08(revision 174320)
+++ gcc/testsuite/gfortran.dg/fmt_g0_6.f08(working copy)
@@ -57,7 +57,7 @@ contains
 do dec = d, 0, -1
 lower = 10.0_RT ** (d - 1 - dec) - r * 10.0_RT ** (- dec - 1)
 upper = 10.0_RT ** (d - dec) - r * 10.0_RT ** (- dec)
-if (lower = mag .and. mag  upper) then
+if (lower  mag .and. mag = upper) then
 write(fmt_f, ('R', a, ',F', i0, '.', i0, ',', i0, 'X'))
roundmode, w - n, dec, n
 exit
 end if

I don't agree with this change, since it was according to the Fortran standard
before (it does not actually make a difference for the values we currently
check in this test, though.)

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
08:43:00 UTC ---
(In reply to comment #5)
 (In reply to comment #4)
 
  Attached patch also includes my pathetic attempt to implement
  ix86_expand_convert_sign_disf_sse, but surely would need some help here...
 
 Let's ask the author of SSE expanders.

It was me? ;)  I think it was the other Richard.

But anyway, ix86_expand_convert_sign_disf_sse doesn't look correct for
signed numbers.  I think we should try to come up with a bit-fiddling
implementation instead, check to what the soft-fp code expands to.

[Bug lto/49277] [4.7 Regression] 456.hmmer in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.06 08:47:54
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
08:47:54 UTC ---
Mine.

[Bug debug/49294] [4.7 Regression] ICE: in mem_loc_descriptor, at dwarf2out.c:14636 with -O -g

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
08:49:54 UTC ---
Created attachment 24441
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24441
gcc47-pr49294.patch

Untested fix.

[Bug tree-optimization/41012] Missing inlining after indirect call promotion

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
08:54:39 UTC ---
(In reply to comment #2)
 Richi,
 was the pointer type in call statement issues solved for 4.7?  If so, we could
 probably resolve this as fixed.

Yes indeed, we preserve the original call stmts type for expansion in 4.7.

[Bug c++/49298] New: c++0x regression: sorry, unimplemented: unexpected ast of kind field_decl

[tim at klingt dot org]

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

   Summary: c++0x regression: sorry, unimplemented: unexpected ast
of kind field_decl
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@klingt.org
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu


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

using a boost.intrusive header with c++0x support, gcc-4.6 stops with the
following error. the same code compiles fine with gcc-4.5 and without c++0x
support


/usr/include/boost/intrusive/list.hpp: In static member function ‘static
boost::intrusive::list_implConfig
boost::intrusive::list_implConfig::priv_container_from_end_iterator(const
const_iterator)’:
/usr/include/boost/intrusive/list.hpp:1274:88: sorry, unimplemented: unexpected
ast of kind field_decl
/usr/include/boost/intrusive/list.hpp:1274: confused by earlier errors, bailing
out

g++ -v:
Using built-in specs.
COLLECT_GCC=g++
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='Ubuntu 4.6.0-3~ppa1'
--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 --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror
--with-arch-32=i686 --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 20110409 (prerelease) (Ubuntu 4.6.0-3~ppa1)

[Bug c/49295] math-68881.h definiton of scalb doesn't match builtin

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

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

Andreas Schwab sch...@linux-m68k.org changed:

   What|Removed |Added

 Target||m68k-*-*

--- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-06-06 08:59:33 
UTC ---
math-68881.h is obsolete and should not be used any more.  See also bug 47672.

[Bug target/42210] avr: optimizing assignment to a bit field

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-06 
09:00:41 UTC ---
Author: gjl
Date: Mon Jun  6 09:00:36 2011
New Revision: 174685

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174685
Log:
PR target/42210
* config/avr/predicates.md (const1_operand, const_0_to_7_operand):
New predicates.
* config/avr/avr.md (insv): New insn expander.
(*movbitqi.1-6.a, *movbitqi.1-6.b, *movbitqi.0, *insv.io,
*insv.not.io, *insv.reg): New insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/predicates.md

[Bug target/47672] math-68881.h does not support C99

[alanh at fairlite dot co.uk]

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

Alan Hourihane alanh at fairlite dot co.uk changed:

   What|Removed |Added

 CC||alanh at fairlite dot co.uk

--- Comment #3 from Alan Hourihane alanh at fairlite dot co.uk 2011-06-06 
09:02:59 UTC ---
Should math-68881.h be part of a OS's libc/libm then ?

[Bug c++/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
  Known to work||4.4.6
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
Summary|Optimization incorrectly|[4.5/4.6/4.7 Regression]
   |presuming constant variable |Optimization incorrectly
   |inside loop in g++ 4.5 and  |presuming constant variable
   |4.6 with -O2 and -O3 for|inside loop in g++ 4.5 and
   |x86_64 targets  |4.6 with -O2 and -O3 for
   ||x86_64 targets
  Known to fail||4.5.4, 4.6.0, 4.7.0

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
09:05:21 UTC ---
Passes with -fno-strict-aliasing.  Presumably the alias-improvement branch
merge is the real issue.  Not sure if it isn't an issue with the testcase
which has

inline const Derived  derived () const
{
  return *static_cast  const Derived *(this);
} inline Derived  derived ()
{
  return *static_cast  Derived * (this);
}

I wasn't able to follow the template instantiation quickly ... ;)

I will have a look.

[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot 
com 2011-06-06 09:07:54 UTC ---
On Sun, 5 Jun 2011, andi-gcc at firstfloor dot org wrote:

 FWIW I just commented out the offending assert and the option works
 now. 
 
 Is that the correct fix?

No, that's certainly wrong.  The caller of generate_canonical_option 
should never be passing an argument to an option that doesn't take one.

[Bug target/42210] avr: optimizing assignment to a bit field

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||gjl at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-06 
09:10:23 UTC ---
Closed as resolved+fixed as of patch above.

[Bug gcov-profile/49299] New: ICE in gimple_ic on profile feedback build

[andi-gcc at firstfloor dot org]

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

   Summary: ICE in gimple_ic on profile feedback build
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org


Created attachment 24443
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24443
usage.i

With  4.6.1 20110606 (and 4.7) and 

/pkg/gcc-4.6-110606/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/cc1
-fpreprocessed usage.i -quiet -dumpbase usage.c -mtune=generic -march=x86-64
-auxbase-strip usage.o -g -O2 -Wall -version -fprofile-use -o usage.s

I get

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ecc22bd7305923b0c90b3c641509cfa5

Program received signal SIGSEGV, Segmentation fault.
gimple_ic (all=23, count=23, prob=1, icall_stmt=0x76b79aa0,
direct_call=value optimized out) at ../../gcc/gcc/value-prof.c:1156
1156
(gdb) bt
#0  gimple_ic (all=23, count=23, prob=1, icall_stmt=0x76b79aa0,
direct_call=value optimized out) at ../../gcc/gcc/value-prof.c:1156
#1  gimple_ic_transform (all=23, count=23, prob=1,
icall_stmt=0x76b79aa0, direct_call=value optimized out) at
../../gcc/gcc/value-prof.c:1274
#2  gimple_value_profile_transformations (all=23, count=23, prob=1,
icall_stmt=0x76b79aa0, direct_call=value optimized out) at
../../gcc/gcc/value-prof.c:528
#3  0x00767e2b in tree_profiling () at ../../gcc/gcc/tree-profile.c:484
#4  0x00689399 in execute_one_pass (pass=0x1097a20) at
../../gcc/gcc/passes.c:1556
#5  0x00689a3a in execute_ipa_pass_list (pass=0x1097a20) at
../../gcc/gcc/passes.c:1923
#6  0x00898efc in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1783
#7  cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1855
#8  0x008990aa in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1096
#9  0x0049e405 in c_write_global_declarations () at
../../gcc/gcc/c-decl.c:9871
#10 0x0071a848 in compile_file () at ../../gcc/gcc/toplev.c:591
#11 do_compile () at ../../gcc/gcc/toplev.c:1900
#12 toplev_main () at ../../gcc/gcc/toplev.c:1963
#13 0x771dfa7d in __libc_start_main () from /lib64/libc.so.6
#14 0x0048de09 in _start () at ../sysdeps/x86_64/elf/start.S:113

[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build

[andi-gcc at firstfloor dot org]

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

--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06 
09:12:25 UTC ---
Created attachment 2
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=2
profile feedback input file

[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.06 09:40:44
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.6.1
 Ever Confirmed|0   |1

[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
09:42:03 UTC ---
Created attachment 24445
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24445
gcc46-pr49299-test.patch

Reduced testcase.  The problem is that gimple_ic doesn't expect the indirect
call might be noreturn.

[Bug fortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[4.6/4.7 Regression] Wrong  |[4.6/4.7 Regression] Wrong
   |I/O END OF FILE |END OF FILE error for
   ||list-directed I/O with
   ||strings

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-06 
09:42:36 UTC ---
The issue already occurs for
  read(20, fmt=*) s1
i.e. the list-directed read of a single character variable. In this case,
read_character should only read abcd - and eat the white space, before the
whole line is eaten.

It works with GCC 4.6.0 (trunk) 2010-09-28-r164677. While it fails with 4.7
2011-05-10 and 2011-06-06 -- and 4.6.0 20110523 [gcc-4_6-branch revision
174058] (SUSE Linux).

(For testing: Ensure that the correct libgfortran version is used.)

I could not find anything very promising in the changelog, maybe Rev. 170239
(2011-02-16) for bug 47567 comment 15, or Rev. 168502 (2011-01-04) for PR 47154
look very vaguely related.

[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build

[andi-gcc at firstfloor dot org]

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

--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06 
09:50:49 UTC ---
Thanks I'll drop the noreturn as workaround

[Bug c++/49298] [4.6/4.7 Regression] [C++0x] sorry, unimplemented: unexpected ast of kind field_decl

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.06 09:53:32
  Known to work||4.5.2
Summary|c++0x regression: sorry,|[4.6/4.7 Regression]
   |unimplemented: unexpected   |[C++0x]  sorry,
   |ast of kind field_decl  |unimplemented: unexpected
   ||ast of kind field_decl
 Ever Confirmed|0   |1
  Known to fail||4.6.0, 4.7.0

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-06 
09:53:32 UTC ---
reduced:


namespace detail {

templateclass Parent, class Member
inline unsigned offset_from_pointer_to_member(const Member Parent::*
ptr_to_member)
{
   const Parent * const parent = 0;
   const char *const member = reinterpret_castconst
char*((parent-*ptr_to_member));
   return unsigned(member - reinterpret_castconst char*(parent));
}

templateclass Parent, class Member
inline Parent *parent_from_member(Member *member, const Member Parent::*
ptr_to_member)
{
   return (Parent*)((char*)member -
  offset_from_pointer_to_member(ptr_to_member));
}

templateclass Parent, class Member
inline const Parent *parent_from_member(const Member *member, const Member
Parent::* ptr_to_member)
{
   return (const Parent*)((const char*)member -
  offset_from_pointer_to_member(ptr_to_member));
}

}


templateclass Config
class list_impl
{
   struct data_t
   {
   } data_;

   data_t* get();

   static void priv_container_from_end_iterator()
   {
  data_t *d = get();
  (void)detail::parent_from_memberlist_impl, data_t(d,
list_impl::data_);
   }

};


interface.cc: In static member function 'static void
list_implConfig::priv_container_from_end_iterator()':
interface.cc:40:80: sorry, unimplemented: unexpected ast of kind field_decl
interface.cc:40:80: internal compiler error: in
potential_constant_expression_1, at cp/semantics.c:7952

[Bug c/49300] New: [x86] Missing SSE4.1 intrinsic function

[piotr.wyderski at gmail dot com]

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

   Summary: [x86] Missing SSE4.1 intrinsic function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com


The _mm_extract_epi64() function is available only on x64, but
according to the instruction set, its underlying pextrq instruction 
has the following parameters:

PEXTRQ r/m64, xmm2, imm8

so the m64 mode is available also on 32-bit x86. The function is defined
in smmintrin.h:

#ifdef __x86_64__
extern __inline long long  __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_extract_epi64 (__m128i __X, const int __N)
{
  return __builtin_ia32_vec_ext_v2di ((__v2di)__X, __N);
}
#endif

[Bug c++/49298] [4.6/4.7 Regression] [C++0x] sorry, unimplemented: unexpected ast of kind field_decl

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-06 
09:57:59 UTC ---
Jason, the switch in potential_constant_expression_1 has no FIELD_DECL case

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[ro at gcc dot gnu.org]

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

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-06-06 10:08:47 UTC 
---
I'm seeing this when using Sun as on Solaris, but not with GNU as 2.21, even
when Sun ld is used in both cases.  I've been able to find the root cause: I
set
a breakpoint in _Unwind_IteratePhdrCallback and checked the pc checked there
on i386-pc-solaris2.11.  For the as/ld combination, I get

   0xfee350d5 _Unwind_RaiseException+52:decl   -0x1577b(%ebp)
   0xfef29500 __cxa_throw+96:decl   0x23e82434(%ecx)
   0x8051019 operator()+47:incl   0x874fffa(%ebx)
   0xfef29500 __cxa_throw+96:decl   0x23e82434(%ecx)
   0x8051019 operator()+47:incl   0x874fffa(%ebx)
   0xfee350d5 _Unwind_RaiseException+52:decl   -0x1577b(%ebp)
   0xfef29500 __cxa_throw+96:decl   0x23e82434(%ecx)
   0x8050fcb operator()+47:call   *-0x75(%ebp)
   0x8050fdd _FUN+17:dec%ecx

then

terminate called after throwing an instance of 'int'

Obviously, the unwind info for _FUNC is missing.  Here's the disassembly

   0x8050fcc _FUN:push   %ebp
   0x8050fcd _FUN+1:mov%esp,%ebp
   0x8050fcf _FUN+3:sub$0x18,%esp
   0x8050fd2 _FUN+6:movl   $0x0,(%esp)
   0x8050fd9 _FUN+13:call   0x8050f9c operator()
   0x8050fde _FUN+18:leave  
   0x8050fdf _FUN+19:ret

Looking at the search table, I find:

 elfdump -u lambda-eh2.exe
[...]
  Binary Search Table:
  InitialLocFdeLoc
0x08050f9c0x08061328_ZZ4mainENKUlvE_clEv
  main::{lambda()#1}::operator()() const
0x08050fea0x08061350_ZZ4mainENKUlvE0_clEv
  main::{lambda()#2}::operator()() const
0x0805102f0x08061378main

i.e. the address above is really missing.  With gas instead, I find

  Binary Search Table:
  InitialLocFdeLoc
0x08050fac0x0806130c_ZZ4mainENKUlvE_clEv
  main::{lambda()#1}::operator()() const
0x08050fdc0x08061328_ZZ4mainENUlvE_4_FUNEv
  main::{lambda()#1}::_FUN()
0x08050ff00x08061348_ZZ4mainENKUlvE_cvPFvvEEv
  main::{lambda()#1}::operator void (*)()() const
0x08050ffa0x08061388_ZZ4mainENKUlvE0_clEv
  main::{lambda()#2}::operator()() const
0x0805103f0x080613a8main

[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:13:27 UTC ---
Author: rguenth
Date: Mon Jun  6 10:13:23 2011
New Revision: 174688

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174688
Log:
2011-06-06  Richard Guenther  rguent...@suse.de

PR tree-optimization/48702
* tree-ssa-address.c (create_mem_ref_raw): Create MEM_REFs
only when we know the base address is within bounds.
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Do not
assume the base address of TARGET_MEM_REFs is in bounds.
(indirect_refs_may_alias_p): Fix TARGET_MEM_REF without index tests.

* gcc.dg/torture/pr48702.c: New testcase.

Backport from mainline
2011-05-31  Jakub Jelinek  ja...@redhat.com

PR rtl-optimization/49235
* tree-ssa-address.c (gen_addr_rtx): Ignore base if it is const0_rtx.
(create_mem_ref_raw): Create MEM_REF even if base is INTEGER_CST.

* gcc.dg/pr49235.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr49235.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48702.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa-address.c
branches/gcc-4_6-branch/gcc/tree-ssa-alias.c

[Bug tree-optimization/48702] [4.6 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #29 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:13:27 UTC ---
Author: rguenth
Date: Mon Jun  6 10:13:23 2011
New Revision: 174688

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174688
Log:
2011-06-06  Richard Guenther  rguent...@suse.de

PR tree-optimization/48702
* tree-ssa-address.c (create_mem_ref_raw): Create MEM_REFs
only when we know the base address is within bounds.
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Do not
assume the base address of TARGET_MEM_REFs is in bounds.
(indirect_refs_may_alias_p): Fix TARGET_MEM_REF without index tests.

* gcc.dg/torture/pr48702.c: New testcase.

Backport from mainline
2011-05-31  Jakub Jelinek  ja...@redhat.com

PR rtl-optimization/49235
* tree-ssa-address.c (gen_addr_rtx): Ignore base if it is const0_rtx.
(create_mem_ref_raw): Create MEM_REF even if base is INTEGER_CST.

* gcc.dg/pr49235.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr49235.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48702.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa-address.c
branches/gcc-4_6-branch/gcc/tree-ssa-alias.c

[Bug tree-optimization/48702] [4.6 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.6.1
 Resolution||FIXED

--- Comment #30 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:18:30 UTC ---
Fixed.

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[mikpe at it dot uu.se]

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

--- Comment #9 from Mikael Pettersson mikpe at it dot uu.se 2011-06-06 
10:21:19 UTC ---
Wasn't this fixed in r174077?  If so, can this be closed now?

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-06 
10:26:49 UTC ---
Yep.

[Bug fortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.06 10:28:12
 Ever Confirmed|0   |1

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-06 
10:28:12 UTC ---
Reduced range:
gcc4.6 r166102 is OK
gcc4.6 r166367 gives the error.

[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:30:12 UTC ---
It doesn't make too much sense to profile (cold) noreturn functions.  It's
probably easiest to not do it (check we have an outgoing edge).  Another
testcase would be triggering the transform to a noreturn function (so
technically a sort-of invalid testcase).

[Bug fortran/49297] ICE gfc_conv_component_ref, at fortran/trans-expr.c:268 when compiling molcas7.6

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.06 10:30:45
 Ever Confirmed|0   |1

[Bug debug/49294] [4.7 Regression] ICE: in mem_loc_descriptor, at dwarf2out.c:14636 with -O -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.06 10:34:36
 Ever Confirmed|0   |1

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:34:36 UTC ---
Waiting for sth like a testcase or more investigation.

[Bug fortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-06 
10:36:33 UTC ---
Revision 166252 is within the range, but I fail to see the connection:

2010-11-03  Jerry DeLisle  jvdeli...@gcc.gnu.org

PR libgfortran/43899
* runtime/error.c (generate_warning): New function to generate a run
time warning message. Fix some whitespace.
* libgfortran.h: Add prototype for new function.
* io/list_read.c (nml_read_obj): Use new function to warn when a
character namelist object is truncated.  Only warn if compiled
with -fbounds-check.

[Bug middle-end/49283] pointless warning with -Wstrict-overflow

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:38:33 UTC ---
1) Line 2026 contains the expression
  (p  buff + sizeof buff - 1)

GCC only looks at local tuple stmts when emitting the warning, so I suppose
it sees sth like

  p = buff[...];
  p = p + 3;
  (p  buff + sizeof buff - 1)

and then optimizes the last two stmts as

  p + 3  buff + sizeof buff - 1

moving the + 3 from the LHS and combining it with the constant offset
on the RHS.  That is only valid if p + 3 does not get outside of buff
which GCC doesn't see (it would also be invalid, but that is what the
option tries to catch - so, catch22).

[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

[andi-gcc at firstfloor dot org]

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

--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06 
10:39:32 UTC ---
If you use my command line and just supply any random object files
for the ones specified it should reproduce I think.

If not i'll upload my builddir, but it's large.

[Bug libstdc++/49293] 22_locale/time_get/get_weekday/char/38081-[12].cc fail with glibc 2.14

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-06 
10:41:48 UTC ---
Created attachment 24446
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24446
Draft patch

[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:42:23 UTC ---
I suppose we keep pointers to inline summaries live across the growth.

[Bug fortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-06 
10:42:32 UTC ---
(In reply to comment #3)
 Revision 166252 is within the range, but I fail to see the connection:

My impression - looking at the diff - is that it is a different patch.

(Janne: Could you please use the normal ChangeLog format in commits? It helps
tremendously to find commits.)

http://gcc.gnu.org/viewcvs?view=revisionrevision=166180

r166180 | jb | 2010-11-02 13:56:38 +0100 (Tue, 02 Nov 2010) | 1 line
Changed paths:
   M /trunk/libgfortran/ChangeLog
   M /trunk/libgfortran/io/io.h
   M /trunk/libgfortran/io/list_read.c
   M /trunk/libgfortran/io/transfer.c

PR 45629 Remove usage of setjmp/longjmp

[Bug fortran/49280] Misinterpretation of -static-libgfortran switch

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:43:27 UTC ---
Report it to Debian instead.

[Bug libstdc++/49293] 22_locale/time_get/get_weekday/char/38081-[12].cc fail with glibc 2.14

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.06 10:42:46
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
 Ever Confirmed|0   |1

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-06 
10:42:46 UTC ---
Thanks Jakub. The patchlet I have just attached should do the trick, then. If
somebody would be so kind to test it...

[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
10:44:43 UTC ---
Can you provide source for random object files?

[Bug gcov-profile/49299] ICE in gimple_ic on profile feedback build

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
10:56:55 UTC ---
Created attachment 24447
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24447
gcc46-pr49299.patch

Untested fix.  Turning of a normal indirect call into an optionally direct
noreturn call seems to work and worked before too.
Anyway, if you prefer to just give up in gimple_ic_transform instead, like
  /* Don't optimize noreturn calls, they should be cold.  */
  if (gimple_call_flags (stmt)  ECF_NORETURN)
return false;
I can test that instead.

[Bug lto/48978] excessive hash table allocation for large lto build

[andi-gcc at firstfloor dot org]

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

Andi Kleen andi-gcc at firstfloor dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2011-06-06 
11:05:47 UTC ---
With the latest tree it's bearable, but still very slow.
But at least I don't run regularly out of memory anymore.

[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-06 
11:18:43 UTC ---
 I'm seeing this when using Sun as on Solaris, but not with GNU as 2.21, even
 when Sun ld is used in both cases.  

I'm seeing it on SPARC/Solaris 8, 9 and 10 with GNU as 2.20.1 and Sun ld.  So
the failure may be predicated on a feature available only in 2.21 or above.

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

[dodji at gcc dot gnu.org]

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

--- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2011-06-06 
11:33:45 UTC ---
Author: dodji
Date: Mon Jun  6 11:33:42 2011
New Revision: 174694

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174694
Log:
PR preprocessor/48532

libcpp/

* directives.c (do_pragma): Don't forget the invocation location
when parsing the pragma name of a namespaced pragma directive.

gcc/testsuite/

* gcc.dg/cpp/pragma-3.c: New test case.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/pragma-3.c
Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/directives.c

[Bug tree-optimization/49243] attribute((returns_twice)) doesn't work

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
11:43:34 UTC ---
Author: rguenth
Date: Mon Jun  6 11:43:31 2011
New Revision: 174695

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174695
Log:
2011-06-06  Mikael Pettersson  mi...@it.uu.se

PR tree-optimization/49243
* calls.c (setjmp_call_p): Also check if fndecl has the
returns_twice attribute.

* gcc.dg/pr49243.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr49243.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/49243] attribute((returns_twice)) doesn't work

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
11:46:16 UTC ---
Author: rguenth
Date: Mon Jun  6 11:46:14 2011
New Revision: 174696

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174696
Log:
2011-06-06  Mikael Pettersson  mi...@it.uu.se

PR tree-optimization/49243
* calls.c (setjmp_call_p): Also check if fndecl has the
returns_twice attribute.

* gcc.dg/pr49243.c: New.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr49243.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/calls.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2011-06-06 11:49:48 UTC 
---
 I suppose we keep pointers to inline summaries live across the growth.
Well, we should not. It is  resized in inline_summary_alloc () and that
function
is called always before we get any pointers out...

Re: [Bug libfortran/48906] Wrong rounding results with -m32

[jerry DeLisle]

On 06/06/2011 01:38 AM, thenlich at users dot sourceforge.net wrote:

For a scale factor 0, we are done. Good work, thank you!

A scale factor != 0 does not work yet, you wrote you are still working on it,
is that correct?


I am now.  ;)



print (-2pg12.3), 0.02 ! 0.200E-01 expected 0.002E+01
print (-1pg12.3), 0.02 ! 0.200E-01 expected 0.020E+00
print (0pg12.3), 0.02 ! 0.200E-01
print (1pg12.3), 0.02 ! 0.200E-01 expected 2.000E-02
print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03

My confusion seems to be when scale factor is to be ignored and when not,  I 
will give the standard another read.

[Bug libfortran/48906] Wrong rounding results with -m32

[jvdelisle at charter dot net]

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

--- Comment #25 from jvdelisle at charter dot net 2011-06-06 12:09:48 UTC ---
On 06/06/2011 01:38 AM, thenlich at users dot sourceforge.net wrote:
 For a scale factor 0, we are done. Good work, thank you!

 A scale factor != 0 does not work yet, you wrote you are still working on it,
 is that correct?

I am now.  ;)


 print (-2pg12.3), 0.02 ! 0.200E-01 expected 0.002E+01
 print (-1pg12.3), 0.02 ! 0.200E-01 expected 0.020E+00
 print (0pg12.3), 0.02 ! 0.200E-01
 print (1pg12.3), 0.02 ! 0.200E-01 expected 2.000E-02
 print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03

My confusion seems to be when scale factor is to be ignored and when not,  I 
will give the standard another read.

[Bug fortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-06 
12:10:14 UTC ---
  Revision 166252 is within the range, but I fail to see the connection:

 My impression - looking at the diff - is that it is a different patch.

You are right!-) Revision 166179 is OK, 166180 is not.

[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

  Component|fortran |libfortran

--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-06 
12:11:43 UTC ---
Changing component to libfortran.

[Bug driver/49178] [4.6/4.7 Regression] Space between linker option and library in gfortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-06-06 
12:20:48 UTC ---
I will leave this to Janne. (I am very short on time.) If the fix is not
obvious, I will be happy to review the patch. It took a while for this to
surface.

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-06 
12:25:45 UTC ---
--- /opt/gcc/_clean/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C2011-05-31
14:24:18.0 +0200
+++ /opt/gcc/work/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C2011-06-06
14:19:13.0 +0200
@@ -14,4 +14,4 @@ main()
 K k;
 }

-// { dg-final {scan-assembler-times \[^\n\r\]*DW_AT_MIPS_linkage_name: 2 } }
+// { dg-final {scan-assembler-times
\[^\n\r\]*DW_AT_MIPS_linkage_name\[:\n\r\] 2 } }

is probably a better patch tested on x86_64-apple-darwin10 and
powerpc-apple-darwin9).

[Bug libfortran/48906] Wrong rounding results with -m32

[thenlich at users dot sourceforge.net]

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

--- Comment #26 from Thomas Henlich thenlich at users dot sourceforge.net 
2011-06-06 12:27:38 UTC ---
(In reply to comment #25)
 My confusion seems to be when scale factor is to be ignored and when not,  I 
 will give the standard another read.

As it happens, you're not the only one to find (this part of) the Fortran
standard confusing and buggy, so if all goes as planned there will be a
rewrite:

-
11-xxx
To: J3
From: John Reid and Thomas Henlich
Subject: Interp: G editing for reals
Date: 2011 June 5

-

NUMBER: F08/
TITLE: G editing for reals
KEYWORDS: format, G editing
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

1. Gw.d editing for a real value that is in the range (0.1,10**d) and 
is not near an integer power of 10 uses F editing to produce exactly 
the same value as 0PEw.d editing would produce. For values in this 
range that are near an integer power of 10, is it intended that F 
editing be used to produce exactly the same value as 0PEw.d editing 
would produce? 

The rules in 10.7.5.2.2 usually have this effect, but the following
examples illustrate exceptions for rounding UP and to ZERO.
  i. 
 print (ru,g11.2), -9.95 
  or
 print (rz,g11.2), -9.95 
  Here, 0PE11.2 editing would produce the value -0.99E+01, which can be 
  represented as -9.9. However, the standard requires F7.0 to be used, 
  which gives the result -9. Note that the standard requires
 print (rd,g11.2), 9.95
  and
 print (rz,g11.2), 9.95
  to give the result 9.9. 

  ii.
 print (ru,0p,g11.2), -99.5
  The standard requires 0PE11.2 editing to be used, which gives 
  -0.99E+02. This is representable as -99.

  iii. 
 print (ru,0p,g11.2), 99.
  The standard requires 0PE11.2 editing to be used, which gives 
  0.99E+02. This is representable as 99.


2. COMPATIBLE and NEAREST modes of rounding differ only when the two
nearest representable values are equidistant from the given value. The
similarity appears not to be represented in the second table. What is
meant by if the higher value is even?

3. Why is no account taken of the effects when PROCESSOR_DEFINED 
rounding is in effect? 


ANSWER:

1. Yes, this was the intention and it would be clearer for the standard
to state this directly. It would also be easier for implementers to 
implement. 

2. If the standard is rewritten as proposed in the first question, these
further problems would be resolved. 

3. If the standard is rewritten as proposed in the first question, 
PROCESSOR_DEFINED rounding would be covered. 

EDITS to 10-007r1:

[258:14-20] In 10.7.5.2.2, replace paragraph 4 by
Otherwise, the method of representation in the output field depends
on the internal value being edited. Let N be the value that would be
output with 0PEw.dEe editing and let s be its exponent part unless N 
is identically 0 in which case let s be 1. Let k be the scale factor 
(10.8.5). Let b be a blank. For Gw.d editing, if s lies in the range
0 = s = d, F(w-4).(d-s),4('b') editing is used to represent N in the
output field; otherwise, kPEw.d editing is used to represent the
internal value. For Gw.dEe editing, if s lies in the range 0 = s = d, 
F(w-n).(d-s),n('b') editing where n=e+2 is used to represent N in the 
output field; otherwise, kPEw.dEe editing is used to represent the 
internal value. 


SUBMITTED BY: John Reid and Thomas Henlich 

HISTORY: 11-xxxm195  Submitted

[Bug libfortran/48906] Wrong rounding results with -m32

[jvdelisle at charter dot net]

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

--- Comment #27 from jvdelisle at charter dot net 2011-06-06 12:36:21 UTC ---

 print (-2pg12.3), 0.02 ! 0.200E-01 expected 0.002E+01
 print (-1pg12.3), 0.02 ! 0.200E-01 expected 0.020E+00
 print (0pg12.3), 0.02 ! 0.200E-01
 print (1pg12.3), 0.02 ! 0.200E-01 expected 2.000E-02Too many 
 significant digits?
 print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03   Too many 
 significant digits?

Should these last two cases by 2.00E-02 and 20.0E-03 ? Otherwise we seem to be 
adding an extra significant digit.

Help me understand this.

Jerry

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
12:37:07 UTC ---
No, the test just should use -fno-merge-debug-strings in dg-options and
make sure it matches only DW_AT_(MIPS_|)linkage_name in .debug_info and not in
.debug_abbrev.  The test will fail even when testing RUNTESTFLAGS='dwarf2.exp
--target_board=unix/-gdwarf4'.

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-06 
12:36:49 UTC ---
Rainer,

What is the difference between

... [trunk revision 174614] (GCC) testsuite on sparc-sun-solaris2.11 at
http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00642.html (for which the test
is OK),

and

...  [trunk revision 174614] (GCC) testsuite on sparc-sun-solaris2.11 at
http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00629.html (for which the test
fails)?

[Bug libfortran/48906] Wrong rounding results with -m32

[thenlich at users dot sourceforge.net]

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

--- Comment #28 from Thomas Henlich thenlich at users dot sourceforge.net 
2011-06-06 12:41:55 UTC ---
I had a look at the code and what I think we should do is the following:

If G editing and a scale factor p != 0 is in effect, split the rounding step
into 2 steps:

First, check if overflow occurs (... = 1....) but do not actually
overwrite the digits yet.

With this information, we determine the final value of e.

If it turns out we need F editing: Repeat the rounding as above (or remember if
overflow occured the first time), and this time actually overwrite the digits.

If it turns out we need E editing: Set the new value for the number of digits
according to p and repeat the rounding.

It may help to refactor some of the code into a separate function, since we
need to call it twice.

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE 2011-06-06 12:42:14 UTC ---
With Sun as, the testcase fails, with GNU as, it passes.  On IRIX 6.5,
it fails even with GNU as, haven't yet checked why.

Rainer

[Bug libfortran/48906] Wrong rounding results with -m32

[thenlich at users dot sourceforge.net]

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

--- Comment #29 from Thomas Henlich thenlich at users dot sourceforge.net 
2011-06-06 12:47:58 UTC ---
(In reply to comment #27)
 
  print (-2pg12.3), 0.02 ! 0.200E-01 expected 0.002E+01
  print (-1pg12.3), 0.02 ! 0.200E-01 expected 0.020E+00
  print (0pg12.3), 0.02 ! 0.200E-01
  print (1pg12.3), 0.02 ! 0.200E-01 expected 2.000E-02Too many 
  significant digits?
  print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03   Too many 
  significant digits?
 
 Should these last two cases by 2.00E-02 and 20.0E-03 ? Otherwise we seem to 
 be 
 adding an extra significant digit.
 
 Help me understand this.

Don't worry, it's not your fault... Say goodbye to the world of common sense,
welcome to the world of the Fortran standard! ;-)

The scale factor k controls the decimal normalization (10.3.2, 10.8.5).  If −d
 k = 0, the output field contains exactly |k| leading zeros and d − |k|
significant digits after the decimal symbol. If 0  k  d + 2, the output field
contains exactly k significant digits to the left of the decimal symbol and d −
k + 1 significant digits to the right of the decimal symbol. Other values of k
are not permitted.

[Bug rtl-optimization/49154] [4.7 Regression]: build fails on cris-elf in libgcc: ICE in setup_pressure_classes, at ira.c:902

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson hp at gcc dot gnu.org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg00136.htm
   ||l

--- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-06 
12:49:50 UTC ---
It's either an IRA bug, or a documentation issue (and subsequently a target
bug). Suggested patch at URL to amend the documentation.

[Bug rtl-optimization/49154] [4.7 Regression]: build fails on cris-elf in libgcc: ICE in setup_pressure_classes, at ira.c:902

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson hp at gcc dot gnu.org changed:

   What|Removed |Added

 Target|cris-axis-elf,  |cris-axis-elf
   |sparc-sun-solaris2* |

--- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-06 
12:53:22 UTC ---
I'm removing sparc-sun-solaris2* from the target field as that was fixed by the
commit in the audit trail.

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.06 13:00:20
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
13:00:20 UTC ---
Created attachment 24448
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24448
gcc47-pr49288.patch

Can you please test this on darwin (just make check-g++ RUNTESTFLAGS=dwarf2.exp
should be enough)?

[Bug c++/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Depends on||48764

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
13:00:44 UTC ---
Indeed PRE thinks that it is loop invariant, presumambly because of TBAA:

  D.7681_206 = MEM[(const double )D.7674_199];
  D.7680_208 = D.7425_99 * D.7681_206;
  D.7663_216 = MEM[(const double )SR.167_105];
  D.7664_217 = D.7680_208 + D.7663_216;
  MEM[(Scalar )SR.167_105] = D.7664_217;

and MEM[(const double )SR.167_105] is sought to be loop-invariant, not
aliasing MEM[(Scalar )SR.167_105].

We do not see the must-alias because SR.167_105 is value-numbered to some
other SSA name and value_dies_in_block_x (after fixing another bug in that
function) does not do value-replacement on the stmt it queries
stmt_may_clobber_ref_p_1.  Then the oracle figures

  if (!ptr_derefs_may_alias_p (ptr1, ptr2))
return false;

and both vars point to restrict tags (but different restrict tags).  So
this looks to me related to PR48764.

Of course this case is somewhat different in that we basically have

struct {
  double * restrict x;
} m;

double * restrict wrap () { return m.x; }

double x;
m.x = x;
for (;;)
  wrap (x) = wrap (x) + 1;

and GCC thinks that the two restrict qualified pointers point to different
things.

See the restrict qualified m_data pointer in MapBase.  As you are
creating a new object via forceAligned - force_aligned_impl.run
- _convertToForceAligned you effectively are loading from two different
restrict qualified pointers.

I'll fixup the bug I noticed in value_dies_in_block_x, but it won't fix
this PR.

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-06 
13:09:59 UTC ---
 ... Can you please test this on darwin ...

It works on x86_64-apple-darwin10 and powerpc-apple-darwin9. Thanks.

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE 2011-06-06 13:22:45 UTC ---
 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
 13:00:20 UTC ---
 Created attachment 24448
   -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24448
 gcc47-pr49288.patch

 Can you please test this on darwin (just make check-g++ 
 RUNTESTFLAGS=dwarf2.exp
 should be enough)?

It passes on i386-pc-solaris2.10 with as (where it failed before) and
gas (where it already passed) and on mips-sgi-irix6.5.

Thanks.
Rainer

[Bug testsuite/49273] FAIL: g++.dg/debug/dwarf2/cdtor-1.C scan-assembler-times [^\n\r]*DW_AT_MIPS_linkage_name: 2

[ro at gcc dot gnu.org]

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

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-06-06 13:22:33 UTC 
---
Duplicate.

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

[Bug bootstrap/49270] make BOOT_CFLAGS=-g -O3 CFLAGS_FOR_TARGET=-g -O3 CXXFLAGS_FOR_TARGET=-g -O3 failure

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-06-06 
13:24:41 UTC ---
Author: aoliva
Date: Mon Jun  6 13:24:39 2011
New Revision: 174697

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174697
Log:
PR bootstrap/49270
* ipa-inline-analysis.c (read_predicate): Initialize all clauses.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c

[Bug testsuite/49288] FAIL: g++.dg/debug/dwarf2/cdtor-1.C

[ro at gcc dot gnu.org]

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

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #7 from Rainer Orth ro at gcc dot gnu.org 2011-06-06 13:22:33 UTC 
---
*** Bug 49273 has been marked as a duplicate of this bug. ***

[Bug bootstrap/49209] unresolved references to fatal() while linking xgcc and cpp

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot 
com 2011-06-06 13:30:11 UTC ---
These programs should only be calling fatal_error from diagnostic.c, not a 
function named fatal.

[Bug bootstrap/49270] make BOOT_CFLAGS=-g -O3 CFLAGS_FOR_TARGET=-g -O3 CXXFLAGS_FOR_TARGET=-g -O3 failure

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva aoliva at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #11 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-06-06 
13:32:25 UTC ---
Fixed

[Bug bootstrap/49270] make BOOT_CFLAGS=-g -O3 CFLAGS_FOR_TARGET=-g -O3 CXXFLAGS_FOR_TARGET=-g -O3 failure

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva aoliva at gcc dot gnu.org changed:

   What|Removed |Added

 CC||d.g.gorbachev at gmail dot
   ||com

--- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-06-06 
13:32:35 UTC ---
*** Bug 49116 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/49243] attribute((returns_twice)) doesn't work

[mikpe at it dot uu.se]

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

Mikael Pettersson mikpe at it dot uu.se changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.1, 4.7.0
 Resolution||FIXED
  Known to fail|4.7.0   |

--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2011-06-06 
13:32:23 UTC ---
Fixed for 4.6.1/4.7.0.  The fix does work for 4.5 and 4.4 too, but given the
age and relative obscurity of the bug I'm not pushing it to older branches.

[Bug other/49116] GCC fails to bootstrap with -O3 (may be used uninitialized errors)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva aoliva at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-06-06 
13:32:35 UTC ---
Fixed, but ChangeLog entry referenced only the other bug, so marking this one
as a dupe.

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

[Bug fortran/49280] Misinterpretation of -static-libgfortran switch

[hroch at physics dot muni.cz]

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

--- Comment #4 from Filip Hroch hroch at physics dot muni.cz 2011-06-06 
13:49:09 UTC ---
(In reply to comment #2)
 Steve makes a good point.  I have found that some distributions do not install
 the static libraries unless one specifically installs them.  An example is
 Fedora 15.  They are provided, but not installed by default

I confirms that the fail has been appeared under Fedora 15. The installation of
recommended static libraries (libgfortran.a, etc.) solved the problem. Sorry
for inconviences, I'm confused user of Debian based distributions. Thank you
very much!

[Bug c++/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
14:03:27 UTC ---
  # PT = nonlocal escaped
  D.7613_101 = MEM[(struct ei_matrix_storage *)this_30(D)];
  # PT = nonlocal escaped
  D.7616_104 = D.7613_101 + D.7582_90;
  # PT = nonlocal escaped { D.7934 } (restr)
  SR.167_105 = (const Scalar * restrict) D.7616_104;

  # PT = nonlocal escaped
  D.7671_127 = MEM[(struct ei_matrix_storage *)this_30(D)];
  D.7672_129 = D.7554_68 * 8;
  # PT = nonlocal escaped
  D.7674_130 = D.7671_127 + D.7672_129;
  # PT = nonlocal escaped { D.7936 } (restr)
  SR.169_131 = (const Scalar * restrict) D.7674_130;

so while the fix for PR48764 makes this_30 point to a single tag that
would make derived pointers derived it doesn't seem to work for this
case.  I have a variant that does.

[Bug tree-optimization/48764] [4.5/4.6/4.7 Regression] wrong-code bug in gcc-4.5.x, related to __restrict

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
14:06:06 UTC ---
The same issue in a more complicated form hits trunk in PR49279.

[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from William J. Schmidt wschmidt at gcc dot gnu.org 
2011-06-06 14:27:44 UTC ---
Author: wschmidt
Date: Mon Jun  6 14:27:41 2011
New Revision: 174701

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174701
Log:
2011-06-06  Bill Schmidt  wschm...@linux.vnet.ibm.com

PR tree-optimization/46728
* builtins.c (powi_table): Remove.
(powi_lookup_cost): Remove.
(powi_cost): Remove.
(expand_powi_1): Remove.
(expand_powi): Remove.
(expand_builtin_pow_root): Remove.
(expand_builtin_pow): Remove.
(expand_builtin_powi): Eliminate handling of constant exponent.
(expand_builtin): Use expand_builtin_mathfn_2 for BUILT_IN_POW.


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

[Bug objc/49301] New: Forward declaration of classes broken

[jos at kuijpersvof dot nl]

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

   Summary: Forward declaration of classes broken
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@kuijpersvof.nl


In the current gcc from SVN is the meaning of @class broken.

@class is used to tell the compiler the class exists, but that its not (yet)
available. Eg: class B uses class A, but class A uses class B too, creating a
recursive import, and thus goes wrong.

Using @class now broke. This is the warning the compiler gives, for example:


OFConnectionFailedException.m: In function â-[OFConnectionFailedException
dealloc]â:
OFConnectionFailedException.m:68:2: warning: @interface of class âOFTCPSocketâ
not found [enabled by default]

It seems like @class is expecting the @interface to follow in the same file...

Please recover the function of @class as it is an important functionality.


Example.m:
[code]
#import objc/objc.h
#import objc/Object.h

@class myClass;

int main()
{
myClass *obj = [myClass new];
}

@interface myClass : Object
@end

@implementation myClass
@end
[/code]


$ gcc -lobjc Example.m
Example.m: In function âmainâ:
Example.m:8:2: warning: @interface of class âmyClassâ not found [enabled by
default]

[Bug objc/49301] Forward declaration of classes broken

[jos at kuijpersvof dot nl]

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

jos at kuijpersvof dot nl changed:

   What|Removed |Added

   Severity|critical|normal

[Bug tree-optimization/49243] attribute((returns_twice)) doesn't work

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug objc/49301] Forward declaration of classes broken

[nicola at gcc dot gnu.org]

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

--- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-06-06 15:14:24 
UTC ---

 @class is used to tell the compiler the class exists, but that its not (yet)
 available. Eg: class B uses class A, but class A uses class B too, creating a
 recursive import, and thus goes wrong.

Yes, that's correct.  Notice that there is no messaging involved in this
scenario. ;-)

An example would look like:

@class B;

@interface A
- (B *) giveMeB;
@end

@interface B
- (A *) giveMeA;
@end

without '@class B', the example doesn't compile because a method in 
@interface A return B *, which isn't known yet, and moving @interface B
before @interface A doesn't work because @interface B itself returns
A *.

This is mostly a concern for header files.


 #import objc/objc.h
 #import objc/Object.h

 @class myClass;

 int main()
 {
myClass *obj = [myClass new];
 }

 @interface myClass : Object
 @end
 
 @implementation myClass
 @end

This example is completely different.  You are messaging 'myClass' which is
forward-declared, and the compiler can't determine if the class responds to
+new or not. ;-)

So, there is a problem with determining the correct method prototype, a
problem which wasn't obvious before because the compiler wasn't warning about
the problem ;-)

You can trivially fix it by moving @interface myClass before int main().

Note that both the recent Apple GCC and Apple clang emit a similar warning.

For example, compiling your code with clang produces:

 example.m:8:19: warning: receiver 'myClass' is a forward class and 
 corresponding @interface may not exist
  myClass *obj = [myClass new];
 ^
 example.m:8:18: warning: method '+new' not found (return type defaults to 
 'id')
  myClass *obj = [myClass new];
 ^
example.m:8:12: warning: unused variable 'obj' [-Wunused-variable]
  myClass *obj = [myClass new];
   ^
 3 warnings generated.

So this warning is not specific to GCC. ;-)

By the way, the warning is useful, because when messaging a Class only declared
with a @class, the compiler is blind as to what messages it can accept, and
won't do any checks on method invocations. :-(

Thanks

[Bug lto/49277] [4.7 Regression] 456.hmmer in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-06 
15:23:47 UTC ---
Works for me.

/abuild/rguenther/install/usr/local/bin/gcc   -m32 -msse2 -mfpmath=sse -O2
-ffast-math -fwhole-program -fuse-linker-plugin
-Wl,-rpath=/abuild/rguenther/install/usr/local/lib -flto=6  alphabet.o
core_algorithms.o debug.o display.o emit.o emulation.o fast_algorithms.o
histogram.o hmmio.o hmmcalibrate.o hmmsearch.o mathsupport.o masks.o misc.o
modelmakers.o plan7.o plan9.o postprob.o prior.o tophits.o trace.o ucbqsort.o
a2m.o aligneval.o alignio.o clustal.o cluster.o dayhoff.o eps.o file.o getopt.o
gki.o gsi.o hsregex.o iupac.o msa.o msf.o phylip.o revcomp.o rk.o selex.o
seqencode.o shuffle.o sqerror.o sqio.o squidcore.o sre_ctype.o sre_math.o
sre_random.o sre_string.o ssi.o stack.o stockholm.o translate.o types.o
vectorops.o weight.o -lm-o hmmer
/usr/bin/ld: Warning: alignment 4 of symbol `Alphabet' in
/tmp/ccb1HVsX.ltrans17.ltrans.o is smaller than 16 in hmmsearch.o.ironly
specmake -j6 options 2 options.err | tee options.out
...

Please provide a testcase.

[Bug c++/48771] [C++0x] is_literal_type incorrect for references to non-literal types

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

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

--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-06 
15:42:57 UTC ---
I guess we can be satisfied with having this fixed in mainline.

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

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson rth at gcc dot gnu.org 2011-06-06 
15:49:06 UTC ---
Uros, the code you generate has a double-rounding error.

You can generate code inline if you have access to SSE2,
by converting the pieces to DFmode and then truncating 
to SFmode.  Since DFmode has  2x the number of bits, we
don't get a double rounding bug.

Otherwise, we *do* have an algorithm to do DI-SF conversion
in libgcc2.c.  See the last bit of ifdeffery there; the
amount of code is really quite large.

Unfortunately, we'd need to define some new symbol in
libgcc to do this completely in SSE mode.  The default
calling conventions would use the FP stack to return the
results.

[Bug objc/49301] Forward declaration of classes broken

[nicola at gcc dot gnu.org]

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

Nicola Pero nicola at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2011-06-06 15:51:27 
UTC ---

 But could we turn it off with some flag?

Not at the moment.  We could add a flag to turn it off if there are enough
important examples.


 And also, in my example, the interface is just BELOW! I think GCC should first
 look further… just a thought.

:-)


 So in programming it must be like this:

 The header file has a @class, so the class can be used for variables and 
 method arguments.

Yes, header files can use @class to refer to classes defined in other headers
and prevent recursive class definitions.  Eg, the header B.h could be:

@class A;

@interface B
- (A *)giveMeA;
@end

and the header A.h could be:

@class B;
@interface A
- (B *)giveMeB;
@end

the two headers are now independent and you can include them independently
with no recursion.


 The method file should have the actual import of the interface, so the 
 messages are known, and no recursive import occurs?

Yes, the implementation generally should include full @interfaces for all
the classes that are involved in messaging ... so that the compiler can do
the checks.  In the example above, in A.m you would do

#import A.h
#import B.h

@implementation A
- (B *) giveMeB
{
   ...
}
@end

and similarly in the implementation of B.  No recursive @interface definitions
would occur, and the actual Objective-C code (... in the example) has the
full
@interfaces for all the classes and can do full type-checking. :-)

You could also a general header that #imports both A.h and B.h, and #import
that one instead.

Thanks

[Bug debug/49262] 3-yr-old infinite loop in dwarf2out.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
16:17:35 UTC ---
Created attachment 24449
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24449
gcc47-pr49262.patch

Untested fix (well, given that we don't have a testcase and nobody hit it, it
is a question if index is ever RANGE_EXPR at that spot so late).  I've tried a
few testcases but RANGE_EXPR wasn't present.  On the other side, e.g. varasm.c
also
tries to handle it in CONSTRUCTORs.

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.

[melaniec at enfocus dot com]

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

--- Comment #4 from Melanie Cappelaere melaniec at enfocus dot com 2011-06-06 
16:27:22 UTC ---
I don't think it does, but it also doesn't matter for this bug report; symbols
are not hidden while they should be.

[Bug c++/49264] [4.6/4.7 Regression] Internal compiler error: segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
17:12:29 UTC ---
Author: jakub
Date: Mon Jun  6 17:12:25 2011
New Revision: 174711

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174711
Log:
PR c++/49264
* gimple-fold.c (fold_stmt_1): Don't try to fold * on the lhs
if stmt folded into nothing.
* tree-inline.c (fold_marked_statements): If a builtin at the
end of a bb folded into nothing, just update cgraph edges
and move to next bb.
* cgraph.c (cgraph_update_edges_for_call_stmt_node): Allow new_stmt
to be NULL.  Don't compute count and frequency if new_call is NULL.

* g++.dg/opt/pr49264.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr49264.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug c++/49264] [4.6/4.7 Regression] Internal compiler error: segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
17:14:33 UTC ---
Author: jakub
Date: Mon Jun  6 17:14:31 2011
New Revision: 174712

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174712
Log:
PR c++/49264
* gimple-fold.c (fold_stmt_1): Don't try to fold * on the lhs
if stmt folded into nothing.
* tree-inline.c (fold_marked_statements): If a builtin at the
end of a bb folded into nothing, just update cgraph edges
and move to next bb.
* cgraph.c (cgraph_update_edges_for_call_stmt_node): Allow new_stmt
to be NULL.  Don't compute count and frequency if new_call is NULL.

* g++.dg/opt/pr49264.C: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/pr49294.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49264] [4.6/4.7 Regression] Internal compiler error: segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-06 
17:16:37 UTC ---
Author: jakub
Date: Mon Jun  6 17:16:35 2011
New Revision: 174713

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174713
Log:
PR c++/49264
* gimple-fold.c (fold_stmt_1): Don't try to fold * on the lhs
if stmt folded into nothing.
* tree-inline.c (fold_marked_statements): If a builtin at the
end of a bb folded into nothing, just update cgraph edges
and move to next bb.
* cgraph.c (cgraph_update_edges_for_call_stmt_node): Allow new_stmt
to be NULL.  Don't compute count and frequency if new_call is NULL.

* g++.dg/opt/pr49264.C: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/opt/pr49264.C
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/cgraph.c
branches/gcc-4_6-branch/gcc/gimple-fold.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-inline.c