On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
> This patch ensures that the finalization expression is generated and that
> use-associated finalizers are properly accessed.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
> 2014-04-04 Tobias Burnus
Applied.
Gerald
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.908
diff -u -r1.908 index.html
--- index.html 13 Mar 2014 15:30:15 - 1.908
+++ index.html 5 Apr 2014 20:48:31 -
On Fri, Apr 04, 2014 at 02:53:32PM -0600, Jeff Law wrote:
> Presumably when we wrote out the PCH -fsanitize wasn't being used
> and thus those builtins are not initialized. Right?
Right. I put a local hack into c_common_write_pch and that said:
wrote x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O2
On 04/05/2014 05:04 PM, Thomas Schwinge wrote:
Is it a linker bug that I need to add something like the following?
--- libgcc/ompstuff.c
+++ libgcc/ompstuff.c
@@ -40,6 +40,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include "libgcc_tm.h"
#if defined(HAVE_GA
Hi!
On Fri, 4 Apr 2014 11:30:49 +0200, Bernd Schmidt
wrote:
> On 03/21/2014 04:20 PM, Jakub Jelinek wrote:
> > On Fri, Mar 21, 2014 at 04:13:45PM +0100, Bernd Schmidt wrote:
> >> On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
> >>> When we were discussing the design last year, my strong preference
Hello,
we have front-end warnings about returning the address of a local
variable. However, quite often in C++, people don't directly return the
address of a temporary, it goes through a few functions which hide that
fact. After some inlining, the fact that we are returning the address of a
l
The test gfortran.dg/warn_conversion_4.f90 has to be adjusted after
r209133. Committed as obvious as r209151.
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 209150)
+++ gcc/testsuite/ChangeLog
Hi!
On Sat, 05 Apr 2014 12:34:30 +0200, I wrote:
> In r209148, I have committed a merge from trunk r209072 (2014-04-04) into
> gomp-4_0-branch.
Oh, and Bernd, would you please verify that I correctly merged the trunk
and gomp-4_0-branch changes to gcc/Makefile.in:install-driver?
Grüße,
Thomas
Hi!
On Sun, 16 Mar 2014 20:23:48 +0100, Tobias Burnus wrote:
> Can you or Thomas apply the following patch after my patch* has
> been committed to the trunk and the branch has been updated? Please
> mention PR fortran/60283 in the ChangeLog.
>
> * http://gcc.gnu.org/ml/gcc-patches/2014-03/msg0
Hi!
In r209148, I have committed a merge from trunk r209072 (2014-04-04) into
gomp-4_0-branch.
Compared to trunk, there is one now regression:
PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o assemble, -O -flto
-save-temps
-PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-
Hi,
Idem than the previous patchlets, this time concerning 'pedwarn'.
Tested x86_64 linux. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne
* pt.c (check_template_variable): Check for the return of pedwarn
before emitting a note.
* parser.c (cp_parser_lambda_introducer): Likew
> I've added the testcase - and a bit more detail on this issue - in the PR.
>
> I've attached an updated patch, which skips past the CODE_LABEL.
> And this one bootstraps on i686-pc-linuc-gnu.
OK for stage 1 modulo the typo ("an" instead of "en") in a comment.
--
Eric Botcazou
On Fri, Apr 4, 2014 at 5:37 PM, Jeff Law wrote:
> On 03/28/14 04:16, K_s, Vishnu wrote:
>>
>> Hi all,
>>
>> The tests added in gcc.dg/tree-ssa/isolate-*.c is failing for AVR target,
>> Because the isolate erroneous path pass needs -fdelete-null-pointer-checks
>> option to be enabled. For AVR targe
Le 02/04/2014 22:29, Paul Richard Thomas a écrit :
> Dear All,
>
> This fix, of itself, is quite obvious. The offset was being set to
> zero for array segments, rather than that required for unity valued
> lvalues.
>
> I think that the fix could be used to clean up:
>
> trans-expr.c(gfc_trans_a
14 matches
Mail list logo
