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 th
Hi Maxim,
2013/9/4 Maxim Kuvyrkov :
> 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 patch addre
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 addres
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 t
On 4/09/2013, at 7:43 PM, Alexander Ivchenko wrote:
> Hi Maxim,
>
> 2013/9/4 Maxim Kuvyrkov :
>> 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
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 alo
On Tue, Sep 3, 2013 at 9:39 PM, Teresa Johnson wrote:
> On Fri, Aug 30, 2013 at 11:28 PM, Sharad Singhai 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 was being emitted to stderr. I
On Wed, Sep 4, 2013 at 5:16 AM, wrote:
> From: Trevor Saunders
>
> 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 include the use of functors and possibly t
Hello,
Richard Biener 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 is
> recognized by opt
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 fo
... 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 x86_6
On Wed, Sep 4, 2013 at 10:46 AM, Dodji Seketeli wrote:
> Hello,
>
> Richard Biener 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 funct
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 si
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?
>
On Tue, Sep 3, 2013 at 3:04 PM, Thomas Koenig 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 know anybody who
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
2013-09-04 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::simple_type_specifier): Now
a virtual member function.
(pp_simple_type_specifier): Remove.
(pp_c_type_specifier): Likewise.
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 bet
> 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
> > * c-typeck.c (output_pending_init_elements): Handle overflow of
> > constructor_unfilled_index.
>
> This patch needs to add
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 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 DECL_IS_BUILTIN a
> 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
On Wed, Sep 4, 2013 at 3:55 PM, DJ Delorie 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 (curren
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, wrote:
From: Trevor Saunders
bootstrapped on x86_64-unknown-linux-gnu with same test results as unpatched
r202185 ok?
That looks like a not too u
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 alr
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 shou
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 appe
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 instantiatio
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 plai
>> 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
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
firs
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 :
> 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++ dynamically. However, if
On Sep 4, 2013, at 7:09 AM, Jan Hubicka 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 slowly getting u
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 opti
On Wed, Sep 04, 2013 at 10:32:17AM +0200, Richard Biener wrote:
> On Wed, Sep 4, 2013 at 5:16 AM, wrote:
> > From: Trevor Saunders
> >
> > 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 dom
On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote:
> On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger
> 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 may invoke undefi
On Sep 4, 2013, at 7:30 AM, Romain Geissler wrote:
>> 2013-08-20 Romain Geissler
>>
>>* 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 then respected by the library. With that chan
On Wed, Sep 4, 2013 at 12:01 AM, Jakub Jelinek 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 some
> platfo
(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
a
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
* cgraphu
On Sat, 2013-08-31 at 19:27 +0200, Richard Biener wrote:
> David Malcolm wrote:
> >On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote:
> >> On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher
> > wrote:
> >> > On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm
> > wrote:
> >> >> * gimple.c (
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
> >
> 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 thos
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 th
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 K&R 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
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 someth
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
>> 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 th
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
wrote:
> On Fri, Aug 30, 2013 at 6:13 PM, Easwaran Raman wrote:
>> On Fri, Aug 30, 2013 at 1:25 AM, Richard Biener
>> wrote:
>>> On
On 04.09.2013 03:41, Gabriel Dos Reis wrote:
On Tue, Sep 3, 2013 at 9:33 PM, Mike Stump
wrote:
On Jul 12, 2013, at 11:18 PM, Adam Butcher
wrote:
* gcc/cp/semantics.c (build_lambda_expr),
(build_lambda_object), (begin_lambda_type),
(lambda_return_type),
(lambda_function), (l
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 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 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 define_bypas
On 04.09.2013 20:39, Gabriel Dos Reis wrote:
On Wed, Sep 4, 2013 at 12:55 PM, Adam Butcher
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 approval for each pa
2013/9/4 Paul Pluzhnikov :
> 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
>
On Wed, Sep 4, 2013 at 1:53 PM, 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 b
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:
term
On Wed, Sep 4, 2013 at 1:59 PM, Joseph S. Myers 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:
>> http://www.cs.berkeley.edu/~fateman/gene
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, but
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)
C
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
On Wed, Sep 4, 2013 at 2:10 PM, Daniel Krügler
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 something else?
> Wh
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 res
On Wed, Sep 4, 2013 at 4:26 PM, Paolo Carlini 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),
>> _N("vector::_M_range_check: __n (wh
Hi,
On 09/05/2013 01:36 AM, Paul Pluzhnikov wrote:
On Wed, Sep 4, 2013 at 4:26 PM, Paolo Carlini 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.
snprintf_lite(__s, sizeof(__
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 rath
On Aug 30, 2013, at 4:22 PM, Diego Novillo 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.
So, the comments
> From: Bernd Edlinger
> 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 seen use some macros
2013/9/5 Paul Pluzhnikov :
> On Wed, Sep 4, 2013 at 2:10 PM, Daniel Krügler
> 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
88 matches
Mail list logo
