Hi Harald,
There's another case of buffer overflows when F2008 submodules are used.
Buffer sizes are further increased, and checks for overflow are put into
place.
OK for master?
OK, also for the backport.
Thanks a lot!
Regards
Thomas
I just committed the attached test case as obvious.
Added test case for a PR which has been fixed in the meantime.
gcc/testsuite/ChangeLog:
PR tree-optimization/50439
* gfortran.dg/loop_interchange_2.f: New test.
C { dg-do compile }
C { dg-options "-std=legacy
Hi,
This patch merges the D front-end implementation with upstream dmd
cef1e7991. Adds a DString type, a struct that has a compatible layout
with D strings. Many parameters in the Global struct have been switched
over to this type, and users of these params have been adjust to use the
length or
On Sun, Jun 7, 2020 at 1:28 AM Thomas Koenig via Gcc-patches
wrote:
>
> Hi Harald,
>
> > There's another case of buffer overflows when F2008 submodules are used.
> > Buffer sizes are further increased, and checks for overflow are put into
> > place.
> >
> > OK for master?
>
> OK, also for the back
Here's a fix for another buffer overflow which is triggered by one of
Gerhard's (in)famous testsuite. Looking at the way symbols are generated,
I decided to partly use a simple solution recommended by Jakub Jelinek.
Regtested with no new failures on x86_64-pc-linux-gnu.
OK for master? Backports
Hi H.J.,
> Gesendet: Sonntag, 07. Juni 2020 um 16:02 Uhr
> Von: "H.J. Lu"
> An: "Thomas Koenig"
> Cc: "Harald Anlauf" , "fortran" ,
> "gcc-patches"
> Betreff: Re: [PATCH] PR fortran/95091 - Buffer overflows with submodules and
> long symbols
> This may have broken bootstrap:
>
> https://gcc
Hi,
This patch merges the D front-end implementation with upstream dmd
1831b24ff. Converts some global and param fields from pointers to value
types.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
gcc/d/ChangeLog:
* dmd/MERGE: Merge
Hello world,
Our finalization handling is a mess. Really, we should get to try and get
this fixed for gcc 11.
In the meantime, here is a patch which fixes a regression I introduced
when fixing a regression with a memory leak. The important thing
here is to realize that we do not need to finali
I've committed the patch below to fix bootstrap.
Sorry for the breakage!
Harald
commit 5aaccde3db39fac7e7f6677ceccc1eadd9c6a424 (HEAD -> master, origin/master,
origin/HEAD)
Author: Harald Anlauf
Date: Sun Jun 7 16:43:12 2020 +0200
PR fortran/95091 - Buffer overflows with submodules and
On Sat, 2020-06-06 at 14:30 -0600, Martin Sebor via Gcc-patches wrote:
> A recent enhancement to the uninitialized access coverage to include
> dynamically allocated objects, including alloca and VLAs, triggers
> an expected instance of -Wmaybe-uninitialized on powerpc64-linux
> in reload_cse_simpl
Hi,
This patch merges the D front-end implementation with upstream dmd
b0df0e982. Adds a struct ParameterList to encapulate parameter and
vararg information in the front-end.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
gcc/d/ChangeLog:
Yes, it works.
On Sun, Jun 7, 2020 at 7:19 AM Harald Anlauf wrote:
>
> Hi H.J.,
>
> > Gesendet: Sonntag, 07. Juni 2020 um 16:02 Uhr
> > Von: "H.J. Lu"
> > An: "Thomas Koenig"
> > Cc: "Harald Anlauf" , "fortran" ,
> > "gcc-patches"
> > Betreff: Re: [PATCH] PR fortran/95091 - Buffer overflows w
Hi,
Sorry for the super late reply.
> 1. Using .so on Windows for DLLs is fine.
I know, but using the standard suffix for the platform seems better, IMHO.
> 2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than
> LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 inst
Hello Roger and nice to hear from you after a loong time!
> Alas there is a mismatch between RTL's definition of PARITY operation
> which has an integer mode result, and the x86's parity flag. So when
> Uros addressed PR target/44481 in 2010, by introducing UNSPEC PARITY,
> we lost some of the op
On Fri, 5 Jun 2020 at 19:58, Jason Merrill wrote:
>
> On 6/5/20 12:39 PM, Jason Merrill wrote:
> > On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon
> > mailto:christophe.l...@linaro.org>> wrote:
> >
> > On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches
> > mailto:gcc-patches@gcc.g
Hi,
This patch merges the D front-end implementation with upstream dmd
b0df0e982. Renames OutBuffer::peekString to OutBuffer::peekChars, and
OutBuffer::extractString to OutBuffer::extractChars. All callers have
been updated as appropriate.
Bootstrapped and regression tested on x86_64-linux-gnu,
gcc/ChangeLog:
* doc/invoke.texi: Document -Wuniversal-initializer.
gcc/c-family/ChangeLog:
* c.opt: Add -Wuniversal-initializer
gcc/c/ChangeLog:
* c-typeck.c (pop_init_level): Don't suppress warnings about { 0 }
if warn_zero_init.
gcc/testsuite/ChangeLog:
Hello,
I accidentally used Init(1) for the option instead of Init(0). The
correction is as follows:
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 15bbb8e69f7..8bfa28e5f6c 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1192,7 +1192,7 @@ C ObjC C++ ObjC++ LTO LangEnabledBy
Hi,
This patch merges the D front-end implementation with upstream dmd
73d8e2fec. Renames the enum PROTKIND to Prot::Kind, updates all uses of
the original enum accordingly.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
gcc/d/ChangeLog:
On 6/6/20 4:56 AM, Eric Botcazou wrote:
This patch fixes walk_tree_1 to call the function on the TYPE_DECL, as we do
for other decls of a DECL_EXPR.
Where is that done exactly? The only case handled by DECL_EXPR is TYPE_DECL.
The only case handled specially is TYPE_DECL; other DECL_EXPRs fal
On 6/7/20 12:56 PM, Christophe Lyon wrote:
On Fri, 5 Jun 2020 at 19:58, Jason Merrill wrote:
On 6/5/20 12:39 PM, Jason Merrill wrote:
On Fri, Jun 5, 2020 at 12:01 PM Christophe Lyon
mailto:christophe.l...@linaro.org>> wrote:
On Fri, 15 May 2020 at 23:54, Jason Merrill via Gcc-patches
On 6/7/20 4:03 PM, Nicolas Bértolo wrote:
> Hi,
>
> Sorry for the super late reply.
>
>> 1. Using .so on Windows for DLLs is fine.
>
> I know, but using the standard suffix for the platform seems better, IMHO.
>
It doesn't prevent applications from actually loading it.
>> 2. The DLL name on W
On 2020-06-05 01:53, Segher Boessenkool wrote:
On Thu, Jun 04, 2020 at 08:46:23AM +0200, Richard Biener wrote:
On Thu, Jun 4, 2020 at 5:34 AM Jiufu Guo
wrote:
> Patch is updated a little according to comments.
> Please see if this is ok to commit.
OK with a proper ChangeLog after bootstrap /
Hi,
On 2020/6/3 04:32, Segher Boessenkool wrote:
> Hi Xiong Hu,
>
> On Tue, Jun 02, 2020 at 04:41:50AM -0500, Xionghu Luo wrote:
>> Double array in structure as function arguments or return value is accessed
>> by BLKmode, they are stored to stack and load from stack with redundant
>> conversion
24 matches
Mail list logo