[Bug c++/45437] Loses reference during update

[phorgan1 at gmail dot com]

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

Patrick Horgan  changed:

   What|Removed |Added

 CC||phorgan1 at gmail dot com

--- Comment #16 from Patrick Horgan  2011-03-23 
07:03:09 UTC ---
Confirming that this is still occurring in gcc (GCC) 4.6.0 20110113
(experimental) where this code:

int
main()
{
bool b1, b2, b3;
b1 = b2 = b3 = true;
b1 |= b2 |= b1 |=b3;
}

results in the error message:

testit.cpp:10:24: warning: operation on ‘b1’ may be undefined
[-Wsequence-point]

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[michael.haubenwallner at salomon dot at]

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

--- Comment #11 from Michael Haubenwallner  2011-03-23 07:46:49 UTC ---
(In reply to comment #10)
> IZ81343 (or one of its sister APARs) fixes the original issue.  But, it leaves
> a new issue.  The new error looks like:

Perry, have you seen this on AIX 5.3 or 6.1 ?

[Bug c++/48196] [C++0x] ICE on inclusion of , decltype

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2011-03-23 
08:43:48 UTC ---
Can you try either current mainline or 4_6-branch (would be 4.6.0), because
quite a few fixes went into those and if the issue isn't a regression and
affects only older branches is very unlikely to be fixed.

[Bug preprocessor/48248] New: Wrong error message location when compiling preprocessed code

[joerg.rich...@pdv-fs.de]

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

   Summary: Wrong error message location when compiling
preprocessed code
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de


$ cat > foobar.h << EOF
enum Foo
{
  BAR
};
#define BAR(x) 
#define BARBAR BAR
EOF

$ cat > main.cc << EOF
#include "foobar.h"



void func()
{
  (void)BARBAR;
  aaa;
}
EOF

$ g++ -c main.cc
main.cc: In function 'void func()':
main.cc:8:3: error: 'aaa' was not declared in this scope

$ g++ -E main.cc > main.ii
$ g++ -c main.ii
foobar.h: In function 'void func()':
foobar.h:8:3: error: 'aaa' was not declared in this scope

Please notice the wrong filename when compiling the preprocessed source.

GCC 4.4 doesn't have this problem.

[Bug c++/48247] Options -std=gnu++0x -pedantic -Werror produce [-Werror=edantic]

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jonathan Wakely  2011-03-23 
09:04:48 UTC ---
dup

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

[Bug c/44774] -Werror=edantic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||Denis.Excoffier at airbus
   ||dot com

--- Comment #13 from Jonathan Wakely  2011-03-23 
09:04:48 UTC ---
*** Bug 48247 has been marked as a duplicate of this bug. ***

[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.23 09:26:39
 CC||iains at gcc dot gnu.org,
   ||mrs at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Iain Sandoe  2011-03-23 09:26:39 
UTC ---
confirmed

for O1 :

Apparently, we have concluded that the indirect references are not required
when there is a 0 offset for the var.   When the offset is non-zero (v.b, v.c,
v.d), we correctly construct the indirect ref.  

for O0, all the references are correctly formed (and there is a corresponding
L_w$non_lazy_ptr).

---

.text
.align2
.globl _foo
_foo:
stw r31,-4(r1);,
mflr r0;,
bcl 20,31,L001$pb;
L001$pb:;
mflr r31;,
mtlr r0;,
addis r2,r31,ha16(_v-L001$pb);,,
la r10,lo16(_v-L001$pb)(r2);,,
addis r2,r31,ha16(_w-L001$pb);,,
la r11,lo16(_w-L001$pb)(r2);,,
addis r2,r31,ha16(L_v$non_lazy_ptr-L001$pb);,,
lwz r2,lo16(L_v$non_lazy_ptr-L001$pb)(r2);,,
addis r8,r31,ha16(L_v$non_lazy_ptr-L001$pb);,,
lwz r8,lo16(L_v$non_lazy_ptr-L001$pb)(r8);,,
addis r9,r31,ha16(L_v$non_lazy_ptr-L001$pb);,,
lwz r9,lo16(L_v$non_lazy_ptr-L001$pb)(r9);,,
; 12
"/Volumes/ScratchCS/gcc-live-trunk/gcc/testsuite/gcc.c-torture/compile/pr44707.c"
1
/* 0(r10) 0(r11) 4(r2) 8(r8) 12(r9) */; v.a, w, v.b, v.c, v.d
; 0 "" 2
lwz r31,-4(r1);,
blr;
.non_lazy_symbol_pointer
L_v$non_lazy_ptr:
.indirect_symbol _v
.long0
.subsections_via_symbols

[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer

[dodji at gcc dot gnu.org]

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

--- Comment #1 from Dodji Seketeli  2011-03-23 
09:31:08 UTC ---
I am not sure to understand why the DW_TAG_type_unit DIE should have a
DW_AT_producer attribute.  From the DWARF-4 specification, I can't see
DW_AT_producer listed as a possible attribute of the DW_TAG_type_unit
DIE. AIUI, the DW_AT_producer attribute is meant to be hung off of
DW_AT_compile_unit and DW_AT_partial_unit.  I guess I am missing
something ...

[Bug c++/48224] ERROR: compile in g++ version 4.5

[evgenij.fokin at gmail dot com]

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

--- Comment #7 from Evgenij  2011-03-23 
09:35:29 UTC ---
Jonathan, I disagree with you.

(In reply to comment #2)
> The C++ standard library says the effects are undefined if an incomplete type
> is used as a template argument when instantiating a template component
> (17.4.3.6p2)

Yes, but instantiation made in cxx file where all types completed.

In any case workaround have been found. Thank you, Andrew.

[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.23 09:41:27
 CC||tromey at gcc dot gnu.org
   Target Milestone|--- |4.5.3
Summary|Wrong error message |[4.5/4.6/4.7 Regression]
   |location when compiling |Wrong error message
   |preprocessed code   |location when compiling
   ||preprocessed code
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-23 
09:41:27 UTC ---
Confirmed.

> g++-4.5 -S foo.c -save-temps
foobar.h: In function ‘void func()’:
foobar.h:8:3: error: ‘aaa’ was not declared in this scope

and preprocessed source looks like

# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"
# 1 "foobar.h" 1
enum Foo
{
BAR
};
# 2 "foo.c" 2



void func()
{
  (void)
# 6 "foobar.h"
   BAR
  ;
  aaa;
}

we miss to switch back to foo.c.  4.4 does not switch to foobar.h at all.

[Bug target/47553] ARM neon vld1q_lane_u8 & co. don't accept lanes >= 8

[rsandifo at gcc dot gnu.org]

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
2011-03-23 09:57:50 UTC ---
Author: rsandifo
Date: Wed Mar 23 09:57:26 2011
New Revision: 171344

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171344
Log:
gcc/
PR target/47553
* config/arm/predicates.md (neon_lane_number): Accept 0..15.

gcc/testsuite/
PR target/47553
* gcc.target/arm/neon-vld-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/neon-vld-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug lto/48246] ICE in lto_wpa_write_files

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.23 10:00:36
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-23 
10:00:36 UTC ---
Confirmed.

An intermediate partition is completely empty (ltrans_partitions[2], after
lto_balanced_map (), out of 7 partitions in total).  Sorting moves that
empty partition last.

We do seem to allow a single empty partition (probably for an empty CU):

  gcc_assert (cgraph_node_set_nonempty_p (set)
  || varpool_node_set_nonempty_p (vset) || !i);

so we could change !i for i == n_sets-1, but I suppose we could arrive
with multiple empty partitions here as well.

Honza, why do we even care to assert the above if we handle empty
partitions just fine (in case of !i)?  It looks like some partitioning
sanity check to me, not something we should assert on.

[Bug regression/48249] New: gcc-4.6: __builtin___memmove_chk wrong results

[holger.hopp at sap dot com]

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

   Summary: gcc-4.6: __builtin___memmove_chk wrong results
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


__builtin___memmove_chk produces wrong results if src and dest are
overlapping (gcc-4.6 rev. 171299 and trunk):

this is already wrong (source mm.c):

typedef long unsigned int size_t;

extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) void *
__attribute__ ((__nothrow__)) memmove (void *__restrict __dest, __const void
*__restrict __src, size_t __len)
{
  return __builtin___memmove_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}

void memmove2 (void *dest, const void *src, size_t n)
{
  memmove (dest, src, n);
}


correct test program that triggers wrong results (source m.c):

#include 
#include 

void memmove2 (void *dest, const void *src, size_t n);

int main()
{
  char s[50];
  strcpy (s, "abcdefghijklmnop");
  memmove2 (s+2, s, 14);
  printf ("%s\n", s);
  return 0;
}


reproduce (linux, x86_64):

$ gcc-4.6 -O2 -c mm.c -o mm46.o
$ gcc-4.5 -O2 -c mm.c -o mm45.o

gcc-4.6 is wrong:
$ gcc-4.6 m.c mm46.o && ./a.out
abababefefijklmn

gcc-4.5 produces correct result:
$ gcc-4.6 m.c mm45.o && ./a.out
ababcdefghijklmn

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto

--- Comment #8 from Richard Guenther  2011-03-23 
10:06:17 UTC ---
(In reply to comment #7)
> Well, upping it only workarounds the problem and you loose parallelizm linking
> small files.  I did bit of tunning on this compiling one of spec2k benchmarks
> (twolf?) to get smallest time with the cpus I had (4 if I remember)

Well ... I suppose this also heavily depends on your I/O speed.  Nevetheless
the number _looks_ awfully low compared to those others.

[Bug regression/48249] gcc-4.6: __builtin___memmove_chk wrong results

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-03-23 
10:12:27 UTC ---
This is a bug in glibc that has been fixed (the restrict qualification on
the wrapper is obviously wrong).

[Bug target/48239] ARM Thumb: Undefined reference to `__aeabi_lmul'

[sebastian.hu...@embedded-brains.de]

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

Sebastian Huber  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Sebastian Huber  
2011-03-23 10:14:01 UTC ---
Sorry for the noise, I had to update the "gcc/config.gcc" with a new line

tm_file="$tm_file ../../libgcc/config/arm/bpabi-lib.h"

in the RTEMS specific ARM part.

[Bug target/47553] ARM neon vld1q_lane_u8 & co. don't accept lanes >= 8

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
2011-03-23 10:17:13 UTC ---
Fixed on trunk.  Will backport to 4.6.1 and 4.5 once 4.6.0 is released.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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

Dr. David Kirkby  changed:

   What|Removed |Added

 CC||david.kirkby at onetel dot
   ||net

--- Comment #12 from Dr. David Kirkby  
2011-03-23 10:34:54 UTC ---
I'm seeing this error on AIX 5.3. Two GNU projects effected by this are 
 * GNU patch
 * GSL (GNU Scientific library)

In the case of the former, if one configures with CFLAGS =-g0, so not to
include debugging information, the problem goes away. So when one compiles GNU
patch like this I see:

gcc -c  -DHAVE_CONFIG_H -Ded_PROGRAM=\"/usr/bin/ed\" -I. -I. -g0 quotesys.c


But the GSL Scientific library can't be compiled this way, as the users's -g0
gets in before the -g added by GSL, so one see something like:

gcc -g0 -g foo.c

which means the debugging information is still present.

[Bug c++/48224] ERROR: compile in g++ version 4.5

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-03-23 
10:37:40 UTC ---
(In reply to comment #7)
> Jonathan, I disagree with you.

You're welcome to disagree, but you're wrong ;)

In your original example the compiler tells you where the template is
instantiated:
compileError.hxx:11:62:   instantiated from here

At that point the type is incomplete.

The example in comment 3 is also undefined, but compiles anyway. That doesn't
make it correct. As I said, undefined means it might work, it might not, you
can't rely on any specific behaviour.

Compiling with -D_GLIBCXX_CONCEPT_CHECKS turns on C++03 concept checking, which
tells you the problem: the concept checks fail for the code in comment 3
because the incomplete type does not meet the requirements of Assignable types
(required by 23.1p3 [lib.containers.requirements] in C++03).  Without concept
checks it compiles OK because you don't do an assignment.  In your original
example you do an assignment on line 11, which is the point of instantiation
that requires 'structure' to be complete.

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 10:58:36 UTC ---
> Before revision 171039 the test was unsupported:
>
> UNSUPPORTED: /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/pr46940_0.c
>
> because the test for 'check_linker_plugin_available' in
> /opt/gcc/p_work/gcc/testsuite/lib/target-supports.exp returned
>
> gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
>
> while following revision 171039 the same test compiles and executes without
> error.

Which linker do you use, and what's the value of HAVE_LTO_PLUGIN in
gcc/auto-host.h?  Could you check the gcc/config.log snippet for the
linker plugin support test.

If, as I assume, you're using the Darwin linker, HAVE_LTO_PLUGIN should
be 0 and you should get the following error for the linker_plugin test:

gcc: error: -fuse-linker-plugin is not supported in this configuration

Rainer

[Bug target/48250] New: ICE in reload_cse_simplify_operands, at postreload.c:403

[ams at gcc dot gnu.org]

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

   Summary: ICE in reload_cse_simplify_operands, at
postreload.c:403
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gcc.gnu.org


Created attachment 23755
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23755
Reduced testcase.

Using a trunk (svn 171251) compiler, configured for ARMv7-a, I get the
following ICE:

gcc -marm -mfpu=neon -O2 -c lp723185.i 

lp723185.i: In function 'foo':
lp723185.i:29:1: error: insn does not satisfy its constraints:
(insn 30 79 31 5 (set (mem/s:DI (plus:SI (reg:SI 3 r3)
(const_int -3 [0xfffd])) [4 unaligned_S_6->u64+0 S8
A64])
(reg:DI 4 r4 [146])) lp723185.i:25 626 {*arm_movdi_vfp}
 (nil))
lp723185.i:29:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


It's possible that this is the same as bug #42949, but I'm not qualified to
judge.

[Bug c++/48224] ERROR: compile in g++ version 4.5

[evgenij.fokin at gmail dot com]

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

--- Comment #9 from Evgenij  2011-03-23 
11:09:25 UTC ---
(In reply to comment #8)
> You're welcome to disagree, but you're wrong ;)

The man who never made a mistake, never made anything :)

Thank you for your quick response.

[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer

[dodji at gcc dot gnu.org]

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

--- Comment #2 from Dodji Seketeli  2011-03-23 
11:28:28 UTC ---
This is a very lightly tested patch to add the DW_AT_producer
attribute to the DW_TAG_type_unit DIE.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f62bb48..ff1adc3 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -6498,6 +6498,7 @@ static inline int local_scope_p (dw_die_ref);
 static inline int class_scope_p (dw_die_ref);
 static inline int class_or_namespace_scope_p (dw_die_ref);
 static void add_type_attribute (dw_die_ref, tree, int, int, dw_die_ref);
+static void add_producer_attribute (dw_die_ref);
 static void add_calling_convention_attribute (dw_die_ref, tree);
 static const char *type_tag (const_tree);
 static tree member_declared_type (const_tree);
@@ -10298,6 +10299,13 @@ break_out_comdat_types (dw_die_ref die)
 unit = new_die (DW_TAG_type_unit, NULL, NULL);
 add_AT_unsigned (unit, DW_AT_language,
  get_AT_unsigned (comp_unit_die (), DW_AT_language));
+
+/* Add a DW_AT_producer attribute.  This is not mandated by
+   the DWARF-4 specification.  But it appears that GDB needs
+   it for cases where different DW_TAG_type_unit DIEs might
+   be emitted by different compilers.  */
+add_producer_attribute (unit);
+
 type_node = ggc_alloc_cleared_comdat_type_node ();
 type_node->root_die = unit;
 type_node->next = comdat_type_list;
@@ -18014,6 +18022,28 @@ add_type_attribute (dw_die_ref object_die, tree type,
int decl_const,
 add_AT_die_ref (object_die, DW_AT_type, type_die);
 }

+/* Add an DW_AT_producer attribute to a given DIE.  */
+
+static void
+add_producer_attribute (dw_die_ref die)
+{
+  char producer[250];
+  const char *language_string = lang_hooks.name;
+  
+   sprintf (producer, "%s %s", language_string, version_string);
+#ifdef MIPS_DEBUGGING_INFO
+  /* The MIPS/SGI compilers place the 'cc' command line options in the
producer
+ string.  The SGI debugger looks for -g, -g1, -g2, or -g3; if they do
+ not appear in the producer string, the debugger reaches the conclusion
+ that the object file is stripped and has no debugging information.
+ To get the MIPS/SGI debugger to believe that there is debugging
+ information in the object file, we add a -g to the producer string.  */
+  if (debug_info_level > DINFO_LEVEL_TERSE)
+strcat (producer, " -g");
+#endif
+  add_AT_string (die, DW_AT_producer, producer);
+}
+
 /* Given an object die, add the calling convention attribute for the
function call type.  */
 static void
@@ -20101,7 +20131,6 @@ static dw_die_ref
 gen_compile_unit_die (const char *filename)
 {
   dw_die_ref die;
-  char producer[250];
   const char *language_string = lang_hooks.name;
   int language;

@@ -20114,21 +20143,8 @@ gen_compile_unit_die (const char *filename)
   if (!IS_ABSOLUTE_PATH (filename) && filename[0] != '<')
 add_comp_dir_attribute (die);
 }
-
-  sprintf (producer, "%s %s", language_string, version_string);
-
-#ifdef MIPS_DEBUGGING_INFO
-  /* The MIPS/SGI compilers place the 'cc' command line options in the
producer
- string.  The SGI debugger looks for -g, -g1, -g2, or -g3; if they do
- not appear in the producer string, the debugger reaches the conclusion
- that the object file is stripped and has no debugging information.
- To get the MIPS/SGI debugger to believe that there is debugging
- information in the object file, we add a -g to the producer string.  */
-  if (debug_info_level > DINFO_LEVEL_TERSE)
-strcat (producer, " -g");
-#endif
-
-  add_AT_string (die, DW_AT_producer, producer);
+  
+  add_producer_attribute (die);

   /* If our producer is LTO try to figure out a common language to use
  from the global list of translation units.  */

[Bug testsuite/48251] New: guality_check hangs indefinitely on Tru64 UNIX

[ro at gcc dot gnu.org]

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

   Summary: guality_check hangs indefinitely on Tru64 UNIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: aol...@gcc.gnu.org
  Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
 Build: alpha-dec-osf5.1b


The guality_check in g++.dg/guality/guality.exp hangs indefinitely on Tru64
UNIX
V5.1B, hanging the whole testsuite run.  It seems to be a gdb issue, but still
occurs with CVS gdb.

Here's what happens when I use a simple looping test program as target of the
procedure used in guality.h:

> gdb -nx -nw --quiet 
(gdb) set height
Argument required (integer to set it to.).
(gdb) set height 0
(gdb) attach 216346
Attaching to process 216346
[New process 216346]
Retry #1:
Retry #2:
Retry #3:
Retry #4:
0x0001200010e0 in ?? ()
(gdb) set guality_attached = 1
No symbol table is loaded.  Use the "file" command.
(gdb) b 1
No symbol table is loaded.  Use the "file" command.

In g++.log, I find that the test is run with the regular timeout of 300
seconds,
but this has no effect for some reason.  Might be a bug in expect (5.38.2).

The guality_check test in gcc.dg/guality/guality.exp isn't affected for some
reason.

I'll disable the test on Tru64 UNIX until this is resolved.

This is somewhat related to PR testsuite/46529, but there the timeout does
work.

[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-03-23 11:56:09 UTC 
---
Author: ro
Date: Wed Mar 23 11:55:51 2011
New Revision: 171346

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171346
Log:
PR testsuite/48251
* g++.dg/guality/guality.exp: Disable on alpha*-dec-osf*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/guality/guality.exp

[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-03-23 
11:56:05 UTC ---
I think it is a bad idea to add DW_AT_producer to .debug_type units.  Making
each .debug_types addition 4 bytes longer is bad for debug info size, we might
have many thousands DW_TAG_type_units for each source.
I think you can safely use referring DW_TAG_compile_unit's DW_AT_producer for
your purposes.  While it is true that .debug_types sections in the end comes
from different *.o file and be produced by different compiler, it will be
referenced by the current CU only if it hashes the same, thus has the same
content (disregarding hash collisions, in which case you are in very bad
trouble, but you are in that very bad trouble no matter whether you just
want to make sure it was produced by the same or compatible producer - when
hash collision happens, it might refer to completely unrelated type).

[Bug c++/48196] [C++0x] ICE on inclusion of , decltype

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.0, 4.7.0
 Resolution||WORKSFORME

--- Comment #4 from Paolo Carlini  2011-03-23 
11:58:12 UTC ---
Indeed, I just checked and both mainline and 4_6-branch are fine. If you see
something different, please re-open.

[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.23 12:00:31
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1
  Known to fail||4.6.0, 4.7.0

--- Comment #2 from Rainer Orth  2011-03-23 12:00:31 UTC 
---
Worked around for now.

[Bug lto/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.23 12:15:19
 CC||dnovillo at google dot com,
   ||rguenther at suse dot de
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Rainer Orth  2011-03-23 12:15:19 UTC 
---
While I'm considering how to apply the prunes from lto.exp (lto_prune_warns) to
tests not yet using lto.exp, I've got a more fundamental question: what's the
point of trying to use visibility support on targets that don't support that
and
later pruning the resulting warning?  It seems far more sensible to me not to
try
this in the first place and thus avoid the resulting mess.

[Bug lto/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  
2011-03-23 12:20:39 UTC ---
On Wed, 23 Mar 2011, ro at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334
> 
> Rainer Orth  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2011.03.23 12:15:19
>  CC||dnovillo at google dot com,
>||rguenther at suse dot de
>Target Milestone|--- |4.7.0
>  Ever Confirmed|0   |1
> 
> --- Comment #1 from Rainer Orth  2011-03-23 12:15:19 
> UTC ---
> While I'm considering how to apply the prunes from lto.exp (lto_prune_warns) 
> to
> tests not yet using lto.exp, I've got a more fundamental question: what's the
> point of trying to use visibility support on targets that don't support that
> and
> later pruning the resulting warning?  It seems far more sensible to me not to
> try
> this in the first place and thus avoid the resulting mess.

Of course.

[Bug target/48252] New: problem with consecutive vzip, vuzp and vtrn

[johan.kristell at axis dot com]

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

   Summary: problem with consecutive vzip, vuzp and vtrn
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: johan.krist...@axis.com


Consecutive vzip, vuzp or vtrn intrinsic overwrite destination register.

Compiler:

gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/4.6/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.6/libexec/gcc/armv7l-unknown-linux-gnueabi/4.6.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabi
Configured with: ../gcc-4.6/configure --prefix=/usr/local/gcc/4.6
--enable-languages=c --with-arch=armv7-a --with-float=softfp
--with-fpu=vfpv3-d16
Thread model: posix
gcc version 4.6.0 20110323 (prerelease) (GCC) 


Test case:

#include 
#include 

int main(void)
{
uint8x8_t v1 = {1, 1, 1, 1, 1, 1, 1, 1};
uint8x8_t v2 = {2, 2, 2, 2, 2, 2, 2, 2};
uint8x8x2_t vd1, vd2;
union {uint8x8_t v; uint8_t buf[8];} d1, d2, d3, d4;
int i;

vd1 = vzip_u8(v1, vdup_n_u8(0));
vd2 = vzip_u8(v2, vdup_n_u8(0));

vst1_u8(d1.buf, vd1.val[0]);
vst1_u8(d2.buf, vd1.val[1]);
vst1_u8(d3.buf, vd2.val[0]);
vst1_u8(d4.buf, vd2.val[1]);

printf("  d1  d2  d3  d4\n");
for (i = 0; i < 8; i++) {
printf("%4d%4d%4d%4d\n",
d1.buf[i],
d2.buf[i],
d3.buf[i],
d4.buf[i]);
}

return 0;
}

-

Compile flags: -mfloat-abi=softfp -mfpu=neon -O2

Output:

  d1  d2  d3  d4
   1   1   2   1
   0   0   0   0
   1   1   2   1
   0   0   0   0
   1   1   2   1
   0   0   0   0
   1   1   2   1
   0   0   0   0

d4 is wrong.

[Bug debug/48253] New: [4.6/4.7 Regression] Further .debug_aranges issues

[jakub at gcc dot gnu.org]

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

   Summary: [4.6/4.7 Regression] Further .debug_aranges issues
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: tro...@gcc.gnu.org, jan.kratoch...@redhat.com


Created attachment 23756
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23756
aranges.c

As following testcases show, while PR48176 fixed some .debug_aranges related
regressions, with the addition of .text.startup and .text.exit sections we
still sometimes don't emit .debug_aranges covering all the code snippets for a
particular CU.

[Bug debug/48253] [4.6/4.7 Regression] Further .debug_aranges issues

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-03-23 
13:01:54 UTC ---
Created attachment 23757
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23757
aranges2.c

Another testcase, this one needs profile feedback (i.e. run compile/link
first with the options and -fprofile-generate, run, compile again with
-fprofile-use).

On this testcase we can see other bugs, e.g. DW_AT_ranges for f1
DW_TAG_subprogram is wrong, it covers twice the same range, once perhaps with a
few extra bytes of padding before it, and then not at all the cold part.

[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer

[jan.kratochvil at redhat dot com]

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

--- Comment #4 from Jan Kratochvil  
2011-03-23 13:07:02 UTC ---
(In reply to comment #3)
> I think it is a bad idea to add DW_AT_producer to .debug_type units.  Making
> each .debug_types addition 4 bytes longer is bad for debug info size, we might
> have many thousands DW_TAG_type_units for each source.
> I think you can safely use referring DW_TAG_compile_unit's DW_AT_producer for
> your purposes.  While it is true that .debug_types sections in the end comes
> from different *.o file and be produced by different compiler, it will be
> referenced by the current CU only if it hashes the same, thus has the same
> content (disregarding hash collisions, in which case you are in very bad
> trouble, but you are in that very bad trouble no matter whether you just
> want to make sure it was produced by the same or compatible producer - when
> hash collision happens, it might refer to completely unrelated type).

I guess there cannot be two struct/class definitions with different fields
accessibility accidentally matching each other due to ODR.

Still I believe DW_TAG_type_unit should have DW_AT_producer as it is a
standalone entity - but currently it is not.  I guess I have to implement your
described althorithm into GDB instead.  Dodji, thanks and sorry for the patch.

[Bug lto/48246] ICE in lto_wpa_write_files

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  2011-03-23 13:07:58 UTC 
---
> Honza, why do we even care to assert the above if we handle empty
> partitions just fine (in case of !i)?  It looks like some partitioning
> sanity check to me, not something we should assert on.
The reason was that empty partition imply overhead and there is no need for
that, so I would preffer partitioning algs to never create the empty parts
(there was various issues with partitioning that lead to them).
But for release branch, dropping the assert is just fine.

Honza

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #60 from Markus Trippelsdorf  
2011-03-23 13:10:50 UTC ---
Latest mozilla-central fails here:

make[5]: Entering directory
`/var/tmp/mozilla-central/moz-build-dir/js/src/shell'
js.cpp
c++ -o js.o -c  -I../../../dist/system_wrappers_js -include
/var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API
-DOSTYPE=\"Linux2.6\"
 -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I..
-I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include
-I../../../dist/include/ns
prpub  -I/usr/include/nspr-fPIC  -fno-rtti -fno-exceptions -Wall
-Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-vir
tual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros
-Werror=return-type -pedantic -Wno-long-long -march=native -fpermissive -flto=4
-fu
se-linker-plugin -fwhole-program -fno-strict-aliasing -pthread -pipe  -DNDEBUG
-DTRIMMED -g -O3   -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF
.deps/js.pp /var/tmp/mozilla-central/js/src/shell/js.cpp
jsworkers.cpp
c++ -o jsworkers.o -c  -I../../../dist/system_wrappers_js -include
/var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API
-DOSTYPE=\"Linux2.6\" -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I..
-I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include
-I../../../dist/include/nsprpub  -I/usr/include/nspr-fPIC  -fno-rtti
-fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native
-fpermissive -flto=4 -fuse-linker-plugin -fwhole-program -fno-strict-aliasing
-pthread -pipe  -DNDEBUG -DTRIMMED -g -O3   -DMOZILLA_CLIENT -include
../js-confdefs.h -MD -MF .deps/jsworkers.pp
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp
In file included from /var/tmp/mozilla-central/js/src/shell/js.cpp:97:0:
/var/tmp/mozilla-central/js/src/jsobjinlines.h: In member function ‘void
JSObject::setArrayLength(uint32)’:
/var/tmp/mozilla-central/js/src/jsobjinlines.h:316:24: warning: cast to pointer
from integer of different size [-Wint-to-pointer-cast]
/usr/bin/python2.7 /var/tmp/mozilla-central/js/src/config/pythonpath.py
-I../config /var/tmp/mozilla-central/js/src/config/expandlibs_exec.py --uselist
--  c++ -o js  -fno-rtti -fno-exceptions -Wall -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type
-pedantic -Wno-long-long -march=native -fpermissive -flto=4 -fuse-linker-plugin
-fwhole-program -fno-strict-aliasing -pthread -pipe  -DNDEBUG -DTRIMMED -g -O3 
js.o jsworkers.o   -lpthread
-Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory   -Wl,-rpath-link,/bin
-Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/lib 
-L../../../dist/bin -L../../../dist/lib -Wl,-R/usr/lib64 -L/usr/lib64 -lplds4
-lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a ../libjs_static.a -ldl
lto1: internal compiler error: in output_die, at dwarf2out.c:11355
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [/tmp/ccC5KSYt.ltrans18.ltrans.o] Error 1
make[6]: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: ld returned 1 exit status

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  2011-03-23 13:12:37 UTC 
---
> Well ... I suppose this also heavily depends on your I/O speed.  Nevetheless
> the number _looks_ awfully low compared to those others.
Well, totally minimizing compilation of small unit is not very worthwhile.  It
was from time I was
trying to stress whopr to get issues like this one soon.

It does not matter if we build application in 1/100th of second or 1/200th of
second and too much parallelizm could slow down build of many small binaries.
I guess we could shoot for resonable user response. UI guys thinks it is about
1/3rd of second, so I would not mind tuning number up until compilation on not
terribly high end system approximately gets to this time.

I don't think this is however terribly related to large unit sizes and inliner
stuff.

Honza

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #49 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 13:13:53 UTC ---
>> Could we please avoid this mess with SUPPORTS_WEAK and GTHREAD_USE_WEAK
>> and make configure define SUPPORTS_WEAKREF or something like this, since
>> this is what we are actually looking for?
>
> The point was to piggyback on the existing weakref support in
> libgfortran rather than reinvent the wheel, but yeah, it's a bit
> confusing.

... especially since SUPPORTS_WEAK is unused now outside of
intrinsics/system_clock.c.

> It seems that target backends expose macros with these same names, but
> they are not visible anymore when compiling libgfortran, hence the
> current hack trying to recreate them in libgfortran configuration. Or
> at least, that's the most plausible reason I came up with, I did not
> write that particular code nor do I claim any deep expertise in this
> matter.

Indeed: I suppose someone saw them in gcc/gthr*.h.  It seems like every
user of that file needs to recreate those definitions.  From what I can
see, libquadmath gets this wrong, e.g.: quadmath_weak.h has

#if SUPPORTS_WEAK

but this isn't defined anywhere ;-(  Terrible user interface, btw.

>> If we include alpha*-dec-osf* in the list of targets that don't support
>> weakrefs, things should start working again, but I'd prefer a patch where
>> you can actually read *and understand* what's going on here.
>
> Would it be possible to create some test using AC_LINK_IFELSE to check
> whether weakrefs are supported? That way we could get rid of the ugly

One should be able to use gcc/testsuite/gcc.dg/attr-weakref-1.c as
basis.

> blacklist for defining GTHREAD_USE_WEAK. In any case, IMHO that's the
> topic of a separate patch.

Indeed, and the only sensible (read: the autoconf way) approach if
feasible.

>> Apart from that, has anyone actually *measured* the overhead of simply
>> linking libgfortran with librt on Linux, rather than claiming that there
>> might be some?  It the overhead were acceptable or even neglegible, we
>> could avoid all this mess in the first place, link with -lrt if need be,
>> and be done with it.
>
> The overhead is application dependent, and while I suspect that it's
> negligible for most, it's not that far fetched to imagine an
> application where it could make a big difference. For instance, the
> seed of the RANDOM_NUMBER intrinsic is protected by a weakrefed mutex;
> thus it's easy to imagine a program that makes lots of RANDOM_NUMBER
> calls becoming a lot slower if every call results in an unecessary
> mutex lock/unlock.

Ok, though it would be useful to have some hard data on this to make an
informed decision.

>> Additionally, the usage model for the weakref seems questionable to
>> me: while the technique is well-known and common on ELF targets to
>> produce code that can work with or without libpthread linked into the
>> application (which is what users will actually do!), which user is
>> supposed to link his Fortran code with librt to get improved system
>> clock resolution?  I dare say that close to nobody will even think about
>> this.
>
> Probably not many. OTOH there are quite many who use OpenMP, and as
> enabling OpenMP implicitly links in librt, they get the better clock
> for free.

True, but those same users will be mightly confused if the clock
resolution suddenly drops without OpenMP ;-(

I wonder how we want to continue from here: adding alpha*-dec-osf* to
the host list in libgfortran/acinclude.m4 (GTHREAD_USE_WEAK) on top of
your patch allowed testing to finish successfully.  Should we go this
way or apply my workaround from the 4.6 branch to mainline until this is
all sorted out properly?

Thanks.
Rainer

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #10 from Rainer Orth  2011-03-23 13:23:20 
UTC ---
Unfortunately, while this works now with gas, it still fails with Sun as,
all Solaris versions, both SPARC and x86.

[Bug debug/48253] [4.6/4.7 Regression] Further .debug_aranges issues

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-03-23 
13:25:04 UTC ---
Created attachment 23758
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23758
gcc46-pr48253.patch

Untested fix.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #13 from Perry Smith  2011-03-23 13:26:10 
UTC ---
On Mar 23, 2011, at 2:47 AM, michael.haubenwallner at salomon dot at wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072
> 
> --- Comment #11 from Michael Haubenwallner  dot at> 2011-03-23 07:46:49 UTC ---
> (In reply to comment #10)
>> IZ81343 (or one of its sister APARs) fixes the original issue.  But, it 
>> leaves
>> a new issue.  The new error looks like:
> 
> Perry, have you seen this on AIX 5.3 or 6.1 ?

5.3 -- something.  I thought I put it in my update.  I can check when I get to
work.  Seems like it was tl10 but a later SP than others reported.

Does that help?

Perry

[Bug other/48254] New: documentation minor

[Denis.Excoffier at airbus dot com]

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

   Summary: documentation minor
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: denis.excoff...@airbus.com


Under GCC 4.6.0 RC 20110314:

Two items:
- consider replacement of "affective" by "effective"; this is under the
description of the option `-fipa-struct-reorg'
- option `-funroll-loops' should not be described twice (pages 108 and 122, if
we consider the PDF manual from http://gcc.gnu.org/onlinedocs/gcc/)

[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109

[cltang at gcc dot gnu.org]

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



--- Comment #3 from Chung-Lin Tang  2011-03-23 
14:48:38 UTC ---

Please disregard the above comments, I think this is an ARM backend problem

after all.

[Bug libmudflap/12310] [tree-ssa] libmudflap fails to build on mips-sgi-IRIX6.5

[fche at redhat dot com]

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



--- Comment #12 from Frank Ch. Eigler  2011-03-23 
14:52:34 UTC ---

testing, please ignore

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[dominiq at lps dot ens.fr]

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



--- Comment #2 from Dominique d'Humieres  2011-03-23 
14:56:37 UTC ---

> Which linker do you use, and what's the value of HAVE_LTO_PLUGIN in

> gcc/auto-host.h?  Could you check the gcc/config.log snippet for the

> linker plugin support test.

>

> If, as I assume, you're using the Darwin linker, HAVE_LTO_PLUGIN should

> be 0 and you should get the following error for the linker_plugin test:

>

> gcc: error: -fuse-linker-plugin is not supported in this configuration



The linker is



@(#)PROGRAM:ld  PROJECT:ld64-97.17

llvm version 2.9svn, from Apple Clang 1.7 (build 77)



on x86_64-apple-darwin10.7.0, and



@(#)PROGRAM:ld  PROJECT:ld64-85.2.1



on powerpc-apple-darwin9.



In gcc/auto-host.h I have



...

/* Define to the level of your linker's plugin support. */

#ifndef USED_FOR_TARGET

#define HAVE_LTO_PLUGIN 0

#endif

...



and in gcc/config.log



...

| #define LTOPLUGINSONAME "liblto_plugin.so"

...

configure:23133: checking linker plugin support

configure:23163: result: 0

...

gcc_cv_lto_plugin=0

...

enable_plugin='yes'

...

pluginlibs=''

...

#define LTOPLUGINSONAME "liblto_plugin.so"

...



I have grepped the different *.log files, but I did not see any



gcc: error: -fuse-linker-plugin is not supported in this configuration

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 15:05:17 UTC ---

> The linker is

>

> @(#)PROGRAM:ld  PROJECT:ld64-97.17

> llvm version 2.9svn, from Apple Clang 1.7 (build 77)

>

> on x86_64-apple-darwin10.7.0, and

>

> @(#)PROGRAM:ld  PROJECT:ld64-85.2.1

>

> on powerpc-apple-darwin9.



So both of them non-GNU and not supporting -plugin.



> In gcc/auto-host.h I have

>

> ...

> /* Define to the level of your linker's plugin support. */

> #ifndef USED_FOR_TARGET

> #define HAVE_LTO_PLUGIN 0

> #endif

> ...



As it should: vendor linker without plugin support.



> I have grepped the different *.log files, but I did not see any

>

> gcc: error: -fuse-linker-plugin is not supported in this configuration



This would only occur in gcc/testsuite/*/*.log, but of course with xgcc

or something as the command name.



What happens if you try to compile and link the test program from

check_linker_plugin_available with the new gcc?



$ cd gcc

$ cat > lpl.c

int main() { return 0; }

$ ./xgcc -B./ -flto -fuse-linker-plugin lpl.c



Rainer

[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|NEW

 AssignedTo|dodji at gcc dot gnu.org|unassigned at gcc dot

   ||gnu.org

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[dominiq at lps dot ens.fr]

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



--- Comment #4 from Dominique d'Humieres  2011-03-23 
15:28:31 UTC ---

> What happens if you try to compile and link the test program from

> check_linker_plugin_available with the new gcc?

>

> $ cd gcc

> $ cat > lpl.c

> int main() { return 0; }

> $ ./xgcc -B./ -flto -fuse-linker-plugin lpl.c



See



>Before revision 171039 the test was unsupported:

> ...

> because the test for 'check_linker_plugin_available' in

> /opt/gcc/p_work/gcc/testsuite/lib/target-supports.exp returned

>

> gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found

>

> while following revision 171039 the same test compiles and executes without

> error.



in comment #0.

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 15:38:08 UTC ---

I see what's going on now: Darwin (in gcc/config/darwin.h) is one of

only two targets (besides i386/djgpp.h) that override

LINK_COMMAND_SPEC.



I think darwin.h should use/honor LINK_PLUGIN_SPEC.  Can you try

inserting



LINK_PLUGIN_SPEC \



in LINK_COMMAND_SPEC_A just after



%(linker) \



as is done in gcc.c (LINK_COMMAND_SPEC) for other targets?



Thanks.

Rainer

[Bug c++/48255] New: default constructor with argument INT

[lisp2d at lisp2d dot net]

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



   Summary: default constructor with argument INT

   Product: gcc

   Version: 4.5.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: lis...@lisp2d.net





class A{

public:

};



A x; // OK

A y(1); //OK



I can't found that standard says: default constructor with argument INT.



By code protection I will write:



class A{

A(); // w/o definition

A(int); // w/o definition

public:

};



What to do?

[Bug target/48256] New: gcc4.4.5 internal compiler error: in change_address_1, at emit-rtl.c:1954

[moloned at gmail dot com]

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



   Summary: gcc4.4.5 internal compiler error: in change_address_1,

at emit-rtl.c:1954

   Product: gcc

   Version: 4.4.4

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: molo...@gmail.com





Created attachment 23759

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23759

FFTW generated source file which fails in compilation



I get an internal compiler error when attempting to compile FFTW code for ARM

NEON.  Details described below.



HW/SW setup

---

BeagleBoard xM (native compilation using gcc under ubuntu)

Ubuntu 10.10

GNU make 3.8.1

gcc (Ubuntu/Linaro 4.4.1-14ubuntu5) 4.4.5



FFTW codebase and setup

---

git clone git://gitorious.org/gsoc2010-fftw-neon gsoc2010-fftw-neon

cd gsoc2010-fftw-neon

make clean

sh bootstrap.sh 

CFLAGS="-O3 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp" ./configure

--prefix=/usr --enable-single --enable-shared --with-pic

--host=arm-none-linux-gnueabi --enable-armv7-cycle-counter --enable-neon 

make

cd kernel

cp cpy1d.c __cpy1d.c

cp cpy1d-neon.c cpy1d.c

cd ..

make



snippet from failing make (offending file attached)

---

/bin/bash ../../../libtool --tag=CC --mode=compile gcc -std=gnu99

-DHAVE_CONFIG_H -I. -I../../..  -I../../../kernel -I../../../dft

-I../../../dft/simd -I../../../simd  -mfpu=neon -O3 -pipe -mcpu=cortex-a8

-mfpu=neon -mfloat-abi=softfp  -MT n1fv_128.lo -MD -MP -MF .deps/n1fv_128.Tpo

-c -o n1fv_128.lo n1fv_128.c

libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../..

-I../../../kernel -I../../../dft -I../../../dft/simd -I../../../simd -mfpu=neon

-O3 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -MT n1fv_128.lo -MD -MP

-MF .deps/n1fv_128.Tpo -c n1fv_128.c  -fPIC -DPIC -o .libs/n1fv_128.o

n1fv_128.c: In function 'n1fv_128':

n1fv_128.c:3513: internal compiler error: in change_address_1, at

emit-rtl.c:1954

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

make[5]: *** [n1fv_128.lo] Error 1

[Bug debug/48204] [4.5/4.6/4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:115 with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |



--- Comment #2 from Jakub Jelinek  2011-03-23 
15:50:25 UTC ---

Created attachment 23760

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23760

gcc46-pr48204.patch



Untested fix.

[Bug c++/48255] default constructor with argument INT

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-03-23 
15:55:36 UTC ---
t.C:5:6: error: no matching function for call to ‘A::A(int)’
t.C:1:8: note: candidates are: A::A()
t.C:1:8: note: A::A(const A&)

your code example is rejected as it should.

[Bug c++/48255] default constructor with argument INT

[lisp2d at lisp2d dot net]

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



--- Comment #2 from Lisp2D  2011-03-23 16:15:14 UTC 
---

found silent conversion



class A have



explicit A(std::complexconst& x);

[Bug other/48254] documentation minor

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||documentation



--- Comment #1 from Jonathan Wakely  2011-03-23 
16:19:00 UTC ---

(In reply to comment #0)

> Under GCC 4.6.0 RC 20110314:

> 

> Two items:

> - consider replacement of "affective" by "effective"; this is under the

> description of the option `-fipa-struct-reorg'



Good catch, thanks



> - option `-funroll-loops' should not be described twice (pages 108 and 122, if

> we consider the PDF manual from http://gcc.gnu.org/onlinedocs/gcc/)



Hmm yes, it's at

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-funroll_002dloops-811

and

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-funroll_002dloops-864

so are -ftracer and -funroll-all-loops ... not sure if there's a reason for

that

[Bug c++/40793] "Error: no matching function for call to XYZ" doesn't display function-template-arguments

[jonathan.sd24 at yahoo dot de]

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

--- Comment #11 from Jonathan Schmidt-Dominé  
2011-03-23 16:29:31 UTC ---
Couldn't this patch be accepted? It looks very nice…

[Bug libstdc++/48257] New: std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[mohsinrzaidi at gmail dot com]

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



   Summary: std::string::assign() corrupts std::string static data

when called on emptyString1 using emptyString2.data()

   Product: gcc

   Version: 4.1.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mohsinrza...@gmail.com





The output of the following program is:

4

4



#include 

#include 



using namespace std;

int main()

{

try

{

string emptyStr1;

string emptyStr2;

string emptyStr3;



emptyStr3.assign(emptyStr2.data(), 4);



cout << emptyStr1.size() << endl;

cout << emptyStr3.size() << endl;

}

catch(...)

{

cout << "Reached here" << endl;

}

}



The size of emptyStr1/3 should not have been modified when emptyStr3 was

assigned the contents of emptyStr2 up to 4 bytes although all string are empty.



>From what I've understood of the basic_string code, the following code flow

will result in this case:







  template

inline basic_string<_CharT, _Traits, _Alloc>::

basic_string()

#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING

: _M_dataplus(_S_empty_rep()._M_refdata(), _Alloc()) { }

#else

: _M_dataplus(_S_construct(size_type(), _CharT(), _Alloc()), _Alloc()) { }

#endif







First, the default constructor. Since I do not have

"_GLIBCXX_FULLY_DYNAMIC_STRING" defined in my implementation, _M_dataplus._M_p

will get initialized to &(_S_empty_rep_storage + sizeof (_Rep)) for all three

strings.







  const _CharT*

  data() const

  { return _M_data(); }











  _CharT*

  _M_data() const

  { return  _M_dataplus._M_p; }











  template

basic_string<_CharT, _Traits, _Alloc>&

basic_string<_CharT, _Traits, _Alloc>::

assign(const _CharT* __s, size_type __n)

{

  __glibcxx_requires_string_len(__s, __n);

  _M_check_length(this->size(), __n, "basic_string::assign");

  if (_M_disjunct(__s) || _M_rep()->_M_is_shared())

return _M_replace_safe(size_type(0), this->size(), __s, __n);

  else

{

  // Work in-place.

  const size_type __pos = __s - _M_data();

  if (__pos >= __n)

_M_copy(_M_data(), __s, __n);

  else if (__pos)

_M_move(_M_data(), __s, __n);

  _M_rep()->_M_set_length_and_sharable(__n);

  return *this;

}

 }







When assign is called using emptyStr2.data(), which returns the same value as

that set above for _M_dataplus._M_p, _M_disjunct() will return 0, as will

_M_is_shared() and we end up going into the else block.



Here, since __s = _M_dataplus._M_p, which is what _M_data() returns, __pos = 0

and so the only statements we end up executing are the last two in the else

block thereby setting the length = 4 in the static storage returned by

_M_rep().



This results in the corruption of static storage used by all std::string

objects.



Does that make sense?



==

Using built-in specs.

Target: x86_64-redhat-linux

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man

--infodir=/usr/share/info --enable-shared --enable-threads=posix

--enable-checking=release --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-libgcj-multifile

--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk

--disable-dssi --enable-plugin

--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic

--host=x86_64-redhat-linux

Thread model: posix

gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||howarth at nitro dot

   ||med.uc.edu, iains at gcc

   ||dot gnu.org, mrs at gcc dot

   ||gnu.org



--- Comment #6 from Dominique d'Humieres  2011-03-23 
16:43:42 UTC ---

> I see what's going on now: Darwin (in gcc/config/darwin.h) is one of

> only two targets (besides i386/djgpp.h) that override

> LINK_COMMAND_SPEC.

>

> I think darwin.h should use/honor LINK_PLUGIN_SPEC.  Can you try

> inserting

>

>LINK_PLUGIN_SPEC \

>

> in LINK_COMMAND_SPEC_A just after

> 

> %(linker) \

> 

> as is done in gcc.c (LINK_COMMAND_SPEC) for other targets?



I'll do the check ASAP (CC Iain Sandoe, Mike Stump, and Jack Howarth).

Meanwhile the following patch skips the test:



--- /opt/gcc/_clean/gcc/testsuite/gcc.dg/lto/pr46940_0.c2010-12-16

08:01:29.0 +0100

+++ /opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr46940_0.c2011-03-23

17:17:07.0 +0100

@@ -1,4 +1,5 @@

 /* { dg-require-linker-plugin "" } */

+/* { dg-require-alias "" } */

 /* { dg-extra-ld-options "-fuse-linker-plugin" } */

 #include 

[Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2011-03-23 
16:45:05 UTC ---

The aim of the extension is to allow correct debug info, not almost correct, so

I think defining "upon entering of the current subprogram" as anything but

before the first insn in it is wrong and would make it not possible to use

DW_OP_GNU_entry_value before the point (end of prologue or what?).

Consider e.g. shrink-wrapping Bernd just proposed for GCC too...

So I think what we currently do on SPARC has to change.



As for teaching var-tracking about save/restore on SPARC, it would be a matter

of adding probably two target hooks, one that would be run e.g. at the end of

adjust_insn and would be supposed to change it using validate_change (...,

true); in whatever way var-tracking should understand the insn.

So e.g. for save you'd add into the parallel things like:

  (set (reg:P 24) (reg:P 8))

  (clobber (reg:P 8))

and similarly for all the other param regs.  Perhaps even make it explicit what

exactly is subtracted from %sp.

And the second target hook would return a different rtx for DECL_INCOMING_RTL,

with registers adjusted back.  Because for -O0 if we don't do var-tracking we

probably want DECL_INCOMING_RTL to still refer to %i0 etc., even when it is not

correct before the save.

[Bug target/48258] New: Add VSX support for float/double vector reductions & improve float insert/extract

[meissner at gcc dot gnu.org]

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



   Summary: Add VSX support for float/double vector reductions &

improve float insert/extract

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: target

AssignedTo: meiss...@gcc.gnu.org

ReportedBy: meiss...@gcc.gnu.org

  Host: powerpc64-linux

Target: powerpc64-linux

 Build: powerpc64-linux





Right now, the powerpc compiler does not do support for float and double vector

reductions.  For float in particular, the compiler does the code, and then

stores the vector in the stack to extract the bottom element.  With VSX it is

possible to do vector reductions in fewer instructions and to eliminate the

store.

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Jonathan Wakely  2011-03-23 
16:59:31 UTC ---

this is undefined behaviour, the standard requires that emptyStr2.data() points

to an array of at least 4 chars

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[iains at gcc dot gnu.org]

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



Iain Sandoe  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2011.03.23 17:07:04

 Ever Confirmed|0   |1



--- Comment #7 from Iain Sandoe  2011-03-23 17:07:04 
UTC ---

I'll try this on *-darwin9 and a  darwin9-X-cris-elf

(I assume we need to clone all the logic to cater for cross compiler cases... )



maybe this is getting complex enough to warrant a spec of its own? (and then we

could avoid cloning it)



===



Index: gcc/config/darwin.h

===

--- gcc/config/darwin.h(revision 171353)

+++ gcc/config/darwin.h(working copy)

@@ -174,6 +174,38 @@ extern GTY(()) int darwin_ms_struct;

 #define CPP_SPEC "%{static:%{!dynamic:-D__STATIC__}}%{!static:-D__DYNAMIC__}"

\

 " %{pthread:-D_REENTRANT}"



+/* Conditional to test whether the LTO plugin is used or not.

+   FIXME: For slim LTO we will need to enable plugin unconditionally.  This

+   still cause problems with PLUGIN_LD != LD and when plugin is built but

+   not useable.  For GCC 4.6 we don't support slim LTO and thus we can enable

+   plugin only when LTO is enabled.  We still honor explicit

+   -fuse-linker-plugin if the linker used understands -plugin.  */

+

+/* The linker has some plugin support.  */

+#if HAVE_LTO_PLUGIN > 0

+/* The linker used has full plugin support, use LTO plugin by default.  */

+#if HAVE_LTO_PLUGIN == 2

+#define PLUGIN_COND "!fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin"

+#define PLUGIN_COND_CLOSE "}"

+#else

+/* The linker used has limited plugin support, use LTO plugin with explicit

+   -fuse-linker-plugin.  */

+#define PLUGIN_COND "fuse-linker-plugin"

+#define PLUGIN_COND_CLOSE ""

+#endif

+#define LINK_PLUGIN_SPEC \

+"%{"PLUGIN_COND": \

+-plugin %(linker_plugin_file) \

+-plugin-opt=%(lto_wrapper) \

+-plugin-opt=-fresolution=%u.res \

+%{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}}

\

+}"PLUGIN_COND_CLOSE

+#else

+/* The linker used doesn't support -plugin, reject -fuse-linker-plugin.  */

+#define LINK_PLUGIN_SPEC "%{fuse-linker-plugin:\

+%e-fuse-linker-plugin is not supported in this configuration}"

+#endif

+

 /* This is mostly a clone of the standard LINK_COMMAND_SPEC, plus

precomp, libtool, and fat build additions.



@@ -185,6 +217,7 @@ extern GTY(()) int darwin_ms_struct;

 #define LINK_COMMAND_SPEC_A \

"%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\

 %(linker) \

+" LINK_PLUGIN_SPEC " \

 %{flto*:%

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[dominiq at lps dot ens.fr]

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



--- Comment #8 from Dominique d'Humieres  2011-03-23 
17:08:59 UTC ---

With the change in comment #5, bootstrapping fails with



ld: file not found: LINK_PLUGIN_SPEC

collect2: ld returned 1 exit status

make[5]: *** [libgcc_s.dylib] Error 1

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 17:10:38 UTC ---

> maybe this is getting complex enough to warrant a spec of its own? (and then 
> we

> could avoid cloning it)



Why would you want to clone that?  LINK_PLUGIN_SPEC is defined in gcc.c

before it is used in LINK_COMMAND_SPEC, irrespective if the latter is

from gcc itself or from target headers.  Just use it as is.



The fact that Darwin uses a clone of LINK_COMMAND_SPEC instead of having

hooks in the generic one to to its stuff is a mistake, IMO.



Rainer

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[david.kirkby at onetel dot net]

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



--- Comment #14 from Dr. David Kirkby  
2011-03-23 17:11:42 UTC ---

Has anyone with an AIX support contract ever raised this issue with IBM? If so,

is there a publicly viewable location for this? 



If not, can someone do it. My own RS/6000 is an ancient thing I personally own,

and so I have no support contract at all. 



It seems to me it could be a gcc bug or a bug in the AIX assembler or linker. 



It would be interesting to try to replace the systems linker and assembler with

versions from unpatched 5.3 or 6.1. That might give some clues. 



I can see this issue raised on an IBM AIX forum



http://www.ibm.com/developerworks/forums/thread.jspa?threadID=348558



but don't know if its even being considered by IBM.

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 17:15:46 UTC ---

> --- Comment #8 from Dominique d'Humieres  
> 2011-03-23 17:08:59 UTC ---

> With the change in comment #5, bootstrapping fails with

>

> ld: file not found: LINK_PLUGIN_SPEC

> collect2: ld returned 1 exit status

> make[5]: *** [libgcc_s.dylib] Error 1



Iain is right: we need to turn this into a proper spec since

LINK_PLUGIN_SPEC isn't defined at the point darwin.h is included.



Rainer

[Bug c++/40793] "Error: no matching function for call to XYZ" doesn't display function-template-arguments

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez  2011-03-23 
17:17:37 UTC ---
(In reply to comment #11)
> Couldn't this patch be accepted? It looks very nice…

Unfortunately, I don't have enough free time to test this patch and submit it
properly. Even if I had some time in the future for GCC, there are other things
I would like to fix first. I am not even sure it is correct in the general
case. So Jonathan or anyone else, please feel free to take it through
contribution process: http://gcc.gnu.org/contribute.html

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[iains at gcc dot gnu.org]

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



--- Comment #11 from Iain Sandoe  2011-03-23 17:20:01 
UTC ---

(In reply to comment #9)

> > maybe this is getting complex enough to warrant a spec of its own? (and 
> > then we

> > could avoid cloning it)



> The fact that Darwin uses a clone of LINK_COMMAND_SPEC instead of having

> hooks in the generic one to to its stuff is a mistake, IMO.



any simplification of maintenance and shortening of darwin.h would suit me ;)

.. 



.. however this pre-dates my involvement and I don't know the reason it was

done... 

perhaps Mike can shed some light on it...

[Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets

[ebotcazou at gcc dot gnu.org]

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



--- Comment #4 from Eric Botcazou  2011-03-23 
17:33:54 UTC ---

> The aim of the extension is to allow correct debug info, not almost correct,

> so I think defining "upon entering of the current subprogram" as anything but

> before the first insn in it is wrong and would make it not possible to use

> DW_OP_GNU_entry_value before the point (end of prologue or what?).



Yes, end of the prologue.  I was under the impression that, with your alternate

scheme, the opposite situation would arise, i.e. it wouldn't be possible to use

DW_OP_GNU_entry_value after the end of the prologue.  Given how GDB works, this

sounded far less appealing than the current scheme.  Sorry if I misunderstood.



> As for teaching var-tracking about save/restore on SPARC, it would be a matter

> of adding probably two target hooks, one that would be run e.g. at the end of

> adjust_insn and would be supposed to change it using validate_change (...,

> true); in whatever way var-tracking should understand the insn.

> So e.g. for save you'd add into the parallel things like:

>   (set (reg:P 24) (reg:P 8))

>   (clobber (reg:P 8))

> and similarly for all the other param regs.  Perhaps even make it explicit

> what exactly is subtracted from %sp.

> And the second target hook would return a different rtx for DECL_INCOMING_RTL,

> with registers adjusted back.  Because for -O0 if we don't do var-tracking we

> probably want DECL_INCOMING_RTL to still refer to %i0 etc., even when it is

> not correct before the save.



I see, thanks for the explanation.

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[iains at gcc dot gnu.org]

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



--- Comment #12 from Iain Sandoe  2011-03-23 17:38:57 
UTC ---

(In reply to comment #10)

> > --- Comment #8 from Dominique d'Humieres  
> > 2011-03-23 17:08:59 UTC ---

> > With the change in comment #5, bootstrapping fails with

> >

> > ld: file not found: LINK_PLUGIN_SPEC

> > collect2: ld returned 1 exit status

> > make[5]: *** [libgcc_s.dylib] Error 1

> 

> Iain is right:



au contraire, I think Rainer is right... ;) ... Iain did not engage brain

sufficiently...



but one needs the " " around the insert spec - see below.



> we need to turn this into a proper spec since



that still might be a nice idea,

Iain



=





Index: gcc/config/darwin.h

===

--- gcc/config/darwin.h(revision 171353)

+++ gcc/config/darwin.h(working copy)

@@ -185,6 +185,7 @@ extern GTY(()) int darwin_ms_struct;

 #define LINK_COMMAND_SPEC_A \

"%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\

 %(linker) \

+" LINK_PLUGIN_SPEC " \

 %{flto*:%

[Bug target/48258] Add VSX support for float/double vector reductions & improve float insert/extract

[meissner at gcc dot gnu.org]

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



--- Comment #1 from Michael Meissner  2011-03-23 
17:45:20 UTC ---

Author: meissner

Date: Wed Mar 23 17:45:06 2011

New Revision: 171357



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

Log:

Add test cases for PR 48258



Added:

branches/ibm/power7-meissner/gcc/testsuite/gcc.target/powerpc/pr48258-1.c

branches/ibm/power7-meissner/gcc/testsuite/gcc.target/powerpc/pr48258-2.c

Modified:

branches/ibm/power7-meissner/gcc/ChangeLog.power7

branches/ibm/power7-meissner/gcc/testsuite/ChangeLog.power7

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 17:49:55 UTC ---

> au contraire, I think Rainer is right... ;) ... Iain did not engage brain

> sufficiently...



Me neither ;-)



> but one needs the " " around the insert spec - see below.



Of course, thanks for finding my snafu.



>> we need to turn this into a proper spec since

>

> that still might be a nice idea,



True, together with documenting this.  But for the moment, the simpler

fix would do, IMO.



Rainer

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[mrs at gcc dot gnu.org]

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



--- Comment #14 from mrs at gcc dot gnu.org  2011-03-23 
18:01:03 UTC ---

If you guys like the patch from #12, I'll approve it...  Looks reasonable to

me.

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[iains at gcc dot gnu.org]

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



--- Comment #15 from Iain Sandoe  2011-03-23 18:27:45 
UTC ---

(In reply to comment #14)

> If you guys like the patch from #12, I'll approve it...  Looks reasonable to

> me.



it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take

longer).



Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc

-B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c  -flto

-fuse-linker-plugin  -m32 -o linker_plugin26306.exe(timeout = 60)

xgcc: error: -fuse-linker-plugin is not supported in this configuration

compiler exited with status 1

output is:

xgcc: error: -fuse-linker-plugin is not supported in this configuration

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 18:41:57 UTC ---

> it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take

> longer).

>

> Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc

> -B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c  -flto

> -fuse-linker-plugin  -m32 -o linker_plugin26306.exe(timeout = 60)

> xgcc: error: -fuse-linker-plugin is not supported in this configuration

> compiler exited with status 1

> output is:

> xgcc: error: -fuse-linker-plugin is not supported in this configuration



But this is probably a different issue with correctly detecting

HAVE_LTO_PLUGIN in cross scenarios.



Why not fix the Darwin problem now and deal with the cross issue

separately?



Rainer

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[iains at gcc dot gnu.org]

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



--- Comment #17 from Iain Sandoe  2011-03-23 18:46:06 
UTC ---

(In reply to comment #16)

> > it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take

> > longer).

> >

> > Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc

> > -B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c  -flto

> > -fuse-linker-plugin  -m32 -o linker_plugin26306.exe(timeout = 60)

> > xgcc: error: -fuse-linker-plugin is not supported in this configuration

> > compiler exited with status 1

> > output is:

> > xgcc: error: -fuse-linker-plugin is not supported in this configuration



sorry, badly phrased - 



I should have said:



the message above is the (correct) output from *-darwin9 native bootstrapped -

the tests are unsupported as expected.



> Why not fix the Darwin problem now and deal with the cross issue

> separately?



I don't see why there should be a cross- issue - 

- but it will take a while longer before I can test it ;)

[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-23 18:52:16 UTC ---

> --- Comment #17 from Iain Sandoe  2011-03-23 
> 18:46:06 UTC ---

> (In reply to comment #16)

>> > it seems to the the Right Thing on *-darwin9 (cross-to-cris-elf will take

>> > longer).

>> >

>> > Executing on host: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/xgcc

>> > -B/Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/ linker_plugin26306.c  -flto

>> > -fuse-linker-plugin  -m32 -o linker_plugin26306.exe(timeout = 60)

>> > xgcc: error: -fuse-linker-plugin is not supported in this configuration

>> > compiler exited with status 1

>> > output is:

>> > xgcc: error: -fuse-linker-plugin is not supported in this configuration

>

> sorry, badly phrased - 

>

> I should have said:

>

> the message above is the (correct) output from *-darwin9 native bootstrapped -

> the tests are unsupported as expected.



I think it's time for me to call it a day ;-)  Didn't read right...



>> Why not fix the Darwin problem now and deal with the cross issue

>> separately?

>

> I don't see why there should be a cross- issue - 

> - but it will take a while longer before I can test it ;)



I'll have to look at cross (and canadian cross) setups in the future for

testsuite work, but would like to do this with my current native targets

involved (like i386-pc-solaris2.11 x sparc-sun-solaris2.11 x

mips-sgi-irix6.5 :-).  The problem is, IRIX doesn't work with gld right

so, so much for a cross toolchain.



Rainer

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[mohsinrzaidi at gmail dot com]

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



Mohsin  changed:



   What|Removed |Added



 Status|RESOLVED|UNCONFIRMED

 Resolution|INVALID |



--- Comment #2 from Mohsin  2011-03-23 19:09:31 
UTC ---

(In reply to comment #1)

> this is undefined behaviour, the standard requires that emptyStr2.data() 
> points

> to an array of at least 4 chars



Kindly point me to where this is stated in the standards. I have searched but

have not been able to find any information in this regard.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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



--- Comment #15 from Perry Smith  2011-03-23 19:31:18 
UTC ---

Let me try and recap.



The initial report was that 5.3 TL10 did *not* have the error.  I discovered

that 5.3 TL10 SP03 does.  See [1].



APAR IZ81343[2] and its sister APARs addresses this issue.  It is shipped (for

example) in 5.3 TL10 SP05 as IZ81339.



After you apply that APAR, you get a new issue where the linker now spews out:



ld: 0711-596 SEVERE ERROR: Object expand.o

An RLD for section 2 (.data) refers to symbol 852,

but the storage class of the symbol is not C_EXT or C_HIDEXT.



I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the

assembler APAR.  I tried two versions of GCC: 4.2.0 and 4.5.2.



IBM is aware of the issue (via me and others).  The last tidbit I have is that

it appears as if it is another assembler bug but that is not confirmed yet.  I

don't have a fix nor do I have an APAR number yet.



[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072#c7

[2] https://www-304.ibm.com/support/docview.wss?uid=isg1IZ81343

[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #3 from Jonathan Wakely  2011-03-23 
19:39:28 UTC ---

In C++03 see 21.3.5.3 [lib.string.assign] paragraph 6 where 

string::assign(const char* s, size_t n) is defined to return

assign( string(s, n) ) and that constructor:



Constructs an object of class basic_string and determines its initial string

value from the array of charT of length n whose first element is designated by

s, 



In C++0x the requirement is explicit, [string::assign] paragraph 8 says



Requires: s points to an array of at least n elements of charT.

[Bug lto/48259] New: Internal compiler errors in lto1

[d.g.gorbachev at gmail dot com]

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



   Summary: Internal compiler errors in lto1

   Product: gcc

   Version: 4.6.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d.g.gorbac...@gmail.com





I just experimented a bit with static libstdc++ compiled with -flto. GCC fails

with internal compiler errors when using it. (Linking with static libgcc

compiled with -flto also reveals a bug in the linker.)



Does it make sense to report such bugs? Or maybe these libraries are too

'special' and can't be expected to work this way?

[Bug lto/48259] Internal compiler errors in lto1

[d.g.gorbachev at gmail dot com]

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



--- Comment #1 from Dmitry Gorbachev  
2011-03-23 19:45:13 UTC ---

Created attachment 23761

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23761

testcase, based on libstdc++



GCC 4.6.0 and 4.7.0 with -flto -O2:

lto1: internal compiler error: in ipcp_iterate_stage, at ipa-cp.c:891



4.6.0 with -flto:

lto1: internal compiler error: in cgraph_mark_functions_to_output, at

cgraphunit.c:11



4.7.0 with -flto:

[...]

lto1: internal compiler error: failed to reclaim unneeded function

[Bug other/48179] Reference mismatch in documentation chapter 6

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2011-03-23 
19:52:18 UTC ---

Author: redi

Date: Wed Mar 23 19:52:13 2011

New Revision: 171359



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48179

PR other/48221

PR other/48234

* doc/extend.texi (Alignment): Move section to match order in TOC.

* doc/invoke.texi (i386 and x86-64 Windows Options): Likewise.

(Warning Options): Adjust -Wno-cpp summary and remove stray backslash.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/doc/extend.texi

trunk/gcc/doc/invoke.texi

[Bug other/48234] documentation bad sequence in toc

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2011-03-23 
19:52:19 UTC ---

Author: redi

Date: Wed Mar 23 19:52:13 2011

New Revision: 171359



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48179

PR other/48221

PR other/48234

* doc/extend.texi (Alignment): Move section to match order in TOC.

* doc/invoke.texi (i386 and x86-64 Windows Options): Likewise.

(Warning Options): Adjust -Wno-cpp summary and remove stray backslash.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/doc/extend.texi

trunk/gcc/doc/invoke.texi

[Bug other/48221] documentation for -Wno-cpp seems wrong

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2011-03-23 
19:52:19 UTC ---

Author: redi

Date: Wed Mar 23 19:52:13 2011

New Revision: 171359



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48179

PR other/48221

PR other/48234

* doc/extend.texi (Alignment): Move section to match order in TOC.

* doc/invoke.texi (i386 and x86-64 Windows Options): Likewise.

(Warning Options): Adjust -Wno-cpp summary and remove stray backslash.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/doc/extend.texi

trunk/gcc/doc/invoke.texi

[Bug c++/48196] [C++0x] ICE on inclusion of , decltype

[gcchelp.5.adept at 0sg dot net]

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

--- Comment #5 from Christian Schüler  
2011-03-23 20:00:55 UTC ---
Yes, 4.6. release candidate doesn't crash thanks

[Bug other/48221] documentation for -Wno-cpp seems wrong

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Target Milestone|--- |4.6.1



--- Comment #4 from Jonathan Wakely  2011-03-23 
20:26:40 UTC ---

fixed on trunk so far

[Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2011-03-23 
20:30:53 UTC ---

(In reply to comment #4)

> Yes, end of the prologue.  I was under the impression that, with your 
> alternate

> scheme, the opposite situation would arise, i.e. it wouldn't be possible to 
> use

> DW_OP_GNU_entry_value after the end of the prologue.  Given how GDB works, 
> this

> sounded far less appealing than the current scheme.  Sorry if I misunderstood.



If say reference to first parameter's original value is

DW_OP_GNU_entry_value 1  (i.e. %o0), then it will work just fine

anywhere in the function.  The debugger either looks up matching entry

for %o0 in DW_TAG_GNU_call_site, or a debugger could put a breakpoint on the

first insn in a function and remember the %o0 value there, then just use the

remembered value anywhere where DW_OP_GNU_entry_value appears.

And for SPARC, using %o0 is also much easier for the debugger, it doesn't have

to translate anything.



On IA-64 things are different because there it is mainly the call insn which

moves the register window, not some insn executed somewhere in function's

prologue.

[Bug driver/48260] New: Accept -arch as an alias for -m32/-m64 on darwin

[gcchelp.5.adept at 0sg dot net]

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

   Summary: Accept -arch as an alias for -m32/-m64 on darwin
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcchelp.5.ad...@0sg.net


If the GCC driver is supplied with '-arch i386' when invoked as linker on
intel-darwin, this should have the same effect as '-m32' (effectively an
alias). Conversely, if '-arch x86_64' is supplied, it should have the same
effect as '-m64'. No further support for the '-arch' switch is necessary.
Without this support, it is impossible to configure the latest GCC to be used
from within xcode. As a proof of concept, I have a patch working that achieves
this.

diff --recursive --normal -w gcc-4.6.0-RC-20110314/gcc/c-family/c.opt
gcc-4.6.0-RC-20110314-patched/gcc/c-family/c.opt
204c204
< C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path after %qs)
---
> Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path after 
> %qs)
diff --recursive --normal -w gcc-4.6.0-RC-20110314/gcc/config/darwin.opt
gcc-4.6.0-RC-20110314-patched/gcc/config/darwin.opt
33a34,36
> arch
> Driver RejectNegative Separate 
> 
diff --recursive --normal -w gcc-4.6.0-RC-20110314/gcc/config/i386/darwin.h
gcc-4.6.0-RC-20110314-patched/gcc/config/i386/darwin.h
120c120
< #define DARWIN_ARCH_SPEC "%{m64:x86_64;:i386}"
---
> #define DARWIN_ARCH_SPEC "%{m64:x86_64;arch*:%*;:i386}"
diff --recursive --normal -w gcc-4.6.0-RC-20110314/gcc/config/i386/darwin64.h
gcc-4.6.0-RC-20110314-patched/gcc/config/i386/darwin64.h
25c25
< #define DARWIN_ARCH_SPEC "%{m32:i386;:x86_64}"
---
> #define DARWIN_ARCH_SPEC "%{m32:i386;arch*:%*;:x86_64}"
diff --recursive --normal -w gcc-4.6.0-RC-20110314/gcc/config/i386/t-darwin
gcc-4.6.0-RC-20110314-patched/gcc/config/i386/t-darwin
2a3
> MULTILIB_MATCHES = "m64=arch+x86_64" 
diff --recursive --normal -w gcc-4.6.0-RC-20110314/gcc/config/i386/t-darwin64
gcc-4.6.0-RC-20110314-patched/gcc/config/i386/t-darwin64
5a6
> MULTILIB_MATCHES = "m32=arch+i386" 
diff --recursive --normal -w gcc-4.6.0-RC-20110314/gcc/gcc.c
gcc-4.6.0-RC-20110314-patched/gcc/gcc.c
7106a7107
> const char *arg;
7108a7110
> int arg_len;
7135c7137
<   while (*q != ' ')
---
> while (*q != ' ' && *q != '+')
7146a7149,7162
> if (*q == '+')
>   {
> matches[i].arg = ++q;
> while (*q != ' ')
> {
>   if (*q == '\0')
> goto invalid_matches;
>   q++;
> }
> matches[i].arg_len = q - matches[i].arg;
>   } 
> else
>   matches[i].arg_len = 0;
> 
7172c7188,7189
<   && ! strncmp (switches[i].part1, matches[j].str, xlen))
---
> && ! strncmp (switches[i].part1, matches[j].str, xlen)
> && ( !matches[j].arg_len || ( switches[i].args && !strncmp 
> (switches[i].args[0], matches[j].arg, matches[j].arg_len ) ) ) )

[Bug other/48234] documentation bad sequence in toc

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2011-03-23 
21:12:58 UTC ---

Author: redi

Date: Wed Mar 23 21:12:51 2011

New Revision: 171363



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48179

PR other/48234

* doc/extend.texi (Alignment): Move section to match order in TOC.

* doc/invoke.texi (i386 and x86-64 Windows Options): Likewise.





Modified:

branches/gcc-4_5-branch/gcc/ChangeLog

branches/gcc-4_5-branch/gcc/doc/extend.texi

branches/gcc-4_5-branch/gcc/doc/invoke.texi

[Bug other/48179] Reference mismatch in documentation chapter 6

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2011-03-23 
21:12:57 UTC ---

Author: redi

Date: Wed Mar 23 21:12:51 2011

New Revision: 171363



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48179

PR other/48234

* doc/extend.texi (Alignment): Move section to match order in TOC.

* doc/invoke.texi (i386 and x86-64 Windows Options): Likewise.





Modified:

branches/gcc-4_5-branch/gcc/ChangeLog

branches/gcc-4_5-branch/gcc/doc/extend.texi

branches/gcc-4_5-branch/gcc/doc/invoke.texi

[Bug other/48179] Reference mismatch in documentation chapter 6

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2011-03-23 
21:45:24 UTC ---

Author: redi

Date: Wed Mar 23 21:45:18 2011

New Revision: 171365



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48179

PR other/48234

* doc/extend.texi (Alignment): Move section to match order in TOC.

* doc/invoke.texi (i386 and x86-64 Windows Options): Likewise.





Modified:

branches/gcc-4_4-branch/gcc/ChangeLog

branches/gcc-4_4-branch/gcc/doc/extend.texi

branches/gcc-4_4-branch/gcc/doc/invoke.texi

[Bug other/48234] documentation bad sequence in toc

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2011-03-23 
21:45:25 UTC ---

Author: redi

Date: Wed Mar 23 21:45:18 2011

New Revision: 171365



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48179

PR other/48234

* doc/extend.texi (Alignment): Move section to match order in TOC.

* doc/invoke.texi (i386 and x86-64 Windows Options): Likewise.





Modified:

branches/gcc-4_4-branch/gcc/ChangeLog

branches/gcc-4_4-branch/gcc/doc/extend.texi

branches/gcc-4_4-branch/gcc/doc/invoke.texi

[Bug other/48234] documentation bad sequence in toc

[redi at gcc dot gnu.org]

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



--- Comment #6 from Jonathan Wakely  2011-03-23 
21:47:28 UTC ---

Fixed on trunk and 4.4 and 4.5 branches. I'll fix for 4.6.1 when the branch

reopens.

[Bug other/48179] Reference mismatch in documentation chapter 6

[redi at gcc dot gnu.org]

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



--- Comment #6 from Jonathan Wakely  2011-03-23 
21:47:41 UTC ---

Fixed on trunk and 4.4 and 4.5 branches. I'll fix for 4.6.1 when the branch

reopens.

[Bug other/48254] documentation minor

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2011-03-23 
22:02:16 UTC ---

Author: redi

Date: Wed Mar 23 22:02:12 2011

New Revision: 171366



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48254

* doc/invoke.texi (-fipa-struct-reorg): Fix typo.





Modified:

branches/gcc-4_4-branch/gcc/ChangeLog

branches/gcc-4_4-branch/gcc/doc/invoke.texi

[Bug other/48254] documentation minor

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2011-03-23 
22:03:32 UTC ---

Author: redi

Date: Wed Mar 23 22:03:29 2011

New Revision: 171367



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

Log:

2011-03-23  Jonathan Wakely  



PR other/48254

* doc/invoke.texi (-fipa-struct-reorg): Fix typo.





Modified:

branches/gcc-4_5-branch/gcc/ChangeLog

branches/gcc-4_5-branch/gcc/doc/invoke.texi

[Bug other/48254] documentation minor

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2011-03-23 
22:06:40 UTC ---

I've fixed the "affective" typo on the 4.4 and 4.5 branches.



I'll leave someone else to decide what to do about the repeated options.



Thanks for reviewing the docs and submitting all these reports, Denis.

[Bug c++/48261] New: internal compiler error: in lookup_template_function, at cp/pt.c:6227

[dtag00 at gmail dot com]

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

   Summary: internal compiler error: in lookup_template_function,
at cp/pt.c:6227
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dta...@gmail.com


Created attachment 23762
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23762
File that GCC asked me to attach to this bug report.

Hi,
I encountered the compiler error:

internal compiler error: in lookup_template_function, at cp/pt.c:6227

I reproduced the error in a small test program:



struct Foo
{
template
static T add(T a, T b)
{
return a+b;
}
};

double gadd(double a, double b)
{
return a+b;
}

typedef double (*gaddType)(double,double);
struct Foo2
{
static gaddType add;
};
gaddType Foo2::add=&gadd;


template
struct Something 
{
void work()
{
double x=T::template add(5.0,6.0);
}
};

int main()
{
Something s;
s.work();

Something s2;
s2.work();
}



$ g++ a.cpp
a.cpp: In member function ‘void Something::work() [with T = Foo2]’:
a.cpp:38:9:   instantiated from here
a.cpp:28:41: internal compiler error: in lookup_template_function, at
cp/pt.c:6227
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccj7WbC1.out file, please attach this to
your bugreport.


Admittedly the program doesn't make much sense but there still shouldn't be an
internal compiler error. Took me a while to figure out the cause of the problem
in my actual program.

I use GCC 4.5.1 (a friend also tried it on 4.5.2 with the same effect).
The file mentioned in the error message is attached to this bug report.

Thanks

[Bug regression/48262] New: Subversion id 171341 breaks various vectorization files on powerpc

[meissner at gcc dot gnu.org]

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

   Summary: Subversion id 171341 breaks various vectorization
files on powerpc
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Created attachment 23763
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23763
-save-temps of a file that shows the bug (compile with -O3 -m64 -mvsx)

I updated GCC to the head release and tried to build spec on power7, and I had
a lot of failures.  I also got failures in one of my vectorization tests.

The failures are in:
oo2.c: In function ‘trunkp7vsx_align_amove_0_0_sign_long’:
foo2.c:120:36: internal compiler error: in expand_insn, at optabs.c:7171
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

GNU gdb (GDB) SUSE (7.0-0.4.16)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc64-suse-linux".
For bug reporting instructions, please see:
...
Reading symbols from
/home/meissner/fsf-build-ppc64/power7-meissner/gcc/cc1...done.
Breakpoint 1 at 0x1020460c: file
/home/meissner/fsf-src/power7-meissner/gcc/diagnostic.c, line 893.
Breakpoint 2 at 0x102052c4: file
/home/meissner/fsf-src/power7-meissner/gcc/diagnostic.c, line 838.
Breakpoint 3 at 0x109e7f94
Breakpoint 4 at 0x109e7884
(gdb) r -O3 -m64 -mvsx foo2.i
Starting program: /home/meissner/fsf-build-ppc64/power7-meissner/gcc/cc1 -O3
-m64 -mvsx foo2.i
Missing separate debuginfo for /usr/lib64/libstdc++.so.6
Try: zypper install -C
"debuginfo(build-id)=ed25a9207e96ab232788f89131590142a443bca0"
Missing separate debuginfo for /lib64/libgcc_s.so.1
Try: zypper install -C
"debuginfo(build-id)=3a099294fce09d9fce7bf2a37e64588381d3c56d"
 atof atoi atol atoll gnu_dev_major gnu_dev_minor gnu_dev_makedev vprintf
getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar fputc_unlocked
putc_unlocked putchar_unlocked feof_unlocked ferror_unlocked
trunkp7vsx_align_amove_0_0_sign_long
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
 Assembling
functions:
 trunkp7vsx_align_amove_0_0_sign_long
Breakpoint 1, fancy_abort (file=0x10a30f18
"/home/meissner/fsf-src/power7-meissner/gcc/optabs.c", line=7171,
function=0x10a30e60 "expand_insn") at
/home/meissner/fsf-src/power7-meissner/gcc/diagnostic.c:893
893   internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1  0x103c2e6c in expand_insn (icode=, nops=, ops=) at
/home/meissner/fsf-src/power7-meissner/gcc/optabs.c:7171
7171gcc_unreachable ();
(gdb) up
#2  expand_insn (icode=, nops=,
ops=) at
/home/meissner/fsf-src/power7-meissner/gcc/optabs.c:7167
7167expand_insn (enum insn_code icode, unsigned int nops,
(gdb) up
#3  0x102864f4 in expand_assignment (nontemporal=,
from=Unhandled dwarf expression opcode 0xf3
) at /home/meissner/fsf-src/power7-meissner/gcc/expr.c:4184
4184  expand_insn (icode, 2, ops);
(gdb) up
#4  expand_assignment (nontemporal=, from=Unhandled dwarf
expression opcode 0xf3
) at /home/meissner/fsf-src/power7-meissner/gcc/expr.c:4108
4108expand_assignment (tree to, tree from, bool nontemporal)
(gdb) print to
$1 = (union tree_node *) 0xfffb63bc5d0
(gdb) pt
 
unit size 
align 64 symtab 0 alias set 2 canonical type 0xfffb62405e8
precision 64 min  max
 context 
pointer_to_this >
V2DI
size 
unit size 
align 64 symtab 0 alias set 2 canonical type 0xfffb6409648 nunits 2
pointer_to_this >

arg 0 
public unsigned restrict DI size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0xfffb6409b88>
visited var def_stmt vect_p.29_94 =
vec1_15 + base_off.22_85;

version 94
ptr-info 0xfffb61db160>
arg 1  constant
0>
arg 2  unit size 
align 64 symtab 0 alias set -1 canonical type 0xfffb624
precision 64 min  max >
visited var def_stmt ivtmp.122_61 =
PHI 
version 61>>
(gdb) print from
Unhandled dwarf expression opcode 0xf3
(gdb) pt
 
unit size 
align 64 symtab 0 alias set 2 canonical type 0xfffb62405e8
precision 64 min  max
 context 
pointer_to_this >
V2DI
size 
unit size 
align 64 symtab 0 alias set 2 canonical type 0xfffb6409648 nunits 2
pointer_to_this >

arg 0