[Bug c++/53135] internal compiler error: in value_format, at dwarf2out.c:8010

[raj.khem at gmail dot com]

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

Khem Raj raj.khem at gmail dot com changed:

   What|Removed |Added

 Target||arm-oe-linux-gnueabi
  Known to fail||4.7.0, 4.7.1

--- Comment #1 from Khem Raj raj.khem at gmail dot com 2012-04-27 05:59:56 
UTC ---
testcase

class QAbstractFileEngine
{
public:
enum FileFlag {

ReadOwnerPerm = 0x4000, WriteOwnerPerm = 0x2000, ExeOwnerPerm = 0x1000,
ReadUserPerm = 0x0400, WriteUserPerm = 0x0200, ExeUserPerm = 0x0100,
ReadGroupPerm = 0x0040, WriteGroupPerm = 0x0020, ExeGroupPerm = 0x0010,
ReadOtherPerm = 0x0004, WriteOtherPerm = 0x0002, ExeOtherPerm = 0x0001,

};
bool setPermissions(unsigned int perms);
};

extern const char* str;
extern bool foo(const char*, int);

bool QAbstractFileEngine::setPermissions(unsigned int perms)
{   
bool ret = false;
int mode = 0;
if (perms  ReadOwnerPerm)
mode |= 0400;
if (perms  WriteOwnerPerm)
mode |= 0200;
if (perms  ExeOwnerPerm)
mode |= 0100;
if (perms  ReadUserPerm)
mode |= 0400;
if (perms  WriteUserPerm)
mode |= 0200;
if (perms  ExeUserPerm)
mode |= 0100;
if (perms  ReadGroupPerm)
mode |= (0400  3);
if (perms  WriteGroupPerm)
mode |= (0200  3);
if (perms  ExeGroupPerm)
mode |= (0100  3);
if (perms  ReadOtherPerm)
mode |= ((0400  3)  3);
if (perms  WriteOtherPerm)
mode |= ((0200  3)  3);
if (perms  ExeOtherPerm)
mode |= ((0100  3)  3);
ret = foo(str, mode) == 0;
return ret;
}

[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org 2012-04-27 06:12:55 UTC ---
Author: vries
Date: Fri Apr 27 06:12:49 2012
New Revision: 186894

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186894
Log:
2012-04-27  Tom de Vries  t...@codesourcery.com

PR tree-optimization/51879
* tree-ssa-sccvn.h (struct vn_reference_s): Add result_vdef field.
* tree-ssa-sccvn.c (mark_use_processed): New function, factored out
of ...
(defs_to_varying): ... here.  Don't set use_processed.
(visit_reference_op_call): Handle gimple_vdef.
Handle case that lhs is NULL_TREE.
(visit_use): Use mark_use_processed.  Handle calls with side-effect
using visit_reference_op_call.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org 2012-04-27 06:28:55 UTC ---
Author: vries
Date: Fri Apr 27 06:28:49 2012
New Revision: 186895

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186895
Log:
2012-04-27  Tom de Vries  t...@codesourcery.com

PR tree-optimization/51879
* gcc.dg/pr51879.c: New test.
* gcc.dg/pr51879-2.c: Same.
* gcc.dg/pr51879-3.c: Same.
* gcc.dg/pr51879-4.c: Same.
* gcc.dg/pr51879-6.c: Same.

Added:
trunk/gcc/testsuite/gcc.dg/pr51879-2.c
trunk/gcc/testsuite/gcc.dg/pr51879-3.c
trunk/gcc/testsuite/gcc.dg/pr51879-4.c
trunk/gcc/testsuite/gcc.dg/pr51879-6.c
trunk/gcc/testsuite/gcc.dg/pr51879.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org 2012-04-27 06:35:30 UTC ---
All listed examples fixed in r186894. 

Todo: follow-up with fix for:
...
struct S { int i; };
extern struct S foo (void);
extern int foo2 (void);
struct S s;
int bar (int c) {
  int r;
  if (c)
{
  s = foo ();
  r = foo2 ();
}
  else
{
  s = foo ();
  r = foo2 ();
}
  return r;
}
...

[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de rguenther at suse dot de 
2012-04-27 08:02:39 UTC ---
On Thu, 26 Apr 2012, amonakov at gcc dot gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53128
 
 Alexander Monakov amonakov at gcc dot gnu.org changed:
 
What|Removed |Added
 
  Status|WAITING |RESOLVED
  CC||amonakov at gcc dot
||gnu.org, rguenth at gcc dot
||gnu.org
  Resolution||INVALID
 
 --- Comment #2 from Alexander Monakov amonakov at gcc dot gnu.org 
 2012-04-26 16:20:39 UTC ---
 The code invokes undefined behavior as the increment statement of the outer
 loop tries to access ss[tt].a1[14] at the last iteration.  GCC optimizes out
 the loop exit test due to recent changes by Richard Guenther.
 
 Richard, I think a warning here would be very helpful (I remember you 
 mentioned
 that in IRC too).  What would implementing such a warning involve?

It's very difficult to warn for this as at the point we use the 
information to optimize the loop exit test we do not know where it came
from.  Thus, apart from warning on every exit test we optimize that
way (with the obvious false positives and the fact the warning would
be very unspecific warning: optimized loop exit test) I see no way
of warning here.

Other loop optimizations also can take advantage of this fact without
knowing.

Richard.

[Bug regression/53130] [4.8 Regression]: gcc.dg/20011021-1.c, gcc.dg/m-un-2.c, gcc.dg/missing-field-init-2.c

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-27 
08:22:01 UTC ---
Author: manu
Date: Fri Apr 27 08:21:49 2012
New Revision: 186896

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186896
Log:
2012-04-25  Manuel López-Ibáñez  m...@gcc.gnu.org

PR c/53130
* c-typeck.c (pop_init_level): Use %qD instead of %qT.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c

[Bug regression/53130] [4.8 Regression]: gcc.dg/20011021-1.c, gcc.dg/m-un-2.c, gcc.dg/missing-field-init-2.c

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-27 
08:22:49 UTC ---
FIXED.

[Bug driver/53002] Request new specs string token for multilib_os_dir

[sbd at NetBSD dot org]

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

Steven Drake sbd at NetBSD dot org changed:

   What|Removed |Added

  Attachment #27163|0   |1
is obsolete||

--- Comment #1 from Steven Drake sbd at NetBSD dot org 2012-04-27 08:30:02 
UTC ---
Created attachment 27251
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27251
Add %M spec string token

Modify patch to handle multilib_os_dir being NULL.

[Bug driver/53002] Request new specs string token for multilib_os_dir

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-27 
08:35:13 UTC ---
Hi Steven, patches go to gcc-patc...@gcc.gnu.org. See also:
http://gcc.gnu.org/contribute.html#patches

Good luck!

[Bug c++/53136] New: Use after free in ipa_make_edge_direct_to_target, cxx_printable_name_internal problem

[ubizjak at gmail dot com]

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

 Bug #: 53136
   Summary: Use after free in ipa_make_edge_direct_to_target,
cxx_printable_name_internal problem
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
Target: x86_64-pc-linux-gnu


Running compilation of iinline-2.C from gcc/testsuite/g++.dg/ipa test directory
under valgrind on x86_64-pc-linux-gnu, I got:

$ valgrind ~/gcc-build/gcc/cc1plus -O3 -fdump-ipa-inline -fno-early-inlining
-quiet iinline-2.C

[uros@localhost ipa]$ valgrind ~/gcc-build/gcc/cc1plus -O3 -fdump-ipa-inline
-fno-early-inlining -quiet iinline-2.C
==15980== Memcheck, a memory error detector
==15980== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15980== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==15980== Command: /home/uros/gcc-build/gcc/cc1plus -O3 -fdump-ipa-inline
-fno-early-inlining -quiet iinline-2.C
==15980== 
==15980== Invalid read of size 8
==15980==at 0xFB8954: search_line_sse42(unsigned char const*, unsigned char
const*) (lex.c:461)
==15980==by 0xFB8E61: _cpp_clean_line (lex.c:739)
==15980==by 0xFB9887: _cpp_get_fresh_line (lex.c:2000)
==15980==by 0xFBAFC0: _cpp_lex_direct (lex.c:2065)
==15980==by 0xFBBD4B: _cpp_lex_token (lex.c:1939)
==15980==by 0xFBFE8F: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2245)
==15980==by 0x717582: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:302)
==15980==by 0x5EFADF: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:721)
==15980==by 0x61D998: c_parse_file() (parser.c:600)
==15980==by 0x71D684: c_common_parse_file() (c-opts.c:1124)
==15980==by 0xA6005F: toplev_main(int, char**) (toplev.c:555)
==15980==by 0x322F62169C: (below main) (libc-start.c:226)
==15980==  Address 0x4cf8ba8 is 0 bytes after a block of size 1,128 alloc'd
==15980==at 0x4A075B2: realloc (vg_replace_malloc.c:525)
==15980==by 0xFE4E7C: xrealloc (xmalloc.c:179)
==15980==by 0xFAD973: _cpp_convert_input (charset.c:1734)
==15980==by 0xFB61EA: read_file(cpp_reader*, _cpp_file*) (files.c:652)
==15980==by 0xFB6D9D: _cpp_stack_file (files.c:723)
==15980==by 0xFB86F7: cpp_read_main_file(cpp_reader*, char const*)
(init.c:593)
==15980==by 0x71CCEB: c_common_post_options(char const**) (c-opts.c:1056)
==15980==by 0xA5F9FA: toplev_main(int, char**) (toplev.c:1228)
==15980==by 0x322F62169C: (below main) (libc-start.c:226)
==15980== 
==15980== Invalid read of size 1
==15980==at 0x322F64B3C6: vfprintf (vfprintf.c:1571)
==15980==by 0x322F651F46: fprintf (fprintf.c:33)
==15980==by 0x93FB69: ipa_make_edge_direct_to_target(cgraph_edge*,
tree_node*) (ipa-prop.c:1784)
==15980==by 0x9400FC: propagate_info_to_inlined_callees(cgraph_edge*,
cgraph_node*, VEC_cgraph_edge_p_heap**) (ipa-prop.c:1813)
==15980==by 0x940318: ipa_propagate_indirect_call_infos(cgraph_edge*,
VEC_cgraph_edge_p_heap**) (ipa-prop.c:1969)
==15980==by 0xF2886E: ipa_inline() (ipa-inline.c:1519)
==15980==by 0x9BBBD4: execute_one_pass(opt_pass*) (passes.c:2176)
==15980==by 0x9BC3E9: execute_ipa_pass_list(opt_pass*) (passes.c:2543)
==15980==by 0x7B006D: cgraph_optimize() (cgraphunit.c:1856)
==15980==by 0x7B03AE: cgraph_finalize_compilation_unit()
(cgraphunit.c:2435)
==15980==by 0x5DD8FA: cp_write_global_declarations() (decl2.c:4030)
==15980==by 0xA600AB: toplev_main(int, char**) (toplev.c:571)
==15980==  Address 0xb7bac50 is 0 bytes inside a block of size 31 free'd
==15980==at 0x4A0662E: free (vg_replace_malloc.c:366)
==15980==by 0x68C540: cxx_printable_name_internal(tree_node*, int, bool)
(tree.c:1615)
==15980==by 0x93FB33: ipa_make_edge_direct_to_target(cgraph_edge*,
tree_node*) (cgraph.h:755)
==15980==by 0x9400FC: propagate_info_to_inlined_callees(cgraph_edge*,
cgraph_node*, VEC_cgraph_edge_p_heap**) (ipa-prop.c:1813)
==15980==by 0x940318: ipa_propagate_indirect_call_infos(cgraph_edge*,
VEC_cgraph_edge_p_heap**) (ipa-prop.c:1969)
==15980==by 0xF2886E: ipa_inline() (ipa-inline.c:1519)
==15980==by 0x9BBBD4: execute_one_pass(opt_pass*) (passes.c:2176)
==15980==by 0x9BC3E9: execute_ipa_pass_list(opt_pass*) (passes.c:2543)
==15980==by 0x7B006D: cgraph_optimize() (cgraphunit.c:1856)
==15980==by 0x7B03AE: cgraph_finalize_compilation_unit()
(cgraphunit.c:2435)
==15980==by 0x5DD8FA: cp_write_global_declarations() (decl2.c:4030)
==15980==by 0xA600AB: toplev_main(int, char**) (toplev.c:571)
==15980== 
==15980== Invalid read of size 2
==15980==at 0x322F68BF7B: __GI_mempcpy (memcpy.S:84)
==15980==by 0x322F679375: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1350)
==15980==by 0x322F64B3A7: vfprintf 

[Bug target/53133] XOR AL,AL to zero lower 8 bits of EAX/RAX causes partial register stall (Intel Core 2)

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-27
 Ever Confirmed|0   |1
  Known to fail||4.3.6, 4.6.2, 4.7.0

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-27 
09:14:45 UTC ---
Confirmed.

[Bug c++/53137] New: g++ segfault

[valery.bickov at gmail dot com]

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

 Bug #: 53137
   Summary: g++ segfault
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: valery.bic...@gmail.com


4.7.0 and 4.8 segfaults on Linux x86-64 with the following code:

template typename STORE
void getParent(STORE tStore)
{
}

struct Store
{
template typename CheckParentFunc
void updateChildCommon(CheckParentFunc c);

template typename T
int getStore();

template typename T
void updateChild(const T obj)
{
updateChildCommon([this] () { getParent(getStoreT()); });
}

void update(int obj)
{
updateChild(obj);
}
};

$ /usr/local/gcc-4.7.0/bin/g++ gcc-4.7.0-crash.cpp -std=c++11 
gcc-4.7.0-crash.cpp: In instantiation of 'Store::updateChild(const T) [with T
= int]::lambda()':
gcc-4.7.0-crash.cpp:17:28:   required from 'struct Store::updateChild(const T)
[with T = int]::lambda()'
gcc-4.7.0-crash.cpp:17:9:   required from 'void Store::updateChild(const T)
[with T = int]'
gcc-4.7.0-crash.cpp:22:24:   required from here
gcc-4.7.0-crash.cpp:17:39: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

$ /usr/local/gcc-4.7.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.7.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.0/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gcc-4.7.0 --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 (GCC)

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-27 
09:26:39 UTC ---
Yes, in a few areas the 4.7.x library is much closer to the letter of C++11 in
terms of constraining, and of course we never did access control under sfinae.
Note that the latter, being a new feature, is very likely to happen only in
4.8, but not in 4.7.x, I don't think however we may want to take out
constraining from the 4.7.x library (indeed, people are normally encouraged to
use deleted members, not access control, together with classic sfinae)

[Bug target/53138] New: [4.7/4.8 Regression] spaceship operator miscompiled

[bonzini at gnu dot org]

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

 Bug #: 53138
   Summary: [4.7/4.8 Regression] spaceship operator miscompiled
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: bonz...@gnu.org
ReportedBy: bonz...@gnu.org
Target: x86_64-pc-linux-gnu


This program is miscompiled at -O2:

typedef struct sreal
{
  unsigned sig;/* Significant.  */
  int exp;/* Exponent.  */
} sreal;

sreal_compare (sreal *a, sreal *b)
{
  if (a-exp  b-exp)
return 1;
  if (a-exp  b-exp)
return -1;
  if (a-sig  b-sig)
return 1;
  return -(a-sig  b-sig);
}

sreal a[] = {
   { 0, 0 },
   { 1, 0 },
   { 0, 1 },
   { 1, 1 }
};

int main()
{
  int i, j;
  for (i = 0; i = 3; i++) {
for (j = 0; j  3; j++) {
  if (i  j  sreal_compare(a[i], a[j]) != -1) abort();
  if (i == j  sreal_compare(a[i], a[j]) != 0) abort();
  if (i  j  sreal_compare(a[i], a[j]) != 1) abort();
}
  }
}

The problem is that the comparison on sig is compiled to this:

movl(%rsi), %ecx
cmpl%ecx, (%rdi)
sbbl%edx, %edx
cmovbe%edx, %eax
ret

but sbbl only preserves the carry flag, not the zero flag.

[Bug target/53138] [4.7/4.8 Regression] spaceship operator miscompiled

[bonzini at gnu dot org]

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

Paolo Bonzini bonzini at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-27
 Ever Confirmed|0   |1

[Bug c++/53139] New: internal compiler error: expected a type, got '#'tree_vec' not supported by dump_expr#expression error'

[i.nixman at gmail dot com]

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

 Bug #: 53139
   Summary: internal compiler error: expected a type, got
'#'tree_vec' not supported by dump_expr#expression
error'
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i.nix...@gmail.com


This code:

// Compile: g++ -std=c++11 test.cpp
// Compile: clang++ -std=c++11 test.cpp

//#include string
//#include iostream

namespace my_types
{

struct nil {};

//original type
template typename T, typename U
struct chain
{
   typedef T first_type;
   typedef U second_type;
};

}

template template typename, typename class Chain, typename Nil
struct chain_generator
{
   template typename T, typename... Args
   struct gen
   {
   private:
  template std::size_t S = sizeof...(Args), typename Dummy = void
  struct inner
  {
 typedef ChainT, typename genArgs...::type  type;
  };

  template typename Dummy
  struct inner0, Dummy
  {
 typedef ChainT, Nil type;
  };
   public:
  typedef typename innersizeof...(Args)::type type;
   };
};

int main( /* int argc, char* argv[] */ )
{
   using my_types::chain;
   using my_types::nil;

   typedef chainint, chainfloat, chainchar, nil t0;
   typedef chain_generatorchain, nil my_gen;
   typedef my_gen::genint, float, char::type t1;

   return 0;
}


when compiling with gcc-4.7.0 produce this errors:
 source.cpp:29:22: error: 'size_t' has not been declared
 source.cpp: In instantiation of 'struct chain_generatormy_types::chain, 
 my_types::nil::genint, float, char::inner2, void':
 source.cpp:41:53:   required from 'struct chain_generatormy_types::chain, 
 my_types::nil::genint, float, char'
 source.cpp:52:41:   required from here
 source.cpp:32:57: error: type/value mismatch at argument 1 in template 
 parameter list for 'templatetemplateclass, class class Chain, class Nil 
 templateclass T, class ... Args struct chain_generatorChain, Nil::gen'
 source.cpp:32:57: error:   expected a type, got '#'tree_vec' not supported by 
 dump_expr#expression error'
 source.cpp:32:57: error: type/value mismatch at argument 2 in template 
 parameter list for 'templatetemplateclass, class class Chain, class Nil 
 templateclass T, class ... Args struct chain_generatorChain, Nil::gen'
 source.cpp:32:57: error:   expected a type, got '#'tree_vec' not supported by 
 dump_expr#expression error'

when compiling with gcc-4.6.3 produce this errors:
 source.cpp:30:13: error: 'size_t' has not been declared
 source.cpp:33:41: sorry, unimplemented: cannot expand 'Args ...' into a 
 fixed-length argument list
 source.cpp:33:49: error: template argument 2 is invalid
 source.cpp:33:51: error: expected '::' before 'type'

with clang this code compiled successfully.

gcc-4.7.0 test-drive:
http://liveworkspace.org/code/6287f6a38362af545712f43a56851a0b

[Bug target/53134] Request for option to disable excess precision on i387

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot 
com 2012-04-27 10:23:42 UTC ---
On Fri, 27 Apr 2012, bugdal at aerifal dot cx wrote:

 Since even with the precision mode set correctly the exponent range of 387 fpu
 registers still matches that of 80-bit long double, this mode would also imply
 a store/load cycle after every single floating point operation, analogous to
 -ffloat-store but on each step of calculation, not only on assignments. I

I think it would also imply checks for subnormal results and fixups to 
avoid double rounding in those cases.

[Bug c/53140] New: Add support for vector of complex numbers

[andrii.riabushenko at barclays dot com]

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

 Bug #: 53140
   Summary: Add support for vector of complex numbers
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andrii.riabushe...@barclays.com


Since now complex numbers are integral types gcc should provide support for
vector of complex numbers. Hence, the following code will start working:


typedef float _Complex v2sc __attribute__((vector_size(16)));
typedef float _Complex v4sc __attribute__((vector_size(32)));
typedef double _Complex v1dc __attribute__((vector_size(16)));
typedef double _Complex v2dc __attribute__((vector_size(32)));

v4sc a,b;
a += b;

[Bug c++/53139] internal compiler error: expected a type, got '#'tree_vec' not supported by dump_expr#expression error'

[marc.glisse at normalesup dot org]

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

Marc Glisse marc.glisse at normalesup dot org changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-04-27 
10:26:35 UTC ---
Works fine on trunk (since very recently). The 4.6 message looks fine (it
indeed wasn't implemented in 4.6). Can you check whether it works with a 4.7
snapshot?

[Bug target/53134] Request for option to disable excess precision on i387

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot 
com 2012-04-27 10:26:22 UTC ---
See also what I said in 
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html:

The option naming leaves open the possibility of other options such as
none if someone wishes to implement them.  (none would involve the
compiler doing mode switching and adding code to deal with extra range
and double rounding of subnormals.  There could also be an option to
have extra range but not precision, again with the compiler inserting
mode switches as needed.)  I am however doubtful of the use of such
options; this patch deals with a major area where -std=c99 fails to
implement standard semantics in default x86 configurations, but I'd
expect people wanting particular semantics beyond a predictable
version of C99 would use SSE.

[Bug middle-end/27139] Optimize double INT-FP-INT conversions with -ffast-math

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-27 
10:34:18 UTC ---
Author: rguenth
Date: Fri Apr 27 10:34:13 2012
New Revision: 186898

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186898
Log:
2012-04-27  Marc Glisse  marc.gli...@inria.fr

PR middle-end/27139
* tree-ssa-forwprop.c (combine_conversions): Handle INT-FP-INT.

* gcc.dg/tree-ssa/forwprop-18.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug c/53140] Add support for vector of complex numbers

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-27 
10:37:27 UTC ---
No, we do not want to have this.

[Bug c++/53139] internal compiler error: expected a type, got '#'tree_vec' not supported by dump_expr#expression error'

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-27
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-27 
10:40:10 UTC ---
Confirmed on the 4.7 branch.

[Bug target/53138] [4.7/4.8 Regression] spaceship operator miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.1

[Bug c++/53137] [4.7/4.8 Regression] g++ segfault

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-27
   Target Milestone|--- |4.7.1
Summary|g++ segfault|[4.7/4.8 Regression] g++
   ||segfault
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-27 
10:41:55 UTC ---
Confirmed.  4.6 rejects the testcase.

[Bug c/51527] ICE: Segmentation fault: 'convert_to_integer' enters infinite recursion

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-04-27 
10:52:03 UTC ---
Author: gjl
Date: Fri Apr 27 10:51:58 2012
New Revision: 186899

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186899
Log:
PR c/51527
* convert.c (convert_to_integer): Avoid infinte recursion for
target-defined built-in types.


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/convert.c

[Bug c/51527] ICE: Segmentation fault: 'convert_to_integer' enters infinite recursion

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.8.0
 Resolution||FIXED

--- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-04-27 
11:03:48 UTC ---
Fixed in 4.7.1

[Bug c++/53139] internal compiler error: expected a type, got '#'tree_vec' not supported by dump_expr#expression error'

[i.nixman at gmail dot com]

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

--- Comment #3 from niXman i.nixman at gmail dot com 2012-04-27 11:08:17 UTC 
---
with 4.7-branch rev-186846 and trunk rev-186841 - everything is ok.

[Bug c++/53139] internal compiler error: expected a type, got '#'tree_vec' not supported by dump_expr#expression error'

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-27 
11:23:00 UTC ---
Indeed.

[Bug target/53134] Request for option to disable excess precision on i387

[bugdal at aerifal dot cx]

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

--- Comment #6 from Rich Felker bugdal at aerifal dot cx 2012-04-27 11:51:05 
UTC ---
Joseph, you're right, and I don't see any way to handle the denormal issue
without really ugly and much slower wrapper code around each op...

[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-04-27 
12:03:00 UTC ---
  Does the aliases behave sanely with emutls?
 
 How do I tell?

Honestly I hoped you will know. Emutls is not my area.  I will try to play with
it on i386 target. Should not be too hard to figure out if the behaviour is
sane.
Basically I would expect that creating two module testcase and accessing same
TLS var with the var and alias should break with current implementation.

Thanks!
Honza

[Bug target/53138] [4.7/4.8 Regression] spaceship operator miscompiled

[bonzini at gnu dot org]

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

--- Comment #1 from Paolo Bonzini bonzini at gnu dot org 2012-04-27 12:18:03 
UTC ---
Author: bonzini
Date: Fri Apr 27 12:17:50 2012
New Revision: 186904

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186904
Log:
2012-04-27  Paolo Bonzini  bonz...@gnu.org

PR target/53138
* config/i386/i386.md (x86_movmodecc_0_m1_neg): Add clobber.

testsuite:
2012-04-27  Paolo Bonzini  bonz...@gnu.org

PR target/53138
* gcc.c-torture/execute/20120427-1.c: New testcase.



Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20120427-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/53124] Arm NEON narrowing right shift instructions impose incorrect operand bounds (intrinsic and asm)

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-04-27 
12:25:06 UTC ---
Just for the record, I've confirmed with the Assembler Guide team that there is
a documentation fault in that document.  It will be clarified in a future
release.

[Bug fortran/53035] ICE with deferred-length module variable

[norm.clerman at gmail dot com]

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

--- Comment #6 from Norman S. Clerman norm.clerman at gmail dot com 
2012-04-27 12:50:47 UTC ---
Hello,

  Thanks to everyone for following up on this. I was very used to seeing
messages that deferred length characters are not yet supported. Therefore, when
I saw the internal compiler error message, I thought it was caused by some
other problem. I see now that it is an existing one.

  I hope I did not seem too severe in my messages. I know many value the
development work being done on gfortran. (I recently attended a webinar given
by Prof. Damian Rouson on object-oriented scientific programming using modern
Fortran, and gfortran was the compiler used.)

  I am curious: How much does it cost to fix a specific bug? Is there a fixed
charge?

  I any case, I'll jump back into using gfortran whenever the current problems
are remedied. Before I added many modern Fortran features to my code, I
achieved some really impressive results using the compiler when I re-factored
one of my main applications using OpenMP.

  Enjoy your weekend.

Norm

[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls

[hp at gcc dot gnu.org]

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

--- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-27 
13:15:51 UTC ---
(In reply to comment #6)
   Does the aliases behave sanely with emutls?
  How do I tell?
 Honestly I hoped you will know. Emutls is not my area.

I should have mentioned that the other tests covering emutls work, so perhaps I
could answer the first question with a weak yes. :)

 Basically I would expect that creating two module testcase and accessing same
 TLS var with the var and alias should break with current implementation.

That might be so, but I don't know how to map module to a target which
doesn't have DSO's.  If you just mean different object files, then please do
add such a test, if there is none!  BTW, *-darwin* might be better for thorough
emutls testing.

Testing the patch in comment#4 finished: success.
thanks.

[Bug c++/12076] gcov misreports coverage of return statement [NRV]

[darkraver at gmail dot com]

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

Paul Robinson darkraver at gmail dot com changed:

   What|Removed |Added

 CC||darkraver at gmail dot com

--- Comment #18 from Paul Robinson darkraver at gmail dot com 2012-04-27 
13:37:30 UTC ---
Is this ever going to be looked at? It makes most gcov output incorrect and
hence not useful.

[Bug rtl-optimization/53141] New: [4.8 Regression] gcc.target/i386/bmi2-mulx32-[12]a.c

[hjl.tools at gmail dot com]

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

 Bug #: 53141
   Summary: [4.8 Regression] gcc.target/i386/bmi2-mulx32-[12]a.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com, kreb...@gcc.gnu.org,
ubiz...@gmail.com


On Linux/ia32, revision 186861

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00814.html

caused:

FAIL: gcc.target/i386/bmi2-mulx32-1a.c scan-assembler-times bmi2_umulsidi3_1 1
FAIL: gcc.target/i386/bmi2-mulx32-2a.c scan-assembler-times mulx[ \\t]+[^\n]* 1

[Bug middle-end/53142] New: FAIL: gcc.dg/pr52283.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

 Bug #: 53142
   Summary: FAIL: gcc.dg/pr52283.c (test for excess errors)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Target: hppa*-*-*


Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr52283.c  -fno-diagnostics-show-caret   
-a
nsi -pedantic-errors -S  -o pr52283.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/pr52283.c -fno-diagnostics-show-caret -ansi
-pedantic-err
ors -S -o pr52283.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr52283.c: In function 'b':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr52283.c:12:5: error: case label is not
an integer constant expression [-Wpedantic]
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr52283.c: In function 'b':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr52283.c:12:5: error: case label is not
an integer constant expression [-Wpedantic]

FAIL: gcc.dg/pr52283.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr52283.c:12:5: error: case label is not
an integer constant expression [-Wpedantic]

[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros

[aaw at gcc dot gnu.org]

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

--- Comment #3 from Ollie Wild aaw at gcc dot gnu.org 2012-04-27 14:29:39 UTC 
---
Author: aaw
Date: Fri Apr 27 14:29:32 2012
New Revision: 186909

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186909
Log:
Add new option, -Wliteral-suffix.

This option, which is enabled by default, causes the preprocessor to warn
when a string or character literal is followed by a ud-suffix which does
not begin with an underscore.  According to [lex.ext]p10, this is
ill-formed.

Also modifies the preprocessor to treat such ill-formed suffixes as separate
preprocessing tokens.  This is consistent with the Clang front end (see
http://llvm.org/viewvc/llvm-project?view=revrevision=152287), and enables
backwards compatibility with code that uses formatting macros from
inttypes.h, as in the following code block:

  int main() {
int64_t i64 = 123;
printf(My int64: %PRId64\n, i64);
  }

Google ref b/6377711.

2012-04-27   Ollie Wild  a...@google.com

PR c++/52538
* gcc/c-family/c-common.c: Add CPP_W_LITERAL_SUFFIX mapping.
* gcc/c-family/c-opts.c (c_common_handle_option): Handle
OPT_Wliteral_suffix.
* gcc/c-family/c.opt: Add Wliteral-suffix.
* gcc/doc/invoke.texi (Wliteral-suffix): Document new option.
* gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix.c: New test.
* libcpp/include/cpplib.h (struct cpp_options): Add new field,
warn_literal_suffix.
(CPP_W_LITERAL_SUFFIX): New enum.
* libcpp/init.c (cpp_create_reader): Default initialization of
warn_literal_suffix.
* libcpp/lex.c (lex_raw_string): Treat user-defined literals which
don't begin with '_' as separate tokens and produce a warning.
(lex_string): Ditto.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/include/cpplib.h
trunk/libcpp/init.c
trunk/libcpp/lex.c

[Bug rtl-optimization/53141] [4.8 Regression] gcc.target/i386/bmi2-mulx32-[12]a.c

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-04-27 
14:32:23 UTC ---
That's because reload now will try with swapped operands before going to the
next alternative. So now the first alternative will be used instead of the
second.

This matches the behavior documented in the GCC internal manual:

http://gcc.gnu.org/onlinedocs/gccint/Multi_002dAlternative.html
If two alternatives need the same amount of copying, the one that
comes first is chosen.

So if the second alternative is preferable then the back-end pattern needs to
be adjusted.

ira:
(insn 9 4 14 2 (parallel [
(set (reg:DI 65 [ res ])
(mult:DI (zero_extend:DI (reg/v:SI 64 [ b ]))
(zero_extend:DI (reg/v:SI 63 [ a ]
(clobber (reg:CC 17 flags))
]) bmi2-mulx32-1.c:24 336 {*umulsidi3_1}
 (expr_list:REG_DEAD (reg/v:SI 64 [ b ])
(expr_list:REG_DEAD (reg/v:SI 63 [ a ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

reload:
(insn 9 4 17 2 (parallel [
(set (reg:DI 0 ax [orig:65 res ] [65])
(mult:DI (zero_extend:DI (reg/v:SI 0 ax [orig:63 a ] [63]))
(zero_extend:DI (reg/v:SI 1 dx [orig:64 b ] [64]
(clobber (reg:CC 17 flags))
]) bmi2-mulx32-1.c:24 336 {*umulsidi3_1}
 (nil))

back-end pattern:

(define_insn *umulmodedwi3_1
  [(set (match_operand:DWI 0 register_operand =A,r)
(mult:DWI
  (zero_extend:DWI
(match_operand:DWIH 1 nonimmediate_operand %0,d))
  (zero_extend:DWI
(match_operand:DWIH 2 nonimmediate_operand rm,rm
   (clobber (reg:CC FLAGS_REG))]

[Bug rtl-optimization/53141] [4.8 Regression] gcc.target/i386/bmi2-mulx32-[12]a.c

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-04-27 
14:47:15 UTC ---
Created attachment 27252
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27252
Patch proposal

This patch should bring back the old behavior.

[Bug libitm/53008] abort in _ITM_getTMCloneSafe

[patrick.marlier at gmail dot com]

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

Patrick Marlier patrick.marlier at gmail dot com changed:

   What|Removed |Added

 CC||patrick.marlier at gmail
   ||dot com

--- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 
2012-04-27 15:00:16 UTC ---
Hello Dave,

This is because your mycompare function is not transaction_safe, so no clone
can be found at runtime.

So if you add transaction_safe to your comparison function, it should work. In
your example it should be:

__attribute__((transaction_safe)) static long mycompare(int a, int b)

If it works, please closed the bug report. Thanks.
--
Patrick Marlier

[Bug other/53143] New: [4.8 Regression] ' in c_tree_printer, at c-objc-common.c:136

[danglin at gcc dot gnu.org]

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

 Bug #: 53143
   Summary: [4.8 Regression] ' in c_tree_printer, at
c-objc-common.c:136
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11


Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/20011021-1.c  -fno-diagnostics-show-caret
-std=c99 -W -Wall -Wtraditional -S  -o 20011021-1.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/20011021-1.c -fno-diagnostics-show-caret -std=c99 -W
-Wal
l -Wtraditional -S -o 20011021-1.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/20011021-1.c:30:8: warning: missing
initi
alizer for field 'b' of 'struct t' [-Wmissing-field-initializers]
'
in c_tree_printer, at c-objc-common.c:136
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/20011021-1.c:30:8: warning: missing
initi
alizer for field 'b' of 'struct t' [-Wmissing-field-initializers]
'
in c_tree_printer, at c-objc-common.c:136
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

PASS: gcc.dg/20011021-1.c  (test for warnings, line 30)
FAIL: gcc.dg/20011021-1.c near init (test for warnings, line 30)
PASS: gcc.dg/20011021-1.c  (test for bogus messages, line 32)
FAIL: gcc.dg/20011021-1.c  (test for warnings, line 34)
PASS: gcc.dg/20011021-1.c  (test for bogus messages, line 35)
PASS: gcc.dg/20011021-1.c  (test for bogus messages, line 40)
FAIL: gcc.dg/20011021-1.c  (test for warnings, line 41)
PASS: gcc.dg/20011021-1.c  (test for bogus messages, line 42)
FAIL: gcc.dg/20011021-1.c  (test for warnings, line 44)
FAIL: gcc.dg/20011021-1.c near init (test for warnings, line 27)
FAIL: gcc.dg/20011021-1.c (test for excess errors)
Excess errors:
'
in c_tree_printer, at c-objc-common.c:136

[Bug go/52358] math FAILs on Solaris 8 and 9

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-04-27 
16:32:50 UTC ---
Author: ian
Date: Fri Apr 27 16:32:42 2012
New Revision: 186913

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186913
Log:
PR go/52358
math: Work around bug in Solaris 9 implementation of ldexp.

The bug is that ldexp(-1, -1075) should return -0, but the
Solaris 9 implementation returns +0.

Modified:
trunk/libgo/go/math/ldexp.go

[Bug go/52358] math FAILs on Solaris 8 and 9

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-04-27 
16:33:14 UTC ---
Author: ian
Date: Fri Apr 27 16:33:01 2012
New Revision: 186914

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186914
Log:
PR go/52358
math: Work around bug in Solaris 9 implementation of ldexp.

The bug is that ldexp(-1, -1075) should return -0, but the
Solaris 9 implementation returns +0.

Modified:
branches/gcc-4_7-branch/libgo/go/math/ldexp.go

[Bug go/52358] math FAILs on Solaris 8 and 9

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-04-27 
16:38:37 UTC ---
Author: ian
Date: Fri Apr 27 16:38:31 2012
New Revision: 186916

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186916
Log:
PR go/52358
configure, runtime: Provide i386 long double math functions if needed.

Modified:
branches/gcc-4_7-branch/libgo/config.h.in
branches/gcc-4_7-branch/libgo/configure
branches/gcc-4_7-branch/libgo/configure.ac
branches/gcc-4_7-branch/libgo/runtime/go-nosys.c

[Bug go/52358] math FAILs on Solaris 8 and 9

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-04-27 
16:38:19 UTC ---
Author: ian
Date: Fri Apr 27 16:38:11 2012
New Revision: 186915

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186915
Log:
PR go/52358
configure, runtime: Provide i386 long double math functions if needed.

Modified:
trunk/libgo/config.h.in
trunk/libgo/configure
trunk/libgo/configure.ac
trunk/libgo/runtime/go-nosys.c

[Bug go/52360] time and net/http FAIL on Solaris 8 and 9

[ian at airs dot com]

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

Ian Lance Taylor ian at airs dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ian Lance Taylor ian at airs dot com 2012-04-27 16:40:29 
UTC ---
This was fixed by a recent patch to libgo/runtime/go-setenv.c.

[Bug middle-end/53144] New: [4.8 Regression] gcc.c-torture/execute/vector-compare-1.c

[hjl.tools at gmail dot com]

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

 Bug #: 53144
   Summary: [4.8 Regression]
gcc.c-torture/execute/vector-compare-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: bonz...@gnu.org


On Linux/x86-64, revision 186905:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00858.html

caused:

WARNING: program timed out.
FAIL: gcc.c-torture/execute/vector-compare-1.c compilation,  -O3
-fomit-frame-pointer 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/vector-compare-1.c compilation,  -O3
-fomit-frame-pointer -funroll
-loops 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/vector-compare-1.c compilation,  -O3
-fomit-frame-pointer -funroll
-all-loops -finline-functions 
WARNING: program timed out.
FAIL: gcc.c-torture/execute/vector-compare-1.c compilation,  -O3 -g

[Bug go/52583] Several new go testsuite failues on Solaris

[ian at airs dot com]

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

Ian Lance Taylor ian at airs dot com changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #22 from Ian Lance Taylor ian at airs dot com 2012-04-27 16:41:42 
UTC ---
Suspending this PR until either Solaris fixes x86_64 makecontext or libgo
starts using a different mechanism.

[Bug go/52358] math FAILs on Solaris 8 and 9

[ian at airs dot com]

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

Ian Lance Taylor ian at airs dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Ian Lance Taylor ian at airs dot com 2012-04-27 16:43:08 
UTC ---
Fixed.

[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros

[jyasskin at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-27 
17:47:30 UTC ---
Is this ok for gcc-4_7-branch too? The other bug reports Jonathan mentioned
won't be helped by a fix that skips 4.7.

[Bug debug/53145] New: [4.8 Regression] gcc.dg/pch/save-temps-1.c

[hjl.tools at gmail dot com]

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

 Bug #: 53145
   Summary: [4.8 Regression] gcc.dg/pch/save-temps-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ja...@redhat.com


On Linux/x86-64, revision 186835:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00787.html

caused:

FAIL: gcc.dg/pch/save-temps-1.c  -O0 -g assembly comparison
FAIL: gcc.dg/pch/save-temps-1.c   -O3 -g  assembly comparison

with --target_board='unix{-m32}'. I got

ine #161 
 .LASF3:
 .LASF0:
line #162
   .string
/export/gnu/import/git/gcc-regression/master/186835/bld/gcc/testsuite/gcc 
   .string unsigned int
line #163   
 .LASF0:
 .LASF3:
line #164
   .string unsigned int
   .string 
 /export/gnu/import/git/gcc-regression/master/186835/bld/gcc/testsuite/gcc 
FAIL: gcc.dg/pch/save-temps-1.c   -O3 -g  assembly comparison

[Bug middle-end/53142] FAIL: gcc.dg/pr52283.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-04-27 
18:52:44 UTC ---
Breakpoint 1, c_tree_printer (pp=0x8001002055b8, text=0x83fffdff1208,
spec=0x8001001c0dc9 T, precision=0, wide=0 '\000',
set_locus=0 '\000', hash=0 '\000') at ../../gcc/gcc/c-objc-common.c:136
136   gcc_assert (TYPE_P (t));
(gdb) p debug_tree (t)
 field_decl 83fffdeb1098 b
type integer_type 83fffddd75e8 int public SI
size integer_cst 83fffddd08e0 constant 32
unit size integer_cst 83fffddd0900 constant 4
align 32 symtab 0 alias set -1 canonical type 83fffddd75e8
precision 32 min integer_cst 83fffddd0880 -2147483648 max integer_cst
83fffddd08a0 2147483647
pointer_to_this pointer_type 83fffdde42a0
SI file /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/20011021-1.c line 11 col 7
size integer_cst 83fffddd08e0 32 unit size integer_cst 83fffddd0900
4
align 32 offset_align 128
offset integer_cst 83fffddd05a0 type integer_type 83fffddd7000
sizetype constant 0 bit offset integer_cst 83fffddd08e0 32 context
record_type 83fffdea29d8 t chain field_decl 83fffdeb1130 c
$4 = void

[Bug middle-end/53142] FAIL: gcc.dg/pr52283.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2012-04-27 
18:56:44 UTC ---
(In reply to comment #1)

Oops, ignore last comment.  It was for different PR.

[Bug other/53143] [4.8 Regression] ' in c_tree_printer, at c-objc-common.c:136

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-04-27 
19:06:48 UTC ---
Seems to be caused by the following decl:

Breakpoint 1, c_tree_printer (pp=0x8001002055b8, text=0x83fffdff1208,
spec=0x8001001c0dc9 T, precision=0, wide=0 '\000',
set_locus=0 '\000', hash=0 '\000') at ../../gcc/gcc/c-objc-common.c:136
136   gcc_assert (TYPE_P (t));
(gdb) p debug_tree (t)
 field_decl 83fffdeb1098 b
type integer_type 83fffddd75e8 int public SI
size integer_cst 83fffddd08e0 constant 32
unit size integer_cst 83fffddd0900 constant 4
align 32 symtab 0 alias set -1 canonical type 83fffddd75e8
precision 32 min integer_cst 83fffddd0880 -2147483648 max integer_cst
83fffddd08a0 2147483647
pointer_to_this pointer_type 83fffdde42a0
SI file /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/20011021-1.c line 11 col 7
size integer_cst 83fffddd08e0 32 unit size integer_cst 83fffddd0900
4
align 32 offset_align 128
offset integer_cst 83fffddd05a0 type integer_type 83fffddd7000
sizetype constant 0 bit offset integer_cst 83fffddd08e0 32 context
record_type 83fffdea29d8 t chain field_decl 83fffdeb1130 c

[Bug other/53143] [4.8 Regression] ' in c_tree_printer, at c-objc-common.c:136

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-27 
19:18:14 UTC ---
Can you try with the latest revision? I think I fixed this already.

[Bug other/53143] [4.8 Regression] ' in c_tree_printer, at c-objc-common.c:136

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net 2012-04-27 19:24:24 UTC ---
On 4/27/2012 3:18 PM, manu at gcc dot gnu.org wrote:
 Can you try with the latest revision? I think I fixed this already.
Ok, I'll give it a try.

[Bug c/53146] New: switch statement compiling wrong code

[erikyyy at erikyyy dot de]

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

 Bug #: 53146
   Summary: switch statement compiling wrong code
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: erik...@erikyyy.de


Created attachment 27253
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27253
Shell script to compile and transfer code to chip.

Target: avr (atmega8)

[Bug target/53146] switch statement compiling wrong code

[erikyyy at erikyyy dot de]

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

--- Comment #1 from Erik Thiele erikyyy at erikyyy dot de 2012-04-27 19:54:00 
UTC ---
Created attachment 27254
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27254
source code to demonstrate problem

[Bug target/53146] switch statement compiling wrong code

[erikyyy at erikyyy dot de]

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

--- Comment #2 from Erik Thiele erikyyy at erikyyy dot de 2012-04-27 19:55:49 
UTC ---
run the shell script to compile the source and transfer it to an atmega8
attached to a stk500 programmer.

if you read the sourcecode you see, it should end in an endless loop.

instead the unreachable code section is executed.

see the shell script. if you compile with -O1 instead of -Os, then the program
will enter endless loop as expected instead of entering unreachable section.

[Bug target/53146] switch statement compiling wrong code

[erikyyy at erikyyy dot de]

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

--- Comment #3 from Erik Thiele erikyyy at erikyyy dot de 2012-04-27 20:01:04 
UTC ---
Created attachment 27255
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27255
collection of output files created by shellscript to show invalid code.

[Bug target/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[danglin at gcc dot gnu.org]

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

--- Comment #11 from John David Anglin danglin at gcc dot gnu.org 2012-04-27 
20:41:22 UTC ---
Author: danglin
Date: Fri Apr 27 20:41:16 2012
New Revision: 186919

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186919
Log:
PR target/52999
* config/pa/pa.c (pa_legitimate_constant_p): Don't put function labels
in constant pool.


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

[Bug middle-end/53147] New: [4.7/4.8 Regression] gcc apparently miscompiles clang-3.1(or trunk)

[markus at trippelsdorf dot de]

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

 Bug #: 53147
   Summary: [4.7/4.8 Regression] gcc apparently miscompiles
clang-3.1(or trunk)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de


When one builds an optimized clang-3.1(or trunk) with gcc-4.7/4.8, clang
crashes regularly (when -Wall is enabled).

For example:
 $ clang++ -Wall -c test.ii
0  clang   0x018c6d1f
1  clang   0x018c7070
2  libpthread.so.0 0x7ffee4b61180
3  clang   0x00d3c402
4  clang   0x00d3d689
5  clang   0x00d3f14c
clang::runUninitializedVariablesAnalysis(clang::DeclContext const, clang::CFG
const, clang::AnalysisDeclContext, clang::UninitVariablesHandler,
clang::UninitVariablesAnalysisStats) + 1292
6  clang   0x00b70ef7
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::BlockExpr const*) +
1207
7  clang   0x008df850
clang::Sema::PopFunctionScopeInfo(clang::sema::AnalysisBasedWarnings::Policy
const*, clang::Decl const*, clang::BlockExpr const*) + 304
8  clang   0x0096e9ec
clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 332
9  clang   0x008c037f
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope) + 159
10 clang   0x00869d40
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator,
clang::Parser::ParsedTemplateInfo const,
llvm::SmallVectorclang::Parser::LateParsedAttribute*, 2u*) + 960
11 clang   0x00874149
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 809
12 clang   0x00865307
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec,
clang::AccessSpecifier) + 135
13 clang   0x00865965
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes,
clang::AccessSpecifier) + 773
14 clang   0x00869415
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange,
clang::Parser::ParsingDeclSpec*) + 3253
15 clang   0x00869727
clang::Parser::ParseTopLevelDecl(clang::OpaquePtrclang::DeclGroupRef) + 199
16 clang   0x00860d15 clang::ParseAST(clang::Sema, bool, bool)
+ 277
17 clang   0x005f6587
clang::CompilerInstance::ExecuteAction(clang::FrontendAction) + 263
18 clang   0x005df87f
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1023
19 clang   0x005d67e5 cc1_main(char const**, char const**, char
const*, void*) + 9029
20 clang   0x005de7ec main + 7660
21 libc.so.6   0x7ffee426c675 __libc_start_main + 245
22 clang   0x005d3a89
Stack dump:
0.  Program arguments: /var/tmp/llvm/build/Release/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name RenameVar.ii -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.22.52.20120422
-momit-leaf-frame-pointer -coverage-file RenameVar.o -resource-dir
/var/tmp/llvm/build/Release/bin/../lib/clang/3.1 -Wall -fdeprecated-macro
-fdebug-compilation-dir /var/tmp/llvm/build -ferror-limit 19 -fmessage-length
149 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o RenameVar.o -x c++-cpp-output
/var/tmp/creduce/clang_delta/RenameVar.ii 
1.  RenameVar.cpp:119:1: current parser token 'bool'
2.  RenameVar.cpp:107:1: parsing function body 'Initialize'
clang: error: unable to execute command: Segmentation fault

Building clang with gcc-4.6.3 fixes the crashes.

I've narrowed it down to one function in
clang/lib/Analysis/UninitializedValues.cpp :

/// This function pattern matches for a '' or '||' that appears at
/// the beginning of a CFGBlock that also (1) has a terminator and 
/// (2) has no other elements.  If such an expression is found, it is returned.
__attribute__((optimize (-Os)))
static const BinaryOperator *getLogicalOperatorInChain(const CFGBlock *block) {
  if (block-empty())
return 0;

  const CFGStmt *cstmt = block-front().getAsCFGStmt();
  if (!cstmt)
return 0;

  const BinaryOperator *b = dyn_cast_or_nullBinaryOperator(cstmt-getStmt());

  if (!b || !b-isLogicalOp())
return 0;

  if (block-pred_size() == 2) {
if (block-getTerminatorCondition() == b) {
  if 

[Bug middle-end/53147] [4.7/4.8 Regression] gcc apparently miscompiles clang-3.1(or trunk)

[markus at trippelsdorf dot de]

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

--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-04-27 21:17:11 UTC ---
BTW the original clang bug can be found here:
http://llvm.org/bugs/show_bug.cgi?id=11926

And this is a RedHat bug report of the same issue:  
https://bugzilla.redhat.com/show_bug.cgi?id=791365

[Bug middle-end/53147] [4.7/4.8 Regression] gcc apparently miscompiles clang-3.1(or trunk)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-27 
21:24:33 UTC ---
According to the redhat bug, it is a bug in clang with respect of
strict-aliasing.

[Bug middle-end/53147] [4.7/4.8 Regression] gcc apparently miscompiles clang-3.1(or trunk)

[markus at trippelsdorf dot de]

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

--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 
2012-04-27 21:27:57 UTC ---
(In reply to comment #2)
 According to the redhat bug, it is a bug in clang with respect of
 strict-aliasing.

No. That was a red herring. clang explicitly uses -fno-strict-aliasing
during the build.

[Bug libfortran/53148] New: [gcc/gfortran-4.7.0 Regression] Incorrect intrinsic function parsing on labeled statements when compiled w/optimization

[jpsinthemix at verizon dot net]

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

 Bug #: 53148
   Summary: [gcc/gfortran-4.7.0 Regression] Incorrect intrinsic
function parsing on labeled statements when compiled
w/optimization
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jpsinthe...@verizon.net


Created attachment 27256
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27256
Compilation and .s files for -O0 and -O2 optimizations

Hi,
There appears to be a gcc/gfortran-4.7.0 regression occurring for -O
optimizations greater than -O0 related to the parsing of labeled statements
containing expressions with repeated function calls. For example, a statement
like:

   10 x = dble(y)*dble(y)

will generate a compiler warning, similar to

label_opt_issue.f:38:0: warning: '__var_1' is used uninitialized in this
function [-Wuninitialized]

and at runtime, the expression dble(y)*dble(y) will always evaluate to 0,
regardless of the value of y.

Expected results are obtained when the code is compiled with default/no
optimization, but failure occurs when compiling with -O1 and above. There is
nothing special about the use of intrinsic DBLE here, the same behavior occurs
for other intrinsic functions (user-defined functions work as expected). In
addition, if a more complicated expression is used, for example,

   10 x = (1.d0 + exp(y)*exp(y))/z

then the same compilation warning occurs, and the value of x is evaluated as

  x = (1 + 0)/z = 1/z

that is, exp(y)*exp(y) evaluates to 0, regardless of y.


This issue is not present in gcc/gfortran-4.6.3. The following program
demonstrates the issue:

C label_opt_issue.f

  program main
  real x
  double precision xsq
  double precision test_func
  double precision work_around

  x = 5.

  xsq = test_func(x)
  write(*,*) function   x: , x, x*x: , xsq

  call test_subr(x,xsq)
  write(*,*) subroutine x: , x, x*x: , xsq

  xsq = work_around(x)
  write(*,*) expected   x: , x, x*x: , xsq
  end program

  subroutine test_subr(x,xsq)
  real x
  double precision xsq
  intrinsic dble

  goto 10

   10 xsq = dble(x)*dble(x)
  return
  end subroutine

  double precision function test_func(x)
  real x
  intrinsic dble

  goto 10

   10 test_func = dble(x)*dble(x)
  return
  end function

  double precision function work_around(x)
  real x
  intrinsic dble

  goto 10

   10 continue
  work_around = dble(x)*dble(x)
  return
  end function

Demonstration code output:

With -O1 to -O3 optimization:

$ ./label_opt_issue
 function   x:5. x*x:0.
 subroutine x:5. x*x:0.
 expected   x:5. x*x:25.000

With default optimization:

$ ./label_opt_issue
 function   x:5. x*x:25.000
 subroutine x:5. x*x:25.000
 expected   x:5. x*x:25.000


I have attached the label_opt_issue.f compilation logs and temp *.s files for
for two cases: default optimization and -O2 optimization. 

I came across this issue building and testing SCIPY; one test failed which
really should not have, and that lead me to a fortran routine using DBLE in the
manner above which always evaluated to 0.

System info:

=== gcc/gfortran version/options/system type:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/bld/gcc-4.7.0-jps_src/gcc-4.7.0/configure --prefix=/usr
--libexecdir=/usr/lib --with-gmp=/usr --with-mpfr=/usr --with-system-zlib
--enable-shared --enable-checking=release --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-bootstrap
--enable-languages=c,c++,fortran --infodir=/usr/share/info
--mandir=/usr/share/man
Thread model: posix
gcc version 4.7.0 (GCC)

system: Linux b-movie 3.3.3 #1 Sun Apr 22 21:11:23 EDT 2012 i686 GNU/Linux
glibc:  2.15

thanks for your time,
John

[Bug testsuite/53028] add dg-pedantic

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28 
00:02:13 UTC ---
(In reply to comment #9)
 also don't test that the warning goes away with -w.  We don't test the warning
 turns into an error with -Werror.

Don't we?

http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01778.html

 How many times has one of these tests caught someone modifying a pedantic into
 a warning?  How many times has one of these tests caught someone modifying a
 pedantic into an error?  How many times did someone modify a pedantic in one 
 of
 the two ways because a testcase wasn't present?

The current practice is a burden for developers and for running the testsuite.
Adding dg-pedantic will make it only a burden for running the testsuite (but it
will actually make the testsuite smaller!). Perhaps we can devise an indirect
way to test that a warning is enabled by a certain option. We could have 
{ dg-warning-with-option Wlong-long ISO C90 does not support 'long long' },
which will match the option shown with -fdiagnostics-show-option. Can we at
least have this?

 Feel free to use your best recollection for the above answers.  I can't help
 but think the numbers are so low, as to not be worth the cost of the 
 additional
 testcases.

Fair enough. But the duplicated testcases are still being added!

[Bug target/53146] switch statement compiling wrong code

[erikyyy at erikyyy dot de]

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

Erik Thiele erikyyy at erikyyy dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Erik Thiele erikyyy at erikyyy dot de 2012-04-28 00:07:23 
UTC ---
:-(
I'm sorry.
The reason was not putting the .data segment into the HEX file.
Please close the bug. :-(
the C switch statement is building a jump table in the data segment.

wrong: avr-objcopy -j .text -O ihex concat.out concat.hex

correct: avr-objcopy -j .text -j .data -O ihex concat.out concat.hex

[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 Depends on||53063

--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28 
00:11:12 UTC ---
Doing this option by option is stupid. Groups options should be encoded in .opt
files and the code to handle sub-options be automatically generated. PR50363
needs to be fixed first.

[Bug c/53072] automatically set Init() only if option was not set in some other way

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28 
00:17:33 UTC ---
(In reply to comment #5)
 
 It may be possible - you'd need to avoid implicit setting marking the 
 implied option as set - and I don't think delaying processing of Init() 
 will actually be helpful anyway.

Then, I don't understand what is your plan. The current hack uses Init(-1) and
checks if warn_whatever == -1 as late as possible before setting the real
default value. My idea was to mimic this, but using the set structure instead
of -1, and using the Init value as the default value. A strategy to implement
this could be to introduce a new Default(), which will be set unconditionally
if the option is unset. This will allow to get rid of Init(-1) incrementally.

[Bug middle-end/53144] [4.8 Regression] gcc.c-torture/execute/vector-compare-1.c

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson hp at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-28 
00:27:12 UTC ---
cris-elf too (186897:186908); no SIMD, FWIW.

[Bug regression/53130] [4.8 Regression]: gcc.dg/20011021-1.c, gcc.dg/m-un-2.c, gcc.dg/missing-field-init-2.c

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-28 
00:32:36 UTC ---
(In reply to comment #3)
 FIXED.

No; gcc.dg/20011021-1.c didn't actually pass after your changes, there's a
missing warning.  I'll clone this PR, as it's supposedly a separate issue.

[Bug regression/53149] New: [4.8 Regression]: gcc.dg/20011021-1.c

[hp at gcc dot gnu.org]

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

 Bug #: 53149
   Summary: [4.8 Regression]: gcc.dg/20011021-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
CC: ja...@gcc.gnu.org, m...@gcc.gnu.org
Depends on: 53130
  Host: x86_64-unknown-linux-gnu
Target: cris-elf, x86_64-linux, s390x-linux, i686-linux


+++ This bug was initially created as a clone of Bug #53130 +++

The gcc.dg/20011021-1.c test still fails at r186918, but no longer with an ICE:

Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/20011021-1.c near init (test for warnings, line 30)

Just as with the original bug, it seems to do this for all major targets, so
maybe there's a problem with your testing?

[Bug regression/53149] [4.8 Regression]: gcc.dg/20011021-1.c

[manu at gcc dot gnu.org]

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

--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28 
01:28:13 UTC ---
Doh, I was testing a revision before my commit. Anyway, the testcase just needs
adjusting. I will do that as soon as an up-to-date version finishes
bootstrapping.

[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #30 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2012-04-28 
01:56:59 UTC ---
Author: mkuvyrkov
Date: Sat Apr 28 01:56:54 2012
New Revision: 186928

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186928
Log:
PR tree-optimization/38785
* common.opt (ftree-partial-pre): New option.
* doc/invoke.texi: Document it.
* opts.c (default_options_table): Initialize flag_tree_partial_pre.
* tree-ssa-pre.c (do_partial_partial_insertion): Insert only if it will
benefit speed path.
(execute_pre): Use flag_tree_partial_pre.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/opts.c
trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #31 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2012-04-28 
02:09:38 UTC ---
Fixed by the above reworked version of Joern's and Steven's patches.

[Bug c++/53150] New: g++ crashes if struct member initializer references to local variable

[yuzurufag+gcc at gmail dot com]

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

 Bug #: 53150
   Summary: g++ crashes if struct member initializer references to
local variable
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yuzurufag+...@gmail.com


$ g++ -std=c++0x crash.cpp 
crash.cpp: In constructor ‘constexpr main()::anonymous struct::._0()’:
crash.cpp:5:2: internal compiler error: in expand_expr_real_1, at expr.c:9147
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccPW0iTF.out file, please attach this to
your bugreport.


$ cat /tmp/ccPW0iTF.out
// /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -quiet -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE crash.cpp -quiet -dumpbase crash.cpp
-mtune=generic -march=x86-64 -auxbase crash -std=c++11 -fstack-protector -o -
-frandom-seed=0
# 1 crash.cpp
# 1 command-line
# 1 crash.cpp
int main()
{
 int foo = 42;
 struct
 {
  int bar = foo;
 } baz;
}


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.0-4ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.0 (Ubuntu/Linaro 4.7.0-4ubuntu2)

[Bug c++/53151] New: [C++11] Incorrect type deduction in conditional expression

[zeratul976 at hotmail dot com]

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

 Bug #: 53151
   Summary: [C++11] Incorrect type deduction in conditional
expression
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com


According to GCC, the type of T in the following is long:

template typename U U declval();
typedef decltype(true ? declvallong() : declvallong()) T;

I believe this is incorrect; the correct type of T is long

The reasoning is as follows (with sections from N3291):
  - Section 5.2.2/10 says that the result of calling a function whose return
type is an rvalue reference to an object type, is an xvalue. This tells us that
declvallong() is an xvalue.
  - Section 5.16/4 says that if the second and third operands to a conditional
expression are glvalues of the same value category and the same type, the
result is of that type and value category. In this case, both operands are
xvalues of the same type, so the whole expression is an xvalue (note that
xvalues are glvalues).
  - Finally, section 7.1.6.2/4 says that if e is an xvalue, decltype(e) is T
where T is the type of e.

It follows that the type of T should be long.


Once this is corrected, an adjustment needs to be made to the implementation of
the binary form of common_type:

templatetypename _Tp, typename _Up
struct common_type_Tp, _Up
{ typedef decltype(true ? declval_Tp() : declval_Up()) type; };

should become:

templatetypename _Tp, typename _Up
struct common_type_Tp, _Up
{ typedef typename remove_referencedecltype(true ? declval_Tp() :
declval_Up()) type::type type; };

(The current implementation causes problems when trying to compile standard
library headers with clang, as common_typelong, long::type evaluates to
long rather than long.)

[Bug c++/53151] [C++11] Incorrect type deduction in conditional expression

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-28 
03:46:11 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000

[Bug c++/53151] [C++11] Incorrect type deduction in conditional expression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-28 
03:47:51 UTC ---
This is an exact duplicate of PR 53000.  Read the PR for the reason why this
has not been fixed in GCC yet.

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

[Bug c++/53000] Conditional operator does not behave as standardized

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||zeratul976 at hotmail dot
   ||com

--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-28 
03:47:51 UTC ---
*** Bug 53151 has been marked as a duplicate of this bug. ***