--- 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=gccview=revrev=142704
Log:
PR c++/37582
* include/bits/cpp_type_traits.h
--- 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 #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
--- 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
--- 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=gccview=revrev=142707
Log:
PR c++/37582
*
--- 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 does
--- 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 #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 #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=16897action=view)
testcase.
to reproduce bug you also need the boost-1.37.0 headers.
--
--- 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 #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 #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
--- 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.
--- 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
/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
--- 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 #3 from schwab at suse dot de 2008-12-12 11:00 ---
1d86aeab250b3c69bf826385bd6875cf0b9ea459 is first bad commit
commit 1d86aeab250b3c69bf826385bd6875cf0b9ea459
Author: mkuvyrkov mkuvyr...@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Tue Sep 11 13:56:30 2007 +
*
--- 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
--- 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
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 #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=gccview=revrev=142709
Log:
gcc/fortran:
2008-12-12 Daniel Franke
--- 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 #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_ =
--- 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=gccview=revrev=142710
Log:
2008-12-12 H.J. Lu hongjiu...@intel.com
PR target/38402
--- 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=gccview=revrev=142711
Log:
2008-12-12 H.J. Lu hongjiu...@intel.com
Backport from
--- 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
--- 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
--- 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
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
--- 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. It
--- 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 #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
--- 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 -,
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')
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
--- 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
--- 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 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 #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 #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=gccview=revrev=142716
Log:
2008-12-12 Sebastian Pop sebastian@amd.com
PR
--- 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
--- 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
--- 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 #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 #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 #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
--- 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 the
--- 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=gccview=revrev=142718
Log:
PR target/11594
* gcc.dg/20020103-1.c: Remove
--- 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
--- 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,
--- 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
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
--- 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
--- 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:
addr_expr 0x77ffb780
type pointer_type 0x7320f600
type integer_type 0x731f8480 short unsigned int
--- 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 #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=gccview=revrev=142719
Log:
PR tree-optimization/32044
*
--- 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 #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=gccview=revrev=142722
Log:
2008-12-12 Sebastian Pop sebastian@amd.com
PR
--- 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 #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=gccview=revrev=142723
Log:
PR objc++/31032
* obj-c++.dg/bitfield-1.mm:
--- 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=gccview=revrev=142724
Log:
PR libgfortran/24685
*
--- 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=gccview=revrev=142725
Log:
PR libgfortran/24685
*
--- 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 #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=16898action=view)
Proposed Patch
2008-12-12 Jan Sjodin jan.sjo...@amd.com
Harsha Jagasia harsha.jaga...@amd.com
--- 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
--- 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 jan.sjo...@amd.com
Harsha Jagasia harsha.jaga...@amd.com
PR tree-optimization/38500
*
--- 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
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_castint *(this-pointer));
}
};
int main(int argc, const char *argv[]) {
TestCase test;
return
--- 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=gccview=revrev=142726
Log:
PR testsuite/38163
* gcc.dg/tree-ssa/loop-3.c:
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
--- 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=16899action=view)
preprocessed source for pymol-1.1/layer0/Matrix.i
Compile with either...
gcc-4 -fgraphite-identity
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-12 22:42 ---
static int non_heap = 0;
bb 2:
if (non_heap != 0)
goto bb 3;
else
goto bb 4;
bb 3:
__builtin_free (non_heap);
Hmm, since the address of non_heap is taken, we don't optimize away the
conditional.
--- 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 #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=gccview=revrev=142727
Log:
2008-12-12 Andrew Pinski
--- 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 use
--- 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=16900action=view)
Forgot to add testcase to patch, updating patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
--- 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
--- 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=gccview=revrev=142728
Log:
2008-12-12 Jan Sjodin jan.sjo...@amd.com
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 #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
--- 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
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 #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
--- 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=gccview=revrev=142729
Log:
PR bootstrap/38383
* pa64-hpux.h
--- 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=gccview=revrev=142734
Log:
PR bootstrap/38383
* pa64-hpux.h
--- 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
--- 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 #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 #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=gccview=revrev=142736
Log:
2008-12-12 H.J. Lu hongjiu...@intel.com
PR libstdc++/37144
--- 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=gccview=revrev=142737
Log:
2008-12-12 H.J. Lu hongjiu...@intel.com
Backport from
--- 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=16901action=view)
install documentation for graphite
Hi,
Here are the documentation changes. I will send the patch to the
--- 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=16902action=view)
A patch to add -D_GLIBCXX_DEBUG to dg-options
I am testing this patch to see if it can trigger the bug.
--
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 #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
--- 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 for
$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
96 matches
Mail list logo
