[Bug target/71629] [7 Regression] ICE in lra_set_insn_recog_data, at lra.c:964 w/ -O2 -mlra

2016-10-16 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71629

--- Comment #8 from Arseny Solokha  ---
Well, snippets from #c0 and #c2 still make the latest snapshot ICE:

%
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/build/./gcc/xgcc
-B/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/build/./gcc/
-fPIC -fstack-protector -O2 -c -w /tmp/1.c
/tmp/1.c: In function 'pf':
/tmp/1.c:41:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:965
 }
 ^

%
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/build/./gcc/xgcc
-B/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/build/./gcc/
-fPIC -fstack-protector -Os -c -w /tmp/2.c
/tmp/2.c: In function 'kw':
/tmp/2.c:37:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:965
 }
 ^

And I still can't bootstrap the latest snapshot itself:

%
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/build/./gcc/xgcc
-B/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/build/./gcc/
-g -O2 -c -w method-gl.ii 
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/gcc-7-20161016/libitm/method-gl.cc:
In member function  virtual void
{anonymous}::gl_wt_dispatch::ITM_WaRU8(_ITM_TYPE_U8*, _ITM_TYPE_U8)':
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20161016/work/gcc-7-20161016/libitm/method-gl.cc:376:88:
internal compiler error: in lra_set_insn_recog_data, at lra.c:965

(but notice the difference in flags needed for reproducing it). So, do you mean
I should open a new PR for the latter bootstrap-related case?

[Bug c++/64270] packed fields

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64270

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
Actually this is invalid and here is the reason why:
a packed reference is not going to bind to a reference by design.  It is a copy
of the array at this point.  If you change from an array to a scalar it will
also do the same behavior.

[Bug tree-optimization/63644] Kahan Summation with fast-math, pattern not always recognized

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63644

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
It is kinda of vectorized:

  :
  # vect_vec_iv_.37_29 = PHI 
  # ivtmp.43_16 = PHI 
  vect_vec_iv_.37_30 = vect_vec_iv_.37_29 + { 4.00059604644775390625e-1,
4.00059604644775390625e-1, 4.00059604644775390625e-1,
4.00059604644775390625e-1 };
  vect_s_10.38_32 = vect_vec_iv_.37_29 + { 1.0001490116119384765625e-1,
1.0001490116119384765625e-1, 1.0001490116119384765625e-1,
1.0001490116119384765625e-1 };
  ivtmp.43_13 = ivtmp.43_16 + 1;
  if (ivtmp.43_13 >= bnd.33_20)
goto ;
  else
goto ;

But then the vectorization part is removed:
  :
  _33 = BIT_FIELD_REF ;


This is odd.

[Bug c++/78003] New: c++17: ICE in build_over_call, at cp/call.c:7847

2016-10-16 Thread jamrial at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78003

Bug ID: 78003
   Summary: c++17: ICE in build_over_call, at cp/call.c:7847
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 39820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39820=edit
Preprocessed output as created by -freport-bug

/home/jamrial/range-v3/include/range/v3/detail/variant.hpp:679:35: internal
compiler error: in build_over_call, at cp/call.c:7847
 detail::variant_visit_(var.index(), data, detail::get_fn{});

~~^
0x646c0f build_over_call
/home/jamrial/gcc-svn/gcc/cp/call.c:7844
0x650edf build_new_method_call_1
/home/jamrial/gcc-svn/gcc/cp/call.c:8661
0x650edf build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:8731
0x651eae build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:8263
0x647d0d build_temp
/home/jamrial/gcc-svn/gcc/cp/call.c:6395
0x647d0d convert_like_real
/home/jamrial/gcc-svn/gcc/cp/call.c:6805
0x648f6c perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:9887
0x643e6b convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:7180
0x6447c0 build_over_call
/home/jamrial/gcc-svn/gcc/cp/call.c:7748
0x6549af build_new_function_call(tree_node*, vec**, bool, int)
/home/jamrial/gcc-svn/gcc/cp/call.c:4204
0x7eee4c finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/jamrial/gcc-svn/gcc/cp/semantics.c:2440
0x6c0298 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:16786
0x6b4d45 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15952
0x6b2d87 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15258
0x6b45cc tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15244
0x6b4410 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:15435
0x6b1875 instantiate_decl(tree_node*, int, bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:22189
0x6fa71b instantiate_pending_templates(int)
/home/jamrial/gcc-svn/gcc/cp/pt.c:22306
0x73e361 c_parse_final_cleanups()
/home/jamrial/gcc-svn/gcc/cp/decl2.c:4506
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Make GCC emit ASM instructions in 'gcc/except.c' for i686 MinGW targets ?

2016-10-16 Thread lhmouse
Hi there,

I come up with an idea about implementing stack unwinding for
the i686-w64-mingw32 target using native Windows Structured
Exception Handling (a.k.a SEH) for efficiency reasons.

Unlike DWARF and SEH for x64, SEH for x86 is stack-based
and works like the SJLJ exception model: The operating system
keeps a thread specific pointer to an SEH node on the stack
that must be installed/uninstalled during run time.

The SEH-head pointer is stored in `fs:[0]`.
Typecially, an SEH handler is installed like this, in Intel syntax:

# typedef EXCEPTION_DISPOSITION
#   filter_function(
# EXCEPTION_RECORD *record, void *establisher_frame,
# CONTEXT *machine_context, void *dispatcher_context)
#   __attribute__((__cdecl__));
# struct x86_seh_node_header {
#   struct x86_seh_node_header *next;
#   filter_function *filter;
#   char extra_data[];
# };

sub esp, 8  # struct x86_seh_node_header this_node;
mov ecx, dword ptr fs:[0]   # 
mov dword ptr[esp], ecx # this_node.next = get_thread_seh_head();
mov dword ptr[esp + 4], offset my_seh_filter
# this_node.filter = _seh_filter
mov dword ptr fs:[0], esp   # set_thread_seh_head(_node);

Before the function exits and its frame is destroyed, the node
must be uninstalled like this:

mov ecx, dword ptr fs:[0]   #
mov dword ptr fs:[0], ecx   # set_thread_seh_head(this_node.next);

Since I am looking at the SJLJ exception model and it seems using
a slim, inlined version of `setjmp()` with `__builtin_longjmp()`
that only stores 3 or 4 pointers, extending that structure should be
a simple matter. The problem is that, installation and uninstallation
of SEH nodes require target-specific ASM code generation.

Is it possible to do in 'gcc/except.c' ?


--
Best regards,
lh_mouse
2016-10-17



[Bug target/71629] [7 Regression] ICE in lra_set_insn_recog_data, at lra.c:964 w/ -O2 -mlra

2016-10-16 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71629

--- Comment #7 from Segher Boessenkool  ---
Is this the same bug at all?  If not, please open a new PR.

Who played with the GCC Bugzilla git repo?

2016-10-16 Thread Frédéric Buclin
Hello,

Someone played with the GCC Bugzilla git repo last week with no real reason:

Author: root 
Date:   Fri Oct 7 15:28:43 2016 +

snap-data


Looks like the goal was to drop all CSS and JS files in data/assets/.
Why? There is no reason to play with the data/ directory. This directory
contains data generated by Bugzilla and is automatically cleaned up (and
regenerated) by checksetup.pl when needed and so doesn't need to be
cleaned up manually, and definitely not via git. data/ is in .gitignore
for a reason!

Moreover, this means that the GCC Bugzilla git repo is no longer in sync
with the upstream Bugzilla git repo, because the one who played with git
also committed my local changes (I didn't do it for a reason). I can no
longer view my local changes, nor can I easily sync both repos with a
fast-forward merge (I think).

Could these changes be reverted to the exact point I left Bugzilla in
May, i.e. 5.0.3 + my patch only?


Frédéric


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

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3
  Known to fail||6.2.0

--- Comment #18 from Richard Biener  ---
GCC 6.2 is being released, adjusting target milestone

[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3

[Bug target/71629] [7 Regression] ICE in lra_set_insn_recog_data, at lra.c:964 w/ -O2 -mlra

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71629

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #6 from Arseny Solokha  ---
(In reply to Segher Boessenkool from comment #5)
> Both testcases build fine for me (with a powerpc-e500v2-linux-gnuspe
> compiler),
> with -fstack-protector -fPIC.
> 
> Closing as fixed; please reopen if it still fails for you.

When building 7.0.0_alpha20160814 snapshot:

In file included from
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/libsanitizer/asan/asan_interceptors.cc:196:0:
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
In function 'SSIZE_T __interceptor_pread64(int, void*, SIZE_T, OFF64_T)':
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:584:1:
internal compiler error: in lra_set_insn_recog_data, at lra.c:964
 }
 ^
0xae0cf1123 lra_set_insn_recog_data(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:962
0xae0cf22f7 lra_get_insn_recog_data
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra-int.h:487
0xae0cf22f7 lra_update_insn_regno_info(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:1584
0xae0cf2750 lra_push_insn_1
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:1735
0xae0cf2750 lra_push_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:1743
0xae0cf29ef push_insns
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:1786
0xae0cf2ff2 lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char const*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:1844
0xae0cffd1e split_reg
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra-constraints.c:5378
0xae0d0090c inherit_in_ebb
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra-constraints.c:6187
0xae0d057fe lra_inheritance()
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra-constraints.c:6257
0xae0cf3f7e lra(_IO_FILE*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:2402
0xae0ca2800 do_reload
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/ira.c:5385
0xae0ca2800 execute
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/ira.c:5569

Reducing this file gives:

namespace __sanitizer {
typedef long uptr;
typedef long sptr;
typedef long long OFF64_T;
}
using namespace __sanitizer;
namespace {
void AsanInitFromRtl();
extern int asan_inited;
}
typedef uptr SIZE_T;
typedef sptr SSIZE_T;
typedef SSIZE_T pread64_f(int, void *, SIZE_T, OFF64_T);
namespace __interception {
pread64_f real_pread64;
}
SSIZE_T
__interceptor_pread64(int fd, void *ptr, SIZE_T count, OFF64_T offset) {
  if (asan_inited)
AsanInitFromRtl();
  __interception::real_pread64(fd, ptr, count, offset);
}

%
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/build/./gcc/xg++
-B/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/build/gcc
-c -w -O2 asan_interceptors.i 
asan_interceptors.i: In function 'SSIZE_T __interceptor_pread64(int, void*,
SIZE_T, __sanitizer::OFF64_T)':
asan_interceptors.i:22:1: internal compiler error: in lra_set_insn_recog_data,
at lra.c:964
 }
 ^
0x79a9f30123 lra_set_insn_recog_data(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:962
0x79a9f312f7 lra_get_insn_recog_data
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra-int.h:487
0x79a9f312f7 lra_update_insn_regno_info(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:1584
0x79a9f31750 lra_push_insn_1
   
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160814/work/gcc-7-20160814/gcc/lra.c:1735
0x79a9f31750 lra_push_insn(rtx_insn*)
   

[Bug rtl-optimization/49857] Put constant switch-tables into flash

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3
  Known to fail||6.2.0

--- Comment #11 from Richard Biener  ---
GCC 6.2 is being released, adjusting target milestone

[Bug c++/66487] sanitizer/warnings for lifetime DSE

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3

[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3
  Known to fail||6.2.0

--- Comment #6 from Richard Biener  ---
GCC 6.2 is being released, adjusting target milestone

[Bug c++/65642] [C++11] GCC rejects valid constant expression

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65642

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3

[Bug c++/70019] VLA size overflow not detected

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3

[Bug target/35514] Gcc shoud generate symbol type for undefined symbol

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3
  Known to fail||6.2.0

--- Comment #4 from Richard Biener  ---
GCC 6.2 is being released, adjusting target milestone

[Bug middle-end/28628] Not forcing alignment of arrays in structs with -fsection-anchors

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28628

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.2 |6.3
  Known to fail||6.2.0

--- Comment #4 from Richard Biener  ---
GCC 6.2 is being released, adjusting target milestone

Re: Question about sibling call epilogues & registers

2016-10-16 Thread Daniel Santos

On 10/16/2016 05:27 PM, Segher Boessenkool wrote:



Oddly enough, I had forgotten to call add_function_usage_to() on my save
stub (which I didn't post), but not the restore stub. So thanks for that
psychic intervention. :) But if you look carefully, it's there, although
it's hard to read because of all the line wrapping:

 (expr_list (use (reg:DI 4 si))
 (nil)))

But shouldn't it be marked as using RCX as well?



So the bright side is that I'm learning a lot more about
gcc internals! Which is probably my main goal of this exercise.

:-)


Segher


Hehe, well no, it's the sibcall to LeaveCriticalSection that needs RCX. 
My stub isn't reading or touching it.


Daniel


[Bug web/77551] Disable the priority and severity fields for users without editbugs privileges

2016-10-16 Thread LpSolit at netscape dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77551

Frédéric Buclin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |LpSolit at netscape dot 
net
Summary|Please disable the  |Disable the priority and
   |"Importance:" field for |severity fields for users
   |normal users of bugzilla|without editbugs privileges
   Severity|normal  |enhancement

--- Comment #2 from Frédéric Buclin  ---
Done.

[Bug libstdc++/77998] clang rejects std::thread from trunk

2016-10-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77998

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-16
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
That result_type typedef is only there to satisfy some pieces of , so
I'll move it out of std::thread.

[Bug c++/77999] GCC diagnoses usage of STL literal operators as invalid.

2016-10-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77999

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
That's not an error. Using -Werror is cheating :P

This is similar to PR 57640, but apparently this slightly different case wasn't
fixed when that was.

gcc-7-20161016 is now available

2016-10-16 Thread gccadmin
Snapshot gcc-7-20161016 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20161016/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 241222

You'll find:

 gcc-7-20161016.tar.bz2   Complete GCC

  MD5=e733c4c84b82a852bc5529f45358179c
  SHA1=9c79193c8bffe7614cc8664c1685629e53ca9ce2

Diffs from 7-20161009 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Re: Question about sibling call epilogues & registers

2016-10-16 Thread Segher Boessenkool
On Sun, Oct 16, 2016 at 05:05:17PM -0500, Daniel Santos wrote:
> >>The insn that's getting deleted is 75, where RCX is set.  I'm starting
> >>to think that maybe df_analyze() presumes that my call (to the stub) is
> >>invalidating RCX, although it does not.
> >It looks like you don't use add_function_usage_to on the call insn?

> Oddly enough, I had forgotten to call add_function_usage_to() on my save 
> stub (which I didn't post), but not the restore stub. So thanks for that 
> psychic intervention. :) But if you look carefully, it's there, although 
> it's hard to read because of all the line wrapping:
> 
> (expr_list (use (reg:DI 4 si))
> (nil)))

But shouldn't it be marked as using RCX as well?


> So the bright side is that I'm learning a lot more about 
> gcc internals! Which is probably my main goal of this exercise.

:-)


Segher


Re: Question about sibling call epilogues & registers

2016-10-16 Thread Daniel Santos

On 10/15/2016 08:41 PM, Segher Boessenkool wrote:

Hi Daniel,

On Sat, Oct 15, 2016 at 01:45:12AM -0500, Daniel Santos wrote:

The insn that's getting deleted is 75, where RCX is set.  I'm starting
to think that maybe df_analyze() presumes that my call (to the stub) is
invalidating RCX, although it does not.

It looks like you don't use add_function_usage_to on the call insn?


Segher


Oddly enough, I had forgotten to call add_function_usage_to() on my save 
stub (which I didn't post), but not the restore stub. So thanks for that 
psychic intervention. :) But if you look carefully, it's there, although 
it's hard to read because of all the line wrapping:


(expr_list (use (reg:DI 4 si))
(nil)))

Right now I'm using gdb and gradually walking through df_analyze() and 
learning how the data flow and problems work. I presume that I can find 
my answer somewhere in the "live register" data flow problem code . This 
eventually runs "dead code elimination" on this insn (during the 
"finalize" phase), so I believe that I'm getting closer to discovering 
the root cause. So the bright side is that I'm learning a lot more about 
gcc internals! Which is probably my main goal of this exercise.


Daniel


[PATCH/AARCH64] Fix some testcases for AARCH64 ILP32

2016-10-16 Thread Andrew Pinski
Hi,
  These testcases use long for 64bit integer which means they will
fail with -mabi=ilp32 on aarch64.  This reduces the number of failures
down for ILP32.

OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions
(including with a multi-lib for ilp32).

Thanks,
Andrew Pinski

testsuite/ChangeLog:
* gcc.dg/tree-ssa/sra-17.c: Use long long instead of long.
* gcc.dg/tree-ssa/sra-18.c: Likewise.
* gcc.target/aarch64/aapcs64/test_align-7.c: Likewise.
* gcc.target/aarch64/cinc_common_1.c: Likewise.
* gcc.target/aarch64/combine_bfi_1.c: Likewise.
* gcc.target/aarch64/fmul_fcvt_1.c: Likewise.
* gcc.target/aarch64/mult-synth_4.c: Likewise.
* gcc.target/aarch64/pr68102_1.c: Likewise.
* gcc.target/aarch64/target_attr_3.c: Likewise.
Index: testsuite/gcc.dg/tree-ssa/sra-17.c
===
--- testsuite/gcc.dg/tree-ssa/sra-17.c  (revision 241217)
+++ testsuite/gcc.dg/tree-ssa/sra-17.c  (working copy)
@@ -7,7 +7,7 @@ extern void abort (void);
 int
 main (int argc, char **argv)
 {
-  long a[4] = { 7, 19, 11, 255 };
+  long long a[4] = { 7, 19, 11, 255 };
   int tot = 0;
   for (int i = 0; i < 4; i++)
 tot = (tot*256) + a[i];
Index: testsuite/gcc.dg/tree-ssa/sra-18.c
===
--- testsuite/gcc.dg/tree-ssa/sra-18.c  (revision 241217)
+++ testsuite/gcc.dg/tree-ssa/sra-18.c  (working copy)
@@ -3,7 +3,7 @@
 /* { dg-additional-options "-mcpu=ev4" { target alpha*-*-* } } */
 
 extern void abort (void);
-struct foo { long x; };
+struct foo { long long x; };
 
 struct bar { struct foo f[2]; };
 
Index: testsuite/gcc.target/aarch64/aapcs64/test_align-7.c
===
--- testsuite/gcc.target/aarch64/aapcs64/test_align-7.c (revision 241217)
+++ testsuite/gcc.target/aarch64/aapcs64/test_align-7.c (working copy)
@@ -7,8 +7,8 @@
 
 struct s
   {
-long x;
-long y;
+long long x;
+long long y;
   };
 
 /* This still has size 16, so is still passed by value.  */
Index: testsuite/gcc.target/aarch64/cinc_common_1.c
===
--- testsuite/gcc.target/aarch64/cinc_common_1.c(revision 241217)
+++ testsuite/gcc.target/aarch64/cinc_common_1.c(working copy)
@@ -15,14 +15,14 @@ barsi (int x)
   return x > 100 ? x + 4 : x + 3;
 }
 
-long
-foodi (long x)
+long long
+foodi (long long x)
 {
   return x > 100 ? x - 2 : x - 1;
 }
 
-long
-bardi (long x)
+long long
+bardi (long long x)
 {
   return x > 100 ? x + 4 : x + 3;
 }
Index: testsuite/gcc.target/aarch64/combine_bfi_1.c
===
--- testsuite/gcc.target/aarch64/combine_bfi_1.c(revision 241217)
+++ testsuite/gcc.target/aarch64/combine_bfi_1.c(working copy)
@@ -25,8 +25,8 @@ f4 (int x, int y)
   return (x & ~0xff) | (y & 0xff);
 }
 
-long
-f5 (long x, long y)
+long long
+f5 (long long x, long long y)
 {
   return (x & ~0xull) | (y & 0x);
 }
Index: testsuite/gcc.target/aarch64/fmul_fcvt_1.c
===
--- testsuite/gcc.target/aarch64/fmul_fcvt_1.c  (revision 241217)
+++ testsuite/gcc.target/aarch64/fmul_fcvt_1.c  (working copy)
@@ -27,13 +27,13 @@ ulsffoo##__a (float x)  \
 }
 
 #define FUNC_DEFD(__a) \
-long   \
+long long  \
 dffoo##__a (double x)  \
 {  \
   return x * __a##.0;  \
 }  \
\
-unsigned long  \
+unsigned long long \
 udffoo##__a (double x) \
 {  \
   return x * __a##.0;  \
@@ -101,18 +101,18 @@ do
\
   __builtin_abort ();  \
 if (usffoo##__a (__b) != (unsigned int)(__b * __a))\
   __builtin_abort ();  \
-if (lsffoo##__a (__b) != (long)(__b * __a))\
+if (lsffoo##__a (__b) != (long long)(__b * __a))   \
   __builtin_abort ();  \
-if (ulsffoo##__a (__b) != (unsigned long)(__b * __a))  \
+if (ulsffoo##__a (__b) != (unsigned long long)(__b * __a)) \
   __builtin_abort ();  \
   } while (0)
 
 #define FUNC_TESTD(__a, __b)   \
 do \
   {\
-if (dffoo##__a (__b) != (long)(__b * __a)) \
+if (dffoo##__a (__b) != (long long)(__b * __a))\
   __builtin_abort ();  \
-if (udffoo##__a (__b) != (unsigned long)(__b * __a))   \
+if (udffoo##__a (__b) != (unsigned long long)(__b * __a))  \
   __builtin_abort ();

[Bug tree-optimization/77938] missing tailcall optimization in case when local variable escapes that goes out of scope before the possible tail call site

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77938

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||59813

--- Comment #4 from Andrew Pinski  ---
Related (maybe a dup really) to PR 59813.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
[Bug 59813] tail-call elimination didn't fire for left-shift of char to cout

Re: [PATCH] Fix PR55152

2016-10-16 Thread Andrew Pinski
On Tue, Oct 4, 2016 at 2:50 AM, Richard Biener  wrote:
> On Tue, 4 Oct 2016, Marc Glisse wrote:
>
>> On Tue, 4 Oct 2016, Richard Biener wrote:
>>
>> > Possibly.  Though then for FP we also want - abs (a) -> copysign (a, -1).
>>
>> I thought this might fix PR 62055, but at least on x86_64, we generate much
>> worse code for copysign(,-1) than for -abs :-(
>
> I would have expected copysign(,-1) to be a simple IOR ...
>
> double foo (double x)
> {
>   return __builtin_copysign (x, -1.);
> }
>
> foo:
> .LFB0:
> .cfi_startproc
> movsd   .LC0(%rip), %xmm1
> movapd  %xmm1, %xmm2
> andpd   .LC2(%rip), %xmm2
> andpd   .LC1(%rip), %xmm0
> orpd%xmm2, %xmm0
> ret
>
> ICK. -fabs (x) yields
>
> foo:
> .LFB0:
> .cfi_startproc
> andpd  .LC0(%rip), %xmm0
> xorpd  .LC1(%rip), %xmm0
> ret
>
> I expected a simple orpd .LC0(%rip), %xmm0 ...

That is recorded already as PR62055 :).

Thanks,
Andrew

>
> Richard.


[Bug ada/67205] eliminate No_Implicit_Dynamic_Code restriction violations

2016-10-16 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #11 from Eric Botcazou  ---
Trampolines are gone on x86, PowerPC and SPARC.  AArch64 and ARM are the next
ones on the list.

[Bug tree-optimization/64031] (un-)conditional execution state is not preserved by PRE/sink

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64031

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

Re: [patch v2] Get rid of stack trampolines for nested functions (0/4)

2016-10-16 Thread Eric Botcazou
> this is the updated version of the patch initially posted at:
>   https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02016.html
> It takes into account Jeff's remarks, both on the code and the
> documentation.
> 
> As discussed, I'm going to split it into 4 parts: common infrastructure, Ada
> front-end bits, individual back-end changes, testsuite.  It was
> bootstrapped and regtested on x86_64-suse-linux but AdaCore has been using
> it on native platforms (Linux, Windows, Solaris, etc) and various
> architectures (x86, PowerPC, SPARC, ARM, etc) for years.

I've installed part #1, #2, #4 and part #3 for x86, PowerPC, SPARC and IA-64.
The PowerPC and SPARC bits as approved, the x86 and IA-64 bits as obvious.

This was tested on x86/Linux, x86-64/Linux, PowerPC/Linux, PowerPC64/Linux, 
IA-64/Linux, SPARC/Solaris and SPARC64/Solaris.

I'll repost the remaining bits for Aarch64, ARM, Alpha, MIPS and HP-PA.

-- 
Eric Botcazou


[Bug ada/37139] DEP prevents using Ada tasking

2016-10-16 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37139

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
At last.

[Bug ada/67205] eliminate No_Implicit_Dynamic_Code restriction violations

2016-10-16 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Sun Oct 16 20:13:32 2016
New Revision: 241222

URL: https://gcc.gnu.org/viewcvs?rev=241222=gcc=rev
Log:
PR ada/37139
PR ada/67205
* common.opt (-ftrampolines): New option.
* doc/invoke.texi (Code Gen Options): Document it.
* doc/tm.texi.in (Trampolines): Add TARGET_CUSTOM_FUNCTION_DESCRIPTORS.
* doc/tm.texi: Regenerate.
* builtins.def: Add init_descriptor and adjust_descriptor.
* builtins.c (expand_builtin_init_trampoline): Do not issue a warning
on platforms with descriptors.
(expand_builtin_init_descriptor): New function.
(expand_builtin_adjust_descriptor): Likewise.
(expand_builtin) : New case.
: Likewise.
* calls.c (prepare_call_address): Remove SIBCALLP parameter and add
FLAGS parameter.  Deal with indirect calls by descriptor and adjust.
Set STATIC_CHAIN_REG_P on the static chain register, if any.
(call_expr_flags): Set ECF_BY_DESCRIPTOR for calls by descriptor.
(expand_call): Likewise.  Move around call to prepare_call_address
and pass all flags to it.
* cfgexpand.c (expand_call_stmt): Reinstate CALL_EXPR_BY_DESCRIPTOR.
* gimple.h (enum gf_mask): New GF_CALL_BY_DESCRIPTOR value.
(gimple_call_set_by_descriptor): New setter.
(gimple_call_by_descriptor_p): New getter.
* gimple.c (gimple_build_call_from_tree): SetCALL_EXPR_BY_DESCRIPTOR.
(gimple_call_flags): Deal with GF_CALL_BY_DESCRIPTOR.
* langhooks.h (struct lang_hooks): Add custom_function_descriptors.
* langhooks-def.h (LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS): Define.
(LANG_HOOKS_INITIALIZER): Add LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS.
* rtl.h (STATIC_CHAIN_REG_P): New macro.
* rtlanal.c (find_first_parameter_load): Skip static chain registers.
* target.def (custom_function_descriptors): New POD hook.
* tree.h (FUNC_ADDR_BY_DESCRIPTOR): New flag on ADDR_EXPR.
(CALL_EXPR_BY_DESCRIPTOR): New flag on CALL_EXPR.
* tree-core.h (ECF_BY_DESCRIPTOR): New mask.
Document FUNC_ADDR_BY_DESCRIPTOR and CALL_EXPR_BY_DESCRIPTOR.
* tree.c (make_node_stat) : Use FUNCTION_ALIGNMENT.
(build_common_builtin_nodes): Initialize init_descriptor and
adjust_descriptor.
* tree-nested.c: Include target.h.
(struct nesting_info): Add 'any_descr_created' field.
(get_descriptor_type): New function.
(lookup_element_for_decl): New function extracted from...
(create_field_for_decl): Likewise.
(lookup_tramp_for_decl): ...here.  Adjust.
(lookup_descr_for_decl): New function.
(convert_tramp_reference_op): Deal with descriptors.
(build_init_call_stmt): New function extracted from...
(finalize_nesting_tree_1): ...here.  Adjust and deal withdescriptors.
* defaults.h (FUNCTION_ALIGNMENT): Define.
(TRAMPOLINE_ALIGNMENT): Set to above instead of FUNCTION_BOUNDARY.
* config/i386/i386.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Define.
* config/ia64/ia64.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise.
* config/rs6000/rs6000.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Likewise.
* config/sparc/sparc.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise.
ada/
* gcc-interface/misc.c (LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS):Define.
* gcc-interface/trans.c (Attribute_to_gnu) : Deal with
a zero TARGET_CUSTOM_FUNCTION_DESCRIPTORS specially for Code_Address.
Otherwise, if TARGET_CUSTOM_FUNCTION_DESCRIPTORS is positive, set
FUNC_ADDR_BY_DESCRIPTOR for 'Access/'Unrestricted_Access of nested
subprograms if the type can use an internal representation.
(call_to_gnu): Likewise, but set CALL_EXPR_BY_DESCRIPTOR on indirect
calls if the type can use an internal representation.

Added:
trunk/gcc/testsuite/gnat.dg/trampoline3.adb
trunk/gcc/testsuite/gnat.dg/trampoline4.adb
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/misc.c
trunk/gcc/ada/gcc-interface/trans.c
trunk/gcc/builtins.c
trunk/gcc/builtins.def
trunk/gcc/calls.c
trunk/gcc/cfgexpand.c
trunk/gcc/common.opt
trunk/gcc/config/i386/i386.h
trunk/gcc/config/ia64/ia64.h
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/sparc/sparc.h
trunk/gcc/defaults.h
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/gimple.c
trunk/gcc/gimple.h
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h
trunk/gcc/rtl.h
trunk/gcc/rtlanal.c
trunk/gcc/target.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree-nested.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug ada/37139] DEP prevents using Ada tasking

2016-10-16 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37139

--- Comment #2 from Eric Botcazou  ---
Author: ebotcazou
Date: Sun Oct 16 20:13:32 2016
New Revision: 241222

URL: https://gcc.gnu.org/viewcvs?rev=241222=gcc=rev
Log:
PR ada/37139
PR ada/67205
* common.opt (-ftrampolines): New option.
* doc/invoke.texi (Code Gen Options): Document it.
* doc/tm.texi.in (Trampolines): Add TARGET_CUSTOM_FUNCTION_DESCRIPTORS.
* doc/tm.texi: Regenerate.
* builtins.def: Add init_descriptor and adjust_descriptor.
* builtins.c (expand_builtin_init_trampoline): Do not issue a warning
on platforms with descriptors.
(expand_builtin_init_descriptor): New function.
(expand_builtin_adjust_descriptor): Likewise.
(expand_builtin) : New case.
: Likewise.
* calls.c (prepare_call_address): Remove SIBCALLP parameter and add
FLAGS parameter.  Deal with indirect calls by descriptor and adjust.
Set STATIC_CHAIN_REG_P on the static chain register, if any.
(call_expr_flags): Set ECF_BY_DESCRIPTOR for calls by descriptor.
(expand_call): Likewise.  Move around call to prepare_call_address
and pass all flags to it.
* cfgexpand.c (expand_call_stmt): Reinstate CALL_EXPR_BY_DESCRIPTOR.
* gimple.h (enum gf_mask): New GF_CALL_BY_DESCRIPTOR value.
(gimple_call_set_by_descriptor): New setter.
(gimple_call_by_descriptor_p): New getter.
* gimple.c (gimple_build_call_from_tree): SetCALL_EXPR_BY_DESCRIPTOR.
(gimple_call_flags): Deal with GF_CALL_BY_DESCRIPTOR.
* langhooks.h (struct lang_hooks): Add custom_function_descriptors.
* langhooks-def.h (LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS): Define.
(LANG_HOOKS_INITIALIZER): Add LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS.
* rtl.h (STATIC_CHAIN_REG_P): New macro.
* rtlanal.c (find_first_parameter_load): Skip static chain registers.
* target.def (custom_function_descriptors): New POD hook.
* tree.h (FUNC_ADDR_BY_DESCRIPTOR): New flag on ADDR_EXPR.
(CALL_EXPR_BY_DESCRIPTOR): New flag on CALL_EXPR.
* tree-core.h (ECF_BY_DESCRIPTOR): New mask.
Document FUNC_ADDR_BY_DESCRIPTOR and CALL_EXPR_BY_DESCRIPTOR.
* tree.c (make_node_stat) : Use FUNCTION_ALIGNMENT.
(build_common_builtin_nodes): Initialize init_descriptor and
adjust_descriptor.
* tree-nested.c: Include target.h.
(struct nesting_info): Add 'any_descr_created' field.
(get_descriptor_type): New function.
(lookup_element_for_decl): New function extracted from...
(create_field_for_decl): Likewise.
(lookup_tramp_for_decl): ...here.  Adjust.
(lookup_descr_for_decl): New function.
(convert_tramp_reference_op): Deal with descriptors.
(build_init_call_stmt): New function extracted from...
(finalize_nesting_tree_1): ...here.  Adjust and deal withdescriptors.
* defaults.h (FUNCTION_ALIGNMENT): Define.
(TRAMPOLINE_ALIGNMENT): Set to above instead of FUNCTION_BOUNDARY.
* config/i386/i386.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Define.
* config/ia64/ia64.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise.
* config/rs6000/rs6000.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS):Likewise.
* config/sparc/sparc.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Likewise.
ada/
* gcc-interface/misc.c (LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS):Define.
* gcc-interface/trans.c (Attribute_to_gnu) : Deal with
a zero TARGET_CUSTOM_FUNCTION_DESCRIPTORS specially for Code_Address.
Otherwise, if TARGET_CUSTOM_FUNCTION_DESCRIPTORS is positive, set
FUNC_ADDR_BY_DESCRIPTOR for 'Access/'Unrestricted_Access of nested
subprograms if the type can use an internal representation.
(call_to_gnu): Likewise, but set CALL_EXPR_BY_DESCRIPTOR on indirect
calls if the type can use an internal representation.

Added:
trunk/gcc/testsuite/gnat.dg/trampoline3.adb
trunk/gcc/testsuite/gnat.dg/trampoline4.adb
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/misc.c
trunk/gcc/ada/gcc-interface/trans.c
trunk/gcc/builtins.c
trunk/gcc/builtins.def
trunk/gcc/calls.c
trunk/gcc/cfgexpand.c
trunk/gcc/common.opt
trunk/gcc/config/i386/i386.h
trunk/gcc/config/ia64/ia64.h
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/sparc/sparc.h
trunk/gcc/defaults.h
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/gimple.c
trunk/gcc/gimple.h
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h
trunk/gcc/rtl.h
trunk/gcc/rtlanal.c
trunk/gcc/target.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree-nested.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

2016-10-16 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-16
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
So ptr_mode vs Pmode mismatch?  If so, the irony is that the implementation as
submitted initially was using Pmode, but was changed upon explicit request:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00418.html

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

2016-10-16 Thread Bernd Edlinger
On 10/06/16 16:11, Bernd Edlinger wrote:
> Hi!
>
> Currently C++ does not warn at all when built-in functions are
> re-defined with a different signature, while C does warn on that
> even without -Wall.
>
> Thus I'd like to propose a -Wall enabled warning for that in C++ only.
>
> Initially I tried to warn unconditionally but that made too  many tests
> in the C++ testsuite emit that warning :-(
>
> So making the warning dependent on -Wall is a compromise due
> to the very many compile only tests, that use this "feature".
>
> There is also a wrong-code side on this redefinition, because
> even if the new function has the nothrow attribute the code is
> generated as if it could throw.  Fixed as well.
>
> This is an updated version of the patch that was posted
> here: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01463.html
> ... but got no response so far.
>
> I have seen a few warnings in system headers, when -Wsystem-headers
> is used, and fixed most of them, for instance strftime got a
> redefinition warning, because the const struct tm* parameter has to be
> handled as the FILE* in other builtin functions.
>
> As a little surprise, it turned out, there were warnings missing
> from strftime in C due to the type conflict when merging the builtin
> with the actual declaration, see the format warnings in the test case
> testsuite/g++.dg/pr71973-2.C, which were not working previously in C++.
>
> Then there are cases, where a builtin function and C++ overloads
> have the same name like the abs function from cstdlib.  Due to
> missing strictness in duplicate_decls the builtin got merged with
> one of the C++ overloads.  That was visible due to the new warning.
>
> I believe a builtin function always needs an extern "C" declaration.
> Additional C++ overloads are possible, but do not redefine the builtin
> function, and create additional overloads.
>
> However these warnings remain, and I have no idea if the header
> file is correct or the warning:
>
> /usr/include/unistd.h:551:12: warning: declaration of 'int execve(const
> char*, char* const*, char* const*)' conflicts with built-in declaration
> 'int execve(const char*, const char**, const char**)'
> [-Wbuiltin-function-redefined]
>  extern int execve (const char *__path, char *const __argv[],
> ^~
> /usr/include/unistd.h:563:12: warning: declaration of 'int execv(const
> char*, char* const*)' conflicts with built-in declaration 'int
> execv(const char*, const char**)' [-Wbuiltin-function-redefined]
>  extern int execv (const char *__path, char *const __argv[])
> ^
> /usr/include/unistd.h:578:12: warning: declaration of 'int execvp(const
> char*, char* const*)' conflicts with built-in declaration 'int
> execvp(const char*, const char**)' [-Wbuiltin-function-redefined]
>  extern int execvp (const char *__file, char *const __argv[])
> ^~
>
> Interesting is that, these do not happen with -std=c++03/11/14 but only
> with -std=gnu++03/11/14.  I could not figure out how to resolve that.
>
> As said, this is only visible with -Wsystem-headers, and would not
> happen, if the declaration in unistd.h would match the builtin function
> prototype.
>

Just in case anybody wants to know, I digged into the warnings
about execv/e/p, and found the following:


First these builtins are declared with DEF_EXT_LIB_BUILTIN, and thus
the builtin function without __builtin_ in the name is only visible with
gnu extensions, therefore the warning does not happen with -std=c++XX
only with -std=gnu++XX.

Second, the declaration in the glibc header files simply look wrong,
because the type of argv, and envp is "char *const *" while the
builtin function wants "const char**", thus only the array of char*
itself is const, not the actual char stings they point to.

Third, in C the  builtins are not diagnosed, because C does only look
at the mode of the parameters see match_builtin_function_types in
c/c-decl.c, which may itself be wrong, because that makes an ABI
decision dependent on the mode of the parameter.

What was broken, because of that mismatch?

Except the missing warning about the redeclared builtin function, there
was also some hidden bug in the execv-builtins:

That is with -fprofile-arcs the execv/e/p is not replaced
with a call to __gcov_execv/e/p, and thus if a C++ program is
left through one of these functions the profile information is
not saved.

This is not fixed with the patch as is:

It would of course be fixed by changing the glibc headers, or if it
turns out that the GCC built-in is actually using the wrong prototype
that would also be possible to fix.

Any ideas which way to go on here?

Maybe a new fix-include rule?


Thanks
Bernd.


Re: [Ada] Set Always_Compatible_Rep to False everywhere

2016-10-16 Thread Eric Botcazou
> Can this be refactored to avoid having to duplicate the whole file for
> every target?

I'm not sure, maybe entries could be omitted if they match the default though.

-- 
Eric Botcazou


[SPARC] Do not create bogus CONST_VECTORs

2016-10-16 Thread Eric Botcazou
The compiler was creating bogus CONST_VECTORs under specific circumstances in 
sparc_expand_vector_init.  Fixed by using the same test as the x86 back-end.

Tested on SPARC/Solaris, applied on all active branches.


2016-10-16  Eric Botcazou  

* config/sparc/sparc.c (sparc_expand_vector_init): Only accept literal
constants in CONST_VECTORs.

-- 
Eric BotcazouIndex: config/sparc/sparc.c
===
--- config/sparc/sparc.c	(revision 241205)
+++ config/sparc/sparc.c	(working copy)
@@ -12366,14 +12366,13 @@ sparc_expand_vector_init (rtx target, rt
   const machine_mode inner_mode = GET_MODE_INNER (mode);
   const int n_elts = GET_MODE_NUNITS (mode);
   int i, n_var = 0;
-  bool all_same;
+  bool all_same = true;
   rtx mem;
 
-  all_same = true;
   for (i = 0; i < n_elts; i++)
 {
   rtx x = XVECEXP (vals, 0, i);
-  if (!CONSTANT_P (x))
+  if (!(CONST_SCALAR_INT_P (x) || CONST_DOUBLE_P (x) || CONST_FIXED_P (x)))
 	n_var++;
 
   if (i > 0 && !rtx_equal_p (x, XVECEXP (vals, 0, 0)))


[Bug target/78002] New: gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002

Bug ID: 78002
   Summary: gcc.target/aarch64/stack-checking.c ICEs with
-mabi=ilp32
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

apinski@apinski-ss1:~/src/local4$ ./tools/bin/gcc -fstack-check
gcc/gcc/testsuite/gcc.target/aarch64/stack-checking.c  -mabi=ilp32
gcc/gcc/testsuite/gcc.target/aarch64/stack-checking.c: In function ‘main’:
gcc/gcc/testsuite/gcc.target/aarch64/stack-checking.c:21:1: internal compiler
error: in plus_constant, at explow.c:88
 }
 ^
0x7fbcdf plus_constant(machine_mode, rtx_def*, long, bool)
../../gcc/gcc/explow.c:88
0xe5d63f aarch64_emit_probe_stack_range
../../gcc/gcc/config/aarch64/aarch64.c:2575
0xe6253f aarch64_expand_prologue()
../../gcc/gcc/config/aarch64/aarch64.c:3216
0xfba47b gen_prologue()
../../gcc/gcc/config/aarch64/aarch64.md:551
0xe5cc83 target_gen_prologue
../../gcc/gcc/config/aarch64/aarch64.md:5584
0x886577 make_prologue_seq
../../gcc/gcc/function.c:5810
0x886797 thread_prologue_and_epilogue_insns()
../../gcc/gcc/function.c:5927
0x886dfb rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6396
0x886dfb execute
../../gcc/gcc/function.c:6438
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/77991] ICE on x32 in plus_constant, at explow.c:87

2016-10-16 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77991

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from Uroš Bizjak  ---
HJ, can you please test the proposed patch on x32?

[Bug target/77991] ICE on x32 in plus_constant, at explow.c:87

2016-10-16 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77991

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #2 from Uroš Bizjak  ---
Created attachment 39819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39819=edit
Proposed patch

Patch that adds missing conversion to Pmode.

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

2016-10-16 Thread Eric Botcazou
> 2016-10-11  Eric Botcazou  
> 
>   * tree.h (build_complex_type): Add second parameter with default.
>   * tree.c (build_complex_type): Add NAMED second parameter and adjust
>   recursive call.  Create a TYPE_DECL only if NAMED is true.
>   (build_common_tree_nodes): Pass true in calls to build_complex_type.

May I backport it to the 6 branch?  It fixes the bootstrap comparison failure 
on x86-64/Solaris reported under PR bootstrap/77995 (x86-64 has patterns for 
unsigned arithmetic overflow checking on the 6 branch too).

-- 
Eric Botcazou


[Bug fortran/77915] [6 Regression] Internal error for matmul() in forall with optimization

2016-10-16 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77915

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Fixed on all affected branches, closing.

[Bug fortran/77915] [6 Regression] Internal error for matmul() in forall with optimization

2016-10-16 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77915

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Oct 16 18:16:29 2016
New Revision: 241217

URL: https://gcc.gnu.org/viewcvs?rev=241217=gcc=rev
Log:
2016-10-16  Thomas Koenig  

Backport from trunk
PR fortran/77915
* frontend-passes.c (inline_matmul_assign):  Return early if
inside a FORALL statement.

2016-10-16  Thomas Koenig  

Backport from trunk
PR fortran/77915
* gfortran.dg/matmul_11.f90:  New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/matmul_11.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/frontend-passes.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-16 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996

--- Comment #11 from Yichao Yu  ---
The case pointed out is fixed in https://reviews.llvm.org/rL284336 although as
expected that doesn't fix the error. Still not sure whose bug is this...

[Bug testsuite/64886] FAIL: gcc.dg/pr64434.c scan-rtl-dump-times expand "Swap operands" 1

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64886

Andrew Pinski  changed:

   What|Removed |Added

 Target|hppa*-*-hpux*   |hppa*-*-hpux*
   ||aarch64_ilp32-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-16
  Component|rtl-optimization|testsuite
   Host|hppa*-*-hpux*   |
 Ever confirmed|0   |1
  Build|hppa*-*-hpux*   |

--- Comment #5 from Andrew Pinski  ---
Same as reason on aarch64 ILP32.

Confirmed.

[Bug c++/78001] [7 Regression] ncurses build error

2016-10-16 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78001

--- Comment #5 from Markus Trippelsdorf  ---
Well,

markus@x4 ~ % clang++ -c n.ii
n.ii:6:24: error: member function 'm_fn1' not viable: 'this' argument has type
'const B', but function is not marked const
  void m_fn2() const { m_fn1(); }
   ^
n.ii:3:8: note: 'm_fn1' declared here
  void m_fn1();
   ^
1 error generated.

is clear immediately.

[Bug target/77897] Compile error with KNL & -O3 for GTC code

2016-10-16 Thread longb at cray dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897

--- Comment #3 from Bill Long  ---
It would appear the customer system has

> /usr/bin/as --version
GNU assembler (GNU Binutils; SUSE Linux Enterprise 12) 2.25.0

[Bug c++/78001] [7 Regression] ncurses build error

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78001

--- Comment #4 from Andrew Pinski  ---
(In reply to Markus Trippelsdorf from comment #3)
> And the error message is horrible.

The only part of the error message which seems really horrible is the
"" part which is related to bug 54948 (there seems like
there are others too).

[Bug c++/78001] [7 Regression] ncurses build error

2016-10-16 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78001

--- Comment #3 from Markus Trippelsdorf  ---
And the error message is horrible.

[Bug c++/78001] [7 Regression] ncurses build error

2016-10-16 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78001

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #1)

I guess you are right. There must be some dups somewhere, but I cannot 
find them ATM.

[Bug c++/78001] [7 Regression] ncurses build error

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78001

--- Comment #1 from Andrew Pinski  ---
So I think GCC is correct here.  A is a non-dependent base so it can be looked
at definition time.  m_fn1 is not a const qualified either.

Does other compiler reject:
class A {
protected:
  void m_fn1();
};
struct B : A {
  void m_fn2() const { m_fn1(); }
};


How about:
class A {
protected:
  void m_fn1();
};
template  struct B : A {
  void m_fn2() const { m_fn1(); }
};

B a;
void f(void) { a.m_fn2(); }

[Bug tree-optimization/64322] More optimize opportunity for constant folding

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

Re: [Patch, fortran] Implement inquire(iolength= ) for DTIO

2016-10-16 Thread Dominique d'Humières
Forget it! It seems that I did not apply the patch!-(

Sorry for the noise.

Dominique

> Le 16 oct. 2016 à 18:42, Dominique d'Humières  a écrit :
> 
> Dear Jerry,
> 
>> The new test fails unless I replace 64 with 16 in 'if (rl.ne.64) call 
>> abort’. This seems consistent with your comment
> 
> I have not been clear enough: I have to replace 64 with 16 even with your 
> patch.
> 
> Dominique
> 



[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

2016-10-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298

--- Comment #27 from Jerry DeLisle  ---
The patch in comment 26 addressed the behavior of inquire(iolength= ) when
derived types with User Defined procedures are in the Output List.

The only other case I see not addressed yet is the size= specifier in input
statements. I do not see where the Standards specifically address this for User
Defined. Should it behave similar to IOLENGTH or try to accumulate the size
from all child procedures?

Re: [Patch, fortran] Implement inquire(iolength= ) for DTIO

2016-10-16 Thread Dominique d'Humières
Dear Jerry,

> The new test fails unless I replace 64 with 16 in 'if (rl.ne.64) call abort’. 
> This seems consistent with your comment

I have not been clear enough: I have to replace 64 with 16 even with your patch.

Dominique



[Bug c++/78001] [7 Regression] ncurses build error

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78001

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |7.0

[Bug sanitizer/64354] no preprocessor symbol __SANITIZE_THREAD__

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed.

[Bug c++/78001] New: [7 Regression] ncurses build error

2016-10-16 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78001

Bug ID: 78001
   Summary: [7 Regression] ncurses build error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 tmp % cat cursesf.ii
class A {
protected:
  void m_fn1();
};
template  struct B : A {
  void m_fn2() const { m_fn1(); }
};

markus@x4 tmp % icpc -c cursesf.ii
markus@x4 tmp % clang++ -c cursesf.ii
markus@x4 tmp % g++-6 -c cursesf.ii
markus@x4 tmp % g++ -c cursesf.ii
cursesf.ii: In member function ‘void B<  >::m_fn2()
const’:
cursesf.ii:6:30: error: no matching function for call to ‘B<
 >::m_fn1() const’
   void m_fn2() const { m_fn1(); }
  ^
cursesf.ii:3:8: note: candidate: void A::m_fn1() 
   void m_fn1();
^
cursesf.ii:3:8: note:   passing ‘const B<  >*’ as
‘this’ argument discards qualifiers

[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

2016-10-16 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298

--- Comment #26 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Oct 16 16:29:46 2016
New Revision: 241216

URL: https://gcc.gnu.org/viewcvs?rev=241216=gcc=rev
Log:
2016-10-16  Jerry DeLisle  

PR fortran/48298
* trans-io.c (transfer_expr): Ignore dtio procedures for inquire
with iolength.

* gfortran.dg/dtio_16.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog

[RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

2016-10-16 Thread Shea Levy
Hello GCC and Clang devs!

Unlike the traditional approach of installing system libraries into one
central location like /usr/{lib,include}, the nix package manager [1]
installs each package into it's own prefix
(e.g. /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev). Moreover,
each package is built in its own environment determined from its
explicitly listed dependencies, regardless of what else is installed on
the system. Because not all package build scripts properly respect
CFLAGS etc., we currently wrap the compiler [2] to respect custom
environment variables like NIX_CFLAGS_COMPILE, so during the build of a
package that depends on zlib and Xlib might have NIX_CFLAGS_COMPILE set
to "-isystem 
/nix/store/bl0rz2xinsm9yslghd7n5vaba86zxknh-libX11-1.6.3-dev/include -isystem 
/nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev/include".

Unfortunately, as you can see if you click through the link or look
through the git history, the wrapper is quite complex (frankly, hacky)
and has evolved mostly through trial and error. Moreover, it's known to
break things like response files [3] and is generally speaking a source
of frustration. I believe the situation would be much improved if gcc
and clang supported some form of "environment-specific" configuration,
either through environment variables or, if absolutely necessary,
command line flags that can be passed unconditionally (note, for
example, that we currently parse the cc command line to see if we're
going to do any linking before deciding to pass in linking-specific
options) and clearly have the semantics we want. Ideally we would be
able to specify something on the level of abstraction of "this directory
should be treated like you would normally treat /usr" and get
e.g. /include, /lib, frameworks on OS X, etc. handled properly.

Would patches aimed at achieving this be considered for inclusion
upstream? My current thought for a first step would be an environment
variable specifying a file with command line flags that are ignored by
the compiler driver in contexts where they are inapplicable or
overridden by other command line flags, but I'm definitely open to
guidance on how this should best be achieved from your perspective. I'm
happy to do the work needed to get this in place if there is interest,
please let me know!

Thanks,
Shea Levy

[1]: https://nixos.org/nix
[2]: 
https://github.com/NixOS/nixpkgs/blob/8cbdd9d0c290e294a9d783c8868e738db05c9ce2/pkgs/build-support/cc-wrapper/cc-wrapper.sh
[3]: 
https://github.com/NixOS/nixpkgs/commit/a421e7bd4a28c69bded8b17888325e31554f61a1


signature.asc
Description: PGP signature


[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

2016-10-16 Thread kjlu at gatech dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992

--- Comment #13 from Kangjie Lu  ---
(In reply to jos...@codesourcery.com from comment #10)
> If you care about information in bytes that are not part of a field with 
> other semantic significance, you should use -Werror=padded to get errors 
> on structs with padding and use that information to add explicit dummy 
> fields in the source code where there was padding.  Once there are 
> explicit dummy fields, their values will be preserved by the compiler, so 
> you can either zero the whole struct with memset and rely on the zeroing 
> of dummy fields not being optimized away, or use a struct initializer and 
> rely on it implicitly zeroing those fields.  (Of course this may reduce 
> efficiency as optimizations such as SRA now need to track values of those 
> fields, whereas they do not need to track values of padding.)

This is a candidate solution, but I think it cannot scale.  
Given that the Linux kernel has tens of thousands of modules, the idea of 
manually initializing padding bytes for all data structures will be definitely 
declined by the Linux community. 

My opinion is still that, as padding is introduced by compilers and is 
"invisible" to developers, initializing padding should be done by on the 
compiler side.

[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

2016-10-16 Thread kjlu at gatech dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992

--- Comment #12 from Kangjie Lu  ---
(In reply to Andreas Schwab from comment #11)
> The problem with that strategy is that padding is architecture dependent,
> and care must be taken not to introduce ABI breakage.

Agreed. Or a developer will have to write corresponding dummy fields for 
various platforms, which will be annoying for code maintenance.

Re: [Ada] Set Always_Compatible_Rep to False everywhere

2016-10-16 Thread Andreas Schwab
On Okt 16 2016, Eric Botcazou  wrote:

>   * system-aix.ads (Always_Compatible_Rep): Change to False.
>   * system-aix64.ads (Always_Compatible_Rep): Likewise.
>   * system-hpux-ia64.ads (Always_Compatible_Rep): Likewise.
>   * system-hpux.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-alpha.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-hppa.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-ia64.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-mips.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-mips64el.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-mipsel.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-s390.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-s390x.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-sh4.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-sparc.ads (Always_Compatible_Rep): Likewise.
>   * system-linux-sparcv9.ads (Always_Compatible_Rep): Likewise.
>   * system-rtems.ads (Always_Compatible_Rep): Likewise.

Can this be refactored to avoid having to duplicate the whole file for
every target?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

2016-10-16 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992

--- Comment #11 from Andreas Schwab  ---
The problem with that strategy is that padding is architecture dependent, and
care must be taken not to introduce ABI breakage.

[Bug c/78000] New: -Wimplicit-function-declaration inhibited with macro from system headers

2016-10-16 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78000

Bug ID: 78000
   Summary: -Wimplicit-function-declaration inhibited with macro
from system headers
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

i/a.h:
#define foo bar

x.c:
#include 
int main(){
  foo(42);
}

$ gcc x.c -isystem i -c
$ gcc x.c -I i -c
In file included from x.c:1:0:
x.c: In function ‘main’:
i/a.h:1:13: warning: implicit declaration of function ‘bar’
[-Wimplicit-function-declaration]
 #define foo bar
 ^
x.c:4:3: note: in expansion of macro ‘foo’
   foo(42);
   ^~~

This problem occurs for instance with GMP headers (installed by the
distribution in /usr/include) that have
#define mpf_out_str __gmpf_out_str
but only declare the function if stdio.h was included first. Users don't get
any indication that they are using an undeclared function.
http://stackoverflow.com/q/40069876/1918193

At least in this case, it seems that it would be better to use the location of
'foo(42)' to determine if the issue is in a system header or not. Are there
cases where the current behavior is preferred?

[Ada] Set Always_Compatible_Rep to False everywhere

2016-10-16 Thread Eric Botcazou
It's not clear why this was set to True in some configuration files.

Applied on the mainline.


2016-10-16  Eric Botcazou  

* system-aix.ads (Always_Compatible_Rep): Change to False.
* system-aix64.ads (Always_Compatible_Rep): Likewise.
* system-hpux-ia64.ads (Always_Compatible_Rep): Likewise.
* system-hpux.ads (Always_Compatible_Rep): Likewise.
* system-linux-alpha.ads (Always_Compatible_Rep): Likewise.
* system-linux-hppa.ads (Always_Compatible_Rep): Likewise.
* system-linux-ia64.ads (Always_Compatible_Rep): Likewise.
* system-linux-mips.ads (Always_Compatible_Rep): Likewise.
* system-linux-mips64el.ads (Always_Compatible_Rep): Likewise.
* system-linux-mipsel.ads (Always_Compatible_Rep): Likewise.
* system-linux-s390.ads (Always_Compatible_Rep): Likewise.
* system-linux-s390x.ads (Always_Compatible_Rep): Likewise.
* system-linux-sh4.ads (Always_Compatible_Rep): Likewise.
* system-linux-sparc.ads (Always_Compatible_Rep): Likewise.
* system-linux-sparcv9.ads (Always_Compatible_Rep): Likewise.
* system-rtems.ads (Always_Compatible_Rep): Likewise.

-- 
Eric BotcazouIndex: system-aix64.ads
===
--- system-aix64.ads	(revision 241147)
+++ system-aix64.ads	(working copy)
@@ -7,7 +7,7 @@
 -- S p e c  --
 --   (PPC/AIX64 Version)--
 --  --
---  Copyright (C) 2009-2015, Free Software Foundation, Inc. --
+--  Copyright (C) 2009-2016, Free Software Foundation, Inc. --
 --  --
 -- This specification is derived from the Ada Reference Manual for use with --
 -- GNAT. The copyright notice above, and the license provisions that follow --
@@ -148,7 +148,7 @@ private
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;
-   Always_Compatible_Rep : constant Boolean := True;
+   Always_Compatible_Rep : constant Boolean := False;
Suppress_Standard_Library : constant Boolean := False;
Use_Ada_Main_Program_Name : constant Boolean := False;
Frontend_Exceptions   : constant Boolean := False;
Index: system-aix.ads
===
--- system-aix.ads	(revision 241147)
+++ system-aix.ads	(working copy)
@@ -7,7 +7,7 @@
 -- S p e c  --
 --(AIX/PPC Version) --
 --  --
---  Copyright (C) 1992-2015, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2016, Free Software Foundation, Inc. --
 --  --
 -- This specification is derived from the Ada Reference Manual for use with --
 -- GNAT. The copyright notice above, and the license provisions that follow --
@@ -148,7 +148,7 @@ private
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;
-   Always_Compatible_Rep : constant Boolean := True;
+   Always_Compatible_Rep : constant Boolean := False;
Suppress_Standard_Library : constant Boolean := False;
Use_Ada_Main_Program_Name : constant Boolean := False;
Frontend_Exceptions   : constant Boolean := False;
Index: system-hpux.ads
===
--- system-hpux.ads	(revision 241147)
+++ system-hpux.ads	(working copy)
@@ -7,7 +7,7 @@
 -- S p e c  --
 -- (HP-UX Version)  --
 --  --
---  Copyright (C) 1992-2015, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2016, Free Software Foundation, Inc. --
 --  --
 -- This specification is derived from the Ada Reference Manual for use with --
 -- GNAT. The copyright notice above, and the license provisions that follow --
@@ -138,7 +138,7 @@ private
Support_Composite_Assign  : constant Boolean := True;
Support_Composite_Compare : constant Boolean := True;
Support_Long_Shifts   : constant Boolean := True;
-   Always_Compatible_Rep : constant Boolean := True;
+   Always_Compatible_Rep : constant Boolean := 

[Bug bootstrap/77995] [6 regression] bootstrap comparison failure on x86-64/Solaris

2016-10-16 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77995

Eric Botcazou  changed:

   What|Removed |Added

 Target|solaris |x86_64-sun-solaris2.*
 Status|WAITING |ASSIGNED
  Known to work||5.4.1
   Host||x86_64-sun-solaris2.*
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|gcc 6.2.0 failed on |[6 regression] bootstrap
   |somparison stage 2 & 3  |comparison failure on
   ||x86-64/Solaris
   Target Milestone|--- |6.3
  Known to fail||6.2.1
  Build||x86_64-sun-solaris2.*

--- Comment #7 from Eric Botcazou  ---
> thanks a lot for proposed patch - i can confirm: it fixed my problem with
> bootstrap on Intel.

Great, thanks for reporting back.

> next step will be - try to test in SPARC :) (i have T5220).

SPARC should bootstrap with or without the patch.

[Bug c/77992] Failures to initialize padding bytes -- causing many information leaks

2016-10-16 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992

--- Comment #10 from joseph at codesourcery dot com  ---
If you care about information in bytes that are not part of a field with 
other semantic significance, you should use -Werror=padded to get errors 
on structs with padding and use that information to add explicit dummy 
fields in the source code where there was padding.  Once there are 
explicit dummy fields, their values will be preserved by the compiler, so 
you can either zero the whole struct with memset and rely on the zeroing 
of dummy fields not being optimized away, or use a struct initializer and 
rely on it implicitly zeroing those fields.  (Of course this may reduce 
efficiency as optimizations such as SRA now need to track values of those 
fields, whereas they do not need to track values of padding.)

Re: [v3 PATCH] Make sure the return value of malloc_allocator::allocate is zero-initialized so that checking it for non-zero works later.

2016-10-16 Thread Jonathan Wakely

On 15/10/16 23:44 +0300, Ville Voutilainen wrote:

On 15 October 2016 at 22:44, Ville Voutilainen
 wrote:

2016-10-15  Ville Voutilainen  

Make sure the return value of malloc_allocator::allocate
is zero-initialized so that checking it for non-zero works
later.
* include/ext/malloc_allocator.h (malloc_allocator::allocate):
Initialize the return value.


A new patch, with small sanity tests added.

2016-10-15  Ville Voutilainen  

   Make sure the return value of malloc_allocator::allocate
   is zero-initialized so that checking it for non-zero works
   later.
   * include/ext/malloc_allocator.h (malloc_allocator::allocate):
   Initialize the return value.
   * testsuite/ext/malloc_allocator/sanity.cc: New.


Oops, thanks for catching that. OK for trunk.


[Bug c++/77999] New: GCC leaks system header diagnostic about reserved names.

2016-10-16 Thread eric at efcs dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77999

Bug ID: 77999
   Summary: GCC leaks system header diagnostic about reserved
names.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:
// g++ -std=c++14 -Werror test.cpp
#include 
using std::chrono::operator ""h; // error emitted on this line.
// {{error: literal operator suffixes not preceded by '_' are reserved for
future standardization}}

Re: [PATCH] rs6000: Fix shrink-wrap-separate for AIX

2016-10-16 Thread David Edelsohn
On Sat, Oct 15, 2016 at 2:16 PM, Segher Boessenkool
 wrote:
> On Sat, Oct 15, 2016 at 07:55:47AM -0400, David Edelsohn wrote:
>> Maybe rs6000 always should prefer inline save-restore when SWS is
>> enabled, except for optimize_size?
>
> Yes, that would be a good optimization probably.
>
> try_shrink_wrapping_separate already does nothing unless you have
> optimize_function_for_speed_p (cfun), so that will do what you want
> already.

Maybe something like the following:

* config/rs6000/rs6000.c (rs6000_savres_strategy) [AIX,ELFv2]: Inline
FPR save and restore if shrink-wrapping and not optimizing for size.

Index: rs6000.c
===
--- rs6000.c(revision 241210)
+++ rs6000.c(working copy)
@@ -25445,7 +25445,8 @@
   else
 {
   gcc_checking_assert (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2);
-  if (info->first_fp_reg_save > 61)
+  if ((!optimize_size && flag_shrink_wrap_separate)
+ || info->first_fp_reg_save > 61)
strategy |= SAVE_INLINE_FPRS | REST_INLINE_FPRS;
   strategy |= SAVE_INLINE_GPRS | REST_INLINE_GPRS;
   strategy |= SAVE_INLINE_VRS | REST_INLINE_VRS;

Thanks, David


[Bug bootstrap/77995] gcc 6.2.0 failed on somparison stage 2 & 3

2016-10-16 Thread ikozhukhov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77995

--- Comment #6 from Igor Kozhukhov  ---
(In reply to Eric Botcazou from comment #4)
> If BUILD_CONFIG is empty, then a possible fix is at:
>   https://gcc.gnu.org/ml/gcc-cvs/2016-10/msg00278.html

thanks a lot for proposed patch - i can confirm: it fixed my problem with
bootstrap on Intel.
next step will be - try to test in SPARC :) (i have T5220).
i'll reply to this bug or open new if it failed.

PATCH to tidy up code in c-warn.c

2016-10-16 Thread Marek Polacek
Found when looking at something else.  find_array_ref_with_const_idx_r would
uselessly keep on looking for other array refs with constant indices, even
though finding one is enough.  So return when something is found, instead of
just ignoring the subtrees.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2016-10-16  Marek Polacek  

* c-warn.c (find_array_ref_with_const_idx_r): Remove parameter names.
Return immediately when finding a match.
(warn_tautological_cmp): Remove a boolean variable that is no longer
needed.

diff --git gcc/c-family/c-warn.c gcc/c-family/c-warn.c
index 88544ce..904f6d3 100644
--- gcc/c-family/c-warn.c
+++ gcc/c-family/c-warn.c
@@ -256,17 +256,14 @@ warn_logical_operator (location_t location, enum 
tree_code code, tree type,
with constant indices.  */
 
 static tree
-find_array_ref_with_const_idx_r (tree *expr_p, int *walk_subtrees, void *data)
+find_array_ref_with_const_idx_r (tree *expr_p, int *, void *)
 {
   tree expr = *expr_p;
 
   if ((TREE_CODE (expr) == ARRAY_REF
|| TREE_CODE (expr) == ARRAY_RANGE_REF)
   && TREE_CODE (TREE_OPERAND (expr, 1)) == INTEGER_CST)
-{
-  *(bool *) data = true;
-  *walk_subtrees = 0;
-}
+return integer_type_node;
 
   return NULL_TREE;
 }
@@ -312,10 +309,8 @@ warn_tautological_cmp (location_t loc, enum tree_code 
code, tree lhs, tree rhs)
 {
   /* Don't warn about array references with constant indices;
 these are likely to come from a macro.  */
-  bool found = false;
-  walk_tree_without_duplicates (, find_array_ref_with_const_idx_r,
-   );
-  if (found)
+  if (walk_tree_without_duplicates (, find_array_ref_with_const_idx_r,
+   NULL))
return;
   const bool always_true = (code == EQ_EXPR || code == LE_EXPR
|| code == GE_EXPR || code == UNLE_EXPR

Marek


[Bug target/77991] ICE on x32 in plus_constant, at explow.c:87

2016-10-16 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77991

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-16
 CC||marxin at gcc dot gnu.org
Summary|[7 Regression] ICE on x32   |ICE on x32 in
   |in plus_constant, at|plus_constant, at
   |explow.c:87 |explow.c:87
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 4.8.0.

[Bug tree-optimization/77988] [7 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: verify_gimple failed

2016-10-16 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77988

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-16
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r241021.

[Bug c++/51392] Wrong code with -Os when __attribute__((__const__)) function returns structure

2016-10-16 Thread cyp561 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51392

--- Comment #4 from cyp561 at gmail dot com ---
Is there any case in which a function returning a structure may not elide the
return value copy to being passed by invisible reference?

If not, I think it is either a bug that the code fails, or a bug that the C++
frontend allows __attribute__((__const__)) on any function which returns a
structure.

It seems strange to me that __attribute__((__const__)) doesn't work in cases
where constexpr does work, since I thought constexpr is a now-standard version
of __attribute__((__const__)).

Re: [Patch, fortran] Implement inquire(iolength= ) for DTIO

2016-10-16 Thread Dominique d'Humières
Dear Jerry,

The new test fails unless I replace 64 with 16 in 'if (rl.ne.64) call abort’. 
This seems consistent with your comment

> The language seems a little obscure. I think the first sentence means
> don't expect inquire to use a UDDTIO procedure and the second sentence
> says when you use a derived type that has UDDTIO procedures
> in the output list, treat them as if they don't and use the default derived 
> type lengths.

The end of the line

  inquire(iolength=rl) rl, kl, chairman, rl, chairman, t;

looks suspicious. Should nit be

  inquire(iolength=rl) rl, kl, chairman, rl, chairman, tl

?

TIA

Dominique



Re: RFC [1/3] divmod transform v2

2016-10-16 Thread Prathamesh Kulkarni
On 16 October 2016 at 11:29, Prathamesh Kulkarni
 wrote:
> Hi,
> After approval from Bernd Schmidt, I committed the patch to remove
> optab functions for
> sdivmod_optab and udivmod_optab in optabs.def, which removes the block
> for divmod patch.
>
> This patch is mostly the same as previous one, except it drops
> targeting __udivmoddi4() because
> it gave undefined reference link error for calling __udivmoddi4() on
> aarch64-linux-gnu.
> It appears aarch64 has hardware insn for DImode div, so __udivmoddi4()
> isn't needed for the target
> (it was a bug in my patch that called __udivmoddi4() even though
> aarch64 supported hardware div).
>
> However this makes me wonder if it's guaranteed that __udivmoddi4()
> will be available for a target if it doesn't have hardware div and
> divmod insn and doesn't have target-specific libfunc for
> DImode divmod ? To be conservative, the attached patch doesn't
> generate call to __udivmoddi4.
>
> Passes bootstrap+test on x86_64-unknown-linux.
> Cross-tested on arm*-*-*, aarch64*-*-*.
> Verified that there are no regressions with SPEC2006 on
I mean no regressions from correctness perspective, I didn't benchmark
the patch.
> x86_64-unknown-linux-gnu.
> OK to commit ?
>
> Thanks,
> Prathamesh


[Bug target/59558] [MSP430-gcc] CPU setup, pre start program

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59558

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Invalid then .

[Bug other/64184] error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function)

2016-10-16 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64184

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Has this been fixed in a newer version of GCC like say 5.4.0?

[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=

2016-10-16 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #11 from Janne Blomqvist  ---
Fixed on trunk, closing.

[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=

2016-10-16 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587

--- Comment #10 from Janne Blomqvist  ---
Author: jb
Date: Sun Oct 16 06:28:15 2016
New Revision: 241211

URL: https://gcc.gnu.org/viewcvs?rev=241211=gcc=rev
Log:
PR 48587 Newunit allocator, cleanup

Improve error message, and remove a redundant check, as the same check is
done a bit earlier due to the PR 48587 patch.

2016-10-16  Janne Blomqvist  

PR libfortran/48587
* io/transfer.c (data_transfer_init): Improve error message,
remove redundant check.

Regtested on x86_64-pc-linux-gnu.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[PATCH, libfortran] PR 48587 Newunit allocator, cleanup

2016-10-16 Thread Janne Blomqvist
Improve error message, and remove a redundant check, as the same check is
done a bit earlier due to the PR 48587 patch.

2016-10-16  Janne Blomqvist  

PR libfortran/48587
* io/transfer.c (data_transfer_init): Improve error message,
remove redundant check.

Regtested on x86_64-pc-linux-gnu. Committed as obvious.
---
 libgfortran/io/transfer.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 7696cca..2232417 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -2606,7 +2606,8 @@ data_transfer_init (st_parameter_dt *dtp, int read_flag)
   /* This means we tried to access an external unit < 0 without
 having opened it first with NEWUNIT=.  */
   generate_error (>common, LIBERROR_BAD_OPTION,
- "Invalid unit number in statement");
+ "Unit number is negative and unit was not already "
+ "opened with OPEN(NEWUNIT=...)");
   return;
 }
   else if (dtp->u.p.current_unit->s == NULL)
@@ -2614,14 +2615,6 @@ data_transfer_init (st_parameter_dt *dtp, int read_flag)
st_parameter_open opp;
unit_convert conv;
 
-  if (dtp->common.unit < 0 && !is_internal_unit (dtp))
-   {
- close_unit (dtp->u.p.current_unit);
- dtp->u.p.current_unit = NULL;
- generate_error (>common, LIBERROR_BAD_OPTION,
- "Bad unit number in statement");
- return;
-   }
   memset (_flags, '\0', sizeof (u_flags));
   u_flags.access = ACCESS_SEQUENTIAL;
   u_flags.action = ACTION_READWRITE;
-- 
2.7.4



[Bug libstdc++/77998] New: clang rejects std::thread from trunk

2016-10-16 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77998

Bug ID: 77998
   Summary: clang rejects std::thread from trunk
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 tmp % cat thread.cpp
#include 
#include 

int main() {
  std::vector threads;
  threads.emplace_back([]() {});
}

markus@x4 tmp % g++ -c thread.cpp
markus@x4 tmp % clang++ -c thread.cpp
In file included from thread.cpp:1:
/usr/lib64/gcc/x86_64-pc-linux-gnu/7.0.0/include/g++-v7/thread:239:39: error:
member access into incomplete type 'std::thread::_Invoker >'
  = decltype(std::declval<_Invoker>()._M_invoke(_Indices()));
 ^
/usr/lib64/gcc/x86_64-pc-linux-gnu/7.0.0/include/g++-v7/thread:126:8: note: in
instantiation of template class 'std::thread::_Invoker >'
  requested here
  __make_invoker(std::forward<_Callable>(__f),
  ^
/usr/lib64/gcc/x86_64-pc-linux-gnu/7.0.0/include/g++-v7/ext/new_allocator.h:120:23:
note: in instantiation of function template specialization
  'std::thread::thread<(lambda at thread.cpp:6:24)>' requested here
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
 ^
/usr/lib64/gcc/x86_64-pc-linux-gnu/7.0.0/include/g++-v7/bits/alloc_traits.h:455:8:
note: in instantiation of function template specialization
  '__gnu_cxx::new_allocator::construct' requested here
{ __a.construct(__p, std::forward<_Args>(__args)...); }
  ^
/usr/lib64/gcc/x86_64-pc-linux-gnu/7.0.0/include/g++-v7/bits/vector.tcc:96:21:
note: in instantiation of function template specialization
  'std::allocator_traits::construct' requested here
_Alloc_traits::construct(this->_M_impl, this->_M_impl._M_finish,
   ^
thread.cpp:6:11: note: in instantiation of function template specialization
'std::vector::emplace_back<(lambda
at thread.cpp:6:24)>'
  requested here
  threads.emplace_back([]() {});
  ^
/usr/lib64/gcc/x86_64-pc-linux-gnu/7.0.0/include/g++-v7/thread:220:14: note:
definition of 'std::thread::_Invoker >'
is not complete until
  the closing '}'
  struct _Invoker
 ^
1 error generated.

RFC [2/3] divmod transform v2 - override expand_divmod_libfunc for ARM port

2016-10-16 Thread Prathamesh Kulkarni
Hi,
This patch overrides expand_divmod_libfunc hook for ARM port.
I separated the SImode tests into separate file from DImode tests
because certain arm configs (cortex-15) have hardware div insn for
SImode but not for DImode, and for that config we want SImode tests to
be disabled but not DImode tests. The patch therefore has two
target-effective checks: divmod and divmod_simode.
Cross-tested on arm*-*-*.
OK to commit ?

Thanks,
Prathamesh
2016-10-15  Prathamesh Kulkarni  
Kugan Vivekanandarajah  
Jim Wilson  

* config/arm/arm.c (arm_expand_divmod_libfunc): Override hook
TARGET_EXPAND_DIVMOD_LIBFUNC.
* doc/sourcebuild.texi: Add items for arm_divmod_simode, divmod,
divmod_simode.

testsuite/
* lib/target-supports.exp (check_effective_target_divmod): New.
(check_effective_target_divmod_simode): Likewise. 
(check_effective_target_arm_divmod_simode): Likewise.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 39e3aa8..b1a6aeb 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -62,6 +62,7 @@
 #include "builtins.h"
 #include "tm-constrs.h"
 #include "rtl-iter.h"
+#include "optabs-libfuncs.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -304,6 +305,7 @@ static section *arm_function_section (tree, enum 
node_frequency, bool, bool);
 static bool arm_asm_elf_flags_numeric (unsigned int flags, unsigned int *num);
 static unsigned int arm_elf_section_type_flags (tree decl, const char *name,
int reloc);
+static void arm_expand_divmod_libfunc (rtx, machine_mode, rtx, rtx, rtx *, rtx 
*);
 
 /* Table of machine attributes.  */
 static const struct attribute_spec arm_attribute_table[] =
@@ -739,6 +741,9 @@ static const struct attribute_spec arm_attribute_table[] =
 #undef TARGET_SECTION_TYPE_FLAGS
 #define TARGET_SECTION_TYPE_FLAGS arm_elf_section_type_flags
 
+#undef TARGET_EXPAND_DIVMOD_LIBFUNC
+#define TARGET_EXPAND_DIVMOD_LIBFUNC arm_expand_divmod_libfunc
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 /* Obstack for minipool constant handling.  */
@@ -30776,4 +30781,33 @@ arm_elf_section_type_flags (tree decl, const char 
*name, int reloc)
   return flags;
 }
 
+/* Generate call to __aeabi_[mode]divmod (op0, op1).  */
+
+static void
+arm_expand_divmod_libfunc (rtx libfunc, machine_mode mode,
+  rtx op0, rtx op1,
+  rtx *quot_p, rtx *rem_p)
+{
+  if (mode == SImode)
+gcc_assert (!TARGET_IDIV);
+
+  machine_mode libval_mode = smallest_mode_for_size (2 * GET_MODE_BITSIZE 
(mode),
+MODE_INT);
+
+  rtx libval = emit_library_call_value (libfunc, NULL_RTX, LCT_CONST,
+   libval_mode, 2,
+   op0, GET_MODE (op0),
+   op1, GET_MODE (op1));
+
+  rtx quotient = simplify_gen_subreg (mode, libval, libval_mode, 0);
+  rtx remainder = simplify_gen_subreg (mode, libval, libval_mode,
+  GET_MODE_SIZE (mode));
+
+  gcc_assert (quotient);
+  gcc_assert (remainder);
+
+  *quot_p = quotient;
+  *rem_p = remainder;
+}
+
 #include "gt-arm.h"
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 07c75e2..39de0ff 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1675,6 +1675,10 @@ and @code{MOVT} instructions available.
 ARM target generates Thumb-1 code for @code{-mthumb} with
 @code{CBZ} and @code{CBNZ} instructions available.
 
+@item arm_divmod_simode
+ARM target for which divmod transform is disabled, if it supports hardware
+div instruction.
+
 @end table
 
 @subsubsection AArch64-specific attributes
@@ -1848,6 +1852,13 @@ Target requires a command line argument to enable a SIMD 
instruction set.
 
 @item pie_copyreloc
 The x86-64 target linker supports PIE with copy reloc.
+
+@item divmod
+Target supporting hardware divmod insn or divmod libcall.
+
+@item divmod_simode
+Target supporting hardware divmod insn or divmod libcall for SImode.
+
 @end table
 
 @subsubsection Environment attributes
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 201ed4b..fc5e37f 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -8070,3 +8070,41 @@ proc check_effective_target_profile_update_atomic {} {
int main (void) { return 0; }
 } "-fprofile-update=atomic -fprofile-generate"]
 }
+
+#For versions of ARM architectures that have hardware div insn,
+#disable the divmod transform
+
+proc check_effective_target_arm_divmod_simode { } {
+return [check_no_compiler_messages arm_divmod assembly {
+   #ifdef __ARM_ARCH_EXT_IDIV__
+   #error has div insn
+   #endif
+   int i;
+}]
+}
+
+# 

RFC [3/3] divmod transform v2 - add test cases

2016-10-16 Thread Prathamesh Kulkarni
Hi,
This patch adds test-cases for divmod transform.
OK to commit ?

Thanks,
Prathamesh
2016-10-15  Prathamesh Kulkarni  
Kugan Vivekanandarajah  
Jim Wilson  

testsuite/
* gcc.dg/divmod-1-simode.c: New test.
* gcc.dg/divmod-1.c: Likewise.
* gcc.dg/divmod-2-simode.c: Likewise.
* gcc.dg/divmod-2.c: Likewise.
* gcc.dg/divmod-3-simode.c: Likewise.
* gcc.dg/divmod-3.c: Likewise.
* gcc.dg/divmod-4-simode.c: Likewise.
* gcc.dg/divmod-4.c: Likewise.
* gcc.dg/divmod-5.c: Likewise.
* gcc.dg/divmod-6-simode.c: Likewise.
* gcc.dg/divmod-6.c: Likewise.
* gcc.dg/divmod-7.c: Likewise.

diff --git a/gcc/testsuite/gcc.dg/divmod-1-simode.c 
b/gcc/testsuite/gcc.dg/divmod-1-simode.c
new file mode 100644
index 000..9e47799
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-1-simode.c
@@ -0,0 +1,25 @@
+/* { dg-require-effective-target divmod_simode } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* div dominates mod.  */
+
+typedef int SImode __attribute__((mode(SI)));
+typedef unsigned USImode __attribute__((mode(SI)));
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no)  \
+bigtype f_##no(smalltype x, bigtype y) \
+{   \
+  bigtype q = x / y; \
+  if (cond)  \
+foo ();  \
+  bigtype r = x % y; \
+  return q + r;  \
+}
+
+FOO(SImode, SImode, 1)
+FOO(SImode, USImode, 2)
+FOO(USImode, USImode, 3)
+
+/* { dg-final { scan-tree-dump-times "DIVMOD" 3 "widening_mul" } } */
diff --git a/gcc/testsuite/gcc.dg/divmod-1.c b/gcc/testsuite/gcc.dg/divmod-1.c
new file mode 100644
index 000..edcc2a1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-1.c
@@ -0,0 +1,32 @@
+/* { dg-require-effective-target divmod } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* div dominates mod.  */
+
+typedef int SImode __attribute__((mode(SI)));
+typedef unsigned USImode __attribute__((mode(SI)));
+
+typedef int DImode __attribute__((mode(DI)));
+typedef unsigned UDImode __attribute__((mode(DI)));
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no) \
+bigtype f_##no(smalltype x, bigtype y)   \
+{   \
+  bigtype q = x / y; \
+  if (cond)  \
+foo ();  \
+  bigtype r = x % y; \
+  return q + r;  \
+}
+
+FOO(SImode, DImode, 1)
+FOO(SImode, UDImode, 2)
+FOO(USImode, DImode, 3)
+FOO(USImode, UDImode, 4)
+FOO(DImode, DImode, 5)
+FOO(DImode, UDImode, 6)
+FOO(UDImode, UDImode, 7)
+
+/* { dg-final { scan-tree-dump-times "DIVMOD" 7 "widening_mul" } } */
diff --git a/gcc/testsuite/gcc.dg/divmod-2-simode.c 
b/gcc/testsuite/gcc.dg/divmod-2-simode.c
new file mode 100644
index 000..fa28beb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-2-simode.c
@@ -0,0 +1,25 @@
+/* { dg-require-effective-target divmod_simode } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* mod dominates div.  */
+
+typedef int SImode __attribute__((mode(SI)));
+typedef unsigned USImode __attribute__((mode(SI)));
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no)  \
+bigtype f_##no(smalltype x, bigtype y) \
+{   \
+  bigtype r = x % y; \
+  if (cond)  \
+foo ();  \
+  bigtype q = x / y; \
+  return q + r;  \
+}
+
+FOO(SImode, SImode, 1)
+FOO(SImode, USImode, 2)
+FOO(USImode, USImode, 3)
+
+/* { dg-final { scan-tree-dump-times "DIVMOD" 3 "widening_mul" } } */
diff --git a/gcc/testsuite/gcc.dg/divmod-2.c b/gcc/testsuite/gcc.dg/divmod-2.c
new file mode 100644
index 000..ded732e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-2.c
@@ -0,0 +1,32 @@
+/* { dg-require-effective-target divmod } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* mod dominates div.  */
+
+typedef int SImode __attribute__((mode(SI)));
+typedef unsigned USImode __attribute__((mode(SI)));
+
+typedef int DImode __attribute__((mode(DI)));
+typedef unsigned UDImode __attribute__((mode(DI)));
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no) \
+bigtype f_##no(smalltype x, bigtype y)   \
+{   \
+  bigtype r = x % y; \
+  if (cond)  \
+foo ();  \
+  bigtype q = x / y; \
+  return q + r;  \
+}
+
+FOO(SImode, DImode, 1)
+FOO(SImode, UDImode, 2)
+FOO(USImode, DImode, 3)
+FOO(USImode, UDImode, 4)
+FOO(DImode, DImode, 5)
+FOO(DImode,