[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-06-15 
06:32:20 UTC ---
Created attachment 24533
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24533
gcc47-pr49411.patch

Untested fix.  Alternatively, we could for the rotation instead just always
mask the immediate operand (the only docs I found about these intrinsics was
MSFT documentation which didn't say anything on invalid count, but even said
that the count is preferrably an integer instead of unconditionally an
integer).
Therefore, perhaps we could mask it if it is constant and expand using
rotl3 expander if it is not CONST_INT.

[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.15 05:48:05
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2011-06-15 
05:48:05 UTC ---
I'll handle this.

[Bug bootstrap/49415] New: [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

   Summary: [4.7 Regression] Revision 175071 fails to bootstrap on
x86_64-apple-darwin10
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: js...@gcc.gnu.org
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10


Revision 175071 fails to bootstrap on x86_64-apple-darwin10 with

...
/opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/bin/
-B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/bin/
-B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/lib/ -isystem
/opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/include -isystem
/opt/gcc/gcc4.7w/x86_64-apple-darwin10.7.0/sys-include-c   -g -O2
-mdynamic-no-pic -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../work/gcc -I../../work/gcc/. -I../../work/gcc/../include
-I../../work/gcc/../libcpp/include -I/opt/sw64/include 
-I../../work/gcc/../libdecnumber -I../../work/gcc/../libdecnumber/dpd
-I../libdecnumber  -I/opt/sw64/include -DCLOOG_INT_GMP -DCLOOG_ORG
-I/opt/sw64/include \
  ../../work/gcc/common/config/i386/i386-common.c -o i386-common.o
In file included from ./tm_p.h:5:0,
 from ../../work/gcc/common/config/i386/i386-common.c:27:
../../work/gcc/config/darwin-protos.h:57:51: error: ISO C forbids forward
references to 'enum' types [-Werror=edantic]
../../work/gcc/config/darwin-protos.h:58:11: error: 'enum machine_mode'
declared inside parameter list [-Werror]
../../work/gcc/config/darwin-protos.h:58:11: error: its scope is only this
definition or declaration, which is probably not what you want [-Werror]
cc1: all warnings being treated as errors

This is likely due to revision 175064.

[Bug c++/49412] __dso_handle should be hidden

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  2011-06-15 
04:11:14 UTC ---
Seems reasonable.

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #23 from Jason Merrill  2011-06-15 
03:58:07 UTC ---
Fixed.

[Bug c++/49389] [C++0x] Wrong value category for pointer-to-member expression with rvalue object expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|jason at redhat dot com |jason at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #2 from Jason Merrill  2011-06-15 
03:56:11 UTC ---
Fixed for 4.7.

[Bug c++/49369] typeof() strips const from member when used in const method

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.1

--- Comment #7 from Jason Merrill  2011-06-15 
03:55:11 UTC ---
Fixed for 4.6.1.

[Bug c++/49117] 4.5 -> 4.6: user-unfriendly change in "invalid conversion" error message

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.1

--- Comment #3 from Jason Merrill  2011-06-15 
03:54:34 UTC ---
Fixed for 4.6.1.

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[jason at gcc dot gnu.org]

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

--- Comment #22 from Jason Merrill  2011-06-15 
03:52:02 UTC ---
Author: jason
Date: Wed Jun 15 03:51:59 2011
New Revision: 175073

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175073
Log:
PR c++/49107
* cp-tree.h (DEFERRED_NOEXCEPT_SPEC_P): Handle overload.
* method.c (defaulted_late_check): Only maybe_instantiate_noexcept
if the declaration had an exception-specifier.
(process_subob_fn): Don't maybe_instantiate_noexcept.
* pt.c (maybe_instantiate_noexcept): Handle overload.
* typeck2.c (nothrow_spec_p_uninst): New.
(merge_exception_specifiers): Add 'fn' parm.  Build up overload.
* typeck.c (merge_types): Adjust.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/method.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*

[howarth at nitro dot med.uc.edu]

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

--- Comment #29 from Jack Howarth  2011-06-15 
03:21:04 UTC ---
While we are fixing the pie/PIE handling on darwin, we should also address a
change required for darwin11 which defaults its linker to -pie. This causes
breakage in gcj and pch since FSF gcc isn't defaulting to -fpie yet. The simple
fix is just pass -no_pie on LINK_GCC_C_SEQUENCE_SPEC for 10.7 or later whenever
the compiler isn't trying to generate pie/PIE code. This change on top of
Iain's patch eliminates the pch and gcj  failures.

[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*

[howarth at nitro dot med.uc.edu]

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

--- Comment #28 from Jack Howarth  2011-06-15 
03:15:44 UTC ---
Created attachment 24532
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24532
patch to fix pie handling for darwin11

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[anitha.boyapati at atmel dot com]

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

--- Comment #25 from Anitha Boyapati  
2011-06-15 02:37:59 UTC ---
(In reply to comment #24)
> The testcase at the head of the PR is now fixed.
> 
> For the 4.6 branch, this required also backporting
> 


(Assuming that backporting implies the emission of DWARF2 CFI) Is it not
possible to drop DWARF2 CFI feature (which is optional) and still make 4.6x
build successful? It is quite possible that some target might want to do this.

If the intention is to make CFI mandatory, then internals document should be
updated as well.

[Bug tree-optimization/49413] over-optimization that causes valid code to segfault

[gattis at gmail dot com]

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

--- Comment #7 from Matt Gattis  2011-06-15 01:19:57 
UTC ---
(In reply to comment #6)
> The problem is:
>   double *v = (qp == &(t->q)) ? t->xyz->va : t->xyz->vb;
> 
> the pointer v is a pointer to a 8 byte aligned data but you supply it with
> something which is only 4 byte aligned.

Silly me, I thought the whole point of a compiler was to make it so you didn't
have to code to machine-specific byte alignments and instructions.

[Bug tree-optimization/49413] over-optimization that causes valid code to segfault

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  2011-06-15 
01:13:14 UTC ---
The problem is:
  double *v = (qp == &(t->q)) ? t->xyz->va : t->xyz->vb;

the pointer v is a pointer to a 8 byte aligned data but you supply it with
something which is only 4 byte aligned.

[Bug tree-optimization/49413] over-optimization that causes valid code to segfault

[gattis at gmail dot com]

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

--- Comment #5 from Matt Gattis  2011-06-15 01:10:35 
UTC ---
(In reply to comment #1)
> I think this code is undefined as the alignment requirements of double is 8
> bytes but the original (t->xyz->va/t->xyz->vb) is packed so it has a alignment
> of 4 bytes.

Isn't the only reason to use a packed struct to be able to squeeze misaligned
data together and have it all work?  My understanding is that GCC is supposed
to automatically take care of the alignment using extra instructions.  And it
does, except when I turn more optimizations on.

For some added context, I am mmap'ing a large file with the data packed in that
struct format.  Are you saying the only way I would get "defined" behavior from
GCC 
is if I referenced xyz->va[i] every access, instead of assigning a temp
variable to xyz->va?

[Bug tree-optimization/49413] over-optimization that causes valid code to segfault

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-06-15 
01:00:34 UTC ---
Personally, I find the expression "over-optimization" misleading: either we
have a compiler *bug*, which therefore is performing an incorrect
transformation, or we don't, thus the code is triggering undefined behavior
(which happens to show up at high optimization level). In either case, I don't
see "over-optimization".

[Bug rtl-optimization/49414] New: gcc.dg/pr44194-1.c failed

[hjl.tools at gmail dot com]

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

   Summary: gcc.dg/pr44194-1.c failed
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: era...@google.com


On Linux/ia32, revision 175063 gave

FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = 2"

[Bug c/49413] over-optimization that causes valid code to segfault

[gattis at gmail dot com]

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

--- Comment #3 from Matt Gattis  2011-06-15 00:39:06 
UTC ---
Created attachment 24531
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24531
verbose gcc output

[Bug c/49413] over-optimization that causes valid code to segfault

[gattis at gmail dot com]

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

--- Comment #2 from Matt Gattis  2011-06-15 00:38:29 
UTC ---
Created attachment 24530
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24530
verbose gcc output

[Bug c/49413] over-optimization that causes valid code to segfault

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-06-15 
00:34:37 UTC ---
I think this code is undefined as the alignment requirements of double is 8
bytes but the original (t->xyz->va/t->xyz->vb) is packed so it has a alignment
of 4 bytes.

[Bug c/49413] New: over-optimization that causes valid code to segfault

[gattis at gmail dot com]

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

   Summary: over-optimization that causes valid code to segfault
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gat...@gmail.com


Created attachment 24529
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24529
source code

The attached short .c code compiles without warnings and segfaults when -O3 is
used.  The code runs fine with -O1 or if I declare v as "volatile double *"
instead of just "double *".  This was triggered in a much larger code base. 
I've managed to strip everything else out and reduce it to this.  I'm pretty
sure the code left is correct, so I think it's a GCC bug.

GCC Version: 4.6.0 w/ gmp-5.0.2, mpc-0.9, mpfr-3.0.1
System: CentOS 5 x86_64 (AMD Istanbull)
GCC ./configure flags: --enable-languages=c,c++,fortran
Source compilation command: gcc -O3 volatile.c -o volatile

[Bug c++/49412] New: __dso_handle should be hidden

[hjl.tools at gmail dot com]

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

   Summary: __dso_handle should be hidden
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ja...@redhat.com


__dso_handle is always defined locally and hidden if
HAVE_GAS_HIDDEN is set.  Does this patch:

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index f4988f9..17ba539 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6435,6 +6435,11 @@ get_dso_handle_node (void)
   dso_handle_node = declare_global_var (get_identifier ("__dso_handle"),
 ptr_type_node);

+#ifdef HAVE_GAS_HIDDEN
+  DECL_VISIBILITY (dso_handle_node) = VISIBILITY_HIDDEN;
+  DECL_VISIBILITY_SPECIFIED (dso_handle_node) = 1;
+#endif
+
   return dso_handle_node;
 }

make any senses?

[Bug c++/49290] [4.6/4.7 Regression][C++0x] ICE in in cxx_eval_indirect_ref, at cp/semantics.c:6795

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jason Merrill  2011-06-14 
23:41:15 UTC ---
Fixed for 4.6.1.

[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-06-14 
23:21:32 UTC ---
It ICEs even for positive values such as _mm_roti_epi8 (s, 76);
I think multi_arg builtin expansion needs to do constant argument checking,
at least for IX86_BUILTIN_VPROT[BWDQ]_IMM and IX86_BUILTIN_VPERMIL2P[DS]{,256}.
And for the former ones either use CODE_FOR_* of an expander that handles both
positive and negative values, where for positive one it would expand to
xop_rotl* and for negative to xop_rotr* with the shift count negated, or
the negation and choice of pattern needs to be done in
ix86_expand_multi_arg_builtin.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[eraman at gcc dot gnu.org]

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

--- Comment #19 from eraman at gcc dot gnu.org 2011-06-14 22:58:24 UTC ---
Author: eraman
Date: Tue Jun 14 22:58:20 2011
New Revision: 175063

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175063
Log:
2011-06-14  Easwaran Raman  

   PR rtl-optimization/44194
   * dse.c: Include tree-flow.h
   (insn_info): Add new field non_frame_wild_read.
   (group_info): Add new fields escaped_n and escaped_p.
   (kill_on_calls): New variable.
   (get_group_info): Initialize gi->escaped_n and gi->escaped_p.
   (dse_step0): Initialize kill_on_calls.
   (can_escape): New function.
   (set_usage_bits): Add additional parameter; record information
   about escaped locations.
   (record_store): Pass EXPR corresponding to MEM to
   set_usage_bits.
   (dse_step2_nospill): Set kill_on_calls based on
   group->escaped_n and group->escaped_n.
   (add_wild_read): Refactor into...
   (reset_active_stores): ... New method, and
   (free_read_records): ... New method.
   (add_non_frame_wild_read): New method.
   (scan_insn): Call add_non_frame_wild_read on non-const calls.
   (scan_reads_nospill): Handle instructions with
   non_frame_wild_read.
   (dse_step5_nospill): Call scan_reads_nospill for instructions
   marked as non_frame_wild_read.
   (dse_step7): Free escaped_n, escaped_p and kill_on_calls
   bitmaps.

testsuite/ChangeLog

2011-06-14  Easwaran Raman  

   PR rtl-optimization/44194
   * gcc.dg/pr44194-1.c: New test.
   * gcc.dg/pr44194-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr44194-1.c
trunk/gcc/testsuite/gcc.dg/pr44194-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dse.c
trunk/gcc/testsuite/ChangeLog

[Bug target/49411] New: [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[qneill at gcc dot gnu.org]

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

   Summary: [4.6/4.7] ICE: unrecognizable insn with -mxop in
_mm_roti_epi8 with negative number
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: qne...@gcc.gnu.org


Using _mm_roti_epi8 in xopintrin.h with a negative number produces an ICE in
4.6/4.7; the negative number is how you use VPROT[BWDQ] to rotate right, see 
http://support.amd.com/us/Processor_TechDocs/26568.pdf

-- testcase.c --
#include 
void f(void)
{
__m128 s;
__m128i d;
return _mm_roti_epi8(s, -1);
}
-- output --
$ gcc -mxop -c vprotbi1.c
vprotbi1.c: In function ‘f’:
vprotbi1.c:6:2: warning: ‘return’ with a value, in function returning void
[enabled by default]
vprotbi1.c:7:1: error: unrecognizable insn:
(insn 6 5 7 3 (set (reg:V16QI 60 [ D.8650 ])
(rotate:V16QI (reg:V16QI 59 [ D.8648 ])
(const_int -1 [0x]))) vprotbi1.c:6 -1
 (nil))
vprotbi1.c:7:1: internal compiler error: in extract_insn, at recog.c:2113
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/49409] some possible new warnings for strange code

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-06-14 
22:34:34 UTC ---
some warnings would seem sensible to me

I tried clang++ which only warns about the first two, via
-Wtautological-compare

[Bug tree-optimization/49365] 436.cactusADM performance regression

[changpeng.fang at amd dot com]

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

--- Comment #5 from Changpeng Fang  2011-06-14 
22:22:11 UTC ---
It seems there is a prefetch generation bug on Bulldozer.

With -O3 -ffast-math -funroll-loops -fpeel-loops -march=bdver1
-fprefetch-loop-arrays, I got a normal timing of 795s.

However, when "--param min-insn-to-prefetch-ratio=9" is added, the timing
becomes 2853s.

This may be a different bug, in the opposite direction to amdfam10

I also want to mention here that software prefetching was actually enabled
at -O3 and higher for Bulldozer, when Honza cleaned up the code in i386.c
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00573.html

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #16 from Jakub Jelinek  2011-06-14 
22:16:54 UTC ---
Worked around for now.

[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-06-14 
22:17:21 UTC ---
Fixed.

[Bug c++/49369] typeof() strips const from member when used in const method

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-06-14 
22:13:32 UTC ---
Author: jason
Date: Tue Jun 14 22:13:29 2011
New Revision: 175059

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175059
Log:
PR c++/49369
* class.c (build_base_path): Fix cv-quals in unevaluated context.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/decltype30.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/class.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/49117] 4.5 -> 4.6: user-unfriendly change in "invalid conversion" error message

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-14 
22:13:39 UTC ---
Author: jason
Date: Tue Jun 14 22:13:36 2011
New Revision: 175060

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175060
Log:
PR c++/49117
* call.c (perform_implicit_conversion_flags): Print source type as
well as expression.

Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/call.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/other/error23.C
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/other/error32.C

[Bug c++/49290] [4.6/4.7 Regression][C++0x] ICE in in cxx_eval_indirect_ref, at cp/semantics.c:6795

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-06-14 
22:13:24 UTC ---
Author: jason
Date: Tue Jun 14 22:13:19 2011
New Revision: 175058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175058
Log:
PR c++/49290
* semantics.c (cxx_eval_indirect_ref): Remove assert.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/regress/49290.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/semantics.c

[Bug inline-asm/49410] New: Internal compiler error in change-stack at reg-stack.c:2540

[gcc.hall at gmail dot com]

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

   Summary: Internal compiler error in change-stack at
reg-stack.c:2540
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com


I saw this while experimenting with the (probably incorrect) inline x87
assembler:

test.c: In function 'main':
test.c:16:1: internal compiler error: in change_stack, at reg-stack.c:2540
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
--
#include 

int
main( int argc, char *argv[] )
{
  long double x, n = 1234.0L;

  asm( "fldpi; fmulp; fsqrt" : "=t" (x) : "u" (n) );

  printf("sqrt(pi * n) = %Lg\n", x );
}
--
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.0/configure
Thread model: posix
gcc version 4.6.0 (GCC)

[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions

[dcb314 at hotmail dot com]

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

--- Comment #4 from dcb  2011-06-14 21:13:11 UTC ---
(In reply to comment #2)
> Same error on all branches back to 4.4.

Interesting. Worth generalising so that source code pattern

if (X)
{
}
else if (X)
{
}

would cause a compiler warning ?

[Bug tree-optimization/48613] [4.6/4.7 Regression] ICE: vector VEC(ipa_node_params_t,base) index domain error with -O0 -flto -findirect-inlining

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  2011-06-14 
20:51:53 UTC ---
Patch posted to mailing list:

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01108.html

[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2

[sje at gcc dot gnu.org]

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

--- Comment #1 from Steve Ellcey  2011-06-14 20:26:13 
UTC ---
Author: sje
Date: Tue Jun 14 20:26:08 2011
New Revision: 175055

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175055
Log:
2011-06-14  Steve Ellcey  

PR testsuite/48727
* g++.dg/opt/devirt2.C: Fix scan rules for ia64*-*-hpux* and hppa*-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/opt/devirt2.C

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #21 from Jason Merrill  2011-06-14 
19:30:25 UTC ---
(In reply to comment #20)
> The patch fixes the example (thanks), but I still have trouble with the
> following

Hmm, looks like I need to delay evaluation of noexcept for implicitly declared
functions, too.

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #24 from Richard Henderson  2011-06-14 
19:15:44 UTC ---
The testcase at the head of the PR is now fixed.

For the 4.6 branch, this required also backporting

2011-03-22  Richard Henderson  

   * config/avr/avr.c (TARGET_EXCEPT_UNWIND_INFO): New.
   (avr_incoming_return_addr_rtx): New.
   (emit_push_byte): New.
   (expand_prologue): Use it.  Remove incorrect dwarf annotation for
   SREG, RAMPZ, zero register.  Push frame pointer by bytes.  Add dwarf
   annotation for __prologue_saves__.  Fixup dwarf annotation for CFA.
   (emit_pop_byte): New.
   (expand_epilogue): Use it.  Pop frame pointer by bytes.
   * config/avr/avr.h (FRAME_POINTER_CFA_OFFSET): Remove.
   (INCOMING_RETURN_ADDR_RTX): New.
   (INCOMING_FRAME_SP_OFFSET): New.
   (ARG_POINTER_CFA_OFFSET): New.
   * config/avr/avr.md (*pushqi): Fix mode of auto-inc.
   (*pushhi, *pushsi, *pushsf, popqi): Likewise.
   (pophi): Remove.

from mainline.

[Bug c++/49409] New: some possible new warnings for strange code

[dcb314 at hotmail dot com]

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

   Summary: some possible new warnings for strange code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Consider the following code

extern void g( int);

void f( int i)
{
if (i == i) // same thing compared
g( i);

if (i != i) // same thing compared
g( 2 * i);

if ((i - i) > 10)   // X - X == 0, unless volatile
g( 3 * i);

if (i || i) // duplicates in ||
g( 4 * i);

if (i && i) // duplicates in &&
g( 5 * i);
}

I ran the above code through the C++ compiler, with warning flags -Wall
-Wextra and it was surprisingly silent.

Would it be worthwhile for g++ to warn about some, all or none of
the above coding errors ?

[Bug debug/49408] member function template id not matching linkage name

[jan.kratochvil at redhat dot com]

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

--- Comment #1 from Jan Kratochvil  
2011-06-14 19:14:19 UTC ---
This Bug may not longer make sense due to:
Bug 49312 - Make DW_AT_name contain only simple name, no template-id

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[rth at gcc dot gnu.org]

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

--- Comment #23 from Richard Henderson  2011-06-14 
19:13:04 UTC ---
Author: rth
Date: Tue Jun 14 19:13:00 2011
New Revision: 175049

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175049
Log:
PR debug/48459
* dwarf2out.c (frame_pointer_fb_offset_valid): New.
(based_loc_descr): Assert it's true.
(compute_frame_pointer_to_fb_displacement): Set it, rather than
aborting immediately.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/dwarf2out.c

[Bug debug/49408] New: member function template id not matching linkage name

[jan.kratochvil at redhat dot com]

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

   Summary: member function template id not matching linkage name
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
CC: do...@gcc.gnu.org
Target: x86_64-unknown-linux-gnu


FAIL gcc (GCC) 4.4.7 20110614 (prerelease)
FAIL gcc (GCC) 4.7.0 20110614 (experimental)

struct S {
  void m (int x) {}
};
template
struct K {
  void f () { S s; (s.*F) (5); }
};
int main () {
  K<&S::m> k;
  k.f ();
}

-g

 <1><64>: Abbrev Number: 8 (DW_TAG_structure_type)
<65>   DW_AT_name: K<&S::m>
 <2><8a>: Abbrev Number: 10 (DW_TAG_template_value_param)
<8b>   DW_AT_name: F
<8d>   DW_AT_type: <0x170>  
 <2><70>: Abbrev Number: 9 (DW_TAG_subprogram)
<72>   DW_AT_name: f
<76>   DW_AT_MIPS_linkage_name: _ZN1KIXadL_ZN1S1mEiEEE1fEv  
 <1><11d>: Abbrev Number: 18 (DW_TAG_subprogram)
<11e>   DW_AT_specification: <0x70> 
<122>   DW_AT_low_pc  : 0x4004de
004004de W _ZN1KIXadL_ZN1S1mEiEEE1fEv
004004de W K<&(S::m(int))>::f()

The linkage name has class name: K<&(S::m(int))>
But DW_AT_name of that class is: K<&S::m>

It is not ambiguous but it breaks debugger lookups.

[Bug debug/49407] New: unusable debuginfo for dll-imported functions.

[pluto at agmk dot net]

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

   Summary: unusable debuginfo for dll-imported functions.
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


Hi,

i;m currently testing the 4,6-based i686-pc-mingw32 toolchain and
afaics the debuginfo for dll-imported functions are quite unusable :/

$ cat d.cpp
#include 
extern "C" __declspec(dllexport) void bar( void )
{
puts( "bar is here!" );
}

$ cat m.cpp
#include 
extern "C" void bar( void );
int main()
{
bar();
}

$ make
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-g++ -Wall
-mthreads -g2 d.cpp -shared -o d.dll
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-objdump -xw d.dll
> d.txt
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-g++ -Wall
-mthreads -g2 m.cpp -o m.exe d.dll
/local/devel/toolchain46/i686-pc-mingw32/bin/i686-pc-mingw32-objdump -xw m.exe
> m.txt

and now on windows host the gdb.exe shows me:

D:\mingw.tests>d:\mingw32\bin\gdb.exe m.exe
GNU gdb (GDB) 7.2.90.20110602-cvs
(...)
(gdb) b bar
Breakpoint 1 at 0x402798
(gdb) r
Starting program: D:\mingw.tests/m.exe
(...)
Breakpoint 1, 0x00402798 in bar ()
(gdb) disassemble
Dump of assembler code for function bar:
=> 0x00402798 <+0>: jmp*0x406200
   0x0040279e <+6>: nop
   0x0040279f <+7>: nop
End of assembler dump.
(gdb) si
0x6b4414c0 in ?? ()
(gdb) disassemble
No function contains program counter for selected frame.

at this point i can't debug the 'bar' function :(

[Bug debug/49407] unusable debuginfo for dll-imported functions.

[pluto at agmk dot net]

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

--- Comment #1 from Pawel Sikora  2011-06-14 19:04:34 
UTC ---
Created attachment 24528
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24528
testcase

[Bug c++/49406] Inlining in inheritance seems broken

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #10 from Jonathan Wakely  2011-06-14 
18:39:55 UTC ---
the usual way to do that is to define the inline function in a header (e.g.
Base.h would be the obvious place)

it cannot be inlined in Derived.c++ if its definition is not included in that
file

[Bug c++/49406] Inlining in inheritance seems broken

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2011-06-14 
18:37:28 UTC ---
your program is invalid

if a function is declared inline in one translation unit (such as Base.c++)
then it must be declared inline in all translation units that refer to it

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #8 from neotheone222 at gmail dot com 2011-06-14 18:36:35 UTC ---
Created attachment 24527
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24527
InlineText preprocessed file

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #7 from neotheone222 at gmail dot com 2011-06-14 18:36:01 UTC ---
Created attachment 24526
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24526
InlineText main file

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #6 from neotheone222 at gmail dot com 2011-06-14 18:35:22 UTC ---
Created attachment 24525
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24525
Derived preprocessed file

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #5 from neotheone222 at gmail dot com 2011-06-14 18:35:04 UTC ---
Created attachment 24524
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24524
Derived implementation file

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #4 from neotheone222 at gmail dot com 2011-06-14 18:34:43 UTC ---
Created attachment 24523
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24523
Derived header file

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #3 from neotheone222 at gmail dot com 2011-06-14 18:34:18 UTC ---
Created attachment 24522
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24522
Base preprocessed file

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #2 from neotheone222 at gmail dot com 2011-06-14 18:33:52 UTC ---
Created attachment 24521
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24521
Base implementation file

[Bug c++/49406] Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

--- Comment #1 from neotheone222 at gmail dot com 2011-06-14 18:33:25 UTC ---
Created attachment 24520
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24520
Base header file

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #23 from Nicola Pero  2011-06-14 
18:26:40 UTC ---
Yes, in a strict sense this bug could be closed ... because objc_msg_sendv() no 
longer exists in the GNU Objective-C runtime.  So if the bug is about it not 
working on some platforms, it can certainly be closed. ;-)

Forwarding in libobjc still uses __builtin_apply(), so the problem, in a wider
sense, still exists.  But that forwarding is not used by any user of libobjc as 
far as I know (they all have their own libffi-based implementation of
forwarding
that are used through the forwarding hooks that libobjc has) and I'm planning
on 
entirely removing it for 4.7.0 - it's unused (the forwarding hooks override any
implementation in libobjc), and it often doesn't work.

I also have some other plans for a new forwarding infrastructure, that may or
may
not happen for 4.7.0.

Summarizing, I would close the bug, or leave it open but just to remind me/us
to:

 * remove the existing forwarding code from libobjc;

 * remove the forward-1.m testcase;

 * add new testcases for the libobjc forwarding hooks.  As these are the
official
ways to use forwarding (and the only ones available), we should have testcases.

Let me know if you have any comments.

Thanks

[Bug c++/49406] New: Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

   Summary: Inlining in inheritance seems broken
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: neotheone...@gmail.com


Gcc version: 4.5.2

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Consider the following two classes: Base and Derived. 
The complete code is as follows:

  //Base.h
class Base
{
  public:
void showBase();
};

  //Base.c++
inline void
Base::showBase()
{
  std::cout << "This is the base class.";
}

 //Derived.h
class Derived : public Base
{
  public:
void showDerived();
};

//Derived.c++
void
Derived::showDerived()
{
  std::cout << "This is derived class.\n";
  std::cout << "Calling base class method.\n";
  Base::showBase();
}

   //InlineTest.c++
int main()
{
  Derived derived;
  derived.showDerived();
  return 0;
}

Command-line : g++ InlineText.c++ Base.c++ Derived.c++ -o Inline.o

Compiler error output: /tmp/ccDKDhFN.o: In function `Derived::showDerived()':
Derived.c++:(.text+0x32): undefined reference to `Base::showBase()'
collect2: ld returned 1 exit status

[Bug c++/49117] 4.5 -> 4.6: user-unfriendly change in "invalid conversion" error message

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-06-14 
18:16:08 UTC ---
Author: jason
Date: Tue Jun 14 18:16:06 2011
New Revision: 175044

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175044
Log:
PR c++/49117
* call.c (perform_implicit_conversion_flags): Print source type as
well as expression.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/error23.C
trunk/gcc/testsuite/g++.dg/other/error32.C

[Bug c++/49369] typeof() strips const from member when used in const method

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-06-14 
18:15:53 UTC ---
Author: jason
Date: Tue Jun 14 18:15:51 2011
New Revision: 175042

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175042
Log:
PR c++/49369
* class.c (build_base_path): Fix cv-quals in unevaluated context.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype30.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49389] [C++0x] Wrong value category for pointer-to-member expression with rvalue object expression

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-06-14 
18:16:00 UTC ---
Author: jason
Date: Tue Jun 14 18:15:58 2011
New Revision: 175043

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175043
Log:
PR c++/49389
* typeck2.c (build_m_component_ref): Preserve rvalueness.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/rv-dotstar.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49290] [4.6/4.7 Regression][C++0x] ICE in in cxx_eval_indirect_ref, at cp/semantics.c:6795

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-14 
18:15:46 UTC ---
Author: jason
Date: Tue Jun 14 18:15:43 2011
New Revision: 175041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175041
Log:
PR c++/49290
* semantics.c (cxx_fold_indirect_ref): Local, more permissive copy
of fold_indirect_ref_1.
(cxx_eval_indirect_ref): Use it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array-ptr7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49405] Inlining in inheritance seems broken

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Paolo Carlini  2011-06-14 
18:09:34 UTC ---
Not a PR.

[Bug c++/49405] New: Inlining in inheritance seems broken

[neotheone222 at gmail dot com]

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

   Summary: Inlining in inheritance seems broken
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: neotheone...@gmail.com

[Bug target/49402] Duplicate use of v850.opt

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #3 from Uros Bizjak  2011-06-14 17:44:04 
UTC ---
.

[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  2011-06-14 
16:36:50 UTC ---
Author: hjl
Date: Tue Jun 14 16:36:45 2011
New Revision: 175036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175036
Log:
Expand strlen to Pmode.

2011-06-14  H.J. Lu  

PR middle-end/47364
* builtins.c (expand_builtin_strlen): Expand strlen to Pmode.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/builtins.c

[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl at gcc dot gnu.org]

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

--- Comment #8 from hjl at gcc dot gnu.org  2011-06-14 
16:36:16 UTC ---
Author: hjl
Date: Tue Jun 14 16:36:12 2011
New Revision: 175035

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175035
Log:
Pass POINTERS_EXTEND_UNSIGNED to convert_to_mode.

2011-06-12  H.J. Lu  

PR middle-end/47364
* builtins.c (expand_builtin_strlen): Properly handle target
not in Pmode if POINTERS_EXTEND_UNSIGNED is defined.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/builtins.c

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[gjl at gcc dot gnu.org]

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

--- Comment #22 from Georg-Johann Lay  2011-06-14 
16:32:08 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > > A full build for AVR fails, but that seems to be related to other
> > > open bugs.
> > 
> > What bugs? 
> 
> Perhaps I shouldn't assume.
> 
> ../../../../../../comb/newlib/libc/search/hash.c: In function 
> ‘__expand_table’:
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: error: unable to find 
> a
> register to spill in class ‘POINTER_REGS’
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: error: this is the
> insn:
> (insn 190 97 191 10 (set (reg:QI 18 r18)
> (mem/c:QI (plus:HI (reg/f:HI 28 r28)
> (const_int 5 [0x5])) [14 S1 A8]))
> ../../../../../../comb/newlib/libc/search/hash.c:886 4 {*movqi}
>  (nil))
> ../../../../../../comb/newlib/libc/search/hash.c:898:1: internal compiler
> error: in spill_failure, at reload1.c:2113

Oh, I doubt newlib works with avr-gcc. There is just one libc implementation
that cooperates with avr-gcc: avr-libc from
http://avr-libc.nongnu.org/

Note that avr-libc does not support in-tree builds, just set --host=avr
CC=/your/avr-gcc

[Bug target/47364] [x32] internal compiler error: in emit_move_insn, at expr.c:3355

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  2011-06-14 
16:32:01 UTC ---
Author: hjl
Date: Tue Jun 14 16:31:57 2011
New Revision: 175034

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175034
Log:
Properly expand strlen to Pmode.

2011-06-14  H.J. Lu  

PR middle-end/47364
* builtins.c (expand_builtin_strlen): Expand strlen to Pmode
and properly handle result not in Pmode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c

[Bug libfortran/49214] [4.7 Regression] Broken pipe in backtrace for x86_64-apple-darwin10

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Tobias Burnus  2011-06-14 
15:56:59 UTC ---
(In reply to comment #6)
> Can this PR be closed? The original issue seems to be fixed in comment 3 and
> the issue of comment 4 seems to be a bug in Darwin's libc implementation of
> backtrace_symbols_fd.

No objections raised - thus: Close as FIXED.

[Bug target/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-14 15:47:16 UTC ---
> --- Comment #14 from Richard Guenther  2011-06-12 
> 12:48:32 UTC ---
> A target issue as it only depends on the assembler used.  Rainer, as people
> don't have access to solaris as I guess you have to debug it and propose a 
> fix.
> I suspect some symout assembler hook gets in the way?

AFAICS, the code doesn't handle assemblers without weakref support
correctly.  So this will work with gas, but with nothing else.  I don't
really know what's necessary to avoid this issue, given that I haven't
really digged what weakrefs are and how to represent the same concept on
non-gas platforms.

Rainer

[Bug testsuite/49375] Target libstdc++.so used by host cc1plus

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-14 15:41:50 UTC ---
IMO this is a clear example why LD_LIBRARY_PATH is evil: the execution
tests in the testsuite should be linked with -R/-rpath/whatever is
required so the correct target libraries are found.  This has the
additional advantage that you can manually reexecute a failing tests
without first having to set LD_LIBRARY_PATH to all the directories
necessary to locate the runtime libraries.  I think some testsuites get
this right, with the exception of libgcc_s.so.1.

As a workaround, you could link cc1plus with libppl and libstdc++
statically.  At least this avoids all RPATH/LD_LIBRARY_PATH issues.
Certainly not pretty, but that's what I've been doing all the time and
what happens for go1 out of the box.  I always found the contortions
necessary to correctly link with libppl a nightmare, and it has only
improved a little bit recently.

Rainer

[Bug target/49402] Duplicate use of v850.opt

[nickc at redhat dot com]

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

--- Comment #2 from Nick Clifton  2011-06-14 15:32:49 
UTC ---
Fixed in mainline.

[Bug target/49403] v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’)

[nickc at redhat dot com]

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

--- Comment #2 from Nick Clifton  2011-06-14 15:32:13 
UTC ---
Fixed in mainline.

[Bug target/49403] v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’)

[nickc at gcc dot gnu.org]

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

--- Comment #1 from Nick Clifton  2011-06-14 15:30:15 
UTC ---
Author: nickc
Date: Tue Jun 14 15:30:05 2011
New Revision: 175030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175030
Log:
PR target/49403
* config/v850/v850.c (v850_memory_move_cost): Add reg_class_t parameter.

PR target/49402
* config.gcc(v850*-*-*): Avoid duplication of v850.opt.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/v850/v850.c

[Bug target/49402] Duplicate use of v850.opt

[nickc at gcc dot gnu.org]

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

--- Comment #1 from Nick Clifton  2011-06-14 15:30:15 
UTC ---
Author: nickc
Date: Tue Jun 14 15:30:05 2011
New Revision: 175030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175030
Log:
PR target/49403
* config/v850/v850.c (v850_memory_move_cost): Add reg_class_t parameter.

PR target/49402
* config.gcc(v850*-*-*): Avoid duplication of v850.opt.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/v850/v850.c

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2011-06-14 
15:28:27 UTC ---
Author: jakub
Date: Tue Jun 14 15:28:21 2011
New Revision: 175029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175029
Log:
PR fortran/49103
* tree.h (DECL_NONSHAREABLE): Define.
(struct tree_decl_common): Change decl_common_unused to
decl_nonshareable_flag.
* cfgexpand.c (expand_used_vars_for_block, clear_tree_used):
Ignore vars with DECL_NONSHAREABLE bit set.
* tree-cfg.c (gimple_duplicate_bb): Set DECL_NONSHAREABLE
on stores to automatic aggregate vars.

* gfortran.dg/pr49103.f90: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/pr49103.f90
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/cfgexpand.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-cfg.c
branches/gcc-4_6-branch/gcc/tree.h

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2011-06-14 
15:27:28 UTC ---
Author: jakub
Date: Tue Jun 14 15:27:24 2011
New Revision: 175028

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175028
Log:
PR fortran/49103
* tree.h (DECL_NONSHAREABLE): Define.
(struct tree_decl_common): Change decl_common_unused to
decl_nonshareable_flag.
* cfgexpand.c (expand_used_vars_for_block, clear_tree_used):
Ignore vars with DECL_NONSHAREABLE bit set.
* tree-cfg.c (gimple_duplicate_bb): Set DECL_NONSHAREABLE
on stores to automatic aggregate vars.

* gfortran.dg/pr49103.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr49103.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree.h

[Bug middle-end/45098] Missed induction variable optimization

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org 2011-06-14 15:05:29 UTC ---
Author: vries
Date: Tue Jun 14 15:05:26 2011
New Revision: 175025

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175025
Log:
2011-06-14  Tom de Vries  

PR target/45098
* gcc.target/arm/ivopts-3.c: New test.
* gcc.target/arm/ivopts-4.c: New test.
* gcc.target/arm/ivopts-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/ivopts-3.c
trunk/gcc/testsuite/gcc.target/arm/ivopts-4.c
trunk/gcc/testsuite/gcc.target/arm/ivopts-5.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-06-14 
15:01:15 UTC ---
Author: jakub
Date: Tue Jun 14 15:01:10 2011
New Revision: 175024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175024
Log:
PR rtl-optimization/49390
Revert:
2010-06-29  Bernd Schmidt  

* cse.c (exp_equiv_p): For MEMs, if for_gcse, only compare
MEM_ALIAS_SET.

* gcc.c-torture/execute/pr49390.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49390.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/cse.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49390] [4.6/4.7 Regression] GCSE miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-06-14 
14:59:55 UTC ---
Author: jakub
Date: Tue Jun 14 14:59:52 2011
New Revision: 175023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175023
Log:
PR rtl-optimization/49390
Revert:
2010-06-29  Bernd Schmidt  

* cse.c (exp_equiv_p): For MEMs, if for_gcse, only compare
MEM_ALIAS_SET.

* gcc.c-torture/execute/pr49390.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr49390.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/45098] Missed induction variable optimization

[vries at gcc dot gnu.org]

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

--- Comment #14 from vries at gcc dot gnu.org 2011-06-14 14:30:01 UTC ---
Author: vries
Date: Tue Jun 14 14:29:58 2011
New Revision: 175022

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175022
Log:
2011-06-14  Zdenek Dvorak  
Tom de Vries  

PR target/45098
* cfgloop.h (nb_iterations_upper_bound, nb_iterations_estimate):
Document changed semantics.
(max_stmt_executions, max_stmt_executions_int): Declare.
* tree-data-ref.c (estimated_loop_iterations)
(estimated_loop_iterations_int): Move functions...
* tree-ssa-loop-niter.c (estimated_loop_iterations)
(estimated_loop_iterations_int): here.
(record_estimate): Change nb_iterations_upper_bound and
nb_iterations_estimate semantics.
(max_stmt_executions, max_stmt_executions_int): New function.
* tree-data-ref.c (estimated_loop_iterations_tree): Rename to ...
(max_stmt_executions_tree): this.
(analyze_miv_subscript): Use max_stmt_executions_tree instead of
estimated_loop_iterations_tree.
tree-ssa-loop-ivopts.c (avg_loop_niter): Use
max_stmt_executions_int instead of estimated_loop_iterations_int.
* predict.c (predict_loops): Idem.
* tree-parloops.c (parallelize_loops): Idem.
* tree-data-ref.c (analyze_siv_subscript_cst_affine)
(compute_overlap_steps_for_affine_1_2, analyze_subscript_affine_affine)
(init_omega_for_ddr_1): Idem.
* tree-ssa-loop-prefetch.c (determine_loop_nest_reuse)
(loop_prefetch_arrays): Idem
* graphite-sese-to-poly.c (build_loop_iteration_domains): Use
max_stmt_executions instead of estimated_loop_iterations.
* tree-data-ref.c (estimated_loop_iterations_tree): Idem.
* tree-vrp.c (adjust_range_with_scev): Use estimated_loop_iterations
instead of nb_iterations_upper_bound.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.h
trunk/gcc/graphite-sese-to-poly.c
trunk/gcc/predict.c
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-parloops.c
trunk/gcc/tree-ssa-loop-ivopts.c
trunk/gcc/tree-ssa-loop-niter.c
trunk/gcc/tree-ssa-loop-prefetch.c
trunk/gcc/tree-vrp.c

[Bug c/49362] Arm Neon intrinsic types not correctly interpreted by compiler.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |4.7.0

[Bug libstdc++/48365] Non-constant references in std::valarray::operator

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis  changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu.org

--- Comment #5 from Gabriel Dos Reis  2011-06-14 
14:17:54 UTC ---
(In reply to comment #1)
> Gaby, can you have a look to this issue? It seems to me that in general, given
> the expression templates mechanism we have in place, something like
> 
>   k = k[0] * k,(1)
> 
> where k is a valarray, cannot possibly work as intuitively expected, because
> the multiplication is expanded "in place": operator= triggers the computation
> of the new k[0] and then k[1] which definitely uses the new k[0], contrary to
> intuition. Is this actually undefined behavior, like morally in
> 
>   operator*(const T& t, const valarray& v)
> 
> t cannot be an element of v? Seems something falling under the special 
> features
> of valarray wrt aliasing, but I don't see it mentioned anywhere in C++03.
> 
> Interestingly, if I change (1) to
> 
>   k *= k[0]
> 
> which should be in principle equivalent, the behavior is the same on GCC,
> whereas another implementation of valarray agrees with GCC in this case.

Yes, Paolo, you are right.  Valarray computations assume absence of 
certain form of aliasing, and this appears to be one of them.

[Bug libstdc++/48365] Non-constant references in std::valarray::operator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #4 from Paolo Carlini  2011-06-14 
14:10:48 UTC ---
Gaby, we should somehow resolve this one too...

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #26 from Paolo Carlini  2011-06-14 
14:02:15 UTC ---
... among other things, std::valarray, at variance with the containers, does
*not* have member begin and end, thus I don't even think novice programmers may
have expectations about that.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #25 from Gabriel Dos Reis  2011-06-14 
14:01:30 UTC ---
(In reply to comment #23)
> Ok, now I see, it's the operator[] of _BinBase which returns by value, I
> overlooked that. 

Yes, "val" in "valarray" stands for "value", e.g. a valarray
is a fundamentally a value, from a conceptual point of view; not an object.

Range-based "for" is fundamentally container-oriented in the
sense that it assumes that the container is an *object* that
resides in memory, and the iteration really visits each cell in
that object.  A valarray is a *value*, and each individual
value in that array may be produced by any mean, e.g. surrogates.

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[js-gcc at webkeks dot org]

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

--- Comment #22 from js-gcc at webkeks dot org  
2011-06-14 14:02:05 UTC ---
Nope, it's still using __builtin_apply.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[gdr at gcc dot gnu.org]

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

--- Comment #24 from Gabriel Dos Reis  2011-06-14 
13:54:13 UTC ---
(In reply to comment #18)

> It should be identical to
> 
> auto&& range = v1 + v2;
> for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
>   { ... }
> (see 6.5.4 [stmt.ranged])

This will not work with expression template-based implementation
of valarray.  The reason is that `range' may be a surrogate, and
you are likely to get rubbish addresses.

I urge people to drop range-based iteration on valarrays.
It wasn't something we were dieing for.  It grew out of
someone's idea of "uniformity" that failed to appreciate
that a valarray is not your usual container.

- Gaby

[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-14 13:53:56 UTC ---
objc.dg/torture/forward-1.m now seems to XPASS (almost?) everywhere with
-fgnu-runtime:

alpha-dec-osf5.1b
i386-pc-solaris2.1[01] -m64
mips-sgi-irix6.5
sparc-sun-solaris2*

Could it be that this PR has now been fixed by the libobjc API rework?
If so, the xfail should be removed.

Rainer

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini  2011-06-14 
13:50:56 UTC ---
Ok, now I see, it's the operator[] of _BinBase which returns by value, I
overlooked that. Thus, fine it seems confirmed that range-based for-loop itself
is Ok, but making sure we have return by const ref everywhere for _Expr seems
unmanageable.

Thus, again, confirmed that I agree with removing the overloads.

[Bug c/49362] Arm Neon intrinsic types not correctly interpreted by compiler.

[mark.pupilli at dyson dot com]

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

mark.pupilli at dyson dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from mark.pupilli at dyson dot com 2011-06-14 13:46:51 UTC ---
Ok, looks like the optimiser will be better in 4.7 as well. Thank you!

[Bug target/49404] New: ARM _Unwind_Backtrace returns _URC_FAILURE too eagerly

[akos.pasztory at gmail dot com]

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

   Summary: ARM _Unwind_Backtrace returns _URC_FAILURE too eagerly
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akos.paszt...@gmail.com
  Host: i686-pc-linux-gnu
Target: arm-none-linux-gnueabi


In the ARM implementation of _Unwind_Backtrace [1], if get_eit_entry() returns
_URC_END_OF_STACK, as it will when reaching a .cantunwind function (e.g.
_start), it is turned into _URC_FAILURE.  Thus, _Unwind_Backtrace will (almost
always?) return _URC_FAILURE, which is bad if someone relies on that return
value.

I wonder if the get_eit_entry() result should be just returned verbatim, if
it's not _URC_OK, something like:

if ((code = get_eit_entry (ucbp, saved_vrs.core.r[R_PC])) != _URC_OK)
  break;

[1]
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/unwind-arm.c;h=4a9e2325c39afca79d05148be46ff72663a8b5cd;hb=HEAD#l974

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[rth at gcc dot gnu.org]

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

--- Comment #21 from Richard Henderson  2011-06-14 
13:31:47 UTC ---
Author: rth
Date: Tue Jun 14 13:31:43 2011
New Revision: 175018

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175018
Log:
PR debug/48459
* dwarf2out.c (frame_pointer_fb_offset_valid): New.
(based_loc_descr): Assert it's true.
(compute_frame_pointer_to_fb_displacement): Set it, rather than
aborting immediately.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug c/49396] c-family/c-cppbuiltin.c: duplicate if expressions

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2011-06-14 13:23:09 UTC ---
On Tue, 14 Jun 2011, rguenth at gcc dot gnu.org wrote:

> I think it should be
> 
> Index: c-family/c-cppbuiltin.c
> ===
> --- c-family/c-cppbuiltin.c (revision 175011)
> +++ c-family/c-cppbuiltin.c (working copy)
> @@ -559,7 +559,7 @@ c_cpp_builtins_optimize_pragma (cpp_read
>cpp_undef (pfile, "__FINITE_MATH_ONLY__");
>cpp_define (pfile, "__FINITE_MATH_ONLY__=1");
>  }
> -  else if (!prev->x_flag_finite_math_only && cur->x_flag_finite_math_only)
> +  else if (prev->x_flag_finite_math_only && !cur->x_flag_finite_math_only)
>  {
>cpp_undef (pfile, "__FINITE_MATH_ONLY__");
>cpp_define (pfile, "__FINITE_MATH_ONLY__=0");

Looks right to me.

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #20 from Richard Henderson  2011-06-14 
13:23:53 UTC ---
(In reply to comment #19)
> > A full build for AVR fails, but that seems to be related to other
> > open bugs.
> 
> What bugs? 

Perhaps I shouldn't assume.

../../../../../../comb/newlib/libc/search/hash.c: In function ‘__expand_table’:
../../../../../../comb/newlib/libc/search/hash.c:898:1: error: unable to find a
register to spill in class ‘POINTER_REGS’
../../../../../../comb/newlib/libc/search/hash.c:898:1: error: this is the
insn:
(insn 190 97 191 10 (set (reg:QI 18 r18)
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 5 [0x5])) [14 S1 A8]))
../../../../../../comb/newlib/libc/search/hash.c:886 4 {*movqi}
 (nil))
../../../../../../comb/newlib/libc/search/hash.c:898:1: internal compiler
error: in spill_failure, at reload1.c:2113
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [lib_a-hash.o] Error 1
make[8]: Leaving directory
`/home/rth/work/gcc/bld-avr/avr-elf/avr25/newlib/libc/search'

I saw r28 in there and assumed it was the same problem with the
frame pointer as PR46779.

Anyway, I believe I've fixed the problem for #c0.  I'll commit it shortly.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini  2011-06-14 
13:27:03 UTC ---
To be clear: I fully agree with the exclusion sentence. But I had to play a bit
with this stuff to realize that really adding overloads to begin() and end()
cannot work.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini  2011-06-14 
13:23:29 UTC ---
Created attachment 24519
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24519
patch

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[paolo.carlini at oracle dot com]

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

--- Comment #20 from Paolo Carlini  2011-06-14 
13:22:13 UTC ---
I'm not sure, really. I'm going to attach a variant which more explicitly only
uses return by const ref and shows the same fundamental problem for me.

[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  2011-06-14 
13:07:07 UTC ---
(Comment fixed 8 fixed the missing deep copy.)

Regarding the reallocate (cf. comment 6, but using scalars to reduce the dump
size): For
  type t
integer, allocatable :: A
  end type t
  type(t), allocatable :: z
...
  z = [ x ]

One gets the following dump:

/* If not initialized. For arrays: Also realloc, if the size is wrong.  */
if (z != 0B) goto L.1;
z = (struct t *) __builtin_malloc (8);

So far so good, but one then has

D.1552 = *z;
if (D.1552.a != 0B)
__builtin_free ((void *) D.1552.a);

which is only OK if "z.data" has neither been just allocated nor reallocated.
If it has, there are two problems: (a) The old memory is not freed. (b) if
malloc/realloc does not return nullified memory, free() operates on some random
pointer.

The question is how to handle it best? The assignment is handled in
gfc_trans_assignment_1, which calls gfc_alloc_allocatable_for_assignment for
the realloc and gfc_trans_scalar_assign for the assignment.

[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  2011-06-14 
13:01:24 UTC ---
Ah, no the problem is std::__addressof(__ex()[0]) which takes the
address of a temporary returned by operator[]

The range-based for seems to do the right thing