2013/7/24 Steve Kargl :
> On Wed, Jul 24, 2013 at 11:53:09PM +0200, Janus Weil wrote:
>> Hi all,
>>
>> here is a straightforward patch for an ICE-on-invalid problem, which
>> basically adds some checks for 'class_ok'.
>>
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
>
> OK.
Thanks, St
Hi,
This fixes up the issues with PR target/19599 and the issues we've had
around it. This fixes up some of the current issues we have around this.
I'll follow up with a separate patch around longjmps.
This puts in predicates for bx where needed - missed out CCFSM (sigh :(
), replaces uses
Hi,
Dave spotted this leftover a while ago. The pa/t-openbsd file doesn't
exist anymore. Seems to have no ill effect, but would be good to
remove this wart anyway. Dave, can you commit this?
Thanks,
Mark
2013-07-25 Mark Kettenis
* config.gcc (hppa-*-openbsd*): Don't set tmake_fi
On OpenBSD/hppa the stack is protected against execution in the same
way as on many other architectures. The diff below makes GCC emit the
call that's needed to "unprotect" the stack such that the magic
trampolines needed for execution of nested functions work.
2013-07-25 Mark Kettenis
On 7/8/13 7:13 PM, Chung-Ju Wu wrote:
Hi, GCC Steering Committee, reviewers, and developers,
On behalf of Andes Technology Corp., we are submitting a new port 'nds32'
for GCC contribution. In this contribution, we use the design and strategy
as modern as possible, such as having LRA enabled and
Hi,
Please find the patch to add assembler option "-mcu" for generating assembler
error messages when target not supporting hardware FPU were seeing FPU code,
namely RX100 and RX200.
KPIT has recently submitted a patch to add warnings of RX variants that do not
have hardware FPU support,
http://w
Hi,
this is in fact a Regression in the 4_8-branch too.
For the testcase, when we try to produce at instantiation time the
warning about the unused parameter we re-enter the diagnostic routines
because cp_convert_to_pointer doesn't get, as it should, a tf_none - the
propagation breaks between
... sorry, attached the wrong ChangeLog entry. Fixed below.
Paolo.
//
/cp
2013-07-25 Paolo Carlini
PR c++/57981
* decl.c (check_default_argument): Take a tsubst_flags_t parameter.
(grokparms): Adjust.
* parser.c (cp_parser_late_parse_one_defaul
*Ping*
Richard, you approved adding "target nonpic" last time, could you
please take quick a look?
I regularly encounter failing due to "AVAIL_OVERWRITABLE" tests on
Android.. When people write tests they don't consider pic targets.
thanks,
Alexander
2013/7/8 Alexander Ivchenko :
> *Ping*
>
>>>
On Wed, Jul 24, 2013 at 8:27 PM, Kirill Yukhin wrote:
> Hello,
> By this patch I am starting series of patches toward Intel (R) AVX-512 and
> SHA (see [1])
> extensions enabling in GCC.
> I've already submitted corresponding patches to BinUtils (see [2],[3]).
>
> This patch adds comand-line optio
Hi Ramana,
why did you leave the space before the bx?
this ends up in the .s file making it look ugly..
+ return \" bx%?\\t%0\\t%@ indirect register sibling call\";
Regards
Bernd.
On Wed, Jul 24, 2013 at 8:27 PM, Kirill Yukhin wrote:
> Hello,
> By this patch I am starting series of patches toward Intel (R) AVX-512 and
> SHA (see [1])
> extensions enabling in GCC.
> I've already submitted corresponding patches to BinUtils (see [2],[3]).
>
> This patch adds comand-line optio
Hi,
On Wed, Jul 24, 2013 at 08:27:43PM -0400, David Malcolm wrote:
> On Wed, 2013-07-24 at 19:10 -0400, Diego Novillo wrote:
> > On Wed, Jul 24, 2013 at 6:56 PM, Diego Novillo wrote:
> > > Could you please add a description of what this does?
> >
> > Sorry. You did, but in a previous message th
This patch only moves ubsan ChangeLog entries to its own ChangeLogs,
to make merging easy.
This is only makeshift; when doing the final merge into trunk
I'll prepend the ubsan CL entries into regular CLs.
Applying to ubsan branch.
---
gcc/ChangeLog | 117
On Thu, Jul 25, 2013 at 12:40 PM, Bernd Edlinger
wrote:
> Hi Ramana,
>
> why did you leave the space before the bx?
> this ends up in the .s file making it look ugly..
Ooops - thanks for noticing - wasn't deliberate - fixed as obvious with this.
Ramana
Index: gcc/config/arm/arm.md
=
Hi,
I don't know why it's me again but again I do have a few comments.
One global remark first: If we are going to start using the gcc
namespace (I understand it you need for isolation of symbols once you
use gcc as library, right?), I'm wondering whether mixing "using
namespace gcc" and explicit
2013/7/25 Joseph S. Myers :
> On Wed, 24 Jul 2013, Ilya Enkovich wrote:
>
>> Well, this patch does not introduce any changes on user-visible level.
>> It just adds MPX instructions support to i386 target. Usually each new
>> x86 instruction has corresponding builtin function and therefore is
>> pro
Hi,
this is first patch that makes function body management more consistent to what
happens with variables. We now no longer incorrectly call
cgraph_release_function_body
for decls that are shared during LTO streaming and I fixed ipa.c to make proper
reachability analysis of partial symtabs seen
OK.
Jason
OK.
Jason
Documents and comments, along with a testcase for not-entirely-correct
basic_regex::position() behavior(when regex_iterator::operator++() is
called).
Thanks!
--
Tim Shen
comments.patch
Description: Binary data
2013/7/17 Cameron McInally :
> Ping.
>
> I do realize that patches of this nature are of low priority, but I
> would really like to see it committed to save my users from tripping
> over the docs.
>
> Thanks again,
> Cameron
>
> On Thu, Jun 13, 2013 at 9:58 PM, Cameron McInally
> wrote:
>> Hey guy
2013/7/17 Cameron McInally :
> Ping.
>
> On Fri, Jun 14, 2013 at 1:41 PM, Cameron McInally
> wrote:
>> Hey guys,
>>
>> The documentation states that the return types on the x86
>> __builtin_ia32_cmp*s builtins are integer vectors. This is
>> inconsistent with the source. These builtins actually re
On 25 July 2013 15:09, Tim Shen wrote:
> Documents and comments, along with a testcase for not-entirely-correct
> basic_regex::position() behavior(when regex_iterator::operator++() is
> called).
This is OK to commit, thanks.
On Thu, 25 Jul 2013, Ilya Enkovich wrote:
> > Usually also new instructions have a -m option to enable them, but you
> > don't have that here either. I realise the instructions are NOPs on
> > processors not supporting them (all processors not supporting them?), but
> > given that the availabilit
On Thu, Jul 25, 2013 at 4:25 PM, Chung-Ju Wu wrote:
> 2013/7/17 Cameron McInally :
>> Ping.
>>
>> I do realize that patches of this nature are of low priority, but I
>> would really like to see it committed to save my users from tripping
>> over the docs.
Please provide ChangeLog entries for both
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960
The patch was successfully bootstrapped and tested on s390 and x86/x86-64.
Committed as rev. 201243.
2013-07-25 Vladimir Makarov
PR rtl-optimization/57960
* lra-constraints.c (process_alt_operands):
Hi all,
Some of the new alternatives added to the add patterns in arm.md recently to
accommodate 16-bit encodings have the output template "add %0, %2" if operand
1 is the same register as the destination (operand 0). This would be fine,
except that the two source operands for the add patterns are
Hi all,
The ssmulsa3 and usmulusa3 fixed point arithmetic patterns contain explicit IT
blocks in their output template that do not conform to the ARMv8 IT block
rules. This patch fixes that. Also cleans up various whitespace issues in the
arm-fixed.md file.
Tested arm-none-eabi on qemu with arch
Hi!
I'd like to announce first version of the Undefined Behavior
Sanitizer, a tool I've spent this June/July hacking on.
It is an undefined behavior detector for the C family FEs
and works by creating a COMPOUND_EXPR around original expression,
for slightly more information see my slides about u
Committed.
Dave
On 25-Jul-13, at 5:50 AM, Mark Kettenis wrote:
Hi,
Dave spotted this leftover a while ago. The pa/t-openbsd file doesn't
exist anymore. Seems to have no ill effect, but would be good to
remove this wart anyway. Dave, can you commit this?
Thanks,
Mark
2013-07-25 Mark Ke
Committed.
On 25-Jul-13, at 6:00 AM, Mark Kettenis wrote:
On OpenBSD/hppa the stack is protected against execution in the same
way as on many other architectures. The diff below makes GCC emit the
call that's needed to "unprotect" the stack such that the magic
trampolines needed for execution
OK for trunk? ("make info" and "make dvi" seem to work, though I don't
have a dvi viewer handy).
commit fb34f52e9f9f1dcce416cb45dab23ec10625ad16
Author: David Malcolm
Date: Thu Jul 25 12:07:26 2013 -0400
gcc/
* doc/install.texi (A POSIX or SVR4 awk): Add note about not
relying on
Hi all,
Currently on arm we miss some opportunities to generate the cmn instruction
(cmn r1, r2 ~ r1 + r2 == 0)
For example, for code:
int foo (int x, int y)
{
if (x + y == 0)
return 25;
else
return 5;
}
we generate
add r0, r0, r1
cmp r0, #0
movn
On 25/07/13 16:31, Kyrylo Tkachov wrote:
Hi all,
Some of the new alternatives added to the add patterns in arm.md recently to
accommodate 16-bit encodings have the output template "add %0, %2" if operand
1 is the same register as the destination (operand 0). This would be fine,
except that the t
On 25/07/13 17:13, Kyrylo Tkachov wrote:
Hi all,
Currently on arm we miss some opportunities to generate the cmn instruction
(cmn r1, r2 ~ r1 + r2 == 0)
For example, for code:
int foo (int x, int y)
{
if (x + y == 0)
return 25;
else
return 5;
}
we generate
add r
On 25/07/13 16:30, Kyrylo Tkachov wrote:
Hi all,
The ssmulsa3 and usmulusa3 fixed point arithmetic patterns contain explicit IT
blocks in their output template that do not conform to the ARMv8 IT block
rules. This patch fixes that. Also cleans up various whitespace issues in the
arm-fixed.md fil
On Thu, Jul 25, 2013 at 10:28 AM, Chung-Ju Wu wrote:
> 2013/7/17 Cameron McInally :
>> Ping.
>>
>> On Fri, Jun 14, 2013 at 1:41 PM, Cameron McInally
>> wrote:
>>> Hey guys,
>>>
>>> The documentation states that the return types on the x86
>>> __builtin_ia32_cmp*s builtins are integer vectors. Thi
On Thu, Jul 25, 2013 at 10:57 AM, Uros Bizjak wrote:
> On Thu, Jul 25, 2013 at 4:25 PM, Chung-Ju Wu wrote:
>> 2013/7/17 Cameron McInally :
>>> Ping.
>>>
>>> I do realize that patches of this nature are of low priority, but I
>>> would really like to see it committed to save my users from tripping
Successfully bootstrapped on x86_64-unknown-linux-gnu
OK for trunk?
commit 4d7b6e5cf8e7f2613f516c9b9fe1f888b1193f8d
Author: David Malcolm
Date: Tue Jul 23 16:11:14 2013 -0400
Add missing deps to tree-sra.o
gcc/
* Makefile.in (tree-sra.o): Add missing deps on TREE_PASS_H and
On Thu, Jul 25, 2013 at 01:21:27PM -0400, David Malcolm wrote:
> Successfully bootstrapped on x86_64-unknown-linux-gnu
>
> OK for trunk?
> commit 4d7b6e5cf8e7f2613f516c9b9fe1f888b1193f8d
> Author: David Malcolm
> Date: Tue Jul 23 16:11:14 2013 -0400
>
> Add missing deps to tree-sra.o
>
Hi all,
here is a small patch for a rejects-valid OOP problem, where a
type-bound call was resolved before the base type and its bindings.
I'm adding a call to resolve_fl_derived, in order to make sure that
the base type is resolved beforehand.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Janus Weil wrote:
here is a small patch for a rejects-valid OOP problem, where a
type-bound call was resolved before the base type and its bindings.
I'm adding a call to resolve_fl_derived, in order to make sure that
the base type is resolved beforehand.
Regtested on x86_64-unknown-linux-gnu. Ok
Hello Richard,
Sorry in the last days, I was not at home. So I couldn't test it until now.
> "Jürgen Urban" writes:
> > Index: gcc/config.gcc
> > ===
> > --- gcc/config.gcc (Revision 200583)
> > +++ gcc/config.gcc (Arbeitskopie)
>
On 07/25/2013 10:13 AM, Kyrylo Tkachov wrote:
Hi all,
Currently on arm we miss some opportunities to generate the cmn instruction
(cmn r1, r2 ~ r1 + r2 == 0)
For example, for code:
int foo (int x, int y)
{
if (x + y == 0)
return 25;
else
return 5;
}
we generate
add
"Jürgen Urban" writes:
>> "Jürgen Urban" writes:
>> > Index: gcc/config.gcc
>> > ===
>> > --- gcc/config.gcc (Revision 200583)
>> > +++ gcc/config.gcc (Arbeitskopie)
>> > @@ -3080,7 +3080,7 @@
>> >esac
>> > fi
>> >
>> > -# Infer
The enclosed patch refactors the logic that decides if a pubname
belongs in the output, taking into account type pruning in the
presence of debug types.
When the logic was separate, it didn't always agree, creating issues
with the size output to the object file. Older editions of Gold didn't
use t
2013/7/25 Tobias Burnus :
> Janus Weil wrote:
>>
>> here is a small patch for a rejects-valid OOP problem, where a
>> type-bound call was resolved before the base type and its bindings.
>> I'm adding a call to resolve_fl_derived, in order to make sure that
>> the base type is resolved beforehand.
>
Janus Weil wrote:
2013/7/25 Tobias Burnus :
Looks fine to me. (If I tracked the PR correctly, it only solves the
original problem but not yet the one of comment 5, does it?)
No, this one should actually fix both. I can also add the variant from
comment 5 to the test case, if you prefer.
I thi
> gcc/ChangeLog
> 013-07-25 Sterling Augustine
>
> * dwarf2out.c (size_of_pubnames): Move code to...
> (include_pubname_in_output): ...here. New.
> (want_pubnames): Rearrange.
> (output_pubnames): Call include_pubname_in_output. Move assertion.
This is OK. Thanks!
-cary
2013/7/25 Tobias Burnus :
> Janus Weil wrote:
>>
>> 2013/7/25 Tobias Burnus :
>>
>>> Looks fine to me. (If I tracked the PR correctly, it only solves the
>>> original problem but not yet the one of comment 5, does it?)
>>
>> No, this one should actually fix both. I can also add the variant from
>>
On 07/25/2013 10:19 AM, Andrew Sutton wrote:
+ pp_cxx_parameter_declaration_clause(pp, TREE_OPERAND (t, 0));
Space before (. Otherwise, looks good.
Jason
Hi,
as discussed once more in the audit trail of PR57974 and agreed with
Gaby I'm going to re-enable the overload. Tested x86_64-linux.
Thanks,
Paolo.
//
2013-07-25 Paolo Carlini
* include/std/complex (pow(const complex<>&, int)): Enable in
C++11 mode t
On 07/25/2013 11:32 AM, Marek Polacek wrote:
+ vec_alloc (v, 3);
+ tree ctor = build_constructor (dtype, v);
You might use build_constructor_va instead of managing a vector directly.
Otherwise, looks fine. If nobody else has comments, go ahead and check
it in next week.
Jason
On Thu, Jul 25, 2013 at 04:13:29PM -0400, Jason Merrill wrote:
> On 07/25/2013 11:32 AM, Marek Polacek wrote:
> >+ vec_alloc (v, 3);
> >+ tree ctor = build_constructor (dtype, v);
>
> You might use build_constructor_va instead of managing a vector directly.
Thanks, will give it a try.
> Otherw
There is an order-only dependency in gcc/Makefile.in that tries to
build the generated files before compiling regular objects. However,
this appears too early, and so at the time it is seen by make,
GCOV_OBJS and GCOV_DUMP_OBJS have not yet been set.
This patch fixes the problem and prevents any
This changes the handling of SHLIB so that it is inlined into
DRIVER_DEFINES. This is ok because SHLIB is defined in a Makefile
fragment that is included by the generated Makefile.
The rationale for this is that it simplifies some .o targets, so that
we can share more code.
* Makefile.in
A few generated files were not mentioned in the generated_files
variable. This fixes the problem.
* Makefile.in (generated_files): Add options.h,
target-hooks-def.h, insn-opinit.h,
common/common-target-hooks-def.h.
---
gcc/Makefile.in | 4 +++-
1 file changed, 3 insertion
This converts the C front end.
Note that this fixes a latent bug in gcc/Makefile.in's definition of
C_TREE_H. This is needed to avoid breaking this build with this
patch.
* Makefile.in (C_TREE_H): Reference c/c-tree.h.
* Make-lang.in (c/gccspec.o): Remove.
(CFLAGS-c/gccs
This converts the C++ front end.
This renames g++spec.o to cp/g++spec.o for uniformity.
This lets us remove an explicit rule.
This patch does not remove various *_H macros from cp/Make-lang.in.
These are still needed by ObjC++. They're removed by a later patch.
* Make-lang.in (g++spec.o
This converts the ObjC++ front end.
Now we can finally remove the *_H macros from cp/Make-lang.in.
* Make-lang.in (CXX_TREE_H, CXX_PARSER_H, CXX_PRETTY_PRINT_H):
Remove.
* Make-lang.in (START_HDRS, cc1objplus-checksum.o)
(objcp/objcp-lang.o, objcp/objcp-decl.o
This converts the ObjC front end.
Note that there is a latent possible bug in this code -- both ObjC and
ObjC++ define START_HDRS. Whichever is included last, wins; if they
are out of sync, then something could break. This possibility is
eliminated by this series.
* Make-lang.in (START_
This adds the configury needed for automatic dependency tracking. It
also adds some bits to the Makefile so we can begin converting
(removing) explicit dependencies.
* Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
(COMPILE): New variables.
(.cc.o .c.o): Use COMPIL
This converts the Java front end.
We also rename jvspec.o to java/jvspec.o, for uniformity; this lets us
remove an explicit rule.
* Make-lang.in (jvspec.o): Remove.
(CFLAGS-java/jvspec.o): New variable.
($(XGCJ)$(exeext), java_OBJS): Use java/jvspec.o
(java/jvspec.
This removes manual dependencies for the c-family .o files.
* Makefile.in (c-family/cppspec.o, c-family/c-common.o)
(c-family/c-cppbuiltin.o, c-family/c-dump.o, c-family/c-format.o)
(c-family/c-gimplify.o, c-family/c-lex.o, c-family/c-omp.o)
(c-family/c-opts.o, c-fa
This convert fortran.
It renames gfortranspec.o to fortran/gfortranspec.o, for uniformity
and to allow removing an explicit rule.
* Make-lang.in (fortran_OBJS): Use fortran/gfortranspec.o.
(gfortranspec.o): Remove.
(CFLAGS-fortran/gfortranspec.o): New variable.
(GF
There is a single reference to TREE_GIMPLE_H in the source tree.
Since it is not defined anywhere, we might as well remove the use.
* config/i386/t-i386 (i386.o): Don't use TREE_GIMPLE_H.
---
gcc/config/i386/t-i386 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/co
This converts Go.
It renames gospec.o to go/gospec.o, for uniformity and so we can
remove an explicit rule.
It defines go_OBJS, to conform to the documented Make-lang.in
conventions, and to ensure that Go objects are given the correct
order-only dependencies on generated files.
* Make-la
This is a small change to make out_object_file use automatic
dependencies.
* Makefile.in ($(out_object_file)): Use COMPILE.
---
gcc/Makefile.in | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 2da93021..b689442 100644
This converts LTO.
This also fixes a latent buglet in lto/Make-lang.in. lto_OBJS should
hold all the objects for a language, but LTO never defined this.
* Make-lang.in (LTO_H, LINKER_PLUGIN_API_H, LTO_TREE_H)
(lto/lto-lang.o, lto/lto.o, lto/lto-partition.o)
(lto/lto-objec
I used this perl script to find unused _H macros in the Makefile. I
deleted the definitions it reported and re-ran the script, until there
was no more output.
The script also makes note of _H variables which are used but never
defined. That is how I found the TREE_GIMPLE_H use, fixed earlier in
There is a single definition of CROSS_FLOAT_H in the source.
As far as I can tell, this is never used anywhere.
So, this patch removes it.
* config/mcore/t-mcore (CROSS_FLOAT_H): Remove.
---
gcc/config/mcore/t-mcore | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/mcore/t-
Somehow "patch #0" of my series didn't go out. So, I'm sending it
separately. Sorry about that. I don't know what happened, so I
wouldn't be totally surprised if it made its way to the list some day :)
This patch series resurrects my automatic dependency tracking patch from
eons ago.
That pat
On Thu, Jul 25, 2013 at 7:07 PM, Cameron McInally
wrote:
I do realize that patches of this nature are of low priority, but I
would really like to see it committed to save my users from tripping
over the docs.
>>
>> Please provide ChangeLog entries for both patches, and I'll commit
Committed as r201254.
Cheers,
Janus
2013/7/25 Janus Weil :
> 2013/7/25 Tobias Burnus :
>> Janus Weil wrote:
>>>
>>> 2013/7/25 Tobias Burnus :
>>>
Looks fine to me. (If I tracked the PR correctly, it only solves the
original problem but not yet the one of comment 5, does it?)
>>>
>>> N
On Wed, Jul 24, 2013 at 3:21 PM, Xinliang David Li wrote:
> Can you collect some number on ggc_memory increase with this change
> in profile_gen build -- the value is recorded gcov_module_info object
> in coverage.c.
The ggc_memory increase if < 0.2% for large modules (initial usage
around 100MB
the patch is ok.
thanks,
David
On Thu, Jul 25, 2013 at 2:53 PM, Sriraman Tallam wrote:
> On Wed, Jul 24, 2013 at 3:21 PM, Xinliang David Li wrote:
>> Can you collect some number on ggc_memory increase with this change
>> in profile_gen build -- the value is recorded gcov_module_info object
>>
This patch is a follow up to the resolve part, which permits
TYPE=>CLASS. That approved patch is at
http://gcc.gnu.org/ml/fortran/2013-06/msg00049.html (I didn't want to
commit it without this trans*.c patch.)
The attached patch adds support for:
TYPE => CLASS
additionally, it fixes some i
On Tue, 23 Jul 2013, Hans-Peter Nilsson wrote:
> Please put the "as it would" parts of the changelog entries as
> comments in the code instead. (ChangeLog says "what", not "why".)
>
> I'd also tweak the head comment of warn_portable_volatility_p
> (like the documentation change) to not refer to
> -
On Thu, 25 Jul 2013, Marek Polacek wrote:
> So far it sanitizes division-by-zeros, shifts and
> __builtin_unreachable calls. This is of course far from being
> complete; I intend to write more features during this 4.9 stage.
Such as everything needed for it to replace -ftrapv (for -ftrapv to bec
On Thu, 25 Jul 2013, Marek Polacek wrote:
> +@item -fsanitize=undefined
> +Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector
> +Various computations will be instrumented to detect
> +undefined behavior, e.g.@: division by zero or various overflows.
The same issues applies as f
On Thu, 25 Jul 2013, David Malcolm wrote:
> OK for trunk? ("make info" and "make dvi" seem to work, though I don't
> have a dvi viewer handy).
This seems the wrong place. A statement about "awk scripts should not" is
information for people modifying GCC, but install.texi is documentation
for
On Thu, 25 Jul 2013, Tom Tromey wrote:
> That patch was ultimately reverted due to a GNU make bug. This time
> around, thanks to git, I chose to make a patch series. This way, even
> if we stumble across the bug again (it is not clear it was ever
> fixed), we can determine which patch triggers i
I tried to reproduce the original bugs that led to these patterns, but
was unable. Testsuite results are the same with and without, and
eembc code size doesn't change.
So, I'm removing these patterns from the port.
The remaining (subreg...) patterns are just optimizations.
; This pattern is i
On Thu, Jul 25, 2013 at 3:31 PM, Tom Tromey wrote:
> This converts the C++ front end.
>
> This renames g++spec.o to cp/g++spec.o for uniformity.
> This lets us remove an explicit rule.
>
> This patch does not remove various *_H macros from cp/Make-lang.in.
> These are still needed by ObjC++. They
Joseph> Thus, it would seem appropriate, for each of the 18 successive
Joseph> states after an initial subsequence of the patches is applied,
Joseph> to verify that, if you build with make 3.81, touch Makefile.in
Joseph> and then do make -j2 cc1, it does not produce the hang
Joseph> previously obse
On 07/25/2013 04:40 PM, Joseph S. Myers wrote:
On Thu, 25 Jul 2013, Marek Polacek wrote:
So far it sanitizes division-by-zeros, shifts and
__builtin_unreachable calls. This is of course far from being
complete; I intend to write more features during this 4.9 stage.
Such as everything needed
On Thu, Jul 25, 2013 at 9:50 PM, Jeff Law wrote:
> On 07/25/2013 04:40 PM, Joseph S. Myers wrote:
>>
>> On Thu, 25 Jul 2013, Marek Polacek wrote:
>>
>>> So far it sanitizes division-by-zeros, shifts and
>>> __builtin_unreachable calls. This is of course far from being
>>> complete; I intend to wr
On Thu, 25 Jul 2013, Joseph S. Myers wrote:
On Thu, 25 Jul 2013, Marek Polacek wrote:
So far it sanitizes division-by-zeros, shifts and
__builtin_unreachable calls. This is of course far from being
complete; I intend to write more features during this 4.9 stage.
Such as everything needed fo
Hello!
> The (static arg) generator functions are casted to a var arg
> function pointer, making the assumption that the ABI for passing
> the arguments will be the same as for static arguments.
> This isn't a valid assumption on all architectures, var args might for
> example be passed on the sta
90 matches
Mail list logo
