--- Comment #7 from hjl at gcc dot gnu dot org 2010-08-14 02:29 ---
Subject: Bug 37074
Author: hjl
Date: Sat Aug 14 02:28:57 2010
New Revision: 163239
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163239
Log:
Support --with-fpmath=sse for x86.
gcc/
2010-08-13 H.J. Lu
--- Comment #6 from mbarenh at alios dot org 2010-08-14 01:27 ---
Created an attachment (id=21475)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21475&action=view)
patch fixes build on thumb2 platform - fixes typos
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999
--- Comment #51 from matz at gcc dot gnu dot org 2010-08-14 01:26 ---
> There you go, you are now famous.
> http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism
Thank you, that's encouraging, I just hope the language of that article won't
be changed too much to also mention ev
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-14 00:19 ---
oops, I see the problem
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-14 00:10
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #2 from paolo at gcc dot gnu dot org 2010-08-14 00:09 ---
Subject: Bug 45281
Author: paolo
Date: Sat Aug 14 00:09:21 2010
New Revision: 163231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163231
Log:
2010-08-13 Paolo Carlini
PR libstdc++/45281
*
I get the below. Jon, can you have a look? Thanks in advance...
/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc:
In function void poll(std::shared_future):
/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.c
--- Comment #50 from redi at gcc dot gnu dot org 2010-08-13 22:40 ---
Oh, and if you do get people to understand that pointer arithmetic is not
always well-defined, that would be a good thing. There are other people who
share you're incorrect understanding of the C and C++ languages, so
--- Comment #7 from sje at cup dot hp dot com 2010-08-13 22:39 ---
Does "memcpy|(ref-all.*ref-all)" need to be "(memcpy|(ref-all.*ref-all))" or
perhaps "(memcpy|ref-all.*ref-all)". Everyplace else I see a | in a scan
statement there are parentheses around the options.
--
sje at cup
--- Comment #49 from redi at gcc dot gnu dot org 2010-08-13 22:38 ---
Please, start a blog and write your views somewhere else. PLEASE.
You're rude, ignorant and annoying.
(In reply to comment #48)
> of why it is important to be able to initialize classes as function
> parameters
You
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 22:38
---
Turns out this CH 15 (N3105). I'll implement it, at least as far as the
container adaptors are concerned.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Ad
--- Comment #6 from darkdragon2000 at hotmail dot com 2010-08-13 22:30
---
OK thanks, is the code I attached here OK? I already submitted this to Atmel
also (#605725). Last time I submitted a bug to them this is the reply I got
back:
Note that avr-gcc and avr-libC are open-source pro
--- Comment #10 from lpsmith at u dot washington dot edu 2010-08-13 21:41
---
Whoops, duh, dinkumware is ms. Never mind, it was a dumb joke anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
--- Comment #9 from lpsmith at u dot washington dot edu 2010-08-13 21:40
---
Fair enough! I still disagree, but I guess my task now is to get Dinkumware
and Roguewave to change their implementations, and come back. I don't suppose
you'd be swayed by Microsoft? I didn't think so ;-)
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-13
21:30 ---
(In reply to comment #5)
> At least one fink-user has reported that Jack's latest packaging that
> automatically uses --with-dwarf2 on darwin8 builds successfully (was on a G5,
> built -j4). (My builds wer
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-13 21:28 ---
It works with the C front-end but the C++ front-end fails to warn.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-13 21:20
---
I'm not erring. We changes this behavior on purpose, after having also checked
that *2* other, completely independent, implementations agree (ie, Dinkumware
and Roguewave).
--
http://gcc.gnu.org/bugzilla/s
--- Comment #48 from rogerio at rilhas dot com 2010-08-13 21:16 ---
(In reply to comment #47)
> OK, here is the deal:
> Since you want this feature so much, I'm sure that everybody would gladly
> implement it for you, for - say - measly 5000 EUR. You can then offer this
> c-like compiler
--- Comment #7 from lpsmith at u dot washington dot edu 2010-08-13 21:14
---
You're right! Sorry; I apparently jumped to a conclusion while testing (but I
did test!)
I still disagree that an 'e' with no digit following can be reasonably
construed as part of an improperly-formatted flo
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-13 21:00
---
You are of course wrong. Parsing something like "59e" as an integer type of
course succeeds and gives "59". Really, we have *tons* of testcases about that
in the testsuite. We know what we are doing ;)
--
p
--- Comment #5 from lpsmith at u dot washington dot edu 2010-08-13 20:56
---
Followup: This still fails even if you're trying to pipe it into an integer
and not a double. Integers, as per 22.2.3.1 in C++98, do not have an optional
'e' after them. (Though of course you could *cast* a
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
This testcase should compile without error, as a .* is an rvalue if the LHS is
an rvalue.
struct A { int i; };
int A::*ipm = &A::i;
template class assert_same_type;
template class assert_same_type { };
assert_same_type x2;
--
Summary: wrong decltype result for .*
Produ
--- Comment #4 from lpsmith at u dot washington dot edu 2010-08-13 20:34
---
Yes, exactly! Which is why the 'e' should not be parsed at all unless there is
an optional sign and a compulsory digit following it. The 'e' in general is
not compulsory. '59' is a valid double.
The context
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-13 20:23
---
By the way, if you read 22.2.3.1 in C++98, it's clear that 'e' is *not* just
any other character: after 'e', a sign is optional but at least a digit is
compulsory.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from lpsmith at u dot washington dot edu 2010-08-13 20:22
---
Is the reasoning explained somewhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45280
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 20:15
---
Yes, this is intended. We even have testcases about that.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Today, after a few weeks, I ran check-performance, and this test didn't
compile. I didn't manage to analyze the failure yet, and I will be away for a
few days of vacations... This is the error:
In file included from
/home/paolo/Gcc/svn-dirs/trunk/libstdc++-v3/testsuite/util/common_type/priority_qu
--- Comment #11 from bigotp at acm dot org 2010-08-13 20:11 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Hm, I only can see references to "symbol" not to either function or variable
> > declaration in the documentation. Can you cite the part that makes you
> > think
> >
In past versions of the C++ standard library, if I piped a string like "59e"
into a double, it would set the double to '59' and set position of the get
pointer to after the e. This meant I had to check if the last char read was an
'e' and if so, back up, but that was OK.
Something changed (and I
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 18:39
---
This has nothing to do with complex per se, it's simply about parsing nan,
infinity, and so on. We'll reconsider the issue in the context of C++0x (but as
a matter of fact I'm afraid we didn't manage to actuall
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-13 18:39
---
*** Bug 45279 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #7 from jv244 at cam dot ac dot uk 2010-08-13 18:20 ---
(In reply to comment #6)
> With or without the other patch, the gimple code has:
isn't the gimple output showing linenumbers even in the case where the
.original dump is missing them ?
--
http://gcc.gnu.org/bugzill
--- Comment #5 from fang at csl dot cornell dot edu 2010-08-13 18:18
---
At least one fink-user has reported that Jack's latest packaging that
automatically uses --with-dwarf2 on darwin8 builds successfully (was on a G5,
built -j4). (My builds were aborted for other reasons, still work
In a C++ program I'd written data - complex to a file:
(66.184415158223105773,-0.00037139050691640109188) (nan,0) (nan,0) (nan,nan)
(nan,0) (66.184390020754110227,0.00076665851805737529283)
(66.201451462903545667,0.0097865244553575969136)
(66.273663243057493816,0.011598247090358962108)
(65.3517113
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-13 18:00
---
Dave, any news on this? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #47 from ubizjak at gmail dot com 2010-08-13 18:00 ---
OK, here is the deal:
Since you want this feature so much, I'm sure that everybody would gladly
implement it for you, for - say - measly 5000 EUR. You can then offer this
c-like compiler to the world and save the planet.
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-08-13 17:24
---
With or without the other patch, the gimple code has:
main (integer(kind=4) argc, character(kind=1) * * argv)
[tx_f90_pointers.f90 : 30:0] {
integer(kind=4) D.1535;
static integer(kind=4) options.0[8] = {68,
--- Comment #26 from janus at gcc dot gnu dot org 2010-08-13 17:28 ---
cf. also PR45271
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-13 17:23 ---
Actually I think it's a duplicate of PR42769, or at least related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-08-13 17:16
---
> But I link GMP and MPFR into GCC source tree, how to make check on
> these? perhaps:
>cd objdir/gcc-4.5.1/gmp ; make check
>cd objdir/gcc-4.5.1/mpfr ; make check
Yes, run "make check" in the build dir
--- Comment #46 from rogerio at rilhas dot com 2010-08-13 16:42 ---
(In reply to comment #45)
> Congratulations. Are you done now?
> What else are you hoping to achieve?
> Is this a cry for attention?
No much really. Now it is all up to the community. I just want everyone to know
that
--- Comment #45 from redi at gcc dot gnu dot org 2010-08-13 16:32 ---
Congratulations. Are you done now?
What else are you hoping to achieve?
Is this a cry for attention?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #44 from rogerio at rilhas dot com 2010-08-13 16:30 ---
(In reply to comment #35)
> > char* p1=(char*)0x3000; // address not pointing to any "C-object in the C99
> > sense"
> > char* p2=(char*)0x4000; // address not pointing to any "C-object in the C99
> > sense"
> >
> > Can
--- Comment #43 from rogerio at rilhas dot com 2010-08-13 16:28 ---
(In reply to comment #41)
> You should really adjust your glasses if you want to continue trolling with
> the high standards we're used to meanwhile:
> > > What in the words "real segmentation like on 286, where there's
$ cat ptr.cpp
extern void* p;
int main() { return ( p<0 ? 1 : 0 ); }
$ g++ ptr.cpp -Wall -Wextra -O2 -S -fdump-tree-optimized
int main() ()
{
:
return 0;
}
gcc manual:
"The option -Wextra also prints warning messages for the following cases:
· A pointer is compared against integer zero with
--- Comment #16 from singler at kit dot edu 2010-08-13 15:48 ---
I would really like to see this bug tackled. It has been confirmed two more
times.
Fixing it is easily done by lowering the spin count as proposed. Otherwise,
please show cases where a low spin count hurts performance.
--- Comment #42 from matz at gcc dot gnu dot org 2010-08-13 15:25 ---
> > [ ] Yes
> > [x] No
>
> Thanks. The comunity will be alerted to this. I'll get back to you when
> your name is in some famous place associated with this claim.
That's very good. Though I'm a bit confused because
--- Comment #41 from matz at gcc dot gnu dot org 2010-08-13 15:18 ---
You should really adjust your glasses if you want to continue trolling with
the high standards we're used to meanwhile:
> > What in the words "real segmentation like on 286, where there's no linear
> > relationship be
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-08-13 15:11
---
I will try the other patch and see what this does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
--- Comment #3 from stephan dot aiche at fu-berlin dot de 2010-08-13 14:58
---
I just did some more tests and stumbled on sth interesting .. when compiling
the same source on a Debian GNU/Linux 5.0.5 (lenny) I get the same error
message
"internal compiler error: in copy_body_r, at tre
--- Comment #40 from rogerio at rilhas dot com 2010-08-13 14:53 ---
(In reply to comment #37)
> (In reply to comment #36)
> > I'm not sure you realize just how true that is. But keep going, you're
> > by far one of the best trolls I've seen in GCC land.
> Well, I can easily imagine more
--- Comment #39 from rogerio at rilhas dot com 2010-08-13 14:48 ---
(In reply to comment #35)
> > char* p1=(char*)0x3000; // address not pointing to any "C-object in the C99
> > sense"
> > char* p2=(char*)0x4000; // address not pointing to any "C-object in the C99
> > sense"
> >
> > Can
--- Comment #38 from rogerio at rilhas dot com 2010-08-13 14:47 ---
(In reply to comment #36)
> > > If you include real segmentation
> > > like on 80286, where there's no linear relationship between effective
> > > address and segment+offset, subtraction would have been prohibitively
> >
--- Comment #2 from stephan dot aiche at fu-berlin dot de 2010-08-13 14:42
---
Just forgot to add the command line to reproduce the error
c++ -DOpenMS_EXPORTS -DQT_DLL -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_TEST_LIB
-DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_DLL
-DQT_O
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-13 14:31 ---
(In reply to comment #6)
> There is code to prevent duplicate names to be imported, but it is bypassed by
> vtab and vtype stuff:
This is fine. The problem is not in importing the vtab symbols, but importing
the TBP t
--- Comment #6 from mikael at gcc dot gnu dot org 2010-08-13 14:25 ---
There is code to prevent duplicate names to be imported, but it is bypassed by
vtab and vtype stuff:
in module.c line 4373:
/* Exception: Always import vtabs & vtypes. */
if (p == NULL && (strc
--- Comment #37 from paolo dot carlini at oracle dot com 2010-08-13 13:31
---
(In reply to comment #36)
> I'm not sure you realize just how true that is. But keep going, you're
> by far one of the best trolls I've seen in GCC land.
Well, I can easily imagine more funny things to do, s
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-13
13:18 ---
Subject: Re: pthread_default_stacksize_np failed.
> dave at hiauly1 dot hia dot nrc dot ca wrote:
> > I think the answer is to provide a stub for pthread_default_stacksize_np
> > which is linked in last i
--- Comment #14 from pj dot pandit at yahoo dot co dot in 2010-08-13 13:14
---
> But surely if (as you suggest) swscanf had a DIE without DW_AT_external that
> would imply it was private to the compilation unit, which would be wrong.
Hmmn...may be.
> DW_AT_specification tells you it
--- Comment #36 from matz at gcc dot gnu dot org 2010-08-13 13:14 ---
> > If you include real segmentation
> > like on 80286, where there's no linear relationship between effective
> > address and segment+offset, subtraction would have been prohibitively
> > expensive to implement anyway
--- Comment #35 from matz at gcc dot gnu dot org 2010-08-13 13:00 ---
> char* p1=(char*)0x3000; // address not pointing to any "C-object in the C99
> sense"
> char* p2=(char*)0x4000; // address not pointing to any "C-object in the C99
> sense"
>
> Can GCC users trust that p2-p1 will alw
--- Comment #24 from jakub at gcc dot gnu dot org 2010-08-13 12:47 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-13 12:36 ---
> We have two routines called 'my_assign' (in two different modules). When
> initializing the vtabs in the main program, we happen to use the wrong one:
This is because the 'f2k_derived' namespace of 'trivial_gradien
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-13 12:35 ---
*** This bug has been marked as a duplicate of 45266 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-13 12:35 ---
*** Bug 45275 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #34 from rogerio at rilhas dot com 2010-08-13 12:14 ---
(In reply to comment #33)
> > Not really, you could always subtract. However, far pointers gave
> > predictable addresses, just like C99 says they pointer arithmetic should.
> They didn't. If you subtracted far pointer
--- Comment #3 from philippe_scelers at mentor dot com 2010-08-13 12:12
---
Subject: Re: make bootstrap fails at:checking whether
the GNU Fortran compiler is working... no
But I link GMP and MPFR into GCC source tree, how to make check on
these? perhaps:
cd objdir/gcc-4.5.1/gmp ;
--- Comment #2 from philippe_scelers at mentor dot com 2010-08-13 12:03
---
Created an attachment (id=21474)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21474&action=view)
requeste by error message output
This file is requested for debugging:
checking whether the GNU Fortran c
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-08-13 12:01
---
Please run 'make check' for GMP and MPFR. Recent versions are miscompiled by
older versions of GCC on this platform. I'd suggest sticking to the versions
listed in http://gcc.gnu.org/install/prerequisites.html.
Error message said to attach a log file, but don't find anything to attach a
file on this form. Let me know how to attach if needed
uname -a: SunOS frg-sol10-05 5.10 Generic_120011-14 sun4v sparc
SUNW,Sun-Fire-T200
using binutils-2.20 (build on the same host)
separate srcdir and objdir (build di
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-13 11:50 ---
(In reply to comment #0)
> I propose to add a more detailed documentation (though I don't know the exact
> place where to add it).
maybe http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html
The html docs are gen
As of r163210 (http://gcc.gnu.org/viewcvs?view=revision&revision=163210)
libstdc++ has two new macros:
_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE
_GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER
and a short documentation for them in include/bits/c++config
I propose to add a more detailed documentation (though
On x86_64-unknown-linux-gnu at r163221 I see the following testsuite
regression:
FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original
"memcpy|(ref-all.*ref-all)" 2
--
Summary: [4.6 Regression] FAIL: gfortran.dg/array_memcpy_3.f90
Product: gcc
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-13 11:05 ---
(In reply to comment #7)
> Also, how does on locate the DIEs for variables/functions that are listed in
> the .debug_pubnames section($ eu-readelf -wpubnames ). The list of
> variables/functions that are *defined* in t
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-13 10:57
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UN
--- Comment #11 from redi at gcc dot gnu dot org 2010-08-13 10:51 ---
But surely if (as you suggest) swscanf had a DIE without DW_AT_external that
would imply it was private to the compilation unit, which would be wrong.
If a non-static function has a DIE, it should include DW_AT_extern
--- Comment #10 from pj dot pandit at yahoo dot co dot in 2010-08-13 10:37
---
I think we've stepped away from DW_AT_external.
This "global" linkage theory is not convincing for why DW_AT_external should be
set for variables/functions that are defined outside of the compilation unit.
--- Comment #16 from hainque at adacore dot com 2010-08-13 10:14 ---
Subject: Re: pthread_default_stacksize_np failed.
dave at hiauly1 dot hia dot nrc dot ca wrote:
> I think the answer is to provide a stub for pthread_default_stacksize_np
> which is linked in last in final executables
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-13 10:11 ---
(In reply to comment #3)
> Might be related to pr41359 (whose patch was not committed).
I think it is unrelated, since this used to work in 4.3, while pr41359 never
worked AFAICT. Nevertheless, would be nice to commit
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-13 09:50 ---
The problem is the following:
We have two routines called 'my_assign' (in two different modules). When
initializing the vtabs in the main program, we happen to use the wrong one:
if (vtab$trivial_gradient_type.
--- Comment #3 from mikael at gcc dot gnu dot org 2010-08-13 09:33 ---
Might be related to pr41359 (whose patch was not committed).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-13 09:29 ---
Here is a reduced test case:
module abstract_vector
implicit none
type, abstract :: vector_class
contains
procedure(op_assign_v_v), deferred :: assign
end type vector_class
abstract interface
subrout
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-13 08:48 ---
Thus, INVALID.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-13 08:26 ---
No, we only have daily testers for SPEC 2000 with profile feedback.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-13 08:22 ---
Confirmed.
-fdump-tree-original shows only one difference when exchanging the use
statements:
--- c1.f90.003t.original2010-08-13 10:05:17.720283742 +0200
+++ c1.f90.003t.original.bug2010-08-13 10:04:53.9
--- Comment #8 from roland at redhat dot com 2010-08-13 08:08 ---
I think you've confused static variables (file scope) with C++ static members
(global scope). At any rate, this is not the place to get an education about
DWARF. You can use the dwarf-discuss mailing list for those quest
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-13 08:01 ---
I don't think this has anything to do with restrict and all with lowering
bitfield accesses only during expansion, and at RTL level the bitfield
operations being too big for combiner to optimize them.
--
http://gc
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:42 ---
Does anyone have a daily autotester for profiled-bootstrap?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:22 ---
Should use sreal, then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273
I tested an svn build from 20100813 with the following code:
struct bar {
unsigned int a:1, b:1, c:1, d:1, e:28;
};
void foo(struct bar * __restrict__ src, struct bar * __restrict__ dst)
{
dst->a = src->a;
dst->b = src->b;
dst->c = src->c;
91 matches
Mail list logo
