[Bug lto/54625] [4.8 Regression] lto/profiledbootstrap broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54625
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-09-22 08:06:55 UTC ---
Here is another example (this one triggers the same gcc_assert as in HJ's
regression report):
markus@x4 moz_lto_debug % test.i
float a;
double sin ();
update_filter ()
{
a = sin (0);
}
markus@x4 moz_lto_debug % test.ii
extern C double sin (double);
typedef double (*UnaryFunType) (double);
class A
{
public:
int hash ();
void lookup (UnaryFunType p1)
{
int a = hash ();
p1 (0);
}
};
A b, c;
void
math_sin_impl ()
{
b.lookup (sin);
}
void
js_math_sqrt ()
{
c.lookup (0);
}
markus@x4 moz_lto_debug % gcc -o test.o -c -flto test.i
markus@x4 moz_lto_debug % g++ -r -nostdlib test.o test.ii -flto -O2
In file included from test.ii:1:0,
from :4:
test.ii: In function ‘math_sin_impl’:
test.ii:17:19: internal compiler error: in cgraph_clone_edge, at
cgraphclones.c:123
b.lookup (sin);
^
Please submit a full bug report,
[Bug fortran/54667] New: [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 Bug #: 54667 Summary: [OOP] gimplification failure with c_f_pointer Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Reported by Andrew Benson at http://gcc.gnu.org/ml/fortran/2012-09/msg00078.html: use, intrinsic :: ISO_C_Binding type :: nc end type type(c_ptr) :: cSelf class(nc), pointer :: self call c_f_pointer(cSelf, self) end This ICEs with all gfortran versions I tried. With trunk one gets: gimplification failed: self addr_expr 0x7f163fa3b4b0 type pointer_type 0x7f163fa3c888 type record_type 0x7f163fa3c7e0 __class_MAIN___Nc_p type_4 TI size integer_cst 0x7f163f92bda0 constant 128 unit size integer_cst 0x7f163f92bdc0 constant 16 align 64 symtab 0 alias set -1 canonical type 0x7f163fa3c7e0 fields field_decl 0x7f163fa31850 _data pointer_to_this pointer_type 0x7f163fa3c888 chain type_decl 0x7f163f94db80 D.1882 unsigned DI size integer_cst 0x7f163f92bd20 constant 64 unit size integer_cst 0x7f163f92bd40 constant 8 align 64 symtab 0 alias set -1 canonical type 0x7f163fa3c888 arg 0 var_decl 0x7f163fa31980 self type record_type 0x7f163fa3c7e0 __class_MAIN___Nc_p addressable used TI file andrew3.f90 line 8 col 0 size integer_cst 0x7f163f92bda0 128 unit size integer_cst 0x7f163f92bdc0 16 align 64 context function_decl 0x7f163fa39300 MAIN__ andrew3.f90:10:0 andrew3.f90: In function ‘MAIN__’: andrew3.f90:10:0: internal compiler error: gimplification failed call c_f_pointer(cSelf, self)
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
--- Comment #1 from janus at gcc dot gnu.org 2012-09-22 08:39:44 UTC ---
The dump for comment 0 shows (with -fdump-tree-original):
MAIN__ ()
{
void * cself;
struct __class_MAIN___Nc_p self;
self = (struct __class_MAIN___Nc_p *) cself;
}
Certainly we are missing are reference to the '_data' component of 'self'.
[Bug target/47099] i686-pc-msdosdjgpp fails to build i386.o: ASM_DECLARE_FUNCTION_NAME undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47099
Andris Pavenis andris.pavenis at iki dot fi changed:
What|Removed |Added
CC||andris.pavenis at iki dot
||fi
--- Comment #3 from Andris Pavenis andris.pavenis at iki dot fi 2012-09-22
08:47:25 UTC ---
(In reply to comment #2)
../../../gcc/gcc/config/i386/i386.c: In function ‘void ix86_code_end()’:
../../../gcc/gcc/config/i386/i386.c:8855:55: error:
‘ASM_DECLARE_FUNCTION_NAME’
was not declared in this scope
ASM_DECLARE_FUNCTION_NAME (asm_out_file, name, decl);
^
make[2]: *** [i386.o] Error 1
Adding lines like
#undef ASM_DECLARE_FUNCTION_NAME
#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
do { \
ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL); \
} while (0)
to gcc/config/i386/djgpp.h should fix that for DJGPP target
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 --- Comment #2 from janus at gcc dot gnu.org 2012-09-22 08:53:51 UTC --- The question is if it is really valid. At first sight both F03 and F08 only specify that FPTR, i.e. the second argument to C_F_POINTER, shall be a pointer with INTENT(OUT). However, there are additional constraints depending on the actual value of CPTR: (1) If the value of CPTR is the C address of an interoperable data entity, FPTR shall be a data pointer with type and type parame- ters interoperable with the type of the entity. ... (2) If the value of CPTR is the result of a reference to C LOC with a noninteroperable argument X, FPTR shall be a nonpolymorphic scalar pointer with the same type and type parameters as X. ... While it would be nontrivial to fully enforce these constraints by a runtime check, I think they might effectively mean that FPTR must not be polymorphic: In the second case this constraint is spelled out explicitly, and the first case demands that FPTR shall be interoperable. But polymorphic objects are by definition not interoperable.
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 janus at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code CC||abensonca at gmail dot com --- Comment #3 from janus at gcc dot gnu.org 2012-09-22 09:04:22 UTC --- (In reply to comment #2) While it would be nontrivial to fully enforce these constraints by a runtime check, I think they might effectively mean that FPTR must not be polymorphic: In the second case this constraint is spelled out explicitly, and the first case demands that FPTR shall be interoperable. But polymorphic objects are by definition not interoperable. Note that there are similar constraints on the argument of C_LOC, where we completely reject any polymorphic entities (cf. PR 44925): cSelf = c_loc (self) 1 Error: Parameter 'self' to 'c_loc' at (1) must not be polymorphic I would conclude that this PR should actually be classified as ICE-on-invalid, and we should reject the polymorphic argument to C_F_POINTER. Andrew, have you tried your test case with any other compilers?
[Bug fortran/54668] New: [ICE] with ALLOCATE statement in which the value and rank is determined by reference to another object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54668 Bug #: 54668 Summary: [ICE] with ALLOCATE statement in which the value and rank is determined by reference to another object Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: xarthisius...@gmail.com Hi, following code gives ICE: program ala integer, dimension(3) :: a integer, dimension(:), allocatable :: b a = [1,2,3] allocate(b, source=a) print *, b deallocate(b) end I'm not 100% sure it's valid code so I'll leave keywords blank (though it works with ifort-13.0). It gives ICE with all version of gfortran =4.6, following backtrace: #0 0x7771b5de in __gmpz_set () from /usr/lib64/libgmp.so.10 #1 0x0059d9fc in conformable_arrays (e2=0x14fcd10, e1=0x14fd530) at gcc/fortran/resolve.c:7056 #2 resolve_allocate_expr (code=0x14fd780, e=0x14fcd10) at gcc/fortran/resolve.c:7222 #3 resolve_allocate_deallocate (code=code@entry=0x14fd780, fcn=optimized out, fcn@entry=0xe19de9 ALLOCATE) at gcc/fortran/resolve.c:7614 #4 0x005a1117 in resolve_code (code=0x14fd780, ns=ns@entry=0x14f9230) at gcc/fortran/resolve.c:9793 #5 0x005a2a5f in resolve_codes (ns=ns@entry=0x14f9230) at gcc/fortran/resolve.c:14310 #6 0x0059310c in gfc_resolve (ns=0x14f9230) at gcc/fortran/resolve.c:14337 #7 0x00588eab in resolve_all_program_units (gfc_global_ns_list=0x14f9230) at gcc/fortran/parse.c:4398 #8 gfc_parse_file () at gcc/fortran/parse.c:4665 #9 0x005c4ce6 in gfc_be_parse_file () at gcc/fortran/f95-lang.c:191 #10 0x0093a96c in compile_file () at gcc/toplev.c:546 #11 0x0093c58a in do_compile () at gcc/toplev.c:1863 #12 toplev_main (argc=2, argv=0x7fffdec8) at gcc/toplev.c:1939 #13 0x76c6a6e5 in __libc_start_main () from /lib64/libc.so.6 #14 0x0051d731 in _start () was produced with: 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 --without-ppl --without-cloog --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=yes --disable-libgcj --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 20120922 (experimental) commit f09a218261ba473738ad45f2c643957523019a17 (Gentoo 4.8.0_pre)
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 --- Comment #4 from janus at gcc dot gnu.org 2012-09-22 10:32:40 UTC --- (In reply to comment #3) Andrew, have you tried your test case with any other compilers? ifort 12.1 and Oracle Studio 12.3 seem to accept the test case without error message, which does not mean a lot, I guess. Both are not known for extremely good correctness checking. Or they might allow it as an extension.
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-22 10:32:58 UTC --- Author: tkoenig Date: Sat Sep 22 10:32:51 2012 New Revision: 191640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191640 Log: 2012-09-22 Thomas König tkoe...@gcc.gnu.org PR fortran/54599 * dependency.c (gfc_dep_compare_expr): Clarify logic, remove dead code. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-22 Ever Confirmed|0 |1 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-22 10:34:22 UTC --- The dependency.c issue is fixed.
[Bug fortran/54668] [ICE] with ALLOCATE statement in which the value and rank is determined by reference to another object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54668 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 10:38:19 UTC --- It looks like a duplicate of pr47616. *** This bug has been marked as a duplicate of bug 47616 ***
[Bug fortran/47616] ICE with allocate(a,source=(/1/))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47616 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||xarthisius.kk at gmail dot ||com --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 10:38:19 UTC --- *** Bug 54668 has been marked as a duplicate of this bug. ***
[Bug fortran/47616] ICE with allocate(a,source=(/1/))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47616 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-22 Ever Confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 10:39:41 UTC --- Still present at revision 191639.
[Bug middle-end/54669] New: [4.8 Regression] ICE: verify_flow_info failed: BB 5 last statement has incorrectly set lp with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54669 Bug #: 54669 Summary: [4.8 Regression] ICE: verify_flow_info failed: BB 5 last statement has incorrectly set lp with -fnon-call-exceptions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28247 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28247 reduced testcase Compiler output: $ gcc -O2 -fexceptions -fnon-call-exceptions testcase.c testcase.c: In function 'foo': testcase.c:4:1: error: BB 5 last statement has incorrectly set lp foo (void) ^ testcase.c:4:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Backtrace: (gdb) bt #0 0x0111f2e0 in internal_error(char const*, ...) () #1 0x0069d48e in verify_flow_info() () at /mnt/svn/gcc-trunk/gcc/cfghooks.c:260 #2 0x00a06825 in cleanup_tree_cfg() () at /mnt/svn/gcc-trunk/gcc/tree-cfgcleanup.c:693 #3 0x010ea8d9 in tree_unroll_loops_completely(bool, bool) () at /mnt/svn/gcc-trunk/gcc/tree-ssa-loop-ivcanon.c:648 #4 0x00ad64f2 in tree_complete_unroll_inner() () #5 0x008fb90d in execute_one_pass(opt_pass*) () at /mnt/svn/gcc-trunk/gcc/passes.c:2199 #6 0x008fbcc5 in execute_pass_list(opt_pass*) () at /mnt/svn/gcc-trunk/gcc/passes.c:2254 #7 0x008fbcd7 in execute_pass_list(opt_pass*) () at /mnt/svn/gcc-trunk/gcc/passes.c:2255 #8 0x006c0098 in expand_function(cgraph_node*) () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1601 #9 0x006c1f42 in compile() () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1705 #10 0x006c2535 in finalize_compilation_unit() () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2080 #11 0x0059f930 in c_write_global_declarations() () at /mnt/svn/gcc-trunk/gcc/c/c-decl.c:10116 #12 0x009e0a85 in compile_file() () at /mnt/svn/gcc-trunk/gcc/toplev.c:560 #13 0x009e265a in toplev_main(int, char**) () at /mnt/svn/gcc-trunk/gcc/toplev.c:1863 #14 0x769594bd in __libc_start_main () from /lib64/libc.so.6 #15 0x00586611 in _start () Version: $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-191586-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-191586-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.8.0 20120920 (experimental) (GCC) Tested revisions: r191586 - crash 4.7 r188682 - OK
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 12:37:41 UTC --- *** Bug 47616 has been marked as a duplicate of this bug. ***
[Bug fortran/47616] ICE with allocate(a,source=(/1/))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47616 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 12:37:41 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 45440 ***
[Bug fortran/54668] [ICE] with ALLOCATE statement in which the value and rank is determined by reference to another object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54668 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 12:40:00 UTC --- As a duplicate of pr45440, a work around is (see pr45440#c4): allocate(b(3), source=a)
[Bug c++/54372] __attribute__((unused)) doesn't work with unused local typedef in template function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54372 --- Comment #6 from Kohei Takahashi flast at flast dot jp 2012-09-22 13:06:32 UTC --- I tested on x86_64-linux-gnu and works fine.
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-09-22
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #5 from janus at gcc dot gnu.org 2012-09-22 13:11:14 UTC ---
Here is a patch to reject polymorphic arguments of C_F_POINTER (together with a
bit of cleanup and fixing/improving two other error messages):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 191382)
+++ gcc/fortran/resolve.c(working copy)
@@ -3532,34 +3532,43 @@ gfc_iso_c_sub_interface (gfc_code *c, gfc_symbol *
{
if (c-ext.actual != NULL c-ext.actual-next != NULL)
{
- if (c-ext.actual-expr-ts.type != BT_DERIVED
- || c-ext.actual-expr-ts.u.derived-intmod_sym_id
- != ISOCBINDING_PTR)
+ gfc_actual_arglist *arg1 = c-ext.actual;
+ gfc_actual_arglist *arg2 = c-ext.actual-next;
+
+ /* Check first argument (CPTR). */
+ if (arg1-expr-ts.type != BT_DERIVED
+ || arg1-expr-ts.u.derived-intmod_sym_id != ISOCBINDING_PTR)
{
- gfc_error (Argument at %L to C_F_POINTER shall have the type
- C_PTR, c-ext.actual-expr-where);
+ gfc_error (Argument CPTR to C_F_POINTER at %L shall have
+ the type C_PTR, arg1-expr-where);
m = MATCH_ERROR;
}
- /* Make sure we got a third arg if the second arg has non-zero
- rank.We must also check that the type and rank are
+ /* Check second argument (FPTR). */
+ if (arg2-expr-ts.type == BT_CLASS)
+{
+ gfc_error (Argument FPTR to C_F_POINTER at %L must not be
+ polymorphic, arg2-expr-where);
+ m = MATCH_ERROR;
+}
+
+ /* Make sure we got a third arg (SHAPE) if the second arg has
+ non-zero rank. We must also check that the type and rank are
correct since we short-circuit this check in
gfc_procedure_use() (called above to sort actual args). */
- if (c-ext.actual-next-expr-rank != 0)
+ if (arg2-expr-rank != 0)
{
- if(c-ext.actual-next-next == NULL
- || c-ext.actual-next-next-expr == NULL)
+ if (arg2-next == NULL || arg2-next-expr == NULL)
{
m = MATCH_ERROR;
- gfc_error (Missing SHAPE parameter for call to %s
+ gfc_error (Missing SHAPE argument for call to %s
at %L, sym-name, (c-loc));
}
- else if (c-ext.actual-next-next-expr-ts.type
- != BT_INTEGER
- || c-ext.actual-next-next-expr-rank != 1)
+ else if (arg2-next-expr-ts.type != BT_INTEGER
+ || arg2-next-expr-rank != 1)
{
m = MATCH_ERROR;
- gfc_error (SHAPE parameter for call to %s at %L must
+ gfc_error (SHAPE argument for call to %s at %L must
be a rank 1 INTEGER array, sym-name,
(c-loc));
}
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
--- Comment #6 from janus at gcc dot gnu.org 2012-09-22 13:18:31 UTC ---
Moreover there is a typo in the documentation of C_F_POINTER:
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi(revision 191382)
+++ gcc/fortran/intrinsic.texi(working copy)
@@ -2362,9 +2362,8 @@ end program main
@table @asis
@item @emph{Description}:
-@code{C_F_POINTER(CPTR, FPTR[, SHAPE])} Assign the target the C pointer
-@var{CPTR} to the Fortran pointer @var{FPTR} and specify its
-shape.
+@code{C_F_POINTER(CPTR, FPTR[, SHAPE])} assigns the target of the C pointer
+@var{CPTR} to the Fortran pointer @var{FPTR} and specifies its shape.
@item @emph{Standard}:
Fortran 2003 and later
[Bug middle-end/54669] [4.8 Regression] ICE: verify_flow_info failed: BB 5 last statement has incorrectly set lp with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54669 Marek Polacek polacek at redhat dot com changed: What|Removed |Added CC||polacek at redhat dot com --- Comment #1 from Marek Polacek polacek at redhat dot com 2012-09-22 13:30:11 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=191387
[Bug middle-end/54669] [4.8 Regression] ICE: verify_flow_info failed: BB 5 last statement has incorrectly set lp with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54669
--- Comment #2 from Marek Polacek polacek at redhat dot com 2012-09-22
14:22:46 UTC ---
With very slightly modified testcase:
int a[10];
void
foo (void)
{
int x;
int i;
for (i = 0; i 1;)
{
int b[3];
for (i = 0; i 4; i++)
b[i] = a[i];
if (x)
a[0] = b[0];
}
}
we get:
x.c: In function ‘foo’:
x.c:4:1: error: statement marked for throw, but doesn’t
foo (void)
^
# VUSE .MEM_15
_16 = a[0];
x.c:4:1: error: statement marked for throw, but doesn’t
# .MEM_17 = VDEF .MEM_15
b[0] = _16;
x.c:4:1: error: statement marked for throw, but doesn’t
# VUSE .MEM_17
_21 = a[1];
x.c:4:1: error: statement marked for throw, but doesn’t
# .MEM_22 = VDEF .MEM_17
b[1] = _21;
x.c:4:1: error: statement marked for throw, but doesn’t
# VUSE .MEM_22
_26 = a[2];
x.c:4:1: error: statement marked for throw, but doesn’t
# .MEM_27 = VDEF .MEM_22
b[2] = _26;
x.c:4:1: error: statement marked for throw, but doesn’t
# VUSE .MEM_27
_31 = a[3];
x.c:4:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[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 --- Comment #7 from Daniel Starke daniel.f.starke at freenet dot de 2012-09-22 16:00:03 UTC --- It seems to be partly a gcc autoconfig macro issue. Seeing the following in gcc/acinclude.m4 dnl See if symbolic links work and if not, try to substitute either hard links or simple copy. AC_DEFUN([gcc_AC_PROG_LN_S], [AC_MSG_CHECKING(whether ln -s works) AC_CACHE_VAL(gcc_cv_prog_LN_S, [rm -f conftestdata_t echo conftestdata_f if ln -s conftestdata_f conftestdata_t 2/dev/null then gcc_cv_prog_LN_S=ln -s else if ln conftestdata_f conftestdata_t 2/dev/null then gcc_cv_prog_LN_S=ln else if cp -p conftestdata_f conftestdata_t 2/dev/null then gcc_cv_prog_LN_S=cp -p else gcc_cv_prog_LN_S=cp fi fi fi rm -f conftestdata_f conftestdata_t ])dnl LN_S=$gcc_cv_prog_LN_S if test $gcc_cv_prog_LN_S = ln -s; then AC_MSG_RESULT(yes) else if test $gcc_cv_prog_LN_S = ln; then AC_MSG_RESULT([no, using ln]) else AC_MSG_RESULT([no, and neither does ln, so using $gcc_cv_prog_LN_S]) fi fi AC_SUBST(LN_S)dnl ]) it is obvious that gcc_cv_prog_LN_S=cp -p needs to be changed to gcc_cv_prog_LN_S=cp -pr. On the other hand running autoconfig on this configure.ac: AC_PREREQ(2.64) AC_INIT AC_PROG_LN_S returns the wrong output as also seen in the patch with: if (echo conf$$.file) 2/dev/null; then if ln -s conf$$.file conf$$ 2/dev/null; then as_ln_s='ln -s' # ... but there are two gotchas: # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail. # 2) DJGPP 2.04 has no symlinks; `ln -s' creates a wrapper executable. # In both cases, we have to default to `cp -p'. ln -s conf$$.file conf$$.dir 2/dev/null test ! -f conf$$.exe || as_ln_s='cp -p' elif ln conf$$.file conf$$ 2/dev/null; then as_ln_s=ln else as_ln_s='cp -p' fi else as_ln_s='cp -p' fi The part mentioned by Tim Vanholder that was not in the attached patch was certainly just overseen by me as it was not necessary to build gcc. I have just filed a bug report against autoconf.
[Bug testsuite/54007] lto15.adb fails: gnat1: error: LTO support has not been enabled in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54007 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-09-22 16:46:35 UTC --- Author: danglin Date: Sat Sep 22 16:46:29 2012 New Revision: 191644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191644 Log: Backport from mainline: 2012-09-16 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR testsuite/54007 * gnat.dg/lto15.adb: Require lto. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/lto15.adb
[Bug testsuite/54007] lto15.adb fails: gnat1: error: LTO support has not been enabled in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54007 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2012-09-22 16:49:16 UTC --- Fixed.
[Bug target/54670] New: ICE in extract_insn, at recog.c:2125
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54670 Bug #: 54670 Summary: ICE in extract_insn, at recog.c:2125 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: x86_64-unknown-linux-gnu Target: powerpc-e500v2-linux-gnuspe Build: x86_64-unknown-linux-gnu Created attachment 28248 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28248 preprocessed src Building libxml2 for e500v2 SPE triggers the following ICE $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: powerpc-e500v2-linux-gnuspe Configured with: ../configure --target=powerpc-e500v2-linux-gnuspe --prefix=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe --with-sysroot=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-root --enable-languages=c,c++ --disable-multilib --with-cpu=8548 --with-tune=8548 --with-gmp=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe --with-mpfr=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe --enable-__cxa_atexit --with-local-prefix=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace --enable-e500_double --with-long-double-128 Thread model: posix gcc version 4.8.0 20120922 (experimental) [trunk revision 191643] (GCC) $ ./xgcc -B. ~/ice.i -O /home/ryan/ice.i: In function 'TrioWriteDouble': /home/ryan/ice.i:47:20: warning: incompatible implicit declaration of built-in function 'floor' [enabled by default] workNumber = floor ((double) (fractionNumber + fractionAdjust)); ^ /home/ryan/ice.i:48:21: warning: incompatible implicit declaration of built-in function 'fmod' [enabled by default] index = (int) fmod ((double) (workNumber), (double) (dblBase)); ^ /home/ryan/ice.i: In function 'TrioFormat': /home/ryan/ice.i:81:1: error: unrecognizable insn: } ^ (insn 189 188 103 5 (set (mem/c:TI (plus:SI (reg:SI 24 24) (const_int 2080 [0x820])) [0 %sfp+2080 S16 A128]) (reg:TI 4 4)) /home/ryan/ice.i:47 -1 (nil)) /home/ryan/ice.i:81:1: internal compiler error: in extract_insn, at recog.c:2125 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 --- Comment #7 from Andrew Benson abensonca at gmail dot com 2012-09-22 16:59:26 UTC --- (In reply to comment #3) (In reply to comment #2) While it would be nontrivial to fully enforce these constraints by a runtime check, I think they might effectively mean that FPTR must not be polymorphic: In the second case this constraint is spelled out explicitly, and the first case demands that FPTR shall be interoperable. But polymorphic objects are by definition not interoperable. Note that there are similar constraints on the argument of C_LOC, where we completely reject any polymorphic entities (cf. PR 44925): cSelf = c_loc (self) 1 Error: Parameter 'self' to 'c_loc' at (1) must not be polymorphic I would conclude that this PR should actually be classified as ICE-on-invalid, and we should reject the polymorphic argument to C_F_POINTER. Andrew, have you tried your test case with any other compilers? The only other compiler I have access to is ifort 11.1 (which also accepts it), so that doesn't add much unfortunately.
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 --- Comment #8 from Andrew Benson abensonca at gmail dot com 2012-09-22 17:02:06 UTC --- Thanks for clarifying this. It does look like this is invalid according to the standard. I'll think of another way to do what I was trying to do.
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-22 17:06:45 UTC --- Unreviewed patch: http://gcc.gnu.org/ml/fortran/2012-09/msg00073.html
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-22 17:08:08 UTC --- Incomplete but mostly finished draft patches: https://userpage.physik.fu-berlin.de/~tburnus/final/
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-22 18:38:42 UTC --- (In reply to comment #7) The only other compiler I have access to is ifort 11.1 (which also accepts it), so that doesn't add much unfortunately. As do crayftn and PGI, however, it is a constraint (i.e. the compiler does not have to diagnose it) but required that the user does. From Fortran 2008 15.2.3.6 and 15.2.3.3: CPTR shall be a scalar of type C PTR. It is an INTENT (IN) argument. Its value shall be * the C address of an interoperable data entity, or * the result of a reference to C LOC with a noninteroperable argument. And CLASS is not interoperable, while C_LOC has [...] It shall either be a variable with interoperable type and kind type parameters, or be a scalar, nonpolymorphic variable with no length type parameters. (Note in TS29113, the scalar, has been deleted.)
[Bug other/54671] New: gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 Bug #: 54671 Summary: gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ncahill_...@yahoo.com Created attachment 28249 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28249 broken output file and generating makefile binutils-2.22/gold has an extra test failure when built with gcc 4.7.2. This is the offending command: gcc -Bgcctestdir/ -Wl,--no-ctors-in-init-array -Wl,-O1,--as-needed -o broken_by_gcc_472 a.o With 4.7.1, the test passes. I have put this in the 'other' category as no compilation seems to be taking place. In the attachment, you'll find output files generated with 4.7.2 and 4.7.1 to compare, hopefully the second is obviously broken. Also there is a Makefile to run the offending command, and preprocessed source for the object file being used. Thank you, hope this is enough to find/fix the error. Neil Cahill.
[Bug other/54671] gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 --- Comment #1 from ncahill_alt at yahoo dot com 2012-09-22 19:00:06 UTC --- gcc -v: Using built-in specs. COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7.2/configure --disable-bootstrap --disable-libada --disable-ld --disable-gold --enable-lto --enable-libssp --enable-cloog-backend=isl --without-cloog --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libgomp --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.2/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran,lto --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ Thread model: posix gcc version 4.7.2 (GCC) Neil.
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
--- Comment #10 from janus at gcc dot gnu.org 2012-09-22 19:02:03 UTC ---
(In reply to comment #9)
From Fortran 2008 15.2.3.6 and 15.2.3.3:
CPTR shall be a scalar of type C PTR. It is an INTENT (IN) argument. Its value
shall be
* the C address of an interoperable data entity, or
* the result of a reference to C LOC with a noninteroperable argument.
And CLASS is not interoperable, while C_LOC has
[...] It shall either be a variable with interoperable type and kind type
parameters, or be a scalar, nonpolymorphic variable with no length type
parameters.
(Note in TS29113, the scalar, has been deleted.)
So, in conclusion, I hope you agree that polymorphic arguments should be
rejected for both C_LOC and C_F_POINTER. For C_LOC we do it already, and for
C_F_POINTER my patch in comment 5 is supposed to do it ...
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
--- Comment #11 from Andrew Benson abensonca at gmail dot com 2012-09-22
19:39:17 UTC ---
(In reply to comment #10)
(In reply to comment #9)
From Fortran 2008 15.2.3.6 and 15.2.3.3:
CPTR shall be a scalar of type C PTR. It is an INTENT (IN) argument. Its
value
shall be
* the C address of an interoperable data entity, or
* the result of a reference to C LOC with a noninteroperable argument.
And CLASS is not interoperable, while C_LOC has
[...] It shall either be a variable with interoperable type and kind type
parameters, or be a scalar, nonpolymorphic variable with no length type
parameters.
(Note in TS29113, the scalar, has been deleted.)
So, in conclusion, I hope you agree that polymorphic arguments should be
rejected for both C_LOC and C_F_POINTER. For C_LOC we do it already, and for
C_F_POINTER my patch in comment 5 is supposed to do it ...
Yes - I definitely agree on this point.
[Bug c++/54606] reference assignment failing/points at previous object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54606 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-22 19:46:36 UTC --- (In reply to comment #1) References cannot be assigned in C++, your code just triggers undefined behavior. More to the point it is not undefined behavior but rather: a = Y; invokes the Dummy::operator= .
[Bug tree-optimization/54669] [4.8 regression] verify_flow_info failure after loop unrolling with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54669 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-22 Component|middle-end |tree-optimization Target Milestone|--- |4.8.0 Summary|[4.8 Regression] ICE: |[4.8 regression] |verify_flow_info failed: BB |verify_flow_info failure |5 last statement has|after loop unrolling with |incorrectly set lp with |-fnon-call-exceptions |-fnon-call-exceptions | Ever Confirmed|0 |1 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-22 19:50:11 UTC --- I guess it's the transformation of array accesses with variable index into array accesses with fixed index in conjunction with -fnon-call-exceptions.
[Bug tree-optimization/54669] [4.8 regression] verify_flow_info failure after loop unrolling with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54669 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-22 19:51:45 UTC --- Fixing.
[Bug tree-optimization/54669] [4.8 regression] verify_flow_info failure after loop unrolling with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54669 --- Comment #5 from Marek Polacek polacek at redhat dot com 2012-09-22 20:03:59 UTC --- It happens in cunrolli pass. It might be propagate_constants_for_unrolling. It seems we eventually end up removing BB 9 and 11, which might be wrong.
[Bug tree-optimization/54669] [4.8 regression] verify_flow_info failure after loop unrolling with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54669 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-09/msg01595.htm ||l --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-22 20:34:50 UTC --- It happens in cunrolli pass. It might be propagate_constants_for_unrolling. It seems we eventually end up removing BB 9 and 11, which might be wrong. We just need to update the EH info after the transformation.
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 21:48:01 UTC --- interface.c: gfc_compare_derived_types BUG Same line twice: 450 if ( !(dt1-ts.type == BT_DERIVED derived1 == dt1-ts.u.derived) 451 !(dt1-ts.type == BT_DERIVED derived1 ==dt1-ts.u.derived) This is pr46244.
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22
21:57:52 UTC ---
If I apply the following patch
--- ../_clean/gcc/fortran/resolve.c2012-09-17 15:50:08.0 +0200
+++ gcc/fortran/resolve.c2012-09-22 18:02:47.0 +0200
@@ -7051,10 +7053,15 @@ conformable_arrays (gfc_expr *e1, gfc_ex
mpz_sub (s, s, tail-u.ar.start[i]-value.integer);
mpz_add_ui (s, s, 1);
}
- else
+ else if(tail-u.ar.start[i])
{
mpz_set (s, tail-u.ar.start[i]-value.integer);
}
+ else
+{
+ gcc_unreachable ();
+ /* mpz_set (s, e1-shape[i]); */
+}
if (mpz_cmp (e1-shape[i], s) != 0)
{
the segmentation fault is indeed replaced with
f951: internal compiler error: in conformable_arrays, at fortran/resolve.c:7062
which means that the allocatable corresponding to tail should be decorated
(bounds, size, ...) somewhere (in a way similar to the lhs reallocation on
assignment).
Also the new else if block seems weird in two counts:
(1) I do not see how it can be reached (I tried something such as b(3:), but I
got a syntax error earlier).
(2) I does not make sense for me to compare tail-u.ar.start[i] to
e1-shape[i].
[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-22 Ever Confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 22:21:02 UTC --- (In reply to comment #4) I would assume that this is invalid, since the declaration of compute_routine's interface is somehow 'recursive', i.e. referring to itself. From f2008 draft: 12.4.3.6 Procedure declaration statement ... 2 If proc-interface appears and consists of interface-name, it speci es an explicit speci c interface (12.4.3.2) for the declared procedures or procedure pointers. The abstract interface (12.4) is that speci ed by the interface named by interface-name. My understanding of the above quote is that procedure(compute_routine) :: zfunc has nothing to do with recursiveness, but that zfunc has the same interface as compute_routine. Am I wrong? BTW adding RECURSIVE to compute_routine does not help.
[Bug rtl-optimization/54524] [4.6/4.7/4.8 Regression] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-22 22:26:37 UTC --- I think this code: /* (LTU/GEU (PLUS a C) C), where C is constant, can be simplified to (GEU/LTU a -C). Likewise for (LTU/GEU (PLUS a C) a). */ Is what is causing the issue as that is only true if C is non-zero.
[Bug c/54672] New: \x00 hexadecimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54672 Bug #: 54672 Summary: \x00 hexadecimal Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: arthur.korkin...@gmail.com Created attachment 28250 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28250 Informations (Compilation, Source File, Version , Config Infos) Hi, I am learning buffer overflow with the shellcoder's handbook. When I try to overflow my buffer with a hexadecimal like \xFF the buffer $ebp registry contain the ASCII code of \, x, F, F in place of \xFF. I search for an option like traditionnal but normaly it is removed and nothing resolve my problem. I installed debian (On Virtual machine (x64 host) ) and gcc to follow the book. (But I already knew Linux) I hope this is not a bug, but only a misunderstanding of a student. :) Thank you for your help! Arthur Korkinski
[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52162 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-22 Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-22 22:29:00 UTC --- From comments #1 and #2, I assume that this PR is confirmed, so I set the status to NEW.
[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 --- Comment #7 from janus at gcc dot gnu.org 2012-09-22 22:29:36 UTC --- (In reply to comment #6) (In reply to comment #4) I would assume that this is invalid, since the declaration of compute_routine's interface is somehow 'recursive', i.e. referring to itself. From f2008 draft: 12.4.3.6 Procedure declaration statement [...] My understanding of the above quote is that procedure(compute_routine) :: zfunc has nothing to do with recursiveness, but that zfunc has the same interface as compute_routine. Yes, sure. I'm not claiming that it actually indicates a recursive procedure. All I ment to say was that the *declaration* is 'recursive', in the sense that it refers to itself. (This recursiveness of the declaration is not to be confused with run-time recursiveness, where a procedure calls itself.)
[Bug c/54672] \x00 hexadecimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54672 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-22 22:34:04 UTC --- gets is a direct get string, it does not do any conversion from /xNN or any other conversion at all.
[Bug target/54673] New: [SH] Unnecessary sign extension of logical operation results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54673
Bug #: 54673
Summary: [SH] Unnecessary sign extension of logical operation
results
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
Logical operations already sign extended values as inputs cause additional sign
extensions of intermediate values. For example:
int test00 (char* a, short* b, int c)
{
return a[0] ^ a[1] ^ c;
}
becomes:
mov.b@(1,r4),r0
mov.b@r4,r1
xor r1,r0
exts.b r0,r0
rts
xor r6,r0
int test01 (char* a, short* b, int c)
{
return a[0] | a[1] | c;
}
becomes:
mov.b@(1,r4),r0
mov.b@r4,r1
or r1,r0
exts.b r0,r0
rts
or r6,r0
int test02 (char* a, short* b, int c)
{
return a[0] a[1] c;
}
becomes:
mov.b@(1,r4),r0
mov.b@r4,r1
and r1,r0
exts.b r0,r0
rts
and r6,r0
This seems to be caused by the fact that patterns for xorsi3, iorsi3 and andsi3
allow matching 'subreg' in their operands. In the combine pass it can be
observed that it tries combinations such as:
Failed to match this instruction:
(set (reg:SI 173 [ D.1867 ])
(sign_extend:SI (subreg:QI (xor:SI (subreg:SI (mem:QI (plus:SI (reg/v/f:SI
166 [ a ])
(const_int 1 [0x1])) [0 MEM[(char *)a_2(D) + 1B]+0
S1 A8]) 0)
(subreg:SI (reg:QI 171 [ *a_2(D) ]) 0)) 3)))
which doesn't go anywhere.
I have quickly tried out prohibiting subreg in the operands of the
*xorsi3_compact insn and the sign extension (as well as the subreg orgy in
combine) disappeared. However, I guess that not matching 'subreg' in the
logical patterns will cause problems with DImode logical ops, since they are
split into SImode ops working on subregs.
[Bug tree-optimization/53922] [4.6 Regression] VRP: semantic conflict between range_includes_zero_p and value_inside_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922
Jack Howarth howarth at nitro dot med.uc.edu changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu
--- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2012-09-22
23:46:14 UTC ---
The new gcc.dg/torture/pr53922.c testcase fails on darwin. The darwin linker
developer had the following comments...
---
This is a feature that darwin does not support:
int y(int a) __attribute__ ((weak));
This is a function prototype marked weak. In the linux world, this tells the
static linker it is ok for there to be no definition
+of the function y - just make a PLT entry as if it was found is some shared
object, and somehow it will be magically found at
+runtime.
Darwin uses two-level namespace where the static linker needs to record in
which dylib (shared object) each undefined symbol was
+found. If the symbol cannot be found at static link time, it is an error.
You can make this example work by adding
-undefined dynamic_lookup
to the link line which tells the static linker to assume any unresolved symbol
will be magically found at runtime.
-
Adding...
/* { dg-options -Wl,-undefined,dynamic_lookup { target *-*-darwin* } } */
is confirmed to allow all of the gcc.dg/torture/pr53922.c tests to pass at
-m32/-m64 on x86_64-apple-darwin11.
[Bug target/54674] New: ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 Bug #: 54674 Summary: ICE in build2_stat, at tree.c:3835 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com CC: olege...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: sh4-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Created attachment 28251 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28251 preprocessed src $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: sh4-unknown-linux-gnu Configured with: ../configure --target=sh4-unknown-linux-gnu --prefix=/home/ryan/x-tools/sh4-unknown-linux-gnuc --with-local-prefix=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root --disable-multilib --with-sysroot=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root --with-newlib --enable-threads=no --disable-shared --enable-__cxa_atexit --disable-nls --enable-symvers=gnu --enable-languages=c --enable-target-optspace --enable-checking --disable-libmudflap --disable-libssp Thread model: single gcc version 4.8.0 20120923 (experimental) [trunk revision 191648] (GCC) ~/gnu/gcc/trunk/sh4-build/gcc$ ./xgcc -B. ~/ice.i -Os -c /home/ryan/ice.i: In function 'foo': /home/ryan/ice.i:11:5: warning: incompatible implicit declaration of built-in function 'memcpy' [enabled by default] memcpy (tmp, buf, bytes); ^ /home/ryan/ice.i: In function 'bar': /home/ryan/ice.i:25:1: internal compiler error: in build2_stat, at tree.c:3835 bar (unsigned len) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This ICE appears to be introduced in rev191342 http://gcc.gnu.org/viewcvs?view=revisionrevision=191342
[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Component|target |tree-optimization Target Milestone|--- |4.8.0 Summary|ICE in build2_stat, at |[4.8 Regression] ICE in |tree.c:3835 |build2_stat, at tree.c:3835 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-23 05:24:32 UTC --- That patch just exposed a latent bug in IV-opts it seems.
[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 Andris Pavenis andris.pavenis at iki dot fi changed: What|Removed |Added CC||andris.pavenis at iki dot ||fi --- Comment #8 from Andris Pavenis andris.pavenis at iki dot fi 2012-09-23 05:56:08 UTC --- One also needs LN_S = cp -pr for DJGPP (v 2.0.3 only, current development version supports symlinks)
