[Bug lto/54625] [4.8 Regression] lto/profiledbootstrap broken

[markus at trippelsdorf dot de]

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

--- Comment #3 from Markus Trippelsdorf  
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

[janus at gcc dot gnu.org]

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 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7f163fa3c7e0 fields

pointer_to_this  chain >
unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7f163fa3c888>

arg 0 
addressable used TI file andrew3.f90 line 8 col 0 size  unit size 
align 64 context >
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

[janus at gcc dot gnu.org]

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

[andris.pavenis at iki dot fi]

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

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris.pavenis at iki dot
   ||fi

--- Comment #3 from Andris Pavenis  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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[xarthisius.kk at gmail dot com]

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=, 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

[janus at gcc dot gnu.org]

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  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=gcc&view=rev&rev=191640
Log:
2012-09-22  Thomas König  

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

[tkoenig at gcc dot gnu.org]

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



Thomas Koenig  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-09-22

 Ever Confirmed|0   |1



--- Comment #7 from Thomas Koenig  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

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Dominique d'Humieres  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/))

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||xarthisius.kk at gmail dot

   ||com



--- Comment #3 from Dominique d'Humieres  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/))

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-09-22

 Ever Confirmed|0   |1



--- Comment #4 from Dominique d'Humieres  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

[zsojka at seznam dot cz]

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  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)

[dominiq at lps dot ens.fr]

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



--- Comment #7 from Dominique d'Humieres  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/))

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||DUPLICATE



--- Comment #5 from Dominique d'Humieres  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

[dominiq at lps dot ens.fr]

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



--- Comment #2 from Dominique d'Humieres  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.

[flast at flast dot jp]

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



--- Comment #6 from Kohei Takahashi  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

[janus at gcc dot gnu.org]

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

[janus at gcc dot gnu.org]

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

[polacek at redhat dot com]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||polacek at redhat dot com



--- Comment #1 from Marek Polacek  2012-09-22 
13:30:11 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=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

[polacek at redhat dot com]

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

--- Comment #2 from Marek Polacek  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  for instructions.

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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



--- Comment #7 from Daniel Starke  
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

[danglin at gcc dot gnu.org]

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



--- Comment #4 from John David Anglin  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=gcc&view=rev&rev=191644

Log:

Backport from mainline:

2012-09-16  John David Anglin  



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

[danglin at gcc dot gnu.org]

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



John David Anglin  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from John David Anglin  2012-09-22 
16:49:16 UTC ---

Fixed.

[Bug target/54670] New: ICE in extract_insn, at recog.c:2125

[rmansfield at qnx dot com]

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

[abensonca at gmail dot com]

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



--- Comment #7 from Andrew Benson  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

[abensonca at gmail dot com]

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



--- Comment #8 from Andrew Benson  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

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #5 from Tobias Burnus  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

[burnus at gcc dot gnu.org]

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



--- Comment #12 from Tobias Burnus  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

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  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

[ncahill_alt at yahoo dot com]

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

[ncahill_alt at yahoo dot com]

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

[janus at gcc dot gnu.org]

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

[abensonca at gmail dot com]

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

--- Comment #11 from Andrew Benson  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

[pinskia at gcc dot gnu.org]

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



--- Comment #2 from Andrew Pinski  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

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  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  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

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  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  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

[polacek at redhat dot com]

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



--- Comment #5 from Marek Polacek  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

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2012-09/msg01595.htm

   ||l



--- Comment #6 from Eric Botcazou  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

[dominiq at lps dot ens.fr]

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



--- Comment #8 from Dominique d'Humieres  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)

[dominiq at lps dot ens.fr]

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



--- Comment #8 from Dominique d'Humieres  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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-09-22
 Ever Confirmed|0   |1

--- Comment #6 from Dominique d'Humieres  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)

[pinskia at gcc dot gnu.org]

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



--- Comment #6 from Andrew Pinski  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

[arthur.korkinski at gmail dot com]

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

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-09-22

 Ever Confirmed|0   |1



--- Comment #3 from Dominique d'Humieres  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

[janus at gcc dot gnu.org]

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

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Andrew Pinski  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

[olegendo at gcc dot gnu.org]

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

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



 CC||howarth at nitro dot

   ||med.uc.edu



--- Comment #11 from Jack Howarth  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

[rmansfield at qnx dot com]

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  for instructions.



This ICE appears to be introduced in rev191342



http://gcc.gnu.org/viewcvs?view=revision&revision=191342

[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  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  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

[andris.pavenis at iki dot fi]

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



Andris Pavenis  changed:



   What|Removed |Added



 CC||andris.pavenis at iki dot

   ||fi



--- Comment #8 from Andris Pavenis  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)

[Bug fortran/54599] Issues found in gfortran by the Coverity Scan

[burnus at gcc dot gnu.org]

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



--- Comment #9 from Tobias Burnus  2012-09-23 
06:48:56 UTC ---

Author: burnus

Date: Sun Sep 23 06:48:48 2012

New Revision: 191649



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191649

Log:

2012-09-23  Tobias Burnus  



* parse.c (parse_derived): Don't set attr.alloc_comp

for pointer components with allocatable subcomps.



PR fortran/54599

* resolve.c (resolve_fl_namelist): Remove superfluous

NULL check.

* simplify.c (simplify_min_max): Remove unreachable code.

* trans-array.c (gfc_trans_create_temp_array): Change

a condition into an assert.



PR fortran/54618

* trans-expr.c (gfc_trans_class_init_assign): Guard

re-setting of the _data by gfc_conv_expr_present.

(gfc_conv_procedure_call): Fix INTENT(OUT) handling

for allocatable BT_CLASS.



2012-09-23  Tobias Burnus  



PR fortran/54618

* gfortran.dg/class_array_14.f90: New.





Added:

trunk/gcc/testsuite/gfortran.dg/class_array_14.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/parse.c

trunk/gcc/fortran/resolve.c

trunk/gcc/fortran/simplify.c

trunk/gcc/fortran/trans-array.c

trunk/gcc/fortran/trans-expr.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE

[burnus at gcc dot gnu.org]

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



--- Comment #6 from Tobias Burnus  2012-09-23 
06:48:56 UTC ---

Author: burnus

Date: Sun Sep 23 06:48:48 2012

New Revision: 191649



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191649

Log:

2012-09-23  Tobias Burnus  



* parse.c (parse_derived): Don't set attr.alloc_comp

for pointer components with allocatable subcomps.



PR fortran/54599

* resolve.c (resolve_fl_namelist): Remove superfluous

NULL check.

* simplify.c (simplify_min_max): Remove unreachable code.

* trans-array.c (gfc_trans_create_temp_array): Change

a condition into an assert.



PR fortran/54618

* trans-expr.c (gfc_trans_class_init_assign): Guard

re-setting of the _data by gfc_conv_expr_present.

(gfc_conv_procedure_call): Fix INTENT(OUT) handling

for allocatable BT_CLASS.



2012-09-23  Tobias Burnus  



PR fortran/54618

* gfortran.dg/class_array_14.f90: New.





Added:

trunk/gcc/testsuite/gfortran.dg/class_array_14.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/parse.c

trunk/gcc/fortran/resolve.c

trunk/gcc/fortran/simplify.c

trunk/gcc/fortran/trans-array.c

trunk/gcc/fortran/trans-expr.c

trunk/gcc/testsuite/ChangeLog