Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw has done a fairly thorough reworking of
the documentation. I've helpe
On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
>> > So the bug was probably fixed more than 15 years ago.
> Probably :)
>
> But the __volatile__ shoud do no harm and shouldn't influence code
> generation in any way, no?
Of course it will: it's a barrier.
Andrew.
On 03/10/2014 03:09 PM, Shahbaz Youssefi wrote:
> Regarding C++ exceptions: exceptions are not really nice. They can
> just make your function return without you even knowing it (forgetting
> a `try/catch` or not knowing it may be needed, which is C++'s fault
> and probably could have been done bet
On 03/10/2014 05:26 PM, Shahbaz Youssefi wrote:
> I'm mostly interested in C. Nevertheless, you can of course also do
> the same in C:
>
> struct option_float
> {
> float value;
> int error_code;
> bool succeeded;
> };
>
> struct option_float inverse(int x) {
> if (x == 0)
> ret
Hi,
On 03/26/2014 03:05 PM, Daniel Gutson wrote:
> assigning a negative literal to an unsigned variable issues no warning:
>
>
>unsigned int x;
>x =- 4;
>
> This is specially important in typos when -= was intended instead of =-
>
> Would be acceptable if I add a new warning to ha
On 03/27/2014 08:05 AM, Thomas Preud'homme wrote:
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Andrew Haley
>>
>> Assigning a negative literal to an unsigned variable is well-defined
>> standard C. Is it really appropriate to w
On 03/27/2014 08:52 AM, Florian Weimer wrote:
> On 03/27/2014 08:44 AM, Andrew Haley wrote:
>
>> On 03/26/2014 03:05 PM, Daniel Gutson wrote:
>>
>>> assigning a negative literal to an unsigned variable issues no warning:
>>>
>>>
>>&g
On 03/28/2014 06:20 AM, dw wrote:
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store memory-based values to memory before executing the
> @code{asm} statement.
I don't know what a "memory-based" value is. This phrase doesn't help
at all. In additio
On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 09:10:11AM +0000, Andrew Haley wrote:
>> On 03/28/2014 06:20 AM, dw wrote:
>>> Using this clobber causes the compiler to flush all (modified) registers
>>> being used to store memory-ba
On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 09:41:41AM +0000, Andrew Haley wrote:
>> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
>>> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
>>>> On 03/28/2014 06:20
On 03/28/2014 02:48 PM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 01:15:39PM +0000, Andrew Haley wrote:
>> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
>>> On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
>>>> On 03/28/2014 09:30
On 03/31/2014 05:44 AM, dw wrote:
> So, after looking over this discussion, I have updated the text. This
> time no undefined terms, while still conveying all the points I had in mind:
>
> The "memory" clobber tells the compiler that the assembly code performs
> memory reads or writes to items o
On 04/10/2014 04:12 PM, Umesh Kalappa wrote:
> Please somebody from the group can share their thoughts and will be
> appricate the same.
But unoptimized code is expected to be large. Why do you expect
otherwise?
Andrew.
On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
> From what I can see, on x86_64, the hardware fsin(x) is more accurate
> than the hardware fsincos(x).
> As you gradually increase the size of X from 0 to 10e22, fsincos(x)
> diverges from the correct accurate value quicker than fsin(x) does.
>
On 02/09/2012 01:38 PM, Tim Prince wrote:
> x87 built-ins should be a fair compromise between speed, code size, and
> accuracy, for long double, on most CPUs. As Richard says, it's
> certainly possible to do better in the context of SSE, but gcc doesn't
> know anything about the quality of math
On 02/09/2012 02:51 PM, James Courtier-Dutton wrote:
> 2012/2/9 Andrew Haley :
>> On 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. As Richard says, it
On 02/09/2012 03:28 PM, Richard Guenther wrote:
> So - do you have an idea what routines we can start off with to get
> a full C99 set of routines for float, double and long double? The last
> time I was exploring the idea again I was looking at the BSD libm.
I'd start with INRIA's crlibm.
Andre
On 02/09/2012 03:56 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 9 Feb 2012, Andrew Haley wrote:
>
>> On 02/09/2012 03:28 PM, Richard Guenther wrote:
>>> So - do you have an idea what routines we can start off with to get
>>> a full C99 set of routines for floa
On 02/09/2012 03:55 PM, James Courtier-Dutton wrote:
> Results for x86_64
> gcc -g -O0 -c -o sincos1.o sincos1.c
> gcc -static -g -o sincos1 sincos1.o -lm
>
> ./sincos1
> sin = -8.52200849767188795e-01(uses xmm register intructions)
> sinl = 0.46261304076460176 (uses fprem and fsin)
On 02/09/2012 03:59 PM, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley wrote:
>> On 02/09/2012 03:56 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 9 Feb 2012, Andrew Haley wrote:
>>>
>>>> On 02/09/2012 03:28 PM, Ri
On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
> My view is that we should have a "GNU libm" project whose purpose is not
> to install a library directly but to provide functions for use in other
> projects (much like gnulib, but the functions could presume that they were
> being built with rece
On 02/09/2012 06:00 PM, Joseph S. Myers wrote:
> On Thu, 9 Feb 2012, Andrew Haley wrote:
>
>> On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
>>> My view is that we should have a "GNU libm" project whose purpose is not
>>> to install a library directly b
On 02/10/2012 10:15 AM, Andreas Schwab wrote:
> Russ Allbery writes:
>
>> For example, suppose I'm doing development on an amd64 box targeting armel
>> and I want to use Kerberos libraries in my armel application. I'd like to
>> be able to install the armel Kerberos libraries on my Debian system
On 02/10/2012 10:07 AM, Richard Guenther wrote:
>
> The issue with libm in glibc here is that Drepper absolutely does
> not want new ABIs in libm - he believes that for example vectorized
> routines do not belong there (nor the SSE calling-convention variants
> for i686 I tried to push once).
Tha
On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
> On 10 February 2012 10:42, Andrew Haley wrote:
>
> I think a starting point would be at least documenting correctly the
> accuracy of the current libm, because what is currently in the
> documents is obviously wrong.
> It
On 02/10/2012 02:24 PM, James Courtier-Dutton wrote:
> On 10 February 2012 14:05, Andrew Haley wrote:
>> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
>>> On 10 February 2012 10:42, Andrew Haley wrote:
>>>
>>> I think a starting point would b
On 02/10/2012 05:31 PM, Paweł Sikora wrote:
> it would be also nice to see functions for reducing argument range in public
> api.
> finally the end-user can use e.g. sin(reduce(x)) to get the best precision
> with some declared cpu overhead.
Hmm. I'm not sure this is such a terrific idea: each f
On 02/13/2012 01:11 PM, Vincent Lefevre wrote:
> On 2012-02-09 16:01:48 +0000, Andrew Haley wrote:
>> On 02/09/2012 03:59 PM, Richard Guenther wrote:
>>> Maybe. Nothing would prevent us from composing from multiple sources
>>> of course. crlibm also only provide
On 02/13/2012 08:00 PM, Geert Bosch wrote:
> GNU Linux is quite good, but has issues with the "pow" function for
> large exponents, even in current versions
Really? Even on 64-bit? I know this is a problem for the 32-bit
legacy architecture, but I thought the 64-bit pow() was OK.
Andrew.
On 02/14/2012 04:41 PM, Geert Bosch wrote:
> Right now we don't have a library either that conforms to C99
Are you sure? As far as I know we do. We might not meet
C99 Annex F, but that's not required.
> and meets the far more relaxed accuracy criteria of OpenCL and
> Ada.
Andrew.
On 02/14/2012 04:54 PM, Geert Bosch wrote:
>
> On Feb 14, 2012, at 11:44, Andrew Haley wrote:
>
>> On 02/14/2012 04:41 PM, Geert Bosch wrote:
>>> Right now we don't have a library either that conforms to C99
>>
>> Are you sure? As far as I know we d
On 02/14/2012 06:54 PM, Christoph Lauter wrote:
> My colleagues Jean-Michel Muller, Florent de Dinechin at École Normale
> Supérieure de Lyon/ INRIA/ CNRS and myself at Université Pierre et Marie
> Curie, Paris Sorbonne, we have been thinking of starting such a project
> for quite a while. We've
On 02/15/2012 09:30 AM, Vincent Lefevre wrote:
>> But to be absolutely clear, glibc's libm doesn't have a problem
>> > meeting C99, AFAIK.
> That's not quite correct. It is completely broken in directed
> rounding modes (up to crashes).
Eh? C99 doesn't require directed rounding modes. I'll grant
On 02/16/2012 02:42 PM, Vincent Lefevre wrote:
On 2012-02-15 15:18:45 +, Andrew Haley wrote:
> On 02/15/2012 09:30 AM, Vincent Lefevre wrote:
> >> But to be absolutely clear, glibc's libm doesn't have a problem
> >> meeting C99, AFAIK.
> > That&
On 02/16/2012 04:21 PM, Joseph S. Myers wrote:
On Thu, 16 Feb 2012, Andrew Haley wrote:
On 02/16/2012 02:42 PM, Vincent Lefevre wrote:
C99 doesn't require directed rounding modes, but as long as they
are claimed to be supported by, they should work:
Ah, I see. So, we could bring gcc+
On 02/21/2012 03:18 PM, 嘉谟 wrote:
> I do a experiments to check how gcc pass the arguments.
> here is the code
>
> #include
> int main(int argc , char *argv[]){
> int a=3;
> int b=3;
> int c=3;
> printf("%d %d\n",++a+c,a+c);
> printf("%d %d\n",++b,b);
>
On 03/18/2012 11:53 PM, Tomasz Borowik wrote:
> The perfect solution would be to shun away the standard model and
> actually support a kind of on-demand recompilation where the editor
> tells the compiler (running in background) what has changed and the
> compiler (having a function inlining map)
On 03/29/2012 02:59 PM, Michael Matz wrote:
> Actually, with -fnon-call-exceptions volatile asms are already supposed to
> be throwing. It's just that this got lost with tree-ssa. With the patch
> and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as
> possibly throwing.
>
On 03/30/2012 05:46 PM, stuart wrote:
> I can not seem to get gcc 4.7.0 to compile; it will not complete the
> configuration stage complaining about missing packages (GMP, MPFR and
> MPC).
Go into the top-level source directory in the unpacked gcc sources
and run this script:
./contrib/download_
On 04/02/2012 06:29 PM, Roman Suvorov wrote:
> Hello everyone,
> Not sure if this is the right place to ask this question, feel free to point
> me in the right direction.
Redirect to gcc-help.
> I'm looking into the evolution of Linux kernel and this requires me
> to build some ancient releases
On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
> For GCC-4.8, I would like to turn on -Wall by default.
> Comments?
Umm, should this really happen at exactly the same time as C++
by default?
Andrew.
On 04/04/2012 01:11 PM, Gabriel Dos Reis wrote:
> On Wed, Apr 4, 2012 at 7:08 AM, Andrew Haley wrote:
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>> Umm, should this real
On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
> Andrew Haley writes:
>
>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>> For GCC-4.8, I would like to turn on -Wall by default.
>>> Comments?
>>
>> Umm, should this really happen at exactly the sam
On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> Really? Such as what?
Such as "I wrote a perfectly legal C program, and gcc spewed out
a ton of messages."
Andrew.
On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
>> Oh, wow. Really? That's a big change. Time to be brave, I guess,
>> > but I very much like the idea of a gcc that does just what it's told;
>> > making -Wall the default is a big break with tradition.
> Sometimes, we have to be brave to challeng
On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
> On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
>> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
>>> Really? Such as what?
>>
>> Such as "I wrote a perfectly legal C program, and gcc spewed out
>> a
On 04/05/2012 03:21 PM, Gabriel Dos Reis wrote:
> On Thu, Apr 5, 2012 at 5:50 AM, Andrew Haley wrote:
>> On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
>>>> Oh, wow. Really? That's a big change. Time to be brave, I guess,
>>>>> but I very much like t
On 04/05/2012 12:30 PM, Vincent Lefevre wrote:
> On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
>> On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
>>> On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
>>>> On 04/04/2012 07:11 PM, Gabriel Dos Reis wrot
On 04/05/2012 01:28 PM, Michael Veksler wrote:
> As for specific warnings, I hate that the the code (a&&b || c&&d),
> which did not cause a warning on older gcc version now gives a
> warning. I would not want it on by default since it forces users to
> write too many parentheses in ((a&&b)||(c&&d)
On 04/11/2012 05:18 PM, Ian Lance Taylor wrote:
> Andrew Haley writes:
>
>> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>>
>>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>>> which did not cause a warning on older gcc
On 04/12/2012 10:46 AM, Robert Dewar wrote:
> On 4/12/2012 4:55 AM, Fabien Chêne wrote:
>
>> I've got a radically different experience here, real bugs were
>> introduced while trying to remove this warning, and as far as I can
>> tell, I've never found any bugs involving precedence of&& and || --
On 04/12/2012 02:03 PM, Robert Dewar wrote:
> On 4/12/2012 6:44 AM, Andrew Haley wrote:
>
>> I would also suggest that a competent programmer would know what they
>> don't know; when reading code they'd look it up, when writing code
>> they'd insert parenth
On 04/12/2012 03:36 PM, Robert Dewar wrote:
> On 4/12/2012 9:30 AM, Andrew Haley wrote:
>
>>>> I would also suggest that your competent programmer would know what
>>>> they don't know; when reading code they'd look it up, when writing
>>>> cod
On 06/22/2012 11:35 AM, Simon Baldwin wrote:
> Firstly, has anyone else encountered this or otherwise given it any
> thought? And secondly, any hints for practical fixes?
What you effectively seem to be building is a cross-compiler from
x86-glibc-A to x86-glibc-B. To run your tests, you want a m
On 06/22/2012 03:27 PM, Ian Lance Taylor wrote:
> Andrew Haley writes:
>
>> On 06/22/2012 11:35 AM, Simon Baldwin wrote:
>>> Firstly, has anyone else encountered this or otherwise given it any
>>> thought? And secondly, any hints for practical fixes?
>>
On 06/28/2012 08:39 PM, Rick Hodgin wrote:
>> Why do you want to bother with a non-standard,
>> unportable extension instead of just writing:
>>
>> inline bool isSystemClosed()
>> { return !isSystemOpen; }
>>
>> Which is simple, conventional, easy to understand
>> and portable.
>>
>> Or in C++ just
On 07/14/2012 11:02 AM, Mikael Pettersson wrote:
> Andreas Enge writes:
> > We are pleased to announce the immediate availability of the first release
> > candidate for GNU MPC 1.0 at
> >http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz
> >sha1sum 9acc8a54ba4ecd0ccf172c0d07
On 07/25/2012 12:15 PM, Jon Beniston wrote:
> For MIPS and LM32, truncation is performed in the calling function
> and sign extension in the called function. One of these operations
> seems redundant. For ARM, truncation is performed in the caller,
> but sign-extension isn't performed in the calle
On 07/25/2012 04:52 PM, Jon Beniston wrote:
> Hi Eric,
>
>>> > > I guess my question is what would I need to change to make it work
>>> > > like the ARM port? I can't see how this is being controlled.
>> >
>> > Try TARGET_PROMOTE_PROTOTYPES.
> For all 3 targets I believe this returns true (Both
On 07/26/2012 09:03 AM, Jon Beniston wrote:
> Hi Eric,
>
>>> I guess my question is what would I need to change to make it work
>>> like the ARM port? I can't see how this is being controlled.
>>
>> Try TARGET_PROMOTE_PROTOTYPES.
>
> Thanks, actually it does turn out to be this, but I was confuse
On 07/26/2012 01:32 PM, Paulo J. Matos wrote:
> On 26/07/12 13:27, Richard Guenther wrote:
>>> Why would the fill value in a memset call be required to fit in a host char?
>>
>> Obviously because of the implementation detail of its caller.
>
> Richard, I am sorry if I was not more clear. I underst
On 08/08/2012 03:01 PM, Elmar Krieger wrote:
> To me, that just looks like a remnant from the ancient past that hinders
> the future. On the other hand, my feeling tells me that this patch would
> not be accepted, that's why I'm asking for my chances in advance ;-)
Not at all high. See Type-Bas
On 08/10/2012 04:44 PM, Elmar Krieger wrote:
> I downloaded the latest official GCC 4.7.1, but unfortunately configure
> stopped with "Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC
> 0.8.0+.", and for my CentOS Linux, only older versions of this libs are
> available as RPMs.
Go into the t
On 08/14/2012 09:44 AM, Dmitri Shubin wrote:
> Any thoughts on this?
> Or maybe it's wrong list for this question?
You've already had an answer from Richard Henderson, who is probably
the best-placed person to answer you.
Please don't top-post.
Andrew.
> On 07.08.2012 12:09, Dmitri Shubin wrot
On 08/30/2012 01:43 PM, Nikos Fotoulis wrote:
> The cxx-conversion idea does not come without its cons. The most
> important for us is that there will not be a plain gcc-core package
> that is smaller, builds faster a plain C compiler with a smaller
> binary and is able to bootstrap future version
On 09/01/2012 05:09 PM, Joseph S. Myers wrote:
> Adding references to C would likely have consequences throughout the
> entire language standard. Producing the proper specification for this
> would be a large amount of work for someone with extensive expertise in
> the standard (and in the C++
On 09/03/2012 04:20 PM, Joseph S. Myers wrote:
> On Mon, 3 Sep 2012, Andrew Haley wrote:
>
>> This isn't the only way to proceed. I'd encourage someone wanting to
>> do this to branch GCC and implement a rough cut of the feature. That
>
> That would very
On 09/18/2012 04:42 PM, Mohamed Abou Samra wrote:
> I'd like to know the performance differences between any gcc
> extension and other external library I link it to my code as I
> linked Intel's DFP library to my code and I used the gcc extension
> for the DFP in another code but with the same str
On 10/06/2012 11:59 AM, _ wrote:
> Not that I think that STL/Boost are not great solutions for many
> problems out there.
> But the fact is that there is and always will be c/c++ code that can't
> and will not use it.
But surely the set of people refusing to use C++ smart pointers is the
same set
On 10/09/2012 12:31 AM, Peter wrote:
>
> On Oct 8, 2012, at 5:17 PM, Andrew Haley wrote:
>
>> On 10/06/2012 11:59 AM, _ wrote:
>>> Not that I think that STL/Boost are not great solutions for many
>>> problems out there.
>>> But the fact is that there i
On 10/11/2012 06:59 PM, Kenneth Zadeck wrote:
> this code looks bogus, i think that the "== INTEGER_CST" needs to disappear.
>
> tree
> build_newarray (int atype_value, tree length)
> {
>tree type_arg;
>
>tree prim_type = decode_newarray_type (atype_value);
>tree type
> = build_
On 10/16/2012 12:45 AM, Mischa Baars wrote:
> Who will be fixing this? Macro arguments without brackets are not
> accepted by the assembler.
>
> If I can be of any help, let me know.
We still don't know what your problem is.
Provide us with an example that we can try.
You need to tell us:
Wh
On 10/31/2012 09:49 AM, Richard Biener wrote:
> On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck
> wrote:
>> jakub,
>>
>> i am hoping to get the rest of my wide integer conversion posted by nov 5.
>> I am under some adverse conditions here: hurricane sandy hit her pretty
>> badly. my house is hoo
On 11/01/2012 10:28 AM, Peter Garbett wrote:
> I am maintaining a private port that I am attempting to port to GCC 4.7.2
>
> With RTL checking enabled, it fails with a message
>
>
> "RTL check: expected code 'reg' have 'const_int' in rhs_regno, at rtl.h:1090"
>
>
> I assume this is because the
On 11/07/12 12:08, nk...@physics.auth.gr wrote:
> AFAICS GPL,v3+ restricts my freedom... I thought that its purpose was
> to protect my freedom.
No. I don't simply want to pile on after everything that has been
said, but this is a common misconception. It isn't the purpose of the
GPL to protec
On 11/07/12 21:20, Alexandra Sawyer wrote:
> I've reported a broken link on your site
> gcc.gnu.org/ml/gcc-help/1999-q3n/msg00261.html that links to
> http://www.cs.unb.ca/~alopez-o/math-faq/math-faq.html and haven't
> heard back, so I just wanted to verify whether you're the right
> person to con
On 11/10/2012 04:45 AM, NightStrike wrote:
> Making c99 the default for gcc would be a great candidate for this.
> IIUC, gcc without -std=c99 will compile for c89. And if I read the
> manual correctly, it's because c99 isn't finished yet. gcc 5.0 should
> have a complete c99.
"Should" in what se
On 11/11/2012 04:47 AM, NightStrike wrote:
> On Sat, Nov 10, 2012 at 6:20 AM, Andrew Haley wrote:
>> On 11/10/2012 04:45 AM, NightStrike wrote:
>>> Making c99 the default for gcc would be a great candidate for this.
>>> IIUC, gcc without -std=c99 will compile
On 11/23/2012 08:12 PM, Andrew Pinski wrote:
> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote:
>> In this day and age of rich-text capable mailers, restricting postings
>> to be text-only seems quaint and antiquated. Are there any hard
>> requirements that force us to only accept plain tex
On 11/27/2012 04:00 PM, Diego Novillo wrote:
> Are there any big PCH users out there?
Yes, lots. We certainly need it to make OpenJDK builds tolerable. It
was quite a lot of work to reorganize the build to use it, but very
worthwhile.
Andrew.
On 12/24/2012 07:53 PM, Roger Cruz wrote:
>
>
> I am compiling this piece of code from an open source project that I
> wish not to have to change. The problem is that when compiled for
> ARM, it generates an LDRD instruction, which when executed, causes a
> bus error since the address in ptr is
On 01/14/2013 08:34 AM, Mischa Baars wrote:
> When running the example attached, you can see the compiler fails to
> recognize not-a-number's properly.
>
> Anyone who would like to have a look?
Comparing NaN with anything always returns false. Even when comparing
with NaN.
You want:
i
On 01/16/2013 09:27 AM, Mischa Baars wrote:
> On 01/16/2013 10:06 AM, Andreas Schwab wrote:
>> Mischa Baars writes:
>>
>>> This means that the first 'if' statement should have been terminated when
>> There is no such thing as a "terminated statement". The first condition
>> evaluates to true.
> W
On 01/16/2013 11:54 AM, Mischa Baars wrote:
>> Here's what Standard C, F.8.3 Relational operators, says:
>> >
>> > x != x → false The statement x != x is true if x is a NaN.
>> >
>> > x == x → true The statement x == x is false if x is a NaN.
>
> And indeed apparently
On 01/22/2013 06:01 AM, Mayuresh Kathe wrote:
> Hello, may I know the estimated timeframe by which full support for
> C++11 would be added in to GCC?
Status is here: http://gcc.gnu.org/projects/cxx0x.html
As usual, it'll be done when volunteer maintainers do it.
Andrew.
On 01/22/2013 12:55 PM, Alec Teal wrote:
> On 22/01/13 09:00, Andrew Haley wrote:
>> On 01/22/2013 06:01 AM, Mayuresh Kathe wrote:
>>> Hello, may I know the estimated timeframe by which full support for
>>> C++11 would be added in to GCC?
>> Status is here: http:
On 01/22/2013 02:29 PM, Alec Teal wrote:
>
> On 22/01/13 14:20, Andrew Haley wrote:
>> On 01/22/2013 12:55 PM, Alec Teal wrote:
>>> On 22/01/13 09:00, Andrew Haley wrote:
>>>> On 01/22/2013 06:01 AM, Mayuresh Kathe wrote:
>>>>> Hello, may I know t
On 01/22/2013 05:47 PM, Jonathan Wakely wrote:
> On 22 January 2013 16:52, NightStrike wrote:
>> Perhaps it'd be worthwhile to consider making the compiler easier to
>> understand, maybe by devoting a lot of effort into the internals
>> documentation. There's a lot of knowledge wrapped up in peop
On 01/22/2013 05:51 PM, Alec Teal wrote:
> I really just wanted a serious discussion, it failed. I should clarify:
> I define bitching to be "pointlessly diffusing statements so nothing
> gets done". Like the error thing "well actually that's a myth from some
> deep dark place where they used a r
On 01/23/2013 07:38 PM, Diego Novillo wrote:
> Evolving this codebase is largely a thankless and difficult job. It's
> technically interesting to me, but I know I can only do so much.
It's also worth pointing out that historically it's been very
difficult to persuade people to fund this. Many c
On 01/24/2013 09:39 AM, Uday Khedker wrote:
> I wasn't sure if taking responsibility automatically grants me the right
> to change what others have put up and that is why I was seeking support
> of the steering committee.
It's not appropriate to involve the every decision, especially when
it's n
On 01/24/2013 03:33 PM, Jeffrey Walton wrote:
> On Thu, Jan 24, 2013 at 10:06 AM, Robert Dewar wrote:
>
>> This is truly undefined, not implementation defined, and
>> if your program has such an overflow, you cannot assume
>> ANYTHING about the generated code.
> Signed integers that suffer overfl
[Resending, this time CC:'d to GCC list.]
I'm looking at Section 3.2.3, Parameter Passing.
http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/
I still cannot tell whether parameters should or should not be sign- or
zero-extended when they are moved into registers at a call
Hi,
On 01/30/2013 02:18 PM, Michael Matz wrote:
> On Wed, 30 Jan 2013, Andrew Haley wrote:
>
>> I'm looking at Section 3.2.3, Parameter Passing.
>> http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/
>>
>> I still cannot tell whether
On 01/30/2013 03:46 PM, Richard Biener wrote:
> On Wed, Jan 30, 2013 at 3:22 PM, Andrew Haley wrote:
>> Hi,
>>
>> On 01/30/2013 02:18 PM, Michael Matz wrote:
>>
>>> On Wed, 30 Jan 2013, Andrew Haley wrote:
>>>
>>>> I'm looking
On 01/30/2013 03:51 PM, Richard Biener wrote:
> On Wed, Jan 30, 2013 at 4:49 PM, Andrew Haley wrote:
>> On 01/30/2013 03:46 PM, Richard Biener wrote:
>>> On Wed, Jan 30, 2013 at 3:22 PM, Andrew Haley wrote:
>>>>
>>>> The problem is that LLVM assume
On 01/30/2013 03:55 PM, Andrew Haley wrote:
>> >
>> > It's incorrect to rely on the extension taking place. It's not incorrect
>> > to
>> > do the extension.
> Sure, I understand that, but I am completely baffled as to how
> extending at a
On 01/30/2013 04:49 PM, Michael Matz wrote:
> Hmm? GCC generates code that doesn't rely on the extension taking place.
Sure, I didn't mean to suggest it was: it's LLVM that's incorrect.
Thanks for the explanation.
Andrew.
On 02/01/2013 12:38 AM, Jan Hubicka wrote:
> Doing the extensions at caller side always is however IMO a preformance bug in
> GCC. We can definitly drop them at -Os, for non-PRS targets and for calls
> within compilation unit where we know that GCC is not really producing
> code like in Michael's
On 02/13/2013 03:06 PM, Diego Novillo wrote:
> One problem I've noticed is that renames seem to confuse svn diff. For
> example:
>
> $ cd gcc/cp
> $ svn log -r81829 cp-gimplify.c
>
> r81829 | dnovillo | 2004-05-13 22:29:32
801 - 900 of 1072 matches
Mail list logo
