Re: [PATCH, libbacktrace] Don't call __sync_lock_test_and_set if we don't have sync functions
On Sun, Dec 9, 2012 at 11:08 AM, John David Anglin wrote: > On hppa*-*-hpux*, we don't have sync functions. However, > __sync_lock_test_and_set is called in backtrace_alloc and > backtrace_free. This causes an abort before ICE proccessing > is fully complete. > > hppa64 is an ELF target and backtraces are nominally supported. > > The attached change avoids calling __sync_lock_test_and_set > if we don't have sync functions. As a result, the memory is > leaked. Sorry for the delay. I think it's better to fix this the same way we handle the other sync functions, as in this patch. Bootstrapped and ran libbacktrace and go testsuites on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2013-01-01 Ian Lance Taylor PR other/55536 * mmap.c (backtrace_alloc): Don't call sync functions if not threaded. (backtrace_free): Likewise. foo.patch Description: Binary data
libbacktrace patch committed: Don't use -I ../gcc/include
There is no reason for libbacktrace to try to include files from ../gcc/include. All the required header files can now be found in libgcc. I'm not sure why I added the -I ../gcc/include in the first place; perhaps I was thinking of code from before the libgcc migration. Using -I ../gcc/include can in some unusual cases lead to the difficulties described in PR 54834. This patch fixes the problem. Bootstrapped and ran libbacktrace testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2013-01-01 Ian Lance Taylor PR bootstrap/54834 * Makefile.am (AM_CPPFLAGS): Remove -I ../gcc/include and -I $(MULTIBUILDTOP)/../../gcc/include. * Makefile.in: Rebuild. Index: Makefile.am === --- Makefile.am (revision 194764) +++ Makefile.am (working copy) @@ -32,7 +32,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \ - -I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/include + -I ../libgcc AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG)
[PATCH] libiberty simple object XCOFF support
The attached patch is a start at libiberty simple object support for AIX XCOFF file format. With this patch, the simple object API can read and write XCOFF files. I need to investigate a little more about the proper attributes for XCOFF sections written using sobj. There are open questions about how to wedge GCC LTO support into the AIX XCOFF file format. I am unsure if LTO can be an additional section in the XCOFF file or should be new CSECTs in an existing section. Maybe CSECTs in the XCOFF comment section. * simple-object-xcoff.c: New file. * Makefile.in: Add it to build machinery. * simple-object-common.h (simple_object_xcoff_functions): Declare. * simple-object. (format_functions): Add simple_object_xcoff_functions. Bootstrapped on powerpc-ibm-aix7.1.0.0 Thanks, David simple-object-xcoff.diff Description: Binary data
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 6:04 PM, David Edelsohn wrote: > There are open questions about how to wedge GCC LTO support into the > AIX XCOFF file format. I am unsure if LTO can be an additional section > in the XCOFF file or should be new CSECTs in an existing section. > Maybe CSECTs in the XCOFF comment section. Does XCOFF differ a lot from COFF? Otherwise you could take some ideas from simple-object-coff.c. Ciao! Steven
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 9:10 AM, Steven Bosscher wrote: > > Does XCOFF differ a lot from COFF? In a word, yes. While COFF and XCOFF share a distant ancestor, they are in effect completely different object file formats. Ian
[Patch, Darwin, ppc] constrain processor usage for m32.
Hi Iain, Mike and Andrew, I have been having issues compiling WebKit with mcpu=970 (or mcpu=G5) without afterwards passing mno-powerpc64 or m32 in to explicitly turn 64 bit instructions off. That was using Apple gcc 5666.3, which is Apples last published version and based on 4.2.1 . I also had another issue with ftree-vrp and found that in some later 4.2.x release a bug related to that was fixed, so I went ahead and merged 4.2.2 - 4.2.4 into Apple's gcc 4.2.1 sources. After that both issues are now gone! So, in gcc 4.2.4 I don't have anymore issues with usage of 64 bit instructions, hence this wasn't broken at that point point in time. Related bug report following: However I also tried to build the mozilla JavaScript library using gcc 4.7.2 as shared library optimized for the G5 explicitly. That works well and neither linker (ld64 97.17), nor mach-o binary tools nor compiler complain about anything. But OS X dyld throws an error complaining about unknown local relocation type when trying to load that library using dlopen(). Examining the library using otool does not show any incorrect local relocation, so I don't know what's going wrong. Might be a dyld bug but when I build with optimization turned off (- O0) the library loads and works fine. I tried to switch off as much optimizations turned on by -O1 as possible (building with -O1 does also cause the problem) but I can't get it working. I even explicitely disabled as much optimization passes as possible (using -fdisable-*) but to no avail. I could try debugging using gdb in order to find out the code that causes the problem. Or do you have any other ideas? Tobias
[patch, Fortran] PR 55806 - Inefficient ANY with array constructors
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
This fixes a bug noted by Michael Metcalf.
Regression-tested. OK for trunk?
Thomas
2013-01-01 Thomas Koenig
PR fortran/55806
* frontend-passes.c (optimize_reduction): New function,
including prototype.
(callback_reduction): Likewise.
(gfc_run_passes): Also run optimize_reduction.
(copy_walk_reduction_arg): New function.
(dummy_code_callback): New function.
2013-01-01 Thomas Koenig
PR fortran/55806
* gfortran.dg/array_constructor_40.f90: New test.
! { dg-do run }
! { dg-options "-ffrontend-optimize -fdump-tree-original" }
! PR 55806 - replace ANY intrinsic for array
! constructor with .or.
module mymod
implicit none
contains
subroutine bar(a,b,c, lo)
real, dimension(3,3), intent(in) :: a,b
logical, dimension(3,3), intent(in) :: lo
integer, intent(out) :: c
real, parameter :: acc = 1e-4
integer :: i,j
c = 0
do i=1,3
if (any([abs(a(i,1) - b(i,1)) > acc, &
abs(a(i,2) - b(i,2)) > acc, &
abs(a(i,3) - b(i,3)) > acc, lo(i,:), &
(j==i+1,j=3,8)])) cycle
c = c + i
end do
end subroutine bar
end module mymod
program main
use mymod
implicit none
real, dimension(3,3) :: a,b
integer :: c
logical lo(3,3)
data a/1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9/
b = a
b(2,2) = a(2,2) + 0.2
lo = .false.
lo(3,3) = .true.
call bar(a,b,c,lo)
if (c /= 1) call abort
end program main
! { dg-final { scan-tree-dump-times "while" 2 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 194760)
+++ frontend-passes.c (Arbeitskopie)
@@ -40,6 +40,8 @@ static bool optimize_lexical_comparison (gfc_expr
static void optimize_minmaxloc (gfc_expr **);
static bool is_empty_string (gfc_expr *e);
static void doloop_warn (gfc_namespace *);
+static void optimize_reduction (gfc_namespace *);
+static int callback_reduction (gfc_expr **, int *, void *);
/* How deep we are inside an argument list. */
@@ -107,6 +109,7 @@ gfc_run_passes (gfc_namespace *ns)
expr_array = XNEWVEC(gfc_expr **, expr_size);
optimize_namespace (ns);
+ optimize_reduction (ns);
if (gfc_option.dump_fortran_optimized)
gfc_dump_parse_tree (ns, stdout);
@@ -180,7 +183,172 @@ optimize_expr (gfc_expr **e, int *walk_subtrees AT
return 0;
}
+/* Auxiliary function to handle the arguments to reduction intrnisics.
+ If the function is a scalar, just copy it; otherwise Returns the new
+ element, the old one can be freed. */
+static gfc_expr *
+copy_walk_reduction_arg (gfc_expr *e, gfc_expr *fn)
+{
+ gfc_expr *fcn;
+ const char *new_name;
+ gfc_actual_arglist *actual_arglist;
+
+ if (e->rank == 0 || e->expr_type == EXPR_FUNCTION)
+fcn = gfc_copy_expr (e);
+ else
+{
+ fcn = gfc_get_expr ();
+ fcn->expr_type = EXPR_FUNCTION;
+ fcn->value.function.isym = fn->value.function.isym;
+ actual_arglist = gfc_get_actual_arglist ();
+ actual_arglist->expr = gfc_copy_expr (e);
+ actual_arglist->next = gfc_get_actual_arglist ();
+ fcn->value.function.actual = actual_arglist;
+ fcn->ts = fn->ts;
+
+ switch (fn->value.function.isym->id)
+ {
+ case GFC_ISYM_SUM:
+ new_name = "__internal_sum";
+ break;
+
+ case GFC_ISYM_PRODUCT:
+ new_name = "__internal_product";
+ break;
+
+ case GFC_ISYM_ANY:
+ new_name = "__internal_any";
+ break;
+
+ case GFC_ISYM_ALL:
+ new_name = "__internal_all";
+ break;
+
+ default:
+ abort ();
+ }
+
+ gfc_get_sym_tree (new_name, current_ns, &fcn->symtree, false);
+ fcn->symtree->n.sym->attr.flavor = FL_PROCEDURE;
+ fcn->symtree->n.sym->attr.function = 1;
+ fcn->symtree->n.sym->attr.elemental = 1;
+ fcn->symtree->n.sym->attr.referenced = 1;
+ fcn->symtree->n.sym->attr.access = ACCESS_PRIVATE;
+ gfc_commit_symbol (fcn->symtree->n.sym);
+}
+
+ (void) gfc_expr_walker (&fcn, callback_reduction, NULL);
+
+ return fcn;
+}
+
+/* Callback function for optimzation of reductions to scalars. Transform
+ ANY ([f1,f2,f3, ...]) to f1 .or. f2 .or. f3 .or. ..., with ANY,
+ SUM and PRODUCT correspondingly. Handly only the simple cases without
+ MASK and DIM. */
+
+static int
+callback_reduction (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data ATTRIBUTE_UNUSED)
+{
+ gfc_expr *fn, *arg;
+ gfc_intrinsic_op op;
+ gfc_isym_id id;
+ gfc_actual_arglist *a;
+ gfc_actual_arglist *dim;
+ gfc_constructor *c;
+ gfc_expr *res, *new_expr;
+
+ fn = *e;
+
+ if (fn->rank != 0 || fn->expr_type != EXPR_FUNCTION
+ || fn->value.function.isym == NULL)
+return 0;
+
+ id = fn->value.function.isym->id;
+
+ if (id
Re: [patch] std::unique_ptr improvements
On 12/28/12, Jonathan Wakely wrote:
> On 28 December 2012 01:51, Lawrence Crowl wrote:
>> I'm not getting errors when converting from derived to base.
>> E.g. the following compiles, when it should not.
>>
>> std::unique_ptr acb_ad(new derived[3]);
>
> I get an error:
>
> shm$ cat up.cc
> #include
> struct base { };
> struct derived : base { virtual ~derived() = default; };
> std::unique_ptr acb_ad(new derived[3]);
> shm$
> shm$ g++11 up.cc -c
> up.cc:4:53: error: use of deleted function ‘std::unique_ptr<_Tp [],
> _Dp>::unique_ptr(_Up*) [with _Up = derived; =
> void; _Tp = const base; _Dp = std::default_delete]’
> std::unique_ptr acb_ad(new derived[3]);
> ^
> In file included from /home/redi/gcc/4.x/include/c++/4.8.0/memory:81:0,
> from up.cc:1:
> /home/redi/gcc/4.x/include/c++/4.8.0/bits/unique_ptr.h:343:2: error:
> declared here
> unique_ptr(_Up* __p) = delete;
> ^
That was pilot error on my part. However, I've been having trouble
when the argument to the constructor or reset has a conversion
operator. The code does distinquish between a safe conversion to
base and an unsafe conversion to derived.
Here is a simplified version of the problem. The code as is fails
to reject the last two calls to accept. The primary reason is that
is_convertable permits both the invocation of the conversion operator
and the derived to base conversion. At present, I see no way to
get a handle on the 'natural' return type of the conversion operator.
#include
struct base { };
struct derived : base { };
template
typename std::enable_if<
std::is_convertible< F, T* >::value,
T*
>::type
accept(F arg) { return arg; }
template
typename std::enable_if<
!std::is_convertible< F(*)[], T(*)[] >::value,
T*
>::type
accept(F* arg) = delete;
struct cvt_b {
operator base*() { return 0; }
};
struct cvt_d {
operator derived*() { return 0; }
};
int main()
{
// should PASS
accept< base >( (base*)0 );
accept< const base >( (base*)0 );
accept< base >( cvt_b() );
accept< const base >( cvt_b() );
// should FAIL
accept< base >( (derived*)0 );
accept< const base >( (derived*)0 );
accept< base >( cvt_d() );
accept< const base >( cvt_d() );
}
--
Lawrence Crowl
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
On Jan 1, 2013, at 10:03 AM, Tobias Netzel wrote: > Or do you have any other ideas? I don't. I'd grab the .s files (compile with -save-temps) and start stripping things out til it loads, then then last thing stripped was the thing that broke it.
Re: [patch] std::unique_ptr improvements
On 1 January 2013 20:40, Lawrence Crowl wrote: > > That was pilot error on my part. However, I've been having trouble > when the argument to the constructor or reset has a conversion > operator. The code does distinquish between a safe conversion to > base and an unsafe conversion to derived. > > Here is a simplified version of the problem. The code as is fails > to reject the last two calls to accept. The primary reason is that > is_convertable permits both the invocation of the conversion operator > and the derived to base conversion. At present, I see no way to > get a handle on the 'natural' return type of the conversion operator. Is the issue here that Geoffrey's proposed resolution allows any conversions (safe or not) if the source type is not a built-in pointer, i.e. is some user-defined type? So a user-defined type that refers an array of derived classes is allowed to be converted to an array of base, even though that's not safe. Howard has strongly objected to this part of the P/R.
Re: [patch] std::unique_ptr improvements
On 1/1/13, Jonathan Wakely wrote: > On 1 January 2013 20:40, Lawrence Crowl wrote: >> That was pilot error on my part. However, I've been having trouble >> when the argument to the constructor or reset has a conversion >> operator. The code does distinquish between a safe conversion to >> base and an unsafe conversion to derived. >> >> Here is a simplified version of the problem. The code as is fails >> to reject the last two calls to accept. The primary reason is that >> is_convertable permits both the invocation of the conversion operator >> and the derived to base conversion. At present, I see no way to >> get a handle on the 'natural' return type of the conversion operator. > > Is the issue here that Geoffrey's proposed resolution allows any > conversions (safe or not) if the source type is not a built-in > pointer, i.e. is some user-defined type? So a user-defined type that > refers an array of derived classes is allowed to be converted to an > array of base, even though that's not safe. Howard has strongly > objected to this part of the P/R. Yes. I see no way to distinguish between objects with safe conversion operators and unsafe conversion operators. -- Lawrence Crowl
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 12:31 PM, Ian Lance Taylor wrote: > On Tue, Jan 1, 2013 at 9:10 AM, Steven Bosscher wrote: >> >> Does XCOFF differ a lot from COFF? > > In a word, yes. While COFF and XCOFF share a distant ancestor, they > are in effect completely different object file formats. simple-object-xcoff.c is based on simple-object-coff.c, which is why I acknowledged Ian in the authorship. The file header and section support is very similar. The 64 bit AIX XCOFF format complicated the structure layouts a little. AIX XCOFF embedded / inserted another layout of control sections within sections. I need to investigate how much CSECT support is necessary in simple object for the way that GCC LTO utilizes simple object. The patch is a start with basic functionality. Thanks, David
Re: [PATCH] libiberty simple object XCOFF support
On Tue, Jan 1, 2013 at 9:04 AM, David Edelsohn wrote: > The attached patch is a start at libiberty simple object support for > AIX XCOFF file format. With this patch, the simple object API can > read and write XCOFF files. I need to investigate a little more about > the proper attributes for XCOFF sections written using sobj. > > There are open questions about how to wedge GCC LTO support into the > AIX XCOFF file format. I am unsure if LTO can be an additional section > in the XCOFF file or should be new CSECTs in an existing section. > Maybe CSECTs in the XCOFF comment section. > > * simple-object-xcoff.c: New file. > * Makefile.in: Add it to build machinery. > * simple-object-common.h (simple_object_xcoff_functions): Declare. > * simple-object. (format_functions): Add simple_object_xcoff_functions. > + return "COFF object format mismatch"; Should say XCOFF. This patch is OK by me. Ian
Re: [patch, libgfortran] PR55818 Reading a REAL from a file which doesn't end in a new line fails
This updated patch addresses the issues with infinities, nans, characters, and
valid reals.
OK for trunk?
Test case attached.
Regards,
Jerry
Index: list_read.c
===
--- list_read.c (revision 194731)
+++ list_read.c (working copy)
@@ -697,6 +697,7 @@ read_logical (st_parameter_dt *dtp, int length)
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c);
eat_separator (dtp);
return; /* Null value. */
@@ -951,6 +952,7 @@ read_character (st_parameter_dt *dtp, int length _
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c); /* NULL value. */
eat_separator (dtp);
return;
@@ -975,8 +977,7 @@ read_character (st_parameter_dt *dtp, int length _
for (;;)
{
- if ((c = next_char (dtp)) == EOF)
- goto eof;
+ c = next_char (dtp);
switch (c)
{
CASE_DIGITS:
@@ -984,6 +985,7 @@ read_character (st_parameter_dt *dtp, int length _
break;
CASE_SEPARATORS:
+ case EOF:
unget_char (dtp, c);
goto done; /* String was only digits! */
@@ -1041,7 +1043,7 @@ read_character (st_parameter_dt *dtp, int length _
the string. */
if ((c = next_char (dtp)) == EOF)
- goto eof;
+ goto done_eof;
if (c == quote)
{
push_char (dtp, quote);
@@ -1167,6 +1169,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
goto exp2;
CASE_SEPARATORS:
+ case EOF:
goto done;
default:
@@ -1202,6 +1205,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
break;
CASE_SEPARATORS:
+ case EOF:
unget_char (dtp, c);
goto done;
@@ -1243,7 +1247,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
&& ((c = next_char (dtp)) == 'y' || c == 'Y')
&& (c = next_char (dtp
{
- if (is_separator (c))
+ if (is_separator (c) || (c == EOF))
unget_char (dtp, c);
push_char (dtp, 'i');
push_char (dtp, 'n');
@@ -1255,7 +1259,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
&& ((c = next_char (dtp)) == 'n' || c == 'N')
&& (c = next_char (dtp)))
{
- if (is_separator (c))
+ if (is_separator (c) || (c == EOF))
unget_char (dtp, c);
push_char (dtp, 'n');
push_char (dtp, 'a');
@@ -1269,7 +1273,7 @@ parse_real (st_parameter_dt *dtp, void *buffer, in
goto bad;
c = next_char (dtp);
- if (is_separator (c))
+ if (is_separator (c) || (c == EOF))
unget_char (dtp, c);
}
goto done_infnan;
@@ -1315,6 +1319,7 @@ read_complex (st_parameter_dt *dtp, void * dest, i
break;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c);
eat_separator (dtp);
return;
@@ -1369,7 +1374,7 @@ eol_4:
goto bad_complex;
c = next_char (dtp);
- if (!is_separator (c))
+ if (!is_separator (c) && (c != EOF))
goto bad_complex;
unget_char (dtp, c);
@@ -1429,6 +1434,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto got_sign;
CASE_SEPARATORS:
+case EOF:
unget_char (dtp, c); /* Single null. */
eat_separator (dtp);
return;
@@ -1484,6 +1490,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto got_repeat;
CASE_SEPARATORS:
+ case EOF:
if (c != '\n' && c != ',' && c != '\r' && c != ';')
unget_char (dtp, c);
goto done;
@@ -1647,7 +1654,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
goto unwind;
c = next_char (dtp);
l_push_char (dtp, c);
- if (!is_separator (c))
+ if (!is_separator (c) && (c != EOF))
{
if (c != 'i' && c != 'I')
goto unwind;
@@ -1700,7 +1707,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
}
}
- if (!is_separator (c))
+ if (!is_separator (c) && (c != EOF))
goto unwind;
if (dtp->u.p.namelist_mode)
@@ -2537,16 +2544,16 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info
switch (nl->type)
{
case BT_INTEGER:
- read_integer (dtp, len);
- break;
+ read_integer (dtp, len);
+break;
case BT_LOGICAL:
- read_logical (dtp, len);
- break;
+ read_logical (dtp, len);
+ break;
case BT_CHARACTER:
- read_character (dtp, len);
- break;
+ read_character (dtp, len);
+ break;
case BT_REAL:
/* Need to copy data back from the real location to the temp in order
! { dg-do run }
! PR55818 Reading a REAL from a file which doesn't end in a new line fails
! Test case from PR reporter.
implicit none
integer :: stat
!integer :: var ! << works
real:: var ! << fails
character(len=10):: cvar ! << fails
complex :: cval
open(99, file="test.dat", access="stream", form="unformatted", status="new")
write(99) "1", new_line("")
write(99) "2", new_line("")
write(99) "3"
close(99)
! Test character kind
open(99, file="test.dat")
read (99,*, iostat=stat) cvar
if (stat /= 0 .or. cvar /= "1") call abort()
read (99,*, iost
[PATCH, committed] Update MAINTAINERS
I've checked in the following patch to update my email address in MAINTAINERS. -- Maxim Kuvyrkov MAINTAINERS-Update-my-email.ChangeLog Description: Binary data MAINTAINERS-Update-my-email.patch Description: Binary data
