[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[ismail at i10z dot com]

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

İsmail Dönmez  changed:

   What|Removed |Added

 CC||ismail at i10z dot com

--- Comment #9 from İsmail Dönmez  ---
This test currently fails on Linux x86-64 machine. Is there a way to get a
better debug output for the failure. For now I see:

FAIL: gfortran.dg/pr68227.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr68227.f90   -O  (test for excess errors)

[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 25 16:11:40 2015
New Revision: 230884

URL: https://gcc.gnu.org/viewcvs?rev=230884=gcc=rev
Log:
Extend valid values of iostream bitmask types

Backport from mainline
2015-11-12  Jonathan Wakely  

PR libstdc++/56158
* include/bits/ios_base.h (_Ios_Fmtflags, _Ios_Openmode, _Ios_Iostate):
Define enumerators to ensure all values of type int are valid values
of the enumeration type.
* testsuite/27_io/ios_base/types/fmtflags/case_label.cc: Add new cases.
* testsuite/27_io/ios_base/types/iostate/case_label.cc: Likewise.
* testsuite/27_io/ios_base/types/openmode/case_label.cc: Likewise.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/ios_base.h
   
branches/gcc-5-branch/libstdc++-v3/testsuite/27_io/ios_base/types/fmtflags/case_label.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/27_io/ios_base/types/iostate/case_label.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/27_io/ios_base/types/openmode/case_label.cc

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Nov 25 16:42:18 2015
New Revision: 230887

URL: https://gcc.gnu.org/viewcvs?rev=230887=gcc=rev
Log:
/cp
2015-11-25  Markus Trippelsdorf  
Paolo Carlini  

PR c++/68087
* constexpr.c (cxx_eval_array_reference): Use tree_fits_shwi_p before
tree_to_shwi to avoid ICEs.

/testsuite
2015-11-25  Markus Trippelsdorf  
Paolo Carlini  

PR c++/68087
* g++.dg/cpp0x/constexpr-array13.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-array13.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/68543] New: Implement overflow arithmetic standard names {u,}{add,sub,mul}v4 and/or negv3

[ktkachov at gcc dot gnu.org]

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

Bug ID: 68543
   Summary: Implement overflow arithmetic standard names
{u,}{add,sub,mul}v4 and/or negv3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

As mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112#c13
we should consider implementing the various overflow arithmetic standard name
expanders that take a label argument and emit a jump to it if the operation
overflows.

A motivational example is the code quality regression from PR 68381:
int
foo(unsigned short x, unsigned short y)
{
  int r;
  if (__builtin_mul_overflow (x, y, ))
__builtin_abort ();
  return r;
}

which for aarch64 at -O3 generates:
foo:
uxthw0, w0
uxthw1, w1
umull   x0, w0, w1
tbnzw0, #31, .L6
mov w2, 0
cbnzw2, .L6
ret
.L6:
stp x29, x30, [sp, -16]!
add x29, sp, 0
bl  abort

which could be improved

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Christophe Lyon  ---
Fixed by r230871.

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

[Bug c++/68385] [6 Regression] ICE building libstdc++ on arm-none-eabi

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
*** Bug 68368 has been marked as a duplicate of this bug. ***

[Bug fortran/68544] New: ICE trying to pass derived type constructor as a function

[jim.macarthur at codethink dot co.uk]

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

Bug ID: 68544
   Summary: ICE trying to pass derived type constructor as a
function
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim.macarthur at codethink dot co.uk
  Target Milestone: ---

Created attachment 36839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36839=edit
Minimal test case

The attached code causes an internal compiler error with the latest source from
git master (commit 9c822ac) and 5.2.0. It attempts to pass the implicit
constructor for a derived type as an argument to a subroutine.

I don't know if this is valid code. I haven't found anything in the standards
which suggest either way yet. Sun's F90 compiler rejects it, but gives a useful
error message.

gfortran -v:
Using built-in specs.
COLLECT_GCC=/home/jimmacarthur/gcc-5.2.0/gccinstall/bin/gfortran
COLLECT_LTO_WRAPPER=/home/jimmacarthur/gcc-5.2.0/gccinstall/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure --with-languages=fortran
--prefix=/home/jimmacarthur/gcc-5.2.0/gccinstall --disable-bootstrap
Thread model: posix
gcc version 5.2.0 (GCC) 

Compiler command line:
~/gcc-5.2.0/gccinstall/bin/gfortran -Wall -Wextra
pass-type-constructor-as-function.f

output:
pass-type-constructor-as-function.f:1:23:

   SUBROUTINE sub (f)
   1
Warning: Unused dummy argument ‘f’ at (1) [-Wunused-dummy-argument]
pass-type-constructor-as-function.f:7:0:

   TYPE t
 1
internal compiler error: Segmentation fault
0xa20cdf crash_signal
../../gcc-5.2.0/gcc/toplev.c:383
0x67b990 gfc_sym_identifier
../../gcc-5.2.0/gcc/fortran/trans-decl.c:347
0x67c38a build_function_decl
../../gcc-5.2.0/gcc/fortran/trans-decl.c:2057
0x682fa5 gfc_get_symbol_decl(gfc_symbol*)
../../gcc-5.2.0/gcc/fortran/trans-decl.c:1487
0x693537 gfc_conv_variable
../../gcc-5.2.0/gcc/fortran/trans-expr.c:2312
0x690c8a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-5.2.0/gcc/fortran/trans-expr.c:7219
0x696048 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc-5.2.0/gcc/fortran/trans-expr.c:7319
0x68d3ff gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc-5.2.0/gcc/fortran/trans-expr.c:4831
0x6be024 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc-5.2.0/gcc/fortran/trans-stmt.c:419
0x66539c trans_code
../../gcc-5.2.0/gcc/fortran/trans.c:1743
0x685e54 gfc_generate_function_code(gfc_namespace*)
../../gcc-5.2.0/gcc/fortran/trans-decl.c:5841
0x622648 translate_all_program_units
../../gcc-5.2.0/gcc/fortran/parse.c:5340
0x622648 gfc_parse_file()
../../gcc-5.2.0/gcc/fortran/parse.c:5537
0x6613e5 gfc_be_parse_file
../../gcc-5.2.0/gcc/fortran/f95-lang.c:229

[Bug middle-end/68066] [6 Regression]: ICE in max_value, at wide-int.cc

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Confirmed fixed.

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> This test currently fails on Linux x86-64 machine. Is there a way to get a
> better debug output for the failure. For now I see:
>
> FAIL: gfortran.dg/pr68227.f90   -O  (internal compiler error)
> FAIL: gfortran.dg/pr68227.f90   -O  (test for excess errors)

It should be fixed after r230873.

[Bug tree-optimization/68128] A huge regression in Parboil v2.5 OpenMP CUTCP test (2.5 times lower performance)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-25
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Jakub Jelinek  ---
Created attachment 36838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36838=edit
gcc6-pr68128.patch

Untested optimization to turn shared clauses of scalar vars into firstprivate
if quickly determined not to be written into in the body (during gimplification
plus tree-nested follow-up).

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Nov 25 16:40:16 2015
New Revision: 230886

URL: https://gcc.gnu.org/viewcvs?rev=230886=gcc=rev
Log:
/cp
2015-11-25  Markus Trippelsdorf  
Paolo Carlini  

PR c++/68087
* constexpr.c (cxx_eval_array_reference): Use tree_fits_shwi_p before
tree_to_shwi to avoid ICEs.

/testsuite
2015-11-25  Markus Trippelsdorf  
Paolo Carlini  

PR c++/68087
* g++.dg/cpp0x/constexpr-array13.C: New.

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

[Bug rtl-optimization/68381] [6 Regression] wrong code and quality regression with __builtin_mul_overflow() @ aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
For the code quality regression Jakub recommends implementing an aarch64
expander for the overflow arithmetic standard names.

I've filed PR 68543 for that

[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Martin Sebor  ---
ICE on the test case from comment #2 confirmed with today's trunk (6.0.0
20151125).

[Bug c++/55004] [meta-bug] constexpr issues

[trippels at gcc dot gnu.org]

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

Bug 68087 Summary: [5/6 Regression] ICE with constexpr in array with negative 
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68087

   What|Removed |Added

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

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
Fixed. Thanks for handling this, Paolo.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to ktkachov from comment #12)
> r223115 caused a code quality regression that I'm seeing on aarch64 with PR
> 68381.
> 
> We have
> int
> foo (unsigned short x, unsigned short y)
> {
>   int r;
>   if (__builtin_mul_overflow (x, y, ))
> __builtin_abort ();
>   return r;
> }
> 
> and before the commit we used to generate:
> foo:
>   uxthx0, w0
>   uxthx1, w1
>   mul x0, x0, x1
>   cmp x0, x0, sxtw
>   bne .L9
>   ret
> .L9:
>   stp x29, x30, [sp, -16]!
>   add x29, sp, 0
>   bl  abort
> 
> but after r223115 at -O3 on an aarch64 toolchain we generate:
>  foo:
>   uxthw0, w0
>   uxthw1, w1
>   stp x29, x30, [sp, -16]!
>   umull   x0, w0, w1
>   add x29, sp, 0
>   tbnzw0, #31, .L6
>   mov w2, 0
>   cbnzw2, .L6
>   ldp x29, x30, [sp], 16
>   ret
> .L6:
>   bl  abort

You really should consider adding {u,}{add,sub,mul}v4 and/or negv3
expanders if you have some better sequences you can generate over the generic
ones on some target.

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Dominique d'Humieres  ---
> Unreopen.

Doing so;-)

[Bug tree-optimization/68529] scev failed for while(i--)

[amker.cheng at gmail dot com]

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

--- Comment #5 from bin.cheng  ---
The dump before ldist is as below:

foo1 ()
{
  unsigned int nchar;
  char c[1];

  :
  c = {};

  :
  # nchar_14 = PHI 
  c[nchar_14] = 65;
  nchar_5 = nchar_14 + 4294967295;
  if (nchar_14 != 0)
goto ;
  else
goto ;

  :
  goto ;

  :
  bar ();
  c ={v} {CLOBBER};
  return 0;

}

Apparently, nchar_14 iterates from 9998 to 0 in the loop and it doesn't
overflow, while nchar_5 does overflow for the last iterations.  It's true
[n_char_14] is an affine since the index doesn't overflow.
When I introduced the change computing non-overlfow control-iv in loop niter
analysis, I only did it for the simplest case, ie, loop exit condition with LT
comp code.  This case falls in another case, ie, NE as the comp code.  I think
this can be fixed in the same framework.  Actually it's easy to enable
non-overflow control-iv computation in this case, then we can use the recorded
control-iv to prove that (sizetype)nchar_14 doesn't overflow and [nchar_14]
is an affine.

I will dig deeper and test a patch for this.

Thanks,
bin

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
I've noticed that this has just been fixed by r230871, so it was in fact a dup
of pr68385

[Bug go/61303] gccgo: segfault, regression since 4.8.2

[ian at gcc dot gnu.org]

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

--- Comment #11 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Nov 26 00:24:33 2015
New Revision: 230923

URL: https://gcc.gnu.org/viewcvs?rev=230923=gcc=rev
Log:
PR go/61303
runtime: don't overallocate in select code

If we've already allocated an fd_set, don't allocate another one.

Also, don't bother to read from rdwake if it wasn't returned in select.

Fixes https://gcc.gnu.org/PR61303.

Reviewed-on: https://go-review.googlesource.com/17243

Modified:
branches/gcc-5-branch/libgo/runtime/netpoll_select.c

[Bug go/61303] gccgo: segfault, regression since 4.8.2

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #12 from Ian Lance Taylor  ---
This seems to have been due to a bug in the select support, which is only used
on Solaris.  Should be fixed on mainline and GCC 5 branch.

[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Wed Nov 25 23:05:07 2015
New Revision: 230915

URL: https://gcc.gnu.org/viewcvs?rev=230915=gcc=rev
Log:

PR lto/67548
* lto-plugin.c (linker_output, linker_output_set): New statics.
(all_symbols_read_handler): Add -flinker-output option.
(onload): Record linker_output info.

* ipa-visibility.c (cgraph_externally_visible_p,
varpool_node::externally_visible_p): When doing incremental linking,
hidden symbols may be still used later.
(update_visibility_by_resolution_info): Do not drop weak during
incremental link.
(function_and_variable_visibility): Fix formating.
* flag-types.h (lto_linker_output): Declare.
* common.opt 9flag_incremental_link): New flag.

* lto-lang.c (lto_post_options): Process flag_lto_linker_output.
* lang.opt (lto_linker_output): New enum.
(flinker_output): New flag.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/flag-types.h
trunk/gcc/ipa-visibility.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lang.opt
trunk/gcc/lto/lto-lang.c
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/lto-plugin.c

[Bug fortran/68544] ICE trying to pass derived type constructor as a function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-25
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

> Sun's F90 compiler rejects it, but gives a useful error message.

What is the message?

[Bug tree-optimization/68548] New: gcc wrongly warns about uninitialized data

[mattst88 at gmail dot com]

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

Bug ID: 68548
   Summary: gcc wrongly warns about uninitialized data
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattst88 at gmail dot com
  Target Milestone: ---

Created attachment 36842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36842=edit
u.c

gcc -Wmaybe-uninitialized wrongly warns about data0 being uninitialized in the
attached test case.

This may be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145

[Bug c/66516] missing diagnostic on taking the address of a builtin function

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Nov 25 23:29:57 2015
New Revision: 230916

URL: https://gcc.gnu.org/viewcvs?rev=230916=gcc=rev
Log:
PR c/66516 - missing diagnostic on taking the address of a builtin function
* g++.dg/addr_builtin-1.C: New test (accidentally omitted from
initial commit).
* gcc.dg/addr_builtin-1.c: Same.

Added:
trunk/gcc/testsuite/g++.dg/addr_builtin-1.C
trunk/gcc/testsuite/gcc.dg/addr_builtin-1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68546] passing non-contiguous associated array section garbles results

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-25
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). BLOCK is not implemented  in 4.6. 4.6 and
4.7 gives

calling foo with associated fixed i section
 *   0.0   NaN


Related to/Duplicate of PR64773.

[Bug tree-optimization/68529] scev failed for while(i--)

[majun4950646 at 163 dot com]

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

--- Comment #6 from majun  ---
(In reply to bin.cheng from comment #5)
> The dump before ldist is as below:
> 
> foo1 ()
> {
>   unsigned int nchar;
>   char c[1];
> 
>   :
>   c = {};
> 
>   :
>   # nchar_14 = PHI 
>   c[nchar_14] = 65;
>   nchar_5 = nchar_14 + 4294967295;
>   if (nchar_14 != 0)
> goto ;
>   else
> goto ;
> 
>   :
>   goto ;
> 
>   :
>   bar ();
>   c ={v} {CLOBBER};
>   return 0;
> 
> }
> 
> Apparently, nchar_14 iterates from 9998 to 0 in the loop and it doesn't
> overflow, while nchar_5 does overflow for the last iterations.  It's true
> [n_char_14] is an affine since the index doesn't overflow.
> When I introduced the change computing non-overlfow control-iv in loop niter
> analysis, I only did it for the simplest case, ie, loop exit condition with
> LT comp code.  This case falls in another case, ie, NE as the comp code.  I
> think this can be fixed in the same framework.  Actually it's easy to enable
> non-overflow control-iv computation in this case, then we can use the
> recorded control-iv to prove that (sizetype)nchar_14 doesn't overflow and
> [nchar_14] is an affine.
> 
> I will dig deeper and test a patch for this.
> 
> Thanks,
> bin

Does https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02317.html  describe your
framework ?
it seems for now loop_exits_before_overflow should only handle th LT and GT
case ? 

I'll see how does this framework do. 

Thanks,
Jun

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[pageexec at gmail dot com]

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

--- Comment #19 from PaX Team  ---
(In reply to Josh Triplett from comment #18)
> (In reply to PaX Team from comment #17)
> > (In reply to Josh Triplett from comment #16)
> > speaking of generalization, the encoding of the lock expression (e.g., lock
> > ptr) will have to change as it really doesn't seem feasible to refer to
> > function arguments from an attribute.
> 
> Doesn't seem too unreasonable to handle, actually.  When parsing an
> attribute, refer back to the function arguments; the context expression must
> either use those or globals.

the problem is that gcc itself refuses to parse an expression that wants to
refer to a function argument (global variables work fine). this is something
that changed with gcc-5, previously such a reference would at least produce an
identifier_node (basically just the name of the referenced parameter but
without any reference to the parm_decl itself, so not too useful), now it's a
compile error:

 error: 'p' undeclared here (not in a function)

so getting this to work would require frontend patches at least (and is beyond
what a plugin can do but see below for an idea).

> That fails for a really common case that should generate a warning:
> 
> spin_lock(_lock);
> /* Piles of code */
> spin_unlock(_other_lock);

hmmm, true, so some parsing is inavoidable. the stringification idea may still
be viable however as the attribute parsing code runs as part of the frontend so
technically it has access to the parsing machinery and could perhaps extract at
least simple expressions (or just a function argument) from the string. i'll
make some experiments and see if i can get back a reference to a parm_decl at
least.

[Bug go/61303] gccgo: segfault, regression since 4.8.2

[ian at gcc dot gnu.org]

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

--- Comment #10 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Nov 26 00:24:21 2015
New Revision: 230922

URL: https://gcc.gnu.org/viewcvs?rev=230922=gcc=rev
Log:
PR go/61303
runtime: don't overallocate in select code

If we've already allocated an fd_set, don't allocate another one.

Also, don't bother to read from rdwake if it wasn't returned in select.

Fixes https://gcc.gnu.org/PR61303.

Reviewed-on: https://go-review.googlesource.com/17243

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/runtime/netpoll_select.c

[Bug target/41868] cell microcode instruction (addic.) is generated for a trivial loop with -O2 optimizations, hurting performance badly

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #11 from Segher Boessenkool  ---
As Andrew notes in comment #3, "addic." is not microcoded on Cell BE.
I fixed this misclassification about a year ago (it used to be type
"compare", now is "add").

Current trunk also does not do a load/store; all is good now.

[Bug c++/67876] [6 Regression] ICE when compiling Firefox 38

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 26 01:52:04 2015
New Revision: 230924

URL: https://gcc.gnu.org/viewcvs?rev=230924=gcc=rev
Log:
PR c++/67876 - [6 Regression] ICE when compiling Firefox 38

gcc/cp
* pt.c (convert_template_argument): Make sure number of tree
operands is greater than zero before attempting to extract one.

gcc/testsuite/
* g++.dg/pr67876.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr67876.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67876] [6 Regression] ICE when compiling Firefox 38

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed with r230924.

[Bug target/68454] internal compiler error: Segmentation fault

[luser.droog at gmail dot com]

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

--- Comment #13 from M Joshua Ryan  ---
I get the same error compiling GMP.

Following instructions from http://stackoverflow.com/a/9450422/733077

josh@LAPTOP-ILO10OOF /tmp
$ cd gmp-4.3.2

josh@LAPTOP-ILO10OOF /tmp/gmp-4.3.2
$ mkdir ../gcc

josh@LAPTOP-ILO10OOF /tmp/gmp-4.3.2
$ ./configure --prefix=/tmp/gcc
checking build system type... x86_64-unknown-cygwin
checking host system type... x86_64-unknown-cygwin
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=64
checking compiler gcc -O2 -pedantic -m64 ... yes
checking compiler gcc -O2 -pedantic -m64  -mtune=k8... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gcc option to accept ISO C99... none needed
checking for gcc option to accept ISO Standard C... (cached) none needed
checking how to run the C preprocessor... gcc -E
checking build system compiler gcc... yes
checking for build system preprocessor... gcc -E
checking for build system executable suffix... .exe
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
using ABI="64"
  CC="gcc"
  CFLAGS="-O2 -pedantic -m64 -mtune=k8"
  CPPFLAGS=""
  MPN_PATH=" x86_64 generic"
checking for function prototypes... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for string.h... (cached) yes
checking whether assembler supports --noexecstack option... no
checking for ar... ar
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output... /usr/bin/sed
checking for ld used by gcc... /usr/x86_64-pc-cygwin/bin/ld.exe
checking if the linker (/usr/x86_64-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking for /usr/x86_64-pc-cygwin/bin/ld.exe option to reload object files...
-r
checking whether ln -s works... yes
checking how to recognize dependent libraries... file_magic ^x86 archive
import|^x86 DLL
checking for dlltool... dlltool
checking for as... as
checking for objdump... objdump
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking the maximum length of command line arguments... 8192
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... (cached) ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/x86_64-pc-cygwin/bin/ld.exe) supports
shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
configure: creating libtool
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking invent.h usability... no
checking invent.h presence... no
checking for invent.h... no
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking nl_types.h usability... no
checking nl_types.h presence... no
checking for nl_types.h... no
checking sys/attributes.h usability... no
checking sys/attributes.h presence... no
checking for sys/attributes.h... no
checking sys/iograph.h usability... no
checking sys/iograph.h presence... no
checking for sys/iograph.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes

[Bug rtl-optimization/67954] [5 / 6 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303

[dbaryshkov at gmail dot com]

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

--- Comment #9 from Dmitry Eremin-Solenikov  ---
This also needs to be applied to the 4.9 branch -- it also contains an
offending commit.

[Bug middle-end/192] String literals don't obey -fdata-sections

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #18 from Segher Boessenkool  ---
I'm closing this bug.  If there is some other (still supported) case we
do not support well, please open a new bug report.

[Bug lto/64860] [5/6 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #13 from Jan Hubicka  ---
This is another bug related to incremental linking and LTO.  I will redirect
them all to PR67548. The testcase now works on mainline GCC in a sense that the
duplicate is gone and we get missing typeinfo:
lib1.lib::typeinfo for CDialogBase: error: undefined reference to
'vtable for __cxxabiv1::__class_type_info'
/usr/bin/ld: the vtable symbol may be undefined because the class is missing
its key function
collect2: error: ld returned 1 exit status

that seems intended.

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

[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #11 from Jan Hubicka  ---
*** Bug 64860 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68548] bogus "may be used uninitialized" (predicate analysis)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-26
 CC||manu at gcc dot gnu.org
Version|unknown |6.0
 Blocks||24639
Summary|gcc wrongly warns about |bogus "may be used
   |uninitialized data  |uninitialized" (predicate
   ||analysis)
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Matt Turner from comment #0)
> Created attachment 36842 [details]
> u.c
> 
> gcc -Wmaybe-uninitialized wrongly warns about data0 being uninitialized in
> the attached test case.
> 
> This may be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145

No, it is not. This is just that the uninit predicate analysis is not powerful
enough. It sees that the DEF is guarded by writemask_3(D) & 1, but it sees that
the use is guarded by remaining_8 == 0, and it doesn't seem to analyse further
than that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/48001] inconsistent warning within loop always taken and outside the loop

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to jerome.borme from comment #3)
> The initialization of sum_f has been forgotten, but no warning is issued,
> although sum_f is used in the loop.

I get in 6.0 even with -O1:

test.c:12:3: error: ‘sum_f’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]

so it seems this got fixed somehow. Please reopen if this is not the case.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[manu at gcc dot gnu.org]

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

Bug 48001 Summary: inconsistent warning within loop always taken and outside 
the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48001

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #18 from Segher Boessenkool  ---
This is fixed now.

[Bug rtl-optimization/67954] [5 / 6 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Nov 25 17:57:15 2015
New Revision: 230893

URL: https://gcc.gnu.org/viewcvs?rev=230893=gcc=rev
Log:
2015-11-25  Vladimir Makarov  

PR rtl-optimization/67954
* lra-constraints.c (curr_insn_transform): Add check on scratch
pseudo when change class to NO_REGS.  Add an assert.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-constraints.c

[Bug rtl-optimization/67954] [5 / 6 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Nov 25 17:58:35 2015
New Revision: 230894

URL: https://gcc.gnu.org/viewcvs?rev=230894=gcc=rev
Log:
2015-11-25  Vladimir Makarov  

PR rtl-optimization/67954
* lra-constraints.c (curr_insn_transform): Add check on scratch
pseudo when change class to NO_REGS.  Add an assert.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug rtl-optimization/67954] [5 / 6 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Assuming fixed for 5.3+.

[Bug rtl-optimization/67954] [5 / 6 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
  The problem occurred in rare cases when a pseudo created from a scratch was
reloaded and assigned to reg and memory back again.  The new reload pseudo
loses "created from clobber" mark and occurs more once in insns.

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
The testcase fails on i686-linux:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-array13.C:6:26: error:
array subscript out of bound
compiler exited with status 1
output is:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-array13.C:6:26: error:
array subscript out of bound

FAIL: g++.dg/cpp0x/constexpr-array13.C  -std=c++11  (test for errors, line 6)
FAIL: g++.dg/cpp0x/constexpr-array13.C  -std=c++11 (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-array13.C:6:26: error:
array subscript out of bound

[Bug target/68454] internal compiler error: Segmentation fault

[luser.droog at gmail dot com]

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

--- Comment #12 from M Joshua Ryan  ---
(In reply to Andrew Pinski from comment #10)
> This sounds related to GMP/MPFR, can you recompile those?

Downloading the src packages now. Will update.

[Bug fortran/68544] ICE trying to pass derived type constructor as a function

[jim.macarthur at codethink dot co.uk]

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

--- Comment #2 from Jim MacArthur  ---
Sun f90 output:


  CALL sub(t)
   ^  
"pass-type-constructor-as-function.f", Line = 10, Column = 16: ERROR: This use
of derived type "T" is not valid.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

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

--- Comment #16 from Josh Triplett  ---
(In reply to PaX Team from comment #14)
> (In reply to Josh Triplett from comment #13)
> > This approach won't necessarily provide the "different contexts for basic
> > block" warning that Sparse has, but I don't necessarily think we need that;
> 
> can you give me an example of this?

Sparse warns if you can reach the same basic block with different context
values (for instance, with or without a lock held).  That warning *may*
indicate a problem, but it can also just indicate code too intricate for Sparse
to understand.

> the thing is, my approach tracks the
> context with statement granularity so if you can tell the compiler where you
> expect specific states (such as the context attr on callees) checks can be
> inserted there easily, down to individual statements (say, the structure
> field accesses you mentioned).

Sounds good to me.

(In reply to Tom Tromey from comment #15)
> Anyway given that this is happening, I suggest closing this gcc bug.

Have we completely ruled out the possibility of a native GCC implementation? 
This really doesn't seem specific to the Linux kernel in any way; it'd be nice
if this could work in most programs.  We could add annotations to pthread
locking functions, and any program using locking would benefit.

[Bug c++/68422] compile-time cost of sizeof... is quadratic

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Nov 25 19:56:12 2015
New Revision: 230900

URL: https://gcc.gnu.org/viewcvs?rev=230900=gcc=rev
Log:
PR c++/68422

* cp-tree.h (PACK_EXPANSION_SIZEOF_P): New.
* parser.c (cp_parser_sizeof_pack): Set it.
* pt.c  (tsubst_copy) [SIZEOF_EXPR]: Likewise.
(tsubst_pack_expansion): Improve T... shortcut when set.

Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/cp-tree.h
branches/gcc-5-branch/gcc/cp/parser.c
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/67813] [C++14] copy-initialization of object with pointer member fails in constexpr function

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Nov 25 19:56:06 2015
New Revision: 230899

URL: https://gcc.gnu.org/viewcvs?rev=230899=gcc=rev
Log:
PR c++/67813

* constexpr.c (cxx_eval_store_expression): Always use *valp if
set.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-copy1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c

[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Nov 25 18:58:11 2015
New Revision: 230897

URL: https://gcc.gnu.org/viewcvs?rev=230897=gcc=rev
Log:
PR c++/67941
* lambda.c (maybe_add_lambda_conv_op): Mark _FUN as
no_sanitize_undefined.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/null-6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c

[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Wed Nov 25 19:56:18 2015
New Revision: 230901

URL: https://gcc.gnu.org/viewcvs?rev=230901=gcc=rev
Log:
PR c++/67941

* lambda.c (maybe_add_lambda_conv_op): Mark _FUN as
no_sanitize_undefined.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/ubsan/null-6.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/lambda.c

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
I see, thanks. I'm going to trivially tweak the dg-error.

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---

I've done some more digging and found that the switch from a gas-derived
as in Xcode 6.4 to the LLVM-based one in Xcode 7 caused this: assembling
the exact same .s file with both assemblers introduces the difference in
relocations causing ld to choke and the 32-bit bootstrap to break.

Command line is

as -arch i386 -force_cpusubtype_ALL -o make-temp-file.o make-temp-file.s

Rainer

[Bug tree-optimization/68523] CFG Expansion Computes Incorrect Block Frequencies for Nested Loops

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Scratch that, ch changes the loop but is not the culprit.

Note there is one further edge at expand time: 2->9 with prob 0%.
This is created by unswitch.  The transform is fine afaics, but it
doesn't update the execution freqs properly, giving the wrong
counts here.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[josh at joshtriplett dot org]

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

--- Comment #18 from Josh Triplett  ---
(In reply to PaX Team from comment #17)
> (In reply to Josh Triplett from comment #16)
> > (In reply to PaX Team from comment #14)
> > > can you give me an example of this?
> > 
> > Sparse warns if you can reach the same basic block with different context
> > values (for instance, with or without a lock held).  That warning *may*
> > indicate a problem, but it can also just indicate code too intricate for
> > Sparse to understand.
> 
> i see, so this would basically trigger every time a lock is taken/released
> based on a condition as in the example in comment #1?

Yes.

> or is there some
> deeper analysis done to avoid at least some false positives?

Nope.  Sparse always generates a warning in such a case.  Usually you can work
around that by simplifying your locking, which seems like a good idea
regardless.

> in any case, with my method this checking is pretty easy too since the SSA
> representation ensures that we get a phi for the local context tracking
> variable if different paths produce different values when a given basic
> block is reached. it also seems that gcc can eliminate at least some trivial
> false reports since none of your conditional locking examples produce a
> false positive or negative (however i expect real linux code to do worse).

I don't think it makes sense to issue "differing contexts for basic block"
warnings at all.

> > (In reply to Tom Tromey from comment #15)
> > > Anyway given that this is happening, I suggest closing this gcc bug.
> > 
> > Have we completely ruled out the possibility of a native GCC implementation?
> > This really doesn't seem specific to the Linux kernel in any way; it'd be
> > nice if this could work in most programs.  We could add annotations to
> > pthread locking functions, and any program using locking would benefit.
> 
> i agree, this context attribute based invariant verification is very generic
> and could be worked into a general gcc feature. the plugin approach is a
> good way to prototype it and get it some real life use before it'd make into
> the compiler.
> 
> speaking of generalization, the encoding of the lock expression (e.g., lock
> ptr) will have to change as it really doesn't seem feasible to refer to
> function arguments from an attribute.

Doesn't seem too unreasonable to handle, actually.  When parsing an attribute,
refer back to the function arguments; the context expression must either use
those or globals.

> as long as we expect to feed the
> compiler only manual annotations, the only thing that matters is that the
> lock expression be something unique, so as a compromise i suggest to simply
> make it a string constant, which would both preserve context for a human
> programmer and be also easy for the compiler to derive a unique name from
> for the local variable tracking the given context. i.e., instead of
> __attribute__((context(lock_expr, in, out))) we'd have
> __attribute__((context("lock_expr", in, out))) and ditto for calling
> __context__().

That fails for a really common case that should generate a warning:

spin_lock(_lock);
/* Piles of code */
spin_unlock(_other_lock);

I don't think stringizing the lock argument and using that as the context makes
sense, either, as it need not textually match to semantically match.

[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #2 from Steve Ellcey  ---
Aurelien,

I could not reproduce this on today’s top-of-tree or the top of the
gcc-5-branch.
Did you use any configure options when building GCC?

When you say 'compiled with debugging enabled' are you talking about just using
-g when compiling the test program or are you talking about something else?

I built a cross compiler on my x86 linux system targeting mips-linux-gnu and
used '-g -O2 -march=mips32r2' when compiling the test program but I did not get
a seg fault or an ICE or any other type of error.

[Bug c++/68434] [concepts] ICE: same canonical type node for different types

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Nov 25 22:13:23 2015
New Revision: 230909

URL: https://gcc.gnu.org/viewcvs?rev=230909=gcc=rev
Log:
PR c++/68434

* pt.c (tsubst): Set PLACEHOLDER_TYPE_CONSTRAINTS before
calling canonical_type_parameter.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr68434.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/67876] [6 Regression] ICE when compiling Firefox 38

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
I'll take a look.

[Bug rtl-optimization/68547] incorrect optimization

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
You invoke undefined behavior (out-of-bounds array access):

$ g++ -fsanitize=undefined ./test.cc 
$ ./a.out   
DEL element[1]=200 volatile 
./test.cc:17:57: runtime error: index 3 out of bounds for type 'unsigned int
[3]'
./test.cc:17:57: runtime error: load of address 0x00601a3c with
insufficient space for an object of type 'unsigned int' 
0x00601a3c: note: pointer points here
  2c 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
DEL element[1]=200 last_element_index=2 (should be 2) volatile
DEL element[1]=200
./test.cc:26:57: runtime error: index 3 out of bounds for type 'unsigned int
[3]'
./test.cc:26:57: runtime error: load of address 0x00601a3c with
insufficient space for an object of type 'unsigned int'
0x00601a3c: note: pointer points here
  2c 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00

[Bug c++/67876] [6 Regression] ICE when compiling Firefox 38

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
This is crashing in Martin's new reject_gcc_builtin code.

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #1 from Steve Ellcey  ---
Felix, I wasn't able to reproduce this with GCC 5.2 or with top-of-tree GCC
when compiling libpcap.  Can you include a preprocessed source file (cut down
if possible) and list exactly what options you used.

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[pageexec at gmail dot com]

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

--- Comment #17 from PaX Team  ---
(In reply to Josh Triplett from comment #16)
> (In reply to PaX Team from comment #14)
> > can you give me an example of this?
> 
> Sparse warns if you can reach the same basic block with different context
> values (for instance, with or without a lock held).  That warning *may*
> indicate a problem, but it can also just indicate code too intricate for
> Sparse to understand.

i see, so this would basically trigger every time a lock is taken/released
based on a condition as in the example in comment #1? or is there some deeper
analysis done to avoid at least some false positives?

in any case, with my method this checking is pretty easy too since the SSA
representation ensures that we get a phi for the local context tracking
variable if different paths produce different values when a given basic block
is reached. it also seems that gcc can eliminate at least some trivial false
reports since none of your conditional locking examples produce a false
positive or negative (however i expect real linux code to do worse).

> (In reply to Tom Tromey from comment #15)
> > Anyway given that this is happening, I suggest closing this gcc bug.
> 
> Have we completely ruled out the possibility of a native GCC implementation?
> This really doesn't seem specific to the Linux kernel in any way; it'd be
> nice if this could work in most programs.  We could add annotations to
> pthread locking functions, and any program using locking would benefit.

i agree, this context attribute based invariant verification is very generic
and could be worked into a general gcc feature. the plugin approach is a good
way to prototype it and get it some real life use before it'd make into the
compiler.

speaking of generalization, the encoding of the lock expression (e.g., lock
ptr) will have to change as it really doesn't seem feasible to refer to
function arguments from an attribute. as long as we expect to feed the compiler
only manual annotations, the only thing that matters is that the lock
expression be something unique, so as a compromise i suggest to simply make it
a string constant, which would both preserve context for a human programmer and
be also easy for the compiler to derive a unique name from for the local
variable tracking the given context. i.e., instead of
__attribute__((context(lock_expr, in, out))) we'd have
__attribute__((context("lock_expr", in, out))) and ditto for calling
__context__().

[Bug c++/67354] [5 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 25 21:13:00 2015
New Revision: 230905

URL: https://gcc.gnu.org/viewcvs?rev=230905=gcc=rev
Log:
Backported from mainline
2015-11-20  Jakub Jelinek  

PR c++/67354
* cp-tree.h (defer_mangling_aliases): Declare.
(generate_mangling_aliases): New prototype.
* decl2.c (defer_mangling_aliases): New variable.
(note_mangling_alias): Use !defer_mangling_aliases
instead of at_eof.
(generate_mangling_aliases): No longer static. Clear
defer_mangling_aliases.
* optimize.c (maybe_thunk_body): Defer emitting mangling aliases
if !defer_mangling_aliases until the fns are put into the same
comdat group.

* g++.dg/abi/mangle67.C: New test.

2015-05-09  Aldy Hernandez  

PR bootstrap/66085
* decl2.c (note_mangling_alias): Declare arguments as unused.

2015-05-08  Jason Merrill  

* decl2.c (mangling_aliases): New variable.
(note_mangling_alias, generate_mangling_aliases): New.
(cp_write_global_declarations): Call generate_mangling_aliases.
(generate_mangling_alias): Split out from...
* mangle.c (mangle_decl): ...here.
* cp-tree.h: Declare note_mangling_alias.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/mangle67.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/cp-tree.h
branches/gcc-5-branch/gcc/cp/decl2.c
branches/gcc-5-branch/gcc/cp/mangle.c
branches/gcc-5-branch/gcc/cp/optimize.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/67354] [5 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
Fixed for 5.3+.

[Bug c++/68509] [6 regression][C++1z] ICE: in check_return_expr, at cp/typeck.c:8635

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jason Merrill  ---
Dup.

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

[Bug fortran/68546] New: passing non-contiguous associated array section garbles results

[klindsay at ucar dot edu]

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

Bug ID: 68546
   Summary: passing non-contiguous associated array section
garbles results
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klindsay at ucar dot edu
  Target Milestone: ---

Created attachment 36840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36840=edit
program demonstrating problem

Hi,

I've associated a non-contiguous array section to a name.
I.e. A2=>A(2,:)
When I pass A2 to a subroutine, the contents are garbled (see below).
When I compile and run the attached program, I expect the output to be

write statement with fixed i section
 201.0 202.0 203.0
--
calling foo with fixed i section
 201.0 202.0 203.0
--
write statement with associated fixed i section
 201.0 202.0 203.0
--
calling foo with associated fixed i section
 201.0 202.0 203.0
--

Instead, with gfortran v5.2.0, the last 4 lines are
--
calling foo with associated fixed i section
 201.0 301.0 102.0
--

If the contents of the associate construct are (A2=>A(:,2)), then the output
from the program is as I would expect it to be. So the problem seems to be
related to the non-contiguous nature of the array section. 

Could this be looked into please?

Thank you,
Keith Lindsay

[Bug rtl-optimization/68547] New: incorrect optimization

[jan.sm...@alcatel-lucent.com]

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

Bug ID: 68547
   Summary: incorrect optimization
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

Created attachment 36841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36841=edit
test case

$ g++ test.cc -o test -O2 -Wall && ./test
DEL element[1]=200 volatile
DEL element[1]=200 last_element_index=2 (should be 2) volatile
DEL element[1]=200
DEL element[1]=200 last_element_index=1 (should be 2)
$ g++ test.cc -o test -O0 -Wall && ./test
DEL element[1]=200 volatile
DEL element[1]=200 last_element_index=2 (should be 2) volatile
DEL element[1]=200
DEL element[1]=200 last_element_index=2 (should be 2)

[Bug rtl-optimization/68547] incorrect optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
That is:
(array_of_elements[last_element_index] != 0) && (last_element_index <
TEST_ARRAY_SIZE)

You should swap those two expressions to get correct behavior.

[Bug bootstrap/66085] [6 Regression] Revision r222934 breaks bootstrap on darwin.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 25 21:13:00 2015
New Revision: 230905

URL: https://gcc.gnu.org/viewcvs?rev=230905=gcc=rev
Log:
Backported from mainline
2015-11-20  Jakub Jelinek  

PR c++/67354
* cp-tree.h (defer_mangling_aliases): Declare.
(generate_mangling_aliases): New prototype.
* decl2.c (defer_mangling_aliases): New variable.
(note_mangling_alias): Use !defer_mangling_aliases
instead of at_eof.
(generate_mangling_aliases): No longer static. Clear
defer_mangling_aliases.
* optimize.c (maybe_thunk_body): Defer emitting mangling aliases
if !defer_mangling_aliases until the fns are put into the same
comdat group.

* g++.dg/abi/mangle67.C: New test.

2015-05-09  Aldy Hernandez  

PR bootstrap/66085
* decl2.c (note_mangling_alias): Declare arguments as unused.

2015-05-08  Jason Merrill  

* decl2.c (mangling_aliases): New variable.
(note_mangling_alias, generate_mangling_aliases): New.
(cp_write_global_declarations): Call generate_mangling_aliases.
(generate_mangling_alias): Split out from...
* mangle.c (mangle_decl): ...here.
* cp-tree.h: Declare note_mangling_alias.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/mangle67.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/cp-tree.h
branches/gcc-5-branch/gcc/cp/decl2.c
branches/gcc-5-branch/gcc/cp/mangle.c
branches/gcc-5-branch/gcc/cp/optimize.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/67089] [4.9/5 Regression] Integer overflow checks not optimized on x86/x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression]|[4.9/5 Regression] Integer
   |Integer overflow checks not |overflow checks not
   |optimized on x86/x86_64 |optimized on x86/x86_64

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk so far.  Wonder if this is desirable to backport.

[Bug c++/68396] function auto-deduced return types get incorrectly classified as parameter packs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||lucdanton at free dot fr

--- Comment #4 from Jason Merrill  ---
*** Bug 68509 has been marked as a duplicate of this bug. ***

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[tromey at gcc dot gnu.org]

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

--- Comment #15 from Tom Tromey  ---
(In reply to Josh Triplett from comment #13)

> Note that in addition to complaining if *any* exit to the function doesn't
> have the correct "out" value, you also need to complain if calls to
> functions with the context attribute don't have the necessary "in" value. 

You also need to have checks to ensure that the value doesn't drop below 0.

Anyway given that this is happening, I suggest closing this gcc bug.

[Bug testsuite/68545] New: gcc.dg/guality/guality.exp hides compiler error

[hjl.tools at gmail dot com]

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

Bug ID: 68545
   Summary: gcc.dg/guality/guality.exp hides compiler error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

When check in gcc.dg/guality/guality.exp fails due to compiler error,
guality.exp is skipped without any error messages, which hides compiler
error.

[Bug inline-asm/61692] ICE in extract_insn in recog.c for asm with many parameters

[mrs at gcc dot gnu.org]

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

--- Comment #5 from mrs at gcc dot gnu.org  ---
Mine.  Mine supports 33. Don't expect it to go past 40.  Most folks won't.  In
10-30 years, maybe we might need to update to 50, but we can do that then.

[Bug middle-end/66269] Issues with mixing strict aliasing (verify_type ICE with Ada)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
This was fixed (well masked) by:
2015-11-24  Jan Hubicka  

* alias.c (get_alias_set): Before checking TYPE_ALIAS_SET_KNOWN_P
double check that type is main variant.
* tree.c (build_variant_type_copy): Clear TYPE_ALIAS_SET when producing
variant.
(verify_type_variant): Verify that variants have no
TYPE_ALIAS_SET_KNOWN_P set
* tree-streamer-out.c (pack_ts_type_common_value_fields): Reorder
streaming so constant fields come first; stream TYPE_ALIAS_SET==0
only for main variants; stream TYPE_ALIAS_SET as a bit.
* tree-streamer-in.c (unpack_ts_type_common_value_fields): Update
accordingly.

the underlying issue that -fstrict-aliasing does not work correctly across
different units or with optimization attribute remains.  I will open
independent bug for this. At least here was nothing Ada specific.

[Bug middle-end/66325] [6 Regression] ICE in gcc.c-torture/execute/930408-1.c, verify_type fails with --enable-checking=yes on arm-none-eabi

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
I believe this was fixed by the patch above.

[Bug c/67106] [6 Regression] ICE: verify_type failed: type variant differs by TYPE_PACKED. with -g -fpack-struct

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
Actually in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66325 I already went
for variant walk.  Will thus test:
Index: c/c-decl.c
===
--- c/c-decl.c (revision 230924)
+++ c/c-decl.c (working copy)
@@ -7213,7 +7213,8 @@ start_struct (location_t loc, enum tree_
 }

   C_TYPE_BEING_DEFINED (ref) = 1;
-  TYPE_PACKED (ref) = flag_pack_struct;
+  for (tree v = TYPE_MAIN_VARIANT (ref); v; v = TYPE_NEXT_VARIANT (v))
+TYPE_PACKED (v) = flag_pack_struct;

   *enclosing_struct_parse_info = struct_parse_info;
   struct_parse_info = XNEW (struct c_struct_parse_info);
Index: testsuite/gcc.c-torture/compile/pr67106.c
===
--- testsuite/gcc.c-torture/compile/pr67106.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr67106.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-options "-g -fpack-struct" } */
+typedef struct S S;
+
+struct S
+{
+  struct
+  {
+S *s;
+  };
+  int a;
+};
+

[Bug lto/66103] [6 Regression] ICE verify_type failed with LTO and "-g -O0" via dwarf2out.c's gen_type_die_with_usage

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Jan Hubicka  ---
This testcase seems to work now even with -ffat-lto-objects, so I am closing
the PR.

[Bug fortran/68486] [6 Regression] 187.facerec in SPEC CPU 2000 failed to build

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #17 from Steve Kargl  ---
On Wed, Nov 25, 2015 at 09:15:04AM +, jgreenhalgh at gcc dot gnu.org wrote:
> > 
> > Of course.  As I stated, it won't hurt anything.
> > FAILs in the testsuite are not a problem.  The
> > issue with EXPR_FUNCTION and cshift is a problem.
> 
> The hurt is for those of us investigating the new regressions... That was 10
> minutes of my time to investigate, multiply that by the number of people
> watching for FAILs on their favourite targets (particularly with trunk as it 
> is
> at the end of stage 1) there is certainly enough hurt to go round.
> 
> Please revert the broken testcase and leave it for when you fix pr68227.
> 

It took you 10 minutes to type 68227 into bugzilla's search feature?

I intend to commit the fix today.  Unfortunately, I have a real job
and fixing gfortran is a hobby.  Unnecessary code churn in the 
repo is well unnecessary.

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Nov 25 15:04:33 2015
New Revision: 230873

URL: https://gcc.gnu.org/viewcvs?rev=230873=gcc=rev
Log:
2015-11-25  Steven G. Kargl  

PR fortran/68227
* trans-stmt.c (gfc_do_allocate): Convert gcc_assert argument into 
into part of conditional statement.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed of trunk.  Thanks for he bug reports.

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Placate the masses.

[Bug fortran/68546] passing non-contiguous associated array section garbles results

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
 Depends on||64773

--- Comment #2 from Thomas Koenig  ---
We're missing an internal_pack here.

This works, as expected:

module x
contains
subroutine foo(A_sect)

   real :: A_sect(:)

   write(*, '(3(1x,f5.1))') A_sect(:)

end subroutine foo
end module x

program assoc
   use x
   integer :: i, j
   real :: A(3,3)

   do j = 1, 3
  do i = 1, 3
 A(i,j) = 100.0*i + j
  end do
   end do

   write(*,'(a)') 'write statement with fixed i section'
   write(*, '(3(1x,f5.1))') A(2,:)
   write(*,'(a)') '--'

   write(*,'(a)') 'calling foo with fixed i section'
   call foo(A(2,:))
   write(*,'(a)') '--'

   write(*,'(a)') 'write statement with associated fixed i section'
   associate( A2 => A(2,:) )
  write(*, '(3(1x,f5.1))') A2
   end associate
   write(*,'(a)') '--'

   write(*,'(a)') 'calling foo with associated fixed i section'
   associate( A2 => A(2,:) )
  call foo(A2)
   end associate
   write(*,'(a)') '--'

end program assoc


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64773
[Bug 64773] [F2008] Not packing arrays with changing variable used for size in
block

[Bug bootstrap/67289] ICE in ipa-devirt.c

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
gnat1 build works for me, but similar problem reproduces for me during Firefox
build.  Apparently we manage to set TREE_PUBLIC of TYPE_STUB_DECL of an
anonymous type.  I will try to track down where it hapepns (probably before LTO
streaming)

[Bug c++/65091] decltype(~arg) fails for template functions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||joel.falcou at lri dot fr

--- Comment #6 from Paolo Carlini  ---
*** Bug 68144 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68521] [6.0 regression] ICE on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> I get some (unrelated) ICE in my heavily patched dev tree with that patch so
> cannot verify it does anything good.

Ah, it's the patch itself not working (domwalk being confused because the
pass splits blocks during the walk)

[Bug c++/58910] std::Tuple_impl is non constexpr when using identical userdefined structs as template-args

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Nov 25 10:00:02 2015
New Revision: 230860

URL: https://gcc.gnu.org/viewcvs?rev=230860=gcc=rev
Log:
2015-11-25  Paolo Carlini  

PR c++/58910
* g++.dg/cpp0x/constexpr-tuple2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-tuple2.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

[pageexec at gmail dot com]

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

--- Comment #14 from PaX Team  ---
(In reply to Josh Triplett from comment #13)
> That sounds really plausible to me.  GCC's constant propagation seems likely
> to do *at least* as well as Sparse does, if not better.  (As long as you
> have optimizations turned on, anyway.)

note that optimizations are not actually necessary for the scheme to work, it
just means that the check(s) will have to do more work as you'll get a phi and
have to traverse back the data flow to see if any unexpected values can end up
there (optimizations basically do this data flow tracking for free and result
in dead code elimination thus making it easier on the checks). in fact i expect
that this will already happen on real linux code so the plugin will have to
handle this case anyway.

> Note that in addition to complaining if *any* exit to the function doesn't
> have the correct "out" value, you also need to complain if calls to
> functions with the context attribute don't have the necessary "in" value. 

sure, it's easy enough to inject more checks than just at the function return
sites, i just wanted to validate my idea first then do the make-it-usable part
which includes increased coverage too.

> You may want to make that a separate warning option, though, as that option
> tends to force adding annotations to far more functions.

actually one idea for the future is to extend the plugin to be IPA then LTO
aware so that it can discover the acquire/release properties itself based on an
initial set of 'seed' functions that have to be marked by hand (and which
already are i guess, all the direct callers of __context__ basically). we have
experience in this area with the size overflow and other plugins, so the
infrastructure is there already (albeit the LTO part is held up by PR61311).

> This approach won't necessarily provide the "different contexts for basic
> block" warning that Sparse has, but I don't necessarily think we need that;

can you give me an example of this? the thing is, my approach tracks the
context with statement granularity so if you can tell the compiler where you
expect specific states (such as the context attr on callees) checks can be
inserted there easily, down to individual statements (say, the structure field
accesses you mentioned).

[Bug target/67089] [4.9/5/6 Regression] Integer overflow checks not optimized on x86/x86_64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 25 08:58:32 2015
New Revision: 230856

URL: https://gcc.gnu.org/viewcvs?rev=230856=gcc=rev
Log:
PR target/67089
* tree-ssa-math-opts.c (uaddsub_overflow_check_p,
match_uaddsub_overflow): New functions.
(pass_optimize_widening_mul::execute): Call match_uaddsub_overflow.

* gcc.dg/pr67089-1.c: New test.
* gcc.dg/pr67089-2.c: New test.
* gcc.dg/pr67089-3.c: New test.
* gcc.dg/pr67089-4.c: New test.
* gcc.dg/pr67089-5.c: New test.
* gcc.dg/pr67089-6.c: New test.
* gcc.dg/pr67089-7.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr67089-1.c
trunk/gcc/testsuite/gcc.dg/pr67089-2.c
trunk/gcc/testsuite/gcc.dg/pr67089-3.c
trunk/gcc/testsuite/gcc.dg/pr67089-4.c
trunk/gcc/testsuite/gcc.dg/pr67089-5.c
trunk/gcc/testsuite/gcc.dg/pr67089-6.c
trunk/gcc/testsuite/gcc.dg/pr67089-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug c++/68530] [C++14] sorry, unimplemented: unexpected AST of kind loop_expr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-25
 Ever confirmed|0   |1

[Bug fortran/68534] No error on mismatch in number of arguments between submodule and module interface

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-25
 CC||damian at sourceryinstitute 
dot or
   ||g,
   ||kargl at apl dot 
washington.edu,
   ||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Confirmed on FC21/x86_64

Paul

[Bug c++/68144] operator~ in trailing return type leads to spurrious error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
Dup.

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

[Bug c++/68161] Inconsistent behaviour of unnamed field with inheritance.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/68528] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-25
 Ever confirmed|0   |1
  Known to fail||4.3.5, 4.8.5, 5.2.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/68521] [6.0 regression] ICE on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I get some (unrelated) ICE in my heavily patched dev tree with that patch so
cannot verify it does anything good.

[Bug tree-optimization/68521] [6.0 regression] ICE on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0