On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay a...@gjlay.de writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations, but moving costly_func across func does *not*
affect the interrupt respond times in such a disastrous way.
Thus you must
On 02/03/14 19:24, Denis Chertykov wrote:
I would remove two maintainers for AVR port:
1. Anatoly Sokolov ae...@post.ru
2. Eric Weddington eric.wedding...@atmel.com
I have discussed the removal with Anatoly Sokolov and he is agree with it.
I can't discuss the removal with Eric Weddington
On 03/03/14 11:49, Richard Biener wrote:
On Mon, Mar 3, 2014 at 11:41 AM, David Brown da...@westcontrol.com wrote:
On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay a...@gjlay.de writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations
On 03/03/14 14:54, Richard Biener wrote:
On Mon, Mar 3, 2014 at 1:53 PM, David Brown da...@westcontrol.com wrote:
On 03/03/14 11:49, Richard Biener wrote:
On Mon, Mar 3, 2014 at 11:41 AM, David Brown da...@westcontrol.com wrote:
On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay
On 03/03/14 21:30, Eric Weddington wrote:
I just replied to Denis personally.
Agreed. I haven't done anything with the AVR port in a while, and I
probably won't be doing so for a while. Maybe some time in the future.
So it makes sense to remove me from maintainership.
Eric Weddington
On
On 27/02/14 07:50, Mingjie Xing wrote:
Hello,
I'm wondering if it's a good idea to turn on some warnings by default
(or even promote them to error), such as -Wreturn-type on C. This
would help programmers to avoid some mistakes.
Regards,
Mingjie
Personally, I think gcc should issue a
On 27/02/14 16:36, Yury Gribov wrote:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a
On 18/02/14 00:12, DJ Delorie wrote:
I presume these will be part of the headers for the library
distributed for msp430 gcc by TI/Redhat?
I can't speak for TI's or Red Hat's plans. GNU's typical non-custom
embedded runtime is newlib/libgloss, which usually doesn't have that
much in the way
On 14/02/14 20:17, DJ Delorie wrote:
The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those). You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins as inline
On 06/12/13 09:30, Konstantin Vladimirov wrote:
Hi,
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i 2;
v[x + 4] = t[x + 4];
}
return 0;
}
Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with options:
gcc -O2 -m32 -S
On 26/11/13 16:12, Paulo Matos wrote:
Hi,
I am slightly confused about the BIGGEST_ALIGNMENT docs which state:
Biggest alignment that any data type can require on this machine, in
bits. Note that this is not the biggest alignment that is supported,
just the biggest alignment that, when
On 04/11/13 06:18, pins...@gmail.com wrote:
On Nov 3, 2013, at 9:10 PM, Ian Lance Taylor i...@google.com
wrote:
On Sun, Nov 3, 2013 at 8:49 PM, pins...@gmail.com wrote:
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov
ma...@kugelworks.com wrote:
Hi,
I am considering a project to
On 30/10/13 16:56, Andrew Haley wrote:
On 10/30/2013 03:23 PM, David Brown wrote:
I believe that's only a minor reason for making signed overflows
undefined behaviour. If it were a matter of implementation, I think it
would have been made implementation defined rather than undefined,
so
On 31/10/13 17:51, Andrew Haley wrote:
On 10/31/2013 08:02 AM, David Brown wrote:
On 30/10/13 16:56, Andrew Haley wrote:
On 10/30/2013 03:23 PM, David Brown wrote:
I believe that's only a minor reason for making signed overflows
undefined behaviour. If it were a matter of implementation, I
On 30/10/13 10:00, Kai Tietz wrote:
2013/10/30 Andrew Haley a...@redhat.com:
On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
The reasons of adding builtins is performance. Without that one can
write a simple template to generically check overflows like
template class C class overflow {
On 30/10/13 15:59, Ondřej Bílka wrote:
On Wed, Oct 30, 2013 at 10:49:09AM -0400, Trevor Saunders wrote:
On Wed, Oct 30, 2013 at 10:00:07AM +0100, Kai Tietz wrote:
2013/10/30 Andrew Haley a...@redhat.com:
On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
The reasons of adding builtins is
On 10/09/13 04:44, Jeff Law wrote:
On 09/09/2013 02:45 PM, Andrew MacLeod wrote:
A number of header files have inline functions declared in them. Some of
these functions are actually quite large, and I doubt that inlining them
is the right thing. For instance, tree-flow-inline.h has some
On 10/09/13 10:11, Jakub Jelinek wrote:
On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
This last point is crucial. I haven't looked at the code in question,
but one point to check is how the functions are called. If they are
often called with constant values, then they may
On 04/09/13 16:06, Ian Lance Taylor wrote:
On Wed, Sep 4, 2013 at 6:40 AM, Kirill Tkhai tk...@yandex.ru wrote:
the following example compiles without warnings:
$ cat a.c
int func (int p)
{
int x;
if (p != 0)
x = 1;
return x;
}
$ gcc -c a.c
On 23/08/13 17:59, Jonathan Wakely wrote:
On 23 August 2013 16:25, Frank Ch. Eigler wrote:
Hi -
On Fri, Aug 23, 2013 at 04:06:22PM +0100, Jonathan Wakely wrote:
[...]
(Assuming we want to go down the ACL route.)
Done! :-)
Thanks.
I've reverted or deleted all the spam I could find (and
On 18/07/13 17:22, Ard Biesheuvel wrote:
On 18 July 2013 16:54, Tejas Belagod tbela...@arm.com wrote:
I'd like to follow up this thread to move towards removing arm_neon.h's
dependence on stdint.h. My comments inline below.
As far as I can tell, the only dependency arm_neon.h has on the
On 11/05/13 17:20, jacob navia wrote:
Le 11/05/13 16:01, Ondřej Bílka a écrit :
As 1) only way is measure that. Compile following an we will see who is
rigth.
cat
#include math.h
int main(){ int i;
double x=0;
double ret=0;
double f;
for(i=0;i1000;i++){
ret+=sin(x);
On 03/05/13 16:03, Richard Sandiford wrote:
David Brown da...@westcontrol.com writes:
Personally, I've used naked when I want to write pure assembly code
and don't want extra stack frames or return codes. I don't want to
write stand-alone assembly files (I've written mountains of them
On 03/05/13 06:40, Geert Bosch wrote:
On May 3, 2013, at 00:15, reed kotler rkot...@mips.com wrote:
There was some confusion on the llvm list because some tests were run on
targets that did not support the naked attribute.
I think we are thinking now that the return statement should not
On 03/05/13 06:03, reed kotler wrote:
On 05/02/2013 08:41 PM, Chung-Ju Wu wrote:
2013/5/3 reed kotler rkot...@mips.com:
Should a return statement be emitted in a function that has the naked
attribute.
There seems to be some confusion here and apparently disagreement
between
various
gcc
On 10/04/13 04:51, Geert Bosch wrote:
On Apr 9, 2013, at 22:19, Segher Boessenkool seg...@kernel.crashing.org
wrote:
Some numbers, 16-core 64-thread POWER7, c,c++,fortran bootstrap:
-j6: real57m32.245s
-j60: real38m18.583s
Yes, these confirm mine. It doesn't make sense to
On 21/03/13 18:03, David Edelsohn wrote:
On Thu, Mar 21, 2013 at 4:58 AM, Will william.swashbuck...@gmail.com wrote:
James Lemke jwlemke at codesourcery.com writes:
I have completed the binutils submission for VLE.
I am working on the gcc submission. The test results are looking good
now.
On 22/03/13 16:18, David Edelsohn wrote:
On Fri, Mar 22, 2013 at 6:28 AM, David Brown da...@westcontrol.com wrote:
I use Freescale PPC devices with VLE, and I use Freescale's CodeWarrior
to do so. At the start of the project, I looked at CodeSourcery's
PPC-EABI tools (I have used
On 18/02/13 18:08, Robert Dewar wrote:
Forgive me, but I don't see where anything is guaranteed to be zero'd
before use. I'm likely wrong somewhere since you disagree.
http://en.wikipedia.org/wiki/.bss
This is about what happens to work, and specifically notes that it is
not part of the C
On 03/02/13 02:10, Jeffrey Walton wrote:
Thanks Andrew.
So, it looks like I don't understand sequence points. Please forgive
my ignorance.
What does C/C++ and GCC offer to ensure writes are complete before
reads are performed on a value in a multi-threaded program?
Jeff
You are probably
On 03/02/13 21:20, Jeffrey Walton wrote:
On Sun, Feb 3, 2013 at 2:47 PM, David Brown david.br...@hesbynett.no wrote:
On 03/02/13 02:10, Jeffrey Walton wrote:
So, it looks like I don't understand sequence points. Please forgive
my ignorance.
What does C/C++ and GCC offer to ensure writes
On 19/12/2012 23:32, Joel Sherrill wrote:
I also couldn't find any strong indication that one could purchase
VHDL or an IP module to build an i386dx class System on Chip.
I don't think this would be one to worry about. The x86 architecture
would be massively inefficient to implement in any
On 13/12/2012 12:24, Steven Bosscher wrote:
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote:
I don't speak for FreeBSD, but dropping them from Tier 1 support because
they don't use a GPLv3 *BASE* compiler is a bit vindictive.
FreeBSD has dropped GCC for future releases so there's no
On 13/12/2012 11:11, Richard Biener wrote:
On Wed, Dec 12, 2012 at 10:07 PM, David Brown david.br...@hesbynett.no wrote:
On 12/12/12 20:54, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need
On 13/12/2012 13:09, Steven Bosscher wrote:
On Thu, Dec 13, 2012 at 12:38 PM, David Brown wrote:
Dropping bsd as a target architecture just because the BSD distributions
don't use it is a bit like dropping support for targeting windows just
because Microsoft didn't use gcc to compile Windows 8
On 12/12/12 20:54, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up with precisely this dichotomy
On 07/11/2012 02:15, David Edelsohn wrote:
On Tue, Nov 6, 2012 at 11:08 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
Ok, does this mean that there is no primary and secondary target in GCC that
covers PowerPC Book E with ELF and EABI?
If I change something in this area is
On 05/11/2012 11:33, Mischa Baars wrote:
On 11/05/2012 05:55 AM, Ian Lance Taylor wrote:
On Sun, Nov 4, 2012 at 1:34 AM, Mischa Baars mjbaars1...@gmail.com
wrote:
On 11/04/2012 02:45 AM, Ian Lance Taylor wrote:
There is no original. The 32-bit and 64-bit ABIs are different.
The 64-bit ABI
On 04/11/12 10:34, Mischa Baars wrote:
On 11/04/2012 02:45 AM, Ian Lance Taylor wrote:
On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars mjbaars1...@gmail.com
wrote:
On 11/02/2012 07:11 PM, Ian Lance Taylor wrote:
On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars mjbaars1...@gmail.com
wrote:
I have
On 08/08/12 16:01, Elmar Krieger wrote:
One other thing I just thought of: GCC has a history of very smart
extensions to C that allow to write faster and more elegant code. If I
look at my code, there are mostly two sources of 'dirty hacks' left. One
that could be fixed easily is the 'void**
On 08/08/12 17:08, William Swashbuckler wrote:
Hi,
I have recently read in several places that GCC now supports the
PowerPC VLE instruction set architecture as a target. However, I have
so far been unable to find any actual documentation on this? AFAICS
the online doc doesn't show any new
On 26/07/2012 11:12, Richard Guenther wrote:
On Wed, Jul 25, 2012 at 8:25 PM, David Brown david.br...@hesbynett.no wrote:
On 25/07/12 17:30, Richard Guenther wrote:
On Wed, Jul 25, 2012 at 4:07 PM, Selvaraj, Senthil_Kumar
senthil_kumar.selva...@atmel.com wrote:
Declaring a function
On 26/07/2012 14:04, Richard Guenther wrote:
On Thu, Jul 26, 2012 at 1:21 PM, David Brown da...@westcontrol.com wrote:
On 26/07/2012 11:12, Richard Guenther wrote:
On Wed, Jul 25, 2012 at 8:25 PM, David Brown david.br...@hesbynett.no
wrote:
On 25/07/12 17:30, Richard Guenther wrote
On 25/07/12 17:30, Richard Guenther wrote:
On Wed, Jul 25, 2012 at 4:07 PM, Selvaraj, Senthil_Kumar
senthil_kumar.selva...@atmel.com wrote:
Declaring a function with __attribute__((optimize(O0)) turns off
inlining for the translation unit (atleast) containing the function
(see output at the
On 24/06/12 23:54, Robert Dewar wrote:
On 6/24/2012 12:09 PM, Ángel González wrote:
Peter A. Felvegi writes:
My question is: wouldn't it be possible to print a warning when a jmp
to itself or trivial infinite recursion is generated? The code
compiled fine w/ -Wall -Wextra -Werror w/ 4.6 and
On 14/06/2012 04:05, Chris Jones wrote:
David Brown wrote:
On 11/06/2012 09:45, Chris Jones wrote:
Is it possible to modify the source code of gcc to enable to compilation
of a completely new programming language, as yet unrecognized? How much
of a big job would I be looking at for such a task
On 14/06/12 19:31, Joe Buck wrote:
It only saves one character in any case: your self is just *this.
No, this points to the object in C++. The OP's self is referring to
the function being compiled. So here self would be the same as foo.
I don't think there is any way to get this without
On 11/06/2012 09:45, Chris Jones wrote:
Is it possible to modify the source code of gcc to enable to compilation
of a completely new programming language, as yet unrecognized? How much
of a big job would I be looking at for such a task?
I would think that would depend entirely on the language
On 01/05/2012 20:11, Joern Rennecke wrote:
Quoting Richard Sandiford rdsandif...@googlemail.com:
nick clifton ni...@redhat.com writes:
OK, but what if it turns out that the new algorithm improves the
performance of some benchmarks/applications, but degrades others, within
the same
On 29/03/2012 00:52, mathog wrote:
On 28-Mar-2012 15:20, Michael Witten wrote:
However, it seems to me that toggling the value with the idiom:
--b;
is aesthetically preferable to the more elaborate:
b = !b;
Aesthetically, not logically. Neither of these makes the least bit of
sense:
one
On 25/03/2012 11:55, Oleg Endo wrote:
Please reply in CC to the GCC mailing list, so others can follow the
discussion.
On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote:
On 25 March 2012 03:59, Oleg Endooleg.e...@t-online.de wrote:
I might be misunderstanding the idea...
Let's assume
On 05/02/12 17:29, Alexandre Almeida wrote:
What do you think about making enum types have only the size needed
for the number of constants held? If an enum type has 256 constants
or less, for example, it needs only one byte. If it has between 257
and 65536 constants, in the other hand, it
On 30/01/2012 23:59, Zoltán Kócsi wrote:
David Browndavid.br...@hesbynett.no wrote:
Until gcc gets a feature allowing it to whack the programmer on the back
of the head with Knuth's The Art of Computer Programming for writing
such stupid code that relies on the behaviour of volatile a = b =
On 30/01/12 23:22, paul_kon...@dell.com wrote:
I would prefer this to generate a warning. The C language standard
change you refer to is a classic example of a misguided change, and
any code whose behavior depends on this deserves a warning message,
NOT an option to work one way or the other.
On 27/01/2012 10:02, Richard Guenther wrote:
On Thu, Jan 26, 2012 at 4:58 PM, David Brownda...@westcontrol.com wrote:
On 26/01/2012 12:53, Konstantin Vladimirov wrote:
Hi,
If I know what I am doing, and my code itself guarantees, that there
will be no overflows and UB here, can I switch off
On 27/01/2012 10:56, Richard Guenther wrote:
On Fri, Jan 27, 2012 at 10:40 AM, David Brownda...@westcontrol.com wrote:
On 27/01/2012 10:02, Richard Guenther wrote:
On Thu, Jan 26, 2012 at 4:58 PM, David Brownda...@westcontrol.com
wrote:
On 26/01/2012 12:53, Konstantin Vladimirov wrote:
On 26/01/2012 12:53, Konstantin Vladimirov wrote:
Hi,
If I know what I am doing, and my code itself guarantees, that there
will be no overflows and UB here, can I switch off this signed char to
unsigned char expansion in favor of signed char to signed int
expansion?
The big question here is
On 31/12/11 10:44, R A wrote:
alright, here's another example why eval is a good idea:
#define A 17 #define B 153 #define N1
((A + B)/2) /* intended was (17 + 153)/2 */
#undef A #define A 230 #define N2 ((A + B)/2) /*
intended was (230 + 153)/2 */
On 29/12/2011 00:08, R A wrote:
And if you want portable pre-processing or code generation, use
something that generates the code rather than inventing tools and
features that don't exist, nor will ever exist. It is also quite
common to use scripts in languages like perl or python to generate
On 29/12/11 22:05, R A wrote:
The gcc developers, and everyone else involved in the development
of C as a language, are perhaps not superhuman - but I suspect
their combined knowledge, experience and programming ability
outweighs yours.
given. but do you have a consensus of the community
On 28/12/2011 07:48, R A wrote:
i'm an amateur programmer that just started learning C. i like most
of the features, specially the c preprocessor that it comes packed
with. it's an extremely portable way of implementing metaprogramming
in C.
though i've always thought it lacked a single
On 28/12/11 21:57, R A wrote:
yes, i do realize that c preprocessor is but a text substitution tool
from days past when programmers where only starting to develop the
rudimentaries of high-level programming. but the reason i'm sticking
with the c preprocessor if the fact that code that i write
On 06/12/2011 20:33, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/06/11 12:21, Ian Lance Taylor wrote:
While using the optimizers to improve the quality of uninitialized
warnings does have some benefits, those benefits are outweighed by
the drawbacks. We need to
On 07/12/11 19:05, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/11 01:19, David Brown wrote:
Would it be possible then to have switches for different levels,
such as is done with the strict aliasing warnings?
Well, there's two obvious levels... Not sure if there's
On 05/12/2011 22:43, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/11 06:03, Patrice B wrote:
Sorry for the noise, the problem is already tracked here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Le 2 décembre 2011 10:42, Patrice Bouchandpbfwdl...@gmail.com a
On 06/12/2011 14:26, Richard Guenther wrote:
On Tue, Dec 6, 2011 at 2:13 PM, Dave Korndave.korn.cyg...@gmail.com wrote:
On 05/12/2011 21:43, Jeff Law wrote:
When the uninitialized initialized to 10 paths meet, the compiler
(correctly) pretends the value for the uninitialized path is 10 as
On 06/12/2011 15:29, Robert Dewar wrote:
On 12/6/2011 9:16 AM, David Brown wrote:
I would say it's better to have false positives in cases like this, than
false negatives, because there are easy ways to remove the false
positives.
My view is that for compiler warnings, you want to balance
On 06/12/2011 16:27, Robert Dewar wrote:
On 12/6/2011 10:18 AM, David Brown wrote:
Unfortunately, there are no such tools available that compare with gcc
and its warnings.
It's surprising this is true of C, it's certainly not true of Ada,
where CodePeer can do a much better job than GNAT+gcc
On 06/12/2011 16:33, Robert Dewar wrote:
On 12/6/2011 10:32 AM, Richard Kenner wrote:
Well I am not sure what you mean by a linter or lint program,
See http://en.wikipedia.org/wiki/Lint_(software)
VERY early (and simple) static analysis program for C.
I know what lint is, but I never heard
On 02/12/2011 13:59, Andrew Haley wrote:
On Fri, Dec 2, 2011 at 5:46 AM,paul_kon...@dell.com wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens that GCC doesn't
do this
On 29/11/2011 15:25, Ian Lance Taylor wrote:
Nadezhda Ivanоvna Vyukovan...@niisi.msk.ru writes:
I am involved in support of customers who use GCC.
Recently a customer has complaint that gcc-4.1.2
generates an infinite loop for the following program:
#includestdio.h
extern void f (int);
On 29/11/11 16:44, Joseph S. Myers wrote:
On Tue, 29 Nov 2011, Nadezhda Ivan�vna Vyukova wrote:
I've explained the customer that by default char is treated
as signed char on our platform and therefore this program
does not conform ISO C90, as it causes the integer overflow
(undefined
On 18/11/2011 10:27, Alexandru Juncu wrote:
Hello!
I have a curiosity with something I once tested. I took a simple C
program and made an assembly file with gcc -S.
The C file looks something like this:
int main(void)
{
int a=1, b=2;
return 0;
}
The assembly instructions look like
On 18/11/2011 14:38, Alexandru Juncu wrote:
On Fri, Nov 18, 2011 at 1:24 PM, David Brownda...@westcontrol.com wrote:
On 18/11/2011 10:27, Alexandru Juncu wrote:
Hello!
I have a curiosity with something I once tested. I took a simple C
program and made an assembly file with gcc -S.
The C
On 10/11/2011 11:58, Basile Starynkevitch wrote:
Hello All
(I am playing with C++11, but I am not a C++ expert, and I don't know the C++
front-end
part of GCC, so this is a feature wish only).
Perhaps it could be useful for some later (4.8?) release of GCC to produce an
inferred
type
On 08/11/2011 05:27, Hans-Peter Nilsson wrote:
On Sun, 6 Nov 2011, Joern Rennecke wrote:
Quoting David Browndavid.br...@hesbynett.no:
Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc). It has an instruction will
multiply two
On 08/11/2011 15:24, Hans-Peter Nilsson wrote:
(Not CC:ing the quoted newsgroup, sorry.)
On Tue, 8 Nov 2011, David Brown wrote:
If the compiler can generate fractional arithmetic code directly from such
expressions, then it is indeed a good step towards implementing such types as
a pure C
On 05/11/11 21:43, Gabriel Dos Reis wrote:
On Sat, Nov 5, 2011 at 2:30 PM, David Brown
A C++ template class for _Fract support would be straightforward to write,
and could easily support the formats in N1169. But it would be very hard to
do so in a way that generates small and fast code
On 06/11/11 16:40, Jonathan Wakely wrote:
On 6 November 2011 15:03, David Brown wrote:
Obviously C++ is going to get features that C does not - that's fair
enough. But it is seldom that there is a good reason for C++ not supporting
the additions to C standards.
Some of the differences
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in the preprocessor. The C++11 spec stipulates
that any suffix that is recognized by the
On 05/11/11 18:29, Ed Smith-Rowland wrote:
On 11/05/2011 08:36 AM, David Brown wrote:
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc
On 04/10/2011 23:47, Andrew Pinski wrote:
On Tue, Oct 4, 2011 at 2:40 PM, David Browndavid.br...@hesbynett.no wrote:
naked functions are often useful in embedded systems, and are therefore
useful (and implemented) on many gcc targets. It would make sense to have
the attribute available
On 05/10/2011 12:00, Andi Kleen wrote:
David Brownda...@westcontrol.com writes:
Some toolchains are configured to have a series of init sections at
startup (technically, that's a matter of the default linker scripts
and libraries rather than the compiler). You can get code to run at
specific
On 04/10/11 21:36, Andrew Pinski wrote:
On Tue, Oct 4, 2011 at 12:30 PM, Iain Buclawibuc...@ubuntu.com wrote:
These patches address two areas of the D language:
1) D calling convention.
2) Naked functions on i386 and x86_64
Some work would need to be done on naked functions at least first so
On 26/09/2011 02:37, Miles Bader wrote:
David Browndavid.br...@hesbynett.no writes:
So what advantages would there be in declaring a volatile buffer like
this to be const? At best, you are helping the compiler check that
you don't accidentally write to it in your own code.
That's actually
On 24/09/2011 18:25, John Regehr wrote:
it. And while I think the compiler should be allowed to generate the
optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully
understand the idea of generating the older, slower, but definitely
correct code of 4.5.
My understanding is that the
On 25/09/11 16:16, Andreas Schwab wrote:
David Brownda...@westcontrol.com writes:
There is a big difference between defining an object as const, and
merely declaring it as const or accessing it as const. When you access it
as const, you are saying /I/ won't change the object with this
On 25/09/11 17:15, Dave Korn wrote:
On 25/09/2011 13:56, David Brown wrote:
There is a big difference between defining an object as const, and
merely declaring it as const or accessing it as const. When you access
it as const, you are saying /I/ won't change the object with this
access. When
On 24/09/2011 17:09, John Regehr wrote:
What can't make sense is a /static/ volatile const which is
/defined/ locally, rather than just declared.
The code in question sounds well-defined (but probably poor style) to me.
It is never OK to access a qualified object through an unqualified
On 21/09/2011 16:57, Paulo J. Matos wrote:
On 21/09/11 15:21, David Brown wrote:
And since this
situation would not occur in real code (at least, not code that is
expected to do something useful other than test the compiler's code
generation), there is no harm in making sub-optimal object code
On 21/09/2011 20:50, Georg-Johann Lay wrote:
David Brown schrieb:
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brownda...@westcontrol.com writes:
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change
On 20/09/2011 18:35, Ian Lance Taylor wrote:
Paulo J. Matospa...@matos-sorge.com writes:
The following code:
static const unsigned int foo = 1;
unsigned int test( void )
{
const volatile unsigned int *bar =foo;
return ( *bar );
}
in GCC45 works as expected:
$test:
ld AL,#foo ;; AL
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of foo - the compiler can still implement it as a
compile-time constant.
But since I am accessing the data through the pointer and the pointer
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brownda...@westcontrol.com writes:
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of foo - the compiler can still implement it as a
compile
On 12/05/2011 17:24, fanqifei wrote:
I am using gcc4.3.2.
In our microcontroller, move instruction(mov reg, imm) can accept
16bits and 32bits immediate operand.
The data memory size is less than 64KB, however, code memory size is
larger than 64KB.
The immediate operand may be addresses of
On 29/04/2011 09:24, Pierre Vittet wrote:
Hi,
My name is Pierre Vittet and my GSOC application as been selected. My
project is about writing a plugin allowing GCC users to add some simple
warnings, being useful in their particular project.
The user should be able to add rules like when I got a
to MELT. Hence a
question to David Brown: will he use MELT if it had an infix syntax
(but all the rest of MELT being the same)? [I am not sure, and this is
why making an infix syntax is not my priority]
Perhaps I wasn't clear here (or perhaps I misunderstood Pierre's first
post). I am not suggesting
On 18/03/2011 11:15, Paulo J. Matos wrote:
On 18/03/11 10:08, WANG.Jiong wrote:
This may related with subreg regmove finding
Suggest specifiy -fdump-rtl-regmove to see what happen after this pass
Maybe avr need a target dependent regmove pass to handle this
It doesn't look like it's regmove,
On 25/02/2011 16:43, Matthias Kretz wrote:
Hi,
On Friday 25 February 2011 16:26:24 Richard Guenther wrote:
On Fri, Feb 25, 2011 at 4:19 PM, Matthias Kretz wrote:
My expectation was, that, since the ctor has a constructed object as
return value, the compiler is free, instead of calling a ctor
On 12/01/2011 12:07, Bill Cox wrote:
First, the problem: I've got a C library I want to share. There are
many users who want to use it. This should be as easy as breathing,
but it's not!
My users and I face what I'm calling GNU/Linux Innovation Red Tape.
This library is two files: sonic.c
201 - 300 of 322 matches
Mail list logo
