[Bug target/48126] arm_output_sync_loop: misplaced memory barrier

[jye2 at gcc dot gnu.org]

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

--- Comment #12 from jye2 at gcc dot gnu.org 2012-06-08 06:58:32 UTC ---
Author: jye2
Date: Fri Jun  8 06:58:25 2012
New Revision: 188327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188327
Log:
Backport mainline r179607, r179979, r179980, r181416, r182014
2012-06-08  Joey Ye  

Backport r182014 from mainline.
2011-12-05  Kazu Hirata  

PR target/51408
* config/arm/arm.md (*minmax_arithsi): Always require the else
clause in the MINUS case.

Backport r181416 from mainline.
2011-11-16  Richard Earnshaw  
Bernd Schmidt 
Sebastian Huber 

PR target/49641
* config/arm/arm.c (store_multiple_sequence): Avoid cases where
the base reg is stored iff compiling for Thumb1.

Backport r179980 from mainline.
2011-10-14  David Alan Gilbert  

PR target/48126
* config/arm/arm.c (arm_output_sync_loop): Move label before barrier.

Backport r179979 from mainline.
2011-10-14  David Alan Gilbert  

* config/arm/arm.h (TARGET_HAVE_DMB_MCR): MCR Not available in Thumb1.

Backport r179607 from mainline.
2011-10-06  Bernd Schmidt  

PR target/49049
* config/arm/arm.md (arm_subsi3_insn): Lose the last alternative.

Testsuites:
Backport r182014 from mainline
2011-12-05  Kazu Hirata  

PR target/51408
* gcc.dg/pr51408.c: New.

Backport r181416 from mainline
2011-11-16  Richard Earnshaw  
Bernd Schmidt 
Sebastian Huber 

PR target/49641
* gcc.target/arm/pr49641.c: New test.

Backport r179607 from mainline
2011-10-06  Bernd Schmidt  

PR target/49049
* gcc.c-torture/compile/pr49049.c: New test.


Added:
   
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr49049.c
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/pr51408.c
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.target/arm/pr49641.c
Modified:
branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.h
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.md
branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm

[Bug target/51408] Miscompilation in arm.md:*minmax_arithsi

[jye2 at gcc dot gnu.org]

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

--- Comment #6 from jye2 at gcc dot gnu.org 2012-06-08 06:58:32 UTC ---
Author: jye2
Date: Fri Jun  8 06:58:25 2012
New Revision: 188327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188327
Log:
Backport mainline r179607, r179979, r179980, r181416, r182014
2012-06-08  Joey Ye  

Backport r182014 from mainline.
2011-12-05  Kazu Hirata  

PR target/51408
* config/arm/arm.md (*minmax_arithsi): Always require the else
clause in the MINUS case.

Backport r181416 from mainline.
2011-11-16  Richard Earnshaw  
Bernd Schmidt 
Sebastian Huber 

PR target/49641
* config/arm/arm.c (store_multiple_sequence): Avoid cases where
the base reg is stored iff compiling for Thumb1.

Backport r179980 from mainline.
2011-10-14  David Alan Gilbert  

PR target/48126
* config/arm/arm.c (arm_output_sync_loop): Move label before barrier.

Backport r179979 from mainline.
2011-10-14  David Alan Gilbert  

* config/arm/arm.h (TARGET_HAVE_DMB_MCR): MCR Not available in Thumb1.

Backport r179607 from mainline.
2011-10-06  Bernd Schmidt  

PR target/49049
* config/arm/arm.md (arm_subsi3_insn): Lose the last alternative.

Testsuites:
Backport r182014 from mainline
2011-12-05  Kazu Hirata  

PR target/51408
* gcc.dg/pr51408.c: New.

Backport r181416 from mainline
2011-11-16  Richard Earnshaw  
Bernd Schmidt 
Sebastian Huber 

PR target/49641
* gcc.target/arm/pr49641.c: New test.

Backport r179607 from mainline
2011-10-06  Bernd Schmidt  

PR target/49049
* gcc.c-torture/compile/pr49049.c: New test.


Added:
   
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr49049.c
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.dg/pr51408.c
branches/ARM/embedded-4_6-branch/gcc/testsuite/gcc.target/arm/pr49641.c
Modified:
branches/ARM/embedded-4_6-branch/gcc/ChangeLog.arm
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.c
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.h
branches/ARM/embedded-4_6-branch/gcc/config/arm/arm.md
branches/ARM/embedded-4_6-branch/gcc/testsuite/ChangeLog.arm

[Bug c++/53599] [4.7/4.8 Regression] gcc-4.7.1_rc20120606 segfaults compiling boost.karma

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-06-08 
06:43:51 UTC ---
Yeah, I agree with that.

[Bug web/53608] New: Documentation could be clearer about designated initializers of unions

[alan.coopersmith at oracle dot com]

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

 Bug #: 53608
   Summary: Documentation could be clearer about designated
initializers of unions
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alan.coopersm...@oracle.com


http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html currently says:

   If the same field is initialized multiple times, it will have value 
   from the last initialization.

(Which should probably say "the value" instead.)

Currently gcc applies this to multiple components of a union type as well.
(At least with gcc 3.4 through 4.5 here.)

For instance, this program:

#include 

int main(int argc, char **argv) {
union {
struct { int i; char c[4]; } a; 
struct { int i; short s[2]; } b;
} u = { .a.i = 1, .b.s[0] = 2, .b.s[1] = 3 };

printf("%d %d %d\n", u.a.i, u.b.s[0], u.b.s[1]);
}

will print "0 2 3" when compiled with gcc, since gcc appears to treat
this as two initializations of the "same field" (fields mapped to the
same spot in memory):

 u.a = { 1 };
 u.b = { 0, 2, 3};

and discards the first.(By comparison, the Solaris Studio compiler
prints "1 2 3" for this code.)

If the current behavior of gcc is considered correct, then it would be helpful 
to update the documentation to say something like:

   If the same field is initialized multiple times, or overlapping members
   of the same union are initialized, the value from the last initialization
   will be used.

   When union members are structures, the entire structure from the last
   member initialized is used.   For example:

union {
struct { int i; char c[4]; } a; 
struct { int i; short s[2]; } b;
} u = { .a.i = 1, .b.s[0] = 2, .b.s[1] = 3 };

   is equivalent to:

   union {
struct { int i; char c[4]; } a; 
struct { int i; short s[2]; } b;
} u = { .a = { 1 }, .b = { 0, 2, 3 } };

   which is in turn equivalent to:

   union {
struct { int i; char c[4]; } a; 
struct { int i; short s[2]; } b;
} u = { .b = { 0, 2, 3 } };

[Bug bootstrap/53607] New: opt-functions.awk --> "awk: There is a regular expression error."

[skunk at iskunk dot org]

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

 Bug #: 53607
   Summary: opt-functions.awk --> "awk: There is a regular
expression error."
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: hppa2.0w-hp-hpux11.00
Target: hppa2.0w-hp-hpux11.00
 Build: hppa2.0w-hp-hpux11.00


Created attachment 27583
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27583
Proposed fix

Bootstrapping 4.7.0 on an HP-UX 11.00 system fails with

[...]
echo timestamp > s-options
awk -f /home/src/gcc-4.7.0/gcc/opt-functions.awk -f /tg/freepor
t/src/gcc/gcc--4.7.0-tera/gcc/opt-read.awk \
   -f /home/src/gcc-4.7.0/gcc/opth-gen.awk \
   < optionlist > tmp-options.h
awk: There is a regular expression error.
?, *, or + not preceded by valid regular expression
 The source line number is 90.
 The error context is
if (flags ~ >>>  "^{") <<< 
gmake[3]: *** [s-options-h] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


The fix for this is fairly trivial; patch against SVN is attached.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||hstong at ca dot ibm.com

--- Comment #14 from Paolo Carlini  2012-06-08 
00:47:47 UTC ---
*** Bug 53606 has been marked as a duplicate of this bug. ***

[Bug c++/53606] Invalid candidate chosen; warning message claims to know better than the Standard

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Paolo Carlini  2012-06-08 
00:47:47 UTC ---
Ah, I fixed it ;)

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

[Bug c++/53606] Invalid candidate chosen; warning message claims to know better than the Standard

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-06-08 
00:30:14 UTC ---
This is a GNU extension, if you use -pedantic to disable it then 4.6 and 4.7
compile the code without a diagnostic.

[Bug c++/53606] Invalid candidate chosen; warning message claims to know better than the Standard

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2012-06-07 
22:49:52 UTC ---
Mainline seems fine, anyway.

[Bug c++/53606] New: Invalid candidate chosen; warning message claims to know better than the Standard

[hstong at ca dot ibm.com]

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

 Bug #: 53606
   Summary: Invalid candidate chosen; warning message claims to
know better than the Standard
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu


GCC emits a warning stating that the template-dependent call in the type of
a parameter of a function template instantiation is ambiguous according to the
Standard.

It then fails to remove the candidate despite what should then be substitution
failure.

I am not quite sure how GCC found one of the operator+ overloads to be better
than the other, but whatever mechanism is being used, it should not interfere
with the translation of a well-formed program.


### Self-contained source (op_overload_sfinae.cpp):> cat op_overload_sfinae.cpp
template 
struct false_ { enum : bool { value = false }; };

struct A {
template 
int operator +(const T &) const;
};

template 
int operator +(const A &, const T &);

const int &lv_const_int();

template 
T &lv_T();

template 
void foo(void *, char * = 0) { }

template 
void foo(int, char (*)[sizeof (lv_T() + lv_const_int(), 0)] = 0) {
   static_assert(false_::value,
"If the warning is correct, then the Standard says I should not see this.");
}

int main() {
   foo(0);
}


### Compiler invocation:
g++-4.7.0 -c op_overload_sfinae.cpp -std=c++11


### Compiler output:
op_overload_sfinae.cpp: In instantiation of 'void foo(int, char (*)[sizeof
(((lv_T() + lv_const_int()), 0))]) [with T = A]':
op_overload_sfinae.cpp:27:12:   required from here
op_overload_sfinae.cpp:21:66: warning: ISO C++ says that these are ambiguous,
even though the worst conversion for the first is better than the worst
conversion for the second: [enabled by default]
op_overload_sfinae.cpp:10:5: note: candidate 1: int operator+(const A&, const
T&) [with T = int]
op_overload_sfinae.cpp:6:5: note: candidate 2: int A::operator+(const T&) const
[with T = int]
op_overload_sfinae.cpp:22:4: error: static assertion failed: If the warning is
correct, then the Standard says I should not see this.


### g++ -v output:> g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.7.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc
--program-suffix=-4.7.0 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --

enable-shared --enable-__cxa_atexit --enable-threads=posix
--enable-languages=c,c++,fortran --with-mpfr=/usr/local/ --with-mpc=/usr/local/
--with-gmp=/usr/local/
Thread model: posix
gcc version 4.7.0 (GCC)

[Bug bootstrap/52850] Linker path ends up using wrong zlib

[skunk at iskunk dot org]

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

--- Comment #3 from Daniel Richard G.  2012-06-07 
21:59:39 UTC ---
Created attachment 27582
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27582
Proposed fix

Since the in-tree zlib is always built as a static archive, we can link it in
with an explicit path rather than -lz (and still use the latter when using the
system zlib). How does this look?

[Bug c++/53602] [4.7/4.8 Regression] Libre Office causes an internal compiler error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
Version|unknown |4.7.0
   Target Milestone|--- |4.7.1
Summary|Libre Office causes an  |[4.7/4.8 Regression] Libre
   |internal compiler error |Office causes an internal
   ||compiler error

--- Comment #6 from Jakub Jelinek  2012-06-07 
21:53:25 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186018

[Bug c++/53602] Libre Office causes an internal compiler error

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-06-07 
21:40:25 UTC ---
Created attachment 27581
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27581
pr53602.ii

Slightly reduced testcase for -m32 -Os -std=c++11.

[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended

[hstong at ca dot ibm.com]

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

Hubert Tong  changed:

   What|Removed |Added

   Keywords|rejects-valid   |wrong-code
Version|4.6.0   |4.7.0
Summary|[C++11] Reference fails to  |[C++11] Lifetime of
   |bind directly to prvalue|temporary object backing
   |member access expression|pointer-to-member
   ||expression not extended
  Known to fail|4.4.0, 4.5.0, 4.6.0 |4.7.0

--- Comment #2 from Hubert Tong  2012-06-07 21:36:54 
UTC ---
(In reply to comment #1)
> It compiles fine with 4.7 or trunk.
> 
> I think this is a dup of an existing bug Jason fixed, possibly one he reported
> himself, about elements of rvalue arrays.

Confirmed that the above works as expected under 4.7.

However, replacing:
const B &b = A(1).b;

with:
const B &b = A(1).*(&A::b);

produces an executable whose output indicates that the lifetime of the
temporary is not being extended:

ctor B(int) body:   (this=0xffe9f7d8,_data=1)
ctor A(int) body:   (this=0xffe9f7d8,_data=1)
dtor for A: (this=0xffe9f7d8,_data=1)
dtor for B: (this=0xffe9f7d8,_data=1)
main() user body begins
main() user body ends

### g++ -v output:> g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.7.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc
--program-suffix=-4.7.0 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --enable-shared --enable-__cxa_atexit
--enable-threads=posix --enable-languages=c,c++,fortran --with-mpfr=/usr/local/
--with-mpc=/usr/local/ --with-gmp=/usr/local/
Thread model: posix
gcc version 4.7.0 (GCC)

[Bug middle-end/53535] non-aligned memset on non-strict-alignment targets not optimized where aligned memset is

[hp at gcc dot gnu.org]

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

--- Comment #6 from Hans-Peter Nilsson  2012-06-07 
20:44:06 UTC ---
Author: hp
Date: Thu Jun  7 20:44:01 2012
New Revision: 188317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188317
Log:
PR middle-end/53535
* gcc.dg/pr46647.c: xfail for cris-* and crisv32-*.

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

[Bug c++/53605] [4.7/4.8 Regression] Compiler ICEs in size_binop_loc

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-07
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.7.2
Summary|Compiler ICEs in|[4.7/4.8 Regression]
   |size_binop_loc  |Compiler ICEs in
   ||size_binop_loc
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2012-06-07 20:10:20 
UTC ---
It is caused by revision 172261:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00456.html

[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[4.7/4.8 Regression]|[4.7 Regression] [C++11]
   |[C++11] name lookup issue   |name lookup issue with
   |with c++11 enums|c++11 enums

--- Comment #4 from Jason Merrill  2012-06-07 
19:53:40 UTC ---
Fixed on trunk.

[Bug other/53601] g++ ICE compiling minion with -Ofast

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-06-07 
17:35:37 UTC ---
20120430 is very old snapshot, always try latest svn from the corresponding
branch.  This bug seems to have been fixed in between r187100 and r187200.

[Bug c++/53605] New: Compiler ICEs in size_binop_loc

[xinliangli at gmail dot com]

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

 Bug #: 53605
   Summary: Compiler ICEs in size_binop_loc
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


Compile the small program with gcc (trunk or 4-7 compiler), the compiler will
ICE.


template 
class EqHelper {
 public:
  template 
  static int  Compare( const T1& expected,
 const T2& actual);
};
void foo(){
  static const int kData[] = {};
 ::EqHelper::Compare(kData, "abc");
}

This is a regression from gcc4_6.

David

[Bug lto/53604] ld reports errors using lto after upgrading from gcc-4.6.2 to gcc-4.7.0

[paul.scruby at ghco dot co.uk]

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

--- Comment #2 from Paul Scruby  2012-06-07 
17:14:13 UTC ---
The 4.7.0 code is different so the patch didn't work:
  'struct varpool_node' has no member named 'symbol'

I'm not familiar with the gcc internals so I'm not sure what I need to add to
4.7.0 to fix this?

If this is the function in question, what do I need to add to fix this problem?

static inline bool
varpool_can_remove_if_no_refs (struct varpool_node *node)
{
  return (!node->force_output && !node->used_from_other_partition
  && (flag_toplevel_reorder || DECL_COMDAT (node->decl)
  || DECL_ARTIFICIAL (node->decl))
&& (DECL_COMDAT (node->decl) || !node->externally_visible));
}

Thanks,

Paul

[Bug fortran/52552] [OOP] ICE when trying to allocate non-allocatable object giving a dynamic type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||janus at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from janus at gcc dot gnu.org 2012-06-07 16:25:57 UTC ---
I think one can avoid the whole problem by reshuffling the order of checks
being done in 'gfc_match_allocate', like this:

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c(revision 188139)
+++ gcc/fortran/match.c(working copy)
@@ -3533,6 +3533,28 @@ gfc_match_allocate (void)
 }
 }

+  /* FIXME: disable the checking on derived types and arrays.  */
+  sym = tail->expr->symtree->n.sym;
+  b1 = !(tail->expr->ref
+   && (tail->expr->ref->type == REF_COMPONENT
+|| tail->expr->ref->type == REF_ARRAY));
+  if (sym && sym->ts.type == BT_CLASS && sym->attr.class_ok)
+b2 = !(CLASS_DATA (sym)->attr.allocatable
+   || CLASS_DATA (sym)->attr.class_pointer);
+  else
+b2 = sym && !(sym->attr.allocatable || sym->attr.pointer
+  || sym->attr.proc_pointer);
+  b3 = sym && sym->ns && sym->ns->proc_name
+   && (sym->ns->proc_name->attr.allocatable
+|| sym->ns->proc_name->attr.pointer
+|| sym->ns->proc_name->attr.proc_pointer);
+  if (b1 && b2 && !b3)
+{
+  gfc_error ("Allocate-object at %L is neither a nonprocedure pointer "
+ "nor an allocatable variable", &tail->expr->where);
+  goto cleanup;
+}
+
   /* The ALLOCATE statement had an optional typespec.  Check the
  constraints.  */
   if (ts.type != BT_UNKNOWN)
@@ -3558,28 +3580,6 @@ gfc_match_allocate (void)
   if (tail->expr->ts.type == BT_DERIVED)
 tail->expr->ts.u.derived = gfc_use_derived (tail->expr->ts.u.derived);

-  /* FIXME: disable the checking on derived types and arrays.  */
-  sym = tail->expr->symtree->n.sym;
-  b1 = !(tail->expr->ref
-   && (tail->expr->ref->type == REF_COMPONENT
-|| tail->expr->ref->type == REF_ARRAY));
-  if (sym && sym->ts.type == BT_CLASS && sym->attr.class_ok)
-b2 = !(CLASS_DATA (sym)->attr.allocatable
-   || CLASS_DATA (sym)->attr.class_pointer);
-  else
-b2 = sym && !(sym->attr.allocatable || sym->attr.pointer
-  || sym->attr.proc_pointer);
-  b3 = sym && sym->ns && sym->ns->proc_name
-   && (sym->ns->proc_name->attr.allocatable
-|| sym->ns->proc_name->attr.pointer
-|| sym->ns->proc_name->attr.proc_pointer);
-  if (b1 && b2 && !b3)
-{
-  gfc_error ("Allocate-object at %L is neither a nonprocedure pointer "
- "nor an allocatable variable", &tail->expr->where);
-  goto cleanup;
-}
-
   if (gfc_peek_ascii_char () == '(' && !sym->attr.dimension)
 {
   gfc_error ("Shape specification for allocatable scalar at %C");


This patch avoids the segfault and correctly rejects the test case. I hope it
does not introduce any other problems (I'll try it on the testsuite soon).

[Bug c++/53602] Libre Office causes an internal compiler error

[andy at benton dot eu.com]

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

--- Comment #4 from Andrew Benton  2012-06-07 
16:12:00 UTC ---
Created attachment 27580
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27580
skeletoncommon.ii preprocessor output compressed

(In reply to comment #3)
> Remember that you can always compress it.

Doh!

[Bug libfortran/52537] slow trim function

[talebi.hossein at gmail dot com]

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

--- Comment #9 from Hossein Talebi  2012-06-07 
16:03:09 UTC ---
I think I found where the problem is. It is not with the trim(). It is mostly
with read (st_input_all(j),*,IOSTAT=ios) I50(1:50).

I attach a self contained program. With intel it takes 11sec but for gfortran
takes 40sec. The input file is 404MB.



program fileread

integer :: linenum
integer  :: j,ferror, ios,i
character (len=200) :: st_input
character (len=200) :: st_input_all(5373122)
integer :: funit2
integer :: I50(0:50)
integer   G_elid, nn !, pEidf, pEconnf,pEmatidf
integer, allocatable :: element_tab(:), Elements(:,:)

linenum=0; ferror=0;
open (funit2, file = "/data/msh/bigmesh.elements", access =
'sequential',iostat=ferror)

if (ferror/=0) then
STOP "error reading the file"
endif

print *, "reading the file..."

G_elid=0
do j=1,5373122
read (funit2,"(A200)",iostat=ferror) st_input_all(j)
if (G_elid== 5373121 ) then
print *,  st_input_all(j)
endif
enddo

G_elid=0
do j=1,5373122
G_elid=G_elid+1
read (st_input_all(j),*,IOSTAT=ios) I50(1:50)
if (G_elid== 5373121 ) then
print *,  I50
endif
enddo

close(funit2)
print *, I50
STOP "permix I am stopped"

end program fileread

[Bug lto/53604] ld reports errors using lto after upgrading from gcc-4.6.2 to gcc-4.7.0

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-06-07 15:50:56 
UTC ---
I think it is a dup for PR 53572.  Can you try patch at

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572#c3

[Bug c++/53599] [4.7/4.8 Regression] gcc-4.7.1_rc20120606 segfaults compiling boost.karma

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2012-06-07 
15:49:38 UTC ---
I think for 4.7.1 let's just revert that patch.

[Bug c++/53602] Libre Office causes an internal compiler error

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-06-07 
15:45:19 UTC ---
Remember that you can always compress it.

[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|FIXED   |

[Bug c++/53602] Libre Office causes an internal compiler error

[andy at benton dot eu.com]

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

--- Comment #2 from Andrew Benton  2012-06-07 
15:26:13 UTC ---
Genius idea! Unfortunately the preprocessor output skeletoncommon.ii is more
than 2MB and so I can't attach it to this bug. I've put it here
http://benton.eu.com/skeletoncommon.ii
The command that produced it was:

andy@router:~$ cd
/home/andy/libreoffice-core-3.5.4.2/unodevtools/source/skeletonmaker
andy@router:~/libreoffice-core-3.5.4.2/unodevtools/source/skeletonmaker$ g++ -v
-save-temps -fmessage-length=0 -c -Os -I.
-I../../unxlngi6.pro/inc/uno-skeletonmaker -I../inc -I../../inc -I../../unx/inc
-I../../unxlngi6.pro/inc -I.
-I/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/stl
-I/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/external
-I/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc
-I/home/andy/libreoffice-core-3.5.4.2/solenv/inc/unxlngi6
-I/home/andy/libreoffice-core-3.5.4.2/solenv/inc
-I/home/andy/libreoffice-core-3.5.4.2/res
-I/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/udkapi
-I/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/offapi
-I/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/oovbaapi -I.
-I../../res -I. -pipe -mtune=pentiumpro -fvisibility-inlines-hidden -std=c++0x
-Wno-deprecated-declarations -Wall -Wextra -Wendif-labels -Wshadow
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -DLINUX -DUNX -DVCL -DGCC -DINTEL
-DGLIBC=2 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1
-DHAVE_GCC_VISIBILITY_FEATURE -DX86 -D__DMAKE -DUNIX -DCPPU_ENV=gcc3
-DGXX_INCLUDE_PATH=/usr/include/c++/4.7.1 -DSUPD=350 -DPRODUCT -DNDEBUG
-DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DGSTREAMER -DHAVE_THREADSAFE_STATICS
-fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o
../../unxlngi6.pro/obj/skeletoncommon.o
/home/andy/libreoffice-core-3.5.4.2/unodevtools/source/skeletonmaker/skeletoncommon.cxx
g++: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=g++
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7-30-05-12/configure --prefix=/usr --enable-shared
--enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit
--enable-cloog-backend=isl --enable-clocale=gnu --disable-multilib
--disable-bootstrap --disable-static --with-system-zlib
Thread model: posix
gcc version 4.7.1 20120530 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fmessage-length=0' '-c' '-Os' '-I' '.'
'-I' '../../unxlngi6.pro/inc/uno-skeletonmaker' '-I' '../inc' '-I' '../../inc'
'-I' '../../unx/inc' '-I' '../../unxlngi6.pro/inc' '-I' '.' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/stl' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/external' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solenv/inc/unxlngi6' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solenv/inc' '-I'
'/home/andy/libreoffice-core-3.5.4.2/res' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/udkapi' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/offapi' '-I'
'/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/oovbaapi' '-I' '.'
'-I' '../../res' '-I' '.' '-pipe' '-mtune=pentiumpro'
'-fvisibility-inlines-hidden' '-std=c++11' '-Wno-deprecated-declarations'
'-Wall' '-Wextra' '-Wendif-labels' '-Wshadow' '-Wno-ctor-dtor-privacy'
'-Wno-non-virtual-dtor' '-D' 'LINUX' '-D' 'UNX' '-D' 'VCL' '-D' 'GCC' '-D'
'INTEL' '-D' 'GLIBC=2' '-D' '_PTHREADS' '-D' '_REENTRANT' '-D' 'NEW_SOLAR' '-D'
'_USE_NAMESPACE=1' '-D' 'HAVE_GCC_VISIBILITY_FEATURE' '-D' 'X86' '-D' '__DMAKE'
'-D' 'UNIX' '-D' 'CPPU_ENV=gcc3' '-D' 'GXX_INCLUDE_PATH=/usr/include/c++/4.7.1'
'-D' 'SUPD=350' '-D' 'PRODUCT' '-D' 'NDEBUG' '-D' 'OSL_DEBUG_LEVEL=0' '-D'
'OPTIMIZE' '-D' 'GSTREAMER' '-D' 'HAVE_THREADSAFE_STATICS' '-fexceptions'
'-fno-enforce-eh-specs' '-D' 'EXCEPTIONS_ON' '-o'
'../../unxlngi6.pro/obj/skeletoncommon.o' '-shared-libgcc' '-march=pentiumpro'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.7.1/cc1plus -E -quiet -v -I . -I
../../unxlngi6.pro/inc/uno-skeletonmaker -I ../inc -I ../../inc -I
../../unx/inc -I ../../unxlngi6.pro/inc -I . -I
/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/stl -I
/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/external -I
/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc -I
/home/andy/libreoffice-core-3.5.4.2/solenv/inc/unxlngi6 -I
/home/andy/libreoffice-core-3.5.4.2/solenv/inc -I
/home/andy/libreoffice-core-3.5.4.2/res -I
/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/udkapi -I
/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/offapi -I
/home/andy/libreoffice-core-3.5.4.2/solver/unxlngi6.pro/inc/oovbaapi -I . -I
../../res -I . -D_GNU_SOURCE -D LINUX -D UNX -D VCL -D GCC -D INTEL -D GLIBC=2
-D _PTHREADS -D _REENTRANT -D NEW_SOLAR -D _USE_NAMESPACE=1 -D
HAVE_GCC_VISIBILITY_FEATURE -D X86 -D __DMAKE -D UNIX -D CPPU_ENV=gcc3 -D
GXX_INCLUDE_PATH=/usr/include/c++/4.7.1 -D SUPD=350 -

[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2012-06-07 
15:25:37 UTC ---
Created attachment 27579
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27579
Proof-of-concept patch (works but has many regression-test failures)

(In reply to comment #5)
> Fixed on trunk, closing.

Well, not completely - only for the special case. I think there is more room
for improvement: Hoisting the memset out of the loop and using ARRAY_RANGE_REF
for the assignments.

 * * *

The attach patch contains a proof-of-concept implementation of ARRAY_RANGE_REF.

The problem is that one needs to strip off several operations on the LHS/RHS in
order to use ARRAY_RANGE_REF. For instance, for a literal, one gets *&"abcd"[1]
but the bare "abcd" is needed (note the ARRAY_REF "[1]"); but one needs to have
just the literal "abcd". For "var(2:0)" one not only needs to strip off the
ARRAY_REF, but one also needs to obtain the offset. While for "string(1)(:)"
and "string(1)(2:3)" the ARRAY_REF for the array has to be kept, but not for
the string part (except for the lower bound). The current version is rather
hacky :-(

Additionally, one runs into the problem that a pointer to a "char" and a
pointer to a "char[:]" aren't the same; many temporary vars have the wrong kind
of "char" type.

While the code works rather nicely for various small test cases, there are many
test-suite failures with the patch. The problem is simply that removing the
(sub)string ARRAY_REF while keeping the array ARRAY_REF is difficult. Fixing
the arguments to gfc_trans_string_copy is also not that simple.

Example for a failing test case:
  character(len=4, kind=1),pointer :: str(:)
  allocate(str(1))
  str(1) = 1_"abcd" ! Fails
  str(1)(2:) = 1_"abcd" ! Works

[Bug lto/53604] New: ld reports errors using lto after upgrading from gcc-4.6.2 to gcc-4.7.0

[paul.scruby at ghco dot co.uk]

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

 Bug #: 53604
   Summary: ld reports errors using lto after upgrading from
gcc-4.6.2 to gcc-4.7.0
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paul.scr...@ghco.co.uk


I recently tried to upgrade from gcc-4.6.2 to gcc-4.7.0.  I have been using the
lto with gcc-4.6.2 and binutils-2.22 for a while with no problems.

However, since I upgraded to gcc-4.7.0 ld is getting "hidden symbol isn't
defined" errors, something like this when I try to link with my static
libraries and a boost shared object:

  $  /opt/gcc-4.7.0/bin/g++ -o /home/pauls/repos/build/bin/my_app
-static-libstdc++ -m64 -march=corei7 -Wl,-rpath,/opt/boost-1.44/lib
-L/opt/boost-1.44/lib -flto -O3 -fuse-linker-plugin
-L/home/pauls/repos/build/lib /home/pauls/repos/build/obj/my_app.o -lmy_lib
-lboost_regex -ldl -lrt
 
`_ZThn16_N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEED1Ev'
referenced in section `.data.rel.ro' of /tmp/cc0n7i0I.ltrans12.ltrans.o:
defined in discarded section
`.gnu.linkonce.t._ZN5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEED5Ev'
of /home/pauls/repos/build/obj/my_app.o (symbol from plugin)
 
/opt/gcc-4.7.0/lib/gcc/x86_64-fedora-linux/4.7.0/../../../../x86_64-fedora-linux/bin/ld:
/home/pauls/repos/build/bin/my_app: hidden symbol `.LTHUNK11.6239' isn't
defined

binutils 2.22 was pre-installed into:
  $ /opt/gcc-4.7.0

gcc4.7.0 was build with:
  $ export PATH=/opt/gcc-4.7.0/bin/:$PATH
  $ ../configure --prefix=/opt/gcc-4.7.0 --build=x86_64-fedora-linux
--with-system-zlib --enable-plugin --enable-bootstrap --enable-shared
--enable-threads=posix --enable-languages=c,c++ --disable-checking
--disable-libunwind-exceptions

I tried upgrading to binutils-2.22.52 to see if was an issue with ld that had
recently been patched, but I got the same error.  

I also tried upgrading from boost-1.44 to boost-1.49 to see if it was an issue
with boost exception code, but I also got the same error.

Thanks,

Paul

[Bug fortran/48543] Collapse identical strings

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  2012-06-07 
14:58:38 UTC ---
I'll do a bit of work on that, because it can also be useful
for reducing memcpy/memset pairs.

Consider

  character(len=3) :: a
  character(len=4) :: b
  a = 'a'
  b = 'a'

This could be changed into (in a first pass)

  a = 'a   '
  b = 'a'

for a simple assignment, but this would mean duplicate strings.
Better to change this into

  a = 'a'
  b = 'a'

[Bug c/53603] abs() doesn't warn if argument is double, not even with -Wall -Wextra

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-06-07 
14:56:25 UTC ---
(In reply to comment #3)
> 1. It seems a bit strange to me that there are warnings that are not enabled 
> by 
> -Wall -Wextra. The man page lists so many different types of warning: perhaps
> it would be useful to mention (under -Wextra) which ones it does *not* enable?

Such a list would almost certainly get out of date when warning options are
added (there are already several places that need to be updated for a new
warning) and if it's not complete it's not very useful.  However, if you want
to compile the list and propose a doc patch please send it to
gcc-patc...@gcc.gnu.org

> Or maybe it would be worthwhile adding something like "-Wkitchensink" to mean:
> yes, really do turn on all the warnings (except maybe for pedantic). 

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

[Bug other/53601] g++ ICE compiling minion with -Ofast

[nagajyothi.eggone at amd dot com]

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

--- Comment #3 from NagaJyothi Eggone  
2012-06-07 14:55:34 UTC ---
Created attachment 27578
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27578
bzip2 compressed pre-processed file

[Bug tree-optimization/51938] missed optimization: 2 comparisons

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization

--- Comment #4 from Marc Glisse  2012-06-07 
14:54:02 UTC ---
Changing to tree-optimization (doing the optimization at RTL level would
require finite-math-only).

There is plenty of code that corresponds to A&&B and A||B, but (almost) nothing
for A&&!B. Quite a big missing piece...

:
  if (x_2(D) > 0.0)
goto ;
  else
goto ;

:
  if (x_2(D) < 0.0)
goto ;
  else
goto ;

The 2 conditions don't share the same then branch or the same else branch (it
is a mix), so ifcombine doesn't even try to turn it into

  if (x_2(D) > 0.0 || !(x_2(D) < 0.0))
goto ;
  else
goto ;

Besides, it doesn't look like the logic is in place to fold that condition into
just its second half (but I may have missed it).

[Bug libfortran/52537] slow trim function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #8 from Thomas Koenig  2012-06-07 
14:51:00 UTC ---
I think this is fixed.  Please reopen if there
is an issue that is still problematic.

[Bug c/53603] abs() doesn't warn if argument is double, not even with -Wall -Wextra

[gcc at richardneill dot org]

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

--- Comment #3 from Richard Neill  2012-06-07 
14:41:10 UTC ---
Thanks for your explanation. I didn't know about -Wconversion existing
independently of -Wextra. 

Might I suggest a couple of things that arise:

1. It seems a bit strange to me that there are warnings that are not enabled by 
-Wall -Wextra. The man page lists so many different types of warning: perhaps
it would be useful to mention (under -Wextra) which ones it does *not* enable?
Or maybe it would be worthwhile adding something like "-Wkitchensink" to mean:
yes, really do turn on all the warnings (except maybe for pedantic). 

2. Even -Wconversion misses the following:

  int a=7; int b=4;
  double y;  
  y = a/b;

I know why: a/b is a perfectly sensible integer division, and then y is being
assigned the integer value of 1, which is also a loss-freel conversion.
But, what I mean by "y=a/b" is "y is the floating point number obtained by
dividing a and b", not "do integer division of a/b and then promote to a
double"

3. As you say, -Wconversion is too noisy to include by default. But perhaps
there could be a distinction between straightforward assignment: 

   int a; 
   unsigned int b;
   a=b; 

and function calls with mismatched parameters:

   int a; 
   double d;
   int myfunction(int x){...}  ; 
   a = myfunction(d);

I'd suggest that when the latter happens, it's most probably a bug, whereas the
former is (often) deliberate. This might allow for some subsets of -Wconversion
to be included within -Wextra ? 

Thanks for your time.

[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  2012-06-07 
14:33:56 UTC ---
Author: tkoenig
Date: Thu Jun  7 14:33:51 2012
New Revision: 188305

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188305
Log:
2012-06-07  Thomas König  

PR fortran/52861
* frontend-passes.c (optimize_assignment):  Don't set the
length of an empty string for deferred-length character
variables.

2012-06-07  Thomas König  

PR fortran/52861
* gfortran.dg/string_assign_2.f90:  New test case.



Added:
trunk/gcc/testsuite/gfortran.dg/string_assign_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||gcc at richardneill dot org

--- Comment #4 from Manuel López-Ibáñez  2012-06-07 
14:03:45 UTC ---
*** Bug 53603 has been marked as a duplicate of this bug. ***

[Bug c/53603] abs() doesn't warn if argument is double, not even with -Wall -Wextra

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #2 from Manuel López-Ibáñez  2012-06-07 
14:03:45 UTC ---
It warns with -Wconversion, but that brings other warnings. See also:

http://gcc.gnu.org/wiki/NewWconversion#Frequently_Asked_Questions

We could have finer grained options such as Wconversion-float-to-int
Wconversion-precission-loss Wconversion-64-to-32, but it isn't clear how far we
should go: There will be always some people that want a warning in a specific
case and not in another very specific case.

Also, Wconversion currently warns in too many common cases to be enabled by
-Wextra: See PR38522, PR39170, PR40752, PR53277, etc.

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

[Bug c/50347] unexpected -Wconversion error from gcc builtin

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  2012-06-07 
14:02:12 UTC ---
Could you send a doc patch to gcc-patches@ ? Thanks!

[Bug c/53603] abs() doesn't warn if argument is double, not even with -Wall -Wextra

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2012-06-07 
13:55:05 UTC ---
Use -Wconversion:

[macbook] f90/bug% gcc48 -Wconversion pr53603.c
pr53603.c: In function 'main':
pr53603.c:6:9: warning: conversion to 'int' from 'double' may alter its value
[-Wconversion]
 y = abs (x);
 ^

although I'ld expect the caret under x. For 4.4 to 4.7 one gets

pr53603.c: In function 'main':
pr53603.c:6: warning: conversion to 'int' from 'double' may alter its value

[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Attachment #27576|0   |1
is obsolete||

--- Comment #10 from Georg-Johann Lay  2012-06-07 
13:31:32 UTC ---
Created attachment 27577
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27577
pr53595.diff: tentative patch

Better return 0 as false...

[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot

[gjl at gcc dot gnu.org]

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

--- Comment #9 from Georg-Johann Lay  2012-06-07 
13:27:33 UTC ---
Created attachment 27576
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27576
pr53595.diff

And here is a tentative patch:

Let HARD_REGNO_CALL_PART_CLOBBERED return false if HARD_REGNO_MODE_OK is false.

[Bug rtl-optimization/53595] Code size increase of +10% between two 4.7.1 snapshot

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-07
 CC||vmakarov at redhat dot com
 Ever Confirmed|0   |1

--- Comment #8 from Georg-Johann Lay  2012-06-07 
13:24:51 UTC ---
(In reply to comment #5)
> That's not very narrow interval.  Please bisect what affected it (or what
> affected it most).

CCing Vladimir

It is caused by fix for PR53065 in

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

--- branches/gcc-4_7-branch/gcc/config/avr/avr.h2012/04/24 15:23:22   
186769
+++ branches/gcc-4_7-branch/gcc/config/avr/avr.h2012/04/24 15:23:46   
186770
@@ -394,6 +394,11 @@

 #define REGNO_OK_FOR_INDEX_P(NUM) 0

+#define HARD_REGNO_CALL_PART_CLOBBERED(REGNO, MODE)\
+  (((REGNO) < 18 && (REGNO) + GET_MODE_SIZE (MODE) > 18)   \
+   || ((REGNO) < REG_Y && (REGNO) + GET_MODE_SIZE (MODE) > REG_Y)  \
+   || ((REGNO) < REG_Z && (REGNO) + GET_MODE_SIZE (MODE) > REG_Z))
+

What's really confusing to me is that this macro is called with invalid
registers, i.e with registers that HARD_REGNO_MODE_OK will reject.

If the macro returns false for the invalid registers, the performance
regression goes away.

Vladimir, is it save to return 0 for invalid hard registers?

What's the point with generating different code when invalid registers are
treated differently?  As far as I can see the hard register is not about
SUBREGs, it contains a pointer.

[Bug c/53603] New: abs() doesn't warn if argument is double, not even with -Wall -Wextra

[gcc at richardneill dot org]

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

 Bug #: 53603
   Summary: abs() doesn't warn if argument is double, not even
with -Wall -Wextra
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@richardneill.org


I think that using abs() with an argument which isn't an int, should to trigger
a warning... but it doesn't. Not even with -Wextra.

//Compile with Wall -Wextra
//I think that gcc could spot that abs() casts x to int, 
//and it could warn me that I did something stupid. 

#include 
#include 
int main(){
double x=44.33;
double y;
y = abs (x);
printf ("y is %f\n", y);
//get 44.00 , expect 44.33
return (0);
}


Please do consider trapping this: I spent 3 hours finding a bug caused by this
one: yes, it was my fault for writing sqrt(abs(a_double)) rather than
sqrt(fabs(a_double)), but the compiler could have warned me. This type of error
is quite insidious, because it can cause subtle errors in mathematical programs
that only occur sometimes!

Imho, gcc should warn, unless I'd written:
 y = abs( (int)x )

[Bug other/53601] g++ ICE compiling minion with -Ofast

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-06-07
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2012-06-07 
12:38:44 UTC ---
See http://gcc.gnu.org/bugs/

[Bug c++/53602] Libre Office causes an internal compiler error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-06-07
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-06-07 
12:35:28 UTC ---
Yeah, preprocessed source plus g++ options are needed.
I don't know the libreoffice build system either, as last resort solution you
could try
mkdir ~/bin
cat > ~/bin/g++ <<\EOF
#!/bin/sh
mkdir -p /tmp/cmdlines/ 2>/dev/null
echo cwd is `pwd` cmdline "$@" >> /tmp/cmdlines/$$
exec /usr/bin/g++ "$@"

and run the build under PATH=~/bin:$PATH CXX=~/bin/g++ or so, then just
grep for the source file in question.  If you hit it already once, supposedly
another make invocation wouldn't recompile everything, just a few sources and
ICE again.

[Bug c++/53602] New: Libre Office causes an internal compiler error

[andy at benton dot eu.com]

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

 Bug #: 53602
   Summary: Libre Office causes an internal compiler error
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@benton.eu.com


Libre Office 3.5.3 compiles fine for me with Gcc 4.7 on x86_64 but on
i686 the build dies with this error:

Making:all_uno-skeletonmaker.dpobj
Compiling: unodevtools/source/skeletonmaker/skeletonmaker.cxx
Compiling: unodevtools/source/skeletonmaker/skeletoncommon.cxx
/home/andy/save/sources/extras/libreoffice-core-3.5.3.2/unodevtools/source/skeletonmaker/skeletoncommon.cxx:
In function 'void
skeletonmaker::checkDefaultInterfaces(boost::unordered::unordered_set&, const boost::unordered::unordered_set&, const rtl::OString&)':
/home/andy/save/sources/extras/libreoffice-core-3.5.3.2/unodevtools/source/skeletonmaker/skeletoncommon.cxx:317:1:
internal compiler error: in force_move_args_size_note, at
combine-stack-adj.c:419
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The "internal compiler error" and the request for a bug report to be
sent to gcc makes it look like a bug in Gcc 4.7. The actual code that
causes the problem looks like this:

void checkDefaultInterfaces(
 boost::unordered_set< OString, OStringHash >& interfaces,
 const boost::unordered_set< OString, OStringHash >& services,
   const OString & propertyhelper)
{
if ( services.empty() ) {
if (interfaces.find("com.sun.star.lang.XServiceInfo") !=
interfaces.end())
interfaces.erase("com.sun.star.lang.XServiceInfo");
} else {
if (interfaces.find("com.sun.star.lang.XServiceInfo") ==
interfaces.end())
interfaces.insert("com.sun.star.lang.XServiceInfo");
}

if ( propertyhelper.equals("_") ) {
if (interfaces.find("com.sun.star.beans.XPropertySet")
!= interfaces.end())
interfaces.erase("com.sun.star.beans.XPropertySet");
if (interfaces.find("com.sun.star.beans.XFastPropertySet")
!= interfaces.end())
interfaces.erase("com.sun.star.beans.XFastPropertySet");
if (interfaces.find("com.sun.star.beans.XPropertyAccess")
!= interfaces.end())
interfaces.erase("com.sun.star.beans.XPropertyAccess");
}
}

Googling on the error found this bug report at Ubunut:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1007616
But sadly they have no solution.

I have previously built Libre Office 3.5.3 on i686 with Gcc 4.7, what was
different this time was that I used an svn pull of the Gcc 4.7 branch
(r188021). Ie, Gcc had changes that had been checked into the Gcc 4.7 branch
since gcc-4.7.0 was released.

Looking at http://gcc.gnu.org/bugs/#detailed it seems that I'm supposed to
provide the output of something like:

gcc -v -save-temps all-your-options source-file

Sadly I have no clue how gcc was called by the Libre Office dmake system (I am
completely unfamiliar with dmake). If someone could guide me on how to find out
how gcc was called I would appreciate it.

Another problem with debugging this is that I can only reproduce this on a 32
bit system and all my 32 bit computers are old and slow. Compiling Libre office
takes about 20 hours but fortunately the error occurs only about 4 hours into
the build

[Bug other/53601] g++ ICE compiling minion with -Ofast

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2012-06-07 
11:47:05 UTC ---
Please provide preprocessed source.

[Bug other/53601] New: g++ ICE compiling minion with -Ofast

[nagajyothi.eggone at amd dot com]

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

 Bug #: 53601
   Summary: g++ ICE compiling minion with -Ofast
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nagajyothi.egg...@amd.com


Compiling the Phoronix/minion benchmark with gcc 4.8 trunk at with -Ofast
produces the following ICE:

  Calls:
CT_GACALLDIFF.cpp:15:445: internal compiler error: verify_cgraph_node failed
 BUILD_CT(CT_GACALLDIFF, 1)

The ICE does not occur with -O2.

gcc version:
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --disable-bootstrap
--enable-languages=c,c++,fortran --prefix=/$HOME/gcc-4.8/usr
Thread model: posix
gcc version 4.8.0 20120430 (experimental) (GCC)

[Bug fortran/53591] Front-end optimize empty string assignments

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Thomas Koenig  2012-06-07 
11:16:46 UTC ---
Also fixed with the commit for PR 52861.

Closing.

[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Thomas Koenig  2012-06-07 
11:13:13 UTC ---
Fixed on trunk, closing.

Thanks for the bug report!

[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  2012-06-07 
11:12:02 UTC ---
Author: tkoenig
Date: Thu Jun  7 11:11:55 2012
New Revision: 188300

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188300
Log:
2012-06-07  Thomas König  

PR fortran/52861
* frontend-passes (empty_string):  Add prototype.
(optimize_assignment):  Set the length of an empty string
constant to zero.

2012-06-07  Thomas König  

PR fortran/52861
* gfortran.dg/string_assign_1.f90:  New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/string_assign_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/53599] [4.7/4.8 Regression] gcc-4.7.1_rc20120606 segfaults compiling boost.karma

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-06-07 
09:36:26 UTC ---
Even shorter (but invalid):
template 
struct C
{
};

template 
struct E
{
  static bool const value = true;
};

template 
int
foo ()
{
  struct F;
  struct G
  {
static int *(F::*bar ()) (T)
{
}
  };
  enum
  {
I = sizeof (C <((E ::value))> (G::bar ()))
  };
  return 1;
}

int z = foo  ();

[Bug c++/53599] [4.7/4.8 Regression] gcc-4.7.1_rc20120606 segfaults compiling boost.karma

[s...@s-e-f-i.de]

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

--- Comment #3 from Philipp  2012-06-07 09:14:56 UTC ---
Created attachment 27575
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27575
Reduced testcase

[Bug c/53593] #pragma prefetch

[litro at graasmilk dot net]

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

--- Comment #2 from atcl  2012-06-07 08:55:11 UTC 
---
(In reply to comment #1)
> This pragma is a control for the equivalent of the option
> -fprefetch-loop-arrays .
> 
> You might want to try out -fprefetch-loop-arrays out.

Well, but what about nested loops, or multiple loop indices or multiple arrays?
The prefetch and noprefetch pragma would give you a better degree of control in
my opinion. I would require these pragmas for very special situation, where I
feel I do know better than the compiler.

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  2012-06-07 
08:53:43 UTC ---
I summarized all this in
http://gcc.gnu.org/wiki/VerboseDiagnostics#delete-non-virtual-dtor but I am
afraid it is not a very good summary, please feel free to improve it.

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-06-07 
08:46:09 UTC ---
(In reply to comment #3)
> Hi, thanks for your answer but I still think it is a bug. Here are my reasons:
> 
> 1) You mention that Clang also warns for my example but this seems to be a bug
> in Clang, see
> http://lists.cs.uiuc.edu/pipermail/llvmbugs/2012-March/022451.html

I expect that bug will get closed, Clang behaves as designed.

> 2) Herb Sutter wrote a Guru of the Week (GotW) article on this topic
> (http://www.gotw.ca/publications/mill18.htm), it says: 
> 
> Guideline #4: A base class destructor should be either public and virtual, or
> protected and nonvirtual.

The compiler cannot know Derived is not a base class (unless you mark it
"final" to prevent derivation, or "__final" as a GCC extension in C++03).  You
have virtual functions, so it's reasonable to assume you plan to derive from
it.

> 3) If I modify 'virtual void foo()' to 'void foo()' in my previous example the
> warning vanishes, this makes no sense.

Then the class isn't polymorphic, so the compiler assumes you don't plan to
derive from it.


> 4) In your MoreDerived example you can make the Derived dtor virtual, this way
> the protected non-virtual Base destructor is absolutely valid.

Obviously. That fixes the undefined behaviour, so there's no warning,  that's
the change the compiler is suggesting you make!

(In reply to comment #4)
> I found another post on the web
> (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110530/042333.html)
> that explains the warning, it says:
> 
> "If Derived (see above) gets subclassed in the future, deletion in "main()"
> will be undefined behavior. Ideally Derived should be marked "final" and then
> there will also be no warning"

That's exactly what I demonstrated in my MoreDerived example.

> Based on this explanation I think the warning is valid. Clang's warning 
> message
> is somewhat more clear:
> 
> "warning: delete called on 'Derived' that has virtual functions but 
> non-virtual
> destructor [-Wdelete-non-virtual-dtor]"

A polymorphic class is one with virtual functions. That's standard terminology.

I prefer the GCC message, it tells you using delete might (or will) be
undefined behaviour, instead of just warning about using delete.

> This also explains why there is no warning in test2.cpp of my previous post.

Exactly.

[Bug c++/53598] missed diagnostics / equality comparison result unused.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-07
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  2012-06-07 
08:40:52 UTC ---
It would be nice to have.

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

[kim.walisch at gmail dot com]

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

kim.walisch at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #5 from kim.walisch at gmail dot com 2012-06-07 08:32:04 UTC ---
The warning is valid (see Comment 4), but the warning message is a bit unclear.

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

[kim.walisch at gmail dot com]

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

--- Comment #4 from kim.walisch at gmail dot com 2012-06-07 08:28:05 UTC ---
I found another post on the web
(http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110530/042333.html)
that explains the warning, it says:

"If Derived (see above) gets subclassed in the future, deletion in "main()"
will be undefined behavior. Ideally Derived should be marked "final" and then
there will also be no warning"

Based on this explanation I think the warning is valid. Clang's warning message
is somewhat more clear:

"warning: delete called on 'Derived' that has virtual functions but non-virtual
destructor [-Wdelete-non-virtual-dtor]"

This also explains why there is no warning in test2.cpp of my previous post.

[Bug c++/53599] [4.7/4.8 Regression] gcc-4.7.1_rc20120606 segfaults compiling boost.karma

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-07
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.7.1
Summary|gcc-4.7.1_rc20120606|[4.7/4.8 Regression]
   |segfaults compiling |gcc-4.7.1_rc20120606
   |boost.karma |segfaults compiling
   ||boost.karma
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2012-06-07 
08:05:42 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188117
i.e. a very recent regression on 4.7 branch and trunk.

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

[kim.walisch at gmail dot com]

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

--- Comment #3 from kim.walisch at gmail dot com 2012-06-07 07:31:41 UTC ---
Hi, thanks for your answer but I still think it is a bug. Here are my reasons:

1) You mention that Clang also warns for my example but this seems to be a bug
in Clang, see
http://lists.cs.uiuc.edu/pipermail/llvmbugs/2012-March/022451.html

2) Herb Sutter wrote a Guru of the Week (GotW) article on this topic
(http://www.gotw.ca/publications/mill18.htm), it says: 

Guideline #4: A base class destructor should be either public and virtual, or
protected and nonvirtual.

3) If I modify 'virtual void foo()' to 'void foo()' in my previous example the
warning vanishes, this makes no sense.

terminal log:

$ g++-4.7 -Wall test2.cpp 
$

/
// file: test2.cpp

#include 

class Base {
protected:
  ~Base() { }
};

class Derived : public Base {
public:
  void foo() { std::cout << "Derived::foo()"  << std::endl; }
  ~Derived() { std::cout << "Derived::~Derived()" << std::endl; }
};

int main() {
  Derived* derived = new Derived();
  derived->foo();
  delete derived; // correct, no warning!
  return 0;
}

/

4) In your MoreDerived example you can make the Derived dtor virtual, this way
the protected non-virtual Base destructor is absolutely valid.

/
// file: test3.cpp

class Base {
public:
  virtual void foo() = 0;
protected:
  ~Base() { }
};

class Derived : public Base {
public:
  virtual void foo() { }
  virtual ~Derived() { }
};

class MoreDerived : public Derived {
public:
  ~MoreDerived() { }
};

int main() {
  Derived* morederived = new MoreDerived();
  morederived->foo();
  delete morederived; // no warning, virtual Derived dtor
  return 0;
}

/