#include
struct S { unsigned addr : 31; };
struct X { static S s; };
int main() { std::make_pair( X::s.addr, true ); }
$ g++ -c t.cpp -std=c++0x
t.cpp: In function 'int main()':
t.cpp:4:46: error: cannot bind bitfield 'X::s.S::addr' to 'unsigned int&'
comeau online accepts this
--- Comment #6 from ian at airs dot com 2010-08-11 04:28 ---
Yes, this is a libgcc issue. This kind of target-specific issue is normally
handled by the relevant backend maintainers.
I'm surprised that it doesn't work, as libgcc/config/rs6000/t-ppccomm includes
crtsavgpr.S and crtresgpr
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-08-11 03:52
---
The ABI is not of concern here really. The issue comes down to you have:
char *a;
char **b = &a;
use(b[1]);
It is undefined what happens when you access b[1]. It does not matter if the
ABI defines that the argum
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2010-08-11 03:48 ---
Subject: Re: [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
On Tue, Aug 10, 2010 at 05:49:40AM -, ebotcazou at gcc dot gnu dot org
wrote:
> > Does anyone know which combination
Compile the following code with options -march=armv7-a -mthumb -Os
struct S{
int f1;
int reserved[3];
};
void ts()
{
struct S map;
map.f1 = 0;
foo(&map);
}
GCC 4.6 generates:
ts:
push{r0, r1, r2, r3, r4, lr}
add r0, sp, #16// A
The following new fails appeared between revision 162917 and 162948:
FAIL: pr29812 execution - gij test
FAIL: ExtraClassLoader execution - source compiled test
FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test
FAIL: ExtraClassLoader -O3 execution - source compiled test
FAI
--- Comment #10 from rogerio at rilhas dot com 2010-08-11 01:57 ---
I'm replying now not in the context of the bug (since as I mentioned I must
move on), but just as a conversation between 2 persons. So please don't getting
me wrong for insisting.
The cdecl calling convention on x86-32
--- Comment #42 from pinskia at gcc dot gnu dot org 2010-08-11 01:28
---
Actually looks like a bug in our specs somehow; it is not related to this issue
at all. But the fix for using -nostdinc++ fixed the real issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #41 from paolo dot carlini at oracle dot com 2010-08-11 01:23
---
We need a build system expert here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
Executing on host: /home/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/
-B/home/dave/o
--- Comment #40 from pinskia at gcc dot gnu dot org 2010-08-11 01:19
---
c++config.h:#define _GLIBCXX_HAVE_FENV_H 1
is happening for uclibc for the Canadian build but not for the cross:
c++config.h:/* #undef _GLIBCXX_HAVE_FENV_H */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
--- Comment #39 from pinskia at gcc dot gnu dot org 2010-08-11 01:12
---
(In reply to comment #38)
> (In reply to comment #37)
> > Thus, does adding -nostdinc++ to the PCHs flags work for you?
> Testing that right now.
No it did not for uclibc:
mips64-octeon-linux-gnu-c++
-L/data/src
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-11 01:09
---
Great, I'll do that.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from leledumbo_cool at yahoo dot co dot id 2010-08-11 01:04
---
Yeah, it works when I compile it myself. But it fails when compiling from make.
Hmm... looks very similar to PR39820, even problem source is the same: regex
(but of course they're different implementation, o
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-11 00:58 ---
>Then, by another well defined attribute (the calling convention) I should be
able to navigate the stack to get the other parameters.
No, the C/C++ standard says doing that is undefined because the array size is
1.
--- Comment #8 from rogerio at rilhas dot com 2010-08-11 00:54 ---
I think you are wrong, I'm not depending on undefined behaviour. When I request
&format that is clearly defined: I should be getting the address of the format
pointer as placed on the stack. Just like I would when request
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-11 00:49 ---
This is valid code and should not be rejected I think. Comeau C++ compiler
agrees with GCC here too. X::X is the same as X
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45158
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-11 00:44 ---
Was fixed in 4.5.0 by the patch which fixed PR 31567.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-11 00:32 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45241
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
GCC ta
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45238
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-08-11 00:16 ---
(In reply to comment #6)
> Created an attachment (id=21434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21434&action=view) [edit]
> gdb backtrace
>
Hmm, GGC strikes again. Well really a small stack size on
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-11 00:15 ---
Yes, I agree. I think it would be good to add the overloads, they can always be
adjusted before 4.6 if they don't match the wording Alisdair proposes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-11 00:04 ---
Closing as fixed then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-10 23:48
---
Jon, is this actually GB 99? Trivially adding something like (& co, likewise
for shared_ptr):
template
inline bool
operator!=(const unique_ptr<_Tp, _Tp_Deleter>& __x, nullptr_t)
{ return __x.get
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-08-10 23:08 ---
>correct results.
There is no correct results since you are depending on undefined behavior. It
is not a short coming of GCC but rather the source you are trying to port. The
code is not portable at all. It will
--- Comment #6 from rogerio at rilhas dot com 2010-08-10 22:35 ---
Let me just add: if you can tell me what options to set to make it always work
that would already be helpful. I noticed that disabling optimizations helps,
but not everytime (adding a lot of local automatic variables to t
--- Comment #5 from rogerio at rilhas dot com 2010-08-10 22:33 ---
Are you sure this is the way to resolve this issue? I think this will make GCC
an inferior product, as all other compilers I've tested produce correct
results. As GCC sometimes produces correct code (and in such cases it
--- Comment #8 from bernds at gcc dot gnu dot org 2010-08-10 22:31 ---
Yes.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-10 22:21 ---
This compiles:
class f1 {
class f2 {
class f3;
friend class f1;
friend void bar(f1::f2::f3 arg);
class f3 {};
};
friend void bar(f1::f2::
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-10 22:20 ---
The error message is correct f1::f2 is not accessible outside of f1 unless it
is a friend of f1 and then f1::f2::f3 is not accessible inside f1 unless f1 is
a friend of f1::f2.
--
pinskia at gcc dot gnu dot org c
--- Comment #38 from pinskia at gcc dot gnu dot org 2010-08-10 22:19
---
(In reply to comment #37)
> Thus, does adding -nostdinc++ to the PCHs flags work for you?
Testing that right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #37 from paolo dot carlini at oracle dot com 2010-08-10 22:18
---
Thus, does adding -nostdinc++ to the PCHs flags work for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #7 from ramana at gcc dot gnu dot org 2010-08-10 22:17 ---
Is this now fixed ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #20 from danglin at gcc dot gnu dot org 2010-08-10 22:13
---
Test still fails on hppa-linux.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dodji at gcc dot gnu dot org 2010-08-10 22:12 ---
(In reply to comment #7)
> Created an attachment (id=21443)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21443&action=view) [edit]
> Candidate patch
>
> I am testing this patch atm that seems to be working for
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-10 22:07 ---
This code will never work as you are not using va_start/va_end to access the
arguments. For format_indirect you should just pass around a va_list instead.
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #3 from rogerio at rilhas dot com 2010-08-10 22:04 ---
Created an attachment (id=21450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21450&action=view)
Compilation script (for the working and non-working builds)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #2 from rogerio at rilhas dot com 2010-08-10 22:03 ---
Created an attachment (id=21449)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21449&action=view)
Source file with comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #1 from rogerio at rilhas dot com 2010-08-10 22:03 ---
Created an attachment (id=21448)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21448&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-08-10 22:01
---
See PR 40974 for the fenv_t issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39238
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfi
When using variable parameters indirectly (the variable-parameter function
calls another function to format its parameters giving it the original address
of the format string), the results are usually ok for non-optimized builds and
cause segmentation faults in optimized builds.
In a large project
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|cannot build gcc-4.4.1: |[4.3/4.4/4.5/4.
--- Comment #36 from pinskia at gcc dot gnu dot org 2010-08-10 21:51
---
I am running into this also when doing a candian cross to mips64-linux-gnu. We
had locally reverted the patch for bug 3800 but I know that is wrong.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #7 from changpeng dot fang at amd dot com 2010-08-10 21:44
---
(In reply to comment #5)
> (In reply to comment #1)
> > This patch should be a valid fix, because the recognition of the dot_prod
> > pattern is known to be fail at this point if the stmt is outside the loop.
> >
--- Comment #5 from mikael at gcc dot gnu dot org 2010-08-10 20:42 ---
(In reply to comment #3)
> Might as well confirm the bug.
>
> This patch stops the segmentation fault, but I do not know
> if it is the correct fix.
>
I think the correct fix here is to take the array spec (and mayb
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-10 20:19 ---
The patch in comment #4 passes regression testing on x86_64-*-freebsd.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45244
--- Comment #6 from bernds at gcc dot gnu dot org 2010-08-10 18:45 ---
Subject: Bug 45177
Author: bernds
Date: Tue Aug 10 18:45:10 2010
New Revision: 163077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163077
Log:
PR bootstrap/45177
* config/arm/arm.c (multiple
--- Comment #4 from fang at csl dot cornell dot edu 2010-08-10 18:10
---
Subject: Re: Stage 3 bootstrap comparison failure
(powerpc-darwin8)
> --- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-08-10
> 17:33 ---
> Does passing --with-dwarf2 fix the bootstrap f
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-10 17:49 ---
Might as well confirm the bug.
This patch stops the segmentation fault, but I do not know
if it is the correct fix.
Index: interface.c
===
--- interface
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-08-10
17:33 ---
Does passing --with-dwarf2 fix the bootstrap failure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
--- Comment #2 from fang at csl dot cornell dot edu 2010-08-10 17:00
---
Created an attachment (id=21447)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21447&action=view)
cumulative patch used before building
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
--- Comment #1 from fang at csl dot cornell dot edu 2010-08-10 16:59
---
Created an attachment (id=21446)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21446&action=view)
fink package file with build script used
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
My build of 4.5.1 (using Jack Howarth's fink packaging) fails comparison at
stage 3.
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap
--- Comment #5 from drow at gcc dot gnu dot org 2010-08-10 16:01 ---
Verified on x86_64 using:
gcc-4.3 -O3 -o 43.s -S reduc.c -ftree-vectorizer-verbose=1
[two loops vectorized]
gcc-4.4 -O3 -o 43.s -S reduc.c -ftree-vectorizer-verbose=1
[one loop vectorized]
--
drow at gcc dot gnu do
--- Comment #8 from sje at cup dot hp dot com 2010-08-10 15:58 ---
Backported to the 4.4 branch.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Sta
--- Comment #7 from sje at gcc dot gnu dot org 2010-08-10 15:41 ---
Subject: Bug 41551
Author: sje
Date: Tue Aug 10 15:40:14 2010
New Revision: 163072
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163072
Log:
2010-08-10 Steve Ellcey
Jakub Jelinek
Backpo
--- Comment #7 from danglin at gcc dot gnu dot org 2010-08-10 15:24 ---
Subject: Bug 34544
Author: danglin
Date: Tue Aug 10 15:23:07 2010
New Revision: 163071
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163071
Log:
PR boehm-gc/34544
* gthr-posix.h (__gthread_s
--- Comment #3 from danglin at gcc dot gnu dot org 2010-08-10 14:56 ---
Reverting 162842 restores full bootstrap.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from dodji at gcc dot gnu dot org 2010-08-10 14:37 ---
*** This bug has been marked as a duplicate of 45200 ***
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from dodji at gcc dot gnu dot org 2010-08-10 14:37 ---
*** Bug 44301 has been marked as a duplicate of this bug. ***
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from hjl dot tools at gmail dot com 2010-08-10 13:36
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00734.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #35 from iains at gcc dot gnu dot org 2010-08-10 13:01 ---
(In reply to comment #34)
> I think the ones in calls.c are OK. So only ObjC still calls
> assemble_external. Iain?
AFAICT, assemble_external () [no longer?] emits any assembly nor does it call
DECL_ASSEMBLER_NAME:
--- Comment #9 from bernds at gcc dot gnu dot org 2010-08-10 12:53 ---
Fixed.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from bernds at gcc dot gnu dot org 2010-08-10 12:48 ---
Subject: Bug 45182
Author: bernds
Date: Tue Aug 10 12:48:16 2010
New Revision: 163057
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163057
Log:
PR middle-end/45182
* combine.c (make_compound_
--- Comment #5 from schwab at linux-m68k dot org 2010-08-10 12:42 ---
The most portable way to put a pointer value in a jlong is a = (uintptr_t)arg.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45246
--- Comment #4 from pinskia at gmail dot com 2010-08-10 12:36 ---
Subject: Re: New: optimizer dereference
On Aug 10, 2010, at 1:00 AM, "attardi at di dot unipi dot it"
wrote:
> Code produced using -O2 handles dereferencing incorrectly.
> Here is a program that shows the bug:
>
> #
On Aug 10, 2010, at 1:00 AM, "attardi at di dot unipi dot it" > wrote:
Code produced using -O2 handles dereferencing incorrectly.
Here is a program that shows the bug:
#include
#include
class Derived : public std::vector
{
public:
Derived() {}
};
void* foo(void* arg) {
void* basept
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2010-08-10
12:31 ---
There was a configuration error on my part.
--
michael dot a dot richmond at nasa dot gov changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-10 12:15 ---
Works for me on x86_64/32 with 4.5.0 and 4.5.1. Sounds similar to PR39820.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45247
--- Comment #6 from dominiq at lps dot ens dot fr 2010-08-10 12:04 ---
This is a [4.5/4.6 Regression]: the test in comment #4 compiles with gcc
version 4.4.4 (GCC).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45241
Upon compiling ruby-1.9.1-p429, I got this:
gcc -s -O4 -O4 -g -Wall -Wno-parentheses -I. -I.ext/include/i386-mingw32
-I./include -I. -DRUBY_EXPORT -o regexec.o -c regexec.c
regexec.c: In function 'onig_search':
regexec.c:3369:1: internal compiler error: Segmentation fault
Please submit a full
--- Comment #19 from dominiq at lps dot ens dot fr 2010-08-10 12:00 ---
(In reply to comment #18)
> Although it is probably better set the stride during resolution.
Probably.
A few comments before leaving for ten days without access to the net.
(1) I think all the changes done recentl
--- Comment #3 from attardi at di dot unipi dot it 2010-08-10 10:27 ---
You are right.
SWIG does this on purpose, as the most portable way to cast a pointer into a 64
bit integer:
"For non-primitive types the "in" and "out" typemaps are responsible for
casting between the C/C++ pointer
--- Comment #5 from irar at il dot ibm dot com 2010-08-10 10:23 ---
(In reply to comment #1)
> This patch should be a valid fix, because the recognition of the dot_prod
> pattern is known to be fail at this point if the stmt is outside the loop.
> (I am not sure whether we should not see
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-10 09:24 ---
The patch doens't work - we have to disable a lot more reassociation which
isn't really allowed for types with undefined overflow. There are a bunch
of invalid testcases in the testsuite as well.
We might be able t
--- Comment #18 from tkoenig at netcologne dot de 2010-08-10 09:19 ---
Subject: Re: Unnecessary temporaries
Am Dienstag, den 10.08.2010, 08:45 + schrieb dominiq at lps dot ens
dot fr:
> I think that
>
> + identical_strides = gfc_dep_compare_expr (l_stride, r_stride)
> == 1;
--- Comment #5 from redi at gcc dot gnu dot org 2010-08-10 09:16 ---
You have not found a bug in GCC and this is not the place to learn C++.
Please find a reference on C++ iostreams or find an appropriate forum to ask
questions.
You can call is_open() to see if the stream was opened
htt
--- Comment #4 from irar at il dot ibm dot com 2010-08-10 09:06 ---
I am testing the same patch as in comment #1.
Testcase that shows the problem:
int
foo(short x)
{
short i, y;
int sum;
for (i = 0; i < x; i++)
y = x * i;
for (i = x; i > 0; i--)
sum += y;
return su
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4 Regression] ICE in |[4.4/4.5/4.6 Regression] ICE
|expand_call, at calls
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-10 08:58 ---
*** This bug has been marked as a duplicate of 45241 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-10 08:58 ---
*** Bug 45239 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45241
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-10 08:58 ---
Can you attach a testcase please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45241
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-10 08:57 ---
The some reason is that loop header copying is not performed at -Os.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45243
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-10 08:56 ---
Bernd, can you commit your fix please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45182
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-10 08:56 ---
Fixed in GCC 4.4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-10 08:54 ---
void* baseptr = 0;
*(std::vector **)&baseptr = (Derived *)arg;
you are accessing an object of type void* via an lvalue of type
std::vector *.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #17 from dominiq at lps dot ens dot fr 2010-08-10 08:45 ---
With the patch in comment#16, there is no temporary created for the code in
comment #15, but one is created for
a(10:16:1) = a(11:17)
This seems to be fixed if I replace
+ if (r_stride)
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-10 08:17
---
What happens if you add -Wall to the command line? Current mainline tells me:
u.cc: In function void* foo(void*):
u.cc:12:31: warning: dereferencing type-punned pointer will break
strict-aliasing rules
u.cc:
Code produced using -O2 handles dereferencing incorrectly.
Here is a program that shows the bug:
#include
#include
class Derived : public std::vector
{
public:
Derived() {}
};
void* foo(void* arg) {
void* baseptr = 0;
*(std::vector **)&baseptr = (Derived *)arg;
return baseptr
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-10 07:23
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #7 from paolo at gcc dot gnu dot org 2010-08-10 07:18 ---
Subject: Bug 45228
Author: paolo
Date: Tue Aug 10 07:17:44 2010
New Revision: 163049
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163049
Log:
2010-08-10 Paolo Carlini
PR libstdc++/45228
*
96 matches
Mail list logo
