[Bug libfortran/47567] Wrong output for small absolute values with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #12 from Thomas Henlich  
2011-02-07 07:01:14 UTC ---
(In reply to comment #11)
> Fixed on trunk.  I don't think this is significant enough to justify a
> back-port. I am not sure why anyone would use f1.X for anything, so this
> exercise is largely academic. I do appreciate the bug reports. Thanks

Thank you for your work on this and for the fast response, which is actually
better than what you get from the "premier" support of some big commercial
compiler vendors.

Of course I agree with you that noone would use (F1.n) editing, that was
exactly my point, see my comment #1: "Any formatting ... with (F1.n) should
always result in asterisks".

However, because of the rule for (F0.n) we need to make clear what is "the
smallest positive actual field width that does not result in a field filled
with asterisks".

print "(F0.0)", 0.0   ! => 0

I'm still pretty sure that this is not compliant to Fortran 2003/2008 and I
would like a convincing explanation why it should be. Of course I can
understand the argument that "0" instead of "0." is useful to express the "real
zero", but I think standard-compliance takes precedence, making it easier for
the user to write portable programs.

In my interpretation, the demand of "a string of digits that contains a decimal
symbol" is equivalent to the syntax:

DIGIT ... DECIMAL-SYMBOL [DIGIT] ...
|
[DIGIT] ... DECIMAL-SYMBOL DIGIT ...

The clause "The optional zero shall appear if there would otherwise be no
digits in the output field." rules out the string becoming just:

DECIMAL-SYMBOL

As I see it, the decimal symbol is not optional and cannot be left out, so the
output "0" is illegal.

The phrase "contains" means that e.g. the Java method
string.contains(decimal_symbol) would return true.

[Bug middle-end/47046] gcc.target/i386/sse4_1-movntdqa.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.07 06:48:14
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Sebastian Pop  2011-02-07 06:48:14 
UTC ---
The testcase contains a chrec: {0, +, {1, +, 2}_1}_1
and chrec_apply (1, {0, +, {1, +, 2}_1}_1, graphite_IV)
fails to produce an expression that can be code generated.

This could be fixed by implementing the missing case
in chrec_apply.  That's probably a too big change for 4.6.

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

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

--- Comment #16 from Laurent GUERBY  2011-02-07 
06:10:13 UTC ---
Joel, could you send me the compressed acats.log or at least post the failing
tests? 335 failures likely mean one Ada feature is broken.

[Bug fortran/47517] [F03] Reallocate on assignment: Segfault

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.07 05:32:21
 Ever Confirmed|0   |1

--- Comment #1 from Paul Thomas  2011-02-07 05:32:21 
UTC ---
(In reply to comment #0)
This somewhat reduced version of James testcase retains the segfault in bar. 
Now to understand what happens in foo!

Confirmed

Paul

>program allocate_assign
   implicit none
   type label
  integer, allocatable :: parts(:)
   end type label
   type table
  type(label), allocatable :: headers(:)
   end type table
   integer, parameter :: ik8 = selected_int_kind(18)
   type(table) x1(1)
   type(table) t1
   type(table), allocatable :: x(:)
   integer k
   integer(ik8) s
   t1 = table([label([1])])
   x1 = [t1]
   s = 0
   do k = 1, 2
  write(*,*) "1> ", k,s
  call foo
  write(*,*) "2> ",k,s, size (x)
  call bar
   end do
   write(*,*) s
contains
   subroutine foo
  x = x1
   end subroutine
   subroutine bar
  s = s+x(2)%headers(2)%parts(2)
   end subroutine
end program allocate_assign

[Bug fortran/42189] gfc_is_constant_expr has unacceptable side effects

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  2011-02-07 
02:57:42 UTC ---
Might as well take this again in light of 47267

[Bug debug/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"

[jiez at gcc dot gnu.org]

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

Jie Zhang  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.07 02:37:06
 Ever Confirmed|0   |1

--- Comment #3 from Jie Zhang  2011-02-07 02:37:06 UTC 
---
Confirmed.

[Bug c/4784] Anonymous structs issues

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jengelh at medozas dot de

--- Comment #9 from Joseph S. Myers  2011-02-07 
02:00:15 UTC ---
*** Bug 47376 has been marked as a duplicate of this bug. ***

[Bug c/47376] Duplicate member through anonymous unions not reported

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Joseph S. Myers  2011-02-07 
02:00:15 UTC ---
Fixed in 4.6.

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

[Bug c/47376] Duplicate member through anonymous unions not reported

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #1 from Joseph S. Myers  2011-02-07 
01:59:50 UTC ---
Fixed in 4.6.

[Bug target/47619] ICE in printf() with -fsplit-stack enabled.

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  2011-02-07 01:48:58 
UTC ---
Good point, I added a note to the wiki page.

[Bug libfortran/47493] FAIL: gfortran.fortran-torture/execute/csqrt_1.f90 compilation

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from John David Anglin  2011-02-07 
01:20:10 UTC ---
Cache issue.

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu.org]

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

--- Comment #15 from Joel Sherrill  2011-02-07 
01:13:51 UTC ---
ACATS results are not perfect but not bad for a first run.  

PASSED: 1984 FAILED  335

[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers

[blelbach at cct dot lsu.edu]

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

--- Comment #1 from Bryce Lelbach (wash)  
2011-02-07 01:00:28 UTC ---
Created attachment 23262
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23262
Fix for STL erase() methods on associative containers

[Bug libstdc++/47628] New: non-compliant C++0x erase methods on STL containers

[blelbach at cct dot lsu.edu]

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

   Summary: non-compliant C++0x erase methods on STL containers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blelb...@cct.lsu.edu


Apologizes if this has changed in the draft standard (my copy of n3092
indicates it hasn't):

As of r169874, std::set<>, std::map<>, std::multiset<>, std::multimap<>,
std::unordered_set<>, std::unordered_map<>, std::unordered_multiset<> and
std::unordered_multimap<> have C++0x erase methods; instead of taking an
`iterator' (or a range of `iterators' for some of the aforementioned
containers), the GNU implementation of these containers accept a
`const_iterator'. In ISO/IEC N3092, the specification of the erase() method is
in [associative.reqmts] (Section 23.2.4) table 99 and [unord.req] (Section
23.2.5) table 100.

I do not believe this problem affects the library in C++03/C++99 mode, as a
preprocessor macro selects the old C++99/C++03 version of erase(). This is
problematic in particular for std::map<>, where it can cause a call to erase()
to be ambigious. I noticed this problem when compiling the Boost.Signals
library (I'm a Boost developer) with a freshly built GCC 4.6.0.

Please find attached a patch against trunk that fixes this problem.

[Bug fortran/47267] array constructor causing long compile times

[dfranke at gcc dot gnu.org]

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

--- Comment #5 from Daniel Franke  2011-02-07 
00:34:00 UTC ---
Jerry, good luck with that one - I'm pretty sure that this is at least
implicitly related to PR42189. Can of Pandoras's Worms ahead :)

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu.org]

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

--- Comment #14 from Joel Sherrill  2011-02-07 
00:18:37 UTC ---
Created attachment 23261
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23261
Patch to use stub file

With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a
minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds Ada.

Is this OK to commit?

[Bug target/37073] -fno-math-errno should be the default on FreeBSD

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.06 23:19:10
 CC||gerald at pfeifer dot com
 Ever Confirmed|0   |1

--- Comment #2 from Gerald Pfeifer  2011-02-06 
23:19:10 UTC ---
I'll see what I can do about this.

[Bug fortran/47267] array constructor causing long compile times

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.06 23:16:02
 Ever Confirmed|0   |1

--- Comment #4 from Jerry DeLisle  2011-02-06 
23:16:02 UTC ---
This is fun.  We actually pass through the loop in array.c (expand_iterator)
four times, each time the trip count is Niter=3. There is no check of
the trip count before starting.

[Bug tree-optimization/47621] [4.6 Regression] Missed dependencies in address-taken optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-02-06 
23:08:39 UTC ---
Note to self:  Before the patch the code in the else branch never triggered.
The original idea was to preserve MEM[&a] re-writing into SSA form, which
didn't happen before the patch.  Re-writing the testcase in this PR would
also be nice, but I see other problems with this code (bit-field component-refs
come to my mind).

I have a patch.

[Bug tree-optimization/47621] [4.6 Regression] Missed dependencies in address-taken optimization

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.06 22:15:37
 CC|rguenther at suse dot de|
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
Summary|Missed dependencies in  |[4.6 Regression] Missed
   |address-taken optimization  |dependencies in
   ||address-taken optimization
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-02-06 
22:15:37 UTC ---
Mine.

[Bug libfortran/47567] Wrong output for small absolute values with F editing

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Jerry DeLisle  2011-02-06 
22:13:12 UTC ---
Fixed on trunk.  I don't think this is significant enough to justify a
back-port. I am not sure why anyone would use f1.X for anything, so this
exercise is largely academic. I do appreciate the bug reports. Thanks

[Bug fortran/47293] libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Jerry DeLisle  2011-02-06 
22:07:16 UTC ---
Fixed on trunk and google.  Google?  ;)

[Bug target/46898] libgcc build failure on lm32-elf

[lekernel at gcc dot gnu.org]

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

Sebastien Bourdeauducq  changed:

   What|Removed |Added

   Severity|normal  |critical

[Bug c/47623] [4.4/4.5/4.6 Regression] false *negative* uninitialized warning

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|tree-optimization   |c

--- Comment #2 from H.J. Lu  2011-02-06 21:32:29 
UTC ---
This regression is triggered by revision 133341:

http://gcc.gnu.org/ml/gcc-cvs/2008-03/msg00560.html

[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

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

--- Comment #51 from Manuel López-Ibáñez  2011-02-06 
20:48:38 UTC ---
BTW, anyone interested in fixing this may want to take a look at the newest
proposal for improving Wuninitialized in Clang:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013170.html

They specifically mention the issues of GCC's implementation and how they plan
to address them. Nevertheless, there are several problems for implementing
Clang's approach in GCC. First, they prefer to have false positives (a false
warning) than false negatives (a missed correct warning), whereas GCC tries as
hard as possible to not warn when it shouldn't.  Second, their proposal makes
use of the static analysis checker build into clang, which GCC does not have
(and probably never will) in its front-ends.

[Bug rtl-optimization/47420] [4.6 regression] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code for mingw

[silver24k at gmail dot com]

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

--- Comment #8 from Yu Simin  2011-02-06 20:40:34 
UTC ---
I used git-bisect and found it is caused by r166555.

Author: hubicka
Date: Wed Nov 10 20:23:09 2010
New Revision: 166555

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166555
Log:
PR tree-optimize/46228
* doc/invoke.texi (comdat-sharing-probability): Document.
* ipa-inline.c (cgraph_estimate_growth): Handle COMDATs
* params.def (PARAM_COMDAT_SHARING_PROBABILITY): New param.
* g++.dg/tree-ssa/pr46228.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr46228.C
Modified:
trunk/gcc/doc/invoke.texi
trunk/gcc/ipa-inline.c
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||zackw at panix dot com

--- Comment #50 from Manuel López-Ibáñez  2011-02-06 
20:25:13 UTC ---
*** Bug 47623 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/47623] [4.4/4.5/4.6 Regression] false *negative* uninitialized warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  2011-02-06 
20:25:13 UTC ---
If this testcase works in GCC 4.3.5 is just by chance. This is the old PR18501.
There is plenty of analysis, discussion and proposals there for anyone
interested in giving it a try.

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

[Bug target/47619] ICE in printf() with -fsplit-stack enabled.

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID

--- Comment #4 from Pawel Sikora  2011-02-06 20:22:53 
UTC ---
(In reply to comment #3)
> Thanks for the bug report.  If you are not using the gold linker, then this
> kind of thing is expected behaviour.  The problem is that glibc itself was not
> compiled with -fsplit-stack.  gold knows how to fix up that kind of call; the
> GNU linker does not.  This is mentioned in the documentation for the
> -fsplit-stack option.
> 
> So: where you using the gold linker?

yup, i'm using the classic (bfd) linker.
the http://gcc.gnu.org/wiki/SplitStacks doesn't explictly mention
that gold linker is required. my fault :(

[Bug c++/47626] internal compiler error: in print_reg (only for i686, and i486, not x86_64)

[lappisstudent at hotmail dot com]

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

--- Comment #1 from Simon Gustafsson  
2011-02-06 20:21:09 UTC ---
Removed my ppl and cloog libraries, and recompiled the 4.4.6 gcc snapshot. I
still get the same internal compiler error, so not dependant on those...

[Bug c++/47627] New: Internal error at specialization of template class with enum type.

[samuel.hangouet at gmail dot com]

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

   Summary: Internal error at specialization of template class
with enum type.
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: samuel.hango...@gmail.com


Created attachment 23260
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23260
g++ test.i to reproduce the problem.

(Same problem with g++-4.4.5)

$ g++-4.5 test.i

test.cpp: In member function ‘const char* Enum::serialize()’:
test.cpp:14:14: internal compiler error: in parameter_of_template_p, at
cp/pt.c:7189
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ uname -a
Linux limar 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011
x86_64 GNU/Linux

$ g++-4.5 -v
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold
--with-plugin-ld=ld.gold --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.5.1 (Ubuntu/Linaro 4.5.1-7ubuntu2)

[Bug libstdc++/47560] [4.6 Regression] FAIL: abi/header_cxxabi.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  2011-02-06 
19:46:12 UTC ---
I haven't got back to hppa2.0w-hp-hpux11.11 yet, but the change results
in the following on hppa64-hp-hpux11.11:

FAIL: abi/header_cxxabi.c (test for excess errors)
Excess errors:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.1
1/bits/os_defines.h:61:1: error: unknown type name 'namespace'
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.1
1/bits/os_defines.h:62:1: error: expected '=', ',', ';', 'asm' or
'__attribute__
' before '{' token

[Bug target/47619] ICE in printf() with -fsplit-stack enabled.

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.02.06 19:37:49
 CC||ian at airs dot com
 AssignedTo|unassigned at gcc dot   |ian at airs dot com
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Ian Lance Taylor  2011-02-06 19:37:49 
UTC ---
Thanks for the bug report.  If you are not using the gold linker, then this
kind of thing is expected behaviour.  The problem is that glibc itself was not
compiled with -fsplit-stack.  gold knows how to fix up that kind of call; the
GNU linker does not.  This is mentioned in the documentation for the
-fsplit-stack option.

So: where you using the gold linker?

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[Kicer86 at gmail dot com]

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

Michał Walenciak  changed:

   What|Removed |Added

 CC||Kicer86 at gmail dot com

--- Comment #3 from Michał Walenciak  2011-02-06 
19:30:06 UTC ---
Another idea is to simplify virtual calls.
At the final link, probably most of the virtual calls could be converted into
regural calls (as whole program is known, and some base classes may have only
one (or zero) descendant, so all virtual calls will affect only it).

[Bug c++/47626] New: internal compiler error: in print_reg (only for i686, and i486, not x86_64)

[lappisstudent at hotmail dot com]

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

   Summary: internal compiler error: in print_reg (only for i686,
and i486, not x86_64)
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lappisstud...@hotmail.com


Created attachment 23259
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23259
minimal code to trigger internal compiler error

Attached code triggers an internal compiler error for these versions of gcc
(when 32-bit build, host, and target supplied to configure)
gcc version 4.4.5 (GCC)
gcc version 4.4.6 20110201 (prerelease) (GCC)
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) <==fails for 32-bit, does however
work for x86_64 variants

Attached code does however work on "gcc version 4.5.2 (GCC)".

System type: Ubuntu 10.10 running under virtualbox, ubuntu 10.04 on an atom
N270, and a friends laptop.

cmdline triggering bug: gcc -c -O3 -o main.o main.cc

Error messages:
=[gcc version 4.4.5 (GCC)]=
main.cc: In function ‘int main(int, char**)’:
main.cc:41: internal compiler error: in print_reg, at config/i386/i386.c:10678
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

=[gcc version 4.4.6 20110201 (prerelease) (GCC)]=
main.cc: In function ‘int main(int, char**)’:
main.cc:41: internal compiler error: in print_reg, at config/i386/i386.c:10717
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

=[gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)]=
main.cc: In function ‘int main(int, char**)’:
main.cc:41: internal compiler error: in print_reg, at config/i386/i386.c:10811
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

=[gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)]=
main.cc: In function ‘int main(int, char**)’:
main.cc:41: internal compiler error: in print_reg, at config/i386/i386.c:10673
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Configurations:
=[gcc version 4.4.5 (GCC)]=
Using built-in specs.
Target: i686-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --prefix=/usr/local
--program-suffix=-4.4.5_ppl --enable-clocale=gnu --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (GCC)

=[gcc version 4.4.6 20110201 (prerelease) (GCC)]=
Using built-in specs.
Target: i686-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --prefix=/usr/local
--program-suffix=-4.4-20110201_ppl --enable-clocale=gnu --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix


=[gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)]=
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

=[gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)]=
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --enable-multiarch --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)


Additional information:
This is probably related to #47596, which was marked as "resolved" since it
worked for a few tested releases (target was i68

[Bug rtl-optimization/47420] [4.6 regression] ICE: in calc_dfs_tree, at dominance.c:395 with c++ code for mingw

[silver24k at gmail dot com]

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

Yu Simin  changed:

   What|Removed |Added

Summary|ICE: in calc_dfs_tree, at   |[4.6 regression] ICE: in
   |dominance.c:395 with c++|calc_dfs_tree, at
   |code|dominance.c:395 with c++
   ||code for mingw

--- Comment #7 from Yu Simin  2011-02-06 18:38:29 
UTC ---
Still fails with r169851. 
Both Linux/x86 and arm-none-eabi versions are OK. Seem it is mingw32 (maybe
also cygwin ?) only.

mingw32-gcc -c -O2 test.cpp  --  ICE
mingw32-gcc -c -O2 -fno-exceptions test.cpp  --  OK
mingw32-gcc -c -O2 -fno-partial-inlining test.cpp--  OK

[Bug lto/47625] New: FAIL: gcc.dg/guality/pr43077-1.c -O2 -flto -flto-partition=none line 42 a == 1

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

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

   Summary: FAIL: gcc.dg/guality/pr43077-1.c  -O2 -flto
-flto-partition=none  line 42 a == 1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
Target: powerpc*-*-*


Breakpoint 1, fn3 ()
at /daten/gcc/gcc-20110206/gcc/testsuite/gcc.dg/guality/pr43077-1.c:44
44  }
(gdb) whatis a
type = const number
(gdb) ptype a
type = union {
int i[2];
double d;
}(gdb) i addr a
Symbol "a" is static storage at address 0xffbc4f0.

[Bug c/47623] [4.4/4.5/4.6 Regression] false *negative* uninitialized warning

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.06 18:11:40
  Known to work||4.3.5
Summary|false *negative*|[4.4/4.5/4.6 Regression]
   |uninitialized warning   |false *negative*
   ||uninitialized warning
 Ever Confirmed|0   |1

[Bug debug/47624] New: FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3

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

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

   Summary: FAIL: gcc.dg/guality/pr43077-1.c  -O1  line 42 c == 3
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
Target: powerpc*-*-*


Breakpoint 1, fn3 ()
at /daten/gcc/gcc-20110206/gcc/testsuite/gcc.dg/guality/pr43077-1.c:44
44  }
(gdb) i addr c
Symbol "c" is a complex DWARF expression:
 1: DW_OP_breg4 12 [$r4]
.
(gdb) disass
Dump of assembler code for function fn3:
   0x14e0 <+0>: stwur1,-32(r1)
   0x14e4 <+4>: mflrr0
   0x14e8 <+8>: stw r0,36(r1)
   0x14ec <+12>:li  r0,0
   0x14f0 <+16>:stw r0,8(r1)
   0x14f4 <+20>:mr  r4,r1
   0x14f8 <+24>:stwur0,12(r4)
   0x14fc <+28>:addir3,r1,8
   0x1500 <+32>:bl  0x14c4 
=> 0x1504 <+36>:lwz r0,36(r1)
   0x1508 <+40>:mtlrr0
   0x150c <+44>:addir1,r1,32
   0x1510 <+48>:blr
End of assembler dump.

c is not at $r4+12 but at $r4+0 (or $r1+12) because $r4 has been incremented
when the value was stored.

[Bug c/47623] New: false *negative* uninitialized warning

[zackw at panix dot com]

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

   Summary: false *negative* uninitialized warning
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: za...@panix.com


Consider

int foo(int x)
{
   int a;
   if (x) return a;
   return 0;
}

This function should trigger the "‘a’ may be used uninitialized" warning when
compiled with -O -Wall, but it doesn't; there are no diagnostics at all.  The
assembly output (x86-64) is just

foo:
movl$0, %eax
ret

Looking at optimization dumps, this is what we have right before CCP1:

foo (int x)
{
  int a;

:
  if (x_2(D) != 0)
goto ;
  else
goto ;

:
  a_4 = a_3(D);
  goto ;

:
  a_5 = 0;

:
  # a_1 = PHI 
  return a_1;
}

but right *after* CCP1, we have instead

:
  # a_1 = PHI 
  return 0;

-- I presume that CCP notices that one of the inputs to the PHI is undefined
and ignores that possibility under the "well, if that happened, there would be
undefined behavior, so we can assume that can't happen" principle.  CDDCE1 then
erases the remainder of the code and we're left with

foo (int x)
{
:
  return 0;
}

which has no uninitialized variable accesses, of course.  I'm not sure exactly
where uninitialized warnings happen these days, but clearly it's after this
point.

As far as a fix, I recommend either that any pass that can make use of the
"that variable is uninitialized so we're going to ignore the possibility of
that control path" principle should emit -Wuninitialized warnings, or (my
personal preference) we scrap the notion of doing -Wuninitialized from inside
the optimizers, and switch to something predictable, like Java's definite
assignment rules.

[Bug fortran/45290] [F08] pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org 2011-02-06 17:42:35 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> >   procedure(), pointer :: ptr3 => p2
> 
> I now believe that this is invalid (all quotes are F2008):
> 
> R505 initialization is [...]  or  => initial-data-target
> R443 initial-data-target  is  designator
> 
> C461 (R443) The designator shall designate a nonallocatable variable that has
> the TARGET and SAVE attributes and does not have a vector subscript. Every
> subscript, section subscript, substring starting point, and substring ending
> point in designator shall be a constant expression.
> 
> 
> Well, in the example (cf. also the ICE in comment 5) "p2" is a POINTER and a
> pointer cannot have the TARGET attribute (cf. C556).
> 
> Thus, the "initial-data-target" can neither be a pointer nor a proc-pointer.

Ok, I agree. Also I remember that we already had some discussion about this
when I committed the first patch for this PR, without any consensus.


Let's compare the above C461 to the corresponding restriction for normal
pointer assignment ...

R737 data-target is variable

C724 (R737) A variable shall have either the TARGET or POINTER attribute, and
shall not be an array section with a vector subscript.

... which explicitly allows both the TARGET and POINTER attribute, while C461
only allows the TARGET attribute.


In conclusion, I propose the following patch:

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 169853)
+++ gcc/fortran/expr.c  (working copy)
@@ -3608,7 +3608,7 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_expr
 "must not be ALLOCATABLE ");
  return FAILURE;
}
-  if (!attr.target)
+  if (!attr.target || attr.pointer)
{
  gfc_error ("Pointer initialization target at %C "
 "must have the TARGET attribute");


We have to explicitly demand that the rhs of the pointer initialization does
not have the POINTER attribute, since gfc_expr_attr gives the TARGET attribute
also to POINTER expressions (probably because the thing that the pointer points
to has the TARGET attribute).


The patch correctly rejects the two invalid lines in the following test case:

module m
 implicit none
 type :: t
   integer, pointer :: p
   integer :: i
 end type
 integer, target :: i
 type(t), target :: x
 integer, pointer :: p1 => i
 integer, pointer :: p2 => p1   ! invalid
 integer, pointer :: p3 => x%p  ! invalid
 integer, pointer :: p4 => x%i
end module m

[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  2011-02-06 16:57:48 
UTC ---
(In reply to comment #7)
> > Honza?  Why is -fwhole-program not ignored, or why should it not be?
> > Why does it make a difference at all here?
> Well, it is effectively ignored - i.e. on symbols with resolution info 
> attached
> it should do nothing.  So it seems we fail to get resolution info from plugin
> correctly.  I will check.
> 
> Honza

Any updates on this?

[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org,
   ||tschwinge at gcc dot
   ||gnu.org

--- Comment #21 from Thomas Schwinge  2011-02-06 
16:44:53 UTC ---
Yesterday, I it a similar problem when building GCC --target=i586-pc-gnu
(with all-gcc), and the lto-plugin was built, and was meant to be used,
but the gcc installed with install-gcc wasn't usable (failing to find the
shared library) unless I also did invoke install-lto-plugin.  I was just
about to submit a patch, but first update to current trunk source --
where Kai had just fixed the problem in exactly the same way I meant to,
thus thanks for that!

As for me, this can be set to RESOLVED, FIXED.

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

[ghazi at gcc dot gnu.org]

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

--- Comment #54 from Kaveh Ghazi  2011-02-06 16:43:38 
UTC ---
(In reply to comment #53)
> I think we should fix this by patching in a new linkage name for the routine 
> in
> question with darwin_patch_builtins and creating a forwarding stub from the 
> old
> name to the new name that we link against.  We could mix in _ieee into the new
> name.  If we compile with -fast-math we can call the old routine, no patch, 
> and
> if one wants accuracy, the we call the new name.

I believe GCC already does the "fast" method in some situations.  See
tree-complex.c:expand_complex_division().  It switches on flag_complex_method,
the difference is that the operation is done inline rather than a libcall.  I'm
foget under what circumstances flag_complex_method triggers, but GCC may
already do what you propose in some fashion.

--Kaveh

[Bug c/47617] SSE rounding mode works -g, not -O3

[cck0011 at yahoo dot com]

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

--- Comment #2 from cck0011 at yahoo dot com 2011-02-06 16:25:55 UTC ---
(In reply to comment #1)
> I think you need to use -frounding-math.  GCC assumes by default the rounding
> mode is round-to-nearest.  See
> http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Optimize-Options.html#index-frounding_002dmath-819
> .

Hi Andrew, 

  thanks for writing. I tried -frounding-math and the result is still the same.
Adding/removing -mfpmath=sse doesn't change it either. Is there any additional
information I can provide?

Thanks!

[Bug debug/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2011-02-06 16:05:29 UTC ---
Attached dumps.

[Bug debug/47622] New: [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"

[danglin at gcc dot gnu.org]

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

   Summary: [4.6 Regression] FAIL: gcc.dg/pr42631.c
scan-rtl-dump-not web "Web oldreg"
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
CC: j...@gcc.gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11


Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr42631.c   -g -O1 -funroll-loops
-fcompare-
debug -fdump-rtl-web -S  -o pr42631.s(timeout = 300)
PASS: gcc.dg/pr42631.c (test for excess errors)
FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"

[Bug tree-optimization/47621] New: Missed dependencies in address-taken optimization

[uweigand at gcc dot gnu.org]

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

   Summary: Missed dependencies in address-taken optimization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uweig...@gcc.gnu.org
CC: rguent...@suse.de


The following program is mis-optimized with 4.6 (not earlier versions) at -O or
higher optimization levels:

int
main (void)
{
  int data = 1;

  struct ptr
{
  int val;
} *ptr = (struct ptr *) &data;

  ptr->val = 0;

  return data;
}

This program should return 0, but actually returns 1.

After the "address-taken" optimization pass, we have:

  dataD.1975_4 = 1;
  MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
  D.3453_2 = dataD.1975_4;
  return D.3453_2;

so the dependency between the assignment to ptr->val and the use of data is
lost.

See this post for more information:
http://gcc.gnu.org/ml/gcc/2011-02/msg00079.html

H.J. Lu identified the following patch as introducing the regression:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00788.html

[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

[ktietz at gcc dot gnu.org]

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

--- Comment #20 from Kai Tietz  2011-02-06 15:06:58 
UTC ---
Author: ktietz
Date: Sun Feb  6 15:06:56 2011
New Revision: 169863

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169863
Log:
2011-02-06  Kai Tietz  

PR lto/47225
* Makefile.def: Add dependency for install-gcc
on install-lto-plugin.
* Makfile.in: Regenerated


Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in

[Bug fortran/47592] Multiple function invocation with ALLOCATE (SOURCE=REPEAT('x',bar()))

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Paul Thomas  2011-02-06 14:25:00 
UTC ---
Fixed on trunk.

Thanks, Thomas.

Paul

[Bug fortran/47592] Multiple function invocation with ALLOCATE (SOURCE=REPEAT('x',bar()))

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  2011-02-06 14:22:51 
UTC ---
Author: pault
Date: Sun Feb  6 14:22:48 2011
New Revision: 169862

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169862
Log:
2011-02-06  Paul Thomas  

PR fortran/47592
* trans-stmt.c (gfc_trans_allocate): For deferred character
length allocations with SOURCE, store to the values and string
length to avoid calculating twice.  Replace gfc_start_block
with gfc_init_block to avoid unnecessary contexts and to keep
declarations of temporaries where they should be. Tidy up the
code a bit.

2011-02-06  Paul Thomas  

PR fortran/47592
* gfortran.dg/allocate_with_source_1 : New test.


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

[Bug rtl-optimization/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #2 from Jakub Jelinek  2011-02-06 
13:06:32 UTC ---
Doesn't fail with ./cc1 -m32 -O2 ice.i -quiet -fprofile-use
The ICE is because queue_insn is called with a DEBUG_INSN.

[Bug rtl-optimization/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-02-06 
13:02:56 UTC ---
Created attachment 23256
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23256
ice.gcda

The corresponding *.gcda file.

[Bug rtl-optimization/47620] New: [4.6 Regression] Profiledbootstrap failure on powerpc-linux

[jakub at gcc dot gnu.org]

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

   Summary: [4.6 Regression] Profiledbootstrap failure on
powerpc-linux
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org
Target: powerpc64-linux


Created attachment 23255
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23255
ice.i

32-bit powerpc64-linux --with-cpu=default32 bootstrap on the trunk fails with
ICE in queue_insn, suspect change are the recent -fcompare-debug scheduler
changes.

./cc1 -m32 -g -O2 ice.i -quiet -fprofile-use
../../gcc/cfganal.c: In function ‘find_unreachable_blocks’:
../../gcc/cfganal.c:327:1: internal compiler error: in queue_insn, at
haifa-sched.c:1322
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

can be reproduced even with cross-compiler.

[Bug fortran/45516] [F08] allocatable compontents of recursive type

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-02-06 12:36:40 UTC ---
With the patch in comment #4, we currently get an ICE on the following test
case:


type entry1
  real :: value
  type(entry1), allocatable :: next
end type entry1

type(entry1), allocatable :: x

allocate(x)

end


The problem is that we run into an infinite loop when trying to auto-deallocate
x and the whole chain of its components, cf. gfc_deallocate_scalar_with_status,
gfc_deallocate_alloc_comp and structure_alloc_comps.

[Bug fortran/45516] [F08] allocatable compontents of recursive type

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2011-02-06 12:28:42 UTC ---
We also need to adjust gfc_get_derived_type, to avoid running into an infinite
loop. Updated patch:


Index: gcc/testsuite/gfortran.dg/class_2.f03
===
--- gcc/testsuite/gfortran.dg/class_2.f03(revision 169853)
+++ gcc/testsuite/gfortran.dg/class_2.f03(working copy)
@@ -36,7 +36,7 @@ end interface

 type t6
   integer :: i
-  class(t6), allocatable :: foo  ! { dg-error "must have the POINTER
attribute" }
+  class(t6) :: foo  ! { dg-error "must be POINTER or ALLOCATABLE" }
 end type t6


Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 169853)
+++ gcc/fortran/decl.c(working copy)
@@ -1515,14 +1515,20 @@ build_struct (const char *name, gfc_charlen *cl, g
   gfc_component *c;
   gfc_try t = SUCCESS;

-  /* F03:C438/C439. If the current symbol is of the same derived type that
we're
- constructing, it must have the pointer attribute.  */
+  /* F03:C438/C439, F08:C440. If the current symbol is of the same derived
type
+ that we're constructing, it must be POINTER or ALLOCATABLE.  */
   if ((current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
   && current_ts.u.derived == gfc_current_block ()
   && current_attr.pointer == 0)
 {
-  gfc_error ("Component at %C must have the POINTER attribute");
-  return FAILURE;
+  if (gfc_notify_std (GFC_STD_F2008, "Component at %C must have the "
+  "POINTER attribute") == FAILURE)
+return FAILURE;
+  else if (current_attr.allocatable == 0)
+{
+  gfc_error ("Component at %C must be POINTER or ALLOCATABLE");
+  return FAILURE;
+}
 }

   if (gfc_current_block ()->attr.pointer && (*as)->rank != 0)
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c(revision 169853)
+++ gcc/fortran/trans-types.c(working copy)
@@ -2096,14 +2096,14 @@ gfc_get_derived_type (gfc_symbol * derived)
   /* Go through the derived type components, building them as
  necessary. The reason for doing this now is that it is
  possible to recurse back to this derived type through a
- pointer component (PR24092). If this happens, the fields
+ pointer or allocatable component. If this happens, the fields
  will be built and so we can return the type.  */
   for (c = derived->components; c; c = c->next)
 {
   if (c->ts.type != BT_DERIVED && c->ts.type != BT_CLASS)
 continue;

-  if ((!c->attr.pointer && !c->attr.proc_pointer)
+  if ((!c->attr.pointer && !c->attr.proc_pointer && !c->attr.allocatable)
   || c->ts.u.derived->backend_decl == NULL)
 c->ts.u.derived->backend_decl = gfc_get_derived_type (c->ts.u.derived);

[Bug tree-optimization/42893] [4.3/4.4/4.5/4.6 Regression] Missed conditionally dead store elimination

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #11 from Steven Bosscher  2011-02-06 
12:24:10 UTC ---
The test case should be added to the test suite.

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

[Kicer86 at gmail dot com]

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

Michał Walenciak  changed:

   What|Removed |Added

 CC||Kicer86 at gmail dot com

--- Comment #5 from Michał Walenciak  2011-02-06 
12:19:00 UTC ---
same problem in 4.5.2.
Maybe importance of this bug should be increased? Imho it's a little bit
embarrassing to keep this bug so long... (since 2008, over 3 yrs!)

regards

[Bug fortran/44529] [F03] array allocation with SOURCE

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  2011-02-06 
11:37:33 UTC ---
I don't think the example is valid F2003.

C628 (R628) An allocate-shape-spec-list shall appear if and only if the
allocate-object is an array.

This is relaxed in F 2008, though.

[Bug fortran/47616] ICE with allocate(a,source=(/1/))

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2011-02-06 
11:00:49 UTC ---
Related (same?): PR 44529

[Bug target/47619] ICE in printf() with -fsplit-stack enabled.

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

 Target||x86_64-gnu-linux
   Host||x86_64-gnu-linux
  Build||x86_64-gnu-linux

--- Comment #2 from Pawel Sikora  2011-02-06 10:19:41 
UTC ---
gcc-4.6.0-20110205, binutils-2.21.51.0.6, glibc-2.13.

[Bug target/47619] ICE in printf() with -fsplit-stack enabled.

[pluto at agmk dot net]

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

--- Comment #1 from Pawel Sikora  2011-02-06 10:17:05 
UTC ---
Created attachment 23254
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23254
testcase.

[Bug target/47619] New: ICE in printf() with -fsplit-stack enabled.

[pluto at agmk dot net]

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

   Summary: ICE in printf() with -fsplit-stack enabled.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


$ g++46 0.cpp -Wall -O1 -g2 -fsplit-stack

(gdb) r
Starting program: /home/users/pluto/src/gcc/PRs/a.out
i = 32768, rsp = 0x7fffdd30
i = 32767, rsp = 0x7fffdc20
i = 32766, rsp = 0x7fffdb10
(...)
i = 32705, rsp = 0x77ff8ab0
i = 32704, rsp = 0x77ff89a0
i = 32703, rsp = 0x77ff8890

Program received signal SIGSEGV, Segmentation fault.
_IO_new_file_xsputn (f=0x7763a7a0, data=0x401ae4, n=4) at fileops.c:1288

(gdb) bt 8
#0  _IO_new_file_xsputn (f=0x7763a7a0, data=0x401ae4, n=4) at
fileops.c:1288
#1  0x772f3e45 in _IO_vfprintf_internal (s=0x7763a7a0,
format=0x401ae4 "i = %ld, rsp = %p\n", ap=0x77ff86a0) at vfprintf.c:1314
#2  0x772feaba in __printf (format=) at
printf.c:35
#3  0x00400c89 in foo (i=) at 0.cpp:7
#4  0x00400ca7 in foo (i=) at 0.cpp:11
#5  0x00400ca7 in foo (i=) at 0.cpp:11
#6  0x00400ca7 in foo (i=) at 0.cpp:11
#7  0x00400ca7 in foo (i=) at 0.cpp:11