Aldy Hernandez wrote:
>Hi folks.
>
>The problem here is that while streaming the DECL_NAME with
>stream_read_tree() and consequently lto_output_tree(), we trigger an
>ICE
>because we are recursing on the DFS walk:
>
> else
> {
> /* This is the first time we see EXPR, write all reacha
Hi Michael,
> -Original Message-
> From: Michael Eager [mailto:ea...@eagerm.com]
> Sent: Friday, 17 January 2014 4:44 am
> To: David Holsgrove; gcc-patches@gcc.gnu.org
> Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala
> Subject: Re: [Patch, microblaze]: Remove SECO
> -Original Message-
> From: Michael Eager [mailto:ea...@eagerm.com]
> Sent: Friday, 17 January 2014 4:36 am
> To: David Holsgrove; gcc-patches@gcc.gnu.org
> Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala
> Subject: Re: [Patch, microblaze]: Fix ICE with mhard-float
Thanks :)
On Wed, Jan 22, 2014 at 1:15 AM, Richard Sandiford
wrote:
> Ian Lance Taylor writes:
>> This patch moves to the gcc/ChangeLog file a gcc ChangeLog entry that
>> was incorrectly added to the top-level ChangeLog file. Changes to
>> ChangeLog files do not themselves get ChangeLog entries
> > And as you imply, o32+fp64 is already an established ABI so I think we
> > have to support the current form alongside any new one. I agree with
> > Joseph that it'd be better to realign the stack dynamically instead.
> > This is what x86 does, so it's well tested within gcc.
>
> With glibc, o
> Just wanted to add a couple of MIPS-specific things on top of what Joseph
> said:
>
> Matthew Fortune writes:
> > The MSA patch as submitted is another variation of O32 ABI which could
> > be described as O32+FP64+MSA(+nan2008) and would be link incompatible
> > with both O32 and O32+FP64(+/-na
ok.
David
On Tue, Jan 21, 2014 at 4:46 PM, Sriraman Tallam wrote:
> On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li wrote:
>> I think it might be better to introduce a new parameter for max peel
>> insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or
>> MAX_DEFAULT_...), and use the same
On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li wrote:
> I think it might be better to introduce a new parameter for max peel
> insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or
> MAX_DEFAULT_...), and use the same logic in your patch to override the
> MAX_COMPLETELY_PEELED_INSN paramete
On Tue, Jan 21, 2014 at 3:29 PM, Michael Hudson-Doyle
wrote:
>
> This patch for the 4.8 branch fixes an inconsistency between gccgo's
> libgo and the go tool over where libraries installed with "go install
> -compiler gccgo" end up. Even if it's not strictly required, it makes
> sense to me that
> On 01/17/14 14:32, Jan Hubicka wrote:
> >>* combine-stack-adj.c (combine_stack_adjustments_for_block): Remove
> >>ARG_SIZE note when adjustment was eliminated.
> >
> >Ping... This patch prevents me from switching the accumulate-args default
> >for generic and I am waiting for that witht
> It looks like the committed version removed the space after "insn".
> Was that intentional? It now triggers on MIPS because of the frame-related
> (insn/f) prologue instruction that stores the link register. The posted
> version works for me FWIW.
I found out that it didn't fail with the space
Hi,
This patch for the 4.8 branch fixes an inconsistency between gccgo's
libgo and the go tool over where libraries installed with "go install
-compiler gccgo" end up. Even if it's not strictly required, it makes
sense to me that as gccgo implements go 1.1 it should match the go tool
from that pa
On Tue, Jan 21, 2014 at 11:54:03PM +0100, Marek Polacek wrote:
> On Tue, Jan 21, 2014 at 11:34:42PM +0100, Jakub Jelinek wrote:
> > On Tue, Jan 21, 2014 at 11:30:58PM +0100, Marek Polacek wrote:
> > > I made another small change: in the second hunk, in
> > > emit_side_effect_warnings, I got rid of
On Tue, Jan 21, 2014 at 11:34:42PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 21, 2014 at 11:30:58PM +0100, Marek Polacek wrote:
> > I made another small change: in the second hunk, in
> > emit_side_effect_warnings, I got rid of the while, since it seems to
> > me we never get COMPOUND_EXPR in TREE_
I think it might be better to introduce a new parameter for max peel
insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or
MAX_DEFAULT_...), and use the same logic in your patch to override the
MAX_COMPLETELY_PEELED_INSN parameter at O2).
By so doing, we don't need to have a hard coded factor o
Hi folks.
The problem here is that while streaming the DECL_NAME with
stream_read_tree() and consequently lto_output_tree(), we trigger an ICE
because we are recursing on the DFS walk:
else
{
/* This is the first time we see EXPR, write all reachable
trees to OB. */
On Tue, Jan 21, 2014 at 11:30:58PM +0100, Marek Polacek wrote:
> I made another small change: in the second hunk, in
> emit_side_effect_warnings, I got rid of the while, since it seems to
> me we never get COMPOUND_EXPR in TREE_OPERAND (r, 1).
For bar (), 1, 2, 3, 4, 5, 6, 7, 8; sure, but what abo
On Tue, Jan 21, 2014 at 07:50:13PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 21, 2014 at 07:38:10PM +0100, Marek Polacek wrote:
> > --- gcc/gcc/c/c-typeck.c.mp 2014-01-21 11:59:33.221215248 +0100
> > +++ gcc/gcc/c/c-typeck.c2014-01-21 18:10:53.900279750 +0100
> > @@ -4757,6 +4757,18 @@ build_co
I merged revision 206906 from trunk to the gccgo branch.
Ian
On 01/17/14 14:32, Jan Hubicka wrote:
* combine-stack-adj.c (combine_stack_adjustments_for_block): Remove
ARG_SIZE note when adjustment was eliminated.
Ping... This patch prevents me from switching the accumulate-args default
for generic and I am waiting for that witht he inlin
On Tue, Jan 21, 2014 at 09:18:17PM +0100, Marc Glisse wrote:
> On Tue, 21 Jan 2014, Marek Polacek wrote:
>
> >--- gcc/libdecnumber/decNumberLocal.h.mp 2014-01-21 18:34:32.235540589
> >+0100
> >+++ gcc/libdecnumber/decNumberLocal.h2014-01-21 19:04:12.173243034
> >+0100
> >@@ -155,8 +1
Hi,
Currently, tree unrolling pass(cunroll) does not allow any code
size growth in O2 mode. Code size growth is permitted only if O3 or
funroll-loops/fpeel-loops is used. I have created a patch to allow
partial code size increase in O2 mode. With funroll-loops the maximum
allowed code growt
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59896
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev 206908.
2014-01-21 Vladimir Makarov
PR rtl-optimization/59896
* lra-constraints.c (process_alt_operands): Check
On Jan 21, 2014, at 5:51 AM, Maxim Ostapenko
wrote:
> This patch fixes c-c++-common/asan/use-after-return-1.c not to fail on darwin
> target (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897).
>
> Ok to commit?
Ok.
On Tue, 21 Jan 2014, Richard Sandiford wrote:
> And as you imply, o32+fp64 is already an established ABI so I think we
> have to support the current form alongside any new one. I agree with
> Joseph that it'd be better to realign the stack dynamically instead.
> This is what x86 does, so it's wel
This patch fixes a stupid oversight in:
2008-10-24 Richard Sandiford
* config/mips/mips.c (mips_canonicalize_move_class): New function.
(mips_move_to_gpr_cost): Likewise.
(mips_move_from_gpr_cost): Likewise.
(mips_register_move_cost): Make more fine-grained.
Th
Eric Botcazou writes:
>> I have made the adjustment and test it. Please check the new attachment.
>
> Thanks, applied on the mainline as obvious.
It looks like the committed version removed the space after "insn".
Was that intentional? It now triggers on MIPS because of the frame-related
(insn/f
Committed to dmalcolm/jit branch:
Add gcc_jit_function_add_comment, a way to add a no-op textual comment to
the internal representation of the code.
It will be optimized away, but will be visible in some dumps
and thus may be of use when debugging how client code's internal
representation gets co
Hi Matthew,
Just wanted to add a couple of MIPS-specific things on top of what
Joseph said:
Matthew Fortune writes:
> The MSA patch as submitted is another variation of O32 ABI which could
> be described as O32+FP64+MSA(+nan2008) and would be link incompatible
> with both O32 and O32+FP64(+/-nan
On Tue, 21 Jan 2014, Marek Polacek wrote:
--- gcc/libdecnumber/decNumberLocal.h.mp2014-01-21 18:34:32.235540589
+0100
+++ gcc/libdecnumber/decNumberLocal.h 2014-01-21 19:04:12.173243034 +0100
@@ -155,8 +155,10 @@ see the files COPYING3 and COPYING.RUNTI
/* Store a uInt, etc., into b
On Tue, Jan 21, 2014 at 2:39 PM, Jonathan Wakely wrote:
> OK, thanks for confirming that. In that case your patch is OK to
> commit.
Committed.
> I'll raise a defect report against the standard as I don't think the
> specification of nosubs is clear. If that's what it means then it
> should be
On Mon, Jan 20, 2014 at 9:46 PM, Baruch Siach wrote:
> Hi Sterling,
>
> On Mon, Jan 20, 2014 at 12:06:59PM -0800, Sterling Augustine wrote:
>> On Sun, Jan 19, 2014 at 1:21 AM, Baruch Siach wrote:
>> > The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement
>> > __builtin_frame_ad
On 21/01/14 14:14 -0500, Tim Shen wrote:
My conclusion is actually based on Boost.Regex's behavior.
boost::basic_regex::mark_count() returns 1 with nosubs flag. Note that
boost::basic_regex::mark_count() == std::basic_regex::mark_count() +
1, because std does not count the 0th capture (the whole
On 21 January 2014 10:00, Jonathan Wakely wrote:
> On 20 January 2014 21:11, François Dumont wrote:
>> On 01/20/2014 04:53 PM, Jonathan Wakely wrote:
>>
>> With this new design couldn't we change the conditions that are used to
>> decide when to cache the hash code. I haven't study it in detail bu
> On Tue, Jan 21, 2014 at 08:08:19PM +0100, Jan Hubicka wrote:
> > Yes, this is OK.
>
> Thanks. BTW, I wonder if we got small expected_size_exp like in this
> case (6), if it is desirable to emit the large >= 32 size handling
> inline, if (say unless -minline-all-stringops) we couldn't just emit
On 01/21/2014 02:17 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59858
>
> The patch was successfully bootstrapped and tested on x86/x86-64.
>
> Committed as rev. 206897.
>
> 2014-01-21 Vladimir Makarov
>
> PR rtl-optimiz
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59858
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 206897.
2014-01-21 Vladimir Makarov
PR rtl-optimization/59858
* gcc.target/arm/pr59858.c: New.
2014-01-21
On Tue, Jan 21, 2014 at 08:08:19PM +0100, Jan Hubicka wrote:
> Yes, this is OK.
Thanks. BTW, I wonder if we got small expected_size_exp like in this
case (6), if it is desirable to emit the large >= 32 size handling
inline, if (say unless -minline-all-stringops) we couldn't just emit for
that a l
On Tue, Jan 21, 2014 at 5:08 AM, Jonathan Wakely wrote:
> What does Boost.Regex do?
My conclusion is actually based on Boost.Regex's behavior.
boost::basic_regex::mark_count() returns 1 with nosubs flag. Note that
boost::basic_regex::mark_count() == std::basic_regex::mark_count() +
1, because std
> Hi!
>
> As the testcase shows, for the memset (x, 0, y); snippet which handles
> y from 16 to 31 inclusive for some tunings, we generate:
> .L36:
> movq$0, (%rdi)
> movq$0, 8(%rdi)
> movq$0, -8(%rsi,%rdi)
Oops...
> which is correct only for y from 16 to 24 inclus
Hi!
As the testcase shows, for the memset (x, 0, y); snippet which handles
y from 16 to 31 inclusive for some tunings, we generate:
.L36:
movq$0, (%rdi)
movq$0, 8(%rdi)
movq$0, -8(%rsi,%rdi)
which is correct only for y from 16 to 24 inclusive, if y is 25 to 31,
Hi,
Can someone, please, commit this patch as I do not have privileges to
do so.
Kind regards,
Alex Velenko
On 21/01/14 13:34, Marcus Shawcroft wrote:
2014/1/16 Alex Velenko :
Hi,
In previous BE patches the way lane indexing in lanes is calculated has
been changed. To accommodate the change, ar
Hi,
Can someone, please, commit this patch as I do not have privileges to
do so.
Kind regards,
Alex Velenko
On 21/01/14 13:32, Marcus Shawcroft wrote:
On 16 January 2014 11:50, Alex Velenko wrote:
Hi,
This patch by James Greenhalgh fixes "by-lane" patterns broken by
previous patches.
Regres
Hi,
Can someone, please, commit this patch as I do not have privileges to
do so.
Kind regards,
Alex Velenko
On 21/01/14 13:31, Marcus Shawcroft wrote:
On 16 January 2014 11:49, Alex Velenko wrote:
Hi,
This patch changes get_lane intrinsics to provide a correct big-endian
indexing. This fixes n
Hi,
Can someone, please, commit this patch as I do not have privileges to
do so.
Kind regards,
Alex Velenko
On 21/01/14 13:27, Marcus Shawcroft wrote:
On 16 January 2014 11:49, Alex Velenko wrote:
Hi,
This patch is the first patch in a series of patches fixing Big-Endian
lane numbering. The go
Hello,
This is non-trivial part of the patch.
> On 15 Jan 20:53, Uros Bizjak wrote:
> On Tue, Jan 14, 2014 at 7:13 AM, Kirill Yukhin
> wrote:
> Did you try to add DF/SF mode to the unspec? I am not familiar with
> this insn, but shouldn't the mode of mem access be somehow similar to
> the avx512
On Tue, Jan 21, 2014 at 07:38:10PM +0100, Marek Polacek wrote:
> --- gcc/gcc/c/c-typeck.c.mp 2014-01-21 11:59:33.221215248 +0100
> +++ gcc/gcc/c/c-typeck.c 2014-01-21 18:10:53.900279750 +0100
> @@ -4757,6 +4757,18 @@ build_compound_expr (location_t loc, tre
>expr2 = TREE_OPERAND (exp
> A previous patch of mine implemented support for -maltivec=be for little
> endian targets when expanding the vec_insert and vec_extract builtins.
> However, I neglected to include test cases for V2DI and V2DF, which are
> implemented using VSX instructions and therefore need different compile
> o
On Tue, 21 Jan 2014, Matthew Fortune wrote:
> The MSA patch as submitted is another variation of O32 ABI which could
> be described as O32+FP64+MSA(+nan2008) and would be link incompatible
> with both O32 and O32+FP64(+/-nan2008). The same of course applies to
> N32/N64 being link incompatible
In this PR the problem was that the C FE, unlike the C++ FE, didn't
warn on e.g. bar (), 1;, that the RHS has no effect. This patch tries
to tweak the C FE so that it follows what the C++ FE does. Note that
the C++ FE uses quite imprecise locus info; the C FE's info is better.
I had to slightly a
Ian Lance Taylor writes:
> This patch moves to the gcc/ChangeLog file a gcc ChangeLog entry that
> was incorrectly added to the top-level ChangeLog file. Changes to
> ChangeLog files do not themselves get ChangeLog entries. Committed as
> obvious.
Sorry, this was my bad, not Kito's fault at all
Hi,
A previous patch of mine implemented support for -maltivec=be for little
endian targets when expanding the vec_insert and vec_extract builtins.
However, I neglected to include test cases for V2DI and V2DF, which are
implemented using VSX instructions and therefore need different compile
option
This patch moves to the gcc/ChangeLog file a gcc ChangeLog entry that
was incorrectly added to the top-level ChangeLog file. Changes to
ChangeLog files do not themselves get ChangeLog entries. Committed as
obvious.
Ian
Index: ChangeLog
===
On 01/18/14 03:12, Richard Sandiford wrote:
Jeff Law writes:
gcc/
* jump.c (delete_related_insns): Keep (use (insn))s.
* reorg.c (redundant_insn): Check for barriers too.
OK. Any chance you've got a testcase you can add to the suite? ISTM
it's potentially valuable given the p
As analysed in the bug report, the scope for the accessibility
check was incorrect, and hence the friend was not allowed access.
Fixed by pushing into the class scope before parsing the
base-clause, and popping afterwards to let the surrounding
nested-name-specifier popping work correctly.
Tested
OK, thanks.
Jason
Hi,
On 01/21/2014 03:55 PM, Jason Merrill wrote:
I think I would prefer to change the "child" assert to be
MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P.
.. Ok, but then it seems to me that we have to explicitly handle the
TYPENAME_TYPE case, otherwise we end up simply accepting the testcase
(ev
On Tue, Jan 21, 2014 at 10:11:45AM -0500, Jason Merrill wrote:
> I'm inclined to handle this situation by using a RANGE_EXPR in
> process_init_constructor_array, and then handling that appropriately
> in build_vec_init, so that we don't have to build up the huge
> CONSTRUCTOR. Would you like to do
On Tue, Jan 21, 2014 at 4:07 PM, Kirill Yukhin wrote:
>> > I have a doubts about changes to sse.md.
>> > I've splitted existing (SF-only) patterns into 2: DF and SF.
>> > As far as insn operands and final instruction have no such data
>> > type discrimination I set this data type to (mem:..) part
I'm inclined to handle this situation by using a RANGE_EXPR in
process_init_constructor_array, and then handling that appropriately in
build_vec_init, so that we don't have to build up the huge CONSTRUCTOR.
Would you like to do that, or shall I take it over?
Jason
Hello,
On 15 Jan 20:53, Uros Bizjak wrote:
> On Tue, Jan 14, 2014 at 7:13 AM, Kirill Yukhin
> wrote:
> > I have a doubts about changes to sse.md.
> > I've splitted existing (SF-only) patterns into 2: DF and SF.
> > As far as insn operands and final instruction have no such data
> > type discrimin
I think I would prefer to change the "child" assert to be
MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P.
Jason
Hi Richard,
I'd like to get some more of your thoughts on the ABI implications of MSA.
Generally, any thoughts you have (or anyone else) on the current state of MIPS
ABIs would be welcome. As an example I'm curious whether you see variations of
O32 as being new ABIs or extensions of O32, it can
On 12/17/2013 12:35 PM, Michael V. Zolotukhin wrote:
Here is a set of patches implementing one more piece of offloading support in
GCC. These three patches allow to build a host binary with target image and all
tables embedded. Along with patches for libgomp and libgomp plugin, which
hopefully
On Tue, Jan 21, 2014 at 2:42 PM, Ilya Tocar wrote:
> I found out that we forgot to implement some of AVX512 intrinsics.
> Here is a patch that adds them. Sorry for huge patch, but changes are
> mostly trivial.
> Ok for trunk?
> +(define_insn "avx512f_2_mask_store"
> + [(set (match_operand:PMOV_
Hi,
This patch fixes c-c++-common/asan/use-after-return-1.c not to fail on
darwin target (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897).
Ok to commit?
-Maxim.
2014-01-21 Dominique Dhumieres
* c-c++-common/asan/use-after-return-1.c: Fixed
to pass on darwin.
diff --git a/gcc/testsui
On 13 January 2014 19:27, Vidya Praveen wrote:
> Hello,
>
> This patch adds support to the SISD variants of SCVTF/UCVTF instructions.
> This also refactors the existing support for floating point instruction
> variants of SCVTF/UCVTF in order to direct the instruction selection based
> on the cons
2014/1/16 Alex Velenko :
> Hi,
> In previous BE patches the way lane indexing in lanes is calculated has
> been changed. To accommodate the change, arm neon intrinsics had to be
> updated.
>
> Is it okay?
OK /Marcus
On 16 January 2014 11:50, Alex Velenko wrote:
> Hi,
>
> This patch by James Greenhalgh fixes "by-lane" patterns broken by
> previous patches.
>
>
> Regression tested on aarch64-none-elf and aarch64_be-none-elf
> with no unexpected issues.
>
> OK?
>
OK /Marcus
On 16 January 2014 11:49, Alex Velenko wrote:
> Hi,
> This patch changes get_lane intrinsics to provide a correct big-endian
> indexing. This fixes numerous BE load and store issues based on getting
> correct lane.
>
> Is this good for trunk?
OK
/Marcus
On 16 January 2014 11:49, Alex Velenko wrote:
> Hi,
> This patch is the first patch in a series of patches fixing Big-Endian
> lane numbering. The goal of this series of patches is to make proper
> bridge between pure GCC big-endian view on lane numbering and internal
> architected view.
OK /Marc
> Patches should be posted to gcc-patches.
>From pr59897
--- ../_clean/gcc/testsuite/c-c++-common/asan/use-after-return-1.c
2014-01-09 10:14:04.0 +0100
+++ gcc/testsuite/c-c++-common/asan/use-after-return-1.c2014-01-09
15:51:04.0 +0100
@@ -48,6 +48,6 @@ int main(int
On Jan 20, 2014, Jakub Jelinek wrote:
> On Mon, Jan 20, 2014 at 06:24:36PM -0200, Alexandre Oliva wrote:
>> But I think this one is wrong.
>> if (var->onepart == ONEPART_VALUE)
>> {
>> if (local_get_addr_cache == NULL)
>> return;
> But when local_get_addr_cache is non-NULL, no matter if we fin
Hi,
in this relatively serious ICE on invalid regression (we don't emit any
sensible diagnostic before ICE-ing) the problem is that is_ancestor
simply asserts that the second argument can be only a NAMESPACE_DECL or
a CLASS_TYPE_P, whereas in the erroneous input at issue it's a
TYPENAME_TYPE.
On 23.12.2013 10:52, Andrey Belevantsev wrote:
Hello,
As described in the PR, the ICE reason was the typo made when introducing
calls to add_hard_reg_set. Fixed by the first attached patch, bootstrapped
and tested on both ia64 and x86_64, committed as obvious.
The test case is very sensitive t
On Tue, Jan 21, 2014 at 04:14:23PM +0400, Maxim Ostapenko wrote:
> > On x86_64-apple-darwin1* the test
> c-c++-common/asan/use-after-return-1.c (new at r206458) fails.
>
> Yes, unfortunately I forgot about this. The patch makes sense.
>
> Should I commit it to fix this bug?
Patches should be pos
Hi,
since there was no progress in the last 2 months on that matter,
and we are quite late in Phase 3 now,
I dare to propose an alternative, very simple solution for this bug now.
It does not try to improve or degade the perfomance at all, instead it simply
detects binary files with embedded NULs
> On x86_64-apple-darwin1* the test
c-c++-common/asan/use-after-return-1.c (new at r206458) fails.
Yes, unfortunately I forgot about this. The patch makes sense.
Should I commit it to fix this bug?
-Maxim
This patch redoes the data structures for pragma SPARK_Mode so
that the tree captures full information on the SPARK_Mode setting
in all cases, so that it can easily be accessed by gnat2why.
It also fully implements the error checking on "monotonicity" of
SPARK_Mode settings, and also properly chec
A project that is imported by an extended project was not allowed to be
extended. This patch fixes this.
Invoking
gnatmake -P test_util.gpr
should not result in an error such as
cannot extend an already imported project file
or
cannot import an already extended project file
with "test_b.gpr
Hi,
As with the AArch64 case,
( http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01317.html )
the way that we rewrite command lines for big.LITTLE systems
causes bugs where more than one source file is to be used.
The solution here is identical to that proposed for AArch64,
we update the spec comman
Hi,
As Charles Baylis pointed out here:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00921.html
The way that we rewrite command lines for big.LITTLE systems
causes bugs where more than one source file is to be used.
The problem fundamentally is that -mcpu never makes it to
the second cc1 invoca
Hi,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions with
mismatching no_sanitize_address attributes should not be considered for
inlining, otherwise the meaning of no_sanitize_address will not be
preserved.
I didn't get feedback in Bugz
> Apologies for the delay. The patch is OK.
Thanks. Committed revision 206875.
Thank you,
Tatiana Udalova
On 20/01/14 17:43 -0500, Tim Shen wrote:
The semantic of `nosubs` should simply be that `let all parentheses
not be a subexpression and do not capture it`.
It's not clear to me whether the standard says that nosubs implies
mark_count() == 0 or that the mark count remains the same, but no
sub-ex
On 20 January 2014 21:11, François Dumont wrote:
> On 01/20/2014 04:53 PM, Jonathan Wakely wrote:
>
> With this new design couldn't we change the conditions that are used to
> decide when to cache the hash code. I haven't study it in detail but it
> looks like the default constructible constraint
> Thanks, commited in 206458 without c-c++-common/asan/no-asan-stack.c
> testfile. ...
This caused http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897.
TIA
Dominique
Hi Gerald,
"command-line option", I think, and I suggest to use ... around
the actual options.
OK - I have made those changes and committed the result.
Cheers
Nick
This is an internal change to documentation, and the interface
to one function in the compiler. No functional effect, so no
test needed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-01-21 Robert Dewar
* sem_eval.adb (Compile_Time_Known_Value): Add Ignore_CRT
paramete
A compilation unit that is a subprogram is rewritten as a package (the wrapper
package) containing the body of the actual subprogram instance. The wrapping
happens when the unit is compiled upon its appearance in the context of some
unit. If it appears in several such contexts, and the subprogram i
If a user-defined operator renames a predefined one, a use of that operator is
rewritten with the predefined one, because the back-end requires it. This
transformation must not be performed when analyzing the expression in a pre- or
postcondition aspect or pragma, because the expression will be rea
This is a preliminary internal change for setting Do_Discriminant_Check
flags properly in the tree. No functional effect, so no test needed
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-01-21 Robert Dewar
* sinfo.ads, sinfo.adb: Change Do_Discriminant_Check to use new Flag1.
92 matches
Mail list logo
