> I want the version of foo because the store with an address as
> destination is costly on my architecture, which is why I defined
> TARGET_ADDRESS_COST and added a cost when I get this scenario.
> However, in the compilation of this code, it seems that, when the
> function is inlined, the addres
Consider the one-liner C++ 'program':
template struct pack;
With the trunk, g++ -c [-std=gnu++98] gives:
warning: variadic templates only available with -std=c++0x or -std=gnu++0x
Should this not be an *error* instead? Variadic templates really should not be
supported in non-c++0x mode.
If n
Hi,
> Consider the one-liner C++ 'program':
>
> template struct pack;
>
> With the trunk, g++ -c [-std=gnu++98] gives:
>
> warning: variadic templates only available with -std=c++0x or -std=gnu++0x
>
> Should this not be an *error* instead? Variadic templates really should not
> be
> supported i
Paolo Bonzini wrote:
>> I also wondered about this. I think the original idea is that splits
>> can call into dojump.c.
>
> A more likely possibility is -fnon-call-exceptions.
Of course this is the main cause. But splitting one jump to multiple
jumps is supported and actually even documented.
2009/3/10 Paolo Carlini :
>>
>> warning: variadic templates only available with -std=c++0x or -std=gnu++0x
>>
> I'm afraid the behavior you are seeing is by design, and is not specific
In any case the wording of the warning is weird: it says variadic
templates are not available but then it is acce
Manuel López-Ibáñez wrote:
> In any case the wording of the warning is weird: it says variadic
> templates are not available but then it is accepted with just a
> warning.
>
I agree.
>> to variadic templates. It also happens, for example, for:
>>
>> enum class e { };
>>
>>
>
> What is the w
Jan van Dijk wrote:
Consider the one-liner C++ 'program':
template struct pack;
With the trunk, g++ -c [-std=gnu++98] gives:
warning: variadic templates only available with -std=c++0x or -std=gnu++0x
Should this not be an *error* instead? Variadic templates really should not be
supported in
Sylvain Pion wrote:
> The problem I fear is that variadic templates are already conveniently
> used as an implementation detail in libstdc++. And the warning there
> is probably hidden by the "system header" warning removal machinery.
It is, you are right.
Paolo.
2009/3/10 Sylvain Pion :
>
> The problem I fear is that variadic templates are already conveniently
> used as an implementation detail in libstdc++. And the warning there
> is probably hidden by the "system header" warning removal machinery.
>
But then probably, variadic templates are implemented
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
The problem I fear is that variadic templates are already conveniently
used as an implementation detail in libstdc++. And the warning there
is probably hidden by the "system header" warning removal machinery.
But then probably, variadic temp
I am pleased to announce that the GCC Steering Committee has
appointed Ira Rosen as an Auto-Vectorizer maintainer.
Please join me in congratulating Ira on her new role.
Ira, please update your listing in the MAINTAINERS file.
Happy hacking!
David
Ahhh ok, so basically I've hit the same wall as for the constant
folding and constant propagation!
Oh well, I will see how important it is for me to try to fix it in this case.
Thanks for the answer,
Jc
On Tue, Mar 10, 2009 at 4:18 AM, Paolo Bonzini wrote:
>
>> I want the version of foo because
Hi,
Since r144598, pr39339.c has been failing on picochip. On investigation,
it looks to me that the testcase is illegal.
Relevant source code:
struct C
{
unsigned int c;
struct D
{
unsigned int columns : 4;
unsigned int fore : 9;
unsigned int back : 9;
unsigned int fragme
On Tue, Mar 10, 2009 at 2:44 PM, Hariharan Sandanagobalane
wrote:
> Hi,
> Since r144598, pr39339.c has been failing on picochip. On investigation, it
> looks to me that the testcase is illegal.
>
> Relevant source code:
> struct C
> {
> unsigned int c;
> struct D
> {
> unsigned int columns :
On Tue, Mar 10, 2009 at 6:58 AM, Sylvain Pion
wrote:
> Manuel López-Ibáñez wrote:
>>
>> 2009/3/10 Sylvain Pion :
>>>
>>> The problem I fear is that variadic templates are already conveniently
>>> used as an implementation detail in libstdc++. And the warning there
>>> is probably hidden by the "s
2009/3/10 Sylvain Pion :
>>
>> But then probably, variadic templates are implemented as a GCC
>> extension to C++98 and they work fine with -std=c++98 despite what the
>> warning says. Or don't they?
>
> Yes, but like any extension, it's nice to be able to disable them
> as errors, so as to be able
On Tue, Mar 10, 2009 at 01:44:11PM +, Hariharan Sandanagobalane wrote:
> Since r144598, pr39339.c has been failing on picochip. On investigation,
> it looks to me that the testcase is illegal.
>
> Relevant source code:
> struct C
> {
> unsigned int c;
> struct D
> {
> unsigned int c
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
But then probably, variadic templates are implemented as a GCC
extension to C++98 and they work fine with -std=c++98 despite what the
warning says. Or don't they?
Yes, but like any extension, it's nice to be able to disable them
as errors, so
Gabriel Dos Reis wrote:
On Tue, Mar 10, 2009 at 6:58 AM, Sylvain Pion
wrote:
Manuel López-Ibáñez wrote:
2009/3/10 Sylvain Pion :
The problem I fear is that variadic templates are already conveniently
used as an implementation detail in libstdc++. And the warning there
is probably hidden by t
Yes, if i change the structure to bring the 3 1-bit members forward, to
avoid padding, the testcase does pass.
Thanks to both of you for your help.
Cheers
Hari
Jakub Jelinek wrote:
On Tue, Mar 10, 2009 at 01:44:11PM +, Hariharan Sandanagobalane wrote:
Since r144598, pr39339.c has been fai
Hello,
Described here is the future plan for automatic parallelization in GCC.
The current autopar pass is based on GOMP infrastructure; it distributes
iterations of loops
to several threads (the number is instructed by the user) if it was
determined that
they are independent. The only depen
Hello,
I would like to have a warning when there is an Implicit conversion in
source code:
uint32_t foo = 2000;
uint16_t bar = foo; //--> Warning Implicit conversion from uint32_t
to uint16_t
uint16_t bar2= (uint16_t) foo; // --> no warning.
I now that -Wtraditional-conversion in GCC 4.3
Hi Razya
great to hear these Graphite plans. Some short comments.
On Tue, 2009-03-10 at 16:13 +0200, Razya Ladelsky wrote:
> [...]
>
> The first step, as we see it, will teach Graphite that parallel code needs
> to be produced.
> This means that Graphite will recognize simple parallel loops (us
Hello Richard
On 09.03.09, you wrote:
>> I believe one should convince the middle end to emit libcall
>> for __builtin_xxx when the target has no builtint support.
>
> It of course does.
On what codeplace is the redefine do in GCC source ?
I see in my c++config.h file
this stand here
/* Defi
On Tue, Mar 10, 2009 at 7:57 AM, Manuel López-Ibáñez
wrote:
> 2009/3/10 Sylvain Pion :
>>>
>>> But then probably, variadic templates are implemented as a GCC
>>> extension to C++98 and they work fine with -std=c++98 despite what the
>>> warning says. Or don't they?
>>
>> Yes, but like any extensio
On Tue, Mar 10, 2009 at 7:58 AM, Bernd Roesch wrote:
> Hello Richard
>
> On 09.03.09, you wrote:
>
>>> I believe one should convince the middle end to emit libcall
>>> for __builtin_xxx when the target has no builtint support.
>>
>> It of course does.
>
> On what codeplace is the redefine do in GC
Joseph S. Myers wrote:
On Mon, 9 Mar 2009, Sylvain Pion wrote:
Later, 1) started to be taken care of, and it was unfortunately
added under the control of the same -frounding-math option.
Which now, makes it harder to come back, since we want different
defaults for these two aspects.
I have alr
On Tue, Mar 10, 2009 at 4:45 PM, Sylvain Pion
wrote:
> - Show quoted text -
> Joseph S. Myers wrote:
>>
>> On Mon, 9 Mar 2009, Sylvain Pion wrote:
>>
>>> Later, 1) started to be taken care of, and it was unfortunately
>>> added under the control of the same -frounding-math option.
>>> Which now, m
On Tue, Mar 10, 2009 at 9:45 AM, Sylvain Pion
wrote:
> - Show quoted text -
> Joseph S. Myers wrote:
>>
>> On Mon, 9 Mar 2009, Sylvain Pion wrote:
>>
>>> Later, 1) started to be taken care of, and it was unfortunately
>>> added under the control of the same -frounding-math option.
>>> Which now, m
Gabriel Dos Reis wrote:
On Tue, Mar 10, 2009 at 9:45 AM, Sylvain Pion
wrote:
- Show quoted text -
Joseph S. Myers wrote:
On Mon, 9 Mar 2009, Sylvain Pion wrote:
Later, 1) started to be taken care of, and it was unfortunately
added under the control of the same -frounding-math option.
Which n
Bernd Roesch writes:
> Hello Richard
>
> On 09.03.09, you wrote:
>
>>> I believe one should convince the middle end to emit libcall
>>> for __builtin_xxx when the target has no builtint support.
>>
>> It of course does.
>
> On what codeplace is the redefine do in GCC source ?
This is in optabs.
Richard Guenther wrote:
The middle-end knows about an explicit association barrier (only
used from the Fortran FE sofar), a PAREN_EXPR. Would exposing
that to C/C++ be of any help? For example it would, even with
-ffast-math, avoid constant folding for (x + FLT_EPS) - FLT_EPS
(which FLT_EPS suc
Hi,
I need to use a scratch register in the "jump" pattern and I can't
figure out how to do it properly.
My problem is that the microcontroller I'm porting gcc onto does not
permit "far" jumps, those must be done using an indirect adressing.
So I wrote this:
-8<-
Sylvain Pion wrote:
> Joseph S. Myers wrote:
>> On Mon, 9 Mar 2009, Sylvain Pion wrote:
>>
>>> Later, 1) started to be taken care of, and it was unfortunately
>>> added under the control of the same -frounding-math option.
>>> Which now, makes it harder to come back, since we want different
>>> def
Stelian Pop wrote:
> I need to use a scratch register in the "jump" pattern and I can't
> figure out how to do it properly.
>
> My problem is that the microcontroller I'm porting gcc onto does not
> permit "far" jumps, those must be done using an indirect adressing.
> (define_insn "*jump"
> Any
-pedantic-errors will make it an error.
I don't feel strongly about whether these should be pedwarn or something
stronger, but I note that libstdc++ wants to use variadic templates in
the default mode, so we can't just disable them entirely.
Jason
On Tue, Mar 10, 2009 at 10:31 AM, Sylvain Pion
wrote:
[...]
> If you are looking for the Right [tm] solution, please take a look at N2811.
I'm familiar with that paper -- I should have made that disclosure in
my previous
message.
-- Gaby
On Tue, Mar 10, 2009 at 10:41 AM, Sylvain Pion
wrote:
> Richard Guenther wrote:
>>
>> The middle-end knows about an explicit association barrier (only
>> used from the Fortran FE sofar), a PAREN_EXPR. Would exposing
>> that to C/C++ be of any help? For example it would, even with
>> -ffast-math,
On Tue, Mar 10, 2009 at 05:20:28PM +, Dave Korn wrote:
> Stelian Pop wrote:
>
> > I need to use a scratch register in the "jump" pattern and I can't
> > figure out how to do it properly.
> >
> > My problem is that the microcontroller I'm porting gcc onto does not
> > permit "far" jumps, thos
Andrew Haley wrote:
We know that's what you want. What we don't know (well, what I don't
know) is *why*. If you want to do something as specialized as interval
arithmetic, what's the big deal with having to pass special flags to
the compiler?
I contest the "as specialized as" comment.
I know
Gabriel Dos Reis wrote:
On Tue, Mar 10, 2009 at 10:41 AM, Sylvain Pion
wrote:
Richard Guenther wrote:
The middle-end knows about an explicit association barrier (only
used from the Fortran FE sofar), a PAREN_EXPR. Would exposing
that to C/C++ be of any help? For example it would, even with
-
On Tue, Mar 10, 2009 at 12:27 PM, Sylvain Pion
wrote:
> Other ways might be possible. E.g. avoiding the wrapping if
> the associativity concept/axiom is somehow local to the function
> and does not leak elsewhere if you provide an Associativity
> concept_map for double (or are "scoped concept ma
This is the beta release of binutils 2.19.51.0.3 for Linux, which is
based on binutils 2009 0310 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
I accidentally found that the local variable
num_never_executed
in function compute_branch_probabilities, is initialized to zero
and never gets modified after that.
I suppose the statement in line 603:
num_branches++, num_never_executed;
was intended to be:
num_branches++, num_never_executed++;
R
On Tue, Mar 10, 2009 at 12:58 PM, Edmar Wienskoski wrote:
> I accidentally found that the local variable
> num_never_executed
> in function compute_branch_probabilities, is initialized to zero
> and never gets modified after that.
>
> I suppose the statement in line 603:
> num_branches++, num_neve
Hello,
It seems that the implementation of DR 387 in trunk's is incomplete:
both versions of operator+,-(const _Tp&) still assume real() is an lvalue (see
below). These are the only offenders , AFAICS.
Is somebody on this, or should I file a PR?
Regards, Jan.
The program:
#in
2009/3/10 Sylvain Pion:
> Manuel López-Ibáñez wrote:
>> 2009/3/10 Sylvain Pion:
>>>
>>> Yes, but like any extension, it's nice to be able to disable them
>>> as errors, so as to be able to use GCC for checking code portability.
>>
>> So use -pedantic-errors as it says in the manual. You should real
Stelian Pop schrieb:
Hi,
I need to use a scratch register in the "jump" pattern and I can't
figure out how to do it properly.
My problem is that the microcontroller I'm porting gcc onto does not
permit "far" jumps, those must be done using an indirect adressing.
So I wrote this:
-
On Tue, Mar 10, 2009 at 10:18:10PM +0100, Georg-Johann Lay wrote:
> Note that no one is generating an insn that looks like "*jump". Maybe
> insn combine and peep2 would try to build such a pattern, but that is
> not what helpd you out here. Write the expander as parallel of a (set
> (pc) ...
if working with a softfloat toolchain, we end up with copies of softfloat
symbols everywhere (from fp-bit.c and dp-bit.c). should these files really
end up with symbols with hidden visibility ? seems like a waste to force
copying of these symbols into binaries when libgcc_s.so itself already h
Hi,
> Is somebody on this, or should I file a PR?
>
I'll fix it, thanks for your report.
Paolo.
PS: in the future remember to also CC libstdc++, to be sure.
On Tue, 10 Mar 2009, Mike Frysinger wrote:
> perhaps we need to extend the libgcc.map function to allow people to insert
> $(FPBIT_FUNCS) and such into the map so libgcc_s.so exports these suckers ?
Exporting functions that are internal to fp-bit rather than part of the
documented libgcc interf
On Tuesday 10 March 2009 21:44:23 Joseph S. Myers wrote:
> On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > perhaps we need to extend the libgcc.map function to allow people to
> > insert $(FPBIT_FUNCS) and such into the map so libgcc_s.so exports these
> > suckers ?
>
> Exporting functions that are
On Tue, 10 Mar 2009, Mike Frysinger wrote:
> On Tuesday 10 March 2009 21:44:23 Joseph S. Myers wrote:
> > On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > > perhaps we need to extend the libgcc.map function to allow people to
> > > insert $(FPBIT_FUNCS) and such into the map so libgcc_s.so exports t
On Tue, 10 Mar 2009, DJ Delorie wrote:
> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode. The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
Thank you fo
> Can you provide example code? I'm confused enough to believe
> that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
> (modulo current bugs).
Imagine a device with four 8-bit registers followed by a 32-bit
register with an 8-bit field:
bytestatus (read-only, clears after readin
56 matches
Mail list logo
