[Bug lto/47841] [4.6 Regression] New guality test failures

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-02-22 
08:08:08 UTC ---
And in case of
 FAIL: gcc.dg/guality/sra-1.c  -O2  line 43 a.j == 14
 FAIL: gcc.dg/guality/sra-1.c  -O3 -fomit-frame-pointer  line 43 a.j == 14
 FAIL: gcc.dg/guality/sra-1.c  -O3 -g  line 43 a.j == 14
 FAIL: gcc.dg/guality/sra-1.c  -Os  line 43 a.j == 14
+FAIL: gcc.dg/guality/sra-1.c  -O2 -flto -flto-partition=none  line 43 a.j ==
14
+FAIL: gcc.dg/guality/sra-1.c  -O2 -flto  line 43 a.j == 14

it is obviously a good thing that sra-1.c fails the same way with -flto as it
does without -flto, that means -flto is less buggier wrt. -g.

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[jb at gcc dot gnu.org]

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

--- Comment #13 from Janne Blomqvist  2011-02-22 
08:37:13 UTC ---
FWIW here's a glibc PR wrt overflowing the 26 byte limit:

http://sourceware.org/bugzilla/show_bug.cgi?id=1460

This was fixed in 2005, which is a while ago, but not long enough so it's
completely unimaginable that someone would want to run gfortran on such a
platform. For this particular glibc issue, a workaround is to make sure the
buffer is at least 33 bytes.

In any case, I'm thinking that Dave's suggestion to use strftime could work.
Also, in addition to the autoconf manual recommending to avoid ctime/ctime_r,
POSIX 2008 also marks those as obsolescent and recommends strftime instead.
strftime appears to have well defined behavior for all kinds of time input and
string lengths. And, using it would obviously also solve the problem of
non-standard ctime_r implementations. strftime needs localtime_r, but we have
already used that one without problems for quite a while (in the implementation
of the DATE_AND_TIME intrinsic) so it shouldn't cause any further portability
problems.

The caveat is that if using a non-default locale the output is different. In
practice, (lib)gfortran never calls setlocale so unless the application
explicitly calls it a gfortran program runs in the "C" locale, in which case a
suitable choice of format string guarantees identical output as ctime(). And,
if the applications does call setlocale, outputting a localized string could be
seen as a feature.

(In reply to comment #6)
> I guess the question we need to ask is how important are these routines
> and should we be issuing warnings when they are used, much like is done
> with gets.  If we don't need them, I'd much prefer to see them go away
> as they're a rats nest of security issues.

Standard Fortran, as of Fortran 2008, supports 3 time related intrinsics;
DATE_AND_TIME, SYSTEM_CLOCK, and CPU_TIME. Every other time intrinsic in
gfortran is due to legacy g77 support, or some other widely used extension. If
one compiles with one of the standards conformance options (-std=f) these
other intrinsics are not available. Personally, I'd be happy to get rid of all
the nonstandard time intrinsics, but some of our users might disagree..

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2011-02-22 
09:26:50 UTC ---
Well, if you don't want to localize, you can as well do it yourself, call
localtime_r and then simple:
char result[26];
int n = snprintf (result, sizeof (result), "%3.3s %3.3s%3d %.2d:%.2d:%.2d
%d\n",
  "SunMonTueWedThuFriSat" + tm->tm_wday * 3,
  "JanFebMarAprMayJunJulAugSepOctNovDec" + tm->tm_mon * 3,
  tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec, 1900 +
tm->tm_year);
if ((size_t) n >= sizeof (result))
  result[0] = '\0'; /* The result didn't fit into 26 bytes.  */ 
(or use larger buffer, perhaps you can just snprintf into the caller provided
buffer instead and depending on return value from snprintf just memset to ' '
the rest of the string if there are still any bytes left in it.

[Bug fortran/47846] New: Deferred-string length: Length is wrong

[burnus at gcc dot gnu.org]

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

   Summary: Deferred-string length: Length is wrong
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org


The test case allocate_deferred_char_scalar_1.f03 fails if one applies the
following patch. It abort in line 178:
if(len(a) /= 50) call abort()

On my system "len(a)" is 0


--- a/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
+++ b/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
@@ -1,4 +1,4 @@
-! { dg-do run}
+! { dg-do run }
 !
 ! Automatic reallocate on assignment, deferred length parameter for char
 !

[Bug target/47847] New: PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double

[sebastian.hu...@embedded-brains.de]

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

   Summary: PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common
-mfloat-gprs=double
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: powerpc-rtems4.11-gcc


Created attachment 23432
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23432
Sample code.

Using the embedded 64-bit floating-point unit causes an internal compiler error
in combination with the small data area:

powerpc-rtems4.11-gcc -c paranoia.i -mcpu=8540 -meabi -msdata -fno-common
-mfloat-gprs=double -mabi=spe
/home/sh/rtems-sync/c/src/../../testsuites/samples/paranoia/paranoia.c: In
function 'paranoia':
/home/sh/rtems-sync/c/src/../../testsuites/samples/paranoia/paranoia.c:1955:1:
internal compiler error: output_operand: invalid %y value, try using the 'Z'
constraint

[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.

[mexas at bristol dot ac.uk]

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

--- Comment #24 from Anton Shterenlikht  2011-02-22 
09:41:48 UTC ---
The error now is:

libtool: compile:  /usr/ports/lang/gcc46/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc46/work/build/./
gcc/ -B/usr/local/ia64-portbld-freebsd9.0/bin/
-B/usr/local/ia64-portbld-freebsd9.0/lib/ -isystem /u
sr/local/ia64-portbld-freebsd9.0/include -isystem
/usr/local/ia64-portbld-freebsd9.0/sys-include -DH
AVE_CONFIG_H -I. -I../.././../gcc-4.6-20110212/libgfortran
-iquote../.././../gcc-4.6-20110212/libgfo
rtran/io -I../.././../gcc-4.6-20110212/libgfortran/../gcc
-I../.././../gcc-4.6-20110212/libgfortran/
../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules
-ffunction-sections -fdata-section
s -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -MT backtrace.lo -MD
-MP -MF .deps/backtrac
e.Tpo -c ../.././../gcc-4.6-20110212/libgfortran/runtime/backtrace.c  -fPIC
-DPIC -o .libs/backtrace
.o
In file included from ../.././../gcc-4.6-20110212/libgfortran/fmain.c:4:0:
../.././../gcc-4.6-20110212/libgfortran/libgfortran.h:53:29: fatal error:
quadmath_weak.h: No such f
ile or directory
compilation terminated.
In file included from
../.././../gcc-4.6-20110212/libgfortran/runtime/backtrace.c:25:0:
../.././../gcc-4.6-20110212/libgfortran/libgfortran.h:53:29: fatal error:
quadmath_weak.h: No such f
ile or directory
compilation terminated.
gmake[3]: *** [fmain.lo] Error 1
gmake[3]: *** Waiting for unfinished jobs
gmake[3]: *** [backtrace.lo] Error 1
gmake[3]: Leaving directory
`/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgfortran'

Please see also:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648

[Bug c++/47488] [4.4/4.5/4.6 Regression] (sizeof|decltype) + template + string literals: ICE in write_template_arg_literal, at cp/mangle.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/47705] [4.5/4.6 Regression] internal compiler error: in convert_nontype_argument, at cp/pt.c:5006

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug middle-end/47735] [4.5/4.6 Regression] Unnecessary adjustments to stack pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug lto/47841] [4.6 Regression] New guality test failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #4 from Richard Guenther  2011-02-22 
09:51:26 UTC ---
Indeed.  Also compare to -fwhole-file (non-LTO) guality.

[Bug middle-end/47691] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1138 with -fgraphite-identity -ffast-math -fno-tree-scev-cprop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug lto/47841] [4.6 Regression] New guality test failures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.

[gerald at pfeifer dot com]

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

--- Comment #25 from Gerald Pfeifer  2011-02-22 
10:09:23 UTC ---
(In reply to comment #24)
> The error now is:

That's a different one, Anton.  You'll need to wait for it to be
resolved before we can proceed with the issue on HEAD.  (I'll update
lang/gcc46 in the next hours in case you are waiting for that to kick
off new testing.)

[Bug fortran/47846] Deferred-string length: Length is wrong

[paul.richard.thomas at gmail dot com]

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

--- Comment #1 from paul.richard.thomas at gmail dot com  2011-02-22 10:09:57 UTC ---
Jerry,

You are not the only one :-)

Tobias, I'll take a look-see tonight.

Cheers

Paul

On Tue, Feb 22, 2011 at 10:31 AM, burnus at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846
>
>           Summary: Deferred-string length: Length is wrong
>           Product: gcc
>           Version: 4.6.0
>            Status: UNCONFIRMED
>          Keywords: wrong-code
>          Severity: normal
>          Priority: P3
>         Component: fortran
>        AssignedTo: unassig...@gcc.gnu.org
>        ReportedBy: bur...@gcc.gnu.org
>                CC: pa...@gcc.gnu.org
>
>
> The test case allocate_deferred_char_scalar_1.f03 fails if one applies the
> following patch. It abort in line 178:
>    if(len(a) /= 50) call abort()
>
> On my system "len(a)" is 0
>
>
> --- a/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
> +++ b/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
> @@ -1,4 +1,4 @@
> -! { dg-do run}
> +! { dg-do run }
>  !
>  ! Automatic reallocate on assignment, deferred length parameter for char
>  !
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

[Bug fortran/41359] Wrong line numbers for debugging/profiling

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  2011-02-22 
10:23:17 UTC ---
Author: burnus
Date: Tue Feb 22 10:23:14 2011
New Revision: 170394

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170394
Log:
2011-02-22  Tobias Burnus  

PR fortran/41359
* trans-stmt.c (gfc_trans_if_1): Use correct line for
expressions in the if condition.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c

[Bug fortran/41359] Wrong line numbers for debugging/profiling

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Tobias Burnus  2011-02-22 
10:26:23 UTC ---
FIXED on the trunk (4.6). Thanks for the report, Edouard, and sorry for needing
one and a half years for fixing it.

[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.

[mexas at bristol dot ac.uk]

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

--- Comment #26 from Anton Shterenlikht  2011-02-22 
10:30:43 UTC ---
yes, I lost track of various issues and versions..

I'll test it when you are ready.

At present I'm particularly keen
on testing Fortran 2003 IEEE exception
handling.

Many thanks for your support, Gerald.

[Bug fortran/41359] Wrong line numbers for debugging/profiling

[Edouard.Canot at irisa dot fr]

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

--- Comment #12 from Edouard.Canot at irisa dot fr 2011-02-22 10:36:41 UTC ---
On Tuesday 22 February 2011 11:26:53 you wrote:
(quoting "burnus at gcc dot gnu.org" )
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359
> 
> Tobias Burnus  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution||FIXED
> 
> --- Comment #11 from Tobias Burnus  2011-02-22 
> 10:26:23 UTC ---
> FIXED on the trunk (4.6). Thanks for the report, Edouard, and sorry for 
> needing
> one and a half years for fixing it.
> 

Thanks for you, too. You are welcome.
Regards,
Édouard Canot

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  
2011-02-22 10:44:47 UTC ---
At revision 170376 (comment #21), the "fix" of revision 170339 (comment #6)
seems no longer needed on powerpc-apple-darwin9 and x86_64-apple-darwin10,
i.e., after reverting revision 170339 on r170376, the tests in
gcc.c-torture/execute/builtins/ and gfortran.dg/lto/ pass without failures.

Thanks for the fix.

[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine "optimizing two comparisons to x_[0-9]+\(D\) != 4"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.22 10:47:01
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-02-22 
10:47:01 UTC ---
I think the difference is because of different initial IL from gimplification
(BRANCH_COST).  On x86 we have

  D.2701 = x != 4;
  D.2702 = x != 6;
  D.2703 = D.2701 && D.2702;
  if (D.2703 != 0) goto ; else goto ;
  :
  D.2705 = x == 2;
  D.2706 = x == 6;
  D.2707 = D.2705 || D.2706;
  if (D.2707 != 0) goto ; else goto ;

this is really a missed optimization in ifcombine, possibly fixed by
later jump-threading for your target.  The result on x86 is

:
  D.2701_3 = x_2(D) != 4;
  D.2702_4 = x_2(D) != 6;
  D.2703_5 = D.2701_3 & D.2702_4;
  D.2705_6 = x_2(D) == 2;
  D.2706_7 = x_2(D) == 6;
  D.2707_8 = D.2705_6 | D.2706_7;
  if (x_2(D) != 4)
goto ;
  else
goto ;

:
Invalid sum of incoming frequencies 400, should be 244

:
Invalid sum of incoming frequencies 9844, should be 1
  # D.2708_1 = PHI <1(2), -1(3)>
  return D.2708_1;


Consider XFAILing the test for your target(s).

[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2011-02-22 
10:51:58 UTC ---
Created attachment 23433
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23433
gcc46-pr46790.patch

The last mentioned variant, which instead of doing configury puts stuff into
.gcc_except_table.startup.main, .gcc_except_table.exit.foo,
.gcc_except_table.unlikely.bar or .gcc_except_table.hot.baz style sections.
Briefly tested with the old and new linker that the testcase is fixed.

[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized "fundamentals..0"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.22 10:56:25
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-02-22 
10:56:25 UTC ---
IVOPTs chooses (again) some unfortunate IV that is enough to confuse the
tree-dump scan.

  ivtmp.6_6 = (long unsigned int) &fundamentals[1];

vs.

  ivtmp.6_6 = (long unsigned int) &fundamentals[0];

The folding that is tested for should happen at loop header copying time.

Can you check if

Index: testsuite/gcc.dg/tree-ssa/foldconst-2.c
===
--- testsuite/gcc.dg/tree-ssa/foldconst-2.c (revision 170359)
+++ testsuite/gcc.dg/tree-ssa/foldconst-2.c (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-options "-O2 -fdump-tree-ch" } */
 typedef union tree_node *tree;
 enum tree_code
 {
@@ -54,5 +54,5 @@ emit_support_tinfos (void)
 }
 /* We should copy loop header to fundamentals[0] and then fold it way into
known value.  */
-/* { dg-final { scan-tree-dump-not "fundamentals.0" "optimized"} } */
-/* { dg-final { cleanup-tree-dump "optimized" } } */
+/* { dg-final { scan-tree-dump-not "fundamentals.0" "ch"} } */
+/* { dg-final { cleanup-tree-dump "ch" } } */

works for you (it does for me) and commit it if so?

Thanks.

[Bug fortran/47648] libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such file or directory - FreeBSD ia64

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-02-22 
10:57:48 UTC ---
STATUS:

- libgfortran uses the same check as libquadmath;
  thus, there should be no build issue anymore as
  libquadmath support is disabled for libgfortran.
  (The Fortran FE still can generate calls for REAL(16).)

- The issue that on FreeBSD libquadmath is not supported remains unsolved.
  The problem is that some support (_U_Q*) is missing.
  The support could come either from FreeBSD's libc or from libgcc.
  Cf. bug 47649 comment 5.

[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.22 10:58:29
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-02-22 
10:58:29 UTC ---
"forces"?  GCC re-aligns the stack if it thinks it is a good idea for
performance.  Or do you mean something else?  Please be more specific.

[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment

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

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

--- Comment #2 from Andreas Schwab  2011-02-22 11:06:41 
UTC ---
A 16-byte aligned stack is still word aligned.

[Bug target/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

[sebastian.hu...@embedded-brains.de]

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

--- Comment #3 from Sebastian Huber  
2011-02-22 11:18:29 UTC ---
(In reply to comment #2)
> -mfloat-gprs=double or -mspe without -mabi=spe does not correspond to any 
> standard ABI variant and is very likely to be broken.

Thanks for the hint.  Adding the -mabi=spe option fixed the problem.  A notice
in the -mfloat-gprs description of the documentation would be nice.

[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-02-22 
11:46:04 UTC ---
I think this also hints at possible DECL issues with imported vars.  You can
see how the C frontend handles the function/block local externs around
c-decl.c:1206

  else if (VAR_OR_FUNCTION_DECL_P (p))
{
  /* For block local externs add a special
 DECL_EXTERNAL decl for debug info generation.  */
  tree extp = copy_node (p);
...

The following fixes the testcase for me (not further tested):

Index: gcc/fortran/f95-lang.c
===
--- gcc/fortran/f95-lang.c  (revision 170359)
+++ gcc/fortran/f95-lang.c  (working copy)
@@ -498,13 +498,20 @@ poplevel (int keep, int reverse, int fun
 tree
 pushdecl (tree decl)
 {
-  /* External objects aren't nested, other objects may be.  */
-  if (DECL_EXTERNAL (decl))
-DECL_CONTEXT (decl) = NULL_TREE;
-  else if (global_bindings_p ())
+  if (global_bindings_p ())
 DECL_CONTEXT (decl) = current_translation_unit;
   else
-DECL_CONTEXT (decl) = current_function_decl;
+{
+  /* External objects aren't nested.  For debug info insert a copy
+ of the decl into the binding level.  */
+  if (DECL_EXTERNAL (decl))
+   {
+ tree orig = decl;
+ decl = copy_node (decl);
+ DECL_CONTEXT (orig) = NULL_TREE;
+   }
+  DECL_CONTEXT (decl) = current_function_decl;
+}

   /* Put the declaration on the list.  The list of declarations is in reverse
  order. The list will be reversed later if necessary.  This needs to be


there might be still multiple backend-decls for USE associated vars in
different subroutines (they should share a single global one).

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mikestump at comcast dot net]

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

--- Comment #23 from Mike Stump  2011-02-22 
11:53:56 UTC ---
I am confused, both Iain and myself still see failures on ppc even with my
patch.  Iain said they were dying on BUILT_IN_SQRTL.  I can't debug, as I'm
using rosetta, and apparently debugging no longer works.  :-(  Odd.

[ long pause ]

Truly, odd, I just updated and removed that hunk from comment #6, and presto,
the testcase that failed for me earlier, now works.  I did do a restrap this
time to try and avoid more uncleanliness.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mikestump at comcast dot net]

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

--- Comment #24 from Mike Stump  2011-02-22 
11:56:37 UTC ---
Iain reports it is fixed for him as well...  :-)

[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-debug

--- Comment #4 from Richard Guenther  2011-02-22 
12:01:03 UTC ---
With the patch and

MODULE PEC_mod
CONTAINS
SUBROUTINE PECapply(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop
END SUBROUTINE PECapply
SUBROUTINE PECapply2(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop
END SUBROUTINE PECapply2
END MODULE PEC_mod

you see

pecapply2 (real(kind=8)[0:] * restrict ex)
{
  extern integer(kind=4)D.8 xstopD.1540;

  {
struct __st_parameter_dt dt_parm.0D.1539;

dt_parm.0D.1539.commonD.1458.filenameD.1355 = &"t.f90"[1]{lb: 1 sz: 1};
dt_parm.0D.1539.commonD.1458.lineD.1356 = 11;
dt_parm.0D.1539.commonD.1458.flagsD.1353 = 128;
dt_parm.0D.1539.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (&dt_parm.0D.1539);
_gfortran_transfer_integer_write (&dt_parm.0D.1539, &xstopD.1538, 4);
_gfortran_st_write_done (&dt_parm.0D.1539);
  }
}

pecapply (real(kind=8)[0:] * restrict ex)
{
  {
struct __st_parameter_dt dt_parm.1D.1543;

dt_parm.1D.1543.commonD.1458.filenameD.1355 = &"t.f90"[1]{lb: 1 sz: 1};
dt_parm.1D.1543.commonD.1458.lineD.1356 = 6;
dt_parm.1D.1543.commonD.1458.flagsD.1353 = 128;
dt_parm.1D.1543.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (&dt_parm.1D.1543);
_gfortran_transfer_integer_write (&dt_parm.1D.1543, &xstopD.1538, 4);
_gfortran_st_write_done (&dt_parm.1D.1543);
  }
}

which is half-way sane (same backend-decl used for the actual USE
associated variable).  But still the 2nd function misses the copy
in its BLOCK tree, so I guess if that function would be nested
in another that has a local of the same name gdb would confuse
references to the USE associated vars with that of the local
parent function decl like with

MODULE PEC_mod
CONTAINS
SUBROUTINE test
integer :: xstop,xbar
write(*,*) xstop
CONTAINS
SUBROUTINE PECapply(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop,xbar
END SUBROUTINE PECapply
END SUBROUTINE test
SUBROUTINE PECapply2(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop
END SUBROUTINE PECapply2
END MODULE PEC_mod

remains to a more Fortran affine person to verify the above wrong-debug
idea with gdb.  The key is

pecapply (real(kind=8)[0:] * restrict ex)
{
  {
struct __st_parameter_dt dt_parm.1D.1545;

dt_parm.1D.1545.commonD.1458.filenameD.1355 = &"t.f90"[1]{lb: 1 sz: 1};
dt_parm.1D.1545.commonD.1458.lineD.1356 = 10;
dt_parm.1D.1545.commonD.1458.flagsD.1353 = 128;
dt_parm.1D.1545.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (&dt_parm.1D.1545);
_gfortran_transfer_integer_write (&dt_parm.1D.1545, &xstopD.1535, 4);
_gfortran_transfer_integer_write (&dt_parm.1D.1545, &xbarD.1546, 4);
_gfortran_st_write_done (&dt_parm.1D.1545);
  }
}

(no extern integer(kind=4)D.8 xstopD.1537; here) and in the parent:

test ()
{
  integer(kind=4)D.8 xbarD.1546;
  integer(kind=4)D.8 xstopD.1547;
  static voidD.27 pecapplyD.1541 (real(kind=8)D.18[0:] * restrict);

  {
struct __st_parameter_dt dt_parm.2D.1548;

dt_parm.2D.1548.commonD.1458.filenameD.1355 = &"t.f90"[1]{lb: 1 sz: 1};
dt_parm.2D.1548.commonD.1458.lineD.1356 = 5;
dt_parm.2D.1548.commonD.1458.flagsD.1353 = 128;
dt_parm.2D.1548.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (&dt_parm.2D.1548);
_gfortran_transfer_integer_write (&dt_parm.2D.1548, &xstopD.1547, 4);
_gfortran_st_write_done (&dt_parm.2D.1548);
  }
}

we have integer(kind=4)D.8 xstopD.1547 which shadows the global xstop
from the module.

[Bug libfortran/47830] errors in intrinsics/c99_functions.c

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-02-22 
12:37:16 UTC ---
Author: burnus
Date: Tue Feb 22 12:37:12 2011
New Revision: 170396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170396
Log:
2011-02-22  Tobias Burnus  
Kai-Uwe Eckhardt  

PR libfortran/47830
* intrinsics/c99_functions.c (roundl): Make C valid for
HAVE_NEXTAFTERL.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/c99_functions.c

[Bug libfortran/47830] errors in intrinsics/c99_functions.c

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-02-22 
12:41:57 UTC ---
Author: burnus
Date: Tue Feb 22 12:41:54 2011
New Revision: 170397

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170397
Log:
2011-02-22  Tobias Burnus  
Kai-Uwe Eckhardt  

PR libfortran/47830
* intrinsics/c99_functions.c (roundl): Make C valid for
HAVE_NEXTAFTERL.


Modified:
branches/gcc-4_5-branch/libgfortran/ChangeLog
branches/gcc-4_5-branch/libgfortran/intrinsics/c99_functions.c

[Bug libfortran/47830] errors in intrinsics/c99_functions.c

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2011-02-22 
12:43:42 UTC ---
Author: burnus
Date: Tue Feb 22 12:43:38 2011
New Revision: 170398

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170398
Log:
2011-02-22  Tobias Burnus  
Kai-Uwe Eckhardt  

PR libfortran/47830
* intrinsics/c99_functions.c (roundl): Make C valid for
HAVE_NEXTAFTERL.


Modified:
branches/gcc-4_4-branch/libgfortran/ChangeLog
branches/gcc-4_4-branch/libgfortran/intrinsics/c99_functions.c

[Bug libfortran/47830] errors in intrinsics/c99_functions.c

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Tobias Burnus  2011-02-22 
12:44:20 UTC ---
FIXED on the trunk (4.6) and on the 4.4 and 4.5 branches.

Thanks for the report!

[Bug fortran/47845] [OOP] Polymorphic deferred function: Not matched class

[Kdx1999 at gmail dot com]

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

--- Comment #2 from KePu  2011-02-22 12:54:10 UTC ---
Thank you for respond this issue, I have modified the definition of vec:). But
it seems that only the first argument can be set to subclass of vec, the other
must be strictly set to vec, so the additional coordinate z can't be used in
newly overriding procedures.

[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine "optimizing two comparisons to x_[0-9]+\(D\) != 4"

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-02-22 
12:55:45 UTC ---
Created attachment 23434
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23434
gcc46-pr47835.patch

I guess instead of XFAILing it is better just to check the end result, whether
tree passes optimized this into x != 4 test in the end or not.  And they
actually do (with the exception of x86_64/i686 and maybe other targets before
PR46909 fix).  For ppc ifcombine only optimizes x != 6 || x == 2 into
x != 6 (that's why it reports that it optimized two comparisons into x != 6),
the reason why it doesn't optimize further is that x == 6 check has two preds,
one is x != 4 && x != 6 and the other one is !(x != 4) (one edge has moved from
x == 2 check to x == 6 during vrp1).  dom manages to optimize it though.

[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine "optimizing two comparisons to x_[0-9]+\(D\) != 4"

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-02-22 
12:56:54 UTC ---
I've tested this patch on x86_64, i686, ppc and ppc64 linux with PR46909
gimple-fold.c change reverted and with vanilla gimple-fold, with the fix
reverted expectedly x86_64 and i686 gcc.dg/pr46909.c test failed.

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[anemo at mba dot ocn.ne.jp]

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

--- Comment #7 from Atsushi Nemoto  2011-02-22 
13:04:10 UTC ---
(In reply to comment #5)
> arm-linux-gnueabi-gcc-4.6.0-20101124 works fine (generates ldr instruction),

It seems that was a side-effect of -fstrict-volatile-bitfields which was
enabled
by default on ARM EABI.
With -fno-strict-volatile-bitfields, arm-linux-gnueabi-gcc-4.6.0-20110222
generates
four ldrb instructions.

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||cato at df dot lth.se

--- Comment #11 from Tobias Burnus  2011-02-22 
13:25:53 UTC ---
I just checked
CC the one of the two NetBSD maintainers who has been last active...

 * * *

  CVS_RSH="ssh"  cvs -d "anon...@anoncvs.netbsd.org:/cvsroot" co src/lib/libm/

and libm/compat contains only compat_cabsf and compat_cabs.c, which use a
struct instead of complex. That those are the only math-related changes, one
sees if on greps for __RENAME in
  CVS_RSH="ssh"  cvs -d "anon...@anoncvs.netbsd.org:/cvsroot" co src/include/
i.e. complex.h contains:

#ifndef __LIBM0_SOURCE__
/* avoid conflict with historical cabs(struct complex) */
double cabs(double complex) __RENAME(__c99_cabs);
float cabsf(float complex) __RENAME(__c99_cabsf);
#endif

 * * *

Regarding the patch (cf. comment 3): Darwin has the files darwin.c in
./gcc/config/, which is included via ./gcc/config.gcc's
  tm_p_file="${tm_p_file} darwin-protos.h"
  target_gtfiles="\$(srcdir)/config/darwin.c"
  extra_objs="darwin.o"
One probably needs to do likewise for "*-*-netbsd*)".

In darwin.c, see darwin_patch_builtins and darwin_patch_builtin.

Those are used via SUBTARGET_INIT_BUILTINS in some ./gcc/config/* files.

[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine "optimizing two comparisons to x_[0-9]+\(D\) != 4"

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-02-22 
13:40:27 UTC ---
Author: jakub
Date: Tue Feb 22 13:40:24 2011
New Revision: 170399

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170399
Log:
PR tree-optimization/47835
* gcc.dg/pr46909.c: Check optimized dump instead of ifcombine.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr46909.c

[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine "optimizing two comparisons to x_[0-9]+\(D\) != 4"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-02-22 
13:41:53 UTC ---
Should be fixed now.

[Bug middle-end/47663] Very simple wrapper not inlined

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-02-22 
13:47:18 UTC ---
Author: rguenth
Date: Tue Feb 22 13:47:15 2011
New Revision: 170400

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170400
Log:
2011-02-22  Richard Guenther  

PR tree-optimization/47663
* cgraph.h (struct cgraph_edge): Add call_stmt_size and
call_stmt_time fields.
(cgraph_edge_inlinable_p): Declare.
(cgraph_edge_recursive_p): New inline function.
* cgraph.c (cgraph_create_edge_1): Initialize call_stmt_size.
(cgraph_clone_edge): Copy it.
* ipa-inline.c (cgraph_estimate_edge_time): New function.
Account for call stmt time.
(cgraph_estimate_time_after_inlining): Take edge argument.
(cgraph_estimate_edge_growth): Account call stmt size.
(cgraph_estimate_size_after_inlining): Take edge argument.
(cgraph_mark_inline_edge): Adjust.
(cgraph_check_inline_limits): Likewise.
(cgraph_recursive_inlining_p): Remove.
(cgraph_edge_badness): Use cgraph_edge_recursive_p.
(cgraph_decide_recursive_inlining): Take edge argument and
adjust.
(cgraph_decide_inlining_of_small_functions): Do not avoid
diags for recursive inlining here.
(cgraph_flatten): Adjust.
(cgraph_decide_inlining_incrementally): Likewise.
(estimate_function_body_sizes): Remove call cost handling.
(compute_inline_parameters): Initialize caller edge call costs.
* tree-inline.c (estimate_num_insns): Only account for call
return value if it is used.
(expand_call_inline): Avoid diagnostics on recursive inline
functions here.
* lto-cgraph.c (lto_output_edge): Output edge call costs.
(input_edge): Input edge call costs.

* gcc.dg/tree-ssa/inline-8.c: New testcase.

2011-02-22  Richard Guenther  

* ipa-inline.c (cgraph_estimate_edge_growth): New function.
(cgraph_estimate_growth): Use it.
(cgraph_edge_badness): Likewise.
(cgraph_check_inline_limits): Take an edge argument.
(cgraph_decide_inlining_of_small_functions): Adjust.
(cgraph_decide_inlining): Likewise.

Added:
branches/pretty-ipa/gcc/testsuite/ChangeLog.pretty-ipa
branches/pretty-ipa/gcc/testsuite/gcc.dg/tree-ssa/inline-8.c
Modified:
branches/pretty-ipa/gcc/ChangeLog.pretty-ipa
branches/pretty-ipa/gcc/cgraph.c
branches/pretty-ipa/gcc/cgraph.h
branches/pretty-ipa/gcc/ipa-inline.c
branches/pretty-ipa/gcc/lto-cgraph.c
branches/pretty-ipa/gcc/tree-inline.c

[Bug fortran/47845] [OOP] Polymorphic deferred function: Not matched class

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-02-22 
13:50:24 UTC ---
(In reply to comment #2)
> Thank you for respond this issue, I have modified the definition of vec:). But
> it seems that only the first argument can be set to subclass of vec, the other
> must be strictly set to vec, so the additional coordinate z can't be used in
> newly overriding procedures.

You could use "GENERIC" to generate different versions of "vec" - and make the
two argument version set "z == 0". (Similar to "GENERIC :: OPERATOR(+)" but for
type-bound procedures.)


Are there other issues in the bug report? From comment 0 it is a bit unclear to
me what the issue is - besides the non-issue mentioned in comment 1.

If there is no issue left, I would like to close this problem report (PR).

 * * *

For general Fortran questions, I would recommend the comp.lang.fortran news
group which is available on *any* (net) news server. It is also available via
Google, but they do not filter spam - thus, your university's or ISP's server
should be preferred. Cf. also http://groups.google.com/group/comp.lang.fortran/

For specific gfortran question, the fortran mailing list at
http://gcc.gnu.org/lists.html

[Bug web/47848] New: invalid -ftree-loop-if-convert-memory-writes flag is mentioned at two places (instead of -ftree-loop-if-convert-stores)

[zsojka at seznam dot cz]

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

   Summary: invalid -ftree-loop-if-convert-memory-writes flag is
mentioned at two places (instead of
-ftree-loop-if-convert-stores)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org


It seems -ftree-loop-if-convert-memory-writes was renamed to
-ftree-loop-if-convert-stores short before the commit, but
-ftree-loop-if-convert-memory-writes is still mentioned at:

gcc/doc/invoke.texi (only in the summary)

http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html (is this auto-generated?)

[Bug fortran/47844] I/O: data transfer statement: Array stride ignored for pointer-valued function results

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
Summary|Pointer-valued function:|I/O: data transfer
   |Provide wrong result when   |statement: Array stride
   |dereferenced automatically  |ignored for pointer-valued
   |after list-write|function results

--- Comment #2 from Tobias Burnus  2011-02-22 
14:45:42 UTC ---
Paul, I added you as you are a tad more familiar with the scalarizer than I am.

 * * *

Slightly simplified test case:

  integer, target :: tgt(5) = [1,2,3,4,5]
  integer, pointer :: ptr(:)
  print *, f(tgt)
contains
  function f(x)
integer, target :: x(:)
integer, pointer :: f(:)
f => x(::2)
  end function f
end

While "f" correctly sets the stride, it is ignored by the PRINT statement;
-fdump-tree-original shows:

  f (&atmp.8, D.1566);
[...]
  D.1579 = (*(integer(kind=4)[0:] * restrict) atmp.8.data)[S.9];
  _gfortran_transfer_integer_write (&dt_parm.5, &D.1579, 4);
}
S.9 = S.9 + 1;

The last line should be S.9 = S.9 + atmp.8.stride, which gets correctly set by
"f()".

Thus, one needs to teach the scalarizer that the stride does not have to be
always 1 for SS_FUNCTION, though the only case I currently can come up with are
array-valued pointer-returning functions. I think one should consider adding a
is_pointer_result:1 to gfc_ss, which could be set in gfc_walk_function_expr.

The scalarizers are set up via gfc_trans_transfer. The "1" setting seems to
happen in gfc_conv_ss_startstride:

case GFC_SS_CONSTRUCTOR:
case GFC_SS_FUNCTION:
  for (n = 0; n < ss->data.info.dimen; n++)
{
  ss->data.info.start[n] = gfc_index_zero_node;
  ss->data.info.end[n] = gfc_index_zero_node;
  ss->data.info.stride[n] = gfc_index_one_node;
}
  break;

At some point, it needs to be modified for array-pointer-returning functions; I
think that should happen in gfc_conv_loop_setup

[Bug target/47831] avoid if-convertion if the conditional instructions and following conditional branch has the same condition

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.02.22 14:50:03
 CC||ibolton at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.6.0

--- Comment #1 from Ian Bolton  2011-02-22 14:50:03 
UTC ---
Confirmed on r170278 of trunk.

The better sequence that Carrot mentions comes from having if-conversion
disabled (-fno-if-conversion2).

I expect Basic Block Reordering might be able to help out in the case where
if-conversion is enabled, but I think it is still disabled for -Os, as it can
sometimes lead to larger code.

That is a separate issue though.  To tackle this properly, the if-conversion
heuristic would need to be enhanced to detect cases where the codesize will
likely increase and pessimise against those cases when using -Os.

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist  2011-02-22 15:34:57 
UTC ---
This seems to be because the libgfortran implementation uses gfc_charlen_type
for the length of the string, but the frontend passes the address of an
integer(8) variable. As a quick and dirty test, changing the libgfortran
implementation to use "long" removes the valgrind errors on x86_64. Though the
correct fix is to change the frontend to create a variable of the correct type.

If not before, perhaps something to fix when/if we change to use size_t for
string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup

[Bug target/47847] PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double

[sebastian.hu...@embedded-brains.de]

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

--- Comment #1 from Sebastian Huber  
2011-02-22 15:55:29 UTC ---
Adding the -mspe (in addition to -mabi=spe) option helped. It seems that only
few combinations of the -mcpu=8520, -mfloat-gprs=*, -mspe, and -mabi=spe flags
are well tested in GCC.  The following combinations worked:

(1) -mcpu=8540 -msoft-float
(2) -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=single
(3) -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double

[Bug tree-optimization/47849] New: ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in find_edge (cfganal.c:491) with
-ftree-loop-if-convert -fno-tree-reassoc
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -ftree-loop-if-convert -fno-tree-reassoc testcase.ctestcase.c: In
function 'foo':
testcase.c:2:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  find_edge (pred=0x75bf2138, succ=0x0) at
/mnt/svn/gcc-trunk/gcc/cfganal.c:491
#1  0x00986bd1 in remove_dead_stmt (i=0x7fffd6a0,
bb=0x75bf2138) at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1102
#2  0x009870f9 in eliminate_unnecessary_stmts () at
/mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1203
#3  0x0098957f in perform_tree_ssa_dce (aggressive=1 '\001') at
/mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1450
#4  0x007f6e86 in execute_one_pass (pass=0x178ee30) at
/mnt/svn/gcc-trunk/gcc/passes.c:1556
#5  0x007f7185 in execute_pass_list (pass=0x178ee30) at
/mnt/svn/gcc-trunk/gcc/passes.c:1611
#6  0x007f7197 in execute_pass_list (pass=0x163bd80) at
/mnt/svn/gcc-trunk/gcc/passes.c:1612
#7  0x00939fd6 in tree_rest_of_compilation (fndecl=0x75b86f00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#8  0x00b01e82 in cgraph_expand_function (node=0x75ba6000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576
#9  0x00b045ca in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635
#10 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899
#11 0x00b04b4a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096
#12 0x0050974c in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9872
#13 0x008e2f78 in compile_file (argc=15, argv=0x7fffda68) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#14 do_compile (argc=15, argv=0x7fffda68) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1900
#15 toplev_main (argc=15, argv=0x7fffda68) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1963
#16 0x76446bbd in __libc_start_main () from /lib/libc.so.6
#17 0x004f02fd in _start ()

Tested revisions:
r170398 - crash

[Bug c++/45383] [4.5 Regression] Implicit conversion to pointer does no longer automatically generate operator== and operator!=.

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

Summary|[4.5/4.6 Regression]|[4.5 Regression] Implicit
   |Implicit conversion to  |conversion to pointer does
   |pointer does no longer  |no longer automatically
   |automatically generate  |generate operator== and
   |operator== and operator!=.  |operator!=.

--- Comment #8 from Dodji Seketeli  2011-02-22 
16:14:59 UTC ---
Fixed in 4.6

[Bug tree-optimization/47849] ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||4.6.0

--- Comment #1 from Zdenek Sojka  2011-02-22 16:17:09 
UTC ---
Originally, it failed with:

(testcase is testsuite/gcc.target/i386/avx-vpcmpistri-1.c)

$ gcc -O2 -mavx -ftree-loop-if-convert -fno-tree-reassoc avx-vpcmpistri-1.i 
avx-vpcmpistri-1.i: In function 'cmp_flags.constprop.1':
avx-vpcmpistri-1.i:5573:1: internal compiler error: in forward_edge_to_pdom, at
tree-ssa-dce.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x117f638 "/mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c",
line=1064, function=0x117fd60 "forward_edge_to_pdom")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x00986ec6 in forward_edge_to_pdom (i=0x7fffd670,
bb=0x77f32548) at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1064
#2  remove_dead_stmt (i=0x7fffd670, bb=0x77f32548) at
/mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1113
#3  0x009870f9 in eliminate_unnecessary_stmts () at
/mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1203
#4  0x0098957f in perform_tree_ssa_dce (aggressive=1 '\001') at
/mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1450
#5  0x007f6e86 in execute_one_pass (pass=0x178ee30) at
/mnt/svn/gcc-trunk/gcc/passes.c:1556
#6  0x007f7185 in execute_pass_list (pass=0x178ee30) at
/mnt/svn/gcc-trunk/gcc/passes.c:1611
#7  0x007f7197 in execute_pass_list (pass=0x163bd80) at
/mnt/svn/gcc-trunk/gcc/passes.c:1612
#8  0x00939fd6 in tree_rest_of_compilation (fndecl=0x75819e00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#9  0x00b01e82 in cgraph_expand_function (node=0x75916b00) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576
#10 0x00b045ca in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635
#11 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899
#12 0x00b04b4a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096
#13 0x0050974c in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9872
#14 0x008e2f78 in compile_file (argc=16, argv=0x7fffda38) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#15 do_compile (argc=16, argv=0x7fffda38) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1900
#16 toplev_main (argc=16, argv=0x7fffda38) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1963
#17 0x76446bbd in __libc_start_main () from /lib/libc.so.6
#18 0x004f02fd in _start ()

The backtrace is very similiar, so it is probably the same problem.

Apart from that, running testsuite with "-ftree-loop-if-convert
-fno-tree-reassoc" resulted in ~177 exec failures - it is probably already
reported as PR47770.

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-02/msg01453.htm
   ||l
   Last reconfirmed||2011.02.22 16:21:09
 AssignedTo|unassigned at gcc dot   |jb at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #15 from Janne Blomqvist  2011-02-22 
16:21:09 UTC ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01453.html

[Bug other/44032] internals documentation is not legally safe to use

[jsm28 at gcc dot gnu.org]

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

--- Comment #2 from Joseph S. Myers  2011-02-22 
16:33:34 UTC ---
Joern, since the GFDL says:

If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.

it ought not be controversial to add a statement that examples of code in the
internals manual are also released under the GPL.  I'd advise preparing a patch
adding a statement to the effect that

You can redistribute and/or modify examples of program code in this manual
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later version.

and sending the patch to RMS for legal review as well as gcc-patches for
technical review.

[Bug other/44035] internals documentation cannot be fixed without new GFDL license grants

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  2011-02-22 
16:41:27 UTC ---
Joern, after discussion with Mark and Richi my advice at this point on the GFDL
issue is that you should prepare a concrete patch that moves all the text you
want from both code and documentation to its ideal places in target.def, and
send that patch - including the changes to the generated file tm.texi - to RMS
for legal review (asking explicitly for approval of GFDL licensing of the
changes to tm.texi and of GPL licensing for the changes to target.def) as well
as to gcc-patches for technical review.  That way at least RMS is faced with
questions relating to licensing of fixed bodies of text under existing licenses
- though the exercise would need repeating in future (maybe once per major
release) after more target macros become hooks - rather than general abstract
questions needing new dual-licensing notices.  And in the past it's been much
easier to get him to approve changes in concrete cases (e.g. licensing of
longlong.h).

It may be worth pointing out in the mail to RMS that the text describing macros
in tm.texi (pre-GFDL, under a non-GPL copyleft) used to be routinely duplicated
in comments (GPL) on individual definitions of those macros, so having this
sort of text under the GPL as well as a documentation license is nothing new.

[Bug fortran/47850] New: [4.6 Regression] ICE in gfc_conv_array_initializer

[burnus at gcc dot gnu.org]

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

   Summary: [4.6 Regression] ICE in gfc_conv_array_initializer
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


The following program is based on James' program at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/625faf82578e9af8

The only difference is that I replaced "(*)" by the bounds as otherwise one
cannot compile it with 4.5.


$ gfortran-4.5 test.f90 && ./a.out
SENSOR_CHANNEL =   10, 12, 17, 20, 22, 30, 33, 34
NLTE_CHANNEL = 20, 22, 34
N_NLTE_CHANNELS =   3
N_CHANNELS =8
C_INDEX =   0,  0,  0,  1,  2,  0,  0,  3

$ gfortran-4.6 test.f90 && ./a.out
test.f90: In function ‘cindex’:
test.f90:23:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:4576


That's gfc_conv_array_initializer's
  switch (expr->expr_type)
{
[...]
default:
  gcc_unreachable ();

Where:

(gdb) p expr->expr_type
$1 = EXPR_FUNCTION
(gdb) p expr->value.function.isym->name
$4 = 0x2ab42858 "unpack"

Thus, for some reason the unpack has not been simplified in 4.6.




program Cindex
   implicit none
   integer,parameter :: SENSOR_CHANNEL(8) = &
  [10,12,17,20,22,30,33,34]
   integer,parameter :: NLTE_CHANNEL(3) = [20,22,34]
   integer,parameter :: N_NLTE_CHANNELS = size(NLTE_CHANNEL)
   integer,parameter :: N_CHANNELS = size(SENSOR_CHANNEL)
   integer i
   integer,parameter :: C_INDEX(8) = unpack( &
  vector = [(i,i=1,size(SENSOR_CHANNEL))], &
  mask = [(any(SENSOR_CHANNEL(i) == NLTE_CHANNEL), &
 i=lbound(SENSOR_CHANNEL,1),ubound(SENSOR_CHANNEL,1))], &
  field = 0)
   character(20) fmt

   write(fmt,'(a,i0,a)') '(a,t19,',size(SENSOR_CHANNEL),'(i3:","))'
   write(*,fmt) 'SENSOR_CHANNEL = ',SENSOR_CHANNEL
   write(fmt,'(a,i0,a)') '(a,t19,',size(NLTE_CHANNEL),'(i3:","))'
   write(*,fmt) 'NLTE_CHANNEL = ',NLTE_CHANNEL
   write(*,'(a,t19,i3)') 'N_NLTE_CHANNELS = ',N_NLTE_CHANNELS
   write(*,'(a,t19,i3)') 'N_CHANNELS = ',N_CHANNELS
   write(fmt,'(a,i0,a)') '(a,t19,',size(C_INDEX),'(i3:","))'
   write(*,fmt) 'C_INDEX = ',C_INDEX
end program Cindex

[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.6.0

[Bug middle-end/47790] [4.5/4.6 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  2011-02-22 17:09:36 
UTC ---
A couple early comments.

First, it appears that it's never possible to get into this code via the old
path where SRC is a binary operation of some sort.  This is presumably an
artifact of how we handle expansion.

If I understand your change correctly, you're walking the use-def chain when
SRC is an SSA_NAME in the hopes of finding a suitable binary operation to set
SRC.  After that, you can just let the original code from
optimize_bitfield_assignment_op do its thing.

I found this fragment somewhat odd, what's its purpose?

+  if (TREE_CODE (op0) == SSA_NAME)
+{
+  gimple op0stmt = get_gimple_for_ssa_name (op0);
+  if (!op0stmt || !is_gimple_assign (op0stmt) || gimple_assign_rhs_code
(op0stmt) != TREE_CODE (to) )
+return false;
+  op0 = gimple_assign_rhs1 (op0stmt);
+}


At this point OP0 is the RHS1 of the statement which set SRC via binary
operator.

Second, the original code stripped nops from OP0.  Is there some reason you
don't do that?  It probably doesn't matter, but you might be missing some
optimization opportunities as a result.

>From peeking at the testcase, if we could handle the case where SRC is a
typecast which is fed by a binary operation, we might have many more
opportunities to optimize.  I guess that should be considered extra credit.

[Bug web/47848] invalid -ftree-loop-if-convert-memory-writes flag is mentioned at two places (instead of -ftree-loop-if-convert-stores)

[spop at gcc dot gnu.org]

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

--- Comment #1 from Sebastian Pop  2011-02-22 17:36:38 
UTC ---
Author: spop
Date: Tue Feb 22 17:36:34 2011
New Revision: 170411

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170411
Log:
Fix PR47848: Do not mention -ftree-loop-if-convert-memory-writes.

2011-02-22  Sebastian Pop  

PR doc/47848
* doc/invoke.texi: Do not mention -ftree-loop-if-convert-memory-writes.

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

[Bug web/47848] invalid -ftree-loop-if-convert-memory-writes flag is mentioned at two places (instead of -ftree-loop-if-convert-stores)

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Sebastian Pop  2011-02-22 17:38:12 
UTC ---
Fixed.

[Bug c++/47851] New: [4.6 Regression] [C++0x] Incorrect decltype result for conditional operator

[mimomorin at gmail dot com]

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

   Summary: [4.6 Regression] [C++0x] Incorrect decltype result for
conditional operator
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mimomo...@gmail.com


Created attachment 23436
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23436
Test case

Suppose we have a code

struct Type {};

typedef Type const ConstType;

struct ConvertibleToType {
operator Type&() { return *reinterpret_cast(this); }
};

Then expression `true ? ConvertibleToType() : ConstType()` has type `Type`.
But `decltype(true ? ConvertibleToType() : ConstType())` is `Type const`.

Note that, in gcc 4.5, both the type of the expression and its `decltype` are
`Type`.
(In clang TOT, both are `Type const`.)

[Bug c++/47851] [4.6 Regression] [C++0x] Incorrect decltype result for conditional operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2011-02-22 
18:04:47 UTC ---
Let's ask Jason to have a look.

[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Nicola Pero  2011-02-22 18:31:43 
UTC ---
Resolved in trunk (4.6).

Thanks

[Bug fortran/45743] [4.6 Regression] gfortran.dg/whole_file_3.f90 ICE: verify_stmts failed: invalid conversion in gimple call with -finline-small-functions

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |pault at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Paul Thomas  2011-02-22 19:17:43 
UTC ---
Created attachment 23437
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23437
A fix for the PR

This has already been submitted to the list.

Cheers

Paul

[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment

[yuri at tsoft dot com]

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

--- Comment #3 from Yuri  2011-02-22 19:23:45 UTC ---
If gcc would only set 16 byte alignment this wouldn't be that bad since, as you
mentioned, it is still word aligned.

The problem is that gcc assumes that stack is 16 aligned and creates code based
on this. For example it places instruction like this 'movdqa %xmm0, 0x10(%esp)'
which assumes 16 byte alignment. As a result, gcc compiled procedure crashes
when called by ABI compliant code.

gcc can't assume 16 byte alignment.

[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib

[th.r.klein at web dot de]

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

--- Comment #2 from th.r.klein at web dot de 2011-02-22 19:39:27 UTC ---
For example a microcontroller do not need to have any kind of standard
C-Library files or its header files.
So it is not possible to build e.g. zlib or libiberty for this target
platforms.
Additional I might to take a decision not to build this library, even if it is
possible to build it.

The build process failed here.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #16 from Janne Blomqvist  2011-02-22 
19:43:10 UTC ---
Patch using the fbuf_getc approach:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01475.html

[Bug c++/47666] [4.6 Regression] ICE in dfs_walk_once

[dodji at gcc dot gnu.org]

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

--- Comment #3 from Dodji Seketeli  2011-02-22 
19:53:16 UTC ---
Author: dodji
Date: Tue Feb 22 19:53:13 2011
New Revision: 170413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170413
Log:
Fix PR c++/47666

gcc/cp/

PR c++/47666
* class.c (dfs_declare_virt_assop_and_dtor)
(declare_virt_assop_and_dtor): New static functions.
(add_implicitly_declared_members): Use
declare_virt_assop_and_dtor.

gcc/testsuite/

PR c++/47666
* g++.dg/inherit/virtual7.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/inherit/virtual7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47666] [4.6 Regression] ICE in dfs_walk_once

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Dodji Seketeli  2011-02-22 
19:59:01 UTC ---
Fixed in trunk (4.6).

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[jb at gcc dot gnu.org]

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

--- Comment #16 from Janne Blomqvist  2011-02-22 
20:24:13 UTC ---
Patch which should hopefully fix the getpwuid_r issue on HP-UX 10.2:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01478.html

[Bug fortran/45743] [4.6 Regression] gfortran.dg/whole_file_3.f90 ICE: verify_stmts failed: invalid conversion in gimple call with -finline-small-functions

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  2011-02-22 20:33:48 
UTC ---
Author: pault
Date: Tue Feb 22 20:33:45 2011
New Revision: 170414

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

PR fortran/45743
* trans-decl.c (gfc_get_extern_function_decl): Don't use the
gsymbol backend_decl if the procedure has a formal argument
that is a procedure.

2011-02-22  Paul Thomas  

PR fortran/45743
* gfortran.dg/whole_file_32.f90 : New test.

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

[Bug driver/47852] New: crash with g++ -lpthread on irix

[bugzilla-gcc at thewrittenword dot com]

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

   Summary: crash with g++ -lpthread on irix
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla-...@thewrittenword.com
CC: r...@cebitec.uni-bielefeld.de
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


gcc-4.4.5 on IRIX 6.5 produces an executable that crashes at runtime if
-lpthread appears before -lstdc++ on the link line.


% echo 'int main() {}' >a.cpp
% g++ a.cpp -lpthread -pthread; ./a.out; echo $?
zsh: segmentation fault (core dumped)  ./a.out
139


See also the discussion here:

http://gcc.gnu.org/ml/gcc-help/2011-02/msg00335.html

http://gcc.gnu.org/ml/gcc-help/2011-02/msg00368.html

[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.02.22 22:28:10
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2011-02-22 
22:28:10 UTC ---
I meant how does it fail?

>For example a microcontroller do not need to have any kind of standard 
>C-Library files or its header files.

I don't think that is true. Most targets even microcontrollers one have a
standard C library.  


Also how are you configuring GCC?  If you really only want GCC and libgcc, the
easiest way to do that is:
make all-gcc && make all-target-libgcc
make install-gcc && make install-target-libgcc

[Bug fortran/47853] New: Assignment of integer to pointer compiles, and a.out segfaults

[thisrod at gmail dot com]

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

   Summary: Assignment of integer to pointer compiles, and a.out
segfaults
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: this...@gmail.com


Created attachment 23438
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23438
Source code to trigger the error

Shell trace:

% gfortran -v test.f08
Driving: gfortran -mmacosx-version-min=10.6.6 -v test.f08 -lgfortran
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/lto-wrapper
Target: x86_64-apple-darwin10.3.0
Configured with: ../gcc-4_5-branch/configure --prefix=/usr/local/gfortran
--enable-languages=c,c++,fortran
--with-gmp=/Users/fx/devel/gcc/ibin45/../irun45 --enable-bootstrap
--with-included-gettext --with-arch=nocona --with-tune=generic
Thread model: posix
gcc version 4.5.1 20100506 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc'
'-mtune=generic' '-march=nocona'
 /usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/f951 test.f08
-fPIC -quiet -dumpbase test.f08 -mmacosx-version-min=10.6.6 -mtune=generic
-march=nocona -auxbase test -version -fintrinsic-modules-path
/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/finclude -o
/var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//ccQWPLn5.s
GNU Fortran (GCC) version 4.5.1 20100506 (prerelease)
(x86_64-apple-darwin10.3.0)
compiled by GNU C version 4.5.1 20100506 (prerelease), GMP version 4.3.1,
MPFR version 2.4.2-p2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.5.1 20100506 (prerelease)
(x86_64-apple-darwin10.3.0)
compiled by GNU C version 4.5.1 20100506 (prerelease), GMP version 4.3.1,
MPFR version 2.4.2-p2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc'
'-mtune=generic' '-march=nocona'
 as -arch x86_64 -force_cpusubtype_ALL -o
/var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//cca9YzEf.o
/var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//ccQWPLn5.s
COMPILER_PATH=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/
LIBRARY_PATH=/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc'
'-mtune=generic' '-march=nocona'
 /usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/collect2
-dynamic -arch x86_64 -macosx_version_min 10.6.6 -weak_reference_mismatches
non-weak -o a.out -lcrt1.10.5.o
-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1
-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/../../..
/var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//cca9YzEf.o -lgfortran
-lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc'
'-mtune=generic' '-march=nocona'
% ./a.out
21766: signal: sys: segmentation violation

[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-02-22 
22:57:15 UTC ---
Basically you are accessing p before pointing it to anything.

[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  2011-02-22 23:01:49 
UTC ---
You need to allocate p before use to get a valid program.
Like:

integer, target :: a
integer, pointer :: p => NULL ()

allocate (p)
p = a   ! should be =>
p = 1

end


Regarding the assignment "p = a",
please read an introduction to Fortran.
It is valid code when p is associated.

[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution||INVALID

--- Comment #3 from kargl at gcc dot gnu.org 2011-02-22 23:13:22 UTC ---
This is a programming mistake on the programmer.  A fortran
compiler is not required to diagnose such errors.  Try compiling
your code with -Wall.  It shows a warning (well actually 
two warnings because the program contains a tab character
where a space is expected), which should give enough information
to be concerned.

[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults

[rodneyp at physics dot uq.edu.au]

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

--- Comment #4 from rodneyp at physics dot uq.edu.au 2011-02-22 23:52:01 UTC ---
Sorry - you're right.  In the original code, p and a were arrays.  The
assignment p = a was still legal, but less obviously.

[Bug rtl-optimization/47763] Useless initialization of register

[jiez at gcc dot gnu.org]

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

--- Comment #11 from Jie Zhang  2011-02-23 00:25:38 
UTC ---
Author: jiez
Date: Wed Feb 23 00:25:34 2011
New Revision: 170422

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170422
Log:
PR rtl-optimization/47763
* web.c (web_main): Ignore naked clobber when replacing register.

testsuite/
PR rtl-optimization/47763
* gcc.dg/pr47763.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr47763.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/web.c

[Bug rtl-optimization/47763] Useless initialization of register

[jiez at gcc dot gnu.org]

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

Jie Zhang  changed:

   What|Removed |Added

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

--- Comment #12 from Jie Zhang  2011-02-23 00:27:15 
UTC ---
Fixed.

[Bug c++/47242] [C++0x] ICE: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:7604 on invalid lambda function

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2011-02-23 00:37:46 UTC ---
Author: paolo
Date: Wed Feb 23 00:37:43 2011
New Revision: 170423

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170423
Log:
/cp
2011-02-22  Paolo Carlini  

PR c++/47242
* semantics.c (build_lambda_object): Bail out if a field is
error_mark_node.

/testsuite
2011-02-22  Paolo Carlini  

PR c++/47242
* g++.dg/cpp0x/lambda/lambda-ice4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #18 from Alexandre Oliva  2011-02-23 
00:37:50 UTC ---
Fixed

[Bug c++/47242] [C++0x] ICE: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:7604 on invalid lambda function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  2011-02-23 
00:38:52 UTC ---
Fixed.

[Bug c++/47833] ICE during GC in gt_ggc_mx_pending_template

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-02-23 
00:47:41 UTC ---
Author: jakub
Date: Wed Feb 23 00:47:38 2011
New Revision: 170424

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170424
Log:
PR c++/47833
* pt.c (struct pending_template): Add chain_next GTY option.
* decl.c (struct named_label_use_entry): Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c

[Bug c++/47833] ICE during GC in gt_ggc_mx_pending_template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-02-23 
00:54:53 UTC ---
Fixed.

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |ccoutant at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Cary Coutant  2011-02-23 
02:00:08 UTC ---
Created attachment 23439
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23439
Patch to add demangler support for cloned function symbols

include/ChangeLog:

PR 40831
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_CLONE, DEMANGLE_COMPONENT_CONSTPROP_CLONE,
DEMANGLE_COMPONENT_ISRA_CLONE, DEMANGLE_COMPONENT_PART_CLONE.

libiberty/ChangeLog:

PR 40831
* cp-demangle.c (struct clone_suffix_list): New type.
(d_make_comp): Add new component types.
(cplus_demangle_mangled_name): Check for clone suffixes.
(d_parmlist): Don't error out if we see '.'.
(clone_suffixes): New array.
(d_clone_suffix): New function.
(d_print_comp): Print info for clone suffixes.
* testsuite/demangle-expected: Add new testcases.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #17 from Janne Blomqvist  2011-02-23 
06:59:54 UTC ---
Author: jb
Date: Wed Feb 23 06:59:51 2011
New Revision: 170432

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432
Log:
PR 47694 Read from named pipe fails

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/fbuf.h
trunk/libgfortran/io/transfer.c

[Bug libgomp/47854] New: omp_get_wtime documentation incorrect

[jb at gcc dot gnu.org]

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

   Summary: omp_get_wtime documentation incorrect
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


The implementation of omp_get_wtime() uses clock_gettime(CLOCK_MONOTONIC, ...)
if available (which IMHO is the correct choice). However, the documentation
(e.g. http://gcc.gnu.org/onlinedocs/libgomp/omp_005fget_005fwtime.html ) states
that "On POSIX compliant systems the seconds since the Epoch (00:00:00 UTC,
January 1, 1970) are returned.". For CLOCK_MONOTONIC, this is incorrect, as
POSIX 2008 only states

http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html

"If the Monotonic Clock option is supported, all implementations shall support
a clock_id of CLOCK_MONOTONIC defined in . This clock represents the
monotonic clock for the system. For this clock, the value returned by
clock_gettime() represents the amount of time (in seconds and nanoseconds)
since an unspecified point in the past (for example, system start-up time, or
the Epoch). This point does not change after system start-up time. "

And indeed, at least on Linux 2.6.32, that starting point is not the epoch.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #18 from Janne Blomqvist  2011-02-23 
07:11:55 UTC ---
Fixed on trunk. Keeping this PR open in order to remind us to

1) Backport to older releases once we have some experience on trunk.

2) Fix io/read.c(read_x) in the same way to use fbuf_getc instead of fbuf_read.

[Bug fortran/45743] [4.6 Regression] gfortran.dg/whole_file_3.f90 ICE: verify_stmts failed: invalid conversion in gimple call with -finline-small-functions

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Paul Thomas  2011-02-23 07:50:21 
UTC ---
Fixed on trunk.

Thanks for the report!

Paul

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[d.g.gorbachev at gmail dot com]

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

--- Comment #8 from Dmitry Gorbachev  
2011-02-23 07:53:45 UTC ---
Does not work for `_Z3fooi.1988' or
`_Z3fooi.part.9.165493.constprop.775.31805'.