[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 --- Comment #16 from Uros Bizjak ubizjak at gmail dot com 2013-02-09 08:02:22 UTC --- I didn't notice that my backport to 4.7 caused: ../../gcc-svn/branches/gcc-4_7-branch/gcc/lto/lto.c:1060:68: warning: format ‘%wx’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat] However, %wx _is_ correct in this case, and it works for 4.8 without problems. Joseph, is there some additional magic that has to be added in lto/lto.c for %wx to pass the check?
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 --- Comment #17 from Uros Bizjak ubizjak at gmail dot com 2013-02-09 08:17:41 UTC --- (In reply to comment #16) I didn't notice that my backport to 4.7 caused: ../../gcc-svn/branches/gcc-4_7-branch/gcc/lto/lto.c:1060:68: warning: format ‘%wx’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat] However, %wx _is_ correct in this case, and it works for 4.8 without problems. Joseph, is there some additional magic that has to be added in lto/lto.c for %wx to pass the check? To answer my own question - we have this typedef in output.h: /* This is a magic identifier which allows GCC to figure out the type of HOST_WIDE_INT for %wd specifier checks. You must issue this typedef before using the __asm_fprintf__ format attribute. */ typedef HOST_WIDE_INT __gcc_host_wide_int__; I am testing following additional patch: --cut here-- Index: lto.c === --- lto.c (revision 195911) +++ lto.c (working copy) @@ -25,6 +25,7 @@ #include toplev.h #include tree.h #include tree-flow.h +#include output.h #include diagnostic-core.h #include tm.h #include cgraph.h --cut here--
[Bug target/56256] [4.8 Regression] inline asm with {|} alternatives in it no longer accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56256 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-09 09:30:49 UTC --- Author: jakub Date: Sat Feb 9 09:30:45 2013 New Revision: 195913 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195913 Log: PR target/56256 * config/rs6000/rs6000.h (ASSEMBLER_DIALECT): Define. * gcc.target/powerpc/pr56256.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr56256.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.h trunk/gcc/testsuite/ChangeLog
[Bug target/56256] [4.8 Regression] inline asm with {|} alternatives in it no longer accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56256 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-09 09:31:34 UTC --- Fixed.
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 --- Comment #18 from Uros Bizjak ubizjak at gmail dot com 2013-02-09 09:47:51 UTC --- Fixed again on 4.7 branch by #including output.h in lto.c.
[Bug fortran/55362] [4.6/4.7/4.8 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 --- Comment #4 from Paul Thomas pault at gcc dot gnu.org 2013-02-09 09:49:52 UTC --- Author: pault Date: Sat Feb 9 09:49:49 2013 New Revision: 195915 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195915 Log: 2013-02-09 Paul Thomas pa...@gcc.gnu.org PR fortran/55362 * check.c (array_check): It is an error if a procedure is passed. 2013-02-09 Paul Thomas pa...@gcc.gnu.org PR fortran/55362 * gfortran.dg/intrinsic_size_4.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_size_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
CC||janus at gcc dot gnu.org
Summary|seg fault call procedure|[OOP] seg fault call
|pointer on polymorphic |procedure pointer on
|array |polymorphic array
--- Comment #2 from janus at gcc dot gnu.org 2013-02-09 09:52:54 UTC ---
(In reply to comment #1)
allocate(c(10))
call f(c)
Adding in here a call to ff(c), the dump reveals the difference between the
two calls:
static struct __class_t_Nc_1_0a c = {};
static void (*T4f8) () f = ff;
[..]
__builtin_memset (c._data.data, 0, 40);
c._data.dtype = 297;
c._data.dim[0].lbound = 1;
c._data.dim[0].ubound = 10;
c._data.dim[0].stride = 1;
c._data.offset = -1;
(struct __vtype_t_Nc *) c._vptr = __vtab_t_Nc;
{
struct __class_t_Nc_1_0 class.2;
class.2._data = VIEW_CONVERT_EXPRstruct array1_nc(c._data);
class.2._vptr = c._vptr;
ff (class.2);
}
f ((struct nc[0:] * restrict) c._data.data);
The first part simply sets up the array descriptor for c after the allocation.
Then comes the call to 'ff' (in curly brackets), which is done correctly
(although I'm not quite sure why the temporary 'class.2' is needed). In the
call to 'f', we wrongly pass c._data.data, while we should rather pass 'c' as a
whole (or with a temporary as in the 'ff' case?).
[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE |ICE with size() on |with size() on character |character pointer |pointer --- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2013-02-09 09:55:35 UTC --- I'll deal with 4.6 and 4.7 tomorrow Paul
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #3 from janus at gcc dot gnu.org 2013-02-09 10:03:06 UTC ---
Fortunately there is a simple workaround: Declaring the procedure pointer as
procedure(ff), pointer :: f = ff
makes the segfault go away. The call is then done in the same way as the direct
call to 'ff':
{
struct __class_t_Nc_1_0 class.2;
class.2._data = VIEW_CONVERT_EXPRstruct array1_nc(c._data);
class.2._vptr = c._vptr;
f (class.2);
}
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #4 from janus at gcc dot gnu.org 2013-02-09 10:08:23 UTC ---
Actually I wonder whether the test case is really valid. The problem is: When
declaring the procedure pointer without an interface, we don't know which kind
of argument it expects. Here is a slightly modified variant:
module t
type :: nc
integer :: n = 1
end type nc
contains
subroutine ff(self)
implicit none
class(nc), intent(in), dimension(:) :: self
write (0,*) ' -- content of self(1)%n) is ',self(1)%n
end subroutine
end module t
program p
use t
implicit none
type(nc), dimension(1:10) :: c
procedure(), pointer :: f = ff
call ff(c)
call f(c)
end program p
As the dump shows, we set up a different array descriptor for both cases, since
we don't know that the procedure pointer expects a polymorphic argument:
{
struct array1_nc parm.2;
struct __class_t_Nc_1_0 class.1;
class.1._vptr = (struct __vtype_t_Nc * {ref-all}) __vtab_t_Nc;
parm.2.dtype = 297;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 10;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) c[0];
parm.2.offset = -1;
class.1._data = parm.2;
ff (class.1);
}
{
struct array1_nc parm.3;
parm.3.dtype = 297;
parm.3.dim[0].lbound = 1;
parm.3.dim[0].ubound = 10;
parm.3.dim[0].stride = 1;
parm.3.data = (void *) c[0];
parm.3.offset = -1;
f ((struct nc[0:] *) parm.3.data);
}
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #5 from janus at gcc dot gnu.org 2013-02-09 10:17:16 UTC ---
One can play the same game with scalars, where the situation is even more
severe:
module t
type :: nc
integer :: n = 1
end type nc
contains
subroutine ff(self)
implicit none
class(nc), intent(in) :: self
write (0,*) ' -- content of self%n) is ',self%n
end subroutine
end module t
program p
use t
implicit none
type(nc) :: c
procedure(), pointer :: f = ff
call ff(c)
call f(c)
end program p
The dump shows:
{
struct __class_t_Nc class.1;
class.1._vptr = (struct __vtype_t_Nc * {ref-all}) __vtab_t_Nc;
class.1._data = c;
ff (class.1);
}
f (c);
i.e. we set up a polymorphic temporary for the 'ff' call, which we don't do for
'f' since we don't know that it expects a CLASS argument.
Fixing this for the array case would be possible, if we just use the
'polymorphic' version of the array descriptor everywhere.
In the scalar case, we would have to set up a class container, for every call
to a procedure pointer without interface, which is passed a TYPE or CLASS
argument. This would then in turn mean we have to wrap the argument of the
original function 'ff' in a class container, even if it is TYPE. AFAICS, this
could even mean we need an class container (or array descriptor) for *every*
TYPE(t) variable, which would be a rather dramatic change in implementation
(and in principle also affects pure F95 code).
I sincerely hope that all the test cases in this PR are invalud. One should
check the standard!
Btw, do other compilers handle this stuff?
[Bug target/56263] New: [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
Bug #: 56263
Summary: [avr] Provide strict address-space checking
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: g...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: demiurg_...@freemail.ru
Target: avr
Created attachment 29401
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29401
Test case that shall error with strict address spaces
The intrinsic address spaces introduced with PR49868 are imlemented in such a
way that each address space is a subset of each other.
This allows code like follows to operate as expected and without warnings:
char read_char (const char *address, int data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
Currently, targetm.addr_space_subset_p returns always true in order to allow
pointer casts like above without diagnostics.
avr.c:avr_addr_space_subset_p() could be implemented in such a way, that it
returns true iff the respective ASes are physical subsets of each other, and
not only if their address, regarded as number, are subsets.
In order not to change the current ABI, this can be achieved by a new command
line option like -maddr-space-subset that allows the user to pick the model of
his favor.
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-09 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug tree-optimization/56264] New: ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56264
Bug #: 56264
Summary: ICE in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:557
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Using GCC 4.8.0 as of 220130209 :
$ cat check.c
int a, b, c;
void f(void)
{
if(b)
{
for(a = 0; a 1; a++)
lbl:
c = c b ? : 0;
c = 0;
goto lbl;
}
if(a)
goto lbl;
}
$ xgcc -w -O2 -funswitch-loops check.c
check.c: In function ‘f’:
check.c:3:6: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:557
void f(void)
^
0x9d90f6 check_loop_closed_ssa_use
../../srcdir/gcc/tree-ssa-loop-manip.c:556
0x9dac42 verify_loop_closed_ssa(bool)
../../srcdir/gcc/tree-ssa-loop-manip.c:602
0x83eede execute_function_todo
../../srcdir/gcc/passes.c:1974
0x83f757 execute_todo
../../srcdir/gcc/passes.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/56264] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56264 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-09 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-02-09 12:14:45 UTC --- Confirmed.
[Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56264 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Summary|ICE in |[4.8 Regression] ICE in |check_loop_closed_ssa_use, |check_loop_closed_ssa_use, |at |at |tree-ssa-loop-manip.c:557 |tree-ssa-loop-manip.c:557 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2013-02-09 13:36:55 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=195879
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Evgeny Grin karlson2k at gmail dot com changed: What|Removed |Added CC||karlson2k at gmail dot com --- Comment #14 from Evgeny Grin karlson2k at gmail dot com 2013-02-09 15:03:24 UTC --- Reconfirming this problem for GCC 4.7.2 Configured with: ../../source/gcc-4.7.2/configure --build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-w64-mingw32 --disable-nls --disable-multilib --prefix=/home/xxx/mingw-w64/mingw-w64-i686 --with-sysroot=/home/xxx/mingw-w64/mingw-w64-i686 --with-native-system-header-dir=/i686-w64-mingw32/include --with-host-libstdcxx=/mingw/lib/gcc/mingw32/4.7.2/libstdc++.a --disable-cloog-version-check --disable-ppl-version-check --with-mpc=/home/xxx/mingw-w64/packages/gcc/packages/mpc/mpc-1.0.1-i686 --with-mpfr=/home/xxx/mingw-w64/packages/gcc/packages/mpfr/mpfr-3.1.1-i686 --with-gmp=/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686 --with-ppl=/home/xxx/mingw-w64/packages/gcc/packages/ppl/ppl-1.0-i686 --with-isl=/home/xxx/mingw-w64/packages/gcc/packages/isl/isl-0.11.1-i686 --with-cloog=/home/xxx/mingw-w64/packages/gcc/packages/cloog-ppl/cloog-ppl-0.15.11-i686 --enable-languages=ada,c,c++ --enable-threads=win32 --enable-fully-dynamic-string --disable-sjlj-exceptions --with-multilib-list=m32 --with-arch=pentium3 --enable-leading-mingw64-underscores --with-dwarf2 --enable-lto --disable-win32-registry --with-win32-nlsapi=unicode --enable-libstdcxx-debug Failed at: rm -rf adainclude rm -rf adalib cp -p ../.././gcc/ada/rts adainclude cp: omitting directory `../.././gcc/ada/rts' make[1]: *** [gnatlib-plain] Error 1 make[1]: Leaving directory `/home/xxx/mingw-w64/packages/gcc/build/4.7.2-i686-w64-mingw32/i686-w64-mingw32/libada' make: *** [all-target-libada] Error 2
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-09 Ever Confirmed|0 |1 --- Comment #6 from janus at gcc dot gnu.org 2013-02-09 15:30:13 UTC --- (In reply to comment #5) I sincerely hope that all the test cases in this PR are invalud. One should check the standard! Whew, good luck: F08, chapter 12.4.2.2: A procedure other than a statement function shall have an explicit interface if it is referenced and (1) a reference to the procedure appears (a) with an argument keyword (12.5.2), or (b) in a context that requires it to be pure, (2) the procedure has a dummy argument that (a) has the ALLOCATABLE, [...] attribute, (b) is an assumed-shape array, (c) is a coarray, (d) is of a parameterized derived type, or (e) is polymorphic, It seems this is not something that the compiler is required to diagnose (probably because that can be hard or impossible in certain cases), but the programmer is responsible for checking this. For comment 1, we should probably throw a warning (at least), but for comment 4 and 5 there is not much we can do, I guess. In general I would advise against using procedure pointers without interface (and EXTERNAL declarations), in particular in OOP code (but also in other cases, because the compiler cannot do any type checking of the arguments, etc). In summary: All test cases shown here are invalid, the compiler is not strictly required to detect this, but we should at least throw a warning where possible (e.g. comment 0 and 1).
[Bug fortran/55907] [4.6/4.7/4.8 Regression] ICE with -fno-automatic -finit-local-zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907 --- Comment #6 from janus at gcc dot gnu.org 2013-02-09 15:34:34 UTC --- The patch in comment 5 regtests cleanly!
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #7 from janus at gcc dot gnu.org 2013-02-09 15:52:55 UTC ---
Here is a patch which rejects comment 0 and 1:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 195915)
+++ gcc/fortran/interface.c(working copy)
@@ -3202,6 +3202,13 @@ gfc_procedure_use (gfc_symbol *sym, gfc_actual_arg
at %L, a-expr-where);
return FAILURE;
}
+
+ if (a-expr a-expr-ts.type == BT_CLASS)
+{
+ gfc_error (Polymorphic argument requires an explicit interface
+ at %L, a-expr-where);
+ return FAILURE;
+}
}
return SUCCESS;
I think it's ok to throw an error (and not just a warning), because a
polymorphic actual arg can only be passed to a polymorphic formal arg, which is
invalid in connection with an implicit interface.
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261 --- Comment #8 from Andrew Benson abensonca at gmail dot com 2013-02-09 16:50:54 UTC --- On the test case in comment 2, ifort v11.1 reports: ifort -o bug.exe bug.F90 bug.F90(23): error #6592: This symbol must be a defined parameter, an enumerator, or an argument of an inquiry function that evaluates to a compile-time constant. [FF] procedure( ), pointer :: f = ff ---^ bug.F90(23): error #6973: This is not a valid initialization expression. [FF] procedure( ), pointer :: f = ff ---^ compilation aborted for bug.F90 (code 1) Same for the scalar case. Interestingly, the workaround doesn't work under ifort - it seems not to like: procedure(ff), pointer :: f = ff but instead needs: procedure(ff), pointer :: f f = ff In fact, if I use: procedure(), pointer :: f f = ff then it compiles without any warnings/errors but segfaults at runtime. With: procedure(ff), pointer :: f f = ff it compiles and runs as expected.
[Bug tree-optimization/56265] New: [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
Bug #: 56265
Summary: [4.8 Regression] ICE in ipa_make_edge_direct_to_target
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
int baz ();
struct A
{
virtual int fn2 () = 0;
virtual int *fn3 ();
double *fn4 ();
int fn5 (int);
template class T
void fn1 (A , T) { fn3 (); fn4 (); fn2 (); }
};
struct B : A
{
int fn2 () { return 6; }
void fn3 (int, double);
B (bool = true);
B (int, int);
};
template typename T
void
foo (B x, A y, A z)
{
y.fn2 ();
z.fn2 ();
int i = baz ();
int j = (y.fn3 ())[i];
x.fn3 (j, (y.fn4 ())[i] + (z.fn4 ())[z.fn5 (j)]);
}
inline B
operator+ (A y, A z)
{
B x;
fooint (x, y, z);
return x;
}
void
bar ()
{
B a, b, c (4, 0), d;
a.fn1 (b, .6);
baz ();
c + d;
}
ICEs at -O2, starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=195066
[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-09 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261 --- Comment #9 from janus at gcc dot gnu.org 2013-02-09 16:58:54 UTC --- (In reply to comment #8) On the test case in comment 2, comment 1? ifort v11.1 reports: ifort -o bug.exe bug.F90 bug.F90(23): error #6592: This symbol must be a defined parameter, an enumerator, or an argument of an inquiry function that evaluates to a compile-time constant. [FF] procedure( ), pointer :: f = ff ---^ bug.F90(23): error #6973: This is not a valid initialization expression. [FF] procedure( ), pointer :: f = ff ---^ compilation aborted for bug.F90 (code 1) Same for the scalar case. Thanks for checking. Probably ifort does not support pointer initialization yet (which is a F08 feature). Interestingly, the workaround doesn't work under ifort - it seems not to like: procedure(ff), pointer :: f = ff but instead needs: procedure(ff), pointer :: f f = ff Again, pointer initialization. In fact, if I use: procedure(), pointer :: f f = ff then it compiles without any warnings/errors but segfaults at runtime. With: procedure(ff), pointer :: f f = ff it compiles and runs as expected. Good, that's compatible with gfortran's behavior (which is fine, since the test case is invalid). Apparently ifort also lacks diagnostics for this.
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261 --- Comment #10 from Andrew Benson abensonca at gmail dot com 2013-02-09 17:01:22 UTC --- You're right - comment 1.
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261 --- Comment #11 from Andrew Benson abensonca at gmail dot com 2013-02-09 17:06:18 UTC --- Thanks for figuring out the problem here. When I specify an interface for the procedure pointer in the original code that I derived the test case from, everything works OK.
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from Ian Lance Taylor ian at airs dot com 2013-02-09 17:56:13 UTC --- I committed a patch for that failure yesterday.
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2013-02-09 18:08:51 UTC --- Which does not work. ERROR: Couldn't find library file timeout.exp.
[Bug target/50678] [4.7/4.8 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #83 from Georg georggcc at googlemail dot com 2013-02-09 18:10:26 UTC --- (In reply to comment #82) Hopefully fixed once for all. Just to confirm: === acats Summary === # of expected passes2320 # of unexpected failures0 === gnat Summary === # of expected passes1158 # of expected failures 17 # of unsupported tests 5 $ gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-apple-darwin11.4.2 Configured with: /Users/bauhaus/src/gcc/configure --prefix=/Users/bauhaus/bauhaus/mine --disable-nls --disable-libstdcxx-pch --enable-languages=c,ada,c++,fortran CC=gcc Thread model: posix gcc version 4.8.0 20130208 (experimental) [trunk revision 195897] (GCC)
[Bug fortran/56266] New: ICE on invalid in gfc_match_varspec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56266 Bug #: 56266 Summary: ICE on invalid in gfc_match_varspec Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: abenso...@gmail.com The following causes an ICE with trunk (and 4.6 and 4.7): module t type nc contains procedure :: encM = em end type nc contains double precision function em(self) implicit none class (nc), intent(inout) :: c em=0.0d0 return end function em double precision function cem(c) implicit none class (nc), intent(inout) :: c cem=c(i)%encM() return end function cem end program p $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown- linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure -- prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran -- disable-multilib --with-gmp=/home/abenson/Galacticus/Tools Thread model: posix gcc version 4.8.0 20130208 (experimental) (GCC) $ gfortran -o bug.exe bug.F90 f951: internal compiler error: in gfc_match_varspec, at fortran/primary.c:1960 0x540478 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc-trunk/gcc/fortran/primary.c:1957 0x541a99 gfc_match_rvalue(gfc_expr**) ../../gcc-trunk/gcc/fortran/primary.c:3118 0x528d8e match_primary ../../gcc-trunk/gcc/fortran/matchexp.c:157 0x528d8e match_level_1 ../../gcc-trunk/gcc/fortran/matchexp.c:211 0x528d8e match_mult_operand ../../gcc-trunk/gcc/fortran/matchexp.c:265 0x528fc8 match_add_operand ../../gcc-trunk/gcc/fortran/matchexp.c:354 0x5292e4 match_level_2 ../../gcc-trunk/gcc/fortran/matchexp.c:478 0x529382 match_level_3 ../../gcc-trunk/gcc/fortran/matchexp.c:549 0x529495 match_level_4 ../../gcc-trunk/gcc/fortran/matchexp.c:597 0x529495 match_and_operand ../../gcc-trunk/gcc/fortran/matchexp.c:691 0x529652 match_or_operand ../../gcc-trunk/gcc/fortran/matchexp.c:720 0x529742 match_equiv_operand ../../gcc-trunk/gcc/fortran/matchexp.c:763 0x529834 match_level_5 ../../gcc-trunk/gcc/fortran/matchexp.c:809 0x528be1 gfc_match_expr(gfc_expr**) ../../gcc-trunk/gcc/fortran/matchexp.c:868 0x522631 gfc_match(char const*, ...) ../../gcc-trunk/gcc/fortran/match.c:1103 0x523b19 gfc_match_assignment() ../../gcc-trunk/gcc/fortran/match.c:1301 0x537449 match_word ../../gcc-trunk/gcc/fortran/parse.c:65 0x537bdb match_word ../../gcc-trunk/gcc/fortran/parse.c:326 0x537bdb decode_statement ../../gcc-trunk/gcc/fortran/parse.c:326 0x539194 next_free ../../gcc-trunk/gcc/fortran/parse.c:777 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. This is with gfortran 4.8.0 r195874 The code is invalid because of this line: cem=c(i)%encM() both because c is not an array, and i is not declared (and the function is IMPLICIT NONE)
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #7 from Ian Lance Taylor ian at airs dot com 2013-02-09 18:17:13 UTC --- Sorry about that, I was told that it worked. Can you figure out why it doesn't work? It seems straightforward enough. The file gcc/testsuite/lib/go.exp does a load_lib of other files from that directory.
[Bug lto/52516] FAIL: gfortran.dg/lto/pr45586* f_lto_pr45586*_0.o-f_lto_pr45586_0.o link, -O0 -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52516 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2013-02-09 18:19:28 UTC --- I suggest this be marked as xfail, referring to PR45586.
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #12 from janus at gcc dot gnu.org 2013-02-09 18:25:33 UTC ---
I just noticed that there is already related diagnostics in resolve.c
(resolve_global_procedure):
/* F2003, 12.3.1.1 (2d); F2008, 12.4.2.2 (2e) */
else if (arg-sym-ts.type == BT_CLASS)
{
gfc_error (Procedure '%s' at %L with polymorphic dummy
argument '%s' must have an explicit interface,
sym-name, sym-declared_at, arg-sym-name);
break;
}
As a consequnce, whole_file_20.f03 now fails (due to a double error message).
Further, abstract_type_6.f03 fails, which is fixed by this:
Index: abstract_type_6.f03
===
--- abstract_type_6.f03 (revision 195915)
+++ abstract_type_6.f03 (working copy)
@@ -46,7 +46,7 @@
SUBROUTINE bottom_c(obj)
CLASS(Bottom) :: obj
- CALL top_c(obj)
+ CALL top_c(obj) ! { dg-error requires an explicit interface }
! other stuff
END SUBROUTINE bottom_c
end module
[Bug other/56245] -fsanitize=address miscompiles GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-09 18:41:05 UTC --- Author: jakub Date: Sat Feb 9 18:41:00 2013 New Revision: 195918 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195918 Log: PR other/56245 * regex.c (PTR_INT_TYPE): Define. (EXTEND_BUFFER): Change incr type from int to PTR_INT_TYPE. Modified: trunk/libiberty/ChangeLog trunk/libiberty/regex.c
[Bug libstdc++/56111] [4.8 Regression] {float,double,long double} complex not accepted anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-09 18:42:48 UTC --- Given this is now P1, could the #c9 patch be committed soon, and perhaps just defer a testcase for it when Marc returns?
[Bug other/56245] -fsanitize=address miscompiles GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56245 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-09 18:45:14 UTC --- Fixed.
[Bug libstdc++/56267] New: [4.7/4.8 Regression] unordered containers require Assignable hash function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56267
Bug #: 56267
Summary: [4.7/4.8 Regression] unordered containers require
Assignable hash function
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
#include unordered_set
struct hash : std::hashint
{
hash operator=(const hash) = delete;
};
int main()
{
std::unordered_setint, hash s{ 0, 1, 2 };
auto i = s.begin(0);
i = i;
}
The standard does not require hash functions to be assignable.
We must cache the hash code unless is_copy_assignableH is true, I'm testing
the fix.
[Bug c++/56268] New: [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56268 Bug #: 56268 Summary: [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ko...@xs4all.nl Created attachment 29402 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29402 Sample code to reproduce the problem This issue is quite similar to bug 55842. Compiling the attached sample file leads to an internal compiler error. The problem only occurs with GCC-4.7 from Debian Unstable 4.7.2-5 and the upcoming 4.8 from Debian Experimental 4.8-20130127-1. Tested on an amd64 system. (GCC 4.6 works, properly.) I'm using a checkout of the latest boost release tree. The command to reproduce the issue is: gcc-4.8 -std=c++11 -c -I/src/boost/release test.cpp In file included from /src/boost/release/boost/config.hpp:57:0, from /src/boost/release/boost/variant/detail/config.hpp:16, from /src/boost/release/boost/variant/variant.hpp:23, from /src/boost/release/boost/variant.hpp:17, from test.cpp:2: /src/boost/release/boost/type_traits/has_nothrow_copy.hpp: In instantiation of 'const bool boost::detail::has_nothrow_copy_impboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ::value': /src/boost/release/boost/type_traits/has_nothrow_copy.hpp:32:1: required from 'struct boost::has_nothrow_copyboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ' /src/boost/release/boost/variant/variant.hpp:1908:17: required from 'void boost::variantT0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19::assigner::internal_visit(const RhsT, int) [with RhsT = boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ; T0_ = boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ; T1 = boost::detail::variant::void_; T2 = boost::detail::variant::void_; T3 = boost::detail::variant::void_; T4 = boost::detail::variant::void_; T5 = boost::detail::variant::void_; T6 = boost::detail::variant::void_; T7 = boost::detail::variant::void_; T8 = boost::detail::variant::void_; T9 = boost::detail::variant::void_; T10 = boost::detail::variant::void_; T11 = boost::detail::variant::void_; T12 = boost::detail::variant::void_; T13 = boost::detail::variant::void_; T14 = boost::detail::variant::void_; T15 = boost::detail::variant::void_; T16 = boost::detail::variant::void_; T17 = boost::detail::variant::void_; T18 = boost::detail::variant::void_; T19 = boost::detail::variant::void_]' /src/boost/release/boost/variant/detail/visitation_impl.hpp:130:9: required from 'typename Visitor::result_type boost::detail::variant::visitation_impl_invoke_impl(int, Visitor, VoidPtrCV, T*, mpl_::true_) [with Visitor = boost::variantboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ::assigner; VoidPtrCV = const void*; T = boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ; typename Visitor::result_type = void; mpl_::true_ = mpl_::bool_true]' /src/boost/release/boost/variant/detail/visitation_impl.hpp:173:9: required from 'typename Visitor::result_type boost::detail::variant::visitation_impl_invoke(int, Visitor, VoidPtrCV, T*, NoBackupFlag, int) [with Visitor = boost::variantboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ::assigner; VoidPtrCV = const void*; T = boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ; NoBackupFlag = boost::variantboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ::has_fallback_type_; typename Visitor::result_type = void]' /src/boost/release/boost/variant/detail/visitation_impl.hpp:256:5: required from 'typename Visitor::result_type boost::detail::variant::visitation_impl(int, int, Visitor, VoidPtrCV, mpl_::false_, NoBackupFlag, Which*, step0*) [with Which = mpl_::int_0; step0 = boost::detail::variant::visitation_impl_stepboost::mpl::l_iterboost::mpl::l_itemmpl_::long_1l, boost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u , boost::mpl::l_end , boost::mpl::l_iterboost::mpl::l_end ; Visitor = boost::variantboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ::assigner; VoidPtrCV = const void*; NoBackupFlag = boost::variantboost::multiprecision::numberboost::multiprecision::backends::cpp_int_backend64u, 0u ::has_fallback_type_; typename Visitor::result_type = void; mpl_::false_ = mpl_::bool_false]'
[Bug c++/56268] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant during assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56268 --- Comment #1 from koraq at xs4all dot nl 2013-02-09 18:59:52 UTC --- Created attachment 29403 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29403 Preprocessed source
[Bug c++/55842] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 --- Comment #8 from koraq at xs4all dot nl 2013-02-09 19:01:13 UTC --- Thanks for fixing it, I can confirm this issue has been fixed. I ran into a similar problem and filed it as bug 56268.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 --- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-02-09 19:07:44 UTC --- Created attachment 29404 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29404 untested patch Untested proposed patch.
[Bug tree-optimization/52868] [4.7/4.8 Regression] 4.6 is faster on Atom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-02-09 19:15:15 UTC --- *** This bug has been marked as a duplicate of bug 52272 ***
[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regression of 410.bwaves on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 --- Comment #17 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-02-09 19:15:15 UTC --- *** Bug 52868 has been marked as a duplicate of this bug. ***
[Bug fortran/56269] New: I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 Bug #: 56269 Summary: I've installed gcc but gfortran doesn't work, see in the attached file Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: shimo...@gmail.com Hello, I've got the following error: configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /usr/local/contrib/build2/config.log Thanks!
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 --- Comment #1 from shimonya at gmail dot com 2013-02-09 19:39:14 UTC --- Created attachment 29405 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29405 This is the config.log file
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org 2013-02-09 19:54:30 UTC --- You seem to have a version mix of 4.5.3 and 4.7.2
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 --- Comment #3 from shimonya at gmail dot com 2013-02-09 20:00:07 UTC --- Thank you for your fast reply. What can I do in order to have only version 4.7.2? (In reply to comment #2) You seem to have a version mix of 4.5.3 and 4.7.2
[Bug fortran/56224] [4.8 Regression] gfortran -fopenmp cannot find omp_lib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56224 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-02/msg00415.htm ||l --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-09 20:13:24 UTC --- Patch has been posted.
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org 2013-02-09 20:21:51 UTC --- (In reply to comment #3) Thank you for your fast reply. What can I do in order to have only version 4.7.2? Obviously, you can remove/uninstall version 4.5.3 (the fortran compiler only). Or remove it from the PATH environment variable.
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2013-02-09 20:22:52 UTC --- (In reply to comment #4) (In reply to comment #3) Thank you for your fast reply. What can I do in order to have only version 4.7.2? Obviously, you can remove/uninstall version 4.5.3 (the fortran compiler only). Or remove it from the PATH environment variable. Or move it to somewhere else. Or rename it to something else.
[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529 Evgeny Grin karlson2k at gmail dot com changed: What|Removed |Added CC||karlson2k at gmail dot com --- Comment #3 from Evgeny Grin karlson2k at gmail dot com 2013-02-09 20:30:33 UTC --- Similar error is always on MinGW hosts. MinGW has '.' in front of PATH by default. So if try to build GCC with language that require C++ or to build GCC by C++, you'll always get g++.exe: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found when building inside sources/gcc/gcc subdirectory. When building GCC using C, there no such problem as temporal GCC renamed to xgcc.exe . But when building GCC using C++, temporal g++.exe is placed in gcc subdirectory and erroneously called instead of host g++ if PATH variable is prefixed by '.:' That's the reason because all MinGW GCC builds are failed when building using C++. Tried with GCC 4.7.2
[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976 --- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2013-02-09 20:33:56 UTC --- Created attachment 29406 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29406 Draft patch for the PR This turned out to be easier than I expected. It obviously needs a bit of cleaning up; deferred character length variables should be made consistent with their variable cousins. This will not take much doing and I expect to submit the patch tomorrow. Bootstraps and regtests on trunk. Proto-testcase: type t character(len=:), allocatable :: str_comp end type t type(t) :: x allocate (x%str_comp, source = abc) print *, len (x%str_comp), x%str_comp deallocate (x%str_comp) allocate (x%str_comp, source = abcdefghijklmnop) print *, len (x%str_comp), x%str_comp x%str_comp = xyz print *, len (x%str_comp), x%str_comp x%str_comp = abcdefghijklmnop call foo (x%str_comp) contains subroutine foo (chr) character (*) :: chr print *, len (chr), chr end subroutine end Cheers Paul
[Bug c++/56238] [4.7/4.8 regression] ICE in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2515
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56238 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-02-09 20:38:44 UTC --- Author: jason Date: Sat Feb 9 20:38:33 2013 New Revision: 195920 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195920 Log: PR c++/56238 * pt.c (build_non_dependent_expr): Don't try to fold instantiation-dependent expressions. (instantiation_dependent_r) [TRAIT_EXPR]: Split out. [BIND_EXPR]: Treat as dependent. Added: trunk/gcc/testsuite/g++.dg/template/cast2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/56247] [4.6/4.7/4.8 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:12131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56247 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-02-09 20:39:21 UTC --- Author: jason Date: Sat Feb 9 20:39:13 2013 New Revision: 195922 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195922 Log: PR c++/56247 * pt.c (eq_specializations): Set comparing_specializations. * tree.c (cp_tree_equal): Check it. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/template/ptrmem23.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 --- Comment #6 from shimonya at gmail dot com 2013-02-09 20:43:49 UTC --- Created attachment 29407 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29407 This is the new config.log file
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 --- Comment #7 from shimonya at gmail dot com 2013-02-09 20:45:33 UTC --- Thank you. I renamed it and now I get a new error (see in the new attached file).(In reply to comment #6) Created attachment 29407 [details] This is the new config.log file
[Bug c++/56247] [4.6/4.7/4.8 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:12131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56247 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-02-09 20:47:31 UTC --- Author: jason Date: Sat Feb 9 20:47:24 2013 New Revision: 195923 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195923 Log: PR c++/56247 * pt.c (eq_specializations): Set comparing_specializations. * tree.c (cp_tree_equal): Check it. * cp-tree.h: Declare it. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/ptrmem23.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/cp-tree.h branches/gcc-4_7-branch/gcc/cp/pt.c branches/gcc-4_7-branch/gcc/cp/tree.c
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #8 from Andreas Schwab sch...@linux-m68k.org 2013-02-09 20:48:07 UTC --- The others were already loaded via libgo.exp. Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/prune.exp Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/prune.exp Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/target-libpath.exp Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/target-libpath.exp Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/wrapper.exp Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/wrapper.exp Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/gcc-defs.exp Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/gcc-defs.exp Looking for ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/go.exp Found ../../../../gcc/libgo/testsuite/../../gcc/testsuite/lib/go.exp Looking for library file ../lib/timeout.exp Looking for library file /usr/share/dejagnu/timeout.exp Looking for library file /usr/share/dejagnu/lib/timeout.exp Looking for library file ../../../../gcc/dejagnu/lib/timeout.exp Looking for library file ../../../../gcc/libgo/testsuite/lib/timeout.exp Looking for library file /usr/share/dejagnu/lib/timeout.exp Looking for library file ./timeout.exp Looking for library file ../../../../dejagnu/lib/timeout.exp ERROR: Couldn't find library file timeout.exp.
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #9 from Andreas Schwab sch...@linux-m68k.org 2013-02-09 20:49:39 UTC --- # DejaGnu does not have proper library search paths for load_lib. # We have to explicitly load everything that go.exp wants to load.
[Bug c++/56247] [4.6/4.7/4.8 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:12131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56247 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-02-09 20:54:05 UTC --- Author: jason Date: Sat Feb 9 20:53:59 2013 New Revision: 195924 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195924 Log: PR c++/56247 * pt.c (eq_specializations): Set comparing_specializations. * tree.c (cp_tree_equal): Check it. * cp-tree.h: Declare it. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/ptrmem23.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/cp-tree.h branches/gcc-4_6-branch/gcc/cp/pt.c branches/gcc-4_6-branch/gcc/cp/tree.c
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #10 from Andreas Schwab sch...@linux-m68k.org 2013-02-09 21:03:35 UTC --- mv: cannot stat #8216;.././libgo/libgo.sum#8217;: No such file or directory mv: cannot stat #8216;.././libgo/libgo.log#8217;: No such file or directory cat: .././libgo/libgo.sum.sep: No such file or directory cat: .././libgo/libgo.log.sep: No such file or directory grep: .././libgo/libgo.sum.sep: No such file or directory expr: syntax error /bin/sh: line 28: test: : integer expression expected grep: .././libgo/libgo.sum.sep: No such file or directory expr: syntax error /bin/sh: line 33: test: : integer expression expected grep: .././libgo/libgo.sum.sep: No such file or directory expr: syntax error /bin/sh: line 38: test: : integer expression expected /bin/sh: line 45: test: : integer expression expected /bin/sh: line 48: test: : integer expression expected /bin/sh: line 51: test: : integer expression expected /bin/sh: line 57: test: : integer expression expected
[Bug libstdc++/56257] std::vector allows access to the elements of _Vector_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56257 --- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2013-02-09 21:37:55 UTC --- :-) Sure, and of course I did tell him don't do that. In essence it's a question of how easy it is to shoot yourself in the foot by exposing internal details of the implementation.
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org 2013-02-09 22:40:10 UTC --- Something is seriously flawed on your side. What is your toplevel configure command?
[Bug fortran/56269] I've installed gcc but gfortran doesn't work, see in the attached file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56269 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2013-02-09 22:57:37 UTC --- configure:12799: checking for Fortran compiler version configure:12808: --version 5 ../gcc-4.7.2/libgfortran/configure: line 12810: --version: command not found You also seem like you are build libgfortran by itself which is not supported at all.
[Bug c/53529] assembler errors while building a cross compiler if . (dot) is in your PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53529 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2013-02-09 23:00:37 UTC --- (In reply to comment #3) Similar error is always on MinGW hosts. MinGW has '.' in front of PATH by default. So if try to build GCC with language that require C++ or to build GCC by C++, you'll always get I fixed that issue in 4.8, see PR 54279. The original issue of as/ld in the PATH is recorded here.
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #11 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-02-09 23:02:27 UTC --- Author: ian Date: Sat Feb 9 23:02:09 2013 New Revision: 195926 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195926 Log: PR go/56017 libgo DejaGNU testsuite: Load timeout.exp before go.exp. Modified: trunk/libgo/testsuite/lib/libgo.exp
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #12 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2013-02-09 23:19:41 UTC --- Author: ian Date: Sat Feb 9 23:19:33 2013 New Revision: 195927 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195927 Log: PR go/56017 libgo testsuite: If using DejaGNU, don't frob the log file. Modified: trunk/libgo/Makefile.am trunk/libgo/Makefile.in
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 --- Comment #13 from Ian Lance Taylor ian at airs dot com 2013-02-09 23:20:42 UTC --- Those problems may be fixed, let me know what the next one is.
[Bug c/56270] New: loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Bug #: 56270 Summary: loop over array of struct float causes compiler error: segmentation fault Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: 4303843kiwemnp...@kabelmail.de Created attachment 29408 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29408 Preprocessed file, comment, compiler call, compiler configuration Compiling a loop over an array of struct with members of type float leads to: internal compiler error: Segmentation Fault Occurs optimizing with -O3 Affected gcc versions: 4.7.2, 4.6.3, 4.6.1, 4.5.2 (at least) NOT affected versions: 3.4.3 (at least) Platforms: Solaris 11.1, Ubuntu 12.04.2 LTS (precise), Linux Mint 12 (Lisa); (Ubuntu and LinuxMint in Virtual Box) Solaris uname -a: SunOS xxx 5.11 11.1 i86pc i386 i86pc Ubuntu uname -a Linux xxx 3.2.0-37-generic #58-Ubuntu SMP Thu Jan 24 15:28:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux LinuxMint uname -a: Linux xxx 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Attachment contains preprocessed file and further information
[Bug tree-optimization/56270] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |tree-optimization --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-02-09 23:47:26 UTC --- pinskia@server:~/src/local$ ~/local-gcc/bin/x86_64-unknown-linux-gnu-gcc-4.7.0 -O3 t.c mbb.c: In function ‘Compute’: mbb.c:33:6: internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_store at tree-vect-stmts.c:3920 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. But works on the trunk.
[Bug ada/56271] New: GCC build errors when building ada and using LDFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56271 Bug #: 56271 Summary: GCC build errors when building ada and using LDFLAGS Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: karlso...@gmail.com Host: i686-pc-mingw32 Target: i686-pc-mingw32 Build: x86_64-w64-mingw32, i686-w64-mingw32 GCC is configured with LDFLAGS=-L/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686/lib ../../source/gcc-4.7.2/configure --build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-w64-mingw32 --disable-nls --disable-multilib --prefix=/home/xxx/mingw-w64/mingw-w64-i686 --with-sysroot=/home/xxx/mingw-w64/mingw-w64-i686 --with-native-system-header-dir=/i686-w64-mingw32/include --with-host-libstdcxx=/mingw/lib/gcc/mingw32/4.7.2/libstdc++.a --disable-cloog-version-check --disable-ppl-version-check --with-mpc=/home/xxx/mingw-w64/packages/gcc/packages/mpc/mpc-1.0.1-i686 --with-mpfr=/home/xxx/mingw-w64/packages/gcc/packages/mpfr/mpfr-3.1.1-i686 --with-gmp=/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686 --with-ppl=/home/xxx/mingw-w64/packages/gcc/packages/ppl/ppl-1.0-i686 --with-isl=/home/xxx/mingw-w64/packages/gcc/packages/isl/isl-0.11.1-i686 --with-cloog=/home/xxx/mingw-w64/packages/gcc/packages/cloog-ppl/cloog-ppl-0.15.11-i686 --enable-languages=ada,c,c++ --enable-threads=win32 --enable-fully-dynamic-string --disable-sjlj-exceptions --with-multilib-list=m32 --with-arch=pentium3 --enable-leading-mingw64-underscores --with-dwarf2 --enable-lto --disable-win32-registry --with-win32-nlsapi=unicode --enable-libstdcxx-debug Building ada is always produce some errors like if [ -f gnat1.exe ] ; \ then \ make ADA_CFLAGS= BISON=bison BISONFLAGS= CFLAGS=-pipe -D__USE_MINGW_ACCESS LDFLAGS=-L/home/xxx/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686/lib FLEX=flex FLEXFLAGS= LN=ln LN_S=cp -pR MAKEINFO=makeinfo--split-size=500 MAKEINFOFLAGS=--no-split MAKEOVERRIDES= SHELL=/bin/sh exeext=.exe build_exeext=.exe objext=.o exec_prefix=/home/xxx/mingw-w64/mingw-w64-i686 prefix=/home/xxx/mingw-w64/mingw-w64-i686 local_prefix=/usr/local gxx_include_dir=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/c++/4.7.2 build_tooldir=/home/xxx/mingw-w64/mingw-w64-i686/i686-w64-mingw32 gcc_tooldir=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32 bindir=/home/xxx/mingw-w64/mingw-w64-i686/bin libexecsubdir=/home/xxx/mingw-w64/mingw-w64-i686/libexec/gcc/i686-w64-mingw32/4.7.2 datarootdir=/home/xxx/mingw-w64/mingw-w64-i686/share datadir=/home/xxx/mingw-w64/mingw-w64-i686/share localedir=/home/xxx/mingw-w64/mingw-w64-i686/share/locale ADA_FOR_BUILD= ADA_INCLUDE_DIR=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/adainclude ADA_RTL_OBJ_DIR=/home/xxx/mingw-w64/mingw-w64-i686/lib/gcc/i686-w64-mingw32/4.7.2/adalib ADAFLAGS=-gnatpg -gnata -gnatwns -W -Wall ADA_FOR_TARGET= INSTALL=/bin/install -c INSTALL_DATA=/bin/install -c -m 644 INSTALL_PROGRAM=/bin/install -c install-gnatlib; \ fi /bin/sh: -c: line 2: unexpected EOF while looking for matching `' /bin/sh: -c: line 4: syntax error: unexpected end of file make[1]: [ada.install-common] Error 2 (ignored) As you can see make parameter LDFLAGS=... don't have closing double quote. The reason for this is as follows: 'root' Makefile adds to LDFLAGS: LDFLAGS += -Wl,--stack,12582912 , so ./gcc/Makefile has LDFLAGS = -L/home/Karlson/mingw-w64/packages/gcc/packages/gmp/gmp-5.1.0-i686/lib -Wl,--stack,12582912 that flag in included into FLAGS_TO_PASS by FLAGS_TO_PASS = \ ADA_CFLAGS=$(ADA_CFLAGS) \ BISON=$(BISON) \ BISONFLAGS=$(BISONFLAGS) \ CFLAGS=$(CFLAGS) $(WARN_CFLAGS) \ LDFLAGS=$(LDFLAGS) \ FLEX=$(FLEX) \... which is filtered in included makefile source/gcc/ada/gcc-interface/Make-lang.in: COMMON_FLAGS_TO_PASS = $(filter-out -pedantic -W%, $(FLAGS_TO_PASS)) This filter is supposed to exclude '-pedantic' and all warning control flags, but in real: 1. Don't filter out option not surrounded by spaces, like CFLAGS=-pedantic 2. With '-W%' filter out with closing quote in LDFLAGS=-L/some/path -Wl,--stack,12582912 3. Filter out all -Wp,... -Wl,... -Wa,.. options as well
[Bug c++/56272] New: Poor diagnostics for error: specialization of ... after instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56272
Bug #: 56272
Summary: Poor diagnostics for error: specialization of ...
after instantiation
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test case:
template typename T class A
{
void Invert ()
{
A double a;
}
};
template class Adouble;
template void A double ::Invert ();
g++ -c t.ii
t.ii:11:40: error: specialization of ‘void AT::Invert() [with T = double]’
after instantiation
Yes, but where was instantiation triggered?
In this reduced test case, it's obvious, but in a real test case I have 2MB of
text, the code builds fine with gcc-4.7, and the instantiation point is nowhere
to be seen.
[Bug other/56273] New: [4.8 regression] Bogus -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273
Bug #: 56273
Summary: [4.8 regression] Bogus -Warray-bounds warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dan...@constexpr.org
The following C++ code cause current gcc master to emit an incorrect array
bounds warning:
$ cat test.cpp
struct type {
bool a, b;
bool get_b() { return b; }
};
type stuff[9u];
void bar();
void foo() {
for(unsigned i = 0u; i 9u; i++) {
if(!stuff[i].a) {
continue;
}
bar();
for(unsigned j = i + 1u; j 9u; j++) {
if(stuff[j].a stuff[j].get_b()) {
return;
}
}
}
}
$ g++-4.8.0-pre -Warray-bounds -O3 -c test.cpp
test.cpp: In function ‘void foo()’:
test.cpp:22:17: warning: array subscript is above array bounds [-Warray-bounds]
if(stuff[j].a stuff[j].get_b()) {
^
I appreciate static analyzers as much as everyone, but having false positives
in the normal warnings (especially ones enabled at -Wall) can be annoying.
GCC was build from git master just now:
$ g++-4.8.0-pre -v
Using built-in specs.
COLLECT_GCC=g++-4.8.0-pre
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.0_pre'
Thread model: posix
gcc version 4.8.0-pre 20130210 (experimental) commit
bc85f3af1b43674782c9b5bb2240117f293b5530 (Gentoo 4.8.0_pre)
[Bug other/56273] [4.8 regression] Bogus -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273 --- Comment #1 from Daniel Scharrer daniel at constexpr dot org 2013-02-10 07:07:40 UTC --- The same code and command-line arguments do not produce a warning in gcc 4.7.2, 4.6.3, 4.5.4 and clang 3.2 as well as clang's static analyzer.
[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, ||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-10 Component|other |tree-optimization Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-02-10 07:34:54 UTC --- The problem is a missing VRP. Basically ivopts changes: if (j_10 != 9) Which works into: j_10 = ivtmp.12_56; if (ivtmp.12_56 != 9) goto bb 7; else goto bb 6; Which does not work as VRP cannot figure out j_10 will never be 9. I have some patches to VRP which improves this but I don't remember if it fixes this case where there is an assignment which is used later on.
[Bug bootstrap/53728] [4.6 regression] Bootstrap comparison failure (gcc/varasm.o differs) with CFLAGS=-O2 -march=pentium3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53728 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-02-10 Ever Confirmed|0 |1 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2013-02-10 07:57:30 UTC --- Please test the source from the latest 4.6 SVN branch.
