Re: [rs6000] Fix reload failures in 64-bit mode with no special constant pool
> Why does this not fail on darwin? It can reach this code afaics, and > it has ASM_OUTPUT_SPECIAL_POOL_ENTRY_P always 0. Probably because Darwin doesn't use the TOC at all. > Use "mode" instead of "Pmode" here? No, "mode" is the mode of the MEM, not that of the SYMBOL_REF. -- Eric Botcazou
Re: [PATCH] Implement new hook for max_align_t_align
On 10/08/16 19:36, John David Anglin wrote:
> On 2016-10-08, at 1:01 PM, Bernd Edlinger wrote:
>
>> I think your callback should also directly control the
>> alignment of max_align_t in stddef.h:
>>
>>
>>long long __max_align_ll __attribute__((__aligned__(__alignof__(long
>> long;
>>long double __max_align_ld
>> __attribute__((__aligned__(__alignof__(long double;
>>/* _Float128 is defined as a basic type, so max_align_t must be
>> sufficiently aligned for it. This code must work in C++, so we
>> use __float128 here; that is only available on some
>> architectures, but only on i386 is extra alignment needed for
>> __float128. */
>> #ifdef __i386__
>>__float128 __max_align_f128
>> __attribute__((__aligned__(__alignof(__float128;
>> #endif
>> } max_align_t;
>>
>>
>> otherwise these will not match.
>
> Yes, i missed a hunk in the submission. On hpux, the alignment is determined
> by the long
> double field. With glibc, we need 16 byte alignment for max_align_t.
>
This looks still brittle to me.
I mean also the defines __hppa__ and __hpux__ come from
builtin_define calls in the backend, why not define
something with builtin_define_with_int_value,
which can be used as is in max_align_t.
For instance have:
typedef struct {
char __max_align[0] __attribute__((__aligned__(__MAX_ALIGN_T_ALIGN__)));
} max_align_t;
Provided we do:
builtin_define_with_value ("__MAX_ALIGN_T_ALIGN__",
targetm.max_align_t_align () / BITS_PER_UNIT);
Would'nt that guarantee, that __max_align_t and
max_align_t_align () will always be the same?
Bernd.
Re: [PATCH] Improve target pass registration
> Here is updated patch, bootstrapped/regtested on x86_64-linux and > i686-linux. I'll still wait a few days before committing to see if somebody > likes to comment on the awk implementation of the script. > > 2016-10-05 Jakub Jelinek > > * gen-pass-instances.awk: Rewritten. This breaks bootstrap on Solaris with nawk: nawk -f /homes/botcazou/gcc-head/src/gcc/gen-pass-instances.awk \ /homes/botcazou/gcc-head/src/gcc/passes.def > pass-instances.def nawk: you can only delete array[element] at source line 196 context is delete >>> pass_counts; <<< nawk: syntax error at source line 196 nawk: illegal statement at source line 196 make[3]: *** [pass-instances.def] Error 2 -- Eric Botcazou
Re: Implement -Wimplicit-fallthrough (version 9)
On Sat, Oct 08, 2016 at 07:04:41PM +0200, Eric Botcazou wrote: > > testing completed successfully, so I've installed the patch with this > > ChangeLog entry: > > > > 2016-09-26 Rainer Orth > > > > gcc: > > * config/i386/i386.c (ix86_print_operand) > > [HAVE_AS_IX86_CMOV_SUN_SYNTAX]: Add gcc_fallthrough. > > * config/sparc/sparc.c (check_pic): Add fallthrough comment. > > (epilogue_renumber): Likewise. > > > > gcc/ada: > > * gcc-interface/decl.c: Fix fall through comment formatting. > > * gcc-interface/misc.c: Likewise. > > * gcc-interface/trans.c: Likewise. > > * gcc-interface/utils.c: Likewise. > > * gcc-interface/utils2.c: Likewise. > > This is a revealing example of how excessive pickiness in warnings can be > counter-productive: after Jakub's latest patches (thanks!) accepting the > original formatting of gcc-interface, I reverted part #2 of the above > patch... > only to discover that bootstrap was still broken because of a -Wimplicit- > fallthrough warning, but this time for a missing break: I really really don't see why anyone would think that those '...' bring any additional information. Since Rainer has changed this, I see zero point in changing it back. > Index: gcc-interface/utils.c > === > --- gcc-interface/utils.c (revision 324591) > +++ gcc-interface/utils.c (working copy) > @@ -4289,6 +4289,7 @@ convert (tree type, tree expr) > TREE_TYPE (expr) = type; > return expr; > } > + break; > > case CONSTRUCTOR: >/* If we are converting a CONSTRUCTOR to a mere type variant, or to > > So the issue went unnoticed among the slew of false positives the first time > and a genuine error was overlooked... It wasn't overlooked, there was a bug that I've fixed already which caused missing warnings. Marek
Re: Implement -Wimplicit-fallthrough (version 9)
> I really really don't see why anyone would think that those '...' bring > any additional information. Since Rainer has changed this, I see zero > point in changing it back. Yet doing it revealed an oversight in the first patch... > It wasn't overlooked, there was a bug that I've fixed already which caused > missing warnings. Nope, see this hunk in the first patch: @@ -4271,6 +4271,8 @@ convert (tree type, tree expr) return expr; } + /* fall through */ + case CONSTRUCTOR: /* If we are converting a CONSTRUCTOR to a mere type variant, or to another padding type around the same type, just make a new one in It's plain wrong, it should have been a break instead, but this was overlooked by everyone because of the bunch of false positives. -- Eric Botcazou
[PATCH] PR 67585 Handle EINTR
Many POSIX systems have the bad habit of not restarting interrupted
syscalls. On these systems it's up to the user to check for an error
with errno == EINTR and restart manually. This patch does this for
libgfortran, so that GFortran users don't have to do it.
2016-10-09 Janne Blomqvist
PR libfortran/67585
* io/io.h: TEMP_FAILURE_RETRY: Define macro if not found.
* io/unix.c (raw_read): Handle EINTR.
(raw_write): Check for return value -1.
(raw_seek): Handle EINTR.
(raw_tell): Likewise.
(raw_size): Likewise.
(raw_truncate): Likewise.
(raw_close): Likewise.
(buf_flush): Call raw_seek instead of lseek.
(buf_read): Likewise.
(buf_write): Likewise.
(fd_to_stream): Likewise.
(tempfile_open): Likewise.
(regular_file2): Likewise.
(compare_file_filename): Likewise.
(find_file): Likewise.
(inquire_sequential): Likewise.
(inquire_direct): Likewise.
(inquire_formatted): Likewise.
Version 2 of the patch: Use the TEMP_FAILURE_RETRY macro to do the
EINTR loop when appropriate, cover more functions (open, mk(o)stemp,
(f)stat).
Regtested on x86_64-pc-linux-gnu. Ok for trunk?
---
libgfortran/io/io.h | 15 +
libgfortran/io/unix.c | 86 +++
2 files changed, 75 insertions(+), 26 deletions(-)
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index ff75741..c8b9bc6 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -647,6 +647,21 @@ typedef struct gfc_unit
gfc_unit;
+/* TEMP_FAILURE_RETRY macro from glibc. */
+
+#ifndef TEMP_FAILURE_RETRY
+/* Evaluate EXPRESSION, and repeat as long as it returns -1 with `errno'
+ set to EINTR. */
+
+# define TEMP_FAILURE_RETRY(expression) \
+ (__extension__ \
+({ long int __result; \
+ do __result = (long int) (expression); \
+ while (__result == -1L && errno == EINTR); \
+ __result; }))
+#endif
+
+
/* unit.c */
/* Maximum file offset, computed at library initialization time. */
diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 29818cd..1e84c42 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -298,8 +298,15 @@ static ssize_t
raw_read (unix_stream * s, void * buf, ssize_t nbyte)
{
/* For read we can't do I/O in a loop like raw_write does, because
- that will break applications that wait for interactive I/O. */
- return read (s->fd, buf, nbyte);
+ that will break applications that wait for interactive I/O. We
+ still can loop around EINTR, though. */
+ while (true)
+{
+ ssize_t trans = read (s->fd, buf, nbyte);
+ if (trans == -1 && errno == EINTR)
+ continue;
+ return trans;
+}
}
static ssize_t
@@ -316,7 +323,7 @@ raw_write (unix_stream * s, const void * buf, ssize_t nbyte)
while (bytes_left > 0)
{
trans = write (s->fd, buf_st, bytes_left);
- if (trans < 0)
+ if (trans == -1)
{
if (errno == EINTR)
continue;
@@ -333,22 +340,33 @@ raw_write (unix_stream * s, const void * buf, ssize_t nbyte)
static gfc_offset
raw_seek (unix_stream * s, gfc_offset offset, int whence)
{
- return lseek (s->fd, offset, whence);
+ while (true)
+{
+ gfc_offset off = lseek (s->fd, offset, whence);
+ if (off == (gfc_offset) -1 && errno == EINTR)
+ continue;
+ return off;
+}
}
static gfc_offset
raw_tell (unix_stream * s)
{
- return lseek (s->fd, 0, SEEK_CUR);
+ while (true)
+{
+ gfc_offset off = lseek (s->fd, 0, SEEK_CUR);
+ if (off == (gfc_offset) -1 && errno == EINTR)
+ continue;
+ return off;
+}
}
static gfc_offset
raw_size (unix_stream * s)
{
struct stat statbuf;
- int ret = fstat (s->fd, &statbuf);
- if (ret == -1)
-return ret;
+ if (TEMP_FAILURE_RETRY (fstat (s->fd, &statbuf)) == -1)
+return -1;
if (S_ISREG (statbuf.st_mode))
return statbuf.st_size;
else
@@ -390,7 +408,9 @@ raw_truncate (unix_stream * s, gfc_offset length)
lseek (s->fd, cur, SEEK_SET);
return -1;
#elif defined HAVE_FTRUNCATE
- return ftruncate (s->fd, length);
+ if (TEMP_FAILURE_RETRY (ftruncate (s->fd, length)) == -1)
+return -1;
+ return 0;
#elif defined HAVE_CHSIZE
return chsize (s->fd, length);
#else
@@ -409,7 +429,17 @@ raw_close (unix_stream * s)
else if (s->fd != STDOUT_FILENO
&& s->fd != STDERR_FILENO
&& s->fd != STDIN_FILENO)
-retval = close (s->fd);
+{
+ retval = close (s->fd);
+ /* close() and EINTR is special, as the file descriptor is
+ deallocated before doing anything that might cause the
+ operation to be interrupted. Thus if we get EINTR the best we
+ can do is ignore it and continue (otherwise if we try again
+ the file descript
Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors
On 08/10/16 22:55 +0200, François Dumont wrote:
On 06/10/2016 23:34, Jonathan Wakely wrote:
On 06/10/16 22:17 +0200, François Dumont wrote:
Another approach is to rely on existing compiler ability to
compute conditional noexcept when defaulting implementations. This
is what I have done in this patch.
The new default constructor on _Rb_tree_node_base is not a problem
as it is not used to build _Rb_tree_node.
Why not?
_Rb_tree_node_base is used in 2 context. As member of _Rb_tree_impl in
which case we need the new default constructor. And also as base class
of _Rb_tree_node which is never constructed. Nodes are being allocated
and then associated value is being constructed through the allocator,
the node default constructor itself is never invoked.
In C++03 mode that is true, but it's only valid because the type is
trivially-constructible. If the type requires "non-vacuous
initialization" then it's not valid to allocate memory for it and
start using it without invoking a constructor. If you add a
non-trivial constructor then we can't do that any more.
In C++11 and later, see line 550 in
::new(__node) _Rb_tree_node<_Val>;
This default-constructs a tree node. Currently there is no
user-provided default constructor, so default-construction does no
initialization. Adding your constructor would mean it is used for
every node.
If you think it is cleaner to create an intermediate type that
will take care of this initialization through its default constructor
I can do that.
I'll try to do the same for copy constructor/assignment and move
constructor/assignment.
We need to make sure we don't change whether any of those operations
are trivial (which shouldn't be a problem for copy/move, because they
are definitely very non-trivial and will stay that way!)
Does this change the default constructors from non-trivial to trivial?
It would be a major compiler bug if making a constructor default was
making it trivial.
I must be misunderstanding you, because this is not a bug:
#include
struct A {
A() { }
};
static_assert( !std::is_trivially_default_constructible::value, "" );
struct B {
B() = default;
};
static_assert( std::is_trivially_default_constructible::value, "" );
[PATCH] Improve performance of list::reverse
Hi,
If we unroll the loop so that we iterate both forwards and backwards,
we can take advantage of memory-level parallelism when chasing
pointers. This means that reverse takes 35% less time when nodes are
randomly scattered in memory and about the same time if nodes are
contiguous.
Further, as our node pointers will never alias, we can interleave the
swaps of the next and previous pointers to remove further data
dependencies. This takes another 5% off the time when nodes are
scattered in memory and takes 20% off when nodes are contiguous.
All in all we save 20%-40% depending on the memory layout.
For future improvement, by passing whether there is an odd or even
number of nodes in the list we can hoist one of the ifs out of the
loop and gain another 5-10% but most likely this is only possible when
_GLIBCXX_USE_CXX11_ABI is defined and size() is O(1). This would bring
the saving to 30%-45%. Is it worth writing a new overload of
_M_reverse which takes the size of the list?
Tested on x86_64-linux-gnu.
Thanks!
commit 073c569818764c5b2e80cc09e89721f3386e1728
Author: Elliot Goodrich
Date: Sun Oct 9 14:34:59 2016 +0100
2016-10-09 Elliot Goodrich
* libstdc++-v3/src/c++98/list.cc (list::reverse): Speedup reverse
method.
* libstdc++-v3/testsuite/23_containers/list/operations/reverse/1.cc:
Add test.
diff --git a/libstdc++-v3/src/c++98/list.cc b/libstdc++-v3/src/c++98/list.cc
index 62b812a..aeb2402 100644
--- a/libstdc++-v3/src/c++98/list.cc
+++ b/libstdc++-v3/src/c++98/list.cc
@@ -112,15 +112,36 @@ namespace std _GLIBCXX_VISIBILITY(default)
void
_List_node_base::_M_reverse() _GLIBCXX_USE_NOEXCEPT
{
- _List_node_base* __tmp = this;
- do
- {
- std::swap(__tmp->_M_next, __tmp->_M_prev);
+ _List_node_base* __forward = this;
+ _List_node_base* __backward = __forward->_M_prev;
+ if (__forward == __backward) {
+return;
+ }
- // Old next node is now prev.
- __tmp = __tmp->_M_prev;
- }
- while (__tmp != this);
+ // unroll the loop to take advantage of memory-level parallelism
+ while (true) {
+_List_node_base* __forward_next = __forward->_M_next;
+_List_node_base* __backward_prev = __backward->_M_prev;
+
+__forward->_M_next = __forward->_M_prev;
+__backward->_M_prev = __backward->_M_next;
+
+__backward->_M_next = __backward_prev;
+__forward->_M_prev = __forward_next;
+
+if (__forward_next == __backward_prev) {
+ // if there is an odd number of nodes, swap the last one
+ std::swap(__forward_next->_M_next, __forward_next->_M_prev);
+ return;
+}
+
+if (__forward_next == __backward) {
+ return;
+}
+
+__forward = __forward_next;
+__backward = __backward_prev;
+ }
}
void
diff --git a/libstdc++-v3/testsuite/23_containers/list/operations/reverse/1.cc
b/libstdc++-v3/testsuite/23_containers/list/operations/reverse/1.cc
new file mode 100644
index 000..7eab83b
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/list/operations/reverse/1.cc
@@ -0,0 +1,88 @@
+// Copyright (C) 2016-2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors
On 09/10/16 16:14 +0100, Jonathan Wakely wrote: On 08/10/16 22:55 +0200, François Dumont wrote: On 06/10/2016 23:34, Jonathan Wakely wrote: On 06/10/16 22:17 +0200, François Dumont wrote: Another approach is to rely on existing compiler ability to compute conditional noexcept when defaulting implementations. This is what I have done in this patch. The new default constructor on _Rb_tree_node_base is not a problem as it is not used to build _Rb_tree_node. Why not? _Rb_tree_node_base is used in 2 context. As member of _Rb_tree_impl in which case we need the new default constructor. And also as base class of _Rb_tree_node which is never constructed. Nodes are being allocated and then associated value is being constructed through the allocator, the node default constructor itself is never invoked. In C++03 mode that is true, but it's only valid because the type is trivially-constructible. If the type requires "non-vacuous initialization" then it's not valid to allocate memory for it and start using it without invoking a constructor. If you add a non-trivial constructor then we can't do that any more. In fact that code is highly questionable, because the element member makes the node require non-trivial initialization. We rely on the base being trivially-constructible, and the element being constructed by the allocator, and assume that it's OK to then treat that memory as a node. In fact only its base class and member have been constructed, not the node itself. The C++11 version (using an aligned buffer) is correct. But I'd prefer not to make the C++98 version worse.
[committed] parisc: Define MALLOC_ABI_ALIGNMENT
The attached patch defines MALLOC_ABI_ALIGNMENT so that it now reflects the alignment provided by malloc on hpux and linux. I also adjusted the comment for BIGGEST_ALIGNMENT so that the define is more understandable. Tested on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2016-10-09 John David Anglin * config/pa/pa.h (BIGGEST_ALIGNMENT): Adjust comment. (MALLOC_ABI_ALIGNMENT): Define. Index: config/pa/pa.h === --- config/pa/pa.h (revision 240688) +++ config/pa/pa.h (working copy) @@ -292,9 +292,21 @@ /* A bit-field declared as `int' forces `int' alignment for the struct. */ #define PCC_BITFIELD_TYPE_MATTERS 1 -/* No data type wants to be aligned rounder than this. */ +/* No data type wants to be aligned rounder than this. The long double + type has 16-byte alignment on the 64-bit target even though it was never + implemented in hardware. The software implementation only needs 8-byte + alignment. This is to match the HP compilers. */ #define BIGGEST_ALIGNMENT (2 * BITS_PER_WORD) +/* Alignment, in bits, a C conformant malloc implementation has to provide. + The HP-UX malloc implementation provides a default alignment of 8 bytes. + This can be increased with mallopt. The glibc implementation also provides + 8-byte alignment. Note that this isn't enough for various POSIX types such + as pthread_mutex_t. However, since we no longer need the 16-byte alignment + for atomic operations, we ignore the nominal alignment specified for these + types. The same is true for long double on 64-bit HP-UX. */ +#define MALLOC_ABI_ALIGNMENT (64) + /* Get around hp-ux assembler bug, and make strcpy of constants fast. */ #define CONSTANT_ALIGNMENT(EXP, ALIGN) \ (TREE_CODE (EXP) == STRING_CST \
Re: [PATCH] Implement new hook for max_align_t_align
On 2016-10-09, at 4:34 AM, Bernd Edlinger wrote:
> For instance have:
>
> typedef struct {
> char __max_align[0] __attribute__((__aligned__(__MAX_ALIGN_T_ALIGN__)));
> } max_align_t;
>
> Provided we do:
>
> builtin_define_with_value ("__MAX_ALIGN_T_ALIGN__",
> targetm.max_align_t_align () / BITS_PER_UNIT);
>
> Would'nt that guarantee, that __max_align_t and
> max_align_t_align () will always be the same?
Yes, excellent suggestion. Testing.
--
John David Anglin dave.ang...@bell.net
Re: [PATCH] Improve target pass registration
> This breaks bootstrap on Solaris with nawk:
>
> nawk -f /homes/botcazou/gcc-head/src/gcc/gen-pass-instances.awk \
> /homes/botcazou/gcc-head/src/gcc/passes.def > pass-instances.def
> nawk: you can only delete array[element] at source line 196
> context is
> delete >>> pass_counts; <<<
> nawk: syntax error at source line 196
> nawk: illegal statement at source line 196
> make[3]: *** [pass-instances.def] Error 2
Here's what I have installed as obvious after testing on Linux and Solaris.
2016-10-09 Eric Botcazou
* gen-pass-instances.awk: Remove GNUism.
--
Eric BotcazouIndex: gen-pass-instances.awk
===
--- gen-pass-instances.awk (revision 240888)
+++ gen-pass-instances.awk (working copy)
@@ -193,7 +193,6 @@ function replace_pass(line, fnname, nu
}
END {
- delete pass_counts;
for (i = 1; i < lineno; i++)
{
ret = parse_line(lines[i], "NEXT_PASS");
@@ -203,13 +202,13 @@ END {
pass_name = args[1];
with_arg = args[2];
- # Set pass_counts
- if (pass_name in pass_counts)
- pass_counts[pass_name]++;
+ # Set pass_final_counts
+ if (pass_name in pass_final_counts)
+ pass_final_counts[pass_name]++;
else
- pass_counts[pass_name] = 1;
+ pass_final_counts[pass_name] = 1;
- pass_num = pass_counts[pass_name];
+ pass_num = pass_final_counts[pass_name];
# Print call expression with extra pass_num argument
printf "%s", prefix;
[Go] Remove obsolete lang_requires_boot_languages setting
Hi, this gets rid of the "'c++' language required by 'go' in stage 1; enabling" obsolete message printed by the configure script. Tested on x86_64-suse-linux, OK for the mainline? 2016-10-09 Eric Botcazou * config-lang.in (lang_requires_boot_languages): Delete. -- Eric BotcazouIndex: config-lang.in === --- config-lang.in (revision 240888) +++ config-lang.in (working copy) @@ -31,10 +31,6 @@ compilers="go1\$(exeext)" target_libs="target-libgo target-libffi target-libbacktrace" lang_dirs="gotools" -# The Go frontend is written in C++, so we need to build the C++ -# compiler during stage 1. -lang_requires_boot_languages=c++ - gtfiles="\$(srcdir)/go/go-lang.c \$(srcdir)/go/go-c.h" # Do not build by default.
Re: [PATCH] Improve target pass registration
On Sun, Oct 09, 2016 at 10:51:10PM +0200, Eric Botcazou wrote: > > This breaks bootstrap on Solaris with nawk: > > > > nawk -f /homes/botcazou/gcc-head/src/gcc/gen-pass-instances.awk \ > > /homes/botcazou/gcc-head/src/gcc/passes.def > pass-instances.def > > nawk: you can only delete array[element] at source line 196 > > context is > > delete >>> pass_counts; <<< > > nawk: syntax error at source line 196 > > nawk: illegal statement at source line 196 > > make[3]: *** [pass-instances.def] Error 2 > > Here's what I have installed as obvious after testing on Linux and Solaris. > > > 2016-10-09 Eric Botcazou > > * gen-pass-instances.awk: Remove GNUism. Thanks. Jakub
Fix for libstdc++-v3's error_constants.h for MinGW-W64
Hi,
Please apply to gcc-5-branch, gcc-6-branch and trunk.
Index: libstdc++-v3/config/os/mingw32-w64/error_constants.h
===
--- libstdc++-v3/config/os/mingw32-w64/error_constants.h (revision
240904)
+++ libstdc++-v3/config/os/mingw32-w64/error_constants.h(working copy)
@@ -41,22 +41,22 @@
// replaced by Winsock WSA-prefixed equivalents.
enum class errc
{
-//address_family_not_supported = EAFNOSUPPORT,
-//address_in_use = EADDRINUSE,
-//address_not_available = EADDRNOTAVAIL,
-//already_connected = EISCONN,
+ address_family_not_supported = EAFNOSUPPORT,
+ address_in_use = EADDRINUSE,
+ address_not_available = EADDRNOTAVAIL,
+ already_connected = EISCONN,
argument_list_too_long = E2BIG,
argument_out_of_domain = EDOM,
bad_address =EFAULT,
bad_file_descriptor =EBADF,
-//bad_message =EBADMSG,
+ bad_message =EBADMSG,
broken_pipe =EPIPE,
-//connection_aborted = ECONNABORTED,
-//connection_already_in_progress = EALREADY,
-//connection_refused = ECONNREFUSED,
-//connection_reset = ECONNRESET,
-//cross_device_link = EXDEV,
-//destination_address_required = EDESTADDRREQ,
+ connection_aborted = ECONNABORTED,
+ connection_already_in_progress = EALREADY,
+ connection_refused = ECONNREFUSED,
+ connection_reset = ECONNRESET,
+ cross_device_link = EXDEV,
+ destination_address_required = EDESTADDRREQ,
device_or_resource_busy =EBUSY,
directory_not_empty =ENOTEMPTY,
executable_format_error =ENOEXEC,
@@ -64,8 +64,8 @@
file_too_large = EFBIG,
filename_too_long = ENAMETOOLONG,
function_not_supported = ENOSYS,
-//host_unreachable = EHOSTUNREACH,
-//identifier_removed = EIDRM,
+ host_unreachable = EHOSTUNREACH,
+ identifier_removed = EIDRM,
illegal_byte_sequence = EILSEQ,
inappropriate_io_control_operation = ENOTTY,
interrupted =EINTR,
@@ -73,67 +73,66 @@
invalid_seek = ESPIPE,
io_error = EIO,
is_a_directory = EISDIR,
-//message_size = EMSGSIZE,
-//network_down = ENETDOWN,
-//network_reset = ENETRESET,
-//network_unreachable =ENETUNREACH,
-//no_buffer_space =ENOBUFS,
+ message_size = EMSGSIZE,
+ network_down = ENETDOWN,
+ network_reset = ENETRESET,
+ network_unreachable =ENETUNREACH,
+ no_buffer_space =ENOBUFS,
#ifdef _GLIBCXX_HAVE_ECHILD
no_child_process = ECHILD,
#endif
-//no_link =ENOLINK,
+ no_link =ENOLINK,
no_lock_available = ENOLCK,
-//no_message_available = ENODATA,
-//no_message = ENOMSG,
-//no_protocol_option = ENOPROTOOPT,
+ no_message_available = ENODATA,
+ no_message = ENOMSG,
+ no_protocol_option = ENOPROTOOPT,
#ifdef _GLIBCXX_HAVE_ENOSPC
no_space_on_device = ENOSPC,
#endif
-//no_stream_resources =ENOSR,
+ no_stream_resources =ENOSR,
no_such_device_or_address = ENXIO,
no_such_device = ENODEV,
no_such_file_or_directory = ENOENT,
no_such_process =ESRCH,
not_a_directory =ENOTDIR,
-//not_a_socket = ENOTSOCK,
-//not_a_stream = ENOSTR,
-//not_connected = ENOTCONN,
+ not_a_socket = ENOTSOCK,
+ not_a_stream =
Re: [Go] Remove obsolete lang_requires_boot_languages setting
On Sun, Oct 9, 2016 at 1:55 PM, Eric Botcazou wrote: > > this gets rid of the "'c++' language required by 'go' in stage 1; enabling" > obsolete message printed by the configure script. > > Tested on x86_64-suse-linux, OK for the mainline? > > > 2016-10-09 Eric Botcazou > > * config-lang.in (lang_requires_boot_languages): Delete. This is OK. Thanks. Ian
PING: [PATCH] Be more conservative in early inliner if FDO is enabled
Hi,
What is the decision on this patch?
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01041.html
Regards,
Yuan, Pengfei
> A new patch for trunk is attached.
>
> Regards,
> Yuan, Pengfei
>
>
> 2016-09-16 Yuan Pengfei
>
> * doc/invoke.texi (--param early-inlining-insns-feedback): New.
> * ipa-inline.c (want_early_inline_function_p): Use
> PARAM_EARLY_INLINING_INSNS_FEEDBACK when FDO is enabled.
> * params.def (PARAM_EARLY_INLINING_INSNS_FEEDBACK): Define.
> (PARAM_EARLY_INLINING_INSNS): Change help string accordingly.
>
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 8eb5eff..6e7659a 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -9124,12 +9124,18 @@ given call expression. This parameter limits
> inlining only to call expressions
> whose probability exceeds the given threshold (in percents).
> The default value is 10.
>
> @item early-inlining-insns
> +@itemx early-inlining-insns-feedback
> Specify growth that the early inliner can make. In effect it increases
> the amount of inlining for code having a large abstraction penalty.
> The default value is 14.
>
> +The @option{early-inlining-insns-feedback} parameter is used only when
> +profile feedback-directed optimizations are enabled (by
> +@option{-fprofile-generate} or @option{-fprofile-use}).
> +The default value is 2.
> +
> @item max-early-inliner-iterations
> Limit of iterations of the early inliner. This basically bounds
> the number of nested indirect calls the early inliner can resolve.
> Deeper chains are still handled by late inlining.
> diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
> index 5c9366a..e028c08 100644
> --- a/gcc/ipa-inline.c
> +++ b/gcc/ipa-inline.c
> @@ -594,10 +594,17 @@ want_early_inline_function_p (struct cgraph_edge *e)
> }
>else
> {
>int growth = estimate_edge_growth (e);
> + int growth_limit;
>int n;
>
> + if ((profile_arc_flag && !flag_test_coverage)
> + || (flag_branch_probabilities && !flag_auto_profile))
> + growth_limit = PARAM_VALUE (PARAM_EARLY_INLINING_INSNS_FEEDBACK);
> + else
> + growth_limit = PARAM_VALUE (PARAM_EARLY_INLINING_INSNS);
> +
>if (growth <= 0)
> ;
>else if (!e->maybe_hot_p ()
> && growth > 0)
> @@ -610,9 +617,9 @@ want_early_inline_function_p (struct cgraph_edge *e)
>xstrdup_for_dump (callee->name ()), callee->order,
>growth);
> want_inline = false;
> }
> - else if (growth > PARAM_VALUE (PARAM_EARLY_INLINING_INSNS))
> + else if (growth > growth_limit)
> {
> if (dump_file)
> fprintf (dump_file, " will not early inline: %s/%i->%s/%i, "
>"growth %i exceeds --param early-inlining-insns\n",
> @@ -622,9 +629,9 @@ want_early_inline_function_p (struct cgraph_edge *e)
>growth);
> want_inline = false;
> }
>else if ((n = num_calls (callee)) != 0
> -&& growth * (n + 1) > PARAM_VALUE (PARAM_EARLY_INLINING_INSNS))
> +&& growth * (n + 1) > growth_limit)
> {
> if (dump_file)
> fprintf (dump_file, " will not early inline: %s/%i->%s/%i, "
>"growth %i exceeds --param early-inlining-insns "
> diff --git a/gcc/params.def b/gcc/params.def
> index 79b7dd4..91ea513 100644
> --- a/gcc/params.def
> +++ b/gcc/params.def
> @@ -199,12 +199,20 @@ DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
> DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
>"ipcp-unit-growth",
>"How much can given compilation unit grow because of the
> interprocedural constant propagation (in percent).",
>10, 0, 0)
> -DEFPARAM(PARAM_EARLY_INLINING_INSNS,
> - "early-inlining-insns",
> - "Maximal estimated growth of function body caused by early inlining of
> single call.",
> - 14, 0, 0)
> +DEFPARAM (PARAM_EARLY_INLINING_INSNS_FEEDBACK,
> + "early-inlining-insns-feedback",
> + "Maximal estimated growth of function body caused by early "
> + "inlining of single call. Used when profile feedback-directed "
> + "optimizations are enabled.",
> + 2, 0, 0)
> +DEFPARAM (PARAM_EARLY_INLINING_INSNS,
> + "early-inlining-insns",
> + "Maximal estimated growth of function body caused by early "
> + "inlining of single call. Used when profile feedback-directed "
> + "optimizations are not enabled.",
> + 14, 0, 0)
> DEFPARAM(PARAM_LARGE_STACK_FRAME,
>"large-stack-frame",
>"The size of stack frame to be considered large.",
>256, 0, 0)
Re: [PATCH] Delete GCJ
On 07.10.2016 10:30, Iain Sandoe wrote: > >> On 7 Oct 2016, at 00:58, Matthias Klose wrote: >> >> On 06.10.2016 20:00, Mike Stump wrote: >>> On Oct 6, 2016, at 9:56 AM, Rainer Orth >>> wrote: I wouldn't hard-fail, but completely disable objc-gc with an appropriate warning. The Objective-C maintainers may have other preferences, though. >> >> I think I can't do that in the top level make file very well (currently I >> only >> have the pkg-config check there for an early failure, but that check doesn't >> tell me if the library is present for all multilib variants). And I can't >> check >> for multilibs because I don't know if the bootstrap compiler is multilib >> aware. > > hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s > the configurer’s responsibility to provide a path with appropriate > headers/libs for the multi-lib configuration being attempted. I don't understand what you are proposing here. >>> gcc historically is fairly weak at complex configurations. I need the 32 >>> bit libraries to support -m32, but, those libraries might not be present, >>> but do I build all the rest of my libraries, and if i do, do I test them >>> once build, but what is other dependent external libraries are missing. Do >>> I turn off the multilib, or do I not? >>> >>> I used to manage some of this by passing in configure flags to control >>> multilibbing based upon what libraries were install and then run testing >>> based upon that. Of course, that's all external to gcc proper. Doesn't >>> really make gcc any easier to configure and build or advance gcc. >>> >>> We could smell the system at configure time, and turn on and off multilib >>> variants and things like objc gc. Target specific, but I think it helps to >>> ponder this in a target independent way. This can then turn on and off >>> objc gc support directly. To get it on, one would need to install the >>> needed libraries, and reconfigure and rebuild gcc. I think I might like >>> that the best. Has a nice easy of use about it, and then everything gcc >>> does is rather sane (no funny build errors when a needed library isn't >>> present). >>> >>> >>> So, I think, if I understand what you propose, I'm fine with that. >> >> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac >> with >> a hard error message and leave it to the user to correctly configure GCC? >> That >> would rely on the compiler to find the library in a system wide multilib >> aware >> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32). Is this the case >> for >> Solaris and Darwin? > > for Darwin, it’s not a default install (but then neither are the host deps > such as gmp & friends) - so the toolchain builder on Darwin already needs to > make some provisions outside the system. It’s just that the only target > provisions to date have been the sysroot (we haven’t yet made use of add-on > target libs). > >> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu >> where multilib is the default (but objc-gc is not). >> >> Looking back at libjava, I think everybody disabled multilibs for libjava, >> because nobody had a complete gtk2 stack for multilibs, however that was a >> complete subdir, not just a certain configuration in that subdir. Looking >> back >> at libffi and separate released libffi's I first built multilib'ed libffi >> libraries from the libffi source for Debian/Ubuntu, then dropped these >> because >> they were not used, and until today GCC internal and external libffi are >> hopelessly out of sync, so you couldn't use an external libffi to build >> libjava. > > Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally > libjava (and libffi, gc) were generally built and tested (by those who cared > to do it) as multilibs [the default]. >> >> In the past I looked at updating boehm-gc to recent sources but never >> finished >> because libjava relied on internals. Afaics this is not the case for >> objc-gc, >> so maybe you could update boehm-gc. But I don't want to go this road myself … > > .. and I don’t have cycles to volunteer to try this at present either. > Iain > > >> >> Matthias >
