$gcc --version
$gcc (GCC) 4.4.0 20081213 (experimental)
$echo $CFLAGS
$-pipe -O3 -march=core2 -mfpmath=sse -ftree-vectorize
-ftree-parallelize-loops=2 -pthread -fopenmp
I compiled and installed gmp,mpfr with this cflags, after that, I try to
compile gcc
trunk and got :
gcc -g -fkeep-inline-fun
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-13 02:37 ---
(In reply to comment #1)
> Also note if we do -Dfloat=int on a target like PPC, the stores are not
> removed
> because postreloadcse does not understand mode changes that well.
I should say PPC64 or -Dfloat=short f
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-13 02:35 ---
Also note if we do -Dfloat=int on a target like PPC, the stores are not removed
because postreloadcse does not understand mode changes that well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38513
Take:
struct f{
float a;
float b;
float c;
float d;
};
struct f a;
void h(float, float, float, float);
void g(void)
{
float a1 = a.a, b = a.b, c = a.c, d = a.d;
a.a = a1;
a.b = b;
a.c = c;
a.d = d;
h(a1, b, c, d);
}
--- CUT ---
Currently only postreload will remove the store back to
--- Comment #31 from hjl dot tools at gmail dot com 2008-12-13 02:02
---
Created an attachment (id=16902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16902&action=view)
A patch to add -D_GLIBCXX_DEBUG to dg-options
I am testing this patch to see if it can trigger the bug.
--
--- Comment #1 from spop at gcc dot gnu dot org 2008-12-13 01:52 ---
Created an attachment (id=16901)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16901&action=view)
install documentation for graphite
Hi,
Here are the documentation changes. I will send the patch to the gcc-patc
--- Comment #30 from hjl at gcc dot gnu dot org 2008-12-13 01:47 ---
Subject: Bug 37144
Author: hjl
Date: Sat Dec 13 01:46:04 2008
New Revision: 142737
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142737
Log:
2008-12-12 H.J. Lu
Backport from mainline:
2008-
--- Comment #29 from hjl at gcc dot gnu dot org 2008-12-13 01:41 ---
Subject: Bug 37144
Author: hjl
Date: Sat Dec 13 01:40:15 2008
New Revision: 142736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142736
Log:
2008-12-12 H.J. Lu
PR libstdc++/37144
* testsuit
--- Comment #2 from levi dot durfee at gmail dot com 2008-12-13 01:11
---
(In reply to comment #1)
> Is this always reproducible?
>
I'm sorry, this was my first time ever reporting a bug.. it works now
--
levi dot durfee at gmail dot com changed:
What|Removed
--- Comment #3 from danglin at gcc dot gnu dot org 2008-12-13 00:37 ---
This doesn't occur in native builds because:
/* Define to 1 if you have the `fabsf' function. */
#define HAVE_FABSF 1
--
danglin at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from danglin at gcc dot gnu dot org 2008-12-13 00:23 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from danglin at gcc dot gnu dot org 2008-12-13 00:19 ---
Subject: Bug 38383
Author: danglin
Date: Sat Dec 13 00:18:00 2008
New Revision: 142734
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142734
Log:
PR bootstrap/38383
* pa64-hpux.h (LINK_GCC_C_
--- Comment #2 from danglin at gcc dot gnu dot org 2008-12-13 00:15 ---
Subject: Bug 38383
Author: danglin
Date: Sat Dec 13 00:14:15 2008
New Revision: 142729
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142729
Log:
PR bootstrap/38383
* pa64-hpux.h (LINK_GCC_C_
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-13 00:07 ---
Is this always reproducible?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38512
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
I was using the MySQL-5.0.67 port, make install all clean..
if c++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr/local\""
-DDATADIR="\"/var/db/mysql\"" -DSHAREDIR="\"/usr/local/share/mysql\""
--- Comment #6 from spop at gcc dot gnu dot org 2008-12-12 23:31 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from markus dot schoepflin at comsoft dot de 2008-12-12
23:19 ---
The last compile command executed was:
ADA_PROJECT_PATH="/home/markus/src/ada/polyorb/projects:/home/markus/src/ada/polyorb/projects:$ADA_PROJECT_PATH"
\
gnatmake -P src.gpr --create-missing-dirs
> gcc --version
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
> svn checkout http://svn.eu.adacore.com/anonsvn/Dev/trunk/polyorb
> cd polyorb
> ./support/reconfig
> ./configure
> make
...
+===GNAT BUG DETECTED==+
| 4.3.2 (i486-pc-linux-gnu) Assert_Failure
--- Comment #5 from hjagasia at gcc dot gnu dot org 2008-12-12 23:06
---
Subject: Bug 38500
Author: hjagasia
Date: Fri Dec 12 23:05:09 2008
New Revision: 142728
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142728
Log:
2008-12-12 Jan Sjodin
Harsha Jagasia
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-12 23:04 ---
Why do you think __m could even appear in a static_assert? It is a function
argument. Changing __m to a type of int shows the same.
Changing it to a template argument causes an ICE though:
t.cc: In function 'int f(
--- Comment #4 from hjagasia at gcc dot gnu dot org 2008-12-12 23:01
---
Created an attachment (id=16900)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16900&action=view)
Forgot to add testcase to patch, updating patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
--- Comment #4 from kargl at gcc dot gnu dot org 2008-12-12 22:58 ---
(In reply to comment #3)
> What is about the obsolescent DO related part? Do we need to do
> something there
> (from F95, B.2):
>
> "Shared DO termination and termination on a statement other than END DO or
> CONTINUE
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-12-12 22:55
---
Subject: Bug 24779
Author: pinskia
Date: Fri Dec 12 22:54:09 2008
New Revision: 142727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142727
Log:
2008-12-12 Andrew Pinski
Peter Bergner
--- Comment #4 from ubizjak at gmail dot com 2008-12-12 22:41 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-12 22:42 ---
static int non_heap = 0;
:
if (non_heap != 0)
goto ;
else
goto ;
:
__builtin_free (&non_heap);
Hmm, since the address of non_heap is taken, we don't optimize away the
conditional.
--
pinskia at
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-12-12
22:44 ---
Created an attachment (id=16899)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16899&action=view)
preprocessed source for pymol-1.1/layer0/Matrix.i
Compile with either...
gcc-4 -fgraphite-identity -
The source file pymol-1.1/layer0/Matrix.c fails to compile under gcc trunk with
either '-O2 -fgraphite-identity' or '-O1 -fgraphite-identity'. In the first
case the failure is...
gcc-4 -fgraphite-identity -O2 -D_HAVE_LIBPNG -D_PYMOL_MODULE -D_PYMOL_NUMPY
-D_PYMOL_FINK -c -o Matrix.o Matrix.iMatri
--- Comment #3 from uros at gcc dot gnu dot org 2008-12-12 22:41 ---
Subject: Bug 38163
Author: uros
Date: Fri Dec 12 22:39:43 2008
New Revision: 142726
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142726
Log:
PR testsuite/38163
* gcc.dg/tree-ssa/loop-3.c: Comp
class TestCase {
private:
const int *pointer;
public:
TestCase() {
static int non_heap = 0;
this->pointer = &non_heap;
}
~TestCase() {
if (*this->pointer != 0) __builtin_free(const_cast(this->pointer));
}
};
int main(int argc, const char *argv[]) {
TestCase test;
return 0
--- Comment #12 from ghazi at gcc dot gnu dot org 2008-12-12 22:31 ---
I can narrow it down on mainline to somewhere between revisions 142545 and
142574 according to my testsuite results below:
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00786.html
http://gcc.gnu.org/ml/gcc-testres
--- Comment #3 from sebpop at gmail dot com 2008-12-12 22:31 ---
Subject: Re: [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
> 2008-12-12 Jan Sjodin
>Harsha Jagasia
>
>PR tree-optimization/38500
>* gcc.dg/graphite/pr38500.c: New.
>*
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-12 22:28 ---
What is about the obsolescent DO related part? Do we need to do something there
(from F95, B.2):
"Shared DO termination and termination on a statement other than END DO or
CONTINUE use an END DO or a CONTINUE state
--- Comment #2 from hjagasia at gcc dot gnu dot org 2008-12-12 22:27
---
Created an attachment (id=16898)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16898&action=view)
Proposed Patch
2008-12-12 Jan Sjodin
Harsha Jagasia
PR tree-optimization/38500
--- Comment #11 from janis at gcc dot gnu dot org 2008-12-12 22:23 ---
This ICE still happens on the 4.3 branch but it was fixed on mainline sometime
between r142476 (20081205) and r142646 (20081210).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
--- Comment #34 from janis at gcc dot gnu dot org 2008-12-12 22:22 ---
Subject: Bug 24685
Author: janis
Date: Fri Dec 12 22:21:14 2008
New Revision: 142725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142725
Log:
PR libgfortran/24685
* gfortran.dg/default_forma
--- Comment #33 from janis at gcc dot gnu dot org 2008-12-12 22:18 ---
Subject: Bug 24685
Author: janis
Date: Fri Dec 12 22:17:31 2008
New Revision: 142724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142724
Log:
PR libgfortran/24685
* gfortran.dg/default_forma
--- Comment #10 from janis at gcc dot gnu dot org 2008-12-12 22:15 ---
Subject: Bug 31032
Author: janis
Date: Fri Dec 12 22:14:39 2008
New Revision: 142723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142723
Log:
PR objc++/31032
* obj-c++.dg/bitfield-1.mm: Remo
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-12 22:05 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from spop at gcc dot gnu dot org 2008-12-12 21:52 ---
Subject: Bug 38492
Author: spop
Date: Fri Dec 12 21:50:57 2008
New Revision: 142722
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142722
Log:
2008-12-12 Sebastian Pop
PR tree-optimization/38492
--- Comment #66 from rakdver at gcc dot gnu dot org 2008-12-12 20:42
---
(In reply to comment #64)
> I agree that the most practical short-term solution is to avoid transforming
> the loop into a division.
>
> However, I'm also interested in what we think the right long-term solution
--- Comment #65 from rakdver at gcc dot gnu dot org 2008-12-12 20:34
---
Subject: Bug 32044
Author: rakdver
Date: Fri Dec 12 20:32:47 2008
New Revision: 142719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142719
Log:
PR tree-optimization/32044
* tree-scalar-ev
--- Comment #3 from doko at ubuntu dot com 2008-12-12 20:21 ---
this now works without the definition of DH_USES
--
doko at ubuntu dot com changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-12 20:19 ---
I'd say the bug is in may_propagate_address_into_dereference, called with addr:
unit size
align 16 symtab 0 alias set -1 canonical type 0x731f8480
precision 16 min max
point
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-12 20:07 ---
I have a semi-working patch for this. Harald's original problem is
easy to fix, but the branching into a IF block requires a little
more clean.
--
kargl at gcc dot gnu dot org changed:
What|Remove
At revision 142717 bootstrapping on i686-apple-darwin9 fails with:
Making all in src
/bin/sh ../libtool --tag CXX --mode=compile /opt/gcc/i686-darwin/./gcc/xgcc
-shared-libgcc -B/opt/gcc/i686-darwin/./gcc -nostdinc++
-L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src
-L/opt/gcc/i686-darwin
--- Comment #10 from janis at gcc dot gnu dot org 2008-12-12 19:41 ---
There are no archived test results for powerpc64-*-darwin*, so if someone can
verify that this fixes the test, please report that here or close this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-12 19:36 ---
Shorter testcase:
struct S
{
unsigned short a[50];
unsigned short b[20];
};
extern void bar (void);
extern unsigned short d[];
void
foo (void)
{
struct S s;
unsigned short g[50];
__builtin_memcpy (&s, g, si
--- Comment #12 from janis at gcc dot gnu dot org 2008-12-12 19:37 ---
Fixed.
>From the patch mail:
The scan assembler check in gcc.dg/20020103-1.c is now XPASS for all powerpc
targets reported in the gcc-testresults archive. It started passing for
powerpc64-unknown-linux-gnu with -m3
--- Comment #11 from janis at gcc dot gnu dot org 2008-12-12 19:36 ---
Subject: Bug 11594
Author: janis
Date: Fri Dec 12 19:34:48 2008
New Revision: 142718
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142718
Log:
PR target/11594
* gcc.dg/20020103-1.c: Remove XF
--- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-12
19:27 ---
Subject: Re: Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
> My long term guidance would be to engineer gcc to use its copy of the libgcc_s
> dylib and link against it. This would mean that th
--- Comment #21 from mrs at apple dot com 2008-12-12 18:42 ---
My long term guidance would be to engineer gcc to use its copy of the libgcc_s
dylib and link against it. This would mean that the newly installed libgcc_s
should be found first, over /usr/lib, and that development and suppo
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-12
18:41 ---
Subject: Re: Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
> Well, they are phasing it out in the long run perhaps but Apple is just
> transitioning to gcc 4.2.1 at the moment so gcc will be in
--- Comment #7 from sabre at nondot dot org 2008-12-12 18:04 ---
oh, that also has 'int expr;' at global scope earlier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
--- Comment #6 from sabre at nondot dot org 2008-12-12 18:02 ---
Here are the testcases I checked in with the clang implementation of this if
you're interested:
// __builtin_constant_p as the condition of ?: allows arbitrary foldable
// constants to be transmogrified into i-c-e's.
char
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2008-12-12
17:52 ---
Well, they are phasing it out in the long run perhaps but Apple is just
transitioning to gcc 4.2.1 at the moment so gcc will be in use for awhile
yet on darwin. I am unclear on what the clang/llvm will use
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-12 17:42 ---
Not only do I agree that warning is bogus, I think we get it wrong even
with END IF. From Annex B,
(2) Branching to an END IF statement from outside its block.
In Fortran 77, and for consistency also in Fort
--- Comment #5 from spop at gcc dot gnu dot org 2008-12-12 17:29 ---
Subject: Bug 38409
Author: spop
Date: Fri Dec 12 17:28:06 2008
New Revision: 142716
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142716
Log:
2008-12-12 Sebastian Pop
PR middle-end/38409
*
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 17:22 ---
It happens on ia32, x86-64 and ia64.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-12 17:20 ---
Revision 142061 is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-12 17:11 ---
It is very likely caused by revision 142061:
http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00562.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from burnus at gcc dot gnu dot org 2008-12-12 16:19 ---
I have the gut feeling that the program in comment 1 is valid, even though
gfortran, g95, ifort and NAG f95 reject it. See PR 38506.
Regarding the c_loc: I think that should be possible; I'm not 100% sure whether
the
Hi,
assuming that my reading of the standard is correct,
the following warning is inappropriate:
% cat gfcbug83.f90program gfcbug83
do 10 i = 1, 5
if (i == 3) goto 10
10 end do
end program gfcbug83
% gfc4x gfcbug83.f90
gfcbug83.f90:3.24:
if (i == 3) goto 10
1
Cloned from PR 36771. See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3d909edac01e60e2#
Since F2003 one can pass a "string" to a character(len=1),dimension(*)
dummy. The question is whether this should also work for generic
resolution or not.
The "call One('String')
--- Comment #5 from kargl at gcc dot gnu dot org 2008-12-12 16:03 ---
Looking at the -fdump-tree-original, I suspect that the minus sign in
the hex formatted number is redundant. To keep things short, I've removed
the dt_parm setup code. _gfortran_transfer_integer probably outputs -,
th
--- Comment #1 from cfairles at gcc dot gnu dot org 2008-12-12 15:59
---
cc'ing Jason
--
cfairles at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-12-12 15:59 ---
> > Sort of confirmed. You are aware that 'value-1' corresponds to
> > '-HUGE(value)-1', which is out of range for integer numbers of that kind?
>
> No. It is in range.
Loose wording on my side, s/range/model/ then
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-12 15:15 ---
(In reply to comment #1)
> Sort of confirmed. You are aware that 'value-1' corresponds to
> '-HUGE(value)-1', which is out of range for integer numbers of that kind?
>
( Ihaven't had my morning coffe, but ...)
No. I
testcase produces internal compiler error (SegFault).
Error occurs with trunk rev. 142153 ... 142709.
Rev. 142038 was ok.
$ gcc-4.4 -O2 -c tst.c
tst.c: In function 'foo1':
tst.c:26: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-12
15:04 ---
Subject: Re: Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
> I assume I am using emutls since I see...
>
> nm crayptr2.exe | grep emut
> 1cd0 t ___emutls_get_address
> 1c90 t ___emutls
--- Comment #2 from kloedej at knmi dot nl 2008-12-12 14:47 ---
(In reply to comment #1)
> Sort of confirmed. You are aware that 'value-1' corresponds to
> '-HUGE(value)-1', which is out of range for integer numbers of that kind?
Thanks for your reply.
Yes I am aware that defining an in
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 14:36 ---
Fixed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRME
--- Comment #2 from hjl at gcc dot gnu dot org 2008-12-12 14:35 ---
Subject: Bug 38402
Author: hjl
Date: Fri Dec 12 14:34:21 2008
New Revision: 142711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142711
Log:
2008-12-12 H.J. Lu
Backport from mainline:
2008-1
--- Comment #1 from hjl at gcc dot gnu dot org 2008-12-12 14:33 ---
Subject: Bug 38402
Author: hjl
Date: Fri Dec 12 14:32:00 2008
New Revision: 142710
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142710
Log:
2008-12-12 H.J. Lu
PR target/38402
* gcc/doc/md.t
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-12-12 13:55 ---
Sort of confirmed. You are aware that 'value-1' corresponds to
'-HUGE(value)-1', which is out of range for integer numbers of that kind?
Reduced testcase:
IntAdtest
integer, parameter :: i8_ = Selected_Int_Kind(1
--- Comment #7 from dfranke at gcc dot gnu dot org 2008-12-12 13:26 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-12-12 13:24 ---
Subject: Bug 36355
Author: dfranke
Date: Fri Dec 12 13:22:55 2008
New Revision: 142709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142709
Log:
gcc/fortran:
2008-12-12 Daniel Franke
PR fortran/
There seems to be a small bug when writing an 8 byte integer to a character
variable, as shown by this little test program:
program IntAdtest
integer, parameter :: i8_ = Selected_Int_Kind(18) ! = integer*8
character(len=22) :: str_value
integer(i8_) :: value
character(len=*), parameter :
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-12-12 12:09 ---
Btw, if you want to dig yourself - the problem is that the alias set of
const struct _Rb_tree_node is not a subset of struct test. So the access
of any part of an object of type struct test through a pointer of type
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-12-12 11:56 ---
Heh, of course not - I have been doing this myself gazillions of times. I am
just looking at this from the middle-end perspective where the middle-end
appears to see an _object_ ctx with a specific member layout. I
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-12 11:53 ---
Related to/dup of PR38477. I'll leave this one for the system header issue
and PR38477 for the libstdc++/C++ alias problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from paolo dot carlini at oracle dot com 2008-12-12 11:53
---
(In reply to comment #6)
> But there is no space for _Rb_tree_node<_Val> in ctx.foo._M_t._M_impl.
>
> struct _Rb_tree_impl : public _Node_allocator
> {
> _Key_compare _M_key_
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-12 11:44 ---
But there is no space for _Rb_tree_node<_Val> in ctx.foo._M_t._M_impl.
struct _Rb_tree_impl : public _Node_allocator
{
_Key_compare _M_key_compare;
_Rb_tree_node_base
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-12 11:39
---
Sorry, but I still do not understand: __x (a const _Rb_tree_node_base *) is
casted to _Const_Link_type (a const _Rb_tree_node<_Val> *) before the access,
then of course an _M_value_field esists. By the way, all
--- Comment #1 from pluto at agmk dot net 2008-12-12 11:37 ---
Created an attachment (id=16897)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16897&action=view)
testcase.
to reproduce bug you also need the boost-1.37.0 headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
/local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -dumpversion
4.4.0
/local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall -O2
-g0 -fPIC --save-temps \
-isystem ./buildenv/linux/gcc-4.4/64/boost-stlport-1.37.0/include \
bug.cpp
bug.cpp: In func
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2008-12-12 11:31
---
Sorry, I've closed this bug hastily though the bug is not fixed 4.3 branch; the
patch I was reffering to was only committed to trunk.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2008-12-12 11:28
---
This was fixed on trunk, presumably by IRA. I've also checked a clean up patch
that fixed this failure on 4.3. See
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01031.html.
--
mkuvyrkov at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-12 11:24 ---
The access is
((const struct _Rb_tree_node *)
&ctx.foo._M_t._M_impl._M_header.D.9518)->_M_value_field.pair_ptr
but _M_header is of type _Rb_tree_node_base (and is embedded in _M_impl).
_Rb_tree_node_base doe
--- Comment #14 from jakub at gcc dot gnu dot org 2008-12-12 11:23 ---
Subject: Bug 37582
Author: jakub
Date: Fri Dec 12 11:22:33 2008
New Revision: 142707
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142707
Log:
PR c++/37582
* testsuite/26_numerics/headers/cma
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-12 11:10
---
Can you explain in better detail which aliasing issues you are seeing in
_Rb_tree_impl (per Comment #1)? At line 530 I cannot see anything obviously
wrong: a pointer to the base is casted to the derived type (j
--- Comment #3 from schwab at suse dot de 2008-12-12 11:00 ---
1d86aeab250b3c69bf826385bd6875cf0b9ea459 is first bad commit
commit 1d86aeab250b3c69bf826385bd6875cf0b9ea459
Author: mkuvyrkov
Date: Tue Sep 11 13:56:30 2007 +
* config/m68k/predicates.md (movsi_const0_operand
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-12 10:11 ---
Yes. Though you have to be careful not to create false positives for
float f;
struct X { int i; };
struct X *p = (struct X *)&f;
float *q = (float *)&p->i;
return *q;
if the code is obfuscated enough that the def
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-12 10:06 ---
*** Bug 38491 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-12 10:06 ---
*** This bug has been marked as a duplicate of 38445 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from jakub at gcc dot gnu dot org 2008-12-12 08:51 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from jakub at gcc dot gnu dot org 2008-12-12 08:47 ---
Subject: Bug 37582
Author: jakub
Date: Fri Dec 12 08:46:26 2008
New Revision: 142704
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142704
Log:
PR c++/37582
* include/bits/cpp_type_traits.h (s
96 matches
Mail list logo
