On 04/04/14 18:33, Nathan Sidwell wrote:
I'm testing a patch that makes the test in the loop:
if (TREE_PUBLIC (base_binfo)
Hm, binfo's aren't noted that way, it's encoded in BINFO_ACCESS and
SET_BINFO_ACCESS in search.c. We'd need to move those back to cp.h or expose an
interface in
On 2014.04.06 at 09:13 +0100, Nathan Sidwell wrote:
> On 04/04/14 18:33, Nathan Sidwell wrote:
>
> > I'm testing a patch that makes the test in the loop:
> >
> >if (TREE_PUBLIC (base_binfo)
>
> Hm, binfo's aren't noted that way, it's encoded in BINFO_ACCESS and
> SET_BINFO_ACCESS in sear
Previously, pa_asm_output_mi_thunk() internally output the assembler
directives needed
for thunks. This patch switches to using final_start_function() an
final_end_function() to
generate these directives. This has the advantage that these
functions also ouput debug
info as well. This fixe
On Apr 4, 2014, at 12:21 AM, Dominique d'Humières wrote:
>
> In http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094#c21 you wrote
>
>> Thanks for the report and the fix guys. I'd be fine with back port, if
>> someone wants to develop and test it.
>
> The patch is identical to r202593 and has be
On Apr 4, 2014, at 1:09 AM, Fabien Chêne wrote:
> I was a bit too optimistic, old-deja needs to be adjusted.
Thanks.
Bernhard Reutner-Fischer wrote:
On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
+ bool has_final2 = false;
+ if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final))
+ return false; /* Error. */
+ has_final = has_final || has_final2;
On Apr 4, 2014, at 9:53 AM, Jason Merrill wrote:
> richi asked for a testcase for 60731, and since we didn't already have
> support for tests using dlopen, I had to add it. Does this approach make
> sense?
Seems reasonable. I wonder if it works on solaris and darwin… I think darwin
pre 10.5
This test is an expected fail on hppa*-*-hpux* because there is no
lockless atomic support.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2014-04-06 John David Anglin
* gcc.dg/atomic/stdatomic-fl
Changes fixes fail on hppa2.0w-hp-hpux11.11.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2014-04-06 John David Anglin
PR testsuite/60672
* g++.dg/cpp1y/auto-fn25.C: Require lto.
Index: g
Hello,
Le 06/04/2014 18:05, Tobias Burnus a écrit :
> Bernhard Reutner-Fischer wrote:
>> On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
>>> +bool has_final2 = false;
>>> +if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final))
>>> + return false; /* Err
On Apr 5, 2014, at 10:36 AM, Marek Polacek wrote:
>
> I'll wait a day or two for possible comments.
So, my only comment would be it would be nice to document the flags that can
vary between pch creation and use time, and which cause an invalidation of the
pch file. This flag then is documente
Fixes PR testsuite/60671.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2014-04-06 John David Anglin
PR testsuite/60671
g++.dg/pr49718.C: Adjust scan-assembler-times for hppa*-*-hpux*.
Ind
On Apr 6, 2014, at 9:23 AM, John David Anglin wrote:
> This test is an expected fail on hppa*-*-hpux* because there is no lockless
> atomic support.
One can add “no lockless atomic” in there somewhere… The reason is that a
secondary port that someone is doing can see a failure, look at the tes
On 6-Apr-14, at 12:51 PM, Mike Stump wrote:
On Apr 6, 2014, at 9:23 AM, John David Anglin
wrote:
This test is an expected fail on hppa*-*-hpux* because there is no
lockless atomic support.
One can add “no lockless atomic” in there somewhere… The reason is
that a secondary port that some
Mikael Morin wrote:
Le 06/04/2014 18:05, Tobias Burnus a écrit :
It is supposed to propagate the information whether any of the
components ("c") has a derived type. However, I made a typo: It
should be "&has_final2" instead of "&has_final".
gfc_is_finalizable couldn't be used?
No that requi
Ramana Radhakrishnan writes:
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr60655-1.c
> b/gcc/testsuite/gcc.c-torture/compile/pr60655-1.c
> new file mode 100644
> index 000..5f38701
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr60655-1.c
> @@ -0,0 +1,31 @@
> +/* { dg-op
Le 06/04/2014 19:46, Tobias Burnus a écrit :
> Mikael Morin wrote:
>> Le 06/04/2014 18:05, Tobias Burnus a écrit :
>>> It is supposed to propagate the information whether any of the
>>> components ("c") has a derived type. However, I made a typo: It
>>> should be "&has_final2" instead of "&has_fina
Mikael Morin wrote:
Argh. great. What about the use_assoc thing? Why is that needed?
Frankly, I don't know. In terms of the code, the problem is that
attr.use_assoc is zero and, hence, the compiler generates a call to some
external version which lacks the module name - that symbol is not fou
This patch fixes some stupid bugs I made in the previous commit:
lhs_se.descriptor_only will give the descriptor only, i.e. it looses the
information about array sections. Additionally, it helps to add
lhs_se.pre to the block ;-)
The implementation in single.c also had some problems - and it o
Testing showed that the test case doesn't work with num_images() > 1.
Fixed by the commit Rev. 209170.
Tobias
Tobias Burnus wrote:
This patch fixes some stupid bugs I made in the previous commit:
lhs_se.descriptor_only will give the descriptor only, i.e. it looses
the information about array
Le 06/04/2014 20:30, Tobias Burnus a écrit :
> Mikael Morin wrote:
>> Argh. great. What about the use_assoc thing? Why is that needed?
>
> Frankly, I don't know. In terms of the code, the problem is that
> attr.use_assoc is zero and, hence, the compiler generates a call to some
> external version
On Tue, 18 Mar 2014, Richard Biener wrote:
> Committed as obvious.
htdocs/svn.html has four occurrences, and a few other pages also
have some. Though I don't think it's appropriate to adjust the
like of news.html, should I update svn.html?
Gerald
Tobias Burnus wrote:
Testing showed that the test case doesn't work with num_images() > 1.
Fixed by the commit Rev. 209170.
I forgot two functions - now it looks as if it really works with
multiple images :-)
Tobias
Index: gcc/testsuite/ChangeLog.fortran-caf
=
* PING *
Tobias Burnus wrote:
*PING*
Tobias Burnus wrote:
H.J. Lu wrote:
On Fri, Mar 28, 2014 at 12:41 PM, Mike Stump
wrote:
Since we are nearing release, I thought I'd mention I see:
../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall
Options' in menu `C Dialect Options' and i
* PING *
Tobias Burnus wrote:
I would like to ping the following two patches of Jakub. As he wrote
in PR60667:
The http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html fix is
still waiting for review, you need that for both
--with-build-config=bootstrap-ubsan and
--with-build-config=boot
25 matches
Mail list logo
