On 08/28/13 12:52, Jan Hubicka wrote:
What is really important for backend is that it is not defined what happens
when you compare addresses of those functions (based on fact that youcan't take
it, as for ctors/dtors, or compare it, as for virtual functions). If backend
also knows that they
On Tue, Sep 03, 2013 at 06:59:30PM -0700, Brooks Moses wrote:
The attached patch fixes bug 58312, by replacing the runtime check of
vsnprintf with a compile-time check -- which means that it now
performs the same checks for both native and cross compilers, ensuring
consistency instead of the
Hi Maxim,
2013/9/4 Maxim Kuvyrkov ma...@kugelworks.com:
On 23/08/2013, at 1:04 AM, Alexander Ivchenko wrote:
Ugh.. thanks, you are right. That points to another problem that I
didn't see before:
3) *linux* targets that do not append to tm_p_file (s390x-*-linux* and
s390x-ibm-tpf* - your
Hi Jakub,
thanks for your review. I also answered Maxim in the initial thread.
I agree we your points about not enforcing Android stuff into all
*linux* targets, but for e.g
tm_file=$tm_file linux-android.h
.. this enforcing been there before my patch and therefore it would be
better to address
On 3/09/2013, at 5:53 PM, Jakub Jelinek wrote:
On Tue, Sep 03, 2013 at 09:25:31AM +0400, Alexander Ivchenko wrote:
Several builds are broken after r201838.
What targets actually support bionic? If it is just arm, i?86/x86_64
and perhaps aarch64 and nothing else, I'd like to question the
On 4/09/2013, at 7:43 PM, Alexander Ivchenko wrote:
Hi Maxim,
2013/9/4 Maxim Kuvyrkov ma...@kugelworks.com:
On 23/08/2013, at 1:04 AM, Alexander Ivchenko wrote:
Ugh.. thanks, you are right. That points to another problem that I
didn't see before:
3) *linux* targets that do not append
On Tue, 3 Sep 2013 21:20:04, Joseph S. Myers wrote:
On Tue, 3 Sep 2013, Bernd Edlinger wrote:
The trouble is that AAPCS semantics are incompatible with the default GNU
semantics for non-packed structures as well - AAPCS
strict-volatile-bitfields is only compatible with --param
On Wed, Sep 04, 2013 at 08:02:13PM +1200, Maxim Kuvyrkov wrote:
Nominal handling of Bionic by all *linux* targets is my fault, and it
seemed like a good thing at the time. With several iterations of
improvements laid on top of this initial decision it now becoming a mess.
I'm thinking along
On Tue, Sep 3, 2013 at 9:39 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Aug 30, 2013 at 11:28 PM, Sharad Singhai sing...@google.com wrote:
Found the issue. The stream was incorrectly being closed when it was
stderr/stdout. So only the dump output before the first dump_finish
call
On Wed, Sep 4, 2013 at 5:16 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
bootstrapped on x86_64-unknown-linux-gnu with same test results as unpatched
r202185 ok?
That looks like a not too useful part-C++-ification of domwalk. A proper
C++-ification would
Hello,
Richard Biener richard.guent...@gmail.com a écrit:
[...]
DECL_IS_BUILTIN is true if the decl was created by the frontend / backend
rather than by user code (indicated by source location). DECL_BUILT_IN
is true if the decl represents a function of the standard library, a
builtin that
Hello,
Could you use the existing facilities instead, such as adjust_priority hook,
or making the compare-branch insn sequence a SCHED_GROUP?
Alexander
The patch below moves IVOPTs out of the GIMPLE loop pipeline more
closer to RTL expansion. That's done for multiple reasons.
First, the loop passes that at the moment preceede IVOPTs leave
around IL that is in desparate need of basic re-optimization
like CSE, constant propagation and DCE. That
The boehm-gc tests currently fail to build with a linker with
--no-copy-dt-needed-entries as the default. dlopen is referenced in the libgcjgc
library itself, so link it with -ldl. The macro name EXTRA_TEST_LIBS is a bit
unfortunate now, but it is the right way to find the library name, as done
... assuming the general idea makes sense, this version may be better
because, at the cost of 3 lines of code duplication, it cuts the
unnecessary function calls, eg exactly zero if the struct doesn't have
anonymous aggregates at all. The patch is also easier to read ;)
Booted and tested
On Wed, Sep 4, 2013 at 10:46 AM, Dodji Seketeli do...@seketeli.org wrote:
Hello,
Richard Biener richard.guent...@gmail.com a écrit:
[...]
DECL_IS_BUILTIN is true if the decl was created by the frontend / backend
rather than by user code (indicated by source location). DECL_BUILT_IN
is
On 09/04/2013 11:00 AM, Matthias Klose wrote:
The boehm-gc tests currently fail to build with a linker with
--no-copy-dt-needed-entries as the default.
Hmm, isn't that a bug in the linker?
Andrew.
Am 04.09.2013 12:21, schrieb Andrew Haley:
On 09/04/2013 11:00 AM, Matthias Klose wrote:
The boehm-gc tests currently fail to build with a linker with
--no-copy-dt-needed-entries as the default.
Hmm, isn't that a bug in the linker?
No, it's the default in gold and in the bfd linker since
On 09/04/2013 11:24 AM, Matthias Klose wrote:
Am 04.09.2013 12:21, schrieb Andrew Haley:
On 09/04/2013 11:00 AM, Matthias Klose wrote:
The boehm-gc tests currently fail to build with a linker with
--no-copy-dt-needed-entries as the default.
Hmm, isn't that a bug in the linker?
No, it's
On Tue, Sep 3, 2013 at 3:04 PM, Thomas Koenig tkoe...@netcologne.de wrote:
Hello world,
here is a rewrite, which I hope make things more clear.
Unformatted sequential files are now made up of subrecords, where
a logical record may only have one.
Looks ok.
Regarding block devices: I don't
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-09-04 Gabriel Dos Reis g...@integrable-solutions.net
c-family/
* c-pretty-print.h (c_pretty_printer::simple_type_specifier): Now
a virtual member function.
(pp_simple_type_specifier): Remove.
It looks to me like this will result in duplicate diagnostics for
invalid members in a nested anonymous union. Maybe make the recursive
part only handle access setting?
Jason
The vaddvq_s64 and vaddvq_u64 intrinsics are defined to return 32-bit
types. This is clearly wrong, so fix them to return int64_t and uint64_t
as expected.
Regression tested with a run through aarch64.exp and sanity checked.
OK for trunk?
Thanks,
James
---
gcc/
2013-09-04 James Greenhalgh
Hi,
On Tue, 3 Sep 2013, David Malcolm wrote:
I can't really say I find this shorter, easier to read, more
expressive or even safer than what was there before. And the
repetition for adding the helpers for const and non-const types
all the time doesn't make it better.
I fully agree with you, the current default state of
-fstrict-volatile-bitfields should be disabled for all targets.
Please don't do that until gcc produces code that does the same
things. Most of my targets rely on gcc not doing the old behavior, to
generate correct code.
For portability
On Fri, Aug 23, 2013 at 09:49:55PM +, Joseph S. Myers wrote:
On Thu, 22 Aug 2013, Selvaraj, Senthil_Kumar wrote:
2013-08-23 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com
* c-typeck.c (output_pending_init_elements): Handle overflow of
constructor_unfilled_index.
On Wed, 4 Sep 2013 09:29:02, DJ Delorie wrote:
I fully agree with you, the current default state of
-fstrict-volatile-bitfields should be disabled for all targets.
Please don't do that until gcc produces code that does the same
things. Most of my targets rely on gcc not doing the old
On Wed, Sep 4, 2013 at 1:46 AM, Dodji Seketeli do...@seketeli.org wrote:
+/* In a FUNCTION_DECL, nonzero means a built in function of a
+ standard library or more generally a built in function that is
+ recognized by optimizers and expanders.
+
+ Note that it is different from the
On Mon, 2013-09-02 at 14:35 +0200, Martin Jambor wrote:
Hi,
On Fri, Aug 30, 2013 at 03:21:22PM -0400, David Malcolm wrote:
Apart from the GTY aspect, how do people feel about the patch series?
FWIW I have vague thoughts about doing something similar for tree -
doing so *might*
On Wed, Sep 4, 2013 at 3:55 PM, DJ Delorie d...@redhat.com wrote:
How about this for a compromise: Let's make the default of
-fstrict-volatile-bitfields an optional configure argument for gcc
4.9, that can be used for every target, even for X86_64 of you want ?
I don't care how it's enabled
On 04/09/13 14:12, James Greenhalgh wrote:
The vaddvq_s64 and vaddvq_u64 intrinsics are defined to return 32-bit
types. This is clearly wrong, so fix them to return int64_t and uint64_t
as expected.
Regression tested with a run through aarch64.exp and sanity checked.
OK for trunk?
You mean the C++11 application or the driver? You mean
-fstrict-volatile-bitfields or -fno-strict-volatile-bitfields?
I mean, if the typedef for a volatile bitfield says char gcc can't
generate an HImode access, by default.
On 09/04/2013 08:59 AM, Trevor Saunders wrote:
On Wed, Sep 04, 2013 at 10:32:17AM +0200, Richard Biener wrote:
On Wed, Sep 4, 2013 at 5:16 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
bootstrapped on x86_64-unknown-linux-gnu with same test results as unpatched
Hi,
this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
functions w/o
bodies I did not really anticipate.
Here removal of the arguments changes mangling algorithm if
set_decl_assembler_name is invoked late. This is something I wanted to get rid
of for a long time: we
On Wed, 4 Sep 2013, Senthil Kumar Selvaraj wrote:
Reattaching the patch with a testcase for the AVR target. I'm not sure
how to generalize the testcase for other targets - the constant is the
max value (unsigned) of the mode used to represent initialized array
indices.
Logically that should
Hi all,
d_print_comp maintains a certain amount of scope across calls (namely
a stack of templates) which is used when evaluating references in
template argument lists. If such a reference is later used from a
subtitution then the scope in force at the time of the substitution is
used. This
On 09/03/2013 11:01 AM, Andrew Sutton wrote:
Attached is a patch for constrained class templates. It's the 3rd time
I've sent it.
Please feel free to ping me if you're waiting for a patch review; once a
week is not too much.
1. Type constraints are checked on lookup rather than
On Wed, Sep 04, 2013 at 06:04:09PM +0200, Jan Hubicka wrote:
* cgraphunit.c (analyze_functions): Populate assembler names once done
with early unreachable function removal.
Please add some of the testcases from the PRs and mention the PRs in the
ChangeLog entry.
--- cgraphunit.c
Hi,
This patch adds the support for the crc extension option to the aarch64
gcc driver.
OK for the trunk?
Thanks,
Yufeng
gcc/
* config/aarch64/aarch64-option-extensions.def: Add
AARCH64_OPT_EXTENSION of 'crc'.
* config/aarch64/aarch64.h (AARCH64_FL_CRC): New define.
How about this for a compromise: Let's make the default of
-fstrict-volatile-bitfields an optional configure argument for gcc
4.9, that can be used for every target, even for X86_64 of you want ?
I don't care how it's enabled (currently, each target that wants it,
sets it) as long as a plain
1. Type constraints are checked on lookup rather than instantiation.
How is this different from function template constraints? Is this just a
difference in internal function name (instantiate_template vs
lookup_template_class)?
It's not supposed to be different. Checking constraints in
Hi,
On 09/04/2013 03:11 PM, Jason Merrill wrote:
It looks to me like this will result in duplicate diagnostics for
invalid members in a nested anonymous union. Maybe make the recursive
part only handle access setting?
Indeed. I think the recursive part already does that, because only the
AIX does not support undefined weak. Skip those tests in the testsuite.
Also, select COFF as AIX file format without requiring objdump.
* gcc.dg/attr-weakref-1.c: Skip on AIX.
* gcc.dg/torture/pr53922.c: Skip on AIX.
* lib/file-format.exp (gcc_target_object_format): AIX is COFF.
Bootstrapped on
Ping
2013/8/20 Romain Geissler romain.geiss...@gmail.com:
Hi,
According to the C++ standard §17.4.3.4(2,3) the global new and delete
operator implementation can be replaced by the program. For example,
tcmalloc does redefine them. On ELF targets, it is currently OK if you
link libstc++
On Sep 4, 2013, at 7:09 AM, Jan Hubicka hubi...@ucw.cz wrote:
Making gengtype to generate ggc_mark for each type would make hand writting
easier - you can use C++ overloading instead of trying to guess the funny
names gengtype uses right now.
But that is independent of this change. I am
On Wed, 4 Sep 2013, Bernd Edlinger wrote:
How about this for a compromise: Let's make the
default of -fstrict-volatile-bitfields an optional
configure argument for gcc 4.9, that can be used for every
target, even for X86_64 of you want ?
I think it's generally a bad idea for semantic
On Wed, Sep 04, 2013 at 10:32:17AM +0200, Richard Biener wrote:
On Wed, Sep 4, 2013 at 5:16 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
bootstrapped on x86_64-unknown-linux-gnu with same test results as
unpatched r202185 ok?
That looks like a not too
On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote:
On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
Now I think this is good opportunity for a simple heuristic:
If a statement is at loop level 1 we can move it out of the loop,
regardless of the fact, that it
On Sep 4, 2013, at 7:30 AM, Romain Geissler romain.geiss...@gmail.com wrote:
2013-08-20 Romain Geissler romain.geiss...@gmail.com
* config/os/gnu-linux/os_defines.h: (_GLIBCXX_WEAK_DEFINITION): Define.
Strikes me as wrong. Using weak should be autoconfed or driven by the compiler
and
On Wed, Sep 4, 2013 at 12:01 AM, Jakub Jelinek ja...@redhat.com wrote:
That looks wrong, the test was intentionally looking for badly implemented
vsnprintf, see
http://www.gnu.org/software/gnulib/manual/html_node/snprintf.html
This function does not return a byte count as specified in C99 on
(This patch supercedes this one:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01462.html)
The movdi_aarch64 pattern allows moving a constant into an FP_REG,
but has the constraint Dd, which is stricter than the constraint N for
moving a constant into a CORE_REG. This is due to restricted values
Hi,
as Michael pointed out, I introduced long lines primarily because of large
indentation in cgraph_analyze_function. It makes the code to look better
if the polymorphic call logic in broken out.
Bootstrapping/regtesting x86_64-linux, will commit it once testing conlcude.
Honza
*
On Sat, 2013-08-31 at 19:27 +0200, Richard Biener wrote:
David Malcolm dmalc...@redhat.com wrote:
On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote:
On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher
stevenb@gmail.com wrote:
On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
functions w/o
bodies I did not really anticipate.
[...]
I would like to basically ask if it seems to make sense to go this route and
try to get rid of those declarations.
On Wed, Sep 04, 2013 at 09:41:20AM -0700, Brooks Moses wrote:
Not sure which of the targets from the above list we still support,
certainly at least mingw, though in that case I don't know if it hasn't been
fixed there. So, as Joseph said, you probably should keep the runtime test
as is,
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
functions w/o
bodies I did not really anticipate.
[...]
I would like to basically ask if it seems to make sense to go this route and
try to get rid of those
On 09/04/2013 11:59 AM, Andrew Sutton wrote:
It's not supposed to be different. Checking constraints in
instantiate_template is actually too late. We want to check before
instantiation, at the point of use.
Right, what I was getting at is that instantiate_template actually only
instantiates
On 09/03/2013 06:03 AM, Tom de Vries wrote:
* semantics.c (finish_transaction_stmt, build_transaction_expr): Handle
flag_exceptions.
I'd rather handle this at a lower level, by making
build_must_not_throw_expr return its argument if -fno-exceptions.
Jason
On 09/04/2013 07:09 PM, Jan Hubicka wrote:
How do you support KR functions here? My basic idea was that TYPE_ARG_TYPES
should give enough information about external function calling convention
anyone will ever need. I would hope that this will be sufficient for your
use, too, despite the fact
On 09/04/2013 10:42 AM, Paolo Carlini wrote:
Indeed. I think the recursive part already does that, because only the
first time is called complain == true (thus does exactly what the
current code does), then when the recursion proper starts, complain ==
false.
Ah yes, I see.
Or you mean
Hi,
Or you mean something else?
I was thinking that the recursive part could be a simple loop to set
access, but your way is fine too.
Ok, great. Note, before committing I mean to also simplify it a bit, the
TREE_STATIC check of the recursive part has no reason to exist, doesn't exist
in
It's not supposed to be different. Checking constraints in
instantiate_template is actually too late. We want to check before
instantiation, at the point of use.
Right, what I was getting at is that instantiate_template actually only
instantiates the declaration of a function, not the
Submitted the patch (r202262) without the insert_stmt_after hunk. Also
fixed nits pointed out by Jakub.
- Easwaran
On Mon, Sep 2, 2013 at 2:31 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Aug 30, 2013 at 6:13 PM, Easwaran Raman era...@google.com wrote:
On Fri, Aug 30, 2013 at
On 04.09.2013 03:41, Gabriel Dos Reis wrote:
On Tue, Sep 3, 2013 at 9:33 PM, Mike Stump mikest...@comcast.net
wrote:
On Jul 12, 2013, at 11:18 PM, Adam Butcher a...@jessamine.co.uk
wrote:
* gcc/cp/semantics.c (build_lambda_expr),
(build_lambda_object), (begin_lambda_type),
On Wed, Sep 4, 2013 at 10:58 AM, Alexander Monakov wrote:
Hello,
Could you use the existing facilities instead, such as adjust_priority hook,
or making the compare-branch insn sequence a SCHED_GROUP?
Or a define_bypass?
Ciao!
Steven
On 09/04/2013 10:49 AM, Bernd Schmidt wrote:
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
functions w/o
bodies I did not really anticipate.
[...]
I would like to basically ask if it seems to make sense to go this route
Jan Hubicka hubi...@ucw.cz wrote:
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
this is third fallout of my change to remove
DECL_ARGUMENTS/DECL_RESULT for functions w/o
bodies I did not really anticipate.
[...]
I would like to basically ask if it seems to make sense to go this
route and
Hello,
PING.
--
Thanks, K
On Wed, Sep 4, 2013 at 9:53 PM, Steven Bosscher stevenb@gmail.com wrote:
On Wed, Sep 4, 2013 at 10:58 AM, Alexander Monakov wrote:
Hello,
Could you use the existing facilities instead, such as adjust_priority hook,
or making the compare-branch insn sequence a SCHED_GROUP?
Or a
On 04.09.2013 20:39, Gabriel Dos Reis wrote:
On Wed, Sep 4, 2013 at 12:55 PM, Adam Butcher a...@jessamine.co.uk
wrote:
Is anyone working on using some use, perhaps filtered, of -MD (or
-MDD) to
generate deps on the fly?
See Tom's patch series.
Ah, yes. Cool. I guess it's just waiting on
2013/9/4 Paul Pluzhnikov ppluzhni...@google.com:
Greetings,
This is a followup to:
http://gcc.gnu.org/ml/libstdc++/2013-08/msg00096.html
Without this patch, the user on vector::at out of bounds sees:
terminate called after throwing an instance of 'std::out_of_range'
what():
On Wed, Sep 4, 2013 at 1:53 PM, Cong Hou co...@google.com wrote:
I have made a new patch according to your comments. I found several
references saying that the precision 2p+2 is OK for the sqrt
conversion (one here:
http://www.cs.berkeley.edu/~fateman/generic/algorithms.pdf). The new
patch is
Greetings,
This is a followup to:
http://gcc.gnu.org/ml/libstdc++/2013-08/msg00096.html
Without this patch, the user on vector::at out of bounds sees:
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check
Aborted (core dumped)
With the patch:
On Wed, Sep 4, 2013 at 1:59 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Wed, 4 Sep 2013, Cong Hou wrote:
I have made a new patch according to your comments. I found several
references saying that the precision 2p+2 is OK for the sqrt
conversion (one here:
I have made a new patch according to your comments. I found several
references saying that the precision 2p+2 is OK for the sqrt
conversion (one here:
http://www.cs.berkeley.edu/~fateman/generic/algorithms.pdf). The new
patch is pasted as below.
Thank you for all the suggestions, Joseph!
Cong
On Wed, 4 Sep 2013, Cong Hou wrote:
I have made a new patch according to your comments. I found several
references saying that the precision 2p+2 is OK for the sqrt
conversion (one here:
http://www.cs.berkeley.edu/~fateman/generic/algorithms.pdf). The new
patch is pasted as below.
This
Richi, and the rest of the community,
Richard Sandiford has proposed a set of patches that change the wide-int
api in a significant way. We think that we really need some input from
the community as to if this is what we want using C++ in gcc is going to
look like. There are, as I see it, two
On 09/04/2013 01:33 PM, Andrew Sutton wrote:
Ah. The goal is to check after we've deduced/coerced template
arguments into a valid substitution. With functions, that's in
fn_type_unification (hopefully called from instantiate_template)
Actually fn_type_unification calls instantiate_template,
Updated patch according to your comment (tabs are not pasted here).
Cong
Index: gcc/convert.c
===
--- gcc/convert.c (revision 201891)
+++ gcc/convert.c (working copy)
@@ -135,16 +135,40 @@ convert_to_real (tree type, tree expr)
On Wed, 4 Sep 2013, Xinliang David Li wrote:
This patch submission still fails to pay attention to various of my
comments.
If you can provide inlined comments in the patch, that will be more
useful and productive.
I have explained things several times in this thread already. I see no
On Wed, Sep 4, 2013 at 2:10 PM, Daniel Krügler
daniel.krueg...@gmail.com wrote:
I expect that this kind of index violation is a rather often occurring
pattern and should be isolated. IMO the _M_range
_check now pessimisms the normal, non-violating case.
Did you mean pessimises code size, or
Hi,
On 09/04/2013 10:53 PM, Paul Pluzhnikov wrote:
I am not at all sure the names I choose here are good ones. Suggestions
welcome.
For sure concat_size would not be Ok, isn't uglified. Thanks for the
code, you understand isn't really something we can imagine committing.
I also shudder at the
Thanks for the suggestions! I take a look at adjust_priority, and find
it may not guarantee to schedule cmp and jmp together. The priority is
used to choose a candidate from ready list. If cmp is the only insn in
ready list and there is another insn-A in queued set (insn-A's
dependence has been
On Wed, Sep 4, 2013 at 4:26 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
For sure concat_size would not be Ok, isn't uglified.
I didn't uglify it because it's inside __gnu_cxx namespace.
Does it still need uglification?
snprintf_lite(__s, sizeof(__s),
Hi,
On 09/05/2013 01:36 AM, Paul Pluzhnikov wrote:
On Wed, Sep 4, 2013 at 4:26 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
For sure concat_size would not be Ok, isn't uglified.
I didn't uglify it because it's inside __gnu_cxx namespace.
Does it still need uglification?
Yes.
On Tue, 3 Sep 2013, Richard Biener wrote:
I think the warning can be completely implemented inside struct-layout.c
for example in finish_bitfield_representative (if you pass that the first
field
in the group, too). Of course that is at the expense of warning for
struct declarations rather
On Aug 30, 2013, at 4:22 PM, Diego Novillo dnovi...@google.com wrote:
Thanks for the suggestions. I've incorporated them into the patch.
It now adds tree-core.h with all the structures, enums, typedefs and
some fundamental declarations from tree.h. Everything else stays in
tree.h for now.
From: Bernd Edlinger bernd.edlin...@hotmail.de
Date: Wed, 4 Sep 2013 10:15:22 +0200
Even driver code rarely uses bit-fields for register access,
because that is inherently non-portabe. Reason: the bit
positions are completely different on little- and big-endian
targets. Most drivers I have
2013/9/5 Paul Pluzhnikov ppluzhni...@google.com:
On Wed, Sep 4, 2013 at 2:10 PM, Daniel Krügler
daniel.krueg...@gmail.com wrote:
I expect that this kind of index violation is a rather often occurring
pattern and should be isolated. IMO the _M_range
_check now pessimisms the normal,
89 matches
Mail list logo
