Jakub Jelinek writes:
> 2012-12-05 Jakub Jelinek
>
> * asan.c (instrument_derefs): Handle bitfield COMPONENT_REFs
> accesses as reads/writes to their DECL_BIT_FIELD_REPRESENTATIVE.
After Richi's comments in this thread, I guess this is OK to me.
--
Dodji
2012/12/8 Thomas Koenig :
> Am 08.12.2012 17:39, schrieb Janus Weil:
>
>> Hi Thomas,
>>
>>> the attached patch fixes a regression introduced with the recent
>>> checking for DO loop variables when they are used with a generic
>>> subroutine where the generic name matches one of the actual names.
>>
Jason Merrill writes:
> On 12/03/2012 08:27 AM, Dodji Seketeli wrote:
> > + - HAS_EXPANSION_ARG_P: Set to TRUE iff at least one parameter
> > + pack has got an argument that is an expansion.
>
> The "got" is unnecessary, just "has an argument" is better.
Removed, thanks.
> > + Setup AP
Am 08.12.2012 17:39, schrieb Janus Weil:
Hi Thomas,
the attached patch fixes a regression introduced with the recent
checking for DO loop variables when they are used with a generic
subroutine where the generic name matches one of the actual names.
Regression-tested. OK for trunk?
A few que
[Sorry, I forgot to copy GCC Patches before]
Some of the libgomp testcases fail on AIX when using native TLS
because variables annotated with
#pragma omp threadprivate(thr)
sometimes are placed in section anchor blocks. Variables declared
with "__thread" create decls with the correct TLS model
I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
SP adjustment instead of a sequence of pushes/pops. The preference to
the MOVs are good for old CPU micro-architectures (before pentium-4,
K10), because it breaks the data dependency. In modern
micro-architecture, push/pop is im
2012/12/4 Tobias Burnus :
> We freed the renamed symbol for intrinsic modules too early, if they
> actually exist on the disk as the name is used in trans*.c. (For "file"
> modules, the data is later freed with the namespace by calling
> gfc_free_use_stmts.)
>
> Build and regtested on x86-64-gnu-li
On Thu, Nov 22, 2012 at 6:45 AM, H.J. Lu wrote:
> Hi,
>
> libasan should come first before any language-specific
> adjustment/addition. Otherwise, we got
>
> g++ -fsanitize=address -static-libasan ...
>
> /usr/local/bin/ld: error:
> /export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknow
Btw, one nit about your ChangeLog:
2012-12-05 Tobias Burnus
* trans-array.c (gfc_deallocate_scalar_with_status): Use
NULL_TREE in the call to gfc_deallocate_scalar_with_status.
* trans-decl.c (gfc_trans_deferred_vars): Pass symbol.
* trans-stmt.c (gfc_trans_deallocate): Pass po
Hi Tobias,
> The patch below is part of my FINAL patch. The NULL -> NULL_TREE change is
> obvious.
certainly ok.
> The expr to al->expr change is to pass a BT_CLASS instead of a
> BT_DERIVED. And the NULL to gfc_lval_expr_from_sym change allows to access
> var->_vtab->_final for a BT_CLASS defe
Hi Thomas,
> the attached patch fixes a regression introduced with the recent
> checking for DO loop variables when they are used with a generic
> subroutine where the generic name matches one of the actual names.
>
> Regression-tested. OK for trunk?
A few questions about that patch:
- f =
On Sat, Dec 8, 2012 at 2:14 AM, Richard Sandiford
wrote:
>
> As far as the dwarf2out.c bits go, I think the original dbx_reg_number assert:
>
> gcc_assert (regno != INVALID_REGNUM);
>
> should become:
>
> gcc_assert (regno != INVALID_REGNUM && regno != IGNORED_DWARF_REGNUM);
>
> since it's the
When bootstrapping GCC with asan or LTO + FDO, I got many
false -Werror=maybe-uninitialized and -Werror=uninitialized:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55519
Are they real bugs or should
> > OK. How we want to handle this with LTO streaming?
>
> Don't know. From debug info quality POV right now, LTO has lots of other
> more important issues first. And from the invalid error POV, that only
> matters if the initializer changes in between RTL expansion of some function
> and end o
This adds an obvious assertion in the N_Indexed_Component case of gnat_to_gnu
so as to avoid the associated crash a few lines below.
Tested on x86_64-suse-linux, applied on the mainline.
2012-12-08 Eric Botcazou
* gcc-interface/trans.c (gnat_to_gnu) : Assert
that the type of
This is an internal error on IA-64 with overaligned vector types, i.e. vector
types with alignment of 256 bits. Because this alignment is larger than the
largest required alignment, the testcase triggers the alignment circuitry in
gigi and there is a small hole in it.
Tested on x86_64-suse-lin
This is an internal error in for_each_index at -O:
+===GNAT BUG DETECTED==+
| 4.8.0 20121208 (experimental) [trunk revision 194319] (x86_64-suse-linux)
GCC error:|
| in for_each_index, at tree-ssa-loop-im.c:324
Vladimir Makarov writes:
> Index: lra-constraints.c
> ===
> --- lra-constraints.c (revision 194307)
> +++ lra-constraints.c (working copy)
> @@ -3329,8 +3329,9 @@ lra_constraints (bool first_p)
> reg = regno_reg_rtx[i];
>
Steve Ellcey writes:
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index b6a2290..bc99f29 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -16757,6 +16757,9 @@ mips_option_override (void)
>for (i = FP_REG_FIRST; i <= FP_REG_LAST; i++)
> mips_dbx
Hello world,
the attached patch fixes a regression introduced with the recent
checking for DO loop variables when they are used with a generic
subroutine where the generic name matches one of the actual names.
Regression-tested. OK for trunk?
Thomas
2012-12-08 Thomas Koenig
20 matches
Mail list logo
