[Bug c++/34624] valid c++ code doesn't compile for x86_64, but for i386

[Ralf dot Wildenhues at gmx dot de]

--- Comment #3 from Ralf dot Wildenhues at gmx dot de  2008-01-14 07:42 
---
This fails with both -m32 and -m64 (but I'm not quite sure if it
still reproduces the original issue):


typedef unsigned long size_t;
template struct array { };
template
struct my_table: public array { };

template
inline const sampletype *
get_samples(array const & buffer) {
  return buffer.begin();
}
int main() {
  my_table tab;
  const float * ptr = get_samples(tab);
}


-- 

Ralf dot Wildenhues at gmx dot de changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug c++/34772] [3.4/4.0/4.1/4.2/4.3 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-01-14 02:08 ---
So it seems this worked in 3.3, so it is a regression after all.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
Summary|self-initialisation does not|[3.4/4.0/4.1/4.2/4.3
   |silence uninitialised   |Regression] self-
   |warnings (-Winit-self   |initialisation does not
   |ignored)|silence uninitialised
   ||warnings (-Winit-self
   ||ignored)


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

[Bug c++/34772] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-01-14 01:45 ---
This should work, if it does not then it is a bug.


-- 


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

[Bug c++/34772] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-01-14 01:35 ---
Actually. Winit-self was introduced in GCC 3.4 but the init-self trick was
probably introduced earlier. So this may actually be a regression from much
earlier. Anyway, documenting that it doesn't work seems the right thing to do.


-- 


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

[Bug c++/34772] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-01-14 01:27 ---
(In reply to comment #3)
> I think it would be better to fix the documentation to reflect the current
> behaviour for C++/ObjC++, and mark this bug as an enhancement request.

It is a bit misleading providing -Winit-self when it has no effect and when it
cannot be disabled. But your argument about breaking existing code is solid.
So, of course, I will only update the documentation:

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 130605)
+++ gcc/doc/invoke.texi (working copy)
@@ -2827,14 +2827,15 @@
 @option{-Wnonnull} is included in @option{-Wall} and @option{-Wformat}.  It
 can be disabled with the @option{-Wno-nonnull} option.

[EMAIL PROTECTED] -Winit-self @r{(C, C++, Objective-C and Objective-C++ only)}
[EMAIL PROTECTED] -Winit-self @r{(C and Objective-C only)}
 @opindex Winit-self
 Warn about uninitialized variables which are initialized with themselves.
 Note this option can only be used with the @option{-Wuninitialized} option,
 which in turn only works with @option{-O1} and above.

-For example, GCC will warn about @code{i} being uninitialized in the
-following snippet only when @option{-Winit-self} has been specified:
+For C and Objective-C, GCC will silence the warning about @code{i}
+being uninitialized in the following snippet unless
[EMAIL PROTECTED] has been specified:
 @smallexample
 @group
 int f()
@@ -3094,11 +3095,12 @@
 These warnings are possible only in optimizing compilation,
 because they require data flow information that is computed only
 when optimizing.  If you do not specify @option{-O}, you will not get
-these warnings. Instead, GCC will issue a warning about
@option{-Wuninitialized}
-requiring @option{-O}.
+these warnings. Instead, GCC will issue a warning about
[EMAIL PROTECTED] requiring @option{-O}.

-If you want to warn about code which uses the uninitialized value of the
-variable in its own initializer, use the @option{-Winit-self} option.
+For C and Objective-C, using the uninitialized value of the variable in its
+own initializer (e.g. @samp{int i = i;}) silences the warning. If you
+want to warn about such code use the @option{-Winit-self} option.

 These warnings occur for individual uninitialized or clobbered
 elements of structure, union or array variables as well as for


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|-Winit-self ignored when|self-initialisation does not
   |compiling C++ (and ObjC++)  |silence uninitialised
   ||warnings (-Winit-self
   ||ignored)


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

[Bug fortran/34556] Rejects valid with bogus error message: parameter initalization

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-01-14 01:11 
---
Patch submitted:

http://gcc.gnu.org/ml/fortran/2008-01/msg00170.html


-- 


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

[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2008-01-14 01:01 ---
This is confirmed, isn't it?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-14 01:01:39
   date||


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

[Bug c++/34772] -Winit-self ignored when compiling C++ (and ObjC++)

[olly at survex dot com]

--- Comment #3 from olly at survex dot com  2008-01-14 00:58 ---
If by "delete this option from the C++ FE" you mean that `g++ -Winit-self
[...]' would give an error, I'm not sure that's the best approach if the option
is likely to be sorted out for C++ in the future.  Removing it now will break
existing makefiles which use -Winit-self for C++ compilations.  And once
-Winit-self is sorted out for C++, it will be harder to write a makefile which
gives a warning for self-initialised variables for any GCC version (if it's
left as-is for now, then -Winit-self can just be specified all the time for any
GCC version >= 3.4).

The situation here is slightly odd in that -Winit-self is effectively always on
for C++, so in a way it does work - it's not specifying it (or -Wno-init-self)
which doesn't!

I think it would be better to fix the documentation to reflect the current
behaviour for C++/ObjC++, and mark this bug as an enhancement request.


-- 


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

[Bug c/34735] C99 6.7.4/3 is not diagnose

[geoffk at gcc dot gnu dot org]

--- Comment #3 from geoffk at gcc dot gnu dot org  2008-01-14 00:55 ---
The quoted paragraph does not apply to the first code example, because an
"inline definition" is defined in paragraph 6 as:

If all of the file scope declarations for a function in a translation
unit include the inline function specifier without extern, then the
definition in that translation unit is an inline definition.

In this case, one of the declarations does not include the inline function
specifier, so it's not an inline definition.

I am unclear on how the standard is supposed to apply to the second example,
but IMO we should give the warning anyway.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c++/34772] -Winit-self ignored when compiling C++ (and ObjC++)

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-01-14 00:42 ---
Good catch!

Well, there is something weird going on

$ cc1 -fdump-tree-original -O winit-self.c

{
  int i = i;

int i = i;
  return i;
}

$ cc1plus -fdump-tree-original -O winit-self.c

{
  int i;

int i;
  <>>
>>;
  return  = i;
}


The first problem is that C++ FE does not generate a DECL_EXPR but a BIND_EXPR,
so it does not trigger the conditional in c-gimplify.c (c_gimplify_expr). My
guess is that this have never worked in C++. So we can just delete this option
from the C++ FE and convert this to an enhancement request. If none disagrees,
I will submit a patch in the next days.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-01-14 00:42:56
   date||


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

[Bug bootstrap/34766] Cannot compute suffix of object files

[andry at inbox dot ru]

--- Comment #2 from andry at inbox dot ru  2008-01-14 00:06 ---
(In reply to comment #1)
> /cygdrive/e/Work/gcc_4_3_trunk_2008-01-13_build/./gcc/xgcc: No such file or
> directory
> 
> figure out why the stage1 compile did not generate that.
> 

Yes, may be i had know why :(
http://cygwin.com/ml/cygwin/2008-01/msg00240.html


-- 


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

[Bug fortran/20923] gfortran slow for large array constructors

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2008-01-13 23:00 ---
See also notes/patch attempt in PR 32489.


-- 


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

[Bug fortran/34760] [4.3 Regression] PRIVATE variable not allowed as STAT variable in ALLOCATE

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-01-13 22:57 ---
Regression, caused by the fix for PR 32760.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.0
  Known to work||4.2.2 4.1.3
Summary|PRIVATE variable not allowed|[4.3 Regression] PRIVATE
   |as STAT variable in ALLOCATE|variable not allowed as STAT
   ||variable in ALLOCATE


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

[Bug fortran/34760] PRIVATE variable not allowed as STAT variable in ALLOCATE

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-01-13 22:49 ---
match_variable is called for "istat" in the subroutine. For the first match, it
is FL_UNKNOWN and then - without PRIVATE - it is set to FL_VARIABLE. With
public/private, it remains FL_UNKNOWN.

As for ALLOCATE sym->attr.flavor == FL_VARIABLE is check, it fails therefore as
soon as the variable has been marked as public/private.

match_variable contains:

  switch (sym->attr.flavor)
{
[...]
case FL_UNKNOWN:
  if (sym->attr.access == ACCESS_PUBLIC
  || sym->attr.access == ACCESS_PRIVATE)
break;
  if (gfc_add_flavor (&sym->attr, FL_VARIABLE,
  sym->name, NULL) == FAILURE)
return MATCH_ERROR;
  break;


-- 


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

[Bug c++/34776] [4.1/4.2/4.3 regression] ICE with invalid member declaration in template class

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c++/34776] New: [4.1/4.2/4.3 regression] ICE with invalid member declaration in template class

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.1.0:

===
template struct A
{
  T::X<0> x;
};

A a;
===

bug.cc:3: error: non-template 'X' used as template
bug.cc:3: note: use 'T::template X' to indicate that it is a template
bug.cc: In instantiation of 'A':
bug.cc:6:   instantiated from here
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3 regression] ICE with invalid member
declaration in template class
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug libfortran/34746] [4.3 Regression] wrong formats in libgfortran's runtime_error

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-01-13 22:15 ---
Fixed, closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/34746] [4.3 Regression] wrong formats in libgfortran's runtime_error

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-01-13 22:14 ---
Subject: Bug 34746

Author: tkoenig
Date: Sun Jan 13 22:13:52 2008
New Revision: 131514

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131514
Log:
2008-01-13  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/34746
* m4/iforeach.m4 (name`'rtype_qual`_'atype_code):  Use %ld
in printf format for all bounds checking; cast all
integer-like arguments to runtime_error() to long int.
(`m'name`'rtype_qual`_'atype_code):  Likewise.
(`s'name`'rtype_qual`_'atype_code):  Likewise.
* m4/ifunction.m4 (name`'rtype_qual`_'atype_code):  Likewise.
(`m'name`'rtype_qual`_'atype_code):  Likewise.
(`s'name`'rtype_qual`_'atype_code):  Likewise.
* generated/all_l16.c: Regenerated.
* generated/all_l4.c: Regenerated.
* generated/all_l8.c: Regenerated.
* generated/any_l16.c: Regenerated.
* generated/any_l4.c: Regenerated.
* generated/any_l8.c: Regenerated.
* generated/count_16_l16.c: Regenerated.
* generated/count_16_l4.c: Regenerated.
* generated/count_16_l8.c: Regenerated.
* generated/count_4_l16.c: Regenerated.
* generated/count_4_l4.c: Regenerated.
* generated/count_4_l8.c: Regenerated.
* generated/count_8_l16.c: Regenerated.
* generated/count_8_l4.c: Regenerated.
* generated/count_8_l8.c: Regenerated.
* generated/maxloc0_16_i1.c: Regenerated.
* generated/maxloc0_16_i16.c: Regenerated.
* generated/maxloc0_16_i2.c: Regenerated.
* generated/maxloc0_16_i4.c: Regenerated.
* generated/maxloc0_16_i8.c: Regenerated.
* generated/maxloc0_16_r10.c: Regenerated.
* generated/maxloc0_16_r16.c: Regenerated.
* generated/maxloc0_16_r4.c: Regenerated.
* generated/maxloc0_16_r8.c: Regenerated.
* generated/maxloc0_4_i1.c: Regenerated.
* generated/maxloc0_4_i16.c: Regenerated.
* generated/maxloc0_4_i2.c: Regenerated.
* generated/maxloc0_4_i4.c: Regenerated.
* generated/maxloc0_4_i8.c: Regenerated.
* generated/maxloc0_4_r10.c: Regenerated.
* generated/maxloc0_4_r16.c: Regenerated.
* generated/maxloc0_4_r4.c: Regenerated.
* generated/maxloc0_4_r8.c: Regenerated.
* generated/maxloc0_8_i1.c: Regenerated.
* generated/maxloc0_8_i16.c: Regenerated.
* generated/maxloc0_8_i2.c: Regenerated.
* generated/maxloc0_8_i4.c: Regenerated.
* generated/maxloc0_8_i8.c: Regenerated.
* generated/maxloc0_8_r10.c: Regenerated.
* generated/maxloc0_8_r16.c: Regenerated.
* generated/maxloc0_8_r4.c: Regenerated.
* generated/maxloc0_8_r8.c: Regenerated.
* generated/maxloc1_16_i1.c: Regenerated.
* generated/maxloc1_16_i16.c: Regenerated.
* generated/maxloc1_16_i2.c: Regenerated.
* generated/maxloc1_16_i4.c: Regenerated.
* generated/maxloc1_16_i8.c: Regenerated.
* generated/maxloc1_16_r10.c: Regenerated.
* generated/maxloc1_16_r16.c: Regenerated.
* generated/maxloc1_16_r4.c: Regenerated.
* generated/maxloc1_16_r8.c: Regenerated.
* generated/maxloc1_4_i1.c: Regenerated.
* generated/maxloc1_4_i16.c: Regenerated.
* generated/maxloc1_4_i2.c: Regenerated.
* generated/maxloc1_4_i4.c: Regenerated.
* generated/maxloc1_4_i8.c: Regenerated.
* generated/maxloc1_4_r10.c: Regenerated.
* generated/maxloc1_4_r16.c: Regenerated.
* generated/maxloc1_4_r4.c: Regenerated.
* generated/maxloc1_4_r8.c: Regenerated.
* generated/maxloc1_8_i1.c: Regenerated.
* generated/maxloc1_8_i16.c: Regenerated.
* generated/maxloc1_8_i2.c: Regenerated.
* generated/maxloc1_8_i4.c: Regenerated.
* generated/maxloc1_8_i8.c: Regenerated.
* generated/maxloc1_8_r10.c: Regenerated.
* generated/maxloc1_8_r16.c: Regenerated.
* generated/maxloc1_8_r4.c: Regenerated.
* generated/maxloc1_8_r8.c: Regenerated.
* generated/maxval_i1.c: Regenerated.
* generated/maxval_i16.c: Regenerated.
* generated/maxval_i2.c: Regenerated.
* generated/maxval_i4.c: Regenerated.
* generated/maxval_i8.c: Regenerated.
* generated/maxval_r10.c: Regenerated.
* generated/maxval_r16.c: Regenerated.
* generated/maxval_r4.c: Regenerated.
* generated/maxval_r8.c: Regenerated.
* generated/minloc0_16_i1.c: Regenerated.
* generated/minloc0_16_i16.c: Regenerated.
* generated/minloc0_16_i2.c: Regenerated.
* generated/minloc0_16_i4.c: Regenerated.
* generated/minloc0_16_i8.c: Regenerated.
* generated/minloc0_16_r10.c: Regenerated.
* generated/minloc0_16_r16.c: Regenerated.
* generated/minloc0_16_r4.c: Regenerated.
* gener

[Bug fortran/34765] erroneous intrinsic assignment call

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2008-01-13 22:10 ---
> It turns out this is not a gfortran bug.  My apologies for any time wasted.
Closing then as invalid. Thanks for re-checking.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/33880] ICE: in extract_omp_for_data, at omp-low.c:162

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-01-13 21:54 ---
Jakub, is there any chance that it can still get fixed for 4.3.0?


-- 


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

[Bug fortran/34665] Cannot pass scalar to array argument 'a'

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2008-01-13 21:49 ---
Fixed on the trunk (4.3.0).

Thanks for the report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34763] bare END not allowed in an interface block in a module procedure

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-01-13 21:49 ---
Fixed on the trunk (4.3.0).

Thanks for the report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-01-13 21:49 ---
Fixed on the trunk (4.3.0).

Thanks for the report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34665] Cannot pass scalar to array argument 'a'

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2008-01-13 21:36 ---
Subject: Bug 34665

Author: burnus
Date: Sun Jan 13 21:35:33 2008
New Revision: 131513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131513
Log:
2008-01-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34665
* resolve.c (resolve_actual_arglist): For expressions,
also check for assume-sized arrays.
* interface.c (compare_parameter): Move F2003 character checks
here, print error messages here, reject elements of
assumed-shape array as argument to dummy arrays.
(compare_actual_formal): Update for the changes above.

2008-01-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34665
* gfortran.dg/argument_checking_11.f90: New.
* gfortran.dg/argument_checking_12.f90: New.
* gfortran.dg/used_dummy_types_4.f90: Update dg-error.
* gfortran.dg/c_assoc_2.f03: Update dg-error.
* gfortran.dg/argument_checking_3.f90: Ditto.
* gfortran.dg/pointer_intent_2.f90: Ditto.
* gfortran.dg/import2.f90: Ditto.
* gfortran.dg/assumed_shape_ranks_1.f90: Ditto.
* gfortran.dg/implicit_actual.f90: Ditto.
* gfortran.dg/used_dummy_types_3.f90: Ditto.
* gfortran.dg/derived_comp_array_ref_6.f90: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_11.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_12.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/argument_checking_3.f90
trunk/gcc/testsuite/gfortran.dg/assumed_shape_ranks_1.f90
trunk/gcc/testsuite/gfortran.dg/c_assoc_2.f03
trunk/gcc/testsuite/gfortran.dg/derived_comp_array_ref_6.f90
trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90
trunk/gcc/testsuite/gfortran.dg/import2.f90
trunk/gcc/testsuite/gfortran.dg/pointer_intent_2.f90
trunk/gcc/testsuite/gfortran.dg/used_dummy_types_3.f90
trunk/gcc/testsuite/gfortran.dg/used_dummy_types_4.f90


-- 


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

[Bug fortran/34763] bare END not allowed in an interface block in a module procedure

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-01-13 21:30 ---
Subject: Bug 34763

Author: burnus
Date: Sun Jan 13 21:29:49 2008
New Revision: 131512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131512
Log:
2008-01-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34763
* decl.c (contained_procedure): Only check directly preceeding
* state.

2008-01-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34763
* gfortran.dg/interface_proc_end.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/interface_proc_end.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-01-13 21:29 ---
Subject: Bug 34759

Author: burnus
Date: Sun Jan 13 21:28:30 2008
New Revision: 131511

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131511
Log:
2008-01-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34759
* check.c (gfc_check_shape): Accept array ranges of
assumed-size arrays.

2008-01-13  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34759
* gfortran.dg/assumed_size_refs_4.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

[tbptbp at gmail dot com]

--- Comment #7 from tbptbp at gmail dot com  2008-01-13 21:20 ---
Subject: Re:  [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

On 13 Jan 2008 21:06:07 -, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
> No idea, but I doubt so ;)
Fantastic.
Now i also see the ldexp sometimes not being folded. I know what i'm
doing is kinda evil, but why so much hatred. Snif.


-- 


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

[Bug c++/34406] [reject valid?] incomplete type 'Y' used in nested name specifier.

[pluto at agmk dot net]

--- Comment #4 from pluto at agmk dot net  2008-01-13 21:07 ---
invalid testcase.


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/28326] [4.1 regression] profiledbootstrap will produce an ICE with "-mtune=power3 -mcpu=power3" in BOOT_CFLAGS

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 21:06:20
   date||


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

[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2008-01-13 21:06 ---
Subject: Re:  [4.1/4.2/4.3 Regression] templates, enumerations,
 overflow, ice

On Sun, 13 Jan 2008, tbptbp at gmail dot com wrote:

> --- Comment #5 from tbptbp at gmail dot com  2008-01-13 19:47 ---
> Thanks a lot for your investigations.
> May i ask if the apparent 'quenching' of sign mismatch - and related - 
> warnings
> (that is if you pile enough templates, due warning are never emitted), is in
> any way related to this bug?

No idea, but I doubt so ;)

Richard.


-- 


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

[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

[tbptbp at gmail dot com]

--- Comment #5 from tbptbp at gmail dot com  2008-01-13 19:47 ---
Thanks a lot for your investigations.
May i ask if the apparent 'quenching' of sign mismatch - and related - warnings
(that is if you pile enough templates, due warning are never emitted), is in
any way related to this bug?


-- 


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

[Bug fortran/34556] Rejects valid with bogus error message: parameter initalization

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-01-13 19:38 
---
In gfc_simplify_reshape, gfc_get_array_element is returning a NULL pointer. 
This is due to a failure in expand_constructor.  I am still tracing this.


-- 


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

[Bug rtl-optimization/34773] fwprop1 bug causing miscompilation of vfprintf_r

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |4.3.0


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

[Bug target/30726] bootstrap support for x86_64-*-solaris2.10

[grobian at gentoo dot org]

--- Comment #3 from grobian at gentoo dot org  2008-01-13 19:30 ---
In bug #34775 I've attached a configuration patch that works for me.


-- 


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

[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-13 19:29 ---
Created an attachment (id=14938)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14938&action=view)
unincluded testcase


-- 


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

[Bug target/34775] configuration for x86_64-pc-solaris2.10 target

[grobian at gentoo dot org]

--- Comment #2 from grobian at gentoo dot org  2008-01-13 19:29 ---
I'm sorry for the spam, this should have been reported in bug #30726

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


-- 

grobian at gentoo dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/30726] bootstrap support for x86_64-*-solaris2.10

[grobian at gentoo dot org]

--- Comment #2 from grobian at gentoo dot org  2008-01-13 19:29 ---
*** Bug 34775 has been marked as a duplicate of this bug. ***


-- 

grobian at gentoo dot org changed:

   What|Removed |Added

 CC||grobian at gentoo dot org


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

[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-01-13 19:24 ---
Reduced testcase that is accepted by 3.3 and 3.4 w/o diagnostic but ICEs
starting with 4.0.

typedef unsigned int op_type_u_t;
typedef op_type_u_t op_type_t;
template
struct shift {
  enum {
num_bits = op_type_u_t(sizeof(op_type_t) * 8),
max_shift = num_bits - 1u,
is_left = shifts < 0 ? true : false,
n0 = is_left ? op_type_u_t(-shifts) : op_type_u_t(shifts),
n = n0 > max_shift ? max_shift : n0,
n_comp = max_shift - n
  } x;
};


-- 


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

[Bug target/34775] configuration for x86_64-pc-solaris2.10 target

[grobian at gentoo dot org]

--- Comment #1 from grobian at gentoo dot org  2008-01-13 19:21 ---
Created an attachment (id=14937)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14937&action=view)
solaris x86_64 configuration


-- 


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

[Bug target/34775] New: configuration for x86_64-pc-solaris2.10 target

[grobian at gentoo dot org]

I will attach a patch that allows me to compile a compiler on Solaris 10/x86
that has a native bits size of 64 for produced code.  I created the
configuration analogous to the sparcv9-sun-solaris2.* case.

With this patch I have successfully built a fully 64-bits environment
(toolchain, userland) that appears to work fine.  Essentially the profile just
switches the default code generation from m32 to m64, so no real rocket science
in here ;)


-- 
   Summary: configuration for x86_64-pc-solaris2.10 target
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grobian at gentoo dot org
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: x86_64-pc-solaris2.10


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

[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-01-13 19:17 ---
This is the same issue as PR31714 (which occurs only on the 4.1 branch).

#0  0x084c1ddd in operand_equal_p (arg0=0xb7d275b0, arg1=0xb7d275cc, flags=0)
at /home/richard/src/trunk/gcc/fold-const.c:3015
#1  0x084c4664 in operand_equal_p (arg0=0xb7d23be0, arg1=0xb7d23c20, flags=0)
at /home/richard/src/trunk/gcc/fold-const.c:3157
#2  0x084c48d0 in operand_equal_p (arg0=0xb7d2806c, arg1=0xb7d28090, flags=0)
at /home/richard/src/trunk/gcc/fold-const.c:3162
#3  0x0853fcb1 in fold_ternary (code=COND_EXPR, type=0xb7c84548, 
op0=0xb7d25550, op1=0xb7d2806c, op2=0xb7d28090)
at /home/richard/src/trunk/gcc/fold-const.c:13018
#4  0x08543a00 in fold_build3_stat (code=COND_EXPR, type=0xb7c84548, 
op0=0xb7d25550, op1=0xb7d2806c, op2=0xb7d28090)
at /home/richard/src/trunk/gcc/fold-const.c:13717
#5  0x084e1cc7 in fold_binary_op_with_conditional_arg (code=GT_EXPR, 
type=0xb7c84548, op0=0xb7c7f280, op1=0xb7d2747c, cond=0xb7c7f280, 
arg=0xb7d2747c, cond_first_p=1)
at /home/richard/src/trunk/gcc/fold-const.c:6398
#6  0x08506c18 in fold_binary (code=GT_EXPR, type=0xb7c84548, op0=0xb7c7f280, 
op1=0xb7d2747c) at /home/richard/src/trunk/gcc/fold-const.c:9532
#7  0x08543530 in fold (expr=0xb7d28048)
at /home/richard/src/trunk/gcc/fold-const.c:13331
#8  0x0826d088 in fold_if_not_in_template (expr=0xb7d28048)
at /home/richard/src/trunk/gcc/cp/tree.c:2728
#9  0x081f7043 in build_binary_op (code=GT_EXPR, orig_op0=0xb7c7f280,

(gdb) call debug_tree (arg0)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xb7c842d8 precision
32 min  max 
pointer_to_this >

arg 0 
readonly constant invariant
   index 0 level 1 orig_level 1>>>

we leak template args to middle-end fold.

3.3 emits an error:

mf/unit.h: In instantiation of `metafloat::core::helpers::details::aligner<7,
metafloat::core::float_t<0, 0, 0, CAT_NRM> >':
mf/unit.h:108:   instantiated from
`metafloat::core::helpers::details::normalizer<7,
metafloat::core::helpers::details::aligner<7, metafloat::core::float_t<0, 0, 0,
CAT_NRM> > >'
metafloat.h:135:   instantiated from `metafloat::core::helpers::normalizer<7,
metafloat::core::float_t<0, 0, 0, CAT_NRM>, true>'
metafloat.h:135:   instantiated from `metafloat::core::ops::add'
tf.cc:59:   instantiated from here
mf/unit.h:84: error: no integral type can represent all of the enumerator 
   values for `metafloat::core::helpers::details::aligner<7, 
   metafloat::core::float_t<0, 0, 0, CAT_NRM> >::'

reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
OtherBugsDependingO||31714
  nThis||
   Keywords||ice-on-invalid-code
  Known to fail||3.4.6 4.1.3 4.3.0
  Known to work||3.3.6
   Priority|P3  |P4
Summary|templates, enumerations,|[4.1/4.2/4.3 Regression]
   |overflow, ice   |templates, enumerations,
   ||overflow, ice
   Target Milestone|--- |4.1.3
Version|unknown |4.3.0


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

[Bug bootstrap/28326] [4.1 regression] profiledbootstrap will produce an ICE with "-mtune=power3 -mcpu=power3" in BOOT_CFLAGS

[markus at unixforces dot net]

--- Comment #6 from markus at unixforces dot net  2008-01-13 19:13 ---
still failing with the 4.1-20080107 snapshot


-- 


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

[Bug rtl-optimization/34773] fwprop1 bug causing miscompilation of vfprintf_r

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-13 18:50:30 |2008-01-13 18:50:56
   date||


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

[Bug rtl-optimization/34773] fwprop1 bug causing miscompilation of vfprintf_r

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 18:50:30
   date||


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

[Bug c++/34774] templates, enumerations, overflow, ice

[tbptbp at gmail dot com]

--- Comment #1 from tbptbp at gmail dot com  2008-01-13 18:50 ---
Created an attachment (id=14936)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14936&action=view)
preprocessed offender


-- 


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

[Bug c++/34774] New: templates, enumerations, overflow, ice

[tbptbp at gmail dot com]

While trying to pinpoint an *intermitent* warning/error with g++ 4.3
"mf/unit.h:84: error: no integral type can represent all of the enumerator
values for `metafloat::core::helpers::details::aligner<7u,
metafloat::core::float_t<0l, 0l, 0ul,  CAT_NRM> >::'" i finally
got it to ice with the attached version. Even better, the venerable g++ 3.4 as
shipped by Cygwin also craps out.


$ g++ tf.ii -o tf
In file included from metafloat.h:13,
 from tf.cc:14:
mf/significand.h:37: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://cygwin.com/problems.html> for instructions.
$ /usr/local/gcc-4.3-20080104/bin/g++ tf.ii -o tf
In file included from metafloat.h:14,
 from tf.cc:15:
mf/significand.h:35: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure
--verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libe
xecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --
enable-version-specific-runtime-libs --without-x --enable-libgcj
--disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-thre
ads=posix --enable-java-gc=boehm --disable-win32-registry
--enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
$ /usr/local/gcc-4.3-20080104/bin/g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/usr/local/gcc-4.3-20080104
--enable-languages=c,c++ --enable-threads=posix --disable-checking
--disable-libmudflap --dis
able-nls --disable-shared --disable-win32-registry --disable-multilib
--enable-sjlj-exceptions --with-system-zlib --with-gnu-ld --with-gnu-as
--verbose --enable
-checking=none --disable-bootstrap
Thread model: posix
gcc version 4.3.0 20080104 (experimental) (GCC)


-- 
   Summary: templates, enumerations, overflow, ice
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com


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

[Bug rtl-optimization/34773] fwprop1 bug causing miscompilation of vfprintf_r

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-01-13 18:35 ---
Created an attachment (id=14935)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14935&action=view)
Preprocessed source corresponding to newlib vfprintf.c

Compile with -O2.


-- 


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

[Bug rtl-optimization/34773] New: fwprop1 bug causing miscompilation of vfprintf_r

[hp at gcc dot gnu dot org]

See attachment vf.i.
The bug manifests in code roughly corresponding to the code snippet:
union double_union
{
  double d;
  __uint32_t i[2];
};
union double_union tmp; tmp.d = value;
 if ((tmp.i[1]) & ((__uint32_t)0x8000L)) {
  value = -value;
  *sign = '-';
 } else
  *sign = '\000';

As manifested by the 142.fwprop1 dump compared to 141.cse1 dump, fwprop1 has
changed
(note 628 627 630 101 [bb 101] NOTE_INSN_BASIC_BLOCK)
(insn 630 628 632 101 vf.i:1270 (set (reg:SI 277)
(const_int -2147483648 [0x8000])) 38 {*movsi_internal}
(nil))
(insn 632 630 629 101 vf.i:1270 (clobber (reg/v:DF 77 [ __x.739 ])) -1
(insn_list:REG_LIBCALL 631 (nil)))
(insn 629 632 631 101 vf.i:1270 (set (subreg:SI (reg/v:DF 77 [ __x.739 ]) 0)
(subreg:SI (reg/v:DF 152 [ __x ]) 0)) 38 {*movsi_internal}
(expr_list:REG_NO_CONFLICT (reg/v:DF 152 [ __x ])
(nil)))
(insn 631 629 633 101 vf.i:1270 (set (subreg:SI (reg/v:DF 77 [ __x.739 ]) 4)
(xor:SI (subreg:SI (reg/v:DF 152 [ __x ]) 4)
(reg:SI 277))) 155 {xorsi3} (insn_list:REG_RETVAL 632
(expr_list:REG_NO_CONFLICT (reg/v:DF 152 [ __x ])
(nil

into:
(note 628 627 631 103 [bb 103] NOTE_INSN_BASIC_BLOCK)
(insn 631 628 633 103 vf.i:1270 (set (subreg:SI (reg/v:DF 77 [ __x.739 ]) 4)
(plus:SI (subreg:SI (reg/v:DF 152 [ __x ]) 4)
(const_int -2147483648 [0x8000]))) 75 {*addsi3_non_v32}
(expr_list:REG_NO_CONFLICT (reg/v:DF 152 [ __x ])
(nil)))
(insn 633 631 634 103 vf.i:1270 (set (reg/v:QI 161 [ softsign ])
(const_int 45 [0x2d])) 47 {movqi} (nil))
(code_label 634 633 635 104 86 "" [0 uses])

thereby making the lower part of the mantissa in (reg:DF 77) undefined and the
bug manifestation depending on stack contents.
Trunk of 130734 was used for the dump above.


-- 
   Summary: fwprop1 bug causing miscompilation of vfprintf_r
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: hp at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: cris-elf


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

[Bug c++/34772] -Winit-self ignored when compiling C++ (and ObjC++)

[olly at survex dot com]

--- Comment #1 from olly at survex dot com  2008-01-13 18:23 ---
I've just noticed that Debian have a packaged 4.3 snapshot:

g++-4.3 (Debian 4.3-20080104-1) 4.3.0 20080104 (experimental) [trunk revision
131316]

Testing with this shows the same behaviour for C++.


-- 

olly at survex dot com changed:

   What|Removed |Added

  Known to fail||3.4.4 4.2.1 4.3.0


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

[Bug c/28306] const / pure call with ignored argument emitted.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-01-13 18:22 ---
This works for 'const' functions because they stick on the function type as
well.
The attributes are only on the DECL and do not get merged and transfered to the
resulting function type of the COND_EXPR.

So this again asks for streamlining attributes on types vs. decls.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug c/28289] composite_types called to do two different things

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-13 18:17 ---
34768 has a testcase.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/34768] [4.1/4.2/4.3 Regression] Wrong code with conditional function invocation

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-13 18:17 ---
*** Bug 28289 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug c++/34772] New: -Winit-self ignored when compiling C++ (and ObjC++)

[olly at survex dot com]

The info manual says:

`-Winit-self (C, C++, Objective-C and Objective-C++ only)'
 Warn about uninitialized variables which are initialized with
 themselves.  Note this option can only be used with the
 `-Wuninitialized' option, which in turn only works with `-O1' and
 above.

 For example, GCC will warn about `i' being uninitialized in the
 following snippet only when `-Winit-self' has been specified:
  int f()
  {
int i = i;
return i;
  }

However, trying that exact example, I get:

$ g++-4.2 -O -Wuninitialized -c warnings.cc 
warnings.cc: In function ‘int f()’:
warnings.cc:3: warning: ‘i’ is used uninitialised in this function
$ g++-4.2 -O -Wuninitialized -Wno-init-self -c warnings.cc 
warnings.cc: In function ‘int f()’:
warnings.cc:3: warning: ‘i’ is used uninitialised in this function

Compiling the same code as C:

$ gcc-4.2 -x c -O -Wuninitialized -c warnings.cc 
$ gcc-4.2 -x c -O -Wuninitialized -Winit-self -c warnings.cc
warnings.cc: In function ‘f’:
warnings.cc:3: warning: ‘i’ is used uninitialised in this function
$

So it appears that g++ simply ignores the -Winit-self setting and always warns
about such code, contrary to what the documentation states (and gcc works as
documented).  ObjC seems to handle this as C does (as documented).  ObjC++
seems to handle it as C++ does (contrary to documentation).

This could be viewed as a documentation bug, though it seems more useful for
this to work for C++ (and ObjC++) as is currently documented.

It looks like -Winit-self was new in GCC 3.4, and I can the same behaviour for
C++ with g++ 3.4.4, so I don't think this is a regression.


-- 
   Summary: -Winit-self ignored when compiling C++ (and ObjC++)
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olly at survex dot com


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

[Bug c++/33810] [4.1 Regression] gcc 4.1.2 mangles results on x86_64 in bitfield operations

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
  Known to fail||4.1.3
  Known to work||3.3.6 4.2.3 4.3.0
Summary|gcc 4.1.2 mangles results on|[4.1 Regression] gcc 4.1.2
   |x86_64 in bitfield  |mangles results on x86_64 in
   |operations  |bitfield operations
   Target Milestone|--- |4.1.3


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

[Bug fortran/34765] erroneous intrinsic assignment call

[damian at rouson dot net]

--- Comment #6 from damian at rouson dot net  2008-01-13 17:59 ---
It turns out this is not a gfortran bug.  My apologies for any time wasted.


-- 

damian at rouson dot net changed:

   What|Removed |Added

 CC||damian at rouson dot net


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

[Bug tree-optimization/30930] [4.3 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-01-13 17:57 ---
(In reply to comment #3)
> It indeed works on the 4.2 branch where the loads magically disappear with the
> first may_alias pass.  Possibly because it doesn't pay attention to whether
> DECL_GIMPLE_REG is set or not.

Well DECL_GIMPLE_REG was not needed for vector types before 4.3.0 :) so yes it
was ignored.


-- 


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

[Bug c/34768] [4.1/4.2/4.3 Regression] Wrong code with conditional function invocation

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-01-13 17:49 ---
THis is related to PR 29382 and PR 13519.  And I think this is exactly the same
issue as PR 28289.


-- 


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

[Bug fortran/34759] Assumed size array reference not allowed in SHAPE intrinsic, even though last subscript specified

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-01-13 17:41 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00566.html


-- 


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

[Bug fortran/34763] bare END not allowed in an interface block in a module procedure

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-01-13 17:41 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00567.html


-- 


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

[Bug fortran/34665] Cannot pass scalar to array argument 'a'

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2008-01-13 17:41 ---
> One has to be careful not to to get the same problem as with SHAPE in PR 
> 34759,
> i.e. passing a rank-2 array A(:,:,5) defined as rank-3 assumed-shape array
> A(:,:,*).
This is actually already properly handled.

Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00570.html


-- 


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

[Bug c/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 17:01:48
   date||


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

[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-13 17:00 ---
We enter that function with:

{4294967288B, +, 4}_1

 
unit size 
align 32 symtab 0 alias set 2 canonical type 0x2acbd9dc1540
precision 32 min  max 
pointer_to_this >
sizes-gimplified public unsigned SI size  unit size 
align 32 symtab 0 alias set -1 canonical type 0x2acbd9dd09c0>

arg 0 
constant invariant 1>
arg 1 
constant invariant public overflow 4294967288> arg 2 >

where the HOST_WIDE_INT will be positive (it's not sign-extended).


For -m64 we instead get

{-8B, +, 4}_1

 
unit size 
align 32 symtab 0 alias set 2 canonical type 0x2b1549894540
precision 32 min  max 
pointer_to_this >
sizes-gimplified public unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2b15498a3b40>

arg 0 
constant invariant 1>
arg 1 
constant invariant public overflow 18446744073709551608> arg 2 >

where the HOST_WIDE_INT will be negative.


For consistency you should always use sizetype variables for offsets, as
they are properly sign-extended.  Using pointer types asks for trouble.


-- 


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

[Bug middle-end/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958

[danglin at gcc dot gnu dot org]

--- Comment #9 from danglin at gcc dot gnu dot org  2008-01-13 16:55 ---
Fixed by patch.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-01-13 16:55 ---
> Please provide preprocessed source, as this test pulls in system headers.

Do you need the system headers for Darwin9?

# 1 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c"
# 1 ""
# 1 ""
# 1 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c"

# 1 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 1 3 4

# 19 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 3 4

typedef __builtin_va_list __gnuc_va_list;

# 91 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 3 4

typedef __gnuc_va_list va_list;
# 125 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include/stdarg.h" 3 4

# 4 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c" 2

# 1 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
1 3 4

# 1
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/syslimits.h" 1
3 4

# 1 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
1 3 4

# 120
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h" 3 4

# 1 "/usr/include/limits.h" 1 3 4

# 23 "/usr/include/limits.h" 3 4

# 59 "/usr/include/limits.h" 3 4

# 1 "/usr/include/sys/cdefs.h" 1 3 4

# 28 "/usr/include/sys/cdefs.h" 3 4

# 66 "/usr/include/sys/cdefs.h" 3 4

# 105 "/usr/include/sys/cdefs.h" 3 4

# 128 "/usr/include/sys/cdefs.h" 3 4

# 155 "/usr/include/sys/cdefs.h" 3 4

# 166 "/usr/include/sys/cdefs.h" 3 4

# 180 "/usr/include/sys/cdefs.h" 3 4

# 198 "/usr/include/sys/cdefs.h" 3 4

# 253 "/usr/include/sys/cdefs.h" 3 4

# 288 "/usr/include/sys/cdefs.h" 3 4

# 298 "/usr/include/sys/cdefs.h" 3 4

# 322 "/usr/include/sys/cdefs.h" 3 4

# 387 "/usr/include/sys/cdefs.h" 3 4

# 410 "/usr/include/sys/cdefs.h" 3 4

# 456 "/usr/include/sys/cdefs.h" 3 4

# 64 "/usr/include/limits.h" 2 3 4

# 1 "/usr/include/machine/limits.h" 1 3 4

# 1 "/usr/include/i386/limits.h" 1 3 4

# 35 "/usr/include/i386/limits.h" 3 4

# 1 "/usr/include/i386/_limits.h" 1 3 4

# 24 "/usr/include/i386/_limits.h" 3 4

# 41 "/usr/include/i386/limits.h" 2 3 4

# 61 "/usr/include/i386/limits.h" 3 4

# 83 "/usr/include/i386/limits.h" 3 4

# 96 "/usr/include/i386/limits.h" 3 4

# 9 "/usr/include/machine/limits.h" 2 3 4
# 65 "/usr/include/limits.h" 2 3 4

# 1 "/usr/include/sys/syslimits.h" 1 3 4

# 28 "/usr/include/sys/syslimits.h" 3 4

# 64 "/usr/include/sys/syslimits.h" 3 4

# 87 "/usr/include/sys/syslimits.h" 3 4

# 104 "/usr/include/sys/syslimits.h" 3 4

# 66 "/usr/include/limits.h" 2 3 4

# 75 "/usr/include/limits.h" 3 4

# 89 "/usr/include/limits.h" 3 4

# 107 "/usr/include/limits.h" 3 4

# 118 "/usr/include/limits.h" 3 4

# 123
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h" 2 3
4

# 8
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/syslimits.h" 2
3 4
# 12 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
2 3 4

# 55 "/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h"
3 4

# 102
"/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin9/4.3.0/include-fixed/limits.h" 3 4

# 5 "/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-25.c" 2

__const __attribute__((vector_size(16))) unsigned int v1 = {10,11,12,13};
__const __attribute__((vector_size(16))) unsigned int v2 = {20,21,22,23};

void foo(int a, ...)
{
  va_list args;
  __attribute__((vector_size(16))) unsigned int v;

  __builtin_va_start(args, a);
  v = __builtin_va_arg(args, __attribute__((vector_size(16))) unsigned int);
  if (a != 1 || memcmp (&v, &v1, sizeof (v)) != 0)
abort ();
  a = __builtin_va_arg(args, int);
  if (a != 2)
abort ();
  v = __builtin_va_arg(args, __attribute__((vector_size(16))) unsigned int);
  if (memcmp (&v, &v2, sizeof (v)) != 0)
abort ();
  __builtin_va_end(args);
}

int main(void)
{

  foo (1, (__attribute__((vector_size(16))) unsigned int){10,11,12,13}, 2,
   (__attribute__((vector_size(16))) unsigned int){20,21,22,23});

  return 0;
}


-- 


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

[Bug middle-end/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958

[danglin at gcc dot gnu dot org]

--- Comment #8 from danglin at gcc dot gnu dot org  2008-01-13 16:53 ---
Subject: Bug 34762

Author: danglin
Date: Sun Jan 13 16:53:02 2008
New Revision: 131508

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131508
Log:
PR middle-end/34762
* reload.c (find_reloads_toplev): Use rtx_equal_p to compare x and mem.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/reload.c


-- 


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

[Bug c++/33810] gcc 4.1.2 mangles results on x86_64 in bitfield operations

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-13 16:45 ---
It simply vectorizes all loops in the testcase.  It looks like there may be a
non-canonical sizetype constant (just wild guesses).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 16:45:47
   date||


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

[Bug fortran/34770] Incorrect array indexing through pointer when array does not start at 1

[john at michalakes dot us]

--- Comment #2 from john at michalakes dot us  2008-01-13 16:43 ---
Subject: RE:  Incorrect array indexing through pointer when array does not
start at 1

Will do. Thanks for the quick response. -John

> -Original Message-
> From: burnus at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 13, 2008 9:18 AM
> To: [EMAIL PROTECTED]
> Subject: [Bug fortran/34770] Incorrect array indexing through pointer when
> array does not start at 1
> 
> 
> 
> --- Comment #1 from burnus at gcc dot gnu dot org  2008-01-13 16:17 ---
> 
> I can reproduce it in GCC/gfortran 4.1.3 and 4.2.1, but it works in 4.3.0.
> 
> Could you try with a newer GCC? http://gcc.gnu.org/wiki/GFortranBinaries
> 
> 
> --
> 
> burnus at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> ---
> -
>   Known to fail||4.1.2 4.1.3 4.2.2
>   Known to work||4.3.0
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34770
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> You reported the bug, or are watching the reporter.


-- 


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

[Bug fortran/34765] erroneous intrinsic assignment call

[damian at rouson dot net]

--- Comment #5 from damian at rouson dot net  2008-01-13 16:40 ---
I was trying to demonstrate multiple instances of the bug.  Based on comment
#4, I realize that the compiler performed correctly in at least 3 of the 4
instances. I will now attempt to verify whether the 4th instance is actually a
bug.  My apologies about the other three.


-- 


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

[Bug fortran/34765] erroneous intrinsic assignment call

[damian at rouson dot net]

-- 

damian at rouson dot net changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug c/34601] [4.3 regression] ICE with undefined enum

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-01-13 16:32 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c

[hjl at lucon dot org]

--- Comment #3 from hjl at lucon dot org  2008-01-13 16:31 ---
This bug may only happen when you compile for 32bit on 64bit host.


-- 


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

[Bug c/34601] [4.3 regression] ICE with undefined enum

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-13 16:31 ---
Subject: Bug 34601

Author: rguenth
Date: Sun Jan 13 16:30:51 2008
New Revision: 131506

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131506
Log:
2008-01-13  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/34601
* emit-rtl.c (set_reg_attrs_for_decl_rtl): Use DECL_MODE
instead of TYPE_MODE to deal with calls from expand_one_error_var.

* gcc.dg/noncompile/incomplete-4.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/noncompile/incomplete-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/34406] [reject valid?] incomplete type 'Y' used in nested name specifier.

[bangerth at dealii dot org]

--- Comment #3 from bangerth at dealii dot org  2008-01-13 16:31 ---
(In reply to comment #2)
> i'd ask why the first code is invalid?
> class Y looks pretty complete so why typedef expression throws an error?

A class is complete at the closing brace. You use it before that.

W.


-- 


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

[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c

[hjl at lucon dot org]

--- Comment #2 from hjl at lucon dot org  2008-01-13 16:26 ---
Revision 131429 is the cause.


-- 


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

[Bug tree-optimization/34769] [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c

[hjl at lucon dot org]

--- Comment #1 from hjl at lucon dot org  2008-01-13 16:25 ---
Revision 131429:

http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00367.html


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
OtherBugsDependingO||34458
  nThis||


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

[Bug fortran/34770] Incorrect array indexing through pointer when array does not start at 1

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-01-13 16:17 ---
I can reproduce it in GCC/gfortran 4.1.3 and 4.2.1, but it works in 4.3.0.

Could you try with a newer GCC? http://gcc.gnu.org/wiki/GFortranBinaries


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2 4.1.3 4.2.2
  Known to work||4.3.0


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

[Bug c/34601] [4.3 regression] ICE with undefined enum

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-13 16:13 ---
This works with -funit-at-a-time, where we don't expand.


-- 


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

[Bug target/32431] [4.3 Regression][m68hc11] ICE in df_refs_verify, at df-scan.c:4066

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2008-01-13 16:04 ---
The m68k and m68hc11 are not the same backend.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 16:04:08
   date||


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

[Bug fortran/34771] New: Parenthesis around character variables: No expression

[burnus at gcc dot gnu dot org]

(c) and c
are regarded as the same for character variables; for other types (z) and z are
not the same.

gfc_get_parentheses (gfc_expr *e)
{
  gfc_expr *e2;

  /* This is a temporary fix, awaiting the patch for various
 other character problems.  The resolution and translation
 of substrings and concatenations are so kludged up that
 putting parentheses around them breaks everything.  */
  if (e->ts.type == BT_CHARACTER && e->ref)
return e;

Test case:

subroutine a(c)
  character :: c(*)
  call b((c))
contains
  subroutine b(y)
character :: y(*)
  end subroutine b
end subroutine

Due to the parenthesis, it should print:
"Error: The upper bound in the last dimension must appear in the reference to
the assumed size array"

(Error messages needs patch for PR 34665.)


-- 
   Summary: Parenthesis around character variables: No expression
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/34770] New: Incorrect array indexing through pointer when array does not start at 1

[michalak at ucar dot edu]

Have put together a small test program demonstrating the error, which has to do
with indexing of a pointer when the array it points to starts at an index other
than '1'.  The test program, gfortran behavior, and the correct (ifort)
behavior
of the program is listed below.


[EMAIL PROTECTED] ~]$ cat showbad.F90
PROGRAM showbad
IMPLICIT NONE
INTEGER, TARGET :: x(0:12)
INTEGER, POINTER :: z(:)
INTEGER i
DO i = 0,12
  x(i) = i
ENDDO
z => x
DO i = 0,12
  print*,i,x(i),z(i)
ENDDO
END PROGRAM showbad 
[EMAIL PROTECTED] ~]$ gfortran showbad.F90
[EMAIL PROTECTED] ~]$ a.out
   0   0  56
   1   1  <<<  0 <<< wrong
   2   2   1
   3   3   2
   4   4   3
   5   5   4
   6   6   5
   7   7   6
   8   8   7
   9   9   8
  10  10   9
  11  11  10
  12  12  11
[EMAIL PROTECTED] ~]$ ifort showbad.F90
[EMAIL PROTECTED] ~]$ a.out
   0   0   0
   1   1  <<<  1 <<< correct
   2   2   2
   3   3   3
   4   4   4
   5   5   5
   6   6   6
   7   7   7
   8   8   8
   9   9   9
  10  10  10
  11  11  11
  12  12  12

---
John Michalakes, Software Engineer[EMAIL PROTECTED]
NCAR, MMM Division   voice: +1 303 497 8199
3450 Mitchell Lane fax: +1 303 497 8181
Boulder, Colorado 80301 U.S.A.cell: +1 720 209 2320
http://www.mmm.ucar.edu/individual/michalakes
---


-- 
   Summary: Incorrect array indexing through pointer when array does
not start at 1
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michalak at ucar dot edu


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

[Bug rtl-optimization/26449] [4.2 Regression] ICE in loop invariant motion

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2008-01-13 15:47 
---
This works for me on the branch.  Uros, what is exactly failing?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|WAITING
  Known to fail||4.2.2
   Target Milestone|4.2.0   |4.2.3


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

[Bug target/31786] [4.1/4.2/4.3 Regression][avr] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2008-01-13 15:44 
---
Adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.2.1   |4.1.3


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

[Bug debug/33044] Local static variable in C++ constructor not visible for debugging

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-01-13 15:43 
---
Unclear status of this bug.  Removing target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.0   |---


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

[Bug ada/15610] Invalid program not detected, generic formal parameter hides declared item

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-13 15:42 ---
Non-regression shouldn't have a target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug middle-end/179] gcc -O2 -Wuninitialized missing warning with &var under 2.95.x and 3.x

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-01-13 15:40 
---
Non-regressions should not have a target milestone set.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug c++/28560] [4.1/4.2/4.3 regression] Trouble with __attribute__ in template parameter

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-01-13 15:39 ---
Adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2/4.3 regression]|[4.1/4.2/4.3 regression]
   |Trouble with __attribute__  |Trouble with __attribute__
   |in template parameter   |in template parameter
   Target Milestone|4.0.4   |4.1.3


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

[Bug tree-optimization/34769] New: [4.3 Regression] gcc.dg/vect/no-vfa-pr29145.c

[hjl at lucon dot org]

On Linux/Intel64, with revision 131442, I got

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/no-vfa-pr29145.c  
-ftree-vectorize -fno-vect-cost-model -msse2 -O2 -fdump-tree-vect-details
--param vect-max-version-for-alias-checks=0 -fno-show-column  -lm   -m32 -o
./no-vfa-pr29145.exe(timeout = 300)
PASS: gcc.dg/vect/no-vfa-pr29145.c (test for excess errors)
FAIL: gcc.dg/vect/no-vfa-pr29145.c execution test
FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 0
loops" 2
FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 1
loops" 1

Revision 131403 is OK.


-- 
   Summary: [4.3 Regression]  gcc.dg/vect/no-vfa-pr29145.c
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org


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

[Bug target/26658] [4.1/4.2/4.3 Regression] memcpy/memset are not inlining with -march=athlon-xp and size of 128

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-01-13 15:30 ---
I am closing this bug as INVALID based on the doubious testcase.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|[4.0/4.1/4.2/4.3 Regression]|[4.1/4.2/4.3 Regression]
   |memcpy/memset are not   |memcpy/memset are not
   |inlining with -march=athlon-|inlining with -march=athlon-
   |xp  and size of 128 |xp  and size of 128


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

[Bug libgcj/32967] [4.3 regression] gcjavac throws java exceptions on startup

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-01-13 15:27 ---
There are questions pending.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/34756] [4.3 regression] ICE with broken specialization of variadic template

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-13 15:25 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 15:25:29
   date||
   Target Milestone|--- |4.3.0


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

[Bug c++/34755] [4.3 regression] ICE with invalid argument in variadic template function

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-13 15:24 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 15:24:35
   date||
   Target Milestone|--- |4.3.0


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

[Bug middle-end/34725] [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-13 15:23 ---
Testcase?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-13 15:22 ---
Please provide preprocessed source, as this test pulls in system headers.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug fortran/34556] Rejects valid with bogus error message: parameter initalization

[jvdelisle at verizon dot net]

--- Comment #6 from jvdelisle at verizon dot net  2008-01-13 15:18 ---
Subject: Re:  Rejects valid with bogus error message:
 parameter initalization

pault at gcc dot gnu dot org wrote:
> --- Comment #5 from pault at gcc dot gnu dot org  2008-01-13 08:49 ---
> (In reply to comment #4)
>> This is similar to 34432 is some ways. I think we are not matching the (\ \)
>> correctly.  I don't think gfc_match_expr has the tooling for it yet.
> 
> The error message is spurious in my opinion.  It is left on the stack from a
> failed match. As I say above, the problem is in simplification and,
> specifically, the simplification of reshape.
> 
I agree there is a failed match.  I am reducing the test case until I can get 
this to succeed.  I have managed to ICE a similar test case. Here:

! Rejects-valid. Fails with gfortran 4.1, 4.2 and 4.3
! For 4.3 the error message is:
!
!(/ linem, nplam /) )
! 1
!Error: Invalid character in name at (1)
!
! Found using the Fortran Company Fortran 90 Test Suite (Lite),
! Version 1.4
program splitprms
   integer, parameter  :: nplam = 3 ! # of plans to expand TABs
   integer, parameter  :: linem = 132 ! max. line length
   integer, parameter  :: ncntm = 39 ! max. # cont. lines
   integer, dimension (linem, nplam) :: nxttab
   nxttab  =  &
   reshape ( &
(/ max( (/ (6+3*((i-6+3)/3), i= 1,linem),&
   (6+2*((i-6+2)/2), i= 1,linem) /), &
(/ (6, i= 1, 2*linem) /)),   &
   (/  (i, i= 1,linem) /) /),&
 (/ linem, nplam /) )
   print *, nxttab
end program splitprms

]$ gfc pr34556.f90
pr34556.f90: In function ‘splitprms’:
pr34556.f90:10: internal compiler error: Intrinsic function (164)


-- 


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

Re: [Bug fortran/34556] Rejects valid with bogus error message: parameter initalization

[Jerry DeLisle]

pault at gcc dot gnu dot org wrote:

--- Comment #5 from pault at gcc dot gnu dot org  2008-01-13 08:49 ---
(In reply to comment #4)

This is similar to 34432 is some ways. I think we are not matching the (\ \)
correctly.  I don't think gfc_match_expr has the tooling for it yet.


The error message is spurious in my opinion.  It is left on the stack from a
failed match. As I say above, the problem is in simplification and,
specifically, the simplification of reshape.

I agree there is a failed match.  I am reducing the test case until I can get 
this to succeed.  I have managed to ICE a similar test case. Here:


! Rejects-valid. Fails with gfortran 4.1, 4.2 and 4.3
! For 4.3 the error message is:
!
!(/ linem, nplam /) )
! 1
!Error: Invalid character in name at (1)
!
! Found using the Fortran Company Fortran 90 Test Suite (Lite),
! Version 1.4
program splitprms
  integer, parameter  :: nplam = 3 ! # of plans to expand TABs
  integer, parameter  :: linem = 132 ! max. line length
  integer, parameter  :: ncntm = 39 ! max. # cont. lines
  integer, dimension (linem, nplam) :: nxttab
  nxttab  =  &
  reshape ( &
   (/ max( (/ (6+3*((i-6+3)/3), i= 1,linem),&
  (6+2*((i-6+2)/2), i= 1,linem) /), &
   (/ (6, i= 1, 2*linem) /)),   &
  (/  (i, i= 1,linem) /) /),&
(/ linem, nplam /) )
  print *, nxttab
end program splitprms

]$ gfc pr34556.f90
pr34556.f90: In function ‘splitprms’:
pr34556.f90:10: internal compiler error: Intrinsic function (164)

[Bug c/34601] [4.3 regression] ICE with undefined enum

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-01-13 15:15 ---
This was caused by

+2007-12-19  Richard Sandiford  <[EMAIL PROTECTED]>
+
+   * rtl.def (SUBREG): Update comments.
...
+   (set_reg_attrs_for_decl_rtl): New function, split out from
+   set_decl_incoming_rtl.  Set the offset of plain REGs to the
+   offset of the REG's mode from the decl's.  Assert that all
+   subregs are lowparts and handle their inner registers in the
+   same way as plain REGs.
+   (set_decl_rtl, set_incoming_decl_rtl): Use reg_attrs_for_decl_rtl.
...

and can be fixed by

Index: emit-rtl.c
===
--- emit-rtl.c  (revision 131502)
+++ emit-rtl.c  (working copy)
@@ -1006,7 +1006,7 @@ set_reg_attrs_for_decl_rtl (tree t, rtx 
   if (REG_P (x))
 REG_ATTRS (x)
   = get_reg_attrs (t, byte_lowpart_offset (GET_MODE (x),
-  TYPE_MODE (TREE_TYPE (t;
+  DECL_MODE (t)));
   if (GET_CODE (x) == CONCAT)
 {
   if (REG_P (XEXP (x, 0)))


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-13 15:11:41 |2008-01-13 15:15:22
   date||


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

[Bug c/34601] [4.3 regression] ICE with undefined enum

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-01-13 15:11 ---
Confirmed.  We leak

(gdb) call debug_tree (t)
 
used unsigned SI file t.i line 3 col 10
align 32 context 
(reg:SI 58)>

to

#2  0x08218782 in set_reg_attrs_for_decl_rtl (t=0xb7cb2108, x=0xb7caee60)
at /home/richard/src/trunk/gcc/emit-rtl.c:1009
1006  if (REG_P (x))
1007REG_ATTRS (x)
1008  = get_reg_attrs (t, byte_lowpart_offset (GET_MODE (x),
1009   TYPE_MODE (TREE_TYPE
(t;

because we end up expanding stuff even though errorcount is 1.  Supposedly
we need to do this, but the special routine expand_one_error_var should
be more careful here.

#1  0x0872766d in tree_class_check_failed (node=0xb7ccb3f0, cl=tcc_type, 
file=0x8a7d4d4 "/home/richard/src/trunk/gcc/emit-rtl.c", line=1009, 
function=0x8a7d560 "set_reg_attrs_for_decl_rtl")
at /home/richard/src/trunk/gcc/tree.c:6863
#2  0x08218782 in set_reg_attrs_for_decl_rtl (t=0xb7cd5108, x=0xb7cd1e60)
at /home/richard/src/trunk/gcc/emit-rtl.c:1009
#3  0x08218978 in set_decl_rtl (t=0xb7cd5108, x=0xb7cd1e60)
at /home/richard/src/trunk/gcc/emit-rtl.c:1045
#4  0x089692bc in expand_one_error_var (var=0xb7cd5108)
at /home/richard/src/trunk/gcc/cfgexpand.c:702


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to work||4.2.3
   Last reconfirmed|-00-00 00:00:00 |2008-01-13 15:11:41
   date||


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

[Bug libgcj/33263] [4.3 regression] libjava testsuite failures on alpha-linux

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-13 14:58 ---
How is the status now?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2008-01-13 14:56 
---
Closing as fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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