Re: [PATCH] C-family: Replace "may may" with "may" in warning message

On Sat, Jan 12, 2019 at 09:00:04PM -0800, H.J. Lu wrote: > gcc/c-family/ > > * c-warn.c (warn_for_address_or_pointer_of_packed_member): > Replace "may may" with "may" in warning message. > > gcc/c-family/testsuite/ > > * gcc.dg/pr51628-20.c: Updated. > * gcc.dg/pr51628-21

[PATCH] C-family: Only check the non-pointer data member

When checking alignment of packed member, we should only check the non-pointer data member. gcc/c-family/ PR c++/88664 * c-family/c-warn.c (check_alignment_of_packed_member): Only check the non-pointer data member. gcc/testsuite/ PR c++/88664 * gcc.dg/pr8

Re: [PATCH] C-family: Only check the non-pointer data member

On Sun, Jan 13, 2019 at 04:48:38AM -0800, H.J. Lu wrote: > When checking alignment of packed member, we should only check the > non-pointer data member. > > gcc/c-family/ > > PR c++/88664 > * c-family/c-warn.c (check_alignment_of_packed_member): Only > check the non-pointer data

Re: [PATCH] C-family: Only check the non-pointer data member

On Sun, Jan 13, 2019 at 5:20 AM Jakub Jelinek wrote: > > On Sun, Jan 13, 2019 at 04:48:38AM -0800, H.J. Lu wrote: > > When checking alignment of packed member, we should only check the > > non-pointer data member. > > > > gcc/c-family/ > > > > PR c++/88664 > > * c-family/c-warn.c (chec

[patch, fortran, committed] Fix PR 57792

Hell world, as part of the contiguous improvement process in gfortran, I have committed the patch below as obvious. gfortran now does not pack/unpack if a function result is contiguous. Regards Thomas 2019-01-13 Thomas Koenig PR fortran/57992 * trans-array.c (gfc_

[patch, fortran, committed] PR88803 gfortran documentation warning: '.' or ',' must follow @xref

Hi, I have committed the following patch preapproved by Thomas on BZ as revision r267906. 2019-01-13 Dominique d'Humieres PR fortran/88803 * gfortran.texi: Replace @xref with @ref and adjust the sentence. --- ../_clean/gcc/fortran/gfortran.texi 2019-01-12 16:27:23.0

[PING] [PATCH v5][C][ADA] use function descriptors instead of trampolines in C

Does this patch have a change? This version seems risk-free and is a clear improvement from simply doing nothing for  '-fno-trampolines'. Also it is useful in situations where one cannot have an executable stack. I am currently thinking about working around this problem by calling nested functio

Re: [RFC/PATCH] gcc.c: access does not work in new msvcr for nul file

Am 03.01.19 um 13:34 schrieb Alexander Monakov: On Thu, 3 Jan 2019, Johannes Pfau wrote: Debugging shows that the access function used to check if the input files exist has different behavior in newer msvcr libraries: It does return proper results for the 'nul' file in the old msvcrt.dll but in

[patch, fortran] Add -fwrite-module-files option

Hello world, the attached patch adds a -fwrite-module-files options, but the main point is that it adds its opposite, -fno-write-module-files. This has advantages in parallel compiling, as it is quite fast to generate a module file with -fsyntax-only, and a subsequent compilation with -fno-write

[C++ Patch] Improve grokbitfield location

Hi, today I realized that if we move further up the "famous" location_t loc declaration in grokdeclarator we can often pass a precise location when building TYPE_DECLs for typedef names too, thus, in particular, profitably use DECL_SOURCE_LOCATION in a grokbitfield error and also enabling fur

[C++ Patch] Fix locations of two "typedef is initialized" errors

Hi, I think we need this patch too in order to have consistent locations for the set of error messages about invalid initializers - most of which I changed in patch 23 of this series - and also in order to have consistent locations for the two cases - in class, out of class - of ill-formed in

Re: [wwwdoc][Patch] Mention Loongson 3a1000 3a2000 3a3000 2k1000 support in gcc9

Hi Paul, On Mon, 31 Dec 2018, Paul Hua wrote: > The attached patch mention Loongson 3a1000 3a2000 3a3000 2k1000 support > in gcc9. thanks for putting this together. Only a couple of editorial changes: Index: changes.html === + +

Re: [patch,libgfortran] PR88776 Namelist read from stdin: loss of data

On 1/12/19 2:35 PM, Jerry DeLisle wrote: Hi all, As stated in the PR, the problem turns out to be an ungraceful return after an error.  Most namelist errors go through nml_err_ret, The one I am removing did not and in the unique case of UNIT=5 after the error it falls through and hits some co

Re: [patch, fortran] Add -fwrite-module-files option

On Sun, Jan 13, 2019 at 11:28:00PM +0100, Thomas Koenig wrote: > > the attached patch adds a -fwrite-module-files options, but the main > point is that it adds its opposite, -fno-write-module-files. > > This has advantages in parallel compiling, as it is quite fast to > generate a module file wit

C++ PATCH for c++/88830 - ICE with abstract class

Here we were crashing because while the class C has a destructor, it hasn't yet been declared at this point in maybe_emit_vtables, so CLASSTYPE_DESTRUCTOR is null, so checking DECL_DEFAULTED_IN_CLASS_P crashed. Fixed by checking CLASSTYPE_LAZY_DESTRUCTOR first. Bootstrapped/regtested on x86_64-li

C++ PATCH for c++/88825 - ICE with bogus function return type deduction

In this (invalid) testcase the return type deduction failed so FUNCTYPE was error_mark_node and can_do_nrvo_p crashed. One way to fix this would be to check error_operand_p as below. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2019-01-13 Marek Polacek PR c++/88825 - ICE wit

Re: [patch, fortran] Add -fwrite-module-files option

Hi Steve, On Sun, Jan 13, 2019 at 11:28:00PM +0100, Thomas Koenig wrote: the attached patch adds a -fwrite-module-files options, but the main point is that it adds its opposite, -fno-write-module-files. This has advantages in parallel compiling, as it is quite fast to generate a module file w