[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions

[vogt at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188

--- Comment #3 from Dominik Vogt  ---
(In reply to kargl from comment #1)
> I assume you found this by using a libc with
> a malloc that has buffer overflow detection.

Actually, no.  We inspected the function manually looking for the
cause of a test FAIL of bessel_7.f90 and just stumbled across it.

> I'll commit this later.

Great.

[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[jan.capek at braiins dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180

--- Comment #5 from Jan Čapek  ---
(In reply to DJ Delorie from comment #4)
> Perhaps you need this patch:
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00993.html

DJ Delorie,

you are the man! The patch works as expected. Interestingly, the compiler now
honors the bitfield sizes even without explicitely specifying this options. The
resulting machine code output is:

.file   "test.c"
.section P,"ax"
.global _test
.type   _test, @function
_test:
pushm   r6-r11
add #-4, r0, r6
mov.L   r6, r0
mov.L   r1, [r6]
mov.L   [r6], r10
mov.W   [r10], r11 ; YES, read the entire register
or  #64, r11
mov.W   r11, [r10] ; YES, write the entire register
rtsd#28, r6-r11
.size   _test, .-_test
.ident  "GCC: (GNU) 4.9.0"


I have checked the 4.9 official branch and it still has not been included will
it go to the trunk/master branch?

Thanks again,

Jan

[Bug c++/62199] New: ICE with -Wlogical-not-parentheses

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62199

Bug ID: 62199
   Summary: ICE with -Wlogical-not-parentheses
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

int
foo (int a, int b)
{
  return !a || b == 10;
}

$ ./cc1plus -quiet p.C -Wlogical-not-parentheses
p.C: In function ‘int foo(int, int)’:
p.C:4:21: internal compiler error: tree check: expected class ‘expression’,
have ‘declaration’ (parm_decl) in tree_operand_check, at tree.h:3186
   return !a || b == 10;
 ^
0xe16466 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marek/src/gcc/gcc/tree.c:9200
0x506884 expr_check
/home/marek/src/gcc/gcc/tree.h:2898
0x506884 tree_operand_check
/home/marek/src/gcc/gcc/tree.h:3186
0x585a9c tree_operand_check(tree_node*, int, char const*, int, char const*)
/home/marek/src/gcc/gcc/tree.h:3174
0x6773ee cp_parser_binary_expression
/home/marek/src/gcc/gcc/cp/parser.c:8130
0x677807 cp_parser_assignment_expression
/home/marek/src/gcc/gcc/cp/parser.c:8274
[...]

[Bug c++/62199] ICE with -Wlogical-not-parentheses

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62199

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-20
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Mine.

[Bug target/62111] ICE when building Linux kernel for sh64

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111

--- Comment #12 from Oleg Endo  ---
(In reply to Segher Boessenkool from comment #11)
> Re: #c7:
> 
> In sh.c, change "char amount[6]" to "signed char
> amount[6]" -- does that help?

Hm, using 'signed char' instead of 'char' maybe could solve a few host related
problems such as PR 60111.  I think the 'char's should be replaced with things
like int8_t, uint8_t and bool in this case.
Anyway, this code paths should actually not be used when compiling for SHmedia.

[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996

--- Comment #3 from Oleg Endo  ---
Created attachment 33366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33366&action=edit
proposed patch for 5,4.9,4.8

David, could you please try out this patch and see if it fixes the issues for
you?  If so, I'll add a test case and commit it.

[Bug target/61360] [5 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360

--- Comment #8 from David Binderman  ---
Not sure if same or different - I am seeing

ChooseInitialTour.c:177:1: internal compiler error: in
lra_update_insn_recog_data, at lra.c:1218

from trunk 20140820.

ice goes away when I remove -march=native.

[Bug lto/62190] LTO DWARF produces __unknown__ type for unsigned int function argument type

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62190

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-20
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Ok, so the reason is that when C parses 'unsigned int' it somehow ends up using
uint32_type_node instead of unsigned_int_type_node and LTO only assigns
identifiers to a subset of all types (well, we're lazy...).

"Somehow ends up" because unsigned_type_node is pointer-equal to
uint64_type_node
for C.

I can see how this is annoying.  Will fix.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 214212)
+++ gcc/tree.c  (working copy)
@@ -9698,9 +9698,9 @@ build_common_tree_nodes (bool signed_cha
   integer_ptr_type_node = build_pointer_type (integer_type_node);

   /* Fixed size integer types.  */
-  uint16_type_node = build_nonstandard_integer_type (16, true);
-  uint32_type_node = build_nonstandard_integer_type (32, true);
-  uint64_type_node = build_nonstandard_integer_type (64, true);
+  uint16_type_node = make_or_reuse_type (16, 1);
+  uint32_type_node = make_or_reuse_type (32, 1);
+  uint64_type_node = make_or_reuse_type (64, 1);

   /* Decimal float types. */
   dfloat32_type_node = make_node (REAL_TYPE);

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov  ---
I can confirm this but I'm not sure that this has anything to do with r213806
(besides it triggering already existing problem). Libasan uses frame pointers
unconditionally to unwind stack on Darwin. By default 32-bit Darwins seem to
use -fomit-frame-pointer so unwinding can (and in our case does) fail. Adding
-fno-omit-frame-pointer to compile options fixed the problem for me. Perhaps we
should add this flag by default when running Asan tests on Darwin? Or maybe
libsanitizer could be updated to unwind with fp?

[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Our restrict support doesn't handle this case.

Note that I don't think the C standard defines what happens with restrict
qualified data members.  What is the "pointer" that is used for all the
"based-on" wording?  What is the "scope" of it?

Special-casing this very special case in points-to is possible, we already
have code to do that but it is "restricted" (heh).

static void
intra_create_variable_infos (struct function *fn)
{
  tree t;

  /* For each incoming pointer argument arg, create the constraint ARG
 = NONLOCAL or a dummy variable if it is a restrict qualified
 passed-by-reference argument.  */
  for (t = DECL_ARGUMENTS (fn->decl); t; t = DECL_CHAIN (t))
{
  varinfo_t p = get_vi_for_tree (t);

  /* For restrict qualified pointers to objects passed by
 reference build a real representative for the pointed-to object.
 Treat restrict qualified references the same.  */
  if (TYPE_RESTRICT (TREE_TYPE (t))
  && ((DECL_BY_REFERENCE (t) && POINTER_TYPE_P (TREE_TYPE (t)))
  || TREE_CODE (TREE_TYPE (t)) == REFERENCE_TYPE)
  && !type_contains_placeholder_p (TREE_TYPE (TREE_TYPE (t
{
...

which was implemented to support Fortran array descriptors with
restrict qualified data pointer.

So if you say we can treat any T * restrict parameter in that way
(no other global(!) or function parameter pointer may be used to
access the memory the fields in the struct pointed to by the
parameter), then fine.  Note that we restrict this to REFERENCEs
as pointers may point to an array of objects which I think we
don't treat correctly here (we need to know the size of the
object - with a pointer you can even access sth before what we point to).

This means supporting this may be difficult.  It may already work
if you use C++ and

static double __attribute__((noinline, noclone))
f (struct omp_data_i &__restrict__ p, int argc)
{

?  That is, if the middle-end uses a REFERENCE_TYPE?

[Bug tree-optimization/62171] restrict pointer to struct with restrict pointers parm doesn't prevent aliases

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62171

--- Comment #2 from Richard Biener  ---
And maybe set DECL_BY_REFERENCE, a mere REFERENCE_TYPE doesn't prevent
you from doing (¶m)[2] which we'd miscompile.  Not sure who added
that REFERENCE_TYPE code.

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

--- Comment #2 from Yury Gribov  ---
s/unwind with fp/unwind without fp/

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-20
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
The following patch fixes the failures:

--- ../_clean/gcc/testsuite/c-c++-common/asan/misalign-1.c2014-05-31
12:40:03.0 +0200
+++ gcc/testsuite/c-c++-common/asan/misalign-1.c2014-08-20
11:30:44.0 +0200
@@ -1,5 +1,6 @@
 /* { dg-do run { target { ilp32 || lp64 } } } */
 /* { dg-options "-O2" } */
+/* { dg-additional-options "-fno-omit-frame-pointer" { target *-*-darwin* } }
*/
 /* { dg-shouldfail "asan" } */

 struct S { int i; } __attribute__ ((packed));
--- ../_clean/gcc/testsuite/c-c++-common/asan/misalign-2.c2014-05-31
12:40:03.0 +0200
+++ gcc/testsuite/c-c++-common/asan/misalign-2.c2014-08-20
11:30:56.0 +0200
@@ -1,5 +1,6 @@
 /* { dg-do run { target { ilp32 || lp64 } } } */
 /* { dg-options "-O2" } */
+/* { dg-additional-options "-fno-omit-frame-pointer" { target *-*-darwin* } }
*/
 /* { dg-shouldfail "asan" } */

 struct S { int i; } __attribute__ ((packed));

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

--- Comment #4 from Yury Gribov  ---
Note that same problem may pop up in other tests as well so IMHO better fix
this in general.

[Bug libstdc++/62200] New: libstdc++ initialization priority

[vhaisman at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62200

Bug ID: 62200
   Summary: libstdc++ initialization priority
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vhaisman at gmail dot com

I am trying to initialize my library early using the `init_priority` attribute.
Some paths of my library's initialization might try to print warnings and/or
errors. I have hit a SIGSEGV with the following test case, which uses
std::cerr. According to some, the library should initialize with priority 101.
If this were the case I would expect the test case to work flawlessly.


#include 

struct S1
{
S1() { std::cerr << __FUNCTION__ << "\n"; }
} static s1 __attribute__ ((__init_priority__ (65535/2)));


int
main ()
{
  return 0;
}


The stack trace is


#0  0x77b6a559 in std::ostream::sentry::sentry(std::ostream&) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x77b6ac19 in std::basic_ostream >&
std::__ostream_insert >(std::basic_ostream >&, char const*, long)
() from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x77b6b077 in std::basic_ostream >&
std::operator<<  >(std::basic_ostream >&, char const*) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x0040081d in S1::S1 (this=0x601172 ) at test.cxx:5
#4  0x004007d6 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=32767) at test.cxx:6
#5  0x004007eb in _GLOBAL__sub_I.32767_main(void) () at test.cxx:13
#6  0x0040087d in __libc_csu_init ()
#7  0x77731e55 in __libc_start_main (main=0x40077d , argc=1,
argv=0x7fffe2c8, init=0x400830 <__libc_csu_init>, fini=,
rtld_fini=,
stack_end=0x7fffe2b8) at libc-start.c:246
#8  0x004006b9 in _start ()

[Bug libstdc++/62200] libstdc++ initialization priority

[vhaisman at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62200

--- Comment #1 from Václav Zeman  ---
And it dumps core on Cygwin as well.

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

--- Comment #5 from Iain Sandoe  ---
(In reply to Yury Gribov from comment #4)
> Note that same problem may pop up in other tests as well so IMHO better fix
> this in general.

Well, we could switch frame pointers in the [darwin.h] asan spec, but I'm a bit
inclined to leave this under User control and just accept that we need to keep
an eye on test-cases.

Will think some more about doing it automatically, but suggest that we
immediately fix these cases for now with Dominique's patch.

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

--- Comment #6 from Iain Sandoe  ---
(In reply to Yury Gribov from comment #2)
> s/unwind with fp/unwind without fp/

it should be possible to do this, if m32 code is compiled with
"-funwind-tables".

for m64, that's already the default and, also for m32 when -fexceptions is
given.

[Bug c++/62201] New: ICE with -Wlogical-not-parentheses: tree check: expected class ‘expression’, have ‘exceptional’

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62201

Bug ID: 62201
   Summary: ICE with -Wlogical-not-parentheses: tree check:
expected class ‘expression’, have ‘exceptional’
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org

The issue appeared using valid code; the delta reduced code fails the same way,
but is obviously invalid:

g++ -S -Wlogical-not-parentheses test8.ii

Test case:

template= __m - 1), 
bool __schrage_ok = __m % __a < __m / __a>   struct _Mod   {


Error message:

test8.ii:1:142: internal compiler error: tree check: expected class
‘expression’, have ‘exceptional’ (template_parm_index) in tree_operand_check,
at tree.h:3186
  template= __m - 1), 
bool __schrage_ok = __m % __a < __m / __a>   struct _Mod   {
   
  ^
0xe5b8b7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9200
0x56dff7 expr_check(tree_node*, char const*, int, char const*)
../../gcc/tree.h:2898
0x56dff7 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3186
0x6ec932 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:2932
0x6ec932 cp_parser_binary_expression
../../gcc/cp/parser.c:8130
0x6ec9cb cp_parser_assignment_expression
../../gcc/cp/parser.c:8271

[Bug c++/62199] ICE with -Wlogical-not-parentheses

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62199

Marek Polacek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
*** Bug 62201 has been marked as a duplicate of this bug. ***

[Bug c++/62201] ICE with -Wlogical-not-parentheses: tree check: expected class ‘expression’, have ‘exceptional’

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62201

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
Dup.  Working on it.

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

[Bug lto/62190] LTO DWARF produces __unknown__ type for unsigned int function argument type

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62190

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Aug 20 11:06:48 2014
New Revision: 214216

URL: https://gcc.gnu.org/viewcvs?rev=214216&root=gcc&view=rev
Log:
2014-08-20  Richard Biener  

PR lto/62190
* tree.c (build_common_tree_nodes): Use make_or_reuse_type
to build uint{16,32,64}_type_node.

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

[Bug lto/62190] LTO DWARF produces __unknown__ type for unsigned int function argument type

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62190

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug target/62098] [4.9/5 regression] incorrect code generated by arm gcc

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098

--- Comment #4 from Ramana Radhakrishnan  ---
Author: ramana
Date: Wed Aug 20 11:31:21 2014
New Revision: 214217

URL: https://gcc.gnu.org/viewcvs?rev=214217&root=gcc&view=rev
Log:
Backport fix for PR target/62098

2014-08-20  Ramana Radhakrishnan  

Backport from mainline.
2014-08-12  Ramana Radhakrishnan  
PR target/62098
* config/arm/vfp.md (*combine_vcvtf2i): Fix constraint.
Remove unnecessary attributes.



Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/vfp.md

[Bug target/62098] [4.9/5 regression] incorrect code generated by arm gcc

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail|4.10.0  |5.0

--- Comment #5 from Ramana Radhakrishnan  ---
Fixed now.

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #6 from Dominique d'Humieres  ---
Created attachment 33367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33367&action=edit
Preprocessed and assembly files for gcc and clang

Preprocessed and assembly files for gcc (ftrapv-1_gcc.(i|s)) and clang
(ftrapv-1_clang.(i|s)).

[Bug c++/62202] New: g++ does not accept typedef-name after struct even if -fpermissive is used

[bugzi...@poradnik-webmastera.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62202

Bug ID: 62202
   Summary: g++ does not accept typedef-name after struct even if
-fpermissive is used
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com

gcc silently compiles this, even with -Wall -Wextra -pedantic:

struct test_s { int n; };
typedef struct test_s test_t;
typedef struct test_t* something_t;
int main() { return 0; }

g++ reports following error even if -fpermissive option is used:
test.c:3:16: error: using typedef-name ‘test_t’ after ‘struct’
 typedef struct test_t* something_t;
^
test.c:2:23: note: ‘test_t’ has a previous declaration here
 typedef struct test_s test_t;
   ^
test.c:3:35: error: invalid type in declaration before ‘;’ token
 typedef struct test_t* something_t;
   ^

Please extend permissive mode to accept such case too. Also consider printing
warning when compiling C code.

[Bug c/59304] #pragma diagnostic pop after warning fails for options unspecified in the command-line and disabled by default

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304

--- Comment #7 from Manuel López-Ibáñez  ---
Author: manu
Date: Wed Aug 20 12:48:16 2014
New Revision: 214221

URL: https://gcc.gnu.org/viewcvs?rev=214221&root=gcc&view=rev
Log:
gcc/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR c/59304
* opts-common.c (set_option): Call diagnostic_classify_diagnostic
before setting the option.
* diagnostic.c (diagnostic_classify_diagnostic): Record
command-line status.

gcc/testsuite/ChangeLog:

2014-08-20  Manuel López-Ibáñez  

PR c/59304
* gcc.dg/pr59304.c: New test.



Added:
trunk/gcc/testsuite/gcc.dg/pr59304.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic.c
trunk/gcc/opts-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c/59304] #pragma diagnostic pop after warning fails for options unspecified in the command-line and disabled by default

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Manuel López-Ibáñez  ---
Fixed in gcc 5.0

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
Bug 58876 depends on bug 59304, which changed state.

Bug 59304 Summary: #pragma diagnostic pop after warning fails for options 
unspecified in the command-line and disabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c/62203] New: arm-rtems ICE compiling libgcc/fixed-bit.c

[joel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203

Bug ID: 62203
   Summary: arm-rtems ICE compiling libgcc/fixed-bit.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

I can provide more details but since this is just with compiling libgcc, I
doubt that much else is needed.

I last built this target on:

arm-rtems4.11-gcc (GCC) 5.0.0 20140818 (experimental)


/users/joel/test-gcc/b-arm-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-arm-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-arm-rtems4.11-gcc/arm-rtems4.11/newlib/ -isystem
/users/joel/test-gcc/b-arm-rtems4.11-gcc/arm-rtems4.11/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/arm-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/arm-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/arm-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/arm-rtems4.11/sys-include-g -O2 -mthumb
-march=armv7-a -O2 -I../../../../../gcc/libgcc/../newlib/libc/sys/rtems/include
-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fno-inline -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fno-inline -I. -I.
-I../../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/.
-I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS  -o _saturate2UDQ.o -MT _saturate2UDQ.o -MD -MP -MF
_saturate2UDQ.dep -DL_saturate2 -DUDQ_MODE -c
../../../../../gcc/libgcc/fixed-bit.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../../gcc/libgcc/fixed-bit.c: In function '__gnu_saturate2udq':
../../../../../gcc/libgcc/fixed-bit.c:246:1: internal compiler error:
Segmentation fault
 }
 ^
0x8dab0f crash_signal
../../gcc/gcc/toplev.c:337
0x577583 bool is_a_helper::test(rtx_def*)
../../gcc/gcc/rtl.h:687
0x577583 bool is_a(rtx_def*)
../../gcc/gcc/is-a.h:182
0x577583 rtx_insn* as_a(rtx_def*)
../../gcc/gcc/is-a.h:192
0x577583 duplicate_insn_chain(rtx_def*, rtx_def*)
../../gcc/gcc/cfgrtl.c:4169
0x8b2299 dup_block_and_redirect(basic_block_def*, basic_block_def*, rtx_def*,
bitmap_head*)
../../gcc/gcc/shrink-wrap.c:389
0x8b34ec try_shrink_wrapping(edge_def**, edge_def*, bitmap_head*, rtx_def*)
../../gcc/gcc/shrink-wrap.c:748
0x6ce5f4 thread_prologue_and_epilogue_insns
../../gcc/gcc/function.c:5691
0x6ce5f4 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6242
0x6ce5f4 execute
../../gcc/gcc/function.c:6280
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [_saturate2UDQ.o] Error 1
make[4]: Leaving directory
`/users/joel/test-gcc/b-arm-rtems4.11-gcc/arm-rtems4.11/thumb/armv7-a/libgcc'

[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dmalcolm at redhat dot com,
   ||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Sounds like the ICE fixed by David Malcolm:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01971.html

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62132

--- Comment #7 from Yury Gribov  ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Yury Gribov from comment #2)
> > s/unwind with fp/unwind without fp/
> 
> it should be possible to do this, if m32 code is compiled with
> "-funwind-tables".

This was my impression as well but it looks like current libsanitizer does not
support anything except fp on Macs. Could you report this on address-sanitizer
tracker (https://code.google.com/p/address-sanitizer/issues/list)?

[Bug c/62141] [GCC-4.10.0][ASAN] ICE: Segmentation fault: 11

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62141

Yury Gribov  changed:

   What|Removed |Added

 CC||jakub at redhat dot com,
   ||polacek at redhat dot com,
   ||y.gribov at samsung dot com

--- Comment #3 from Yury Gribov  ---
Added sanitizer folks.

[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c

[dmalcolm at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203

--- Comment #2 from Dave Malcolm  ---
Sorry about this; I believe I introduced this in r214197, and fixed it in
r214207.

[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c

[joel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203

--- Comment #3 from Joel Sherrill  ---
Could your change have impacted multiple targets? I see ICE on i386, nios2,
powerpc, and sh.

I would be happy to learn I just started a sweep at an unfortunate point. I
have updated my gcc tree and will start another one. If ok, I will then close
this.

[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c

[dmalcolm at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203

--- Comment #4 from Dave Malcolm  ---
(In reply to Joel Sherrill from comment #3)
> Could your change have impacted multiple targets? I see ICE on i386, nios2,
> powerpc, and sh.

Yes.  Sorry again.

> I would be happy to learn I just started a sweep at an unfortunate point. I
> have updated my gcc tree and will start another one. If ok, I will then
> close this.

[Bug c++/62175] Internal compiler error in gimplify_modify_expr gimplify.c:4616

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62175

--- Comment #3 from Richard Biener  ---
Created attachment 33368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33368&action=edit
somewhat autoreduced testcsae

very slow to reduce.  attaching what I have.

[Bug c++/62204] New: internal compiler error with -Wall

[koes at cmu dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62204

Bug ID: 62204
   Summary: internal compiler error with -Wall
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koes at cmu dot edu

Created attachment 33369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33369&action=edit
preprocessed file for reproducing -Wall related bug

I get an internal compiler error when compiling pharmer (http://pharmer.sf.net)
under Ubuntu 14.04 with the packaged g++ 4.8.2 and with a version of 4.8.3 I
built myself (../configure --enable-languages=c,c++,fortran x86_64-linux-gnu
).  The problem may also be present in 4.9.1, but manifest differently.

The command line to reproduce this error in 4.8.2/4.8.3 is:
 g++  -O3 -Wall -c   main.ii

Interestingly, there is another file in the build that gets a similar error
(PharmerQuery.cpp). For this file removing -Wall does not resolve the crash,
but passing -save-temps does, so it is difficult to provide a preprocessed
file. g++ 4.9.1 also cannot compile this file, although with 4.9.1 this ICE
goes away with the removal of -Wall (as well as -save-temps).

Below I've pasted both the output for main.ii (where removing -Wall fixes the
problem) and the output for PharmerQuery.cpp (where I can't provide a .ii
file).

koes@nova:~/workspace/pharmer/Release$ g++  -O3 -Wall -c   main.ii -v
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran x86_64-linux-gnu
Thread model: posix
gcc version 4.8.3 (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-Wall' '-c' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /raid/usr/local/bin/../libexec/gcc/x86_64-linux-gnu/4.8.3/cc1plus
-fpreprocessed main.ii -quiet -dumpbase main.ii -mtune=generic -march=x86-64
-auxbase main -O3 -Wall -version -o /tmp/ccpGqbNt.s
GNU C++ (GCC) version 4.8.3 (x86_64-linux-gnu)
compiled by GNU C version 4.8.3, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.3 (x86_64-linux-gnu)
compiled by GNU C version 4.8.3, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1cbd2130c9c03c77c4428f506cfeafb2
In file included from /usr/include/boost/algorithm/string/split.hpp:16:0,
 from /usr/include/boost/algorithm/string.hpp:23,
 from ../queryparsers.h:34,
 from ../main.cpp:44:
/usr/include/boost/algorithm/string/iter_find.hpp: In instantiation of
‘SequenceSequenceT& boost::algorithm::iter_split(SequenceSequenceT&, RangeT&,
FinderT) [with SequenceSequenceT = std::vector >;
RangeT = std::basic_string; FinderT =
boost::algorithm::detail::token_finderF]’:
/usr/include/boost/algorithm/string/split.hpp:149:69:   required from
‘SequenceSequenceT& boost::algorithm::split(SequenceSequenceT&, RangeT&,
PredicateT, boost::algorithm::token_compress_mode_type) [with SequenceSequenceT
= std::vector >; RangeT = std::basic_string;
PredicateT = int (*)(int)throw ()]’
../queryparsers.h:237:50:   required from here
/usr/include/boost/algorithm/string/iter_find.hpp:182:9: internal compiler
error: Segmentation fault
 }
 ^
0x89ffdf crash_signal
../../gcc/toplev.c:332
0x5b236a c_tree_chain_next
../../gcc/c-family/c-common.h:1058
0x5b236a gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:158
0x5b2d01 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:495
0x5b3346 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:520
0x5b3743 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:509
0x5b3989 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:260
0x5cd8a5 gt_ggc_mx_cp_binding_level(void*)
./gt-cp-name-lookup.h:64
0x5b269f gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:659
0x5b3787 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:366
0x5b2c84 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:476
0x5b3885 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:243
0x5cd993 gt_ggc_mx_cxx_binding(void*)
./gt-cp-name-lookup.h:87
0x5b269f gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:659
0x5b3787 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:366
0x5b3755 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:510
0x5b4089 gt_ggc_mx_lang_type(void*)
./gt-cp-tree.h:795
0x5b2d4a gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:500
0x5b2d39 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:499
0x5b376b gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:364
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



g++ -DOUTPUTSMINA -DEIGEN_DISABLE_STACK_SIZE_ASSERT
-I/usr/

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191

--- Comment #16 from Steve Ellcey  ---
Author: sje
Date: Wed Aug 20 15:56:45 2014
New Revision: 214226

URL: https://gcc.gnu.org/viewcvs?rev=214226&root=gcc&view=rev
Log:
2014-08-20  Steve Ellcey  

PR middle-end/49191
* doc/sourcebuild.texi (non_strict_align): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191

--- Comment #17 from Steve Ellcey  ---
Author: sje
Date: Wed Aug 20 15:57:42 2014
New Revision: 214227

URL: https://gcc.gnu.org/viewcvs?rev=214227&root=gcc&view=rev
Log:
2014-08-20  Steve Ellcey  

PR middle-end/49191
* lib/target-supports.exp (check_effective_target_non_strict_align):
Add function description.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091

--- Comment #13 from Jan Hubicka  ---
Thanks, Jason!
This is patch I am testing that cures the testcase from Comment #7. I would
apprechiate if someone could reduce it - my simple attempts has failed and I am
bit in hurry this week.

The problem here is that get_dynamic_class gets into placement new paranoia
because
it manages to mismatch polymorphic_type[2] with polymorphic_type.

Honza

Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 214225)
+++ ipa-devirt.c(working copy)
@@ -2846,6 +2891,18 @@ ipa_polymorphic_call_context::get_dynami
   bool function_entry_reached = false;
   tree instance_ref = NULL;
   gimple stmt = call;
+  /* Remember OFFSET before it is modified by restrict_to_inner_class.
+ This is because we do not update INSTANCE when walking inwards.  */
+  HOST_WIDE_INT instance_offset = offset;
+
+  /* Walk into inner type. This may clear maybe_derived_type and save us
+ from useless work.  It also makes later comparsions with static type
+ easier.  */
+  if (outer_type)
+{
+  if (!restrict_to_inner_class (otr_type))
+return false;
+}

   if (!maybe_in_construction && !maybe_derived_type)
 return false;

[Bug fortran/62176] [OOP] Inconsistent resolution of GENERIC interface

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62176

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-20
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Reduced test

module m_string
  implicit none

  type t_string
  character, dimension(:), allocatable :: buffer
  integer :: length = 0
  integer :: size = 0

contains

! Interfaces for string types
  generic :: character => string_to_char
  procedure :: string_to_char

! Element comparison operators
  procedure :: string_less_equal_char
  procedure, pass(right) :: char_less_equal_string
  generic :: operator(<=) => string_less_equal_char, &
 char_less_equal_string

! Character compatibility interfaces  
  generic :: lle => string_less_equal_char, &
char_less_equal_string

end type t_string

contains

! Return the string as character
pure function string_to_char( this ) result(res)
  class(t_string), intent(in) :: this
  character(len=this%size) :: res
  if( allocated(this%buffer) ) then
res = transfer( this%buffer(:this%size), res )
  else
res = ''
  end if
end function string_to_char

! Comparison operator 'string <= character'
elemental function string_less_equal_char( left, right ) result(res)
  class(t_string), intent(in) :: left
  character(len=*), intent(in) :: right
  logical :: res
  res = ( left%character() <= right )
end function string_less_equal_char

! Comparison operator 'character <= string'
elemental function char_less_equal_string( left, right ) result(res)
  character(len=*), intent(in) :: left
  class(t_string), intent(in) :: right
  logical :: res
  res = ( left <= right%character() )
end function char_less_equal_string

end module m_string

The code compiles if the lines

  generic :: lle => string_less_equal_char, &
char_less_equal_string

are commented. I cannot see how 'string_less_equal_char' and
'char_less_equal_string' are ambiguous for 'lle', but not for operator '<='.

[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Aug 20 16:18:27 2014
New Revision: 214229

URL: https://gcc.gnu.org/viewcvs?rev=214229&root=gcc&view=rev
Log:
2014-08-20  Steven G. Kargl  

PR libgfortran/62188
* m4/bessel.m4: Avoid indexing off the end of an array.
* generated/bessel_r10.c: Regenerated.
* generated/bessel_r16.c: Ditto.
* generated/bessel_r4.c: Ditto.
* generated/bessel_r8.c: Ditto.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/bessel_r10.c
trunk/libgfortran/generated/bessel_r16.c
trunk/libgfortran/generated/bessel_r4.c
trunk/libgfortran/generated/bessel_r8.c
trunk/libgfortran/m4/bessel.m4

[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091

--- Comment #14 from Markus Trippelsdorf  ---
Reduced testcase for  Comment #7:

typedef enum
{
} UErrorCode;
class UnicodeString
{
public:
  UnicodeString ();
  virtual ~UnicodeString ();
};
class A
{
  UnicodeString &m_fn1 (UnicodeString &, int &p2, UErrorCode &) const;
};
UnicodeString::UnicodeString () {}
UnicodeString &
A::m_fn1 (UnicodeString &, int &p2, UErrorCode &) const
{
  UnicodeString a[2];
}

[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Aug 20 16:23:55 2014
New Revision: 214231

URL: https://gcc.gnu.org/viewcvs?rev=214231&root=gcc&view=rev
Log:
2014-08-20  Steven G. Kargl  

PR libgfortran/62188
* m4/bessel.m4: Avoid indexing off the end of an array.
* generated/bessel_r10.c: Regenerated.
* generated/bessel_r16.c: Ditto.
* generated/bessel_r4.c: Ditto.
* generated/bessel_r8.c: Ditto.

Modified:
branches/gcc-4_8-branch/libgfortran/ChangeLog
branches/gcc-4_8-branch/libgfortran/generated/bessel_r10.c
branches/gcc-4_8-branch/libgfortran/generated/bessel_r16.c
branches/gcc-4_8-branch/libgfortran/generated/bessel_r4.c
branches/gcc-4_8-branch/libgfortran/generated/bessel_r8.c
branches/gcc-4_8-branch/libgfortran/m4/bessel.m4

[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Aug 20 16:22:20 2014
New Revision: 214230

URL: https://gcc.gnu.org/viewcvs?rev=214230&root=gcc&view=rev
Log:
2014-08-20  Steven G. Kargl  

PR libgfortran/62188
* m4/bessel.m4: Avoid indexing off the end of an array.
* generated/bessel_r10.c: Regenerated.
* generated/bessel_r16.c: Ditto.
* generated/bessel_r4.c: Ditto.
* generated/bessel_r8.c: Ditto.

Modified:
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/generated/bessel_r10.c
branches/gcc-4_9-branch/libgfortran/generated/bessel_r16.c
branches/gcc-4_9-branch/libgfortran/generated/bessel_r4.c
branches/gcc-4_9-branch/libgfortran/generated/bessel_r8.c
branches/gcc-4_9-branch/libgfortran/m4/bessel.m4

[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Dominik Vogt from comment #3)
> (In reply to kargl from comment #1)
> > I assume you found this by using a libc with
> > a malloc that has buffer overflow detection.
> 
> Actually, no.  We inspected the function manually looking for the
> cause of a test FAIL of bessel_7.f90 and just stumbled across it.

Ah, bessel_7.f90.  This test has some tolerances that are at the
very edge of numerical accuracy.  If your underlying libm implementation
of yn is poor, you'll get FAIL[ures].

> > I'll commit this later.
> 
> Great.

Committed to trunk and all open branches.

Thanks for the bug report.

[Bug ada/62205] New: GNAT does not accept class types for Default_Iterator

[porton at narod dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62205

Bug ID: 62205
   Summary: GNAT does not accept class types for Default_Iterator
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: porton at narod dot ru

Created attachment 33370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33370&action=edit
An Ada file whose semantics does not verify

I attach an Ada package file which does not verify:

gprbuild -q -c -gnatc -u -P/home/porton/t/default.gpr test.ads --subdirs=check
-cargs:Ada -g -O0 -gnato -fstack-check -gnatVa -cargs:C -g -O0 -fstack-check
-cargs:C++ -g -O0 -fstack-check
test.ads:19:28: Default Iterator must be a primitive of "Descriptions_List"
gprbuild: *** compilation phase failed

But from Ada Reference Manual 2012 (5.5.1 8/3):

[[[
Default_Iterator

This aspect is specified by a name that denotes exactly one function declared
immediately within the same declaration list in which T is declared, whose
first parameter is of type T or T'Class or an access parameter whose designated
type is type T or T'Class, whose other parameters, if any, have default
expressions, and whose result type is an iterator type.
]]]

That is T'Class (in our case Descriptions_List'Class) should work.

I think this is a bug in GNAT 4.9.1.

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

[mkuvyrkov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mkuvyrkov at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mkuvyrkov at gcc dot 
gnu.org

[Bug middle-end/61776] [4.9/5 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[wmi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776

--- Comment #8 from wmi at gcc dot gnu.org ---
Author: wmi
Date: Wed Aug 20 16:47:12 2014
New Revision: 214233

URL: https://gcc.gnu.org/viewcvs?rev=214233&root=gcc&view=rev
Log:
2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* tree-ssa-operands.c (update_stmt_operands): Remove
MODIFIED_NORETURN_CALLS.
* tree-cfgcleanup.c (cleanup_call_ctrl_altering_flag): New func.
(cleanup_control_flow_bb): Use cleanup_call_ctrl_altering_flag.
(split_bb_on_noreturn_calls): Renamed from split_bbs_on_noreturn_calls.
(cleanup_tree_cfg_1): Use split_bb_on_noreturn_calls.
* tree-ssanames.h: Remove MODIFIED_NORETURN_CALLS.
* gimple.h (enum gf_mask): Add GF_CALL_CTRL_ALTERING.
(gimple_call_set_ctrl_altering): New func.
(gimple_call_ctrl_altering_p): Ditto.
* tree-cfg.c (gimple_call_initialize_ctrl_altering): Ditto.
(make_blocks): Use gimple_call_initialize_ctrl_altering.
(is_ctrl_altering_stmt): Use gimple_call_ctrl_altering_p.
(execute_fixup_cfg): Use gimple_call_ctrl_altering_p and
remove MODIFIED_NORETURN_CALLS.

2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* testsuite/gcc.dg/lto/pr60449_1.c: New test.
* testsuite/gcc.dg/lto/pr60449_0.c: New test.
* testsuite/gcc.dg/pr61776.c: New test.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-cfgcleanup.c
trunk/gcc/tree-ssa-operands.c
trunk/gcc/tree-ssanames.h

[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail

[wmi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449

--- Comment #16 from wmi at gcc dot gnu.org ---
Author: wmi
Date: Wed Aug 20 16:47:12 2014
New Revision: 214233

URL: https://gcc.gnu.org/viewcvs?rev=214233&root=gcc&view=rev
Log:
2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* tree-ssa-operands.c (update_stmt_operands): Remove
MODIFIED_NORETURN_CALLS.
* tree-cfgcleanup.c (cleanup_call_ctrl_altering_flag): New func.
(cleanup_control_flow_bb): Use cleanup_call_ctrl_altering_flag.
(split_bb_on_noreturn_calls): Renamed from split_bbs_on_noreturn_calls.
(cleanup_tree_cfg_1): Use split_bb_on_noreturn_calls.
* tree-ssanames.h: Remove MODIFIED_NORETURN_CALLS.
* gimple.h (enum gf_mask): Add GF_CALL_CTRL_ALTERING.
(gimple_call_set_ctrl_altering): New func.
(gimple_call_ctrl_altering_p): Ditto.
* tree-cfg.c (gimple_call_initialize_ctrl_altering): Ditto.
(make_blocks): Use gimple_call_initialize_ctrl_altering.
(is_ctrl_altering_stmt): Use gimple_call_ctrl_altering_p.
(execute_fixup_cfg): Use gimple_call_ctrl_altering_p and
remove MODIFIED_NORETURN_CALLS.

2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* testsuite/gcc.dg/lto/pr60449_1.c: New test.
* testsuite/gcc.dg/lto/pr60449_0.c: New test.
* testsuite/gcc.dg/pr61776.c: New test.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-cfgcleanup.c
trunk/gcc/tree-ssa-operands.c
trunk/gcc/tree-ssanames.h

[Bug c++/62206] New: Gcc doesn't optimize methods in template class, even when they don't depend on the template variable

[tohava at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62206

Bug ID: 62206
   Summary: Gcc doesn't optimize methods in template class, even
when they don't depend on the template variable
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tohava at gmail dot com

Take a look at the following code:

#include 

template 
class C {
public:
static int foobar() { printf("helloworld\n"); }
};

int main() {
C::foobar();
C::foobar();
}

Since olga_rocks is not dependent on the template parameter T, I would expect
gcc to generate only a single version of `olga_rocks`. However, it generates
two identical versions instead, even when compiling with `-O3 -fno-inline`.

[Bug c++/62206] Gcc doesn't optimize methods in template class, even when they don't depend on the template variable

[tohava at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62206

ori bar  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/62206] Gcc doesn't optimize methods in template class, even when they don't depend on the template variable

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62206

--- Comment #1 from Andrew Pinski  ---
>I would expect gcc to generate only a single version of `olga_rocks`.

Well it has to generate two different functions, that is:
C::foobar != C::foobar
has to hold true.

[Bug c/62198] spurious warning - initialization discards qualifier from pointer target type for pointer to array

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198

--- Comment #1 from joseph at codesourcery dot com  ---
Sounds like a Clang bug to me.  The type pointed to by "const int (*)[10]" 
is "array of 10 const int", which is not a const-qualified type.

[Bug middle-end/61776] [4.9/5 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[wmi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776

--- Comment #9 from wmi at gcc dot gnu.org ---
Author: wmi
Date: Wed Aug 20 17:09:25 2014
New Revision: 214237

URL: https://gcc.gnu.org/viewcvs?rev=214237&root=gcc&view=rev
Log:
2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* tree-ssa-operands.c (update_stmt_operands): Remove
MODIFIED_NORETURN_CALLS.
* tree-cfgcleanup.c (cleanup_call_ctrl_altering_flag): New func.
(cleanup_control_flow_bb): Use cleanup_call_ctrl_altering_flag.
(split_bb_on_noreturn_calls): Renamed from split_bbs_on_noreturn_calls.
(cleanup_tree_cfg_1): Use split_bb_on_noreturn_calls.
* tree-ssanames.h: Remove MODIFIED_NORETURN_CALLS.
* gimple.h (enum gf_mask): Add GF_CALL_CTRL_ALTERING.
(gimple_call_set_ctrl_altering): New func.
(gimple_call_ctrl_altering_p): Ditto.
* tree-cfg.c (gimple_call_initialize_ctrl_altering): Ditto.
(make_blocks): Use gimple_call_initialize_ctrl_altering.
(is_ctrl_altering_stmt): Use gimple_call_ctrl_altering_p.
(execute_fixup_cfg): Use gimple_call_ctrl_altering_p and
remove MODIFIED_NORETURN_CALLS.

2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* testsuite/gcc.dg/lto/pr60449_1.c: New test.
* testsuite/gcc.dg/lto/pr60449_0.c: New test.
* testsuite/gcc.dg/pr61776.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr60449_0.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr60449_1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61776.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/gimple.h
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-cfg.c
branches/gcc-4_9-branch/gcc/tree-cfgcleanup.c
branches/gcc-4_9-branch/gcc/tree-ssa-operands.c
branches/gcc-4_9-branch/gcc/tree-ssanames.h

[Bug c++/62206] Gcc doesn't optimize methods in template class, even when they don't depend on the template variable

[tohava at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62206

--- Comment #2 from ori bar  ---
It can still generate two different functions which are just single jump
instructions to the same code.

Also, does the C++ standard say that your inequality must be true?

[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail

[wmi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449

--- Comment #17 from wmi at gcc dot gnu.org ---
Author: wmi
Date: Wed Aug 20 17:09:25 2014
New Revision: 214237

URL: https://gcc.gnu.org/viewcvs?rev=214237&root=gcc&view=rev
Log:
2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* tree-ssa-operands.c (update_stmt_operands): Remove
MODIFIED_NORETURN_CALLS.
* tree-cfgcleanup.c (cleanup_call_ctrl_altering_flag): New func.
(cleanup_control_flow_bb): Use cleanup_call_ctrl_altering_flag.
(split_bb_on_noreturn_calls): Renamed from split_bbs_on_noreturn_calls.
(cleanup_tree_cfg_1): Use split_bb_on_noreturn_calls.
* tree-ssanames.h: Remove MODIFIED_NORETURN_CALLS.
* gimple.h (enum gf_mask): Add GF_CALL_CTRL_ALTERING.
(gimple_call_set_ctrl_altering): New func.
(gimple_call_ctrl_altering_p): Ditto.
* tree-cfg.c (gimple_call_initialize_ctrl_altering): Ditto.
(make_blocks): Use gimple_call_initialize_ctrl_altering.
(is_ctrl_altering_stmt): Use gimple_call_ctrl_altering_p.
(execute_fixup_cfg): Use gimple_call_ctrl_altering_p and
remove MODIFIED_NORETURN_CALLS.

2014-08-20  Martin Jambor  
Wei Mi  

PR ipa/60449
PR middle-end/61776
* testsuite/gcc.dg/lto/pr60449_1.c: New test.
* testsuite/gcc.dg/lto/pr60449_0.c: New test.
* testsuite/gcc.dg/pr61776.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr60449_0.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/lto/pr60449_1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61776.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/gimple.h
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-cfg.c
branches/gcc-4_9-branch/gcc/tree-cfgcleanup.c
branches/gcc-4_9-branch/gcc/tree-ssa-operands.c
branches/gcc-4_9-branch/gcc/tree-ssanames.h

[Bug c++/62207] New: ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in tsubst_copy, at cp/pt.c

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62207

Bug ID: 62207
   Summary: ICE: tree check: expected tree that contains 'decl
minimal' structure, have 'overload' in tsubst_copy, at
cp/pt.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org

The following invalid file (found while reducing a different ICE) prints
several errors and ends with:

file.cpp:16:3: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'overload' in tsubst_copy, at cp/pt.c:12846
   ptr
   ^
0xe314e4 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/data/repos/gcc/pristine/gcc/tree.c:9321
0x62a998 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/data/repos/gcc/pristine/gcc/tree.h:2843
0x62a998 tsubst_copy
/data/repos/gcc/pristine/gcc/cp/pt.c:12846
0x630ee9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/data/repos/gcc/pristine/gcc/cp/pt.c:15420
0x612f93 tsubst_expr
/data/repos/gcc/pristine/gcc/cp/pt.c:14239
0x613391 tsubst_expr
/data/repos/gcc/pristine/gcc/cp/pt.c:13665
0x6128a3 tsubst_expr
/data/repos/gcc/pristine/gcc/cp/pt.c:13651
0x613533 tsubst_expr
/data/repos/gcc/pristine/gcc/cp/pt.c:13837
0x61104e instantiate_decl(tree_node*, int, bool)
/data/repos/gcc/pristine/gcc/cp/pt.c:20176
0x6569e4 instantiate_pending_templates(int)
/data/repos/gcc/pristine/gcc/cp/pt.c:20292
0x69352d cp_write_global_declarations()
/data/repos/gcc/pristine/gcc/cp/decl2.c:4355



class A {
  virtual create() const
} class PostModNothing class AllocatorNew;
template <0> void ptr();
template  class AbstractFactoryStd : A {
  create() const
} template  abstractFactoryStd() {
  new AbstractFactoryStd
}
template 
typename a
: obj_ptr_t
  AbstractFactoryStd::create()
  const const const {
  typename T_Allocator : ptr_t ptr;
  ptr
}
enableMueLuTpetra() {
  typedef int Base;
  typedef int Impl;
Teuchos:
abstractFactoryStd

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |WAITING
  Known to fail|4.10.0  |5.0

--- Comment #4 from Kai Tietz  ---
Issue got fixed on mingw-w64's side by providing on trunk ftw/nftw API.
Nevertheless it would be good that for ftw include and use at least a
header-check is done.  That gcov data isn't deleted isn't necessarily that bad.
 IMO better then disabling complete tool.

[Bug lto/62208] New: ICE with LTO on valid code at -O3 on x86_64-linux-gnu in trunc_int_for_mode, at explow.c:56

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62208

Bug ID: 62208
   Summary: ICE with LTO on valid code at -O3 on x86_64-linux-gnu
in trunc_int_for_mode, at explow.c:56
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk with
LTO at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode).

It is a regression from 4.9.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20140820 (experimental) [trunk revision 214209] (GCC) 
$ 
$ gcc-trunk -m32 -O3 small.c; a.out
$ gcc-trunk -flto -m64 -O3 small.c; a.out
$ gcc-4.9 -flto -m32 -O3 small.c; a.out
$ 
$ gcc-trunk -flto -m32 -O3 small.c
small.c: In function ‘main’:
small.c:21:1: internal compiler error: in trunc_int_for_mode, at explow.c:56
 }
 ^
0x627bb0 trunc_int_for_mode(long, machine_mode)
../../gcc-trunk/gcc/explow.c:56
0x616418 gen_int_mode(long, machine_mode)
../../gcc-trunk/gcc/emit-rtl.c:437
0x8d159c simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc-trunk/gcc/simplify-rtx.c:1735
0x8ceb6a simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc-trunk/gcc/simplify-rtx.c:814
0x8cff10 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
../../gcc-trunk/gcc/simplify-rtx.c:387
0xe1249e if_then_else_cond
../../gcc-trunk/gcc/combine.c:8615
0xe1d32e combine_simplify_rtx
../../gcc-trunk/gcc/combine.c:5262
0xe1fbaa subst
../../gcc-trunk/gcc/combine.c:5199
0xe1f8c8 subst
../../gcc-trunk/gcc/combine.c:5144
0xe1f8c8 subst
../../gcc-trunk/gcc/combine.c:5144
0xe22124 try_combine
../../gcc-trunk/gcc/combine.c:3134
0xe27f8d combine_instructions
../../gcc-trunk/gcc/combine.c:1280
0xe27f8d rest_of_handle_combine
../../gcc-trunk/gcc/combine.c:13896
0xe27f8d execute
../../gcc-trunk/gcc/combine.c:13939
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: gcc-trunk returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ 


--


int *a;
unsigned int b;

void fn2 ()
{
  int t[9];
  for (; b; b++)
*a ^= (~t[b] != t[b]);
}

int fn1 ()
{
  fn2 (); 
  return 0; 
}

int main ()
{
  fn1 (); 
  return 0;
}

[Bug tree-optimization/62209] New: ICE with LTO on valid code on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209

Bug ID: 62209
   Summary: ICE with LTO on valid code on x86_64-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk (as
well as 4.8.x and 4.9.x) with LTO on x86_64-linux-gnu in both 32-bit and 64-bit
modes.

It is a regression from 4.7.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20140820 (experimental) [trunk revision 214209] (GCC) 
$ 
$ gcc-trunk -O0 -c fn1.c
$ gcc-trunk -O0 -c main.c
$ gcc-trunk -O1 *.o  
$ ./a.out
$ 
$ gcc-trunk -flto -O0 -c fn1.c
$ gcc-trunk -flto -O0 -c main.c
$ gcc-trunk -flto -O1 *.o
fn1.c: In function ‘fn1’:
fn1.c:9:5: internal compiler error: in as_a, at is-a.h:192
 int fn1 (void)
 ^
0x90de17 gimple_statement_phi const* as_a(gimple_statement_base const*)
../../gcc-trunk/gcc/is-a.h:192
0x9210c7 gimple_statement_phi const* as_a(gimple_statement_base const*)
../../gcc-trunk/gcc/is-a.h:192
0x9210c7 gimple_phi_result
../../gcc-trunk/gcc/gimple.h:3791
0x9210c7 verify_gimple_phi
../../gcc-trunk/gcc/tree-cfg.c:4532
0x9210c7 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:4864
0x82f136 execute_function_todo
../../gcc-trunk/gcc/passes.c:1749
0x82fc53 execute_todo
../../gcc-trunk/gcc/passes.c:1806
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: gcc-trunk returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ 
$ gcc-4.7 -flto -O0 -c fn1.c
$ gcc-4.7 -flto -O0 -c main.c
$ gcc-4.7 -flto -O1 *.o
$ ./a.out
$ 
$ cat fn1.c  
struct S
{
  int f0;
  unsigned int f1:1;
} b;

int a, c, d;

int fn1 (void)
{
  unsigned int t1 = 0;
  struct S t2 = { 0, 0 };
  if (c)
{
  struct S t3 = { 0, 0 };
  for (; a;)
t3 = b;
  d = ((65531 && t1) < t3.f1) & t3.f1;
}
  return t2.f0;
}
$ cat main.c
extern int fn1 (void); 

int main ()
{
  fn1 (); 
  return 0;
}
$

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #5 from xur at google dot com ---
I sent a patch for this a few days ago:

https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg87155.html

It's pending review.


Thanks,

-Rong

On Wed, Aug 20, 2014 at 10:36 AM, ktietz at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
>
> Kai Tietz  changed:
>
>What|Removed |Added
> 
>  Status|NEW |WAITING
>   Known to fail|4.10.0  |5.0
>
> --- Comment #4 from Kai Tietz  ---
> Issue got fixed on mingw-w64's side by providing on trunk ftw/nftw API.
> Nevertheless it would be good that for ftw include and use at least a
> header-check is done.  That gcov data isn't deleted isn't necessarily that 
> bad.
>  IMO better then disabling complete tool.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #6 from Kai Tietz  ---
Yes, I remember.  I didn't comment on it.
The following checks aren't ok.
'#if !defined(_WIN32)'

you should disable those parts *only* if ftw API isn't present. This you should
check by a HAVE_FTW_H configure-check-macro.  To disable it just because _WIN32
is defined is wrong.

[Bug c/62198] spurious warning - initialization discards qualifier from pointer target type for pointer to array

[PHHargrove at lbl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198

--- Comment #2 from Paul H. Hargrove  ---
Both icc (v13.0.1) and pgcc (v12.9-0) agree with gcc (and thus disagree with
clang) on this:

$ cat -n q.c
 1  
 2  typedef unsigned long size_t;
 3  extern const void *alloc (size_t);
 4  
 5  int main()
 6  {
 7const int (*X0)[10] = alloc (10 * sizeof (int));
 8return !X0;
 9  }

$ icc -c q.c
q.c(7): warning #2331: a value of type "const void *" cannot be used to
initialize an entity of type "const int (*)[10]" (dropping qualifiers)
const int (*X0)[10] = alloc (10 * sizeof (int));
  ^


$ pgcc -c q.c
PGC-W-0095-Type cast required for this conversion (q.c: 7)
PGC/x86-64 Linux 12.9-0: compilation completed with warnings

[Bug c/62198] spurious warning - initialization discards qualifier from pointer target type for pointer to array

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Marek Polacek  ---
Closing then.

[Bug other/62210] New: download_prerequisites does not download into current directory

[richard_sharman at mitel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62210

Bug ID: 62210
   Summary: download_prerequisites does not download into current
directory
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard_sharman at mitel dot com

Created attachment 33371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33371&action=edit
Patch for download_prerequisites

The wget calls in /contrib/download_prerequisites downloads
files into directories such as gcc.gnu.org/pub/gcc/infrastructure
but tries to extract them as files in the current directory.

The --nd or --no-directories option should be given on the calls to wget.

[Bug web/62211] New: ./configure --with-float= and ARM

[dilyan.palauzov at aegee dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62211

Bug ID: 62211
   Summary: ./configure --with-float= and ARM
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org

At https://gcc.gnu.org/install/configure.html is written:

Options specification

--with-fpu=type
--with-float=type
  These configure options provide default values for the -mfpu= option and for
-mhard-float or -msoft-float.

I want to configure for ARM.  In the gcc manual, node 3.1 Option Summary under
_ARM Options_ is mentioned the option -mfloat-abi= but -m(hard,sort)-float are
not mentioned.

In node 3.17.4 ARM Options is mentioned, that -mfloat-abi can be hard, soft or
softfp.

Does ./configure-ing gcc --with-float=X lead to defaulting the -mfloat-abi
option later, when gcc is not called?  In such a case, the documentation for
configuring gcc shall mention, that --with-float=type on ARM has no impact on
-msoft-float or -mhard-float, but on -mfloat-abi .

The documentation of GCC does mention neither -mhard-float nor -msoft-float as
general options nor as ARM-specific options, so I conclude that these are not
permitted.

However, the documentation of -mfpu= , where the ARM options are described,
mentions:

 If '-msoft-float' is specified this specifies the format of floating-point
values.


So apparently, -msoft-float can be passed, when gcc produces ARM-code.

Please clarify in the gcc manual if -msoft-float is the same as
-mfloat-abi=soft, if -mhard-float is the same as -mfloat-abi=hard and if these,
including -mfloag-abu=softfp are impacted by ./configure --with-float .

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #7 from xur at google dot com ---
OK. I'll fix this and submit another patch.

On Wed, Aug 20, 2014 at 11:26 AM, ktietz at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
>
> --- Comment #6 from Kai Tietz  ---
> Yes, I remember.  I didn't comment on it.
> The following checks aren't ok.
> '#if !defined(_WIN32)'
>
> you should disable those parts *only* if ftw API isn't present. This you 
> should
> check by a HAVE_FTW_H configure-check-macro.  To disable it just because 
> _WIN32
> is defined is wrong.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/62212] New: ICE compiling template function with array reference parameter whose size depends on a template parameter

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212

Bug ID: 62212
   Summary: ICE compiling template function with array reference
parameter whose size depends on a template parameter
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com

I get an ICE in gcc 4.8.1 and also on 4.9 when compiling the code below.
Doesn't matter the optimization level or what -std=:



typedef int my_int;

template
struct X {
enum {value = 1};
};

template
void f(const my_int(&)[X::value]);

int main() {
const my_int a[1] = {};
f(a);
}



$ g++ -v -c t.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/gcc48/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-threads=posix --enable-__cxa_atexit
--prefix=/usr/local/gcc-4.8.1
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus -quiet
-v -D_GNU_SOURCE t.cpp -quiet -dumpbase t.cpp -mtune=generic -march=x86-64
-auxbase t -version -o /tmp/ccbr6RST.s
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/x86_64-unknown-linux-gnu

/usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/backward
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include
 /usr/local/include
 /usr/local/gcc-4.8.1/include
 /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9381368e685e312c931bb6a2db2d568c
t.cpp: In instantiation of 'void f(const my_int (&)[X::value]) [with T =
void; my_int = int]':
t.cpp:13:15:   required from here
t.cpp:9:6: internal compiler error: Segmentation fault
 void f(const my_int(&)[X::value]);
  ^
0x89ffef crash_signal
../.././gcc/toplev.c:332
0x72a8c7 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../.././gcc/fold-const.c:1879
0x72e648 associate_trees
../.././gcc/fold-const.c:891
0x71d534 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:10589
0x72768a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:14877
0x7195ce fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:9934
0x72768a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../.././gcc/fold-const.c:14877
0x89ac30 layout_type(tree_node*)
../.././gcc/stor-layout.c:2230
0xa0aaa3 build_array_type_1
../.././gcc/tree.c:7490
0x5add1f build_cplus_array_type(tree_node*, tree_node*)
../.././gcc/cp/tree.c:811
0x5af08e cp_build_qualified_type_real(tree_node*, int, int)
../.././gcc/cp/tree.c:1000
0x5bd2a0 canonicalize_for_substitution
../.././gcc/cp/mangle.c:364
0x5bd2a0 write_type
../.././gcc/cp/mangle.c:1886
0x5bd61d write_type
../.././gcc/cp/mangle.c:2052
0x5be6ff write_method_parms
../.././gcc/cp/mangle.c:2496
0x5be7fd write_bare_function_type
../.././gcc/cp/mangle.c:2438
0x5bbaff write_mangled_name
../.././gcc/cp/mangle.c:689
0x5c145d mangle_decl_string
../.././gcc/cp/mangle.c:3431
0x5c15d8 get_mangled_id
../.././gcc/cp/mangle.c:3453
0x5c15d8 mangle_decl(tree_node*)
../.././gcc/cp/mangle.c:3476
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



It seems to be related to "my_int" being a typedef... if you change it to
#define my_int int

then it works fine.

Also, if I intentionally give it the wrong sort of array, then it gives the
correct error message and does not ICE, e.g. if I change the type to "const
double a[1] = {}" then i get:

t.cpp: In function 'int main()':
t.cpp:13:14: error: no matching function for call to 

[Bug c++/61566] [4.9/4.10 Regression] ICE in write_unscoped_name

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #13 from Hans-Peter Nilsson  ---
(In reply to Jason Merrill from comment #11)
> Author: jason
> Date: Wed Aug 20 01:17:37 2014
> New Revision: 214206
> 
> URL: https://gcc.gnu.org/viewcvs?rev=214206&root=gcc&view=rev
> Log:
>   PR c++/61566
>   * pt.c (instantiate_class_template_1): Ignore lambda on
>   CLASSTYPE_DECL_LIST.
>   (push_template_decl_real): A lambda is not primary.
>   * lambda.c (maybe_add_lambda_conv_op): Distinguish between being
>   currently in a function and the lambda living in a function.
> 
> Modified:
> branches/gcc-4_9-branch/gcc/cp/ChangeLog
> branches/gcc-4_9-branch/gcc/cp/lambda.c
> branches/gcc-4_9-branch/gcc/cp/pt.c
>
> branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template13.C

This or another nearby commit of yours in the range (214200:214208] regressed
g++.dg/cpp0x/lambda/lambda-template13.C on the 4.9 branch for all targets
(presumably; at least those at the URLs and cris-elf) for the scan-assembler
match.
See  and
.

[Bug c++/61566] [4.9/4.10 Regression] ICE in write_unscoped_name

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566

--- Comment #14 from Jason Merrill  ---
Thanks, corrected the testcase.

[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c

[joel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203

Joel Sherrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Joel Sherrill  ---
Fixed now.

[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c

[joel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203

--- Comment #5 from Joel Sherrill  ---
Appears to be fixed now.

[Bug rtl-optimization/62177] mips-rtems ICE at lra_assigns.c:1335 compiling strtod.c in newlib

[joel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62177

Joel Sherrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Joel Sherrill  ---
Fixed now.

[Bug c/62198] spurious warning - initialization discards qualifier from pointer target type for pointer to array

[gary at intrepid dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198

--- Comment #4 from Gary Funck  ---
I realize that this bug has been closed as invalid, thus making the warning
valid.  

However, if the warning is valid what can be done to this declaration to avoid
the warning?

const int (*X0)[10] = alloc (10 * sizeof (int));

The C99 spec. says:

6.7.3 Semantics

8. If the specification of an array type includes any type qualifiers,
the element type is so qualified, not the array type. If the
specification of a function type includes any type qualifiers,
the behavior is undefined.116)

116) Both of these can occur through the use of typedefs

Since the constraint above talks about the qualifiers being propagated to the
element type, is it possible at all for an array type to be qualified?  what is
the syntax for that?

It seems reasonable to conclude for the purpose of determining compatibility in
the case of assignment of a qualified pointer-to-void to a pointer-to-array
with a qualified element type that the ultimate element type would be used, but
I didn't find anywhere in the C99 spec. that this was explicitly discussed.

It's interesting that g++ just banned this situation outright:

error: invalid conversion from ‘const void*’ to ‘const int (*)[10]’
[-fpermissive]

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

--- Comment #14 from Manuel López-Ibáñez  ---
Author: manu
Date: Wed Aug 20 23:07:29 2014
New Revision: 214245

URL: https://gcc.gnu.org/viewcvs?rev=214245&root=gcc&view=rev
Log:
gcc/ChangeLog:

2014-08-21  Manuel López-Ibáñez  

PR fortran/44054
* diagnostic.c (default_diagnostic_finalizer): Move caret printing
 to here ...
(diagnostic_report_diagnostic): ... from here.
* toplev.c (general_init): Move code to c-family.

gcc/cp/ChangeLog:

2014-08-21  Manuel López-Ibáñez  

PR fortran/44054
* error.c (cp_diagnostic_finalizer): Delete.
(init_error): Do not set diagnostic_finalizer here.

gcc/c-family/ChangeLog:

2014-08-21  Manuel López-Ibáñez  

PR fortran/44054
* c-opts.c: Include tree-diagnostics.h.
(c_diagnostic_finalizer): New.
(c_common_initialize_diagnostics): Use it.

gcc/fortran/ChangeLog:

2014-08-21  Manuel López-Ibáñez  

PR fortran/44054
* error.c (gfc_diagnostic_finalizer): Call default finalizer.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/diagnostic.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/toplev.c

[Bug c++/62175] Internal compiler error in gimplify_modify_expr gimplify.c:4616

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62175

--- Comment #4 from Marc Glisse  ---
struct B {
  B(int = 0);
};
int c;
int *d;
struct G {
  G();
  int numProcs_;
};
int fn1();
B fn2() {
  if (c)
return 0;
  return B();
}

long &fn3(long &p1, long &p2) {
  if (p2 < p1)
return p2;
  return p1;
}

void fn4(long p1) {
  long a = fn1();
  fn2();
  int b = fn3(p1, a);
  for (int i; i < b; ++i)
d[0] = 0;
  for (; a < p1; ++a)
d[a] = 0;
}

G::G() { fn4(numProcs_ + 1); }

(compiled with -O3 -ftrapv)

[Bug target/45808] FreeBSD: -pthread is handled incompletely

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45808

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC|manu at gcc dot gnu.org|

--- Comment #8 from Manuel López-Ibáñez  ---
Perhaps this should be closed?

[Bug other/35376] #pragma GCC diagnostic expand function.

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35376

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC|manu at gcc dot gnu.org|

--- Comment #1 from Manuel López-Ibáñez  ---
I am not sure what this is about, but it is so old that we should probably
close it.

[Bug c++/52959] Missing typo suggestions

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52959

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-20
 CC||mpolacek at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
I for one would love to have this (and PR52277) but I cannot commit the amount
of time/work needed to make this work.

Pretty please, could someone implement it? Marek, Paolo, Google guys?

[Bug c++/58589] diagnostics: missing proper file:line on C++ compilation error

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58589

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Target|x86_64-unknown-linux-gnu|
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-08-20
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
Waiting for a minimized testcase.

[Bug c/59098] Unwarranted warning: promoted ~unsigned is always non-zero [-Wsign-compare]

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59098

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-20
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
I think this is confirmed.

[Bug c/61405] Not emitting "enumeration value not handled in switch" warning for bit-field enums

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61405

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-20
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
Seems confirmed enough.

[Bug c++/44521] unhelpful candidates for ambiguous lookup

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44521

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
Jason, do we want this?

Following Clang or in some other way?

[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

--- Comment #10 from Manuel López-Ibáñez  ---
So what is missing here? Can we close this or not yet?

[Bug c/47781] warnings from custom printf format specifiers

[philipp_s...@redfish-solutions.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #8 from Philip Prindeville  ---
(In reply to jos...@codesourcery.com from comment #4)

> For the general issue, my inclination is that we should add plugin hooks 
> into the format checking machinery that allow plugins to define formats 
> with the full flexibility of all the format checking datastructures in 
> GCC.  Using GCC plugins for this avoids problems with defining complicated 
> syntax in the source file to describe the peculiarities of different 
> formats, which might constrain future changes to the format checking 
> implementation by making too much of the internals visible to user source 
> code, because by design GCC plugins can use GCC internals which are free 
> to change incompatibly in ways that require plugin changes.

What about using pragmas to describe the new format specifier?

[Bug c/53562] Add -Werror= support for -D_FORTIFY_SOURCE / __builtin___memcpy_chk

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53562

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-21
 CC||davidxl at gcc dot gnu.org,
   ||dnovillo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
I think we want this. It would be nice if the Google guys took care of it. ;-)

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054

--- Comment #15 from Manuel López-Ibáñez  ---
Author: manu
Date: Thu Aug 21 00:27:25 2014
New Revision: 214251

URL: https://gcc.gnu.org/viewcvs?rev=214251&root=gcc&view=rev
Log:
gcc/ChangeLog:

2014-08-21  Manuel López-Ibáñez  

PR fortran/44054
* diagnostic.c: Set default caret.
(diagnostic_show_locus): Use it. Tell pretty-printer that a new
line is needed.
* diagnostic.h (struct diagnostic_context):


gcc/fortran/ChangeLog:

2014-08-21  Manuel López-Ibáñez  

PR fortran/44054
* error.c (gfc_diagnostic_build_locus_prefix): New function.
(gfc_diagnostic_starter): Follow Fortran FE diagnostics.
(gfc_diagnostic_finalizer): Do not call default finalizer.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c

[Bug c++/61339] add mismatch between struct and class to non-bugs

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339

--- Comment #3 from Manuel López-Ibáñez  ---
Meanwhile, I added a FAQ to the wiki:
https://gcc.gnu.org/wiki/FAQ#Wmismatched-tags

Feel free to improve it !

[Bug c++/62185] New warning for "defined as a struct here but previously declared as a class" / [-Wmismatched-tags]

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62185

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
As said in PR61339, it would be nice to add this to the list of non-bugs.
Meanwhile, I added a FAQ to the wiki:
https://gcc.gnu.org/wiki/FAQ#Wmismatched-tags

Feel free to improve it!

[Bug c++/62185] New warning for "defined as a struct here but previously declared as a class" / [-Wmismatched-tags]

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62185

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WONTFIX |DUPLICATE

--- Comment #3 from Andrew Pinski  ---


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

[Bug c++/61339] add mismatch between struct and class to non-bugs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339

Andrew Pinski  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
*** Bug 62185 has been marked as a duplicate of this bug. ***

[Bug c/62184] [C/C++] Extend -Wempty-body to 'while' loops

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
We had this and it got removed (see PR36478). Perhaps a better implementation
is possible now that we track macro locations.

(I wonder how the Clang guys get away with warning about all this stuff by
default. Is it because they have very good heuristics to avoid being annoying?)

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #34 from Manuel López-Ibáñez  ---
In any case, the current patch needs more work. In case you want to see this in
GCC 5.0, you need to hurry up! :)

[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651

--- Comment #28 from Manuel López-Ibáñez  ---
A good way to finish this is to find which option in Clang warns for the
corresponding thing in Wextra and add the same option to GCC.

I can take care of writing and testing the patches but someone else would need
to do the search for each warning.

[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786

--- Comment #11 from Vincent Lefèvre  ---
(In reply to Manuel López-Ibáñez from comment #10)
> So what is missing here? Can we close this or not yet?

I've tested that -fno-sanitize-recover works correctly with gcc-snapshot under
Debian. So, I suppose that this can be closed.

[Bug c++/44521] unhelpful candidates for ambiguous lookup

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44521

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-21
 Ever confirmed|0   |1

--- Comment #2 from Jason Merrill  ---
(In reply to Manuel López-Ibáñez from comment #1)
> Jason, do we want this?
> 
> Following Clang or in some other way?

Yes, the Clang diagnostic is better.

There are two issues with the G++ diagnostic:

1) It talks about f(double), which is not viable.
2) It doesn't distinguish between two occurrences of the same function reached
through different base paths.

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.2

--- Comment #10 from Jason Merrill  ---
Fixed for 4.9.2.