Hi Michael and Jan-Benedict,
On Fri, 19 Dec 2014 13:56:50, Michael Haubenwallner wrote:
> On the way to prepare some (aix) libtool patch for toplevel libtool.m4
> I've discovered that different versions of automake were used to generate
> files across various libs:
>
> most libs: automa
?
Thanks
Bernd.
gcc/ChangeLog:
2014-12-29 Bernd Edlinger
Instrument bit field and unaligned accesses for TSAN.
* sanitizer.def (BUILT_IN_TSAN_READ_RANGE): New built-in function.
(BUILT_IN_TSAN_WRITE_RANGE): New built-in function
Hi,
this patch fixes unresolved externals with c++98 std::string templates.
Boot-strapped and Regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
libstdc++v3/ChangeLog:
2015-01-01 Bernd Edlinger
PR libstdc++/64422
libstdc++v3/ChangeLog:
2015-01-01 Bernd Edlinger
PR libstdc++/64422
* src/c++98/misc-inst.cc (string::erase): Add missing overloads.
(string::insert): Likewise.
(string::replace): Likewise.
(wstring::eras
On Fri, 2 Jan 2015 20:01:02, Jakub Jelinke wrote:
>
> On Mon, Dec 29, 2014 at 09:20:57PM +0100, Bernd Edlinger wrote:
>
>> --- gcc/sanitizer.def (revision 218963)
>> +++ gcc/sanitizer.def (working copy)
>> @@ -188,6 +188,10 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE
Hi,
On Fri, 2 Jan 2015 22:29:01, Jakub Jelinek wrote:
>
> On Fri, Jan 02, 2015 at 10:06:29PM +0100, Bernd Edlinger wrote:
>> OK, I will do that.
>> I removed the __tsan_vptr_update stuff from the patch, for now.
>
> Guess we should ask Dmitry about that.
>
>> It
Unfortunately I did the check for not-power-of-two in the wrong way.
Committed as obvious.
Index: ChangeLog
===
--- ChangeLog (Revision 219151)
+++ ChangeLog (Revision 219152)
@@ -1,5 +1,9 @@
2015-01-02 Bernd Edlinger
Hi,
the test case g++.dg/tsan/aligned_vs_unaligned_race.C
still fails sporadically (around 1 out of 100 times).
That is apparently a race condition in the tsan runtime itself.
To make the test reproducible pass, I need to add a sleep(1)
in one of the two threads.
Tested really often with:
make
On Sat, 3 Jan 2015 01:51:34, Mike Strump wrote:
>
> On Jan 3, 2015, at 1:01 AM, Bernd Edlinger wrote:
>> the test case g++.dg/tsan/aligned_vs_unaligned_race.C
>> still fails sporadically (around 1 out of 100 times).
>> That is apparently a race condition in the tsan ru
a all the time.
Boot-Strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
gcc/ChangeLog:
2015-01-03 Bernd Edlinger
Enable experimental TSAN support for Ada.
* tsan.c (instrument_expr): Handle VIEW_CONVERT_EXPR.
4.8 branch
has no tsan tests, so I would leave the test case away for 4.8.
Boot-strapped and regression-tested on x86_64-linux-gnu
OK for trunk and 4.9 + 4.8 branches?
Thanks
Bernd.
gcc/ChangeLog:
2015-01-04 Bernd Edlinger
* sanititer.c
Aehm, sorry,
that's the sporadic failure, I mentioned:
https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00041.html
New failures:
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
New passes:
https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00044.html
New failures:
New passes:
Hi,
On Sun, 4 Jan 2015 20:16:58, Jakub Jelinek wrote:
>
> On Sun, Jan 04, 2015 at 11:07:31AM -0800, Mike Stump wrote:
>> On Jan 4, 2015, at 9:00 AM, Bernd Edlinger wrote:
>>> It is due to a race condition in tsan itself, it cannot decide which access
>>> was the
On Sun, 4 Jan 2015 11:04:34, Mike Stump wrote:
>
> Ah, even more curious. So, for testing, it would be best if we had a way to
> synchronize the threads so that they reliably can show what you want to show,
> and reliably pick which thread will run first and which second and so on. The
> proble
On Sun, 4 Jan 2015 13:57:38, Mike Stump wrote:
>
> On Jan 4, 2015, at 1:48 PM, Bernd Edlinger wrote:
>> I would need a way to link the test case two helper functions, that are not
>> compiled with -fsanitize=thread
>
> /* { dg-additional-sources “tsan-helper.c&quo
Hi,
On Sun, 4 Jan 2015 14:18:59, Mike Stump wrote:
>
>> But tsan still gets at least 90% chance to spot that. As a matter of fact,
>> the tsan runtime is just _incredibly_ fast,
>> and catches errors, with a very high reliability. But it is racy by design.
>
> You say by design. I’m skeptical of
Hi Mike,
On Mon, 5 Jan 2015 14:01:42, Mike Stump wrote:
>
> On Jan 5, 2015, at 12:58 PM, Mike Stump wrote:
>> So, to help you out, I tried my hand at wiring up the extra library code:
>
> So, my tsan build finally finished, and I could try this with a real test
> case. I ran it 20 times, and go
Hi Mike,
after some hours of sleep I realized that your step function can do something
very interesting,
(which you already requested previously):
That is: create a race condition that is _always_ at 100% missed by tsan:
cat lib.c
/* { dg-do compile } */
/* { dg-options "-O2 -fno-sanitize=all"
On Tue, 6 Jan 2015 10:16:33, Jakub Jelinek wrote:
>
> On Tue, Jan 06, 2015 at 10:08:22AM +0100, Bernd Edlinger wrote:
>> Hi Mike,
>>
>> after some hours of sleep I realized that your step function can do
>> something very interesting,
>> (which you already
in
> g++.dg/tsan/aligned_vs_unaligned_race.C
>
> On Tue, Jan 06, 2015 at 10:08:22AM +0100, Bernd Edlinger wrote:
>> Hi Mike,
>>
>> after some hours of sleep I realized that your step function can do
>> something very interesting,
>> (which you already requ
On Tue, 6 Jan 2015 11:47:30, Mike Stump wrote:
>
> On Jan 6, 2015, at 9:45 AM, Bernd Edlinger wrote:
>> I tried your suggestion now, and it seems to work. (on a 4-way core AMD64
>> laptop)
>>
>> Would you prefer this over adding a sleep in Thread1, which I posted
On Tue, 6 Jan 2015 16:32:35, Mike Stump wrote:
>
> On Jan 6, 2015, at 3:22 PM, Bernd Edlinger wrote:
>> Yes, I think too that it can't fail under these conditions.
>
> If you mean your version… A lot has been written on how to to make racy code
> non-racy… I’d refer yo
On Wed, 7 Jan 2015 09:23:39, Jakub Jelinek wrote:
>
> But I really don't like the busy waiting. You essentially want something
> like pthread_barrier_wait that libtsan isn't aware of, right?
>
Yes.
> As tsan is only supported on x86_64-linux (and in the future could be on
> some other 64-bit li
On Wed, 7 Jan 2015 18:00:27, Jakub Jelinek wrote:
>
> On Wed, Jan 07, 2015 at 08:58:04AM -0800, Mike Stump wrote:
>> On Jan 7, 2015, at 12:23 AM, Jakub Jelinek wrote:
>>> But I really don't like the busy waiting.
>>
>> We’ve already determined that sched_sleep isn’t intercepted and can be used
>
atch, that uses this method on all tsan tests,
which seem to depend on sleep(1), and which have unstable results
because of that.
Successfully tested multiple times with:
make check-gcc-c check-gcc-c++ RUNTESTFLAGS="tsan.exp=*"
OK for trunk?
Thanks
Bernd.
On Thu, 8 Jan 2015 14:05:32, Mike Stump wrote:
>
> On Jan 8, 2015, at 1:27 PM, Jakub Jelinek wrote:
>>> Any objections to approving it now?
>>
>> LGTM.
>
> Patch is Ok. If you could send the clang folks a heads up, I’ve love to see
> them adopt the style.
Thanks, I am glad that we finally have
Hi,
On Fri, 9 Jan 2015 10:57:14, Richard Biener wrote:
>
> On Mon, Jan 5, 2015 at 9:00 PM, Jeff Law wrote:
>> On 01/03/15 06:49, Bernd Edlinger wrote:
>>>
>>> Hi,
>>>
>>> I was experimenting with enabling TSAN for Ada recently.
>>> I
On Fri, 9 Jan 2015 12:04:26, Richard Biener wrote:
>
>>>
>>> There may be multiple VIEW_CONVERT_EXPRs in a reference chain
>>> so simply stripping the outermost only doesn't work (the assert).
>>>
>>
>> Hmm, that did not happen in any of the Ada tests in ada/acats nor in gnat.dg,
>> but with Ada an
On Fri, 9 Jan 2015 13:30:45, Jakub Jelinke wrote:
>
> On Fri, Jan 09, 2015 at 01:12:09PM +0100, Bernd Edlinger wrote:
>>>> should be equivalent to
>>>>
>>>> if (DECL_P (base) && !may_be_aliased (base))
>>>> return false;
>>&g
On Fri, 9 Jan 2015 14:04:27, Richard Biener wrote:
>
>>
>> FYI: the VIEW_CONVERT_EXPR did not fail in the
>> gcc_checking_assert (is_gimple_addressable (base))
>> but much later, somewhere in tree-cfg.c it dropped out.
>
> How did it fail there? It doesn't look like &VIEW_CONVERT_EXPR
> is forbidde
Hi,
On Thu, 8 Jan 2015 22:27:26, Jakub Jelinek wrote:
>> Any objections to approving it now?
>
> LGTM.
>
> Jakub
would it be OK to apply this patch also to the 4.9 testsuite,
except for c-c++-common/tsan/bitfield_race.c and
g++.dg/tsan/aligned_vs_unaligned_race.C of course?
Bernd.
ell, none of the other terms here seem to be redundant.
Attached patch was boot-strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
gcc/ChangeLog:
2015-01-11 Bernd Edlinger
* tsan.c (instrument_expr): Use force_gi
Hi,
On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote:
>
> Hi Jakub,
>
>
> I think I have found a reasonable test case, see the attached patch file.
> The use case is: a class that destroys an owned thread in the destructor.
> The destructor sets the vptr again to thread:
Hi Jakub,
I am asking if we plan to merge the TSAN runtime from the LLVM tree soon, or if
it is better to cherry pick
specific changes from there.
I am especially interested in fixing these two issues, but there may be other
important improvements too:
https://gcc.gnu.org/bugzilla/show_bug.cg
On Tue, 13 Jan 2015 17:22:23, Jakub Jelinek wrote:
>
>
> So do you mean following? I've bootstrapped/regtested on x86_64-linux and
> i686-linux, but haven't tried any special testcases on it. If it works for
> you, I'll commit it.
>
OK.
Thanks
Bernd.
> 2015-01-13 Jakub Jelinek
>
> * sanitizer_
Hi,
this patch fixes PR58893, which is an access to uninitialized memory, which may
or may not crash in
linemap_resolve_location, or just print error messages with bogus location.
When the first -include file is processed we have the case, where
pfile->cur_token == pfile->cur_run->base, this is
*run, unsigned int count)
> {
> run->base = XNEWVEC (cpp_token, count);
> run->limit = run->base + count;
> run->next = NULL;
> }
>
> so, limit points at the end of the run.
>
>
> Boot-Strapped and Regression-tested on x86_64-linux-gnu
> Ok for trunk?
>
&
; Date: Sat, 27 Sep 2014 11:42:29 +0200
>
>
>
> On Fri, 26 Sep 2014 12:48:44, Jeff Law wrote:
> >
> > On 09/26/14 06:21, Bernd Edlinger wrote:
> >>>>
> >>>>Hi,
> >>>>
> >>>>this
Hi Jeff,
On Mon, 29 Sep 2014 22:40:58, Jeff Law wrote:
>
> On 09/27/14 03:53, Bernd Edlinger wrote:
>>>> Comment before this change. Someone not familiar with this code is
>>>> going to have no idea why these two lines exist.
>>>>
>>>
&
Hi Jeff,
as you know, this test case takes too long to complete if the test suite is run
with
this command line:
MALLOC_PERTURB_=237 make -k check
The reason was found in libcpp/charset.c, where a reallocation is done one byte
at a time.
It seems to be in the macro expansion of this constr
Hi Sandra,
good work!
I tested with arm-none-eabi.
Now both variants, with and without -fstrict-volatile-bitfields
produce the expected results for EABI-compliant structures,
and still create reasonable code with non-compliant packed structures.
> I think there is still a case where this ve
pe you don't
mind :)
I really hope that the GCC maintainers can accept this patch now, as the
current state of -fstrict-volatile-bitfields is very painful to all of us.
Regards
Bernd Edlinger
gcc-4.9-portable-volatility.diff
Description: Binary data
Hello Zoran,
I may be wrong, but what you are trying to do is very similar to what's
in fold-const.c optimize_bit_field_compare().
There was a discussion in April 2012 on this thread: "Continue
strict-volatile-bitfields fixes"
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01094.html
The result
Hello Hans-Peter,
> On Sat, 13 Jul 2013, Bernd Edlinger wrote:
>> Hi Sandra,
>>
>> On Fri, 5 Jul 2013, Hans-Peter Nilsson wrote
>>> Or - maybe more acceptable - an optional warning, say
>>> -Wportable-volatility, to warn about code for which separate
&g
Hi Ramana,
why did you leave the space before the bx?
this ends up in the .s file making it look ugly..
+ return \" bx%?\\t%0\\t%@ indirect register sibling call\";
Regards
Bernd.
gt;
> Please also change the name to check_portable_volatility instead
> of warn_portable_volatility_p; the "_p" suffix is canonically
> used for boolean predicates. (You might have copied the wrong
> use of _p from somewhere else in the gcc code, but that's also
> in e
=neon
-mfloat-abi=softfp" the function foo is inlined into bar,
but the inlined version does not use vstr instructions any more, because
the front-end does assume that malloc returns 4 byte aligned memory.
Regards
Bernd Edlinger2013-08-07 Bernd Edlinger
g++.dg/ext/mv5.C
g++.dg/ext/mv12.C
Regards
Bernd Edlinger2013-08-13 Bernd Edlinger
PR target/58105
Fixed wrong code generation for multiversioned functions.
* gcc/config/i386/i386.c (make_resolver_func): Set DECL_UNINLINABLE.
patch
Therefore the inlining of the resolver function generates wrong code, and has
> to be avoided. That is what this patch does.
>
> This patch fixes the following test cases:
> g++.dg/ext/mv2.C
> g++.dg/ext/mv5.C
> g++.dg/ext/mv12.C
>
> Regards
> Bernd Edlinger
On Wed, 14 Aug 2013 12:36:00, Richard Biener wrote:
> ChangeLog without gcc/ prefix - it's for the gcc/ChangeLog file. Ok
> with that
> change.
>
> Thanks,
> Richard.
>
Thanks for your quick response.
But as I do not have check-in access I might need some help.
Thanks
Bernd.
for trunk and 4.9 branch?
Thanks
Bernd.
2014-04-30 Bernd Edlinger
Work around for current cygwin32 build problems (Bug gas/16858).
* config/i386/cygming-crtbegin.c (__register_frame_info,
__deregister_frame_info
Hi Rainer,
On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote:
>
> Bernd Edlinger writes:
>
>> 2014-04-30 Bernd Edlinger
>>
>> Work around for current cygwin32 build problems (Bug gas/16858).
>> * config/i386/cygming-crtbegin.c (__register_frame
Opps...
this time with the attachment.
>
> Hi Rainer,
>
>
>
> On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote:
>>
>> Bernd Edlinger writes:
>>
>>> 2014-04-30 Bernd Edlinger
>>>
>>> Work around for current cygwin32 build
Ping...
> Date: Tue, 15 Apr 2014 13:49:37 +0200
>
> Hi Tobias,
>
> On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote:
>>
>> Hi Tobias,
>>
>> On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote:
>>> On Fri, 11 Apr 2014 13:37:46, Tobias Bur
only defined when windows.h is included.
Boot-strapped under Cygwin32 and Cygwin64.
OK for trunk and 4.9.1 branch?
Thanks
Bernd.
2014-05-10 Bernd Edlinger
Fix current cygwin build problems.
* seh_init.c (__gnat_map_SEH): Compile also
ed on Cygwin-32 and Cygwin-64.
OK for trunk and 4.9.1?
Thanks
Bernd.
boehm-gc/ChangeLog:
2014-05-11 Bernd Edlinger
Fix current cygwin-64 build problems.
* include/gc_config_macros.h (GC_PTHREADS): Use __CYGWIN__ instead
of __CYGWI
Hi Eric,
On Wed, 14 May 2014 09:28:55, Eric Botcazou wrote:
>
>>> So does this remove the last concern around Bernd's patch?
>>
>> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
>> by obj-c/c++ as well, but I can't find such use)
>
> Probably but, as previously indicated, I need to d
Hi Jan,
looks good. Thanks!
Bernd
On Mon, 26 May 2014 21:07:28 +0200, Jan Hubicka wrote:
> From: hubi...@ucw.cz
> To: bernd.edlin...@hotmail.de
> CC: hubi...@ucw.cz; gcc-patches@gcc.gnu.org
> Subject: Re: aarch64 build broken
>
>> Hi Jan,
>>
>>
>>
>> r210901 | hubicka | 2014-05-25 00:00:14 +02
1]
add x8, x0, 4
add x7, x0, 8
add x6, x0, 12
add x5, x0, 16
add x4, x0, 20
str x8, [x2, 8]
str x7, [x2, 16]
str x6, [x2, 24]
str x5, [x2, 32]
str x4, [x2, 40]
Hi,
On Tue, 27 May 2014 11:06:21, Richard Biener wrote:
>
> But the coment previously read
>
> /* A constant address in TO_RTX can have VOIDmode, we must not try
> to call force_reg for that case. Avoid that case. */
>
> and you are removing that check. So I guess you want to retain
>
> && GET_MO
because this is always satisfied, after the if (!MEM_P(to_rtx))-block above.
Now both places have exactly the same logic.
Boot-strapped & regression-tested in x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
2014-05-27 Bernd Edlinger
* expr.c (
Honza,
I try to build this configuration:
../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64
--target=arm-linux-gnueabihf --enable-languages=c,c++,fortran,ada
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
but make fails:
libtool: compil
Hi,
On Wed, 28 May 2014 22:36:17, Jan Hubicka wrote:
>
> On the other hand, the alias created ought to inherit properties form its
> target, so yes, we probably want to copy flags that matters, including
> DECL_THREAD_LOCAL_P. We however should not copy DECL_INITIAL - we never have
> constructors
Hi Kai,
this patch also mis-compiles binuitls-2.24 on x86_64.
In the function walk_wild_consider_section (ld/ldlang.c)
a tail-call gets miscompiled:
The stack frame is cleaned up, but now the jump target is invalid.
0x0040c801 <+193>: add $0x28,%rsp
0x0040c805 <+197>
;
> + if (read && line_len)
> + *line_len = len;
>
> - fclose (stream);
> - return buffer;
> + return read ? buffer : NULL;
> }
>
> /* Expand the source location LOC into a human readable location. If
> diff --git a/gcc/input.h b/gcc/input.h
> index 8fdc7
Hi,
it is quite late in P3 now, so how about the attached patch?
This would return to the status quo before your patch, where $GMPINC must be !=
sysroot.
Bernd.
> Date: Tue, 7 Jan 2014 16:45:15 +0100
>
> Hi Alan,
>
>
> This issue is not yet resolved, in the moment this cross-compiler issue l
Hi,
this might be almost obvious?
Thanks
Bernd.
> Date: Mon, 13 Jan 2014 12:13:53 +0100
>
> Hello,
>
> there is another test case, that misses the necessary check_vect() runtime
> check.
>
> Tested on i686-pc-linux-gnu.
> OK for trunk?
>
> Regards
> Bernd.
Hi,
On Thu, 23 Jan 2014 18:12:45, Jakub Jelinek wrote:
>
> On Wed, Jan 22, 2014 at 09:16:02AM +0100, Dodji Seketeli wrote:
>> +static fcache*
>> +add_file_to_cache_tab (const char *file_path)
>> +{
>> +
>> + FILE *fp = fopen (file_path, "r");
>> + if (ferror (fp))
>> + {
>> + fclose (fp);
>> + ret
Hi,
On Thu, 23 Jan 2014 12:52:03, Jakub Jelinek wrote:
>
> On Thu, Jan 23, 2014 at 12:49:06PM +0100, Bernd Edlinger wrote:
>> Hi,
>>
>> this might be almost obvious?
>
> No, check_vect () has to preceed all the vector statements in main, or
> often even better
Ping...
>
> Hello,
>
> and Ping for this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01552.html
>
>
> note however, that cross-building is probably broken
> anyway in the moment by r205690,
>
>
> Thanks
> Bernd.
>
>> there is a small problem with SSIZE_MAX, because it is not always
>
++ memory model conflict)
> later. Neither of them are obvious to users. How about a configure
> option to set default?
>
> Thanks,
> Joey
>
> On Fri, Jan 10, 2014 at 10:20 PM, Bernd Edlinger
> wrote:
>> On Fri, 10 Jan 2014 14:45:12, Richard Biener wrote:
>>&g
Ping...
this is still open,
in short, the configuration
../gcc-4.9-20140202/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
--enable-languages=c,c++,fortran,ada --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --wi
Thanks
Bernd. 2014-02-06 Bernd Edlinger
PR middle-end/60080
* cfgexpand.c (expand_asm_operands): Attach source location to
ASM_INPUT rtx objects.
* print-rtl.c (print_rtx): Check for UNKNOWN_LOCATION.
patch-pr60080.diff
Description: Binary data
Hi,
this test case fails on ARM, because this target has by default unsigned char
type.
Attached please find my proposed (almost obvious) fix for this,
by using signed char, instead of char alone.
Boot-Strapped and tested on X86_64 and ARM.
Thanks
Bernd.
Hi,
the test case gfortran.dg/vect/pr32380.f was found to fail on
armv7l-unknown-linux-gnueabihf.
The reason for this is that one out of 6 loops does not get vectorized, because
this target does
not support a vectorization of sqrtf.
The same test case is known to fail on powerpc-apple-darwin9 d
required mode.
Regards
Bernd Edlinger.
.
>> To make sure X is SI mode algined,virtual register base must be realigned.
>>
>> For this patch,I only intent to make it right.Making it best is next task.
>> --
>> Regards
>> lin zuojian.
>>
>> 于 2014年02月28日 15:47, Bernd Edlinger 写道:
>>
Ping.
> Subject: [PATCH] Fix fortran/pr60236
> Date: Sun, 23 Feb 2014 14:50:46 +0100
>
> Hi,
>
> the test case gfortran.dg/vect/pr32380.f was found to fail on
> armv7l-unknown-linux-gnueabihf.
> The reason for this is that one out of 6 loops does not get vectorized,
> because this target does
>
semicolons.
Boot-strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
2014-07-15 Bernd Edlinger
PR rtl-optimization/61461
* sched-vis.c (print_pattern) : Fixed.
patch-pr61461.diff
Description: Binary data
iadic,
while
float func(int, ...);
is incompatible on this target and uses r0 for the result.
Boot-strapped and Regression-tested on arm-linux-gnueabihf and x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd. 2014-03-31 Bernd Edlinger
PR fortran/6019
I hope it is not too late, and this can still go into 4.9.0.
Boot-Strapped without any regressions on x86_64-unknown-linux-gnu.
Ok for trunk?
Thanks
Bernd.
gcc:
2014-04-08 Bernd Edlinger
* fortran/class.c (gfc_build_class_symbol): Append
with "[0-9]t".
> This trick makes all names unique again.
>
> I hope it is not too late, and this can still go into 4.9.0.
>
> Boot-Strapped without any regressions on x86_64-unknown-linux-gnu.
>
> Ok for trunk?
>
> Thanks
> Bernd.
>
Lin,
are you still working on this?
Thanks
Bernd.
Hi Lin,
thanks for clarifying this.
If you say you can't sign the FSF copyright assignment,
we can't use your patch, I'm afraid.
Well, I was curious how to proceed, because these unaligned
stm instructions are also a problem under linux.
The test cases don't fail, because the exception handler
Hi Lin,
> Seem we are not talking the same problem.You should first make sure
> what has been going wrong first.
Maybe I misunderstood your point.
> And I will sign it.
> --
> Regards
> lin zuojian
Ok, then please do it.
Once you have signed it, and got the approval by a global GCC reviewer,
Hi Tobias,
On Thu, 10 Apr 2014 10:50:24, Tobias Burnus wrote:
>
> Bernd Edlinger wrote:
>> this patch fixes a recently discovered name-clash in gfc_build_class_symbol.
>>
>> Fortunately it is quite easy to fix: just make sure that the class names of
>> target
>&g
Hi,
On Thu, 10 Apr 2014 17:15:16, Tobias Burnus wrote:
>
> Hi Bernd,
>
> On Thu, Apr 10, 2014 at 11:54:52AM +0200, Tobias Burnus wrote:
>> No re-reading the orginal patch, I think it is okay. Thanks!
>> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00376.html
>
>
> Thanks for the commit. However, c
linux-gnueabihf.
OK for trunk?
Thanks
Bernd.
2014-04-11 Bernd Edlinger
PR fortran/60718
* trans-expr.c (gfc_conv_procedure_call): Fix a strict aliasing
violation when passing a class object to a formal parameter which has
Hi Teresa,
> @@ -1947,7 +1947,7 @@ remove_bb (basic_block bb)
>fprintf (dump_file, "Removing basic block %d\n", bb->index);
>if (dump_flags & TDF_DETAILS)
> {
> - dump_bb (dump_file, bb, 0, dump_flags);
> + dump_bb (dump_file, bb, 0, dump_flags && ~TDF_DETAI
Hi Tobias,
On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote:
>
> Hi Bernd,
>
> Bernd Edlinger wrote:
>> It was caused by a strict aliasing violation, when passing a value of the
>> type
>> "class(x),pointer" to a formal procedure parameter of the ty
Hi Tobias,
On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote:
>
> Hi Tobias,
>
> On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote:
>> On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote:
>> Hmm,
>>
>> I was hoping somehow that only that test case
Hi Lin,
On Thu, 17 Apr 2014 22:29:14, Lin Zuojian wrote:
>
> Hi Bernd,
> I have my copyright mark signed and the process has completed. Now I
> am going to answer two more questions before my patch can be
> commited right?
>
> Did you copy any
> files or text written by someone else in these chang
Hi Jakub,
I can take that task over and will boot-strap with all languages and run the
test suite on my armv7-linux-gnueabihf system.
But that will take until next week as it is currently occupied with other tests.
Can you please review Lin's latest patch and give your OK for check-in on trunk
a
e objections?
Thanks
Bernd.
> get_object_alignment should be able to properly handle this case
> if you call it on the full reference in the normal_inner_ref: case.
> All the weird duplicate code on the VIEW_CONVERT_EXPR case
> should IMHO go.
>
> Richard.
>
>> --
&g
Hi Eric,
On Tue, 22 Apr 2014 10:09:28, Eric Botcazou wrote:
>
>> I still have that already-approved patch, updated to current trunk.
>> I've successfully boot-strapped it on armv7-linux-gnueabihf with
>> all languages enabled, including Ada.
>> The test suite runs cleanly without any drop-outs.
>
1301 - 1395 of 1395 matches
Mail list logo
