On October 8, 2016 9:11:22 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>This patch changes various TREE_CODE (xyz) == VAR_DECL into VAR_P
>(xyz),
>TREE_CODE (xyz) != VAR_DECL into !VAR_P (xyz) and
>TREE_CODE (xyz) == VAR_DECL || TREE_CODE (xyz) == FUNCTION_DECL
>into VAR_OR_FUNCTION_DECL_P (xyz).
>
On October 8, 2016 9:09:43 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>I forgot to take into account that ranges[i].exp might not be just NULL
>or
>SSA_NAME, but it can be e.g. BIT_AND_EXPR etc. when optimized by
>earlier
>optimize_range_tests* optimizations. We only care about SSA_NAMEs or
>the
>
On Sat, Oct 8, 2016 at 4:05 PM, Bernd Edlinger
wrote:
> On 10/08/16 19:40, Jason Merrill wrote:
>> On Fri, Sep 30, 2016 at 1:07 AM, Bernd Edlinger
>> wrote:
>>> On 09/29/16 22:38, Jason Merrill wrote:
On Thu, Sep 29, 2016 at 3:58 PM, Bernd Edlinger
wrote:
> Unfortunately, without t
On Fri, Oct 07, 2016 at 03:18:07PM +, Bernd Edlinger wrote:
> Hi!
>
> This extends -Wint-in-bool-context to uses of enum values in boolean
> context, and fixes one place where accidentally an enum value was
> passed to a bool parameter.
>
> I excluded enum values 0 and 1 because that is used
Hi!
On Sat, Oct 08, 2016 at 07:53:42PM +0200, Eric Botcazou wrote:
> this fixes reload failures in 64-bit mode with -mcmodel=medium for targets
> that define ASM_OUTPUT_SPECIAL_POOL_ENTRY_P to 0; that's the case for the
> VxWorks port we'll submit because of the compatibility with the system
>
On 06/10/2016 23:34, Jonathan Wakely wrote:
On 06/10/16 22:17 +0200, François Dumont wrote:
Another approach is to rely on existing compiler ability to compute
conditional noexcept when defaulting implementations. This is what I
have done in this patch.
The new default constructor on _Rb_tree
On 10/08/16 19:40, Jason Merrill wrote:
> On Fri, Sep 30, 2016 at 1:07 AM, Bernd Edlinger
> wrote:
>> On 09/29/16 22:38, Jason Merrill wrote:
>>> On Thu, Sep 29, 2016 at 3:58 PM, Bernd Edlinger
>>> wrote:
Unfortunately, without that exception there is a false positive:
In file incl
Hi Richard,
Thanks for the review.
On 07/10/16 20:11, Richard Biener wrote:
On Fri, Oct 7, 2016 at 12:00 AM, kugan
wrote:
Hi,
In vrp intersect_ranges, Richard recently changed it to create integer value
ranges when it is integer singleton.
Maybe we should do the same when the other range is
Hi,
In vrp_intersect_ranges_1, when !vr0->equiv, we are copying vr1->equiv
without allocating bitmap. This patch fixes this.
Bootstrap and regression testing are ongoing. Is this OK if no new
regressions?
Thanks,
Kugan
gcc/ChangeLog:
2016-10-09 Kugan Vivekanandarajah
* tree-vr
Hi!
This patch changes various TREE_CODE (xyz) == VAR_DECL into VAR_P (xyz),
TREE_CODE (xyz) != VAR_DECL into !VAR_P (xyz) and
TREE_CODE (xyz) == VAR_DECL || TREE_CODE (xyz) == FUNCTION_DECL
into VAR_OR_FUNCTION_DECL_P (xyz).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2
Hi!
I forgot to take into account that ranges[i].exp might not be just NULL or
SSA_NAME, but it can be e.g. BIT_AND_EXPR etc. when optimized by earlier
optimize_range_tests* optimizations. We only care about SSA_NAMEs or the
a < b comparisons that can be ranges[i].exp == NULL if they are in
GIMPL
Hi,
adding patterns for unsigned arithmetic overflow checking in a back-end can
have unexpected fallout because of a latent GC issue: when they are present,
GIMPLE optimization passes can create complex (math. sense) types at will by
invoking build_complex_type. Now build_complex_type goes thr
Hi,
this fixes reload failures in 64-bit mode with -mcmodel=medium for targets
that define ASM_OUTPUT_SPECIAL_POOL_ENTRY_P to 0; that's the case for the
VxWorks port we'll submit because of the compatibility with the system linker,
which rejects .got sections in object files.
When reload ends
On Fri, Sep 30, 2016 at 1:07 AM, Bernd Edlinger
wrote:
> On 09/29/16 22:38, Jason Merrill wrote:
>> On Thu, Sep 29, 2016 at 3:58 PM, Bernd Edlinger
>> wrote:
>>> Unfortunately, without that exception there is a false positive:
>>>
>>> In file included from ../../gcc-trunk/gcc/ada/gcc-interface/de
On 2016-10-08, at 1:01 PM, Bernd Edlinger wrote:
> I think your callback should also directly control the
> alignment of max_align_t in stddef.h:
>
> typedef struct {
> long long __max_align_ll __attribute__((__aligned__(__alignof__(long
> long;
> long double __max_align_ld
> __attribut
It de facto was fixed already, since it belongs to no register class, so there
is no functional change.
Tested on SPARC/Solaris, applied on the mainline.
2016-10-08 Eric Botcazou
* config/sparc/sparc.h (FIXED_REGISTERS): Add %icc.
--
Eric BotcazouIndex: config/sparc/sparc.h
==
> On 6 October 2016 at 18:51, Jan Hubicka wrote:
> >> >
> >> > What do you mean by "for instance?" What are the other cases when it
> >> > happens?
> >> Well ipa_get_type() returned NULL for 481.wrf, and I assumed it was a
> >> fortran-only
> >> code-base but apparently it's a mix of C and fortra
On 7 October 2016 at 17:49, David Malcolm wrote:
> On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote:
>> On 22 September 2016 at 23:15, Joseph Myers
>> wrote:
>> > On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>> >
>> > > Would that be acceptable ? I am not sure how to make %Z check
On 2016-10-08, at 12:53 PM, John David Anglin wrote:
>
> It doesn't look as if the change was reviewed.
For reference, the submission is here:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00796.html
Dave
--
John David Anglin dave.ang...@bell.net
> testing completed successfully, so I've installed the patch with this
> ChangeLog entry:
>
> 2016-09-26 Rainer Orth
>
> gcc:
> * config/i386/i386.c (ix86_print_operand)
> [HAVE_AS_IX86_CMOV_SUN_SYNTAX]: Add gcc_fallthrough.
> * config/sparc/sparc.c (check_pic): Add fa
bounced, resent...
Hi,
I think your callback should also directly control the
alignment of max_align_t in stddef.h:
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long;
long double __max_align_ld
__attribute__((__aligned__(__alignof__(long doubl
The attached patch reverts commit r235318. It caused an ICE in
binds_to_current_def_p building java.
Although java is now gone, the change broke bootstrap and the handling of
_GLOBAL constructors on
32-bit hpux targets.
See PR 70795:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795
In as muc
Hi,
I think your callback should also directly control the
alignment of max_align_t in stddef.h:
typedef struct {
long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long;
long double __max_align_ld
__attribute__((__aligned__(__alignof__(long double;
/* _Float1
On Thu, Oct 6, 2016 at 5:26 PM, Jason Merrill wrote:
> Here's an update that handles more cases.
And a further update that handles direct-initialization, which the
actual proposal doesn't specify at all. I'm dealing with
direct-initialization from a type with a conversion operator that
produces
Various pthread types on hppa-linux require an alignment of 16 bytes for ABI
reasons. This is larger
than the current implementations of max_align_t and max_align_t_align. As a
result, the patch to
implement C++17 over-aligned new causes warnings on hppa. The thread here
discusses the proble
Tested on Linux-x64.
2016-10-08 Ville Voutilainen
Make any's copy assignment operator exception-safe,
don't copy the underlying value when any is moved,
make in_place constructors explicit.
* include/std/any (any(in_place_type_t<_ValueType>, _Args&&...)):
Make explicit.
Prevent paths relative to sysroot directory from being transformed to Windows
form with MSYS prefix.
Second attempt:
Moved most changes to x-mingw32. Only thing added to Makefile.in are new
variables to ease overriding in included file.
Disabled overriding standard lib and include paths (with /
On Fri, Sep 30, 2016 at 10:05:57PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 30, 2016 at 11:26:27AM +0200, Marek Polacek wrote:
> > I haven't gone over the patch in detail yet, but I wonder if we should
> > also accept /* Else, fall through. */ (to be found e.g. in
> > aarch64-simd.md).
>
> Here
28 matches
Mail list logo
