--- Comment #3 from charlet at gcc dot gnu dot org 2008-04-09 06:45 ---
missing debug info is never really major, since there are always work arounds
(like print statements).
Note that there is close to zero chance that someone will look into your .bz2
file,
let alone your README.
The following test program returns 1 for omp_get_max_threads in a parallel
region. This is different from what I get with three other compilers, and hence
somewhat unexpected. Is this correct, and if so, should it be the default?
gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
gfortran seems to misreport a warning about exceeding the number of
continuation lines limit (39 lines of continuation) in certain cases when
compiled with -pedantic.
We found the bug when using a very long write statement, with alternating
continuation lines of string literals and data. The bug
--- Comment #1 from jv244 at cam dot ac dot uk 2008-04-09 08:07 ---
reading a bit more, this seems a real bug.
Can this be fixed for 4.3, pretty please ?
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #8 from rguenther at suse dot de 2008-04-09 08:08 ---
Subject: Re: time/memory hog for large c++ source.
On Tue, 8 Apr 2008, pluto at agmk dot net wrote:
--- Comment #7 from pluto at agmk dot net 2008-04-08 16:50 ---
(In reply to comment #6)
We'll not be able
--- Comment #2 from burnus at gcc dot gnu dot org 2008-04-09 09:19 ---
We found the bug when using a very long write statement, with alternating
continuation lines of string literals and data. The bug does not appear if
only string literals are used.
I forget to say thank you for
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-09 09:05 ---
Confirm.
The problem is not the settings, but that the counting goes wrong. This can
also be seen if one adds comment or empty lines in between. One would expect
that this should not affect the line count (i.e.
--- Comment #3 from bachlipp at web dot de 2008-04-09 10:05 ---
Created an attachment (id=15454)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15454action=view)
Preprocessed source file, third chunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35883
--- Comment #8 from irar at gcc dot gnu dot org 2008-04-09 10:55 ---
Subject: Bug 35821
Author: irar
Date: Wed Apr 9 10:55:11 2008
New Revision: 134136
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134136
Log:
PR tree-optimization/35821
* tree-vect-transform.c
--- Comment #2 from jv244 at cam dot ac dot uk 2008-04-09 10:58 ---
also confirmed for trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to
--- Comment #1 from pcarlini at suse dot de 2008-04-09 11:22 ---
Names starting with __ and _ (see 17.4.3.1 for details) are reserved. That's
exactly the reason why the library uses everywhere and only such names (why,
otherwise?)
--
pcarlini at suse dot de changed:
What
The following program:
#include stdio.h
int main(int argc, char **argv) {
unsigned inttestu32a = 0x506f85f;
unsigned long long testu64a = 0x9afa246709018f48ULL;
printf(before: testu64a = %08x%08x, testu32a = %08x\n, (unsigned
int)( testu64a 32 ), (unsigned int)(
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-09 10:32 ---
This fails actually since:
http://gcc.gnu.org/viewcvs?root=gccview=revrev=132282
AKA PR34824.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bachlipp at web dot de 2008-04-09 10:04 ---
Created an attachment (id=15452)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15452action=view)
Preprocessed source file, first chunk
Generated from original log4cplus-1.0.2 distribution, configured using just
When you define __need_size_t before including cstddef it only pulls in
size_t, but the cstddef header expects ptrdiff_t there too and fails.
sample code:
--
#define __need_size_t
#include cstddef
main() {}
--
error message produced by g++:
$ g++ main.cpp
In file included from main.cpp:2:
--- Comment #2 from bachlipp at web dot de 2008-04-09 10:05 ---
Created an attachment (id=15453)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15453action=view)
Preprocessed source file, second chunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35883
I tried to compile log4cplus-1.0.2 with the latest stable GCC distributed with
MinGW (gcc-*-3.4.5-20060117-2). This failed. So I compiled GCC 3.4.6 myself:
export PATH=/mingw/bin:$PATH
export GCC_EXEC_PREFIX=/mingw/lib/gcc/
cd ..
mkdir mingw32
cd mingw32
mkdir /usr/include
../gcc-3.4.6/configure
); not even using valgrind. This is with
gfortran 4.4.0 20080409 (experimental) [trunk revision 134131]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-09 13:01 ---
Sorry, but the oldest GCC version still maintained is GCC 4.1.2 though I
suggest
to at least try GCC 4.2.x which will even get further updates.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-09 13:05 ---
This works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35885
GNAT switches the location of the full type and the incomplete type when a
tagged type is completed with a non-tagged record:
% gcc -gnatv -c p.ads
GNAT 4.4.0 20080409 (experimental)
Copyright 1992-2008, Free Software Foundation, Inc.
Compiling: p.ads (source file time stamp: 2008-04-09 13:15:07
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #3 from jv244 at cam dot ac dot uk 2008-04-09 13:31 ---
I decided to ask, and maybe it is correct anyway, even though I have not fully
followed the bit on 'nthreads-var'
http://www.openmp.org/forum/viewtopic.php?f=3t=100
--
--- Comment #1 from sam at gcc dot gnu dot org 2008-04-09 13:38 ---
Confirmed on GCC 4.4.0 20080409.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from danglin at gcc dot gnu dot org 2008-04-09 14:13 ---
This was introduced in revision 133452.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-09 14:22 ---
Subject: Bug 28305
Author: sam
Date: Wed Apr 9 14:21:18 2008
New Revision: 134142
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134142
Log:
gcc/ada/
PR ada/28305
* sem_ch6.adb
--- Comment #4 from sam at gcc dot gnu dot org 2008-04-09 14:22 ---
Fixed in SVN trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
with --disable-libgomp buildsystem omits omp.h installation
but installs libstdc++/parallel stuff which depends on it.
this won't work.
--
Summary: stl parallel includes installed for --disable-libgomp
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-09 14:25 ---
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-04-09 14:32 ---
Created an attachment (id=15455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15455action=view)
gcc43-pr35634.patch
Here is the updated FE only patch. One change is that it avoids
P{RE,OST}{IN,DE}CREMENT_EXPR
--- Comment #5 from dje at gcc dot gnu dot org 2008-04-09 14:41 ---
Subject: Bug 35597
Author: dje
Date: Wed Apr 9 14:41:07 2008
New Revision: 134143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134143
Log:
PR libstdc++/35597
* toplev.c (process_options):
20080409 (experimental) (i686-pc-linux-gnu) Storage_Error stack
overflow (or erroneous memory access)|
| Error detected at b.ads:5:20 |
--
Summary: ICE: converting a concrete type into a classwide
interface
Product
--- Comment #4 from scovich at gmail dot com 2008-04-09 15:18 ---
If it's any help, adding some inline asm to the file makes the Sun toolchain
croak on my machine.
SunOS 5.10 Generic_118833-23 sun4v sparc SUNW,Sun-Fire-T200
Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
Solaris Link
--- Comment #4 from knoxj at att dot net 2008-04-09 15:19 ---
Print statements work if you know what you want to look at.
The application is an aircraft simulation by stimulating avionics black boxes.
We use a debugger to examine state information while the simulation is running
to try
--- Comment #1 from rbertran at ac dot upc dot edu 2008-04-09 15:20 ---
Created an attachment (id=15456)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15456action=view)
Temp file generated when -save-temps flag is set
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35889
--- Comment #13 from rguenther at suse dot de 2008-04-09 15:26 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] operand of
pre-/postin-/decrement not promoted
On Wed, 9 Apr 2008, jakub at gcc dot gnu dot org wrote:
--- Comment #12 from jakub at gcc dot gnu dot org 2008-04-09
--- Comment #3 from rbertran at ac dot upc dot edu 2008-04-09 15:25 ---
Created an attachment (id=15457)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15457action=view)
Temp file generated when -save-temps flag is set
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35889
Hello,
I'm using gcc4.3.0 for compiling cell binaries on a x86 platform.
I've some benchmarks that use c++ templates like:
template typename T inline
T rot_veci( T v, int n )
{
return (T) si_rotqbyi( (vector signed char)v, n );
}
When compiling, I get the following error:
error: si_rotqbyi
--- Comment #2 from rbertran at ac dot upc dot edu 2008-04-09 15:24 ---
Command executed:
spu-g++ -ffreestanding -Wall -ffast-math -fno-rtti -fno-exceptions
--function-sections --data-sections -fsigned-char -I -I../.. -I../../include
-I./org -I. `pkg-config --cflags opencv`
--- Comment #5 from charlet at adacore dot com 2008-04-09 15:25 ---
Subject: Re: GNAT (GCC) Ada does not generate symbolic debug for shared memory
The application is an aircraft simulation by stimulating avionics black boxes.
We use a debugger to examine state information while the
--- Comment #2 from wilbert at jdg dot info 2008-04-09 15:36 ---
I just did a fresh build of gcc 4.1.3 from the ports collection under freebsd
6.1
And got this (incorrect) result again:
before: testu64a = 9afa246709018f48, testu32a = 0506f85f
after: testu64a = 9afa246709018f48,
--- Comment #53 from bergner at gcc dot gnu dot org 2008-04-09 15:38
---
Author: bergner
Date: Wed Apr 9 13:42:43 2008
New Revision: 134139
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134139
Log:
PR middle-end/PR28690
* explow.c (break_out_memory_refs): Use
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-09 15:53 ---
*** This bug has been marked as a duplicate of 35546 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-09 15:53 ---
*** Bug 35890 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following code, which compiles cleanly in gcc 4.2.3, produces an error with
4.3.0:
template typename T
struct X {
void f(const char *fmt, ...)
__attribute__((format (printf, 2, 3) ));
};
template class X void ;
fmt_et.cc: In instantiation of 'Xvoid':
fmt_et.cc:7:
--- Comment #8 from jason at gcc dot gnu dot org 2008-04-09 16:16 ---
Subject: Bug 35708
Author: jason
Date: Wed Apr 9 16:15:53 2008
New Revision: 134146
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134146
Log:
PR c++/35708
* semantics.c
--- Comment #6 from knoxj at att dot net 2008-04-09 16:19 ---
Thank you for your comments. This is my first free software bug report, so I'm
still learning the ropes. I have been submitting commercial vendor bug reports
for several decades, and old habits die hard.
README file contents
I'm in the process of merging ObjC 2.0 Apple stuff into gcc 4.3.0 for the
cocotron project; we build a cross-compiler to build Windows/Linux binaries
from Darwin.
In the progress we got an ICE when compiling any ObjC++ code that would cause
an __objc_gnu_init constructor to be emitted with
--- Comment #4 from singler at gcc dot gnu dot org 2008-04-09 16:47 ---
Subject: Bug 35588
Author: singler
Date: Wed Apr 9 16:47:00 2008
New Revision: 134148
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134148
Log:
2008-04-09 Johannes Singler [EMAIL PROTECTED]
*
/gcc --enable-languages=c,fortran
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20080409 (experimental) (GCC)
Although gcc -v reports 'i386' this is in fact an x86_64. But compiling on a
true ia32 (and omitting -m64) produces the same crash.
With -g removed or -O1 the compiler
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-09 17:24
---
Created an attachment (id=15458)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15458action=view)
Fortran source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
--- Comment #5 from singler at gcc dot gnu dot org 2008-04-09 17:03 ---
Fixed for mainline and gcc-4_3-branch.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from yuri at tsoft dot com 2008-04-09 18:06 ---
After further investigation it appears to be some issue with exceptions in
FreeBSD-STABLE-7.0 system g++ compiler. Exceptions don't work on FreeBSD with
system compiler at all.
System compiler is a version of gcc-4.2.1
--- Comment #1 from hp at gcc dot gnu dot org 2008-04-09 18:08 ---
honza's bug; cc:ed.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-09 18:10 ---
*** Bug 35868 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-09 18:10 ---
*** This bug has been marked as a duplicate of 35843 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jaydub66 at gmail dot com 2008-04-09 18:23 ---
Here is a modified version of the original test case, which is also accepted by
gfortran, while it is rejected by ifort:
module m
contains
subroutine one(a)
integer a(1:2)
end subroutine one
--- Comment #5 from jaydub66 at gmail dot com 2008-04-09 18:48 ---
(In reply to comment #4)
If we are lucky this fixes PR 35831.
Actually it does not, but I think I know how to fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-09 18:49 ---
In this test case both arrays are explicit-sized, and even have the same size,
but their upper and lower bounds are shifted. gfortran currently does not even
check if both arrays have the same size, only their
--- Comment #2 from burnus at gcc dot gnu dot org 2008-04-09 18:31 ---
Confirm. Seems to be introduced between 2008-04-03-r133863 and
2008-03-27-r133632. I tried to reduce the test case -- and I failed. I think
somewhere the memory gets corrupted.
==1454== Invalid read of size 2
--- Comment #2 from eric dot weddington at atmel dot com 2008-04-09 19:04
---
I'll see about testing with Andy Hutchinson's fwprop patch at bug #35542.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #32 from fche at redhat dot com 2008-04-09 19:15 ---
The patch has been committed for some time, and this test case passes.
--
fche at redhat dot com changed:
What|Removed |Added
--- Comment #3 from hutchinsonandy at aim dot com 2008-04-09 19:24 ---
Subject: Re: code bloat caused by -fsplit-wide-types
Try fwprop patch it might well help.
I can't tell from report where the oppertunities are missed.
But anything split at combine/split won't get any benefit as
I just tried to compile the Suse Linux package smalltalk-2.1.12
with the GNU C compiler version 4.4 snapshot 20080404
The compiler said
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib-src -I../lightning
-I../lightning -I../snprintfv -I../snprintfv
-DKERNEL_PATH=\/usr/share/smalltalk/kernel\
--- Comment #1 from dcb314 at hotmail dot com 2008-04-09 19:40 ---
Created an attachment (id=15459)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15459action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35893
--- Comment #5 from laguest at archangeli dot demon dot co dot uk
2008-04-09 19:45 ---
This is still a problem on 4.4.0 trunk.
Luke.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
--- Comment #9 from jason at gcc dot gnu dot org 2008-04-09 19:58 ---
Subject: Bug 35708
Author: jason
Date: Wed Apr 9 19:57:19 2008
New Revision: 134151
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134151
Log:
PR c++/35708
* semantics.c
--- Comment #10 from jason at gcc dot gnu dot org 2008-04-09 20:10 ---
Fixed for 4.3.1 and 4.4.0. Patch seems risky for 4.2 at this point.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ludovic at ludovic-brenta dot org 2008-04-09 20:10
---
Reduced test case:
package Observers is
type Observer is tagged null record;
type Observer_Access is access all Observers.Observer'Class;
end Observers;
limited with Observers;
with
--- Comment #7 from ludovic at ludovic-brenta dot org 2008-04-09 20:25
---
Further reduced test case: replace observers.ads with:
package Observers is
type Observer is new Integer;
type Observer_Access is access Observer;
end Observers;
and the bug is still there.
--
--- Comment #8 from sam at gcc dot gnu dot org 2008-04-09 20:40 ---
Yes, the bug manifests when the view on the type is limited at this point *but*
we know the underlying type (because of a non-limited with for example). This
triggers it if you compile p2.adb:
package P1 is
type T
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c-O3
ati_fragment_shader.i
ati_fragment_shader.i: In function 'g':
ati_fragment_shader.i:39: internal compiler error: in calc_dfs_tree, at
dominance.c:393
--
Summary: ICE in calc_dfs_tree, at dominance.c:393
Product:
--- Comment #1 from marcus at jet dot franken dot de 2008-04-09 21:53
---
Created an attachment (id=15460)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15460action=view)
ati_fragment_shader.i
gcc -c -O3 ati_fragment_shader.i
--
--- Comment #4 from eric dot weddington at atmel dot com 2008-04-09 22:09
---
Confirmed.
Andy's fwprop patch from bug #35542 did not solve this.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
gcc can place code into the .rodata section. I found this while debugging a
crash in Ingo Molnar's sched-devel kernel. In the kernel code
arch/x86/kernel/alternative.c the static inline function costant_test_bit was
placed into the rodata. Later on in the kernel boot up sequence, the rodata
--- Comment #1 from rostedt at goodmis dot org 2008-04-09 22:20 ---
Created an attachment (id=15461)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15461action=view)
alternative.c file compiled with -E and with some stipping
This is a gzipped version that shows the problem.
Do the
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-09 22:34 ---
The toplevel asm has:
asm(\t.section .rodata, \a\\nintelnops:
.byte 0x90\n .byte 0x89,0xf6\n .byte 0x8d,0x76,0x00\n .byte
0x8d,0x74,0x26,0x00\n .byte 0x90\n .byte 0x8d,0x74,0x26,0x00\n .byte
Four tests in libgomp.fortran (omp_parse3.f90, pr25162.f, and
threadprivate[23].f90 started failing with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=133801
r133801 | george | 2008-04-01 17:23:36 -0400 (Tue, 01 Apr 2008)
This small testcase fails in the same way when compiled with -m64
--- Comment #1 from janis at gcc dot gnu dot org 2008-04-09 22:46 ---
Created an attachment (id=15462)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15462action=view)
generated code before patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35896
--- Comment #2 from janis at gcc dot gnu dot org 2008-04-09 22:47 ---
Created an attachment (id=15463)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15463action=view)
generated code after patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35896
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||openmp
Target Milestone|--- |4.4.0
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-09 22:50 ---
I think we are emitting the debug info too early for _testcom before we marked
it as a TLS.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2008-04-09 22:51
---
Subject: Bug 35519
Author: hutchinsonandy
Date: Wed Apr 9 22:50:42 2008
New Revision: 134152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134152
Log:
2008-04-09 Andy Hutchinson [EMAIL PROTECTED]
--- Comment #12 from hutchinsonandy at gcc dot gnu dot org 2008-04-09
22:51 ---
Subject: Bug 34916
Author: hutchinsonandy
Date: Wed Apr 9 22:50:42 2008
New Revision: 134152
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134152
Log:
2008-04-09 Andy Hutchinson [EMAIL PROTECTED]
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-09 22:51 ---
Before:
.quad [EMAIL PROTECTED]
After:
.8byte testcom_
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35896
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-09 22:54 ---
Actually we just don't take into account TLSness of the decl/RTL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35896
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-04-09 23:47
---
After a clean bootstrap (empty build directory) I get a pass. I suspect we
have a dependency somewhere not getting taken car of. Hans-Peter can you try
this and see whta happends.
--
--- Comment #7 from hp at gcc dot gnu dot org 2008-04-09 23:49 ---
For cris-elf, this graduated to a runtime error equivalent to SEGV (no
valgrind); worked with 134139, failed from 134147.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hp at gcc dot gnu dot org 2008-04-09 23:56 ---
Try what? I always start with a clean slate; an empty build directory!
Perhaps you mean something else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
--- Comment #9 from hp at gcc dot gnu dot org 2008-04-09 23:57 ---
(In reply to comment #8)
Try what? I always start with a clean slate; an empty build directory!
Perhaps you mean something else?
Oops, replied in wrong PR... please ignore.
--
--- Comment #7 from hp at gcc dot gnu dot org 2008-04-09 23:57 ---
Try what? I always start with a clean slate; an empty build directory!
Perhaps you mean something else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-04-09 23:59
---
Subject: Bug 33782
Author: hutchinsonandy
Date: Wed Apr 9 23:58:39 2008
New Revision: 134153
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134153
Log:
2008-04-09 Andy Hutchinson [EMAIL PROTECTED]
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-04-09 23:59
---
Subject: Bug 34894
Author: hutchinsonandy
Date: Wed Apr 9 23:58:39 2008
New Revision: 134153
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134153
Log:
2008-04-09 Andy Hutchinson [EMAIL PROTECTED]
--- Comment #8 from hp at gcc dot gnu dot org 2008-04-10 00:00 ---
I haven't tried it myself, but since we're in voodoo-debug mode, try
--enable-checking=yes,valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
--- Comment #7 from hp at gcc dot gnu dot org 2008-04-10 00:03 ---
(In reply to comment #6)
I am discussing with Zdenek the proper fix.
Any conclusion in sight? If not, I'll xfail this as per protocol.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
--- Comment #3 from joseph at codesourcery dot com 2008-04-10 00:15 ---
Subject: Re: Vector load/store from a packed struct does
not work (without -mstrict-align)
On Tue, 8 Apr 2008, pinskia at gcc dot gnu dot org wrote:
With -mstrict-align, we get the correct (but suboptimal)
dse.c has
struct store_info
{
...
/* An bitmask as wide as the number of bytes in the word that
contains a 1 if the byte may be needed. The store is unused if
all of the bits are 0. */
long positions_needed;
};
...
record_store ()
{
...
gcc_assert ((unsigned) width sizeof
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-10 00:41 ---
Well first it should be made HOST_WIDE_INT and x86 should move over to 64bit
HWI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
--- Comment #2 from hjl at gcc dot gnu dot org 2008-04-10 00:53 ---
Subject: Bug 35897
Author: hjl
Date: Thu Apr 10 00:53:04 2008
New Revision: 134160
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134160
Log:
2008-04-09 H.J. Lu [EMAIL PROTECTED]
PR middle-end/35897
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
1 - 100 of 102 matches
Mail list logo
