Re: [PATCH] Add support for OpenMP fortran user defined reductions
Jakub Jelinek ja...@redhat.com writes:
--- gcc/testsuite/gfortran.dg/gomp/udr6.f90.jj2014-06-02
10:49:02.674337338 +0200
+++ gcc/testsuite/gfortran.dg/gomp/udr6.f90 2014-06-02 15:40:52.664740529
+0200
@@ -0,0 +1,205 @@
+! { dg-do compile }
+! { dg-options -fmax-errors=1000 -fopenmp -ffree-line-length-160 }
+
+module udr6
+ type dt
+integer :: i
+ end type
+end module udr6
+subroutine f1
+ use udr6, only : dt
+!$omp declare reduction (+:integer:omp_out = omp_out + omp_in) ! { dg-error
Redefinition of predefined }
+!$omp declare reduction (+:real(kind=4):omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (+:double precision:omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (+:integer(kind=8),integer(kind=1) ! { dg-error
Redefinition of predefined }
+!$omp :omp_out = omp_out + omp_in)
+!$omp declare reduction (+:complex:omp_out = omp_out + omp_in) ! { dg-error
Redefinition of predefined }
+!$omp declare reduction (+:complex(kind=16):omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
udr6.f90:17:42: Error: Kind 16 not supported for type COMPLEX at (1)
udr6.f90:41:42: Error: Kind 16 not supported for type COMPLEX at (1)
udr6.f90:58:42: Error: Kind 16 not supported for type COMPLEX at (1)
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.
Re: [PATCH] Add support for OpenMP fortran user defined reductions
On Sat, Jun 07, 2014 at 10:11:06AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com writes:
--- gcc/testsuite/gfortran.dg/gomp/udr6.f90.jj 2014-06-02
10:49:02.674337338 +0200
+++ gcc/testsuite/gfortran.dg/gomp/udr6.f90 2014-06-02 15:40:52.664740529
+0200
@@ -0,0 +1,205 @@
+! { dg-do compile }
+! { dg-options -fmax-errors=1000 -fopenmp -ffree-line-length-160 }
+
+module udr6
+ type dt
+integer :: i
+ end type
+end module udr6
+subroutine f1
+ use udr6, only : dt
+!$omp declare reduction (+:integer:omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (+:real(kind=4):omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (+:double precision:omp_out = omp_out + omp_in) !
{ dg-error Redefinition of predefined }
+!$omp declare reduction (+:integer(kind=8),integer(kind=1) ! { dg-error
Redefinition of predefined }
+!$omp :omp_out = omp_out + omp_in)
+!$omp declare reduction (+:complex:omp_out = omp_out + omp_in) ! {
dg-error Redefinition of predefined }
+!$omp declare reduction (+:complex(kind=16):omp_out = omp_out + omp_in) !
{ dg-error Redefinition of predefined }
udr6.f90:17:42: Error: Kind 16 not supported for type COMPLEX at (1)
udr6.f90:41:42: Error: Kind 16 not supported for type COMPLEX at (1)
udr6.f90:58:42: Error: Kind 16 not supported for type COMPLEX at (1)
Which target? I thought complex(kind=16) is normal double _Complex, isn't
it? The point is just to test complex(kind=NNN), if you have some other
kind that works everywhere, it can be changed.
Jakub
Re: [PATCH] Add support for OpenMP fortran user defined reductions
Jakub Jelinek ja...@redhat.com writes: I thought complex(kind=16) is normal double _Complex, isn't it? No, that would be complex(kind=8). 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.
Re: __float128 typeinfo
On Fri, 6 Jun 2014, Paolo Carlini wrote: On 06/06/2014 04:16 PM, Marc Glisse wrote: abi_check is broken before my patch (134 incompatible symbols). Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I would recommend investigating in some detail what's going on at your end... Ah, no, abi_check actually passed in the regular bootstrap, it is in the debug builds (-O0) that it fails because more than a hundred non-inlined inline functions find their way into the library. False alarm. -- Marc Glisse
Re: __float128 typeinfo
Hi, On 07 giugno 2014 11:42:23 CEST, Marc Glisse marc.gli...@inria.fr wrote: On Fri, 6 Jun 2014, Paolo Carlini wrote: On 06/06/2014 04:16 PM, Marc Glisse wrote: abi_check is broken before my patch (134 incompatible symbols). Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I would recommend investigating in some detail what's going on at your end... Ah, no, abi_check actually passed in the regular bootstrap, it is in the debug builds (-O0) that it fails because more than a hundred non-inlined inline functions find their way into the library. False alarm. Thanks for checking. That is a known issue: short term the only solution I can see is tightening by hand the patterns in the linker script to avoid exporting all the functions which are not inlined anymore at -O0. If nobody has smarter plans I can come to that boring work. Paolo
[libgfortran, patch] Fix compilation on HP/UX 10
Attached patch should fix compilation of libgfortran on hppa1.1-hp-hpux10.20 (see PR60468: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60468), by adding a missing math.h header to the configure checks. I’ve tested that it doesn’t break bootstrap on x86_64-apple-darwin, but not on hpux10. It seems safe enough to me to proceed first, and let John test in his next build of trunk (bootstrap on those machines probably isn’t fast). OK to commit? FX hpux.diff Description: Binary data hpux.ChangeLog Description: Binary data
Re: [PATCH, PR61219]: Fix sNaN handling in ARM float to double conversion
Ping. Note that PR61219 is a duplicate of PR59833, so this patch
actually fix PR59833.
On Sun, May 18, 2014 at 11:23:38PM +0200, Aurelien Jarno wrote:
On ARM soft-float, the float to double conversion doesn't convert a sNaN
to qNaN as the IEEE Std 754 standard mandates:
Under default exception handling, any operation signaling an invalid
operation exception and for which a floating-point result is to be
delivered shall deliver a quiet NaN.
Given the soft float ARM code ignores exceptions and always provides a
result, a float to double conversion of a signaling NaN should return a
quiet NaN. Fix this in extendsfdf2.
2014-05-18 Aurelien Jarno aurel...@aurel32.net
PR target/61219
* config/arm/ieee754-df.S (extendsfdf2): Convert sNaN to qNaN.
Index: libgcc/config/arm/ieee754-df.S
===
--- libgcc/config/arm/ieee754-df.S(revision 210588)
+++ libgcc/config/arm/ieee754-df.S(working copy)
@@ -473,11 +473,15 @@
eorne xh, xh, #0x3800 @ fixup exponent otherwise.
RETc(ne)@ and return it.
- teq r2, #0 @ if actually 0
- do_it ne, e
- teqne r3, #0xff00 @ or INF or NAN
+ bicsr2, r2, #0xff00 @ isolate mantissa
+ do_it eq @ if 0, that is ZERO or INF,
RETc(eq)@ we are done already.
+ teq r3, #0xff00 @ check for NAN
+ do_it eq, t
+ orreq xh, xh, #0x0008 @ change to quiet NAN
+ RETc(eq)@ and return it.
+
@ value was denormalized. We can normalize it now.
do_push {r4, r5, lr}
mov r4, #0x380 @ setup corresponding exponent
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Re: [PATCH] Trust TREE_ADDRESSABLE
Hmm, I don't see this.
Usual scheduler-sensitive stuff I guess, here's the assembly I have:
movqaliasing3_pkg__pointer(%rip), %rax
testq %rax, %rax
je .L6
cmpl$5, aliasing3_pkg__block(%rip)
movl$5, (%rax)
insns #4 and #5 have been wrongly swapped.
In Ada we don't mark (external) variables as addressable if we don't
see their address taken.
You have to (now). The testing was of course to detect this...
Well, you need to define what TREE_ADDRESSABLE means now, because according to
/* In VAR_DECL, PARM_DECL and RESULT_DECL nodes, nonzero means address
of this is needed. So it cannot be in a register.
[...]
#define TREE_ADDRESSABLE(NODE) ((NODE)-base.addressable_flag)
your change is clearly wrong and the Ada compiler clearly right. And auditing
the various front-ends might also be in order here if they really need to mark
every single external variable as addressable to be safe wrt aliasing.
Obvious testcase for the C compiler attached, compile at -O2.
This looks like a big hack to work around an LTO issue...
--
Eric Botcazouextern int a;
extern int *p;
int main (void)
{
*p = 0;
a = 1;
test ();
}extern void abort (void);
int a;
int *p = a;
void test (void)
{
if (a != 1)
abort ();
}
Re: [PATCH] Sink loads (fix PR59299)
The following adds the missing capability to sink loads to tree-ssa-sink.c. This enables sinking of loads and dependent expressions into code paths that uses them (thus performing partial dead code elimination on loads). There is a much heavier implementation in tree-ssa-loop-im.c attached to PR tree-opt/57186 as well as 3 testcases. The algorithm is simple (similar to that sinking stores) to be light-weight on compile-time thus it may miss some opportunities but it fires quite a bit on GCC itself. Is it sufficient for the aforementioned testcases? -- Eric Botcazou
Re: [PATCH] Trust TREE_ADDRESSABLE
On Sat, Jun 7, 2014 at 12:59 PM, Eric Botcazou wrote: In Ada we don't mark (external) variables as addressable if we don't see their address taken. You have to (now). The testing was of course to detect this... Well, you need to define what TREE_ADDRESSABLE means now, because according to /* In VAR_DECL, PARM_DECL and RESULT_DECL nodes, nonzero means address of this is needed. So it cannot be in a register. [...] #define TREE_ADDRESSABLE(NODE) ((NODE)-base.addressable_flag) your change is clearly wrong and the Ada compiler clearly right. Clearly? An external variable is a VAR_DECL that cannot be in a register. It can be loaded into a register (or stored into), and for that its address is needed. So I would expect an external variable to be marked addressable by default. I was always surprised that this was not the case before Richi's change. And auditing the various front-ends might also be in order here if they really need to mark every single external variable as addressable to be safe wrt aliasing. Right. And this should have been done (clearly ;-) ) before the patch was committed... Ciao! Steven
Fix bug in tree-ssa-tail-merge.c
This is a regression present on the mainline and 4.9 branch (at least): the
recently added tree-ssa-tail-merge.c pass totally disregards the static chain
of calls, so it can wrongly merge 2 calls to the same function with different
instances of a non-local frame object generated by inlining.
Tested on x86_64-suse-linux, applied on mainline and 4.9 branch as obvious.
2014-06-07 Eric Botcazou ebotca...@adacore.com
* tree-ssa-tail-merge.c (same_succ_hash): Hash the static chain of a
call statement, if any.
(gimple_equal_p) GIMPLE_CALL: Compare the static chain of the call
statements, if any. Tidy up.
2014-06-07 Eric Botcazou ebotca...@adacore.com
* gnat.dg/opt38.adb: New test.
* gnat.dg/opt38_pkg.ad[sb]: New helper.
--
Eric BotcazouIndex: tree-ssa-tail-merge.c
===
--- tree-ssa-tail-merge.c (revision 211313)
+++ tree-ssa-tail-merge.c (working copy)
@@ -481,7 +481,11 @@ same_succ_hash (const_same_succ e)
hashval = iterative_hash_hashval_t
((hashval_t) gimple_call_internal_fn (stmt), hashval);
else
- hashval = iterative_hash_expr (gimple_call_fn (stmt), hashval);
+ {
+ hashval = iterative_hash_expr (gimple_call_fn (stmt), hashval);
+ if (gimple_call_chain (stmt))
+ hashval = iterative_hash_expr (gimple_call_chain (stmt), hashval);
+ }
for (i = 0; i gimple_call_num_args (stmt); i++)
{
arg = gimple_call_arg (stmt, i);
@@ -1121,18 +1125,23 @@ gimple_equal_p (same_succ same_succ, gim
switch (gimple_code (s1))
{
case GIMPLE_CALL:
- if (gimple_call_num_args (s1) != gimple_call_num_args (s2))
- return false;
if (!gimple_call_same_target_p (s1, s2))
return false;
+ t1 = gimple_call_chain (s1);
+ t2 = gimple_call_chain (s2);
+ if (!gimple_operand_equal_value_p (t1, t2))
+ return false;
+
+ if (gimple_call_num_args (s1) != gimple_call_num_args (s2))
+ return false;
+
for (i = 0; i gimple_call_num_args (s1); ++i)
{
t1 = gimple_call_arg (s1, i);
t2 = gimple_call_arg (s2, i);
- if (gimple_operand_equal_value_p (t1, t2))
- continue;
- return false;
+ if (!gimple_operand_equal_value_p (t1, t2))
+ return false;
}
lhs1 = gimple_get_lhs (s1);-- { dg-do run }
-- { dg-options -O2 -gnatn }
with Opt38_Pkg; use Opt38_Pkg;
procedure Opt38 is
begin
Test (-1);
end;
package body Opt38_Pkg is
procedure Proc (I : Integer);
pragma Inline (Proc);
procedure Proc (I : Integer) is
procedure Inner;
pragma No_Inline (Inner);
procedure Inner is
begin
if I /= 110 then
raise Program_Error;
end if;
end;
begin
if I 0 then
Inner;
end if;
end;
procedure Test (I : Integer) is
begin
if I -1 then
Proc (I);
else
Proc (I + 111);
end if;
end;
end Opt38_Pkg;
package Opt38_Pkg is
procedure Test (I : Integer);
end Opt38_Pkg;
Re: [PATCH] Trust TREE_ADDRESSABLE
An external variable is a VAR_DECL that cannot be in a register. It can be loaded into a register (or stored into), and for that its address is needed. So I would expect an external variable to be marked addressable by default. address of this is needed historically means ADDR_EXPR of this is taken. -- Eric Botcazou
Re: [PATCH] Trust TREE_ADDRESSABLE
On June 7, 2014 1:54:06 PM CEST, Steven Bosscher stevenb@gmail.com wrote: On Sat, Jun 7, 2014 at 12:59 PM, Eric Botcazou wrote: In Ada we don't mark (external) variables as addressable if we don't see their address taken. You have to (now). The testing was of course to detect this... Well, you need to define what TREE_ADDRESSABLE means now, because according to /* In VAR_DECL, PARM_DECL and RESULT_DECL nodes, nonzero means address of this is needed. So it cannot be in a register. [...] #define TREE_ADDRESSABLE(NODE) ((NODE)-base.addressable_flag) your change is clearly wrong and the Ada compiler clearly right. Clearly? An external variable is a VAR_DECL that cannot be in a register. It can be loaded into a register (or stored into), and for that its address is needed. So I would expect an external variable to be marked addressable by default. I was always surprised that this was not the case before Richi's change. Well, honza was as well, so I thought I must be wrong. And auditing the various front-ends might also be in order here if they really need to mark every single external variable as addressable to be safe wrt aliasing. Right. And this should have been done (clearly ;-) ) before the patch was committed... I thought that bootstrap and regtest plus what I remember from debug sessions was enough. Anyway, an easy fix is to make all globals TREE_ADDRESSABLE somewhere in the varpool code. But I have no idea how to audit the frontends and judge their language specific knowledge they put into deciding whether a deck may have its address taken. Richard. Ciao! Steven
Re: [PATCH] Trust TREE_ADDRESSABLE
On June 7, 2014 2:06:47 PM CEST, Eric Botcazou ebotca...@adacore.com wrote: An external variable is a VAR_DECL that cannot be in a register. It can be loaded into a register (or stored into), and for that its address is needed. So I would expect an external variable to be marked addressable by default. address of this is needed historically means ADDR_EXPR of this is taken. ... In this particular translation unit you mean? That would be worthless information for decls also reachable from elsewhere. So - let's say history is something of the past? Richard.
Re: [PATCH, libgfortran] PR 56981 Flush buffer at record boundaries
On 06/06/2014 07:47 PM, Janne Blomqvist wrote: PING On Tue, May 27, 2014 at 11:50 PM, Janne Blomqvist blomqvist.ja...@gmail.com wrote: Hi, the attached patch implements the idea in https://gcc.gnu.org/ml/fortran/2013-04/msg00258.html ; though it turned out it was much simpler than what I envisaged back then. With this patch, we no longer seek back and forth when writing small records with sequential unformatted, which previously happened due to the buffer filling up when not on record boundaries. Performance-wise, I didn't really see any difference on Linux/tmpfs, but maybe it makes a difference in other circumstances. And of course, as a side-effect, it makes sequential unformatted work on unseekable devices such as pipes as long as the records are small, although I'm not sure this is something we want to advertise to users. Regtested on x86_64-unknown-linux-gnu, Ok for trunk? 2014-05-27 Janne Blomqvist j...@gcc.gnu.org PR libfortran/56981 * io/unix.h (struct stream_vtable): Add new member function, markeor. (smarkeor): New inline function. (flush_if_unbuffered): Remove prototype. * io/unix.c (raw_markeor): New function. (raw_vtable): Initialize markeor member. (buf_markeor): New function. (buf_vtable): Initialize markeor member. (mem_vtable): Likewise. (mem4_vtable): Likewise. (flush_if_unbuffered): Remove function. * io/transfer.c (next_record): Call smarkeor instead of flush_if_unbuffered. -- Janne Blomqvist OK, thanks for patch.
[4.9] Re: std::quoted doesn't respect padding - backport from trunk.
On 06/06/2014 11:41 PM, Ed Smith-Rowland wrote:
On 06/06/2014 10:27 AM, Jonathan Wakely wrote:
On 06/06/14 10:08 -0400, Ed Smith-Rowland wrote:
I'll look at rdbuf. Error in rdbuf? Do I need to do something?
No, just me being dumb. The ostream::operator(streambuf*) overload
behaves as an unformatted output function, so won't obey the padding,
which is exactly what you're trying to fix. Sorry for suggesting it.
As committed..
I'll backport to 4.9 tomorrow or Sunday.
This tested clean on gcc-4.9 as expected.
I just noted backport in the ChangeLog.
2014-06-07 Ed Smith-Rowland 3dw...@verizon.net
DR 2344 - std::quoted doesn't respect padding
* include/std/iomanip: Allow for padding in quoted inserters.
* testsuite/27_io/manipulators/standard/char/dr2344.cc: New.
* testsuite/27_io/manipulators/standard/wchar_t/dr2344.cc: New.
Index: include/std/iomanip
===
--- include/std/iomanip (revision 211313)
+++ include/std/iomanip (working copy)
@@ -41,7 +41,10 @@
#if __cplusplus = 201103L
#include locale
+#if __cplusplus 201103L
+#include sstream // used in quoted.
#endif
+#endif
namespace std _GLIBCXX_VISIBILITY(default)
{
@@ -342,7 +345,6 @@
/**
* @brief Struct for delimited strings.
- *The left and right delimiters can be different.
*/
templatetypename _String, typename _CharT
struct _Quoted_string
@@ -364,8 +366,10 @@
};
/**
- * @brief Inserter for delimited strings.
- *The left and right delimiters can be different.
+ * @brief Inserter for quoted strings.
+ *
+ * _GLIBCXX_RESOLVE_LIB_DEFECTS
+ * DR 2344 quoted()'s interaction with padding is unclear
*/
templatetypename _CharT, typename _Traits
auto
@@ -372,21 +376,24 @@
operator(std::basic_ostream_CharT, _Traits __os,
const _Quoted_stringconst _CharT*, _CharT __str)
{
- __os __str._M_delim;
+ std::basic_ostringstream_CharT, _Traits __ostr;
+ __ostr __str._M_delim;
for (const _CharT* __c = __str._M_string; *__c; ++__c)
{
if (*__c == __str._M_delim || *__c == __str._M_escape)
- __os __str._M_escape;
- __os *__c;
+ __ostr __str._M_escape;
+ __ostr *__c;
}
- __os __str._M_delim;
+ __ostr __str._M_delim;
- return __os;
+ return __os __ostr.str();
}
/**
- * @brief Inserter for delimited strings.
- *The left and right delimiters can be different.
+ * @brief Inserter for quoted strings.
+ *
+ * _GLIBCXX_RESOLVE_LIB_DEFECTS
+ * DR 2344 quoted()'s interaction with padding is unclear
*/
templatetypename _CharT, typename _Traits, typename _String
auto
@@ -393,16 +400,17 @@
operator(std::basic_ostream_CharT, _Traits __os,
const _Quoted_string_String, _CharT __str)
{
- __os __str._M_delim;
+ std::basic_ostringstream_CharT, _Traits __ostr;
+ __ostr __str._M_delim;
for (auto __c : __str._M_string)
{
if (__c == __str._M_delim || __c == __str._M_escape)
- __os __str._M_escape;
- __os __c;
+ __ostr __str._M_escape;
+ __ostr __c;
}
- __os __str._M_delim;
+ __ostr __str._M_delim;
- return __os;
+ return __os __ostr.str();
}
/**
Index: testsuite/27_io/manipulators/standard/char/dr2344.cc
===
--- testsuite/27_io/manipulators/standard/char/dr2344.cc(revision 0)
+++ testsuite/27_io/manipulators/standard/char/dr2344.cc(working copy)
@@ -0,0 +1,50 @@
+// { dg-do run }
+// { dg-options -std=gnu++14 }
+
+// Copyright (C) 2014 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
+// http://www.gnu.org/licenses/.
+
+// 27.7.6 - Quoted manipulators[quoted.manip]
+
+#include sstream
+#include iomanip
+#include testsuite_hooks.h
+
+void
+test01()
+{
+ bool test [[gnu::unused]] = true;
+
+ std::ostringstream ssx;
+ ssx [ std::left std::setfill('x') std::setw(20) R(AB
\CD\ EF) ];
+ VERIFY( ssx.str() == R([AB
Re: [PATCH] Trust TREE_ADDRESSABLE
... In this particular translation unit you mean? Yes, in the translation unit being processed. That would be worthless information for decls also reachable from elsewhere. It's the information: ADDR_EXPR of this DECL is taken somewhere in the IL, it's no more or not less worthless than any other information. So - let's say history is something of the past? Maybe, but it's an annoying precedent: no clear explanation for the change, no testcase and no audit of the affected front-ends (all I guess). That should really have been discussed beforehand. -- Eric Botcazou
Re: RFA: Rework FOR_BB_INSNS iterators
On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
The two parts of the loop condition are really handling two different
kinds of block: ones like entry and exit that are completely empty
and normal ones that have at least a block note. There's no real
need to check for null INSNs in normal blocks.
Block notes should go away some day, they're just remains of a time
when there was no actual CFG in the compiler.
Also, refetching NEXT_INSN (BB_END (BB)) for each iteration can be expensive.
If we're prepared to say that the loop body can't insert instructions
for another block immediately after BB_END,
This can happen with block_label() if e.g. a new jump is inserted
for one reason or another. Not very likely for passes working in
cfglayout mode, but post-RA there may be places that need this
(splitters, peepholes, machine dependent reorgs, etc.).
So even if we're prepared to say what you suggest, I don't think you
can easily enforce it.
It's easier to change these macros if they define the INSN variables
themselves.
If you're going to hack these iterators anyway (much appreciated BTW),
I suggest to make them similar to the gsi, loop, edge, and bitmap
iterators: A new insn_iterator structure to hold the variables and
static inline functions wrapped in the macros. This will also be
helpful if (when) we ever manage to make the type for an insn a
non-rtx...
+/* For iterating over insns in a basic block. The iterator allows the loop
+ body to delete INSN. It also ignores any instructions that the body
+ inserts between INSN and the following instruction. */
+#define FOR_BB_INSNS(BB, INSN) \
+ for (rtx INSN = BB_HEAD (BB), INSN##_cond_ = INSN, INSN##_next_, \
+ INSN##_end_ = INSN ? NEXT_INSN (BB_END (BB)) : NULL_RTX;
\
+ INSN##_cond_ (INSN##_next_ = NEXT_INSN (INSN), true);
\
+ INSN = INSN##_next_,\
+ INSN##_cond_ = (INSN != INSN##_end_ ? (rtx) 1 : NULL_RTX))
This just makes my eyes hurt...
What about cases where a FOR_BB_INSNS is terminated before reaching
the end of a basic block, and you need to know at what insn you
stopped? Up to now, you could do:
rtx insn; basic_block bb;
FOR_BB_INSNS (bb, insn)
{
... // do stuff
if (something) break;
}
do_something_with (insn);
Looks like this is no longer possible with the implementation of
FOR_BB_INSNS of your patch.
I would not approve this patch, but let's wait what others think of it.
Ciao!
Steven
Re: [patch, mips, tree] align microMIPS functions to 16 bits with -Os
On 06/06/2014 01:44 AM, Richard Biener wrote: On Fri, 6 Jun 2014, Richard Sandiford wrote: [snip] How about initialising the DECL_ALIGN to: (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn ? 2 * BITS_PER_UNIT : BITS_PER_UNIT) instead of function_boundary (NULL)? That way we might even be able to rely on DECL_ALIGN in get_object_alignment_2. Not sure about that, but initializing that way certainly looks reasonable. Btw, maybe we should call function_boundary to properly initialize DECL_ALIGN earlier than output time, for example in cgraph_finalize_function. There might be an IPA pass sorting functions after their alignment to squeeze some more bits by reducing possible padding. Hr. I was looking again at handle_aligned_attribute in c-common.c, which gives an error if you try to decrease the alignment from the target-specific default given by FUNCTION_BOUNDARY. If we don't invoke the new hook to set the default until after alignment attributes are handled, we'll have to duplicate that logic. More problematically, earlier in that file there is also code to handle the __alignof__ operator. When the operand is a function type, it uses FUNCTION_BOUNDARY; when the operand is a FUNCTION_DECL, it uses DECL_ALIGN. So, if we defer setting the target-specific default after the front end, we could potentially break all code that uses __alignof__ on functions :-( Like I mentioned before, my guess was that the right place to set DECL_ALIGN for functions is in layout_decl or some new equivalent for functions. Postponing it to output time, or some random optimization pass, seems likely to cause inconsistent behavior. -Sandra
Re: __float128 typeinfo
Hi again,
On 06/07/2014 11:42 AM, Marc Glisse wrote:
On Fri, 6 Jun 2014, Paolo Carlini wrote:
On 06/06/2014 04:16 PM, Marc Glisse wrote:
abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I
would recommend investigating in some detail what's going on at your
end...
Ah, no, abi_check actually passed in the regular bootstrap, it is in
the debug builds (-O0) that it fails because more than a hundred
non-inlined inline functions find their way into the library. False
alarm.
I'm finishing testing the attached... So far, it works fine for me at -O0.
Paolo.
Index: config/abi/pre/gnu.ver
===
--- config/abi/pre/gnu.ver (revision 211346)
+++ config/abi/pre/gnu.ver (working copy)
@@ -24,11 +24,9 @@
# Names inside the 'extern' block are demangled names.
extern C++
{
- std::[A-Z]*;
- std::a[a-c]*;
- std::ad[a-n]*;
- std::ad[p-z]*;
- std::a[e-z]*;
+# std::[A-Z]*;
+# std::a[e-z]*;
+ std::ad[a-np-z]*;
# std::ba[a-r]*;
std::basic_[a-e]*;
std::basic_f[a-h]*;
@@ -45,12 +43,10 @@
std::basic_istr[f-z]*;
std::basic_i[t-z]*;
std::basic_[j-n]*;
- std::basic_o[a-e]*;
# std::basic_ofstream;
# std::basic_o[g-z]*;
- std::basic_o[g-r]*;
- std::basic_ostr[a-d]*;
- std::basic_ostr[f-z]*;
+ std::basic_o[a-eg-r]*;
+ std::basic_ostr[a-df-z]*;
std::basic_[p-r]*;
# std::basic_streambuf
# std::basic_string
@@ -64,20 +60,20 @@
# std::c[i-z]*;
std::c[i-n]*;
# std::condition_variable;
- std::co[^n]*;
- std::c[p-s]*;
+# std::co[^n]*;
+ std::cout;
+# std::codecvt*;
+ std::collate*;
+ std::c[p-sv-z]*;
std::cu[^r]*;
# std::current_exception
- std::c[v-z]*;
# std::[d-g]*;
- std::d[a-d]*;
- std::d[f-n]*;
+ std::d[a-df-np-z]*;
std::domain_error::d*;
# std::domain_error::~d*;
- std::d[p-z]*;
- std::e[a-q]*;
+ std::e[a-m]*;
std::error[^_]*;
- std::e[s-z]*;
+# std::e[s-z];
std::gslice*;
std::h[^a]*;
std::i[a-m]*;
@@ -84,9 +80,24 @@
std::invalid_argument::i*;
# std::invalid_argument::~i*;
# std::ios_base::[A-Ha-z]*;
- std::ios_base::[A-Ha-f]*;
+ std::ios_base::[A-Ha-e]*;
+ std::ios_base::fixed;
+ std::ios_base::float;
+ std::ios_base::failbit;
+ std::ios_base::failure*;
+ std::ios_base::floatfield;
std::ios_base::goodbit;
- std::ios_base::[h-z]*;
+# std::ios_base::[h-z]*;
+ std::ios_base::[h-otu]*;
+ std::ios_base::right;
+ std::ios_base::showpos;
+ std::ios_base::scientific;
+ std::ios_base::showbase;
+ std::ios_base::showpoint;
+ std::ios_base::skipws;
+ std::ios_base::sync_with_stdio*;
+ std::ios_base::register_callback*;
+ std::ios_base::xalloc*;
std::ios_base::_M_grow_words*;
std::ios_base::_M_init*;
std::ios_base::Init::[A-Za-z]*;
@@ -96,19 +107,19 @@
# std::istreambuf_iterator
std::istringstream*;
std::istrstream*;
- std::i[t-z]*;
+# std::i[t-z]*;
std::[A-Zj-k]*;
std::length_error::l*;
# std::length_error::~l*;
std::logic_error*;
std::locale::[A-Za-e]*;
- std::locale::facet::[A-Za-z]*;
+ std::locale::facet::[A-Zg-z]*;
std::locale::facet::_S_get_c_locale*;
std::locale::facet::_S_clone_c_locale*;
std::locale::facet::_S_create_c_locale*;
std::locale::facet::_S_destroy_c_locale*;
std::locale::[A-Zg-h]*;
- std::locale::id::[A-Za-z]*;
+# std::locale::id::[A-Za-z]*;
std::locale::id::_M_id*;
std::locale::[A-Zj-z]*;
std::locale::_[A-Ha-z]*;
@@ -117,15 +128,14 @@
std::locale::_[J-Ra-z]*;
std::locale::_S_normalize_category*;
std::locale::_[T-Za-z]*;
-# std::[A-Zm-r]*;
-# std::[A-Zm]*;
- std::[A-Z]*;
- std::messages*;
- std::money*;
+# std::messages*;
+# std::money*;
# std::n[^u]*;
- std::n[^aue]*;
- std::nu[^m]*;
- std::num[^e]*;
+# std::n[^aue]*;
+ std::nothrow;
+# std::nu[^m]*;
+# std::num[^e]*;
+ std::numpunct*;
std::ostrstream*;
std::out_of_range::o*;
# std::out_of_range::~o*;
@@ -145,18 +155,16 @@
std::strstreambuf*;
# std::t[a-q]*;
std::t[a-g]*;
- std::th[a-h]*;
- std::th[j-q]*;
- std::th[s-z]*;
+ std::th[a-hj-qs-z]*;
# std::t[i-n]*;
std::tr1::h[^a]*;
- std::t[s-z]*;
+# std::t[s-z]*;
# std::[A-Zu-z]*;
std::underflow_error::u*;
# std::underflow_error::~u*;
std::uncaught_exception*;
std::unexpected*;
- std::[A-Zv-z]*;
+ std::[A-Zw-z]*;
std::_List_node_base::hook*;
