[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[eric at baculasystems dot com]

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

--- Comment #4 from Eric Bollengier  ---
I don't know exactly when someone decided that a doing memset(buf, 0,
sizeof(buf)); leads to an "undefined behavior", but it's how C and C++ work
since quite long time. And it's also why the operator new() is so useful.

I see the interest of the optimization, however I think that it's not correctly
implemented.

If GCC can find out that the code is

void *operator new(size_t x) {
...
  a = malloc(x);
  memset(a, 0, x);
  return a;
}

Then, it is probably OK to strip out the memset() call. However, here, the
optimization looks to be only about the memset followed by the return call in
the new operator.

void *operator new(size_t x) {

   memset(a, 0, x);
   return a;
}

GCC doesn't check that the memory is coming from a malloc() call or if
something was modified in the memory before striping out the memset
automatically. I think that it is an incorrect behavior. The memory can come
from various places (like a pool of existing buffers), it can be dirty due to
some work done before the memset.

It looks that the optimizer thinks that the object returned by the function is
a "dead object", but it is not the case, we return it to the caller.

The written code explicitly asks to set a value to a memory area (to avoid
undefined behavior), and the compiler decided to not do what is written, and it
leads to a situation where the memory doesn't contain what the program expects. 

Thanks,

Best Regards,
Eric

[Bug c/71889] New: [5.4 Regression] [MIPS] python: "insn does not satisfy its constraints"

[kabel at blackhole dot sk]

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

Bug ID: 71889
   Summary: [5.4 Regression] [MIPS] python: "insn does not satisfy
its constraints"
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kabel at blackhole dot sk
  Target Milestone: ---

Created attachment 38909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38909=edit
_codecs_cn.preprocessed.c

Compiling Python-2.7.11/Modules/cjkcodecs/_codecs_cn.c with gcc-5.4.0 on MIPS
with -O2 results in "insn does not satisfy its constraints" error (full in
attachment).

When instead of -O2 I try all the -f flags that are specified by manpage to be
implied by -O2 (and -O1), compilation is successful - I thus think that there
are some more -f options implied (which are not in the manpage) or there is
some other error.

I am 98% sure that this was an error in 5.3.0 as well.

Attached preprocessed _codecs_cn.c and also commands used for both
compilations.

[Bug c/71889] [5.4 Regression] [MIPS] python: "insn does not satisfy its constraints"

[kabel at blackhole dot sk]

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

Marek Behun  changed:

   What|Removed |Added

 CC||kabel at blackhole dot sk

--- Comment #1 from Marek Behun  ---
Created attachment 38910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38910=edit
commands used for both compilations.txt

[Bug c++/71888] New: internal compiler error: in force_type_die, at dwarf2out.c:23236

[patrick at motec dot com.au]

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

Bug ID: 71888
   Summary: internal compiler error: in force_type_die, at
dwarf2out.c:23236
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at motec dot com.au
  Target Milestone: ---

The following code snippet causes an internal compiler error in gcc 6.1.0 if
built with -g.

namespace std
{
  using ::__builtin_va_list;
}

$ g++ -g bug.cpp
bug.cpp:3:11: internal compiler error: in force_type_die, at dwarf2out.c:23236
   using ::__builtin_va_list;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

--- Comment #4 from asmwarrior  ---
It looks like the code is called from an inline function, you can see this code
snippet in the prepossessed file.


inline wxObject *wxCheckDynamicCast(wxObject *obj, wxClassInfo *classInfo)
{
return obj && obj->GetClassInfo()->IsKindOf(classInfo) ? obj : 
# 502 "..\\..\\include/wx/object.h" 3 4
  __null
# 502 "..\\..\\include/wx/object.h"
  ;
}

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

asmwarrior  changed:

   What|Removed |Added

 CC||asmwarrior at gmail dot com

--- Comment #3 from asmwarrior  ---
Created attachment 38908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38908=edit
The preprocessed file

This is the command I use to generate the preprocessed file(a.cpp in zip)

g++ -E -o a.cpp -O2 -mthreads  -DHAVE_W32API_H -D__WXMSW__   -DNDEBUG   
-D_UNICODE   -I..\..\lib\gcc_dll\mswu -I..\..\include  -W -Wall -DWXBUILDING
-I..\..\src\tiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib
-I..\..\src\regex -I..\..\src\expat\lib -DwxUSE_BASE=1 -DWXMAKINGDLL  
-Wno-ctor-dtor-privacy  -Wno-unused-local-typedefs -Wno-deprecated-declarations
-fno-keep-inline-dllexport -g -MTgcc_mswudll\monodll_xh_sizer.o
-MFgcc_mswudll\monodll_xh_sizer.o.d -MD -MP ../../src/xrc/xh_sizer.cpp

I use TDM GCC5.1 under Windows XP, I use wxWidgets 2.8.12 official release. The
command is run from the folder \build\msw\.

[Bug rtl-optimization/71887] New: wrong code (SIGFPE) at -O1 and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

Bug ID: 71887
   Summary: wrong code (SIGFPE) at -O1 and above on
x86_64-linux-gnu (in both 32-bit and 64-bit modes)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O1
and above in both 32-bit and 64-bit modes.

This is a regression from 6.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160714 (experimental) [trunk revision 238331] (GCC) 
$ 
$ gcc-trunk -O0 small.c; ./a.out
$ gcc-6.1 -O1 small.c; ./a.out
$ 
$ gcc-trunk -O1 small.c
$ ./a.out
Floating point exception (core dumped)
$ 





char a;
int b;

int main ()
{
  unsigned char c = a, d = a;
  b = d == 0 ? c : c % d;
  return 0;
}

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
(In reply to Martin Sebor from comment #4)
> Second, it's unclear to me what purpose the warning is meant to serve in
> this case.  Since a function attribute always applies to the instance of the
> function it decorates and never affects its type the warning doesn't
> indicate anything unusual or unexpected, and only serves to confuse users. 

Actually, most of these attributes, including warn_unused_result, apply to the
function type, not to the function declaration.  That's why you get the
warning.  As an example of this:

__attribute ((warn_unused_result)) int f();

decltype(f)* p;

int main()
{
  p(); // warns about unused result, by design.
}

The warning is letting you know that the attribute is being discarded, so you
don't get the warning within a template:

__attribute ((warn_unused_result)) int f();

template 
struct A {
  T *p;
  void g() { p(); } // no warning   
};

int main()
{
  A().g();
}

Note that the C++17 [[nodiscard]] attribute applies to the function, so it
works differently.

> (In cases where the function is declared in a system header it's also
> unclear how the should be avoided.)

If you don't want this warning, -Wno-ignored-attributes will silence it.

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #14 from Vincent  ---
The bug is still in 6.1.0.

[Bug c++/71117] [6/7 Regression] Overeager application of conversion to function pointer during overload resolution of call to function object

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-07-14
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/71886] Incorrect error on operator() being an member in template

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
Clang also rejects the template.

[Bug c++/71886] Incorrect error on operator() being an member in template

[tomaszkam at gmail dot com]

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

--- Comment #1 from Tomasz Kamiński  ---
Such code is useful, for example in case of variant universal
constructor from U&&, where there is a need to determine best candidate among
the function taking parameter each type be value.

This may be implemented using:
template
struct single_call
{
   Sig operator();
};

template
struct multiple_calls : single_call...
{
  using single_call::operator()...;
};

Then to determine an index of type to be constructed can be done by:
decltype(multiple_calls)::value
Where Is is [0,1,2] and Ts is [T0, T1, T2].

[Bug c++/71886] New: Incorrect error on operator() being an member in template

[tomaszkam at gmail dot com]

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

Bug ID: 71886
   Summary: Incorrect error on operator() being an member in
template
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomaszkam at gmail dot com
  Target Milestone: ---

Following class correctly compiles without any error in GCC 5.1.0:
struct NonTemplate
{
typedef void type();

type operator(); //Actually declares an member function.
};

However in case of the class template:
template
struct Template
{
typedef T type;

T operator();
};
Followinge error is generated:
error: declaration of 'operator()' as non-function
 T operator();
Despite the fact that Template is identical to NonTemplate.

[Bug testsuite/71865] [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714

[seurer at linux dot vnet.ibm.com]

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

--- Comment #4 from Bill Seurer  ---
Thanks, that fixed things up.

[Bug fortran/29819] Error/warning message should ignore comments for "1" in %C output

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
fixed on trunk

[Bug fortran/29819] Error/warning message should ignore comments for "1" in %C output

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jul 14 20:54:40 2016
New Revision: 238354

URL: https://gcc.gnu.org/viewcvs?rev=238354=gcc=rev
Log:
2016-07-14  Steven G. Kargl  

PR fortran/29819
* parse.c (parse_contained): Use proper locus.


2016-07-14  Steven G. Kargl  

PR fortran/29819
* gfortran.dg/bind_c_usage_9.f03: Move dg-error.
* gfortran.dg/contains.f90: Ditto.
* gfortran.dg/contains_empty_1.f03: Ditto.
* gfortran.dg/submodule_3.f08: Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_9.f03
trunk/gcc/testsuite/gfortran.dg/contains.f90
trunk/gcc/testsuite/gfortran.dg/contains_empty_1.f03
trunk/gcc/testsuite/gfortran.dg/submodule_3.f08

[Bug c++/56856] the location of Wformat warnings points *after* the format string

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #7)
> Thanks for the background and the pointer.  Is this report then a duplicate
> of bug 43486?

It may be possible to fix this one imperfectly without fixing PR43486. As you
say, one can start passing locations from the parsing point to the warning
point case by case and eventually you will cover most testcases.

Many people have tried to fix PR43486 and eventually desisted. It doesn't seem
to be a problem that can be solved piecemeal: either you have a thoroughly
designed solution that is supported by the maintainers and you commit yourself
to do the transition in one go and fix all the fall-out or it will never
happen.

[Bug middle-end/50060] intrinsics not folded by the middle-end

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Shouldn't this be solvable in C++14 and later?
We still reject it:
error: ‘((y = 1), 6.2e-1)’ is not a constant expression
but I suppose with some hacking of cp/constexpr.c this could be handled.

constexpr double f1 (double x)
{
  int y = 0;
  return __builtin_frexp (x, );
}
constexpr int f2 (double x)
{
  int y = 0;
  __builtin_frexp (x, );
  return y;
}
constexpr double c1 = f1 (1.24);
constexpr int c2 = f2 (1.24);

[Bug c++/71712] Redundant ABI tags for conversion operator

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
See https://gcc.gnu.org/gcc-6/porting_to.html (More aggressive optimization of
-flifetime-dse).

You're invoking undefined behavior; -flifetime-dse=1 is a workaround.

[Bug testsuite/71865] [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 14 18:42:53 2016
New Revision: 238353

URL: https://gcc.gnu.org/viewcvs?rev=238353=gcc=rev
Log:
PR testsuite/71865
* gcc.dg/diagnostic-token-ranges.c: Add -std=c11 to dg-options.
(wide_string_literal_in_asm): Use __asm instead of asm, adjust
expected diagnostics.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c

[Bug c/71858] Surprising suggestions for misspellings

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 14 18:34:00 2016
New Revision: 238352

URL: https://gcc.gnu.org/viewcvs?rev=238352=gcc=rev
Log:
PR c/71858
* c-decl.c (lookup_name_fuzzy): Ignore binding->invisible.

* gcc.dg/spellcheck-identifiers.c (snprintf): Declare.
* gcc.dg/spellcheck-identifiers-2.c: New test.
* gcc.dg/diagnostic-token-ranges.c (nanl): Declare.
* c-c++-common/attributes-1.c: Adjust dg-prune-output.

Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-identifiers-2.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/attributes-1.c
trunk/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c
trunk/gcc/testsuite/gcc.dg/spellcheck-identifiers.c

[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 14 18:30:38 2016
New Revision: 238351

URL: https://gcc.gnu.org/viewcvs?rev=238351=gcc=rev
Log:
PR tree-optimization/71872
* tree-data-ref.c (get_references_in_stmt): Ignore references
with is_gimple_constant get_base_address.

* gcc.c-torture/compile/pr71872.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr71872.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
This is during ldist, destroy_loop removes a loop which contains a PHI that is
used by a debug stmt used after the loop, and during
rewrite_into_loop_closed_ssa this is detected and ICEs.

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.2

--- Comment #2 from Jakub Jelinek  ---
Started with r231162.

[Bug c++/71164] [6/7 Regression] tree check fail at cp/pt.c:12961

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
The original testcase works with current 6 branch and trunk.

[Bug fortran/71839] undefined reference to `_gfortran_caf_stop_str'

[mexas at bristol dot ac.uk]

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

--- Comment #7 from Anton Shterenlikht  ---
submitted as OCA ticket 207:
 https://github.com/sourceryinstitute/opencoarrays/issues/207

hope to close this ticket when there is some clarity from OCA people

[Bug c++/71495] [6/7 Regression] Spurious "note: initializing argument ... of ..." without any warning/error

[jason at gcc dot gnu.org]

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

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++/71511] [6/7 Regression] ICE on valid C++11 code (with decltype) on x86_64-linux-gnu: in cxx_incomplete_type_diagnostic, at cp/typeck2.c:567

[jason at gcc dot gnu.org]

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

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 fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[vehre at gcc dot gnu.org]

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

--- Comment #10 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Thu Jul 14 17:07:47 2016
New Revision: 238347

URL: https://gcc.gnu.org/viewcvs?rev=238347=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2016-07-14  Andre Vehreschild  

PR fortran/70842
* gfortran.dg/select_type_35.f03: New test.

gcc/fortran/ChangeLog:

2016-07-14  Andre Vehreschild  

PR fortran/70842
* simplify.c (gfc_simplify_len): Only for unlimited polymorphic
types replace the expression's _data ref with a _len ref.


Added:
trunk/gcc/testsuite/gfortran.dg/select_type_35.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71885] Incorrect code generated with -01, function calls are missing

[eric at baculasystems dot com]

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

--- Comment #2 from Eric Bollengier  ---
Created attachment 38907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38907=edit
c++ file that reproduces the issue

[Bug c++/71885] Incorrect code generated with -01, function calls are missing

[eric at baculasystems dot com]

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

--- Comment #1 from Eric Bollengier  ---
Created attachment 38906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38906=edit
ii file generated with -O0

[Bug c++/71885] New: Incorrect code generated with -01, function calls are missing

[eric at baculasystems dot com]

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

Bug ID: 71885
   Summary: Incorrect code generated with -01, function calls are
missing
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at baculasystems dot com
  Target Milestone: ---

Created attachment 38905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38905=edit
.ii file generated with -O1 option

I overload the new operator in a class (to initialize the memory to 0 and track
memory leaks), and after the upgrade from GCC 5.x to 6.1, my program stopped to
work correctly.

If I tweak a little bit the new operator (I add a printf() inside, or I do all
operations in one line memset(malloc()) instead of malloc() ; memset();) the
code is generated correctly.

I have a small test file, not sure this is the best example.

In my little program, I have two set of classes, one that is properly
generated, and an other one that is buggy. The only difference between the two
is a "printf()" in a function. The good result should be a == 0

# g++ -Wall -00 new.c
# ./a.out
new is called from new.c:81 and it works!
test_ok a == 0
testa == 0


# g++ -Wall -01 new.c
# ./a.out
test_ok a == 0
testa == 1431655765

I'm running Archlinux.

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.1.1 20160707 (GCC) 

Thanks

[Bug fortran/71883] ICE in identical_array_ref, at fortran/dependency.c:104

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---


Runtime behavior :


$ cat y1.f90
program p
   character(3), allocatable :: z(:,:)
   z(1:2,1:2) = 'abc'
   z(2,1) = z(1,2)
   z(2,1) = z(1,2)
end


$ gfortran-6 -g -O0 -Wall -fcheck=all -fno-frontend-optimize y1.f90
$ a.out
At line 3 of file y1.f90
Fortran runtime error: Index '1' of dimension 2 of array 'z' outside of
expected range (47021301956608:0)

Error termination. Backtrace:
#...

[Bug fortran/71883] ICE in identical_array_ref, at fortran/dependency.c:104

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Backup tests, analogous backtrace :


$ cat z2.f90
program p
   character(:), allocatable :: z(:,:)
   z(1:2,1:2) = 'abc'
   z(2,1) = z(12)
   z(21) = z(1,2)
end


$ cat z3.f90
program p
   character(3), allocatable :: z(:,:)
   z(1:2,1:2) = 'abc'
   z(2,1) = z(-1)
   z(2,1) = z(99)
   z(2,1) = z(huge(0))
   z(2,1) = z(-huge(0))
   z(-1) = z(2,1)
   z(99) = z(2,1)
   z(huge(0)) = z(2,1)
   z(-huge(0)) = z(2,1)
end


$ cat z4.f90
program p
   character(:), allocatable :: z(:,:)
   z(1:2,1:2) = 'abc'
   z(2,1) = z(-1)
   z(2,1) = z(99)
   z(2,1) = z(huge(0))
   z(2,1) = z(-huge(0))
   z(-1) = z(2,1)
   z(99) = z(2,1)
   z(huge(0)) = z(2,1)
   z(-huge(0)) = z(2,1)
end

[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Another source position with obviously invalid code :


$ cat za.f90
program p
   character(:), allocatable :: z
   allocate (character(*) :: z)
end


$ gfortran-7-20160710 za.f90
za.f90:3:0:

allocate (character(*) :: z)

internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5698
0x7a17f2 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:5698
0x71bf87 trans_code
../../gcc/fortran/trans.c:1838
0x74ac88 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6171
0x6d6860 translate_all_program_units
../../gcc/fortran/parse.c:5914
0x6d6860 gfc_parse_file()
../../gcc/fortran/parse.c:6120
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/71884] New: ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71884
   Summary: ICE in gfc_trans_allocate, at
fortran/trans-stmt.c:5582 and :5698
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With these snippets :


$ cat z1.f90
program p
   class(*), allocatable :: x
   allocate (x, source=null())
end


$ cat z2.f90
program p
   class(*), allocatable :: x
   allocate (x, mold=null())
end


$ gfortran-6 z2.f90
z2.f90:3:0:

allocate (x, mold=null())

internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5573


$ gfortran-7-20160710 z2.f90
z2.f90:3:0:

allocate (x, mold=null())

internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5582
0x7a1d26 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:5582
0x71bf87 trans_code
../../gcc/fortran/trans.c:1838
0x74ac88 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6171
0x6d6860 translate_all_program_units
../../gcc/fortran/parse.c:5914
0x6d6860 gfc_parse_file()
../../gcc/fortran/parse.c:6120
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug c++/70977] [6/7 Regression] Out of memory during compilation of facebook/wangle (flag c++0x works, flag c++14 fails).

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #9 from Romain Geissler  ---
Note: this affects builds of Facebook's Folly in C++14 with gcc 6 too. See
https://github.com/facebook/folly/issues/418

[Bug rtl-optimization/71878] ICE in cselib_record_set

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Author: thopre01
Date: Thu Jul 14 16:41:06 2016
New Revision: 238346

URL: https://gcc.gnu.org/viewcvs?rev=238346=gcc=rev
Log:
2016-07-14  Thomas Preud'homme  

gcc/
PR rtl-optimization/71878
* lra-constraints.c (match_reload): Pass information about other
output operands.  Create new unique register value if matching input
operand shares same register value as output operand being considered.
(curr_insn_transform): Record output operands already processed.

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

[Bug fortran/71883] New: ICE in identical_array_ref, at fortran/dependency.c:104

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71883
   Summary: ICE in identical_array_ref, at
fortran/dependency.c:104
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICE on rank mismatch or typo with experimental (--enable-checking=yes)
versions 7, 6, and maybe older. No ICE for release versions 4.9, 5, 6.


$ cat z1.f90
program p
   character(3), allocatable :: z(:,:)
   z(1:2,1:2) = 'abc'
   z(2,1) = z(12)
   z(21) = z(1,2)
end


$ gfortran-6 z1.f90# release
z1.f90:4:13:

z(2,1) = z(12)
 1
Error: Rank mismatch in array reference at (1) (1/2)
z1.f90:5:4:

z(21) = z(1,2)
1
Error: Rank mismatch in array reference at (1) (1/2)



$ gfortran-7-20160710 z1.f90   # experimental
z1.f90:4:13:

z(2,1) = z(12)
 1
Error: Rank mismatch in array reference at (1) (1/2)
z1.f90:5:4:

z(21) = z(1,2)
1
Error: Rank mismatch in array reference at (1) (1/2)
f951: internal compiler error: in identical_array_ref, at
fortran/dependency.c:104
0x70fdee identical_array_ref
../../gcc/fortran/dependency.c:104
0x70fdee are_identical_variables
../../gcc/fortran/dependency.c:164
0x70fdee gfc_dep_compare_expr(gfc_expr*, gfc_expr*)
../../gcc/fortran/dependency.c:462
0x7ac7a6 realloc_string_callback
../../gcc/fortran/frontend-passes.c:182
0x7af779 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:3376
0x7b08c2 realloc_strings
../../gcc/fortran/frontend-passes.c:1015
0x6eb38a gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15707
0x6d668a resolve_all_program_units
../../gcc/fortran/parse.c:5853
0x6d668a gfc_parse_file()
../../gcc/fortran/parse.c:6105
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug c++/58796] throw nullptr not caught by catch(type*)

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
(In reply to Jason Merrill from comment #12)
> For a pointer to member function that's still problematic because the
> exception object for 'throw nullptr' is currently one word, and a pointer to
> member function is two.  So I suppose we will need to allocate two words for
> 'throw nullptr'.  But clang doesn't do that; do they actually handle
> catching nullptr as a pointer to member function?

But then again, testing whether a PMF is null only checks the first word on
non-ARM targets, so we can probably get away with still only allocating the one
word and setting it to NULL.  ARM will probably need to allocate two words.

[Bug fortran/71807] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #3 from vehre at gcc dot gnu.org ---
Patch available at

https://gcc.gnu.org/ml/fortran/2016-07/msg00065.html

Waiting for review.

[Bug target/71869] __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.

[murphyp at linux dot vnet.ibm.com]

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

--- Comment #1 from Paul E. Murphy  ---
__builtin_isfinite also has a similar issue.

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-14
 CC||marxin at gcc dot gnu.org
Summary|ICE on valid code at -O3|[4.9/6/7 Regression] ICE on
   |with -g enabled on  |valid code at -O3 with -g
   |x86_64-linux-gnu: cannot|enabled on
   |update SSA form |x86_64-linux-gnu: cannot
   ||update SSA form
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, GCC 5 branch looks fine, however 4.9 doesn't:

pr71881.c:4:5: internal compiler error: Segmentation fault
 int fn1 ()
 ^
0x9ad80f crash_signal
/home/marxin/BIG/Programming/gcc/gcc/toplev.c:337
0xb4d7a3 verify_use
/home/marxin/BIG/Programming/gcc/gcc/tree-ssa.c:803
0xb52357 verify_ssa(bool)
/home/marxin/BIG/Programming/gcc/gcc/tree-ssa.c:1058
0x900a0c execute_function_todo
/home/marxin/BIG/Programming/gcc/gcc/passes.c:1854
0x9012c4 do_per_function
/home/marxin/BIG/Programming/gcc/gcc/passes.c:1574
0x9012c4 execute_todo
/home/marxin/BIG/Programming/gcc/gcc/passes.c:1887

[Bug c++/71882] New: elaborated-type-specifier friend not looked up in unnamed namespace

[sbergman at redhat dot com]

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

Bug ID: 71882
   Summary: elaborated-type-specifier friend not looked up in
unnamed namespace
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with both GCC 6.1.1 and recent trunk, compiling

  namespace { struct S; }
  class C {
friend struct S;
static void f();
  };
  namespace { struct S { void f() { C::f(); } }; }

fails with

> $ g++ -c test.cc
> test.cc: In member function ‘void {anonymous}::S::f()’:
> test.cc:6:42: error: ‘static void C::f()’ is private within this context
>namespace { struct S { void f() { C::f(); } }; }
>   ^
> test.cc:4:17: note: declared private here
>  static void f();
>  ^

[Bug tree-optimization/71881] New: ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[su at cs dot ucdavis.edu]

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

Bug ID: 71881
   Summary: ICE on valid code at -O3 with -g enabled on
x86_64-linux-gnu: cannot update SSA form
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 with -g enabled on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 6.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160714 (experimental) [trunk revision 238331] (GCC) 
$ 
$ gcc-trunk -O3 -c small.c
$ gcc-trunk -O2 -g -c small.c
$ gcc-6.1 -O3 -g -c small.c
$ 
$ gcc-trunk -O3 -g -c small.c
small.c: In function ‘fn1’:
small.c:3:5: error: statement uses released SSA name:
 int fn1 ()
 ^~~
# DEBUG i => i_29 + 1
The use of i_29 should have been replaced
small.c:3:5: internal compiler error: cannot update SSA form
0xc6090e update_ssa(unsigned int)
../../gcc-source-trunk/gcc/tree-into-ssa.c:3203
0xd35e5c rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:623
0xc670ff execute
../../gcc-source-trunk/gcc/tree-loop-distribution.c:1838
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.
$ 


---


int a, b, c, d, *e, f, g;

int fn1 ()
{
  char h[2];
  int i = 0;
  for (; i < 2; i++)
{
  if (c)
for (*e = 0; *e;)
  {
int j[f];
i = *e;
  }
  h[i] = 0;
}
  for (; a;)
return h[0];
  for (b = 0; b;)
i = g = (1 & i) < d;
  return 0;
}

[Bug driver/69028] ICE on *any* valid Cilk+ code C/C++: Invalid read of size 2 in cp_dump_tree(void*, tree_node*) (dump.c:318)

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 38904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38904=edit
Candidate patch for the profiling issue

Following cilk function has no location, if it's a valid that a function does
not have a location, then the patch should fix that.

[Bug driver/69028] ICE on *any* valid Cilk+ code C/C++: -fcilkplus is incompatible with -fprofile-arcs

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Ok, the problem comes from r224161:

Author: aldyh 
Date:   Fri Jun 5 18:44:53 2015 +

Merge debug-early branch into mainline.

where running:
./xg++ -B. ~/Programming/testcases/PR69028/pr69028.ii -fcilkplus
-fdump-tree-all -c

0x10da092 crash_signal
../../gcc/toplev.c:375
0x9ecaf5 cp_dump_tree(void*, tree_node*)
../../gcc/cp/dump.c:318
0x114488e dequeue_and_dump
../../gcc/tree-dump.c:427
0x114650e dump_node(tree_node const*, int, _IO_FILE*)
../../gcc/tree-dump.c:774
0x8e2f75 dump_tu
../../gcc/cp/decl2.c:4387
0x8e4024 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4819
0xac0899 c_common_parse_file()
../../gcc/c-family/c-opts.c:1091

it's:
==21456== Invalid read of size 2

[Bug c++/63875] Bogus unused-but-set-parameter warning when expanding a variadic template argument pack

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||7.0
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
Confirmed as fixed along with bug 66543 by r235221:

commit a4735361ea12ff1c5cac8ac66e08d0e775a7365f
Author: jason 
Date:   Tue Apr 19 19:30:22 2016 +

PR c++/66543 - -Wunused-but-set* false positives

* expr.c (mark_exp_read): Handle NON_DEPENDENT_EXPR.
* pt.c (make_pack_expansion): Call mark_exp_read.
* semantics.c (finish_id_expression): Call mark_type_use in
unevaluated context.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@235221
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #9 from vehre at gcc dot gnu.org ---
Patch available at:

https://gcc.gnu.org/ml/fortran/2016-07/msg00063.html

Waiting for review.

[Bug middle-end/50060] intrinsics not folded by the middle-end

[pbristow at hetp dot u-net.com]

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

Paul A. Bristow  changed:

   What|Removed |Added

 CC||pbristow at hetp dot u-net.com

--- Comment #6 from Paul A. Bristow  ---
This is a serious 'fault' that prevents making constexpr and functions that use
frexp, even though the mantissa and exponent are definitely constant.

This prevents using constexpr in Boost.Math functions and distributions,
Boost.Multiprecision and Proposed Boost.Fixed-Point.

Suggestions on workaround(s)?

Two separate constexpr functions for mantissa and exponent?

One function that 'returns' both as a tuple/pair?

Either are a major nuisance to replace frexp.

(Perhaps a single function to 'return' both doesn't such a good idea now?)

[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Will change.
While:
/* PR tree-optimization/71872 */

struct __attribute__((may_alias)) S { int *a; };
int b;

void
foo (int *x, struct S *y)
{
  int i;
  for (i = 0; i < 16; i++)
{
  int *a = 
  if (*x)
*(struct S *) y = *(struct S *) 
}
}
doesn't ICE, it has:
  *y_7(D) = VIEW_CONVERT_EXPR();
in the IL.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[ktkachov at gcc dot gnu.org]

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

Bug 65951 Summary: [AArch64] Will not vectorize 64bit integer multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951

   What|Removed |Added

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

[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64

[ktkachov at gcc dot gnu.org]

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

Bug 65951 Summary: [AArch64] Will not vectorize 64bit integer multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951

   What|Removed |Added

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

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[ramana.radhakrishnan at foss dot arm.com]

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

--- Comment #8 from ramana.radhakrishnan at foss dot arm.com ---
On 14/07/16 12:15, aurelien at aurel32 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833
> 
> --- Comment #7 from Aurelien Jarno  ---
> (In reply to Ramana Radhakrishnan from comment #6)
>> (In reply to Aurelien Jarno from comment #5)
>>> (In reply to Ramana Radhakrishnan from comment #4)
 Need to apply Aurelien's patch - looks like that's slipped through the
 cracks.
>>>
>>> What was missing to the patch was a testcase which compiles on all platform.
>>> This has happened recently, as part of the testcase for PR61441. I therefore
>>> guess this patch can now be applied.
>>
>> Do you mind pinging it after another round of testing ? 
>>
> 
> I have just done a another round on testing on trunk:
> - The patch is still necessary.
> - The patch still applies, but with fuzz. I'll resend an update patch.
> - The patch still works as expected.
> - The testcase for PR61441 does not seems to work for this bug as it is
> compiled with -O1. GCC 6 does constant propagation and the resulting binary do
> not call aeabi_f2d. With GCC 5 or with -O0 the testcase also work for his bug.
> Is there a way to specify that a test should run with both -O0 and -O1? That
> would avoid writing an almost identical testcase.

An option might be to move the test into gcc.c-torture/execute and then it will
torture over all optimization levels and add the option needed with
dg-additional-options ?

Ramana

> 
> Aurelien
>

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Should be fixed now.

[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Implemented for GCC 7

[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On July 14, 2016 2:33:12 PM GMT+02:00, "jakub at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872
>
>Jakub Jelinek  changed:
>
>   What|Removed |Added
>
> Status|NEW |ASSIGNED
>  Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
>
>--- Comment #5 from Jakub Jelinek  ---
>Created attachment 38903
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38903=edit
>gcc7-pr71872.patch
>
>Untested fix.

Is_gimple_min_invariant?

[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to vehre from comment #7)
> Hi Karl,
> 
> (In reply to kargl from comment #5)
> > With the patch I posted earlier today and code in comment #1, I see
> 
> which patch are you referring to? At least upto now I don't see a patch from
> you on the list or in this PR. 
> 

See PR 71862

[Bug tree-optimization/70923] [7 regression] gcc.dg/vect/pr60092.c etc. FAIL

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jul 14 14:32:39 2016
New Revision: 238340

URL: https://gcc.gnu.org/viewcvs?rev=238340=gcc=rev
Log:
[vectorizer][2/2] Hook up mult synthesis logic into vectorisation of
mult-by-constant

PR target/65951
PR tree-optimization/70923
* tree-vect-patterns.c: Include mult-synthesis.h.
(target_supports_mult_synth_alg): New function.
(synth_lshift_by_additions): Likewise.
(apply_binop_and_append_stmt): Likewise.
(vect_synth_mult_by_constant): Likewise.
(target_has_vecop_for_code): Likewise.
(vect_recog_mult_pattern): Use above functions to synthesize vector
multiplication by integer constants.

* gcc.dg/vect/vect-mult-const-pattern-1.c: New test.
* gcc.dg/vect/vect-mult-const-pattern-2.c: Likewise.
* gcc.dg/vect/pr65951.c: Likewise.
* gcc.dg/vect/vect-iv-9.c: Remove ! vect_int_mult-specific scan.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65951.c
trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-iv-9.c
trunk/gcc/tree-vect-patterns.c

[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jul 14 14:32:39 2016
New Revision: 238340

URL: https://gcc.gnu.org/viewcvs?rev=238340=gcc=rev
Log:
[vectorizer][2/2] Hook up mult synthesis logic into vectorisation of
mult-by-constant

PR target/65951
PR tree-optimization/70923
* tree-vect-patterns.c: Include mult-synthesis.h.
(target_supports_mult_synth_alg): New function.
(synth_lshift_by_additions): Likewise.
(apply_binop_and_append_stmt): Likewise.
(vect_synth_mult_by_constant): Likewise.
(target_has_vecop_for_code): Likewise.
(vect_recog_mult_pattern): Use above functions to synthesize vector
multiplication by integer constants.

* gcc.dg/vect/vect-mult-const-pattern-1.c: New test.
* gcc.dg/vect/vect-mult-const-pattern-2.c: Likewise.
* gcc.dg/vect/pr65951.c: Likewise.
* gcc.dg/vect/vect-iv-9.c: Remove ! vect_int_mult-specific scan.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr65951.c
trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-mult-const-pattern-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-iv-9.c
trunk/gcc/tree-vect-patterns.c

[Bug c++/58796] throw nullptr not caught by catch(type*)

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
Also note that a null pointer to data member is represented as -1, not 0, so
you'll want

  *(ptrdiff_t*)thrown_ptr = -1;

for that case.

A null pointer to member function is { nullptr, 0 }.

You might also handle this in __pbase_type_info::__do_catch rather than
get_adjusted_ptr.

[Bug c++/58796] throw nullptr not caught by catch(type*)

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #12)
> (In reply to Jonathan Wakely from comment #4)
> > However with that patch the caught pointer is not null, so it's not right.
> 
> For a pointer, you just need to set thrown_ptr to null.

Oh, well that's easier than I thought!

> For a pointer to member it's trickier, since they are thrown by reference,
> and we end up returning a pointer to the exception object.  I suppose that
> since nullptr has no actual value we can feel free to clobber the "value" of
> the exception object before returning.
> 
> For a pointer to member function that's still problematic because the
> exception object for 'throw nullptr' is currently one word, and a pointer to
> member function is two.  So I suppose we will need to allocate two words for
> 'throw nullptr'.  But clang doesn't do that; do they actually handle
> catching nullptr as a pointer to member function?

I don't know, when I test with clang it uses libstdc++.so, so the nullptr
doesn't get caught.

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #5)
> Perhaps ECF_MAY_BE_ALLOCA too?  But ECF_NORETURN and ECF_LEAF are not
> conservative, sure.

Yes. That's right.
alloca can not return null.
See tree_expr_nonzero_warnv_p.

Test case:

void *alloca(void);

void bar(void)
{
  char * x = alloca();
  if (x) 
*x = 0;
}

gcc -Wall -O3 -S -ffreestanding test.c

result: if(x) is optimized away:

bar:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
callalloca
movb$0, (%rax)
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

[Bug c++/58796] throw nullptr not caught by catch(type*)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #12 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #4)
> However with that patch the caught pointer is not null, so it's not right.

For a pointer, you just need to set thrown_ptr to null.

For a pointer to member it's trickier, since they are thrown by reference, and
we end up returning a pointer to the exception object.  I suppose that since
nullptr has no actual value we can feel free to clobber the "value" of the
exception object before returning.

For a pointer to member function that's still problematic because the exception
object for 'throw nullptr' is currently one word, and a pointer to member
function is two.  So I suppose we will need to allocate two words for 'throw
nullptr'.  But clang doesn't do that; do they actually handle catching nullptr
as a pointer to member function?

[Bug fortran/71880] pointer to allocatable character

[valeryweber at hotmail dot com]

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

--- Comment #1 from Valery Weber  ---
what about this one?

cat gcc-6.1b.f90
program t
character(:), dimension(:), allocatable, target :: c
character(:), dimension(:), pointer :: p
allocate(c(10),source='X')
p=>c(:)
write(*,*) 'p=<',p(1),'> c=<',c(1),'>',len(p(1))
end program t


gfortran-6.1.0 gcc-6.1b.f90 
./a.out 
p= c=   32674

[Bug go/71396] "use of undefined type" error in gccgo-6 when go (1.6.1) is perfectly happy

[thanm at google dot com]

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

Than McIntosh  changed:

   What|Removed |Added

 CC||thanm at google dot com

--- Comment #1 from Than McIntosh  ---
Hello,
I was unable to access the attachment (just got a single line of text). Could
you please repost?
Thanks, Than

[Bug fortran/71880] New: pointer to allocatable character

[valeryweber at hotmail dot com]

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

Bug ID: 71880
   Summary: pointer to allocatable character
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
  Target Milestone: ---

Hi All
is that a compiler bug?
many thanks
v

cat gcc-6.1.f90 
program t
character(:), dimension(:), allocatable, target :: c
character(:), dimension(:), pointer :: p
allocate(c(10),source='X')
p=>c
write(*,*) 'p=<',p(1),'> c=<',c(1),'>',len(p(1))
end program t

gfortran-6.1.0 gcc-6.1.f90 
./a.out 
 p=<> c=   0

gfortran-trunk gcc-6.1.f90 
./a.out 
 p=<> c=   0

[Bug c++/71879] Error in unevaluated context breaks SFINAE

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Taking the address of Foo::foo instantiates it, which results in an
error outside the immediate context, so you get an error not a substitution
failure.

http://stackoverflow.com/a/15261234/981959

[Bug c++/71879] New: Error in unevaluated context breaks SFINAE

[manuel.schil...@bmw-carit.de]

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

Bug ID: 71879
   Summary: Error in unevaluated context breaks SFINAE
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.schil...@bmw-carit.de
  Target Milestone: ---

Having asked at Stackoverflow I was told the following might be a bug in GCC:



When comparing member function pointers in an SFINAE context, member function
Foo::foo() exists, but its body contains code (x.hello()) which eventually does
not compile.

The following code compiles with clang. GCC however seems to evaluate the
function body of Foo::foo() and exits with an error ('struct Caller' has no
member named 'hello'), despite being in an unevaluated SFINAE context.


///
#include 
#include 

struct Foo
{
template  void foo(T&& x) { x.hello();}
};

struct Caller
{
template 
auto call(T&& x, int) -> decltype(
std::enable_if_t<
std::is_same<
decltype(::template foo),
void (T::*)(decltype(*this))
>::value
>())
{
//x.foo(*this);
}

template 
void call(T&&, char){ std::cout << "hello" << std::endl;}
};

int main()
{
  Caller c;
  c.call(Foo(), 0);
}
///

Error message:

main.cpp: In instantiation of 'void Foo::foo(T&&) [with T = Caller&]':

main.cpp:14:14:   required by substitution of 'template decltype
(std::enable_if_t::value>()) Caller::call(T&&, int) [with T = Foo]'

main.cpp:31:18:   required from here

main.cpp:6:47: error: 'struct Caller' has no member named 'hello'

 template  void foo(T&& x) { x.hello(); }

 ~~^
--
version: g++ 6.1.0
flags: g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp

--
Link to code on coliru: http://coliru.stacked-crooked.com/a/a984ad1ca2edcb0c

Link to stackoverflow: http://stackoverflow.com/q/38371924/678093

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[dave.anglin at bell dot net]

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

--- Comment #19 from dave.anglin at bell dot net ---
On 2016-07-12 10:38 AM, danglin at gcc dot gnu.org wrote:
> Patch looks reasonable but needs to be sent to gcc-patches with cc's.
Further, the patch needs to be submitted by someone with a gcc copyright 
assignment.

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[vz-gcc at zeitlins dot org]

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

--- Comment #2 from Vadim Zeitlin  ---
I'll try to add the preprocessed code a bit later, but, FWIW, I can already say
that there is no macro trickery whatsoever in this code itself.

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Perhaps ECF_MAY_BE_ALLOCA too?  But ECF_NORETURN and ECF_LEAF are not
conservative, sure.

[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 38903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38903=edit
gcc7-pr71872.patch

Untested fix.

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
And, what is "qsetjmp" ?

Also "setjmp_syscall", "savectx" are also completely new to me.

And why is the prefix "__x" discarded?

[Bug target/71652] [4.9/5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Jan Hubicka  ---
The patch looks fine to me. i would not drop the gcc_unreachable and instead
just arrange the -march to be set to some other reasonable value at the time
error is produced.

For all the suggestions, i think answer is yes.

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-14
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Yes, only ECF_RETURNS_TWICE is conservative.

[Bug tree-optimization/71866] [7 Regression] gcc locks up after fix for PR70159

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/71878] ICE in cselib_record_set

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Target||arm-none-eabi
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org
   Target Milestone|--- |5.5
Summary|ICE in  |ICE in cselib_record_set
  Known to fail||5.4.1

--- Comment #2 from Thomas Preud'homme  ---
Hi,

The attached testcase (extracted from gcc.dg/vect/slp-perm-5) ICEs on GCC 5 +
backport of r227382 on arm-none-eabi when compiled with -mcpu=cortex-a8 -marm
-mfpu=neon -mfloat-abi=softfp -ftree-vectorize -O2 and gives the following
stacktrace:

/home/thopre01/issues/sjp/slp-perm-5.c: In function ‘foo’:
/home/thopre01/issues/sjp/slp-perm-5.c:44:1: internal compiler error: in
cselib_record_set, at cselib.c:2396
 }
 ^
0x653c37 cselib_record_set
/data/dev/repos/internal/gcc/gcc/cselib.c:2396
0x653c37 cselib_record_sets
/data/dev/repos/internal/gcc/gcc/cselib.c:2613
0x654237 cselib_process_insn(rtx_insn*)
/data/dev/repos/internal/gcc/gcc/cselib.c:2686
0x89e547 reload_cse_regs_1
/data/dev/repos/internal/gcc/gcc/postreload.c:248
0x89fcab reload_cse_regs
/data/dev/repos/internal/gcc/gcc/postreload.c:94
0x89fcab execute
/data/dev/repos/internal/gcc/gcc/postreload.c:2387


This is due to LRA allocating the same hard register to the two destinations
registers of neon_vtrn_insn pattern (in config/arm/neon.md).

GCC was configured with --target=arm-none-eabi only.

LRA produces the following insn:

(insn 77 61 154 2 (parallel [
(set (reg:V4SI 52 d18 [188])
(unspec:V4SI [
(reg:V4SI 52 d18 [188])
(reg:V4SI 52 d18 [188])
] UNSPEC_VTRN1))
(set (reg:V4SI 52 d18 [188])
(unspec:V4SI [
(reg:V4SI 52 d18 [188])
(reg:V4SI 52 d18 [188])
] UNSPEC_VTRN2))
]) pr71878.c:41 1940 {*neon_vtrnv4si_insn}
 (nil))

This causes cselib to fail when processing the second SET of that parallel in
cselib_record_set () because of the assert gcc_assert (REG_VALUES (dreg)->elt
== 0) since the field was already set when processing the first SET.

[Bug rtl-optimization/71878] ICE in

[thopre01 at gcc dot gnu.org]

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

--- Comment #1 from Thomas Preud'homme  ---
Created attachment 38902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38902=edit
Testcase allowing to reproduce ICE in cselib

[Bug c/71876] longjmp is miscompiled with -ffreestanding

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
test case for the ECF_LEAF:

test.c:

int setjmp(void);
static int x;

void foo(int z)
{
 x = z;
}

int bar(void)
{
  int z = x;
  setjmp();
  z += x;
  return z;
}


gcc -O3 -S -ffreestanding test.c

bar:
.LFB1:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movlx(%rip), %eax
movl%eax, 12(%rsp)
callsetjmp
movl12(%rsp), %eax
addq$24, %rsp
.cfi_def_cfa_offset 8
addl%eax, %eax
ret
.cfi_endproc


but the free-standing setjmp function could call back to foo.

[Bug tree-optimization/71866] [7 Regression] gcc locks up after fix for PR70159

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 14 12:15:38 2016
New Revision: 238334

URL: https://gcc.gnu.org/viewcvs?rev=238334=gcc=rev
Log:
2016-07-14  Richard Biener  

PR tree-optimization/71866
* tree-ssa-pre.c (get_constant_for_value_id): Remove.
(do_hoist_insertion): Avoid endless recursion when we
didn't insert anything because we managed to simplify
things down to a constant or SSA name.
(fully_constant_expression): Re-write in terms of ...
* tree-ssa-sccvn.h (vn_nary_simplify): ... this.  Declare.
* tree-ssa-sccvn.c (vn_nary_simplify): New wrapper around
vn_nary_build_or_lookup_1.
(vn_nary_build_or_lookup_1): Added flag and renamed from ...
(vn_nary_build_or_lookup): ... this which now wraps it.

* gcc.dg/torture/pr71866.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71866.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug rtl-optimization/71878] New: ICE in

[thopre01 at gcc dot gnu.org]

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

Bug ID: 71878
   Summary: ICE in
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---

[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|ICE in inchash::add_expr,   |[7 Regression] ICE in
   |at tree.c:7782 -|inchash::add_expr, at
   |OEP_ADDRESS_OF asserted for |tree.c:7782 -
   |ADDR_EXPR applied to|OEP_ADDRESS_OF asserted for
   |constant|ADDR_EXPR applied to
   ||constant

[Bug tree-optimization/71872] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase:

struct __attribute__((may_alias)) S { int a; };

void
foo (int *x, struct S *y)
{
  int i;
  for (i = 0; i < 16; i++)
{
  int a = 0;
  if (*x)
*(struct S *) y = *(struct S *) 
}
}

[Bug libgomp/71877] -fdump-tree-ompexp is generating incomplete code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-14
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I don't see what you find incomplete on the 6.1 output.  In 5.x, you indeed
should look at -fdump-tree-ssa dump instead if you want to see the IL for the
*.omp_fn* functions, but GCC 6 does dump them even in *.ompexp.

[Bug libgomp/71877] New: -fdump-tree-ompexp is generating incomplete code

[rogerio.rag at gmail dot com]

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

Bug ID: 71877
   Summary: -fdump-tree-ompexp is generating incomplete code
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogerio.rag at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38901=edit
Generate output files.

Hello,

I have a problem using the gcc + libgomp.

I'm trying to get the expanded code format for openmp directives.
Specifically for loops with schedule types (unespecified, static, auto,
dynamic, guided and runtime).

I'm using the options -fdump-tree-ompexp and -fdump-tree-ompexp-graph.

gcc-4.8 -fopenmp -fdump-tree-ompexp for-schedule-dynamic-upper-bound-value.c
gcc-4.8 -fopenmp -fdump-tree-ompexp-graph
for-schedule-dynamic-upper-bound-value.c
dot -Tpng for-schedule-dynamic-upper-bound-value.c.015t.ompexp.dot >
for-schedule-dynamic-upper-bound-value.c.015t.ompexp.png

The generated output files are in attach.

I'm testing with gcc-4.9, gcc-5.3 and gcc-6.1.
The result likes incomplete. The name of file is modified to *.c.012t.ompexp
and it have no complete code according this doc
https://gcc.gnu.org/onlinedocs/libgomp/Implementing-FOR-construct.html#Implementing-FOR-construct

Something was changed in this option after gcc-4.8?

[Bug c/71876] longjmp is miscompiled with -ffreestanding

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
I'm unsure, if ECF_LEAF is also unsafe:

/* The function does not lead to calls within current function unit.  */
#define ECF_LEAF  (1 << 10)

I couldn't guarantee for that in a freestanding environmnent.

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[bernd.edlinger at hotmail dot de]

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

--- Comment #18 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #17)
> Can you open a separate bug please?

sure: pr71876

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #7 from Aurelien Jarno  ---
(In reply to Ramana Radhakrishnan from comment #6)
> (In reply to Aurelien Jarno from comment #5)
> > (In reply to Ramana Radhakrishnan from comment #4)
> > > Need to apply Aurelien's patch - looks like that's slipped through the
> > > cracks.
> > 
> > What was missing to the patch was a testcase which compiles on all platform.
> > This has happened recently, as part of the testcase for PR61441. I therefore
> > guess this patch can now be applied.
> 
> Do you mind pinging it after another round of testing ? 
> 

I have just done a another round on testing on trunk:
- The patch is still necessary.
- The patch still applies, but with fuzz. I'll resend an update patch.
- The patch still works as expected.
- The testcase for PR61441 does not seems to work for this bug as it is
compiled with -O1. GCC 6 does constant propagation and the resulting binary do
not call aeabi_f2d. With GCC 5 or with -O0 the testcase also work for his bug.
Is there a way to specify that a test should run with both -O0 and -O1? That
would avoid writing an almost identical testcase.

Aurelien

[Bug c/71876] New: longjmp is miscompiled with -ffreestanding

[bernd.edlinger at hotmail dot de]

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

Bug ID: 71876
   Summary: longjmp is miscompiled with -ffreestanding
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Even with -ffreestanding we handle some functions conservatively.
See special_function_p.

However, the function longjmp and siglongjmp are not handled conservatively
as the following test case illustrates:

cat test.c
int longjmp(void);

int bar(void)
{
  return longjmp();
}

gcc -Wall -ffreestanding -O3 -S test.c

emits no warning, but resulting code is invalid (no ret):

bar:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
calllongjmp
.cfi_endproc

[Bug c++/71871] ICE on mixing templates and vector extensions ternary operator

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 38900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38900=edit
gcc7-pr71871.patch

Untested fix.

[Bug c++/71875] [5 Regression] template specialization compile error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[6 Regression] template |[5 Regression] template
   |specialization compile  |specialization compile
   |error   |error

--- Comment #3 from Martin Liška  ---
(In reply to Martin Liška from comment #2)
>   5-base (905be4e64f0f9136b06cbfb1e006e8eec1de0b4b): OK
>   6-base (a050099a416f013bda35832b878d9a57b0cbb231): FAILED
> /tmp/cci9uL6d.s: Assembler messages:
> /tmp/cci9uL6d.s:27: Error: symbol `_ZL8IsMatrix' is already defined

Sorry, there are commits where the branches were branched.

  5 (c8db82c76d5f97641bf344c0244323e64b4f5cea): FAILED
/tmp/cc4E7vAF.s: Assembler messages:
/tmp/cc4E7vAF.s:27: Error: symbol `_ZL8IsMatrix' is already defined
  6 (c3f09c3a4a94fd23b245fde516dc5d7188f3a13e): OK

[Bug c++/71875] [6 Regression] template specialization compile error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |6.2
Summary|[5/6 Regression] template   |[6 Regression] template
   |specialization compile  |specialization compile
   |error   |error

--- Comment #2 from Martin Liška  ---
  5-base (905be4e64f0f9136b06cbfb1e006e8eec1de0b4b): OK
  6-base (a050099a416f013bda35832b878d9a57b0cbb231): FAILED
/tmp/cci9uL6d.s: Assembler messages:
/tmp/cci9uL6d.s:27: Error: symbol `_ZL8IsMatrix' is already defined

[Bug c++/63875] Bogus unused-but-set-parameter warning when expanding a variadic template argument pack

[roman.perepelitsa at gmail dot com]

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

Roman Perepelitsa  changed:

   What|Removed |Added

 CC||roman.perepelitsa at gmail dot 
com

--- Comment #3 from Roman Perepelitsa  ---
This appears to be fixed in gcc 6.1: the provided snippet compiles cleanly.

[Bug c++/71875] [5/6 Regression] template specialization compile error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, it was fixed on trunk by r236946:

commit 4a2d1b33a26657aeddb839adf306e29123526452
Author: jason 
Date:   Tue May 31 19:49:16 2016 +

PR c++/60095 - partial specialization of variable templates

PR c++/69515
PR c++/69009
* pt.c (instantiate_template_1): Don't put the partial
specialization in DECL_TI_TEMPLATE.
(partial_specialization_p, impartial_args): Remove.
(regenerate_decl_from_template): Add args parm.
(instantiate_decl): Look up the partial specialization again.

I'm going to verify the behavior of HEADs of 5 and 6 branches.

[Bug c++/71875] [5/6 Regression] template specialization compile error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-14
  Known to work||5.3.0, 7.0
Summary|template specialization |[5/6 Regression] template
   |compile error   |specialization compile
   ||error
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.1.0
   Severity|critical|normal

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On Thu, 14 Jul 2016, bernd.edlinger at hotmail dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
> 
> --- Comment #16 from Bernd Edlinger  ---
> (In reply to rguent...@suse.de from comment #15)
> > On Thu, 14 Jul 2016, bernd.edlinger at hotmail dot de wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
> > > 
> > > --- Comment #14 from Bernd Edlinger  ---
> > > One question though...
> > > 
> > > This depends on a special knowledge about "vfork",
> > > but it seems that gcc does not honor -ffreestanding
> > > correctly in this case, because:
> > > 
> > > gcc -ffreestanding pr71104-1.c
> > > 
> > > should not have crashed (before your patch, but it did).
> > 
> > Even with -ffreestanding we handle some functions conservatively.
> > See special_function_p.
> 
> Oh, I see.
> Handling vfork that may be conservative, but longjmp is not conservative.

Yeah, returning ECF_NORETURN isn't conservative.  OTOH this code
only looking at the name of the function rather than using the
corresponding builtin pre-dates my GCC involvement.

Can you open a separate bug please?

> 
> test.c:
> 
> void foo(void);
> int longjmp(void);
> int *p;
> 
> void bar(void)
> {
>   foo();
>   *p = longjmp();
> }
> 
> gcc -Wall -S -O3 -ffreestanding test.c
> gives zero warning, and invalid code:
> 
> bar:
> .LFB0:
> .cfi_startproc
> subq$8, %rsp
> .cfi_def_cfa_offset 16
> callfoo
> calllongjmp
> .cfi_endproc
> 
>

[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Done.

[Bug libstdc++/70716] Doxygen comments on std containers need updating for C++11 allocators

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Jul 14 10:02:10 2016
New Revision: 238332

URL: https://gcc.gnu.org/viewcvs?rev=238332=gcc=rev
Log:
Improve doxygen comments for allocators in containers

PR libstdc++/70716
* include/bits/forward_list.h (forward_list): Update doxygen comments
to reflect allocator propagation semantics. Remove ambiguous
statements about data being lost.
* include/bits/stl_deque.h (deque): Likewise.
* include/bits/stl_list.h (list): Likewise.
* include/bits/stl_map.h (map): Likewise.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_vector.h (vector): Likewise.
* include/bits/unordered_map.h (unordered_map, unordered_multimap):
Likewise.
* include/bits/unordered_set.h (unordered_set, unordered_multiset):
Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/forward_list.h
trunk/libstdc++-v3/include/bits/stl_deque.h
trunk/libstdc++-v3/include/bits/stl_list.h
trunk/libstdc++-v3/include/bits/stl_map.h
trunk/libstdc++-v3/include/bits/stl_multimap.h
trunk/libstdc++-v3/include/bits/stl_multiset.h
trunk/libstdc++-v3/include/bits/stl_set.h
trunk/libstdc++-v3/include/bits/stl_vector.h
trunk/libstdc++-v3/include/bits/unordered_map.h
trunk/libstdc++-v3/include/bits/unordered_set.h