> > Do we require that to match? I don't remember that we do.
>
> For scalar types (and arrays of scalars), the alignment is essentially
> encoded
> in the size/mode pair but that's not the case for non-array aggregate types,
> so declaring a conversion that changes the alignment as useless se
> > - /* For aggregates we rely on TYPE_CANONICAL exclusively and require
> > - explicit conversions for types involving to be structurally
> > - compared types. */
> > + /* For aggregates compare only the size and mode. Accesses to fields do
> > have
> > + a type information by th
On 10/01/2015 05:28 AM, Andrew Haley wrote:
On 09/29/2015 04:21 PM, Sandra Loosemore wrote:
What is "weak compare_exchange", and what is "the strong variation", and
how do they differ in terms of behavior?
It's in C++11 29.6.5:
Remark: The weak compare-and-exchange operations may fail spuriou
Tested on Linux-PPC64.
/cp
2015-10-01 Ville Voutilainen
PR c++/54430
* name-lookup.c (push_binding): Make non-static.
* name-lookup.h (push_binding): Declare it.
* parser.c (cp_parser_range_for): Use it, get the range
declaration away from the scope until the range expressi
On 01/10/15 11:57 -0600, Sandra Loosemore wrote:
H, yes. Looking at the section as a whole, is it a bug in the
implementation that the built-ins only "approximately match" the C++11
requirements?
AFAIK they exactly match, so I don't know why the docs say that.
If there were an exact corr
On Thu, Oct 01, 2015 at 02:57:15PM +0100, James Greenhalgh wrote:
> 2015-10-01 James Greenhalgh
>
> * match.pd (mult (COPYSIGN:s real_onep @0) @1): New simplifier.
Also, please note that
+ wide_int m = wi::min_value (TYPE_PRECISION (type), SIGNED);
+ tree tt
+ = build_nonst
On 01/10/15 18:23 +0100, Jonathan Wakely wrote:
+struct op_delete {
+ void operator()(void* p) const { ::operator delete(p); }
+};
+std::unique_ptr<::dirent*, op_delete> ptr;
Oops, that should be dirent not dirent* i.e.
std::unique_ptr<::dirent, op_delete> ptr;
(Found on
There's a typo in an example too.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ce1b4ae..599ad87 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9471,7 +9471,7 @@ alignment. A value of 0 indicates typical alignment should be used. The
compiler may also ignore this
This patch fixes the two wrong-code PRs.
The problem is related to the way the noce_emit_cmove helper function
emits conditional moves.
For some targets it re-emits the comparison from the condition block and
then the conditional move
after we have emitted the two basic blocks. Later passes always
Hello,
This patch fixes the reported LTO issue, which is caused by not
implemented case of uniinitialized variables with selectany-attribute
(as common), as such variables couldn't be placed into
linkonce-section for pe-coff.
I adjusted existing testcase to reflect now supported case of
selectany
On 10/01/2015 06:31 PM, Sebastian Pop wrote:
create mode 100644 gcc/testsuite/gcc.dg/graphite/scop-pr66980.c
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
LGTM.
Tobias
be an integer expression.
The attached patch checks that a numerical constant in
a CHARACTER(LEN=x) declaration is an integer. Regression
tested on x86_64-*-freebsd*. OK to commit?
2015-10-01 Steven G. Kargl
PR fortran/67802
* decl.c (add_init_expr_to_sym): Numeric constant
OK.
Jason
> 2015-10-01 Steven G. Kargl
>
> PR fortran/67802
> * decl.c (add_init_expr_to_sym): Numeric constant for character
> length must be an INTEGER.
>
> 2015-10-01 Steven G. Kargl
>
> PR fortran/67802
> * gfortran.dg/pr67802.f90: New test.
OK, but not with that e
On Thu, Oct 01, 2015 at 09:19:15PM +0200, FX wrote:
> > 2015-10-01 Steven G. Kargl
> >
> > PR fortran/67802
> > * decl.c (add_init_expr_to_sym): Numeric constant for character
> > length must be an INTEGER.
> >
> > 2015-10-01 Steven G. Kargl
> >
> > PR fortran/67802
> >
On 1 October 2015 at 11:10, Kyrill Tkachov wrote:
>
> On 30/09/15 17:39, Kyrill Tkachov wrote:
>>
>> On 09/06/15 09:17, Kyrill Tkachov wrote:
>>>
>>> On 05/06/15 14:14, Kyrill Tkachov wrote:
On 05/06/15 14:11, Richard Earnshaw wrote:
>
> On 05/06/15 14:08, Kyrill Tkachov wrote:
>
On Tue, 2015-09-29 at 09:27 -0500, Peter Bergner wrote:
> The first ICE seems to be due to a conversion to long double and LRA ends
> up going into a infinite loop spilling things until it hits a threshold and
> quits with an ICE. I haven't spent enough time to determine whether this
> is a LRA or
From: hiraditya
Renaming gimple_bb to gimple_poly_bb because there is a function gimple_bb
by the same name in gimple.h. No functional change intended.
Passes regtest and bootstrap.
gcc/ChangeLog:
2015-10-01 Aditya Kumar
Sebastian Pop
* graphite-isl-ast-to-gimple.c (cla
Hi,
In "aarch64_get_lane" operand 0 is VEL, so for %0,
iterator vwcore should (?) support all the modes in VEL.
Ran into following error with a local patch for an existing test case.
However it can also be reproduced with the attached test case.
fnction ‘fn1’:
t.c:25:1: internal compiler error:
While debugging gfortran with -fdump-fortran-*, I noticed that a couple
of OMP_LIST_ entries weren't being handled show_omp_clauses so I've
added them. I also took advantage of the opportunity to rearrange the
the cases in the switch statement that handles those lists in a way that
matches the enum
> Well, ahem, gfortran does have several error messages that use the
> standard notation. I know. I wrote some of them. :-)
>
> I'll simply change it to "Expecting an INTEGER at %L”
Thanks. I have no objections to using the full standard terminology (scalar
integer expression), but not the sho
Ping.
Torvald, David approved the code portion of the patch.
How does the documentation part look to you?
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00315.html
Peter
On 09/30/2015 11:57 PM, Jason Merrill wrote:
commit e946db577784ed4670944dd91e81666af16793b3
Author: Jason Merrill
Date: Tue Sep 29 14:43:08 2015 -0400
Diagnose volatile accesses in transaction_safe function.
* trans-mem.c (volatile_lvalue_p): Rename from volatile_var_p.
On 10/01/2015 01:11 PM, Nathan Sidwell wrote:
On 10/01/15 13:00, Andrew MacLeod wrote:
btw, not that it's necessarily important, but I'm about to submit the
include
reduction patches today, and it turns out this line is the first use of
anything from cgraph.h in builtins.c.
So if this is "th
Without initialization the errors are of the kind:
Error: Expression at (1) must be of INTEGER type, found *
see https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg00081.html. Should not we get
the same message with initialization?
Cheers,
Dominique
From: hiraditya
Use sese_l throughout SCoP detection and create vec at the very end when
all SCoPs have been identified. 'struct sese_l' is very lightweight (two
pointers) compared to 'struct scop'.
No functional change intended. Passes regtest and bootstrap.
gcc/ChangeLog:
2015-10-01 Aditya
This is a forward-port of the abandoned SH FDPIC patch from 2010:
https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html
I'm submitting it at this point for initial review, not to be applied
right away; I would not be surprised if some changes are needed. It
applies on top of gcc 5.2.0 with the
On 10/01/2015 11:23 PM, Aditya Kumar wrote:
From: hiraditya
Use sese_l throughout SCoP detection and create vec at the very end when
all SCoPs have been identified. 'struct sese_l' is very lightweight (two
pointers) compared to 'struct scop'.
No functional change intended. Passes regtest and b
On 10/01/2015 10:36 PM, Aditya Kumar wrote:
From: hiraditya
Renaming gimple_bb to gimple_poly_bb because there is a function gimple_bb
by the same name in gimple.h. No functional change intended.
Passes regtest and bootstrap.
LGTM
Tobias
On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote:
> This is a forward-port of the abandoned SH FDPIC patch from 2010:
>
> https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html
>
> I'm submitting it at this point for initial review, not to be applied
> right away; I would not be surprised i
Other than that, I tend to be leery of using plain char arrays
as buffers for objects of bigger types. I don't know to what
extent this is a problem for libstdc++ anymore as more and more
hardware is tolerant of misaligned accesses and as the default
new expression typically returns memory suitabl
On Thu, Oct 01, 2015 at 11:19:37PM +0200, Dominique d'Humières wrote:
> Without initialization the errors are of the kind:
>
> Error: Expression at (1) must be of INTEGER type, found *
>
> see https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg00081.html. Should not we get
> the same message with initia
On Fri, Oct 02, 2015 at 07:36:27AM +0900, Oleg Endo wrote:
> On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote:
> > This is a forward-port of the abandoned SH FDPIC patch from 2010:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html
> >
> > I'm submitting it at this point for ini
On 01/10/15 19:38 +0100, Jonathan Wakely wrote:
On 01/10/15 18:23 +0100, Jonathan Wakely wrote:
+struct op_delete {
+ void operator()(void* p) const { ::operator delete(p); }
+};
+std::unique_ptr<::dirent*, op_delete> ptr;
Oops, that should be dirent not dirent* i.e.
std::
On Thu, Oct 01, 2015 at 12:18:08PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 01, 2015 at 12:14:44PM +0200, Richard Biener wrote:
> > So even if not "easy", can you try?
>
> I did, and after half a day had a big mess and lots of things failing,
> no idea where this was headed, and in the meant
On Fri, Oct 02, 2015 at 10:24:07AM +0930, Alan Modra wrote:
> On Thu, Oct 01, 2015 at 12:18:08PM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 01, 2015 at 12:14:44PM +0200, Richard Biener wrote:
> > > So even if not "easy", can you try?
> >
> > I did, and after half a day had a big mess and lot
On Thu, Oct 01, 2015 at 07:39:10PM -0400, Rich Felker wrote:
> On Fri, Oct 02, 2015 at 07:36:27AM +0900, Oleg Endo wrote:
> > On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote:
> > > This is a forward-port of the abandoned SH FDPIC patch from 2010:
> > >
> > > https://gcc.gnu.org/ml/gcc-patches
OK, newly regenerated patches to remove header files from the latest
version of the tools.
The patches are generated by a pair of tools.
* gcc-order-includes goes through the headers and canonically reorders
some of our more common/troublesome headers and removes any duplicates.
This includes
there are most of the config files... 109 files total.
I built every target in config-list.mk. The reduction tool reduced
each source file by examining *every* target object directory for the
resulting object, and testing the reduction each of those targets.
This took a long time to run
these are all in the main gcc directory. 297 files total.
Everything bootstraps on x86_64-pc-linux-gnu and
powerpc64le-unknown-linux-gnu. All targets in config-list.mk still
build. Regressions tests also came up clean.
OK for trunk?
Andrew
backend.patch.bz2
Description: application/bzip
141 front end files.. all in subdirectories of gcc.
Everything bootstraps an a x86_64-pc-linux-gnu and
powerpc64le-unknown-linux-gnu with
--enable-languages=all,ada,go,obj-c++,jit --enable-host-shared. All
targets in config-list.mk still build. Regressions tests also came up
clean.
OK for
From: hiraditya
Outlined functions from stmt_simple_for_scop_p. No functional changes intended.
Passes regtest and bootstrap.
gcc/ChangeLog:
2015-10-01 Aditya Kumar
* graphite-scop-detection.c (stmt_has_side_effects): New function
outlined from stmt_simple_for_scop_p.
> There must be a reason why I allowed modes to differ there btw ;)
Thinking about it, I guess reason is that incomplete types do not have
resonable modes set, so requiring modes to match will prevent complete
and incomplete types to match.
Here is updated patch which uses the earlier mode check
101 - 143 of 143 matches
Mail list logo
