[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[fxcoudert at gcc dot gnu.org]

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

--- Comment #5 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Tue Aug  4 07:27:19 2015
New Revision: 226548

URL: https://gcc.gnu.org/viewcvs?rev=226548&root=gcc&view=rev
Log:
PR fortran/64022

* simplify.c (gfc_simplify_ieee_selected_real_kind): Extend IEEE
support to all real kinds.

* ieee/ieee_exceptions.F90: Support all real kinds.
* ieee/ieee_arithmetic.F90: Likewise.
* ieee/ieee_helper.c (ieee_class_helper_10,
ieee_class_helper_16): New functions
* gfortran.map (GFORTRAN_1.7): Add entries.

* gfortran.dg/ieee/ieee_7.f90: Adjust test.
* gfortran.dg/ieee/large_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/ieee/large_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_7.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
trunk/libgfortran/ieee/ieee_arithmetic.F90
trunk/libgfortran/ieee/ieee_exceptions.F90
trunk/libgfortran/ieee/ieee_helper.c

[Bug lto/66784] no symbol emitted for builtin with lto

[guido.hatzsis at yandex dot com]

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

--- Comment #2 from Guido Haztsis  ---
Well I believe that the is_builtin_fn cometh from here:

+2488 gcc/lto-streamer-out.c 
   if (!TREE_PUBLIC (t)
   || is_builtin_fn (t)
   || DECL_ABSTRACT_P (t)
   || (TREE_CODE (t) == VAR_DECL && DECL_HARD_REGISTER (t)))

[Bug lto/67111] New: ld -plugin segmentation fault

[dilyan.palauzov at aegee dot org]

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

Bug ID: 67111
   Summary: ld -plugin segmentation fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

I have the newest gcc (g207b8288) and binutils (gedc66de).

binutils is configured with "/git/binutils-gdb/configure
--target=armv6kz-hardfloat-linux-gnueabi --with-sysroot=/raspberryOS/
--with-system-readline --enable-gold --with-system-zlib --with-mmap
--with-python=python3"

gcc is configured with "/git/gcc/configure --enable-host-shared
--enable-threads=posix --enable-languages=c,c++,jit,lto --enable-targets=all
--enable-nls --with-linker-hash-style=gnu --enable-interpreter
--enable-libgcj-multifile --with-system-zlib --with-mtune=arm1176jzf-s
--with-arch=armv6kz --target=armv6kz-hardfloat-linux-gnueabi --with-fpu=vfp
--with-float=hard --with-sysroot=/raspberryOS/"

I compile this programm  c.c

  int  main ()  {
return 0;
  }

with
$ ulimit -c unlimited
$ armv6kz-hardfloat-linux-gnueabi-gcc -pipe -O3 -flto -fno-fat-lto-objects 
-Wl,-O1,-z,relro,-s -flto=4
-Wl,-plugin,/usr/local/libexec/gcc/armv6kz-hardfloat-linux-gnueabi/6.0.0/liblto_plugin.so
c.c
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core
dumped
compilation terminated.

$ gdb armv6kz-hardfloat-linux-gnueabi-ld core 
warning: core file may not match specified executable file.
[New LWP 19330]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by
`/usr/local/lib/gcc/armv6kz-hardfloat-linux-gnueabi/6.0.0/../../../../armv6kz-ha'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  get_symbols (handle=, nsyms=, syms=, def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:667
667   if (syms[n].def != LDPK_UNDEF)



(gdb) bt f

#0  get_symbols (handle=, nsyms=, syms=, def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:667
blhe = 
owner_sec = 
res = 
input = 
abfd = 0x128adb0
n = 
#1  0x7fdad3f67448 in write_resolution () at
/git/gcc/lto-plugin/lto-plugin.c:476
info = 0x128cf50
symtab = 0x128cf60
syms = 
i = 0
f = 0x14d5970
#2  all_symbols_read_handler () at /git/gcc/lto-plugin/lto-plugin.c:643
i = 
num_lto_args = 
lto_argv = 0x14d57c0
lto_arg_ptr = 0x14d57c0
__PRETTY_FUNCTION__ = "all_symbols_read_handler"
#3  0x0041fe02 in plugin_call_all_symbols_read () at
/git/binutils-gdb/ld/plugin.c:1210
rv = 
curplug = 0x1249fd0
#4  0x004155df in lang_process () at /git/binutils-gdb/ld/ldlang.c:6646
added = {
  head = 0x1247210, 
  tail = 0x125ea00
}
files = {
  head = 0x125ea00, 
  tail = 0x124a160
}
inputfiles = {
  head = 0x1247210, 
  tail = 0x12d2d38
}
#5  0x004036c7 in main (argc=43, argv=0x7ffc8b525068) at
/git/binutils-gdb/ld/ldmain.c:419
emulation = 0x7ffc8b525fbf "armelf_linux_eabi"
start_time = 0
start_sbrk = 0x1246000 ""

[Bug c++/67104] [5/6 regression] Constant expression factory function initializes std::array with static storage duration strangely

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jason at gcc dot gnu.org
Summary|Constant expression factory |[5/6 regression] Constant
   |function initializes|expression factory function
   |std::array with static  |initializes std::array with
   |storage duration strangely  |static storage duration
   ||strangely

--- Comment #5 from Markus Trippelsdorf  ---
Started with r217663 (C++14 constexpr support).

[Bug libstdc++/67015] "^[a-z0-9][a-z0-9-]*$", std::regex::extended is miscompiled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug libstdc++/67015] "^[a-z0-9][a-z0-9-]*$", std::regex::extended is miscompiled

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
OK, let's backport to 4.9 too.

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Calcutt from comment #3)
> Are there technical reasons this is not desirable or possible beyond what
> you have already stated? Is the behavior of the priority queue here also
> outside of the intent of the standard?

Yes, using a reference type for the comparison object of std::priority_queue is
highly quesitonable. Use std::reference_wrapper if you want reference
semantics.

[Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #10 from Mikael Morin  ---
(In reply to Paul Thomas from comment #8)
> Created attachment 36113 [details]
> Patch for th 5 branch
> 
Doesn't look like a patch. :-/

[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.

[rguenther at suse dot de]

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

--- Comment #38 from rguenther at suse dot de  ---
On Mon, 3 Aug 2015, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> 
> --- Comment #37 from alalaw01 at gcc dot gnu.org ---
> Hmmm, no it's not the hashing - that pretty much ignores all types. It's the
> comparison in hashable_expr_equal_p, which just uses operand_equal_p,
> specifically this part (in fold-const.c):
> 
> case MEM_REF:
>   /* Require equal access sizes, and similar pointer types.
>  We can have incomplete types for array references of
>  variable-sized arrays from the Fortran frontend
>  though.  Also verify the types are compatible.  */
>   if (!((TYPE_SIZE (TREE_TYPE (arg0)) == TYPE_SIZE (TREE_TYPE (arg1))
>|| (TYPE_SIZE (TREE_TYPE (arg0))
>&& TYPE_SIZE (TREE_TYPE (arg1))
>&& operand_equal_p (TYPE_SIZE (TREE_TYPE (arg0)),
>TYPE_SIZE (TREE_TYPE (arg1)),
> flags)))
>   && types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1))
>   && ((flags & OEP_ADDRESS_OF)
>   || (alias_ptr_types_compatible_p
> (TREE_TYPE (TREE_OPERAND (arg0, 1)),
>  TREE_TYPE (TREE_OPERAND (arg1, 1)))
>   && (MR_DEPENDENCE_CLIQUE (arg0)
>   == MR_DEPENDENCE_CLIQUE (arg1))
>   && (MR_DEPENDENCE_BASE (arg0)
>   == MR_DEPENDENCE_BASE (arg1))
>   && (TYPE_ALIGN (TREE_TYPE (arg0))
> == TYPE_ALIGN (TREE_TYPE (arg1)))
> 
> specifically, a pointer to int, and a pointer to an array of int, are not
> alias_ptr_types_compatible_p. (I'm not clear that they should be, either!?)

As said neither the hashing nor operand_equal_p are perfect fits for
the constraints on equality DOM needs to put on memory references.

[Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram

[paul.richard.thomas at gmail dot com]

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

--- Comment #11 from paul.richard.thomas at gmail dot com  ---
Hi Mikael,

It looks like my finger slipped on the mouse wheel - I'll put it right tonight.

Thanks

Paul

On 4 August 2015 at 11:27, mikael at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
>
> Mikael Morin  changed:
>
>What|Removed |Added
> 
>  CC||mikael at gcc dot gnu.org
>
> --- Comment #10 from Mikael Morin  ---
> (In reply to Paul Thomas from comment #8)
>> Created attachment 36113 [details]
>> Patch for th 5 branch
>>
> Doesn't look like a patch. :-/
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug c++/66604] ICE in use_thunk at cp/method.c:338 when creating a default virtual destructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.8.3, 4.9.0, 5.0
 Resolution|--- |FIXED

--- Comment #3 from Paolo Carlini  ---
Closing.

[Bug c++/66602] std::tuple bug when constructed with temporary empty object

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Closing then.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #7 from Mikael Morin  ---
(In reply to Francois-Xavier Coudert from comment #6)
> I tracked the issue to the two calls to wi::from_mpz() and
> wide_int_to_tree() in gcc/fortran/trans-const.c:gfc_conv_mpz_to_tree().
> There the mpz value (which is correct) in translated into:
> 
>   wide_int_storage = {
> val = ([0] = -2, [1] = 0, [2] = 56)
> len = 1
> precision = 128
>   }
> 
> which appears to be where the -2 comes from.

And in wi::from_mpz it probably comes from the mpz_sizeinbytes and mpz_export
functions not paying attention to the sign, as stated in the documentation:

https://gmplib.org/manual/Integer-Import-and-Export.html
> The sign of op is ignored, just the absolute value is exported. An application
> can use mpz_sgn to get the sign and handle it as desired. (see Integer
> Comparisons) 

https://gmplib.org/manual/Miscellaneous-Integer-Functions.html#Miscellaneous-Integer-Functions
> The sign of op is ignored, just the absolute value is used.

[Bug libstdc++/67112] New: [MinGW64] build failure due to name conflict with system headers

[sliwa at ifpan dot edu.pl]

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

Bug ID: 67112
   Summary: [MinGW64] build failure due to name conflict with
system headers
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sliwa at ifpan dot edu.pl
  Target Milestone: ---

Created attachment 36118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36118&action=edit
proposed path

libstdc++ fails to build on MinGW64 due to a name conflict:

* the macro "C" is #defined to the character type for which classes templates
are being instantiated

* the name "C" is used as the name of a field in a struct in winnt.h (a MinGW
system header file)

The attached patch changes the name of the parameter macro to "CHARC".

[Bug c++/67113] New: unintelligent error message "only declarations of constructors can be 'explicit'" in cpp file's constructor define.

[robinh3123 at gmail dot com]

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

Bug ID: 67113
   Summary: unintelligent error message "only declarations of
constructors can be 'explicit'" in cpp file's
constructor define.
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robinh3123 at gmail dot com
  Target Milestone: ---

For the following codes (in 3 files):

$ cat a.cpp
#include "a.h"

int A::f()
{
return n+1;
}

explicit A::A(int _n)   // <=== error at this line
{
n = _n;
}



$ cat  a.h
class A
{
public:
int n;
int f();
explicit A(int _n);
};



$ cat main.cpp
#include 
#include "a.h"  // for class A

using namespace std;

int main()
{
A a(5);
int i = a.f();
cout << i << endl;
return 0;
}


The compiler reports error message:
a.cpp:8:21: error: only declarations of constructors can be 'explicit'
 explicit A::A(int _n)

This is misleading, since A::A is really a constructor.
The error message should be something similar to:
 extra explicit before function A::A

[Bug libstdc++/67114] New: [MinGW64] build failure with POSIX threads enabled

[sliwa at ifpan dot edu.pl]

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

Bug ID: 67114
   Summary: [MinGW64] build failure with POSIX threads enabled
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sliwa at ifpan dot edu.pl
  Target Milestone: ---

Created attachment 36119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36119&action=edit
proposed patch to GCC

Since operator< is not available for thread types when using the pthreads-win32
library, gcc build fails when configured with POSIX threads on MinGW64.

The attached patch implements a field-by-field comparison.

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[sliwa at ifpan dot edu.pl]

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

--- Comment #1 from Cezary Śliwa  ---
Created attachment 36120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36120&action=edit
complementary patch to the w32-pthreads library

[Bug c++/66427] The compiler rejects too complex variable templates

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
   Target Milestone|--- |5.2
 Ever confirmed|0   |1

--- Comment #2 from Paolo Carlini  ---
5.2.0 is also fine, I'm adding a testcase and closing the bug.

[Bug c/67115] New: [MinGW64] name conflict with system headers (identifier "CONST")

[sliwa at ifpan dot edu.pl]

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

Bug ID: 67115
   Summary: [MinGW64] name conflict with system headers
(identifier "CONST")
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sliwa at ifpan dot edu.pl
  Target Milestone: ---

A pthreads build on MinGW64 fails due to a name conflict:

* "CONST" is a macro in the system headers (#defined to const)

* CONST is an enum value in the GCC source


Apparently, the build completes fine with Win32 threads.

[Bug c++/66427] The compiler rejects too complex variable templates

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Aug  4 11:05:02 2015
New Revision: 226568

URL: https://gcc.gnu.org/viewcvs?rev=226568&root=gcc&view=rev
Log:
2015-08-04  Paolo Carlini  

PR c++/66427
* g++.dg/cpp1y/var-templ34.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ34.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/66427] The compiler rejects too complex variable templates

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|morwenn29 at hotmail dot fr|
 Resolution|--- |FIXED

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin  ---
Created attachment 36121
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36121&action=edit
Beginning of a patch

The existing code mixes gmp allocation with wide_int allocation.
With the patch, an extra sign bit needs to be written in the most significant
word.
I don't know how to avoid the memory management nightmare.

[Bug target/67110] gcc.target/i386/iamcu/test_struct_returning.c execution test FAILs with -fpic

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com

--- Comment #1 from H.J. Lu  ---
Since

/* Clear all scratch integer registers.  */
#define clear_int_hardware_registers \
  asm __volatile__ ("xor %%eax, %%eax\n\t" \
"xor %%edx, %%edx\n\t" \
"xor %%ecx, %%ecx\n\t" \
::: "eax", "edx", "ecx");

/* Clear both hardware and register structs for integers, excluding the
   one used to return aggregate.  */
#define clear_non_sret_int_registers \
  clear_struct_registers \
  clear_non_sret_int_hardware_registers

#undef D
#define D(I) { static struct S_ ## I s; current_test = I; struct_addr =
(void*)&s; \
  clear_non_sret_int_registers; \
  s = WRAP_RET(f_ ## I) (); \
  check_all(class_ ## I, sizeof(s)); \
}

trash PIC register, iamcu tests should add -fno-PIC -no-pie.

[Bug c++/67113] unintelligent error message "only declarations of constructors can be 'explicit'" in cpp file's constructor define.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
The diagnostic is technically correct (the best kind of correct!) because that
is a definition of a constructor, not just a declaration.

i.e. you are focusing on the word constructors and saying "but it is a
constructor!" when you should be focusing on "declarations of constructors".

[Bug c/67115] [MinGW64] name conflict with system headers (identifier "CONST")

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Why do mingw system headers use non-reserved names?

[Bug libstdc++/67112] [MinGW64] build failure due to name conflict with system headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 Ever confirmed|0   |1

[Bug c++/67113] unintelligent error message "only declarations of constructors can be 'explicit'" in cpp file's constructor define.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This is already fixed anyway, gcc 5 says:

a.cc:5:15: error: ‘explicit’ outside class declaration

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
The problem is real, but obviously this patch is not acceptable because you
would need to add pthread_less to every implementation of pthreads, and to the
POSIX standard. GCC doesn't only support mingw.

[Bug c/67115] [MinGW64] name conflict with system headers (identifier "CONST")

[sliwa at ifpan dot edu.pl]

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

--- Comment #2 from Cezary Śliwa  ---
It may be because they follow the OS specific standards, so to say.

[Bug target/67110] gcc.target/i386/iamcu/test_struct_returning.c execution test FAILs with -fpic

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Aug  4 11:54:20 2015
New Revision: 226570

URL: https://gcc.gnu.org/viewcvs?rev=226570&root=gcc&view=rev
Log:
Compile IAMCU tests with -fno-pie -no-pie

Since IAMCU tests clear all scratch integer registers with:

  asm __volatile__ ("xor %%eax, %%eax\n\t" \
"xor %%edx, %%edx\n\t" \
"xor %%ecx, %%ecx\n\t" \
::: "eax", "edx", "ecx");

PIC register may be trashed between setting PIC register and using it.
This patch compiles AMCU tests with -fno-pie -no-pie.

PR target/67110
* gcc.target/i386/iamcu/abi-iamcu.exp (additional_flags): Add
-fno-pie -no-pie.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/iamcu/abi-iamcu.exp

[Bug target/67110] gcc.target/i386/iamcu/test_struct_returning.c execution test FAILs with -fpic

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug tree-optimization/67109] [6 Regression] ICE at -O3 on x86_64-linux-gnu in vect_analyze_slp_instance, at tree-vect-slp.c:1793

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE at -O3 on   |[6 Regression] ICE at -O3
   |x86_64-linux-gnu in |on x86_64-linux-gnu in
   |vect_analyze_slp_instance,  |vect_analyze_slp_instance,
   |at tree-vect-slp.c:1793 |at tree-vect-slp.c:1793
 Ever confirmed|0   |1

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

[Bug tree-optimization/67109] [6 Regression] ICE at -O3 on x86_64-linux-gnu in vect_analyze_slp_instance, at tree-vect-slp.c:1793

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r224077.

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[sliwa at ifpan dot edu.pl]

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

--- Comment #3 from Cezary Śliwa  ---
Yes, I understand. The purpose of the patch is to point the problem. In
particular I don't know why operator< is needed and what are the required
semantics (i.e. comparing pointers vs. comparing thread sequence numbers; what
is the x field in the struct?). I am also concerned if the current
implementation of pthread_equal in the w32-pthreads library is correct in this
respect.

[Bug c++/67108] [6 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1345 when dumping

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 CC||mpolacek at gcc dot gnu.org
Summary|ICE: in |[6 Regression] ICE: in
   |cxx_eval_call_expression,   |cxx_eval_call_expression,
   |at cp/constexpr.c:1345 when |at cp/constexpr.c:1345 when
   |dumping |dumping
 Ever confirmed|0   |1

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

[Bug c++/67108] [6 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1345 when dumping

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
The dumping ICE started with r217663.

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The C++ standard requires thread::id objects to be comparable with operator<
and for it to impose a total order.

The current libstdc++ code assumes that a total order can be obtained simply by
comparing the pthread_t objects, which is not portable, but some form of total
order over pthread_t objects is needed.

For w32-pthreads comparing thread sequence numbers should be sufficient.

[Bug c/67107] [6 Regression] ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 Ever confirmed|0   |1

[Bug c/67107] [6 Regression] ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r225375.

[Bug libstdc++/64351] std::uniform_real_distribution(0, 1) returns 1

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
Closely related to PR63176 ...

[Bug tree-optimization/67109] [6 Regression] ICE at -O3 on x86_64-linux-gnu in vect_analyze_slp_instance, at tree-vect-slp.c:1793

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/67056] Wrong code generated

[veg...@yahoo-inc.com]

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

Vegard Sjonfjell  changed:

   What|Removed |Added

 CC||veg...@yahoo-inc.com

--- Comment #5 from Vegard Sjonfjell  ---
Created attachment 36122
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36122&action=edit
Minimal failing example

We've tried to strip the code down to a minimal failing example. Compile with
-O3 -fPIC -std=c++11 (or std=c++14).

[Bug c/67107] [6 Regression] ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug c++/67056] Wrong code generated

[veg...@yahoo-inc.com]

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

--- Comment #6 from Vegard Sjonfjell  ---
Created attachment 36123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36123&action=edit
Preprocessed file

Also adding the preprocessed file.

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #36119|0   |1
is obsolete||
  Attachment #36120|0   |1
is obsolete||

--- Comment #5 from Jonathan Wakely  ---
Created attachment 36124
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36124&action=edit
Add _GLIBCXX_THREAD_ID_LESS hook for thread ID comparisons

This patch preserves the existing behaviour for most targets but adds a new
macro hook that can be used to define a target-specific alternative in
os_defines.h

This does not require any changes to pthreads-win32. Could you test it?

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #36124|0   |1
is obsolete||

--- Comment #6 from Jonathan Wakely  ---
Created attachment 36125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36125&action=edit
Patch to add _GLIBCXX_THREAD_ID_LESS hook.

Oops, that wasn't the final version of the patch. This one should actually
compile!

[Bug c++/66092] [c++-concepts] Concept can't check variadic template arguments

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Crash was fixed.

[Bug c++/66841] [concepts] bogus error "invalid reference to function concept" when function concept is overloaded

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Let's keep the variadic concepts discussion in 66834.

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

[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error

[jason at gcc dot gnu.org]

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

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

[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard

[simon at pushface dot org]

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

--- Comment #5 from simon at pushface dot org ---
(In reply to Jim Wilson from comment #4)

> If you want a proper thumb2 hard multilib, then in the file
> gcc/config/arm/t-arm-elf see the line
> MULTILIB_EXCEPTIONS+= *mthumb/*mfloat-abi=hard*
> Put a # in front of it to disable it, rebuild gcc, and then you will have
> thumb2 hard-float libraries.  See also the comments before this section of
> code.

Brilliant, thanks.

> The t-aprofile that Ramana mentioned does support thumb/hard multilibs, but
> makes this work by requiring armv7 or higher.

Wouldn’t I need a t-mprofile?

[Bug c++/66834] [concepts] variadic concepts and DR 1430

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2015-08-04
 Depends on||66092
Summary|[concepts] concept  |[concepts] variadic
   |parameter kind mismatch |concepts and DR 1430
   |causes hard error   |
 Ever confirmed|0   |1

--- Comment #16 from Jason Merrill  ---
Suspending.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66092
[Bug 66092] [c++-concepts] Concept can't check variadic template arguments

[Bug libstdc++/67116] New: incorrect detection of thread model when cross-compiling the tool chain

[sliwa at ifpan dot edu.pl]

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

Bug ID: 67116
   Summary: incorrect detection of thread model when
cross-compiling the tool chain
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sliwa at ifpan dot edu.pl
  Target Milestone: ---

The configure script detects the thread model of the CXX compiler. When
building the tool chain it is the compiler for the host rather than for the
target. These are different when cross-compiling.

For example: I am on Linux; I have built a cross compiler to MinGW64 which uses
Win32 threads; and I want to use it to cross-compile a native MinGW64 compiler
for applications using POSIX threads. I such a situation libstdc++ detects
Win32 thread model and builds without thread support.

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

[ibuclaw at ubuntu dot com]

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

--- Comment #5 from Iain Buclaw  ---
I can still reproduce the wrong-line diagnostic using gcc (GCC) 6.0.0 20150720
(experimental).

However GDB has been building just fine for a while now.  But I don't know if
that is due to a change on GCC or GDB side.

[Bug c++/66921] [4.9/5/6 Regression] failure to determine size of static constexpr array that is nested within a templated class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
Summary|failure to determine size   |[4.9/5/6 Regression]
   |of static constexpr array   |failure to determine size
   |that is nested within a |of static constexpr array
   |templated class |that is nested within a
   ||templated class
 Ever confirmed|0   |1

[Bug c++/66564] ICE on explicit instantiation of nested template class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 Ever confirmed|0   |1

[Bug c++/67056] Wrong code generated

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Created attachment 36126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36126&action=edit
Somewhat reduced testcase

[Bug ipa/67056] [5/6 regression] Wrong code generated

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 CC||hubicka at gcc dot gnu.org
  Component|c++ |ipa
Summary|Wrong code generated|[5/6 regression] Wrong code
   ||generated
 Ever confirmed|0   |1

--- Comment #8 from Markus Trippelsdorf  ---
markus@x4 tmp % g++  -fsanitize=undefined -std=c++14 -O2 -fPIC mem.ii
markus@x4 tmp % ./a.out
mem.ii:72:5: runtime error: execution reached a __builtin_unreachable() call
markus@x4 tmp % g++ -fno-devirtualize -fsanitize=undefined  -std=c++14 -O2
-fPIC mem.ii
markus@x4 tmp % ./a.out
markus@x4 tmp %

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[sliwa at ifpan dot edu.pl]

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

--- Comment #7 from Cezary Śliwa  ---

1. After applying the patch to GCC 5.2.0, the build fails (I do not see
PTW32_VERSION defined):

Making all in c++11
make[5]: Entering directory
`/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src/c++11'
/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/czarek/src/nowe/build-pthreads/objdir-gcc/./gcc/xgcc -shared-libgcc
-B/home/czarek/src/nowe/build-pthreads/objdir-gcc/./gcc -nostdinc++
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/opt/mingw64/x86_64-w64-mingw32/lib -L/opt/mingw64/mingw/lib -isystem
/opt/mingw64/x86_64-w64-mingw32/include -isystem /opt/mingw64/mingw/include
-B/opt/mingw64/x86_64-w64-mingw32/bin/ -B/opt/mingw64/x86_64-w64-mingw32/lib/
-isystem /opt/mingw64/x86_64-w64-mingw32/include -isystem
/opt/mingw64/x86_64-w64-mingw32/sys-include   
-I/home/czarek/src/nowe/build-pthreads/gcc-5.2.0/libstdc++-v3/../libgcc
-I/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include
-I/home/czarek/src/nowe/build-pthreads/gcc-5.2.0/libstdc++-v3/libsupc++ 
-std=gnu++11 -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=functexcept.lo -g -O2  -c -o
functexcept.lo ../../../../../gcc-5.2.0/libstdc++-v3/src/c++11/functexcept.cc
libtool: compile:  /home/czarek/src/nowe/build-pthreads/objdir-gcc/./gcc/xgcc
-shared-libgcc -B/home/czarek/src/nowe/build-pthreads/objdir-gcc/./gcc
-nostdinc++
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/opt/mingw64/x86_64-w64-mingw32/lib -L/opt/mingw64/mingw/lib -isystem
/opt/mingw64/x86_64-w64-mingw32/include -isystem /opt/mingw64/mingw/include
-B/opt/mingw64/x86_64-w64-mingw32/bin/ -B/opt/mingw64/x86_64-w64-mingw32/lib/
-isystem /opt/mingw64/x86_64-w64-mingw32/include -isystem
/opt/mingw64/x86_64-w64-mingw32/sys-include
-I/home/czarek/src/nowe/build-pthreads/gcc-5.2.0/libstdc++-v3/../libgcc
-I/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include
-I/home/czarek/src/nowe/build-pthreads/gcc-5.2.0/libstdc++-v3/libsupc++
-std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=functexcept.lo -g -O2 -c
../../../../../gcc-5.2.0/libstdc++-v3/src/c++11/functexcept.cc -o functexcept.o
In file included from
/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include/future:40:0,
 from
../../../../../gcc-5.2.0/libstdc++-v3/src/c++11/functexcept.cc:34:
/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include/thread:
In instantiation of ‘static bool std::thread::id::__less<_Tp,
 >::_S_less(const _Tp&, const _Tp&) [with _Tp =
ptw32_handle_t;  = void]’:
/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include/thread:106:37:
  required from here
/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/include/thread:91:36:
error: ‘_GLIBCXX_THREAD_ID_LESS’ was not declared in this scope
{ return _GLIBCXX_THREAD_ID_LESS(__x, __y); }
^
make[5]: *** [functexcept.lo] Error 1
make[5]: Leaving directory
`/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src/c++11'
make[5]: Entering directory
`/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src'
/bin/sh ../libtool --tag CXX   --mode=compile
/home/czarek/src/nowe/build-pthreads/objdir-gcc/./gcc/xgcc -shared-libgcc
-B/home/czarek/src/nowe/build-pthreads/objdir-gcc/./gcc -nostdinc++
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/opt/mingw64/x86_64-w64-mingw32/lib -L/opt/mingw64/mingw/lib -isystem
/opt/mingw64/x86_64-w64-mingw32/include -isystem /opt/mingw64/mingw/include
-B/opt/mingw64/x86_64-w64-mingw32/bin/ -B/opt/mingw64/x86_64-w64-mingw32/lib/
-isystem /opt/m

[Bug c++/66392] rejects-valid: copy-initialization through user-defined conversion sequence fails

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #1 from Paolo Carlini  ---
Works in mainline, likely due to the fix for c++/54521. I'm adding the testcase
and closing the bug.

[Bug c++/66392] rejects-valid: copy-initialization through user-defined conversion sequence fails

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Aug  4 14:54:07 2015
New Revision: 226579

URL: https://gcc.gnu.org/viewcvs?rev=226579&root=gcc&view=rev
Log:
2015-08-04  Paolo Carlini  

PR c++/66392
* g++.dg/init/explicit4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/init/explicit4.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/66392] rejects-valid: copy-initialization through user-defined conversion sequence fails

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|paolo.carlini at oracle dot com|
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Paolo Carlini  ---
Done.

[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard

[jim.wilson at linaro dot org]

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

--- Comment #6 from jim.wilson at linaro dot org ---
On Tue, Aug 4, 2015 at 6:39 AM, simon at pushface dot org
 wrote:
>> The t-aprofile that Ramana mentioned does support thumb/hard multilibs, but
>> makes this work by requiring armv7 or higher.
>
> Wouldn’t I need a t-mprofile?

Perhaps.  I'm relatively new to arm, and not sure about the
differences between the a-profile and m-profile.

Jim

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Severity|major   |normal

[Bug c++/66696] confusing diagnostic on a friend main definition returning void

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-04
 Blocks||65608
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
[Bug 65608] [meta-bug] friend issues

[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
I am seeing:

FAIL: gfortran.dg/ieee/large_1.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/ieee/large_1.f90   -Os  (test for excess errors)

on Fedora 22/x86.

[Bug c++/66586] Template backtrace is truncated/absent after 'template argument deduction/substitution failed:'

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
Happens in c++/66439 too.

[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #6)
> I am seeing:
> 
> FAIL: gfortran.dg/ieee/large_1.f90   -O0  (test for excess errors)
> FAIL: gfortran.dg/ieee/large_1.f90   -O1  (test for excess errors)
> FAIL: gfortran.dg/ieee/large_1.f90   -O2  (test for excess errors)
> FAIL: gfortran.dg/ieee/large_1.f90   -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions  (test for excess errors)
> FAIL: gfortran.dg/ieee/large_1.f90   -O3 -g  (test for excess errors)
> FAIL: gfortran.dg/ieee/large_1.f90   -Os  (test for excess errors)
> 
> on Fedora 22/x86.

So, what is the the log file?  We can't see 
inside your computer or head!

[Bug c++/67117] New: [c++-concepts] Constraints ignored on variable template

[Casey at Carter dot net]

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

Bug ID: 67117
   Summary: [c++-concepts] Constraints ignored on variable
template
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

r226546 fails to compile this TU:

template 
  requires false
constexpr bool v = true;

template 
constexpr bool f() { return true; }

template 
  requires v
constexpr bool f() { return false; }

static_assert(f());

with error:

~/concept-gcc/bin/g++ -std=gnu++1z foo.cpp -c
foo.cpp:12:1: error: static assertion failed
 static_assert(f());
 ^

It seems the constraints on the variable template are not checked. Indeed this
TU:

template 
  requires false
constexpr bool v = true;

static_assert(v);

is accepted without diagnoses.

[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
(In reply to Andrew Sutton from comment #14)
> Created attachment 36054 [details]
> 
> There is still complexity induced by the use of disjunctions. This manages
> it a little better. It could be further improved by making the term list
> into a term set by way of hashing or ordering.

This seems like a definite improvement, though I agree that we will want to
move to a set.  I was waiting for you to check it in; perhaps you were also
waiting for me to do it?  I'll go ahead and apply it now.

[Bug fortran/67118] New: gcc and gfortran started crashing recently

[niksah at gmail dot com]

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

Bug ID: 67118
   Summary: gcc and gfortran started crashing recently
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niksah at gmail dot com
  Target Milestone: ---

Created attachment 36127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36127&action=edit
preprocessed file generated with gfortran -save-temps -c drotmg.f

gcc, gfortran and g++ started crashing on my system recently.  Below, I show
the output while trying to compile one of the BLAS routines with gfortran.

gfortran  -c drotmg.f

f951: internal compiler error: Illegal instruction
0xa596bf crash_signal
../../gcc-5.2.0/gcc/toplev.c:383
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I get similar errors with g++
0xaa39af crash_signal
../../gcc-5.2.0/gcc/toplev.c:383

and also with gcc:
0x9bd0af crash_signal
../../gcc-5.2.0/gcc/toplev.c:383

The compilers do not crash for all .f, .c, .cpp files.  gcc 4.8 worked fine on
my system until at least early June but started giving the same crashes shown
above.  Versions 4.8 and 5.2 of the compilers were configured/built with
default options, i.e., ../gcc.../configure, followed by make and, finally, make
install.

the exact version of GCC;
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/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
Thread model: posix
gcc version 5.2.0 (GCC)

the system type;
$ uname -a
Linux localhost 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

The compilers worked fine on a very similar system, which makes me suspect that
the issue is due to one of the gcc dependencies but I have been unable to
figure this out.  Thanks in advance for any guidance you can provide to resolve
this issue.

[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE

[jason at gcc dot gnu.org]

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

--- Comment #18 from Jason Merrill  ---
Author: jason
Date: Tue Aug  4 15:38:29 2015
New Revision: 226583

URL: https://gcc.gnu.org/viewcvs?rev=226583&root=gcc&view=rev
Log:
PR c++/66962
* logic.cc (term_list::insert): Avoid adding duplicate terms.

Added:
branches/c++-concepts/gcc/testsuite/g++.dg/concepts/disjunction1.C
Modified:
branches/c++-concepts/ChangeLog.concepts
branches/c++-concepts/gcc/cp/logic.cc

[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #19 from Jason Merrill  ---
Fixed.

[Bug ipa/67056] [5/6 regression] Wrong code generated

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
Started with r215902.

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Cezary Śliwa from comment #7)
> 1. After applying the patch to GCC 5.2.0, the build fails (I do not see
> PTW32_VERSION defined):

Doh, of course not, because gthr.h isn't included until after os_defines.h,
sorry.

[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-08-04
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
What are the configure commands you're using?

Libstdc++ is built using the target compiler, so its configure uses the target
compiler not the host, so this shouldn't happen.

[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[fxcoudert at gcc dot gnu.org]

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

--- Comment #8 from Francois-Xavier Coudert  ---
(In reply to H.J. Lu from comment #6)
> FAIL: gfortran.dg/ieee/large_1.f90   -O0  (test for excess errors)

This is fixed by the following patch, waiting for approval:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00124.html

[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain

[sliwa at ifpan dot edu.pl]

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

--- Comment #2 from Cezary Śliwa  ---

This is a quite special case, target and host architecture are the same, only
the thread models are different. I think libstdc++ uses the preinstalled
compiler rather that the one just built. Anyway, the preinstalled compiler is:

$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/opt/mingw64-v4.0.2/bin/../libexec/gcc/x86_64-w64-mingw32/5.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../gcc-5.2.0/configure --with-sysroot=/opt/mingw64
--prefix=/opt/mingw64 --enable-languages=c,c++,fortran,lto
--target=x86_64-w64-mingw32 --enable-targets=all
Thread model: win32
gcc version 5.2.0 (GCC)


and the configure command:

../gcc-5.2.0/configure --with-sysroot=/mingw64 --prefix=/mingw64
--enable-languages=c,c++,fortran,lto --target=x86_64-w64-mingw32
--enable-targets=all --host=x86_64-w64-mingw32 --enable-threads=posix
--enable-libgomp

[Bug c++/66197] c++1z generic function wrong type for auto

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
Indeed, this is also fixed in mainline. I'm adding a testcase and closing the
bug.

[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #7 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Aug  4 16:22:32 2015
New Revision: 226586

URL: https://gcc.gnu.org/viewcvs?rev=226586&root=gcc&view=rev
Log:
[AArch64] PR target/66731 Fix fnmul insn with -frounding-math (rtx costs)

2015-08-04  Szabolcs Nagy  

PR target/66731
* config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL.
(aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math.


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

[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #8 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Aug  4 16:43:46 2015
New Revision: 226587

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

Backport from mainline:
2015-08-04  Szabolcs Nagy  

PR target/66731
* config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL.
(aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math.

2015-07-06  Szabolcs Nagy  

PR target/66731
* config/aarch64/aarch64.md (fnmul3): Handle -frounding-math.

gcc/testsuite:

Backport from mainline r225450:
2015-07-06  Szabolcs Nagy  

PR target/66731
* gcc.target/aarch64/fnmul-1.c: New.
* gcc.target/aarch64/fnmul-2.c: New.
* gcc.target/aarch64/fnmul-3.c: New.
* gcc.target/aarch64/fnmul-4.c: New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-4.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/aarch64/aarch64.c
branches/gcc-5-branch/gcc/config/aarch64/aarch64.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Iain Buclaw from comment #5)
> I can still reproduce the wrong-line diagnostic using gcc (GCC) 6.0.0
> 20150720 (experimental).
> 
> However GDB has been building just fine for a while now.  But I don't know
> if that is due to a change on GCC or GDB side.

Probably GDB worked around the issue or silence the warning via #pragma. That
doesn't mean that the bug is fixed.

[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Cezary Śliwa from comment #2)
> This is a quite special case, target and host architecture are the same,
> only the thread models are different. I think libstdc++ uses the
> preinstalled compiler rather that the one just built. 

If that is happening it's certainly a bug. Could you attach the
$target/libstdc++-v3/config.log please?

[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #9 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Aug  4 16:49:54 2015
New Revision: 226588

URL: https://gcc.gnu.org/viewcvs?rev=226588&root=gcc&view=rev
Log:
Fix broken backport patch.

gcc:

Backport from mainline:
2015-08-04  Szabolcs Nagy  

PR target/66731
* config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL.
(aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math.


Modified:
branches/gcc-5-branch/gcc/config/aarch64/aarch64.c

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[mrs at gcc dot gnu.org]

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

--- Comment #9 from mrs at gcc dot gnu.org  ---
I've audited the patch for the memory management nightmares; we are safe with
it.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[zadeck at naturalbridge dot com]

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

--- Comment #10 from Kenneth Zadeck  ---
I have audited the patch for the non memory management issues and it is 
approved.

thanks for doing this.

kenny

On 08/04/2015 07:38 AM, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311
>
> --- Comment #8 from Mikael Morin  ---
> Created attachment 36121
>--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36121&action=edit
> Beginning of a patch
>
> The existing code mixes gmp allocation with wide_int allocation.
> With the patch, an extra sign bit needs to be written in the most significant
> word.
> I don't know how to avoid the memory management nightmare.
>

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
(In reply to Kenneth Zadeck from comment #10)
> I have audited the patch for the non memory management issues and it is 
> approved.

Please don't apply just yet, I'd like to take a closer look.
(Sorry for not doing it earlier.)

[Bug c++/66197] c++1z generic function wrong type for auto

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Aug  4 17:22:05 2015
New Revision: 226591

URL: https://gcc.gnu.org/viewcvs?rev=226591&root=gcc&view=rev
Log:
2015-08-04  Paolo Carlini  

PR c++/66197
* g++.dg/cpp1z/abbrev2.C: New.

2015-08-04  Paolo Carlini  

* g++.dg/cpp1z/static_assert-nomsg.C: Fix DejaGnu directive.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/abbrev2.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1z/static_assert-nomsg.C

[Bug c++/66197] c++1z generic function wrong type for auto

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math

[nsz at gcc dot gnu.org]

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

--- Comment #10 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Aug  4 17:42:05 2015
New Revision: 226592

URL: https://gcc.gnu.org/viewcvs?rev=226592&root=gcc&view=rev
Log:
gcc:
Backport from mainline:
2015-07-06  Szabolcs Nagy  

PR target/66731
* config/aarch64/aarch64.md (fnmul3): Handle -frounding-math.

gcc/testsuite:

Backport from mainline r225450:
2015-07-06  Szabolcs Nagy  

PR target/66731
* gcc.target/aarch64/fnmul-1.c: New.
* gcc.target/aarch64/fnmul-2.c: New.
* gcc.target/aarch64/fnmul-3.c: New.
* gcc.target/aarch64/fnmul-4.c: New.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-2.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-3.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-4.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/67063] segfault in opening a formatted file at second time with status="replace"

[ismail at donmez dot ws]

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

İsmail Dönmez  changed:

   What|Removed |Added

 CC||ismail at donmez dot ws

--- Comment #5 from İsmail Dönmez  ---
You can try with my 6.x snapshots from https://i10z.com/mingw-w64/6.x/ , I
tested your testcase and it works fine.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Created attachment 36128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36128&action=edit
Alternative patch

Here's an alternative patch. I haven't yet tested it beyond
an expanded version of the testcase, but I think it's easier
to follow if we separate the "val != valres" and "need an extra
zero block" logic.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[fxcoudert at gcc dot gnu.org]

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

--- Comment #13 from Francois-Xavier Coudert  ---
(In reply to rsand...@gcc.gnu.org from comment #12)
> Here's an alternative patch. I haven't yet tested it beyond
> an expanded version of the testcase, but I think it's easier
> to follow if we separate the "val != valres" and "need an extra
> zero block" logic.

I can confirm that the attached patch fixes all Fortran testcases reported in
this thread.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[mikael at gcc dot gnu.org]

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

--- Comment #14 from Mikael Morin  ---
(In reply to rsand...@gcc.gnu.org from comment #12)
> Created attachment 36128 [details]
> Alternative patch
> 
> Here's an alternative patch. I haven't yet tested it beyond
> an expanded version of the testcase, but I think it's easier
> to follow if we separate the "val != valres" and "need an extra
> zero block" logic.

Looks cleaner indeed. :-)
I'm still worried by the case where x is negative and fits in wide_int, but its
absolute value doesn't.
It's somehow the same as this case, except that the boundary is at the size of
wide_int (whatever it is) instead of 64 bits (the size of HOST_WIDE_INT) in
this case.
Not sure it matters.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[fxcoudert at gcc dot gnu.org]

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

--- Comment #15 from Francois-Xavier Coudert  ---
Created attachment 36129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36129&action=edit
Fortran testcase

Attached is a Fortran testcase, ready for inclusion in
gcc/testsuite/gfortran.dg
Please commit it along with the patch, when the issue is fixed.

[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

[rsandifo at gcc dot gnu.org]

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

--- Comment #16 from rsandifo at gcc dot gnu.org  
---
(In reply to Mikael Morin from comment #14)
> (In reply to rsand...@gcc.gnu.org from comment #12)
> > Created attachment 36128 [details]
> > Alternative patch
> > 
> > Here's an alternative patch. I haven't yet tested it beyond
> > an expanded version of the testcase, but I think it's easier
> > to follow if we separate the "val != valres" and "need an extra
> > zero block" logic.
> 
> Looks cleaner indeed. :-)
> I'm still worried by the case where x is negative and fits in wide_int, but
> its absolute value doesn't.
> It's somehow the same as this case, except that the boundary is at the size
> of wide_int (whatever it is) instead of 64 bits (the size of HOST_WIDE_INT)
> in this case.
> Not sure it matters.

Well, in a sense there's no such wide_int, since wide_ints don't have
an inherent sign.  If a wide_int has precision N, the absolute value
of the minimum signed value is 1<<(N-1).  We'd read that in the same
way as we'd read an unsigned N-bit integer with value 1<<(N-1),
so the value would fit at that stage.  If the mpz is negative we then
negate the wide_int, which for the minimum signed value is a no-op.
We'd end up with an N-bit integer in which only bit N-1 is set.

The problem in the testcase is more to do with the decision that,
if an N-bit wide_int is represented with M

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin  ---
Paul, is there something to be done before closing?

[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain

[sliwa at ifpan dot edu.pl]

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

--- Comment #4 from Cezary Śliwa  ---
OK, the newly built compiler cannot be used because we are cross-compiling. The
only thing that can be done is to move the trees to the target system and
finish building target libraries there. A warning or error message could be a
good idea, but otherwise you can close this bug report.

[Bug web/67119] New: URL linking to previous patches are not available

[songlinhai0543 at gmail dot com]

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

Bug ID: 67119
   Summary: URL linking to previous patches are not available
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: songlinhai0543 at gmail dot com
  Target Milestone: ---

I am tracking some old bugs. I notice that many bug patches are not available
from the URL in the bug report. 

For example:

https://gcc.gnu.org/viewvc/gcc?cvsroot=gcc&r1=1.65&r2=1.66

How should I revise the above URL and find related patches?

[Bug gcov-profile/65831] gcov does not output 0% coverage files

[mdennis at merfer dot net]

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

Matthew Dennis  changed:

   What|Removed |Added

 CC||mdennis at merfer dot net

--- Comment #1 from Matthew Dennis  ---
I've got the same problem

user@host:~$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

user@host:~$ gcov --version
gcov (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.

because there is no .gcov file produced, tools like gcovr don't produce any
output indicating that some files have zero coverage.