On Fri, Jan 25, 2019 at 9:18 PM Alexandre Oliva wrote:
> On Jan 24, 2019, Jason Merrill wrote:
>
> > The latter; you can't have a partial specialization in a function.
>
> *nod* (though not entirely reflected in the patch below, I see)
> >> Any suggestion of a good name for the inline function
On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek wrote:
>
> On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote:
> > On 1/25/19 12:09 PM, Marek Polacek wrote:
> > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
> > >
On Fri, Jan 25, 2019 at 4:20 PM Marek Polacek wrote:
> On Fri, Jan 25, 2019 at 10:05:00AM -0500, Jason Merrill wrote:
> > On 1/24/19 7:17 PM, Marek Polacek wrote:
> > > On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wrote:
> > > > On Wed, Jan 23, 2019 at 12:57 PM Marek Polacek
> > > >
On Sat, Jan 26, 2019 at 04:01:13PM +0100, Jakub Jelinek wrote:
> Here is an untested patch that should fix all of that, ok for trunk
> if it passes bootstrap/regtest on {x86_64,i686}-linux?
Had to change:
-+ { dg-do compile { target { lp64 || ilp32 || llp64 } } }
++ { dg-do compile { target {
Hi,
On Sat, Jan 26 2019, Gerald Pfeifer wrote:
> On Sat, 26 Jan 2019, Martin Jambor wrote:
>> I'd like to propose the following hunk mentioning -Wabsolute-value in
>> changes.html of the upcoming gcc 9. Is it OK?
>
> Lovely^WThanks, ok!
>
> Actually, one question:
>
>> + -Wabsolute-value
On Thu, Jun 23, 2016 at 09:01:30PM -0700, Davide Italiano wrote:
> LLVM currently ships with a new ELF linker http://lld.llvm.org/.
> I experiment a lot with gcc and lld so it would be nice if
> -fuse-ld=lld is supported (considering the linker is now mature enough
> to link large C/C++
On Sat, 26 Jan 2019, Martin Jambor wrote:
> I'd like to propose the following hunk mentioning -Wabsolute-value in
> changes.html of the upcoming gcc 9. Is it OK?
Lovely^WThanks, ok!
Actually, one question:
> + -Wabsolute-value warns when a wrong absolute value
> + function seems to
Hi,
I'd like to propose the following hunk mentioning -Wabsolute-value in
changes.html of the upcoming gcc 9. Is it OK?
Thanks,
Martin
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
Hi,
This patch changes an assertion into an early return condition, fixing
PR d/89042.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r268304.
--
Iain
---
gcc/d/ChangeLog:
2019-01-26 Iain Buclaw
PR d/89042
* decl.cc
Committed as Revision: 268303
URL: https://gcc.gnu.org/viewcvs?rev=268303=gcc=rev
Log:
2019-01-26 Harald Anlauf
PR fortran/57553
* expr.c (check_inquiry): Add list of inquiry functions allowed in
constant expressions for F2008+.
2019-01-26 Harald Anlauf
PR
Committed as simple and obvious. (With a ChangeLog Bobble fixed)
Regression tested on x86_64.
Committed r268301
M libgfortran/ChangeLog
M libgfortran/io/close.c
Regards,
Jerry
2019-01-26 Jerry DeLisle
PR libfortran/89020
* io/close.c
Hi Christophe,
> On 23 Jan 2019, at 13:16, Christophe Lyon wrote:
> dg-extract-results currently moves lines like
> WARNING: program timed out
> at the end of each .exp section when it generates .sum files.
>
> This is because it sorts its output based on the 2nd field, which is
> normally the
On Fri, Jan 25, 2019 at 7:57 AM Richard Biener wrote:
>
> The following fixes an ICE with -flto -ffat-lto-objects
> -fdebug-types-section -g where optimize_external_refs does not
> expect to see DW_AT_signature as made "local" by build_abbrev_table(sic!).
>
> This is because we run
This is a regression present on all active branches: under a specific set of
circumstances, the compiler generate wrong code for the assignment of an array
component of a record type, when the nominal subtype of the component is an
array type with an alignment clause that specifies a larger
Committed as obvious at revision r268295
2019-01-26 Dominique d'Humieres
PR fortran/85579
* gfortran.dg/pr51434.f90: Fix the TRANSFER argument.
--- ../7_clean/gcc/testsuite/gfortran.dg/pr51434.f902018-03-10
01:18:34.0 +0100
+++
I have committed the following patch to the gcc-7-branch as r268294 after a
regtest.
Manfred, could you please check with your script that I did not miss
some test in the gcc-7 and gcc-8 branches?
TIA
Dominique
Index: gcc/testsuite/ChangeLog
Hi!
Here is an untested patch that should fix all of that, ok for trunk
if it passes bootstrap/regtest on {x86_64,i686}-linux?
Notes:
1) seems the C++ FE is even stricter and uses the
builtin_structptr_types[x].str string to verify the pointed type
has the right TYPE_NAME; is that
Hi,
This patch merges platform fixes for both druntime and phobos from upstream.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r268293.
--
Iain
---
diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
new file mode 100644
index
On Sat, Jan 26, 2019 at 01:35:05PM +0100, Jakub Jelinek wrote:
> On Sat, Jan 26, 2019 at 01:25:04AM +, Joseph Myers wrote:
> > It's also broken the build of the glibc testsuite, e.g.:
> >
> > ../time/time.h:88:15: error: mismatch in argument 1 type of built-in
> > function 'strftime';
On Sat, Jan 26, 2019 at 01:25:04AM +, Joseph Myers wrote:
> It's also broken the build of the glibc testsuite, e.g.:
>
> ../time/time.h:88:15: error: mismatch in argument 1 type of built-in function
> 'strftime'; expected 'char *' [-Werror=builtin-declaration-mismatch]
>88 | extern
This does a small tweak in gnat_to_gnu with no functional changes and fixes
some formatting issues in recently added code.
Tested on x86_64-suse-linux, applied on the mainline.
2019-01-26 Eric Botcazou
* gcc-interface/trans.c (Iterate_Acc_Clause_Arg): Fix formatting.
This is a regression present on all active branches: the output of -gnatR3 is
suboptimal in some cases, for example:
package P is
type Arr is array (Short_Integer range <>) of Integer;
type Rec (D : Short_Integer) is record
A : Arr (2 .. D);
end record;
end P;
for Rec'Object_Size
Hi!
The following 4 define_insn shuffle patterns don't have sufficient
conditions. As can be seen even from the way how they transform the
RTL representation into the mask, e.g.:
mask = INTVAL (operands[3]) / 2;
mask |= INTVAL (operands[5]) / 2 << 2;
mask |= (INTVAL (operands[7]) - 8) / 2
On Fri, Jan 25, 2019 at 09:31:18AM -0500, Jason Merrill wrote:
> On 1/25/19 12:15 AM, Jakub Jelinek wrote:
> > On Thu, Jan 24, 2019 at 05:16:52PM -0500, Jason Merrill wrote:
> > > > --- libcpp/expr.c.jj2019-01-01 12:38:16.132007335 +0100
> > > > +++ libcpp/expr.c 2019-01-24
24 matches
Mail list logo
