--- Comment #3 from ubizjak at gmail dot com 2007-11-20 08:01 ---
(In reply to comment #2)
> I build the toolchains use buildroot, the gcc version is 4.1.2, the target
> platform is arm, host platform is cygwin. The busybox version is 1.1.3
> If i uncomment some configure of busybox, a n
Hi!
I don't seem to get gfortran to warn when assigning to an unallocated array
(I've tried '-g -fbounds-check -Wall -pedantic', which I take it should cover
it all), it only segfaults at run-time...
While this is obviously menial stuff, the Lahey compiler for one nicely warns
both at compile- an
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-20 09:08 ---
(In reply to comment #3)
> WTF? tree if-conversion generates this crap.
It split up the store to rc.aec[i].fCubeful .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-20 10:36 ---
Subject: Bug 34146
Author: jakub
Date: Tue Nov 20 10:36:03 2007
New Revision: 130311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130311
Log:
PR c/34146
* c-gimplify.c (optimize_compound_lite
--- Comment #5 from steven at gcc dot gnu dot org 2007-11-20 09:57 ---
-ENONEWSFORMONTHS
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-20 09:13 ---
Well I don't think ifcvt is fully to be blamed here:
if (D.1542_49 != 0)
goto ;
else
goto ;
:
# prephitmp.14_44 = PHI <1(13), 0(11)>
# rc_45 = PHI
Why do we have that last PHI anyways? Unswitch c
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 10:36 ---
Subject: Bug 33978
Author: jakub
Date: Tue Nov 20 10:36:03 2007
New Revision: 130311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130311
Log:
PR c/34146
* c-gimplify.c (optimize_compound_lite
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 10:59 ---
The testcase is wrong, static unsigned char sbox[] = {}; means zero sized
array.
But using sbox[256] makes the testcase valid and the problem is still there.
This looks like a bug in can_convert_to_perfect_nest, this l
--- Comment #7 from burnus at gcc dot gnu dot org 2007-11-20 10:55 ---
Assign bug to myself. I have a patch, which does:
- rejects bind(c) with -std=f2003 for internal function (was missing!)
- Allows for -std=gnu bind(c) for internal procedures, but
rejects bind(c,name=...)
- Rejects
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-20 11:00 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 11:00 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
Where are "temp1.cc" and "temp2.cc" so that I correct them? are they part of
the compiler?
Thanks,
pinskia at gcc dot gnu dot org wrote:
>
> Two files are appended at the end of this report: temp1.cc and temp2.cc.
>
> temp1.cc is the only file that causes a problem with recent releases
> of G
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-20 11:34 ---
The problem is that you end up in the wrong file. If you enter "break 3" you
are debugging the wrapping program not the Fortran "program test", which is the
reason that there is no "i" available.
Try: break file.f:li
--- Comment #18 from patchapp at dberlin dot org 2007-11-20 11:45 ---
Subject: Bug number PR rtl-optimization/34085
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01050.html
--
http://gcc.
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 11:50 ---
While it would be nice if that got folded, I believe the problem is elsewhere.
Consider:
static const char s[] = "ab.cd.efghijk";
static const char t[] = "abcde";
long
foo (const char *x)
{
const char *a;
long b =
int main()
{
static int i, n;
static double a[200], b[200];
... (more variables and control flow)
for (i = 0; i < n; i++)
a[i] = b[i];
...
}
Tree-level optimisations do not pull out loads of i and n and store to i out of
loop. As a result, GCC generates five memory accesses on ia64 f
--- Comment #1 from amonakov at gmail dot com 2007-11-20 12:06 ---
Created an attachment (id=14584)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14584&action=view)
Preprocessed source
Testcase attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34160
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-20 12:20 ---
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01046.html fixes the miscompile
of the C++ frontend.
-fno-strict-aliasing makes the testcase consume a lot more memory than
-fstrict-aliasing. Which is why -O is also a
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-20 12:21 ---
Created an attachment (id=14585)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14585&action=view)
worse testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
--- Comment #4 from ludovic at ludovic-brenta dot org 2007-11-20 12:31
---
Questions:
1) If Targparm.Stack_Check_Probes_On_Target is False (i.e. the "GNAT
Stack-limit checking" is in effect), what circumstances would cause the stack
check to not detect an overflow (i.e. "unreliable sta
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-20 13:03
---
The Intel and Sun compilers complain that this code is not legal, because you
can't do "x = mytype(yy, bar)" if yy is not allocated.
Otherwise, a reduced testcase on x86_64-linux is:
type t
integer, alloca
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-20 12:58 ---
Calling middle-end aggregate_value_p on a dependent type certainly is not the
right thing to do. It can't possibly do the right thing for various C++
specific type tree codes anyway.
I wonder if the easiest fix would
When compiling the following program with -Os, the short member x of struct a
is read using a movl instruction instead of movzwl.
struct a {
int dummy;
short x;
};
struct b {
unsigned short x;
};
extern void dummy(struct b *b);
void f(struct a *a, struct b *b)
{
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-20 13:10
---
(In reply to comment #1)
> The problem is that you end up in the wrong file. If you enter "break 3" you
> are debugging the wrapping program not the Fortran "program test", which is
> the
> reason that there is n
I actually only fill this to ensure my test case does not get lost.
Fortran 2003 contains ("12.4 Procedure reference"):
"C1229 (R1221) A procedure-name shall be the name of an external procedure, a
dummy procedure, a module procedure, a procedure pointer, or a specific
intrinsic function that is
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--- Comment #8 from patchapp at dberlin dot org 2007-11-20 14:01 ---
Subject: Bug number PR34133
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01062.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from rakdver at kam dot mff dot cuni dot cz 2007-11-20
13:56 ---
Subject: Re: [4.3 Regression] ICE in is_hidden_global_store, at
tree-ssa-sink.c:207
>
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-20 09:13
> ---
> Well I don't think ifcvt is
--- Comment #7 from sam at rfc1149 dot net 2007-11-20 13:56 ---
This issue can be closed as the code in init.c has changed and those warnings
have been taken care of.
--
sam at rfc1149 dot net changed:
What|Removed |Added
--
--- Comment #4 from bauhaus at futureapps dot de 2007-11-20 14:49 ---
I can't resist pointing out that right now I am seeing an
update to widely used free software where once again an integer
overflow is creating a security hole in the system. (CVE-2007-4619)
--
http://gcc.gnu.org/b
According to http://www.suse.de/~gcctest/c++bench/polyhedron/, the run time of
"NF" increased from 37.70s to 41.57s (+10%) between 071031 and 071101. This is
an AMD Opteron system.
The same result I obtained at
http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
also on an AMD64. Interestingl
Looking at 4.1.1
/data_storage/obj-4.1.1/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc
It looks as though the size is incorrectly figured for the deallocate.
_M_destroy uses sizeof(_Rep_base) where _S_create uses sizeof(_Rep) to
determine the size of the allocation. Based on the
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-20 15:36 ---
Confirmed. HWI32 problem. The middle-end uses HWI for computing with the
case values. Up to 4.1.1, gcc ICEs for me on the testcase, from 4.1.1 on wrong
code is emitted.
--
rguenth at gcc dot gnu dot org change
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-20 15:41 ---
What's wrong? The x member is properly aligned, so a load beyond it is valid.
If you make struct a packed, then the load uses movw.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-20 15:43 ---
Alias got in the way here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-11-20 15:37
---
> 1) If Targparm.Stack_Check_Probes_On_Target is False (i.e. the "GNAT
> Stack-limit checking" is in effect), what circumstances would cause the
> stack check to not detect an overflow (i.e. "unreliable stack chec
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 16:19 ---
Subject: Bug 34089
Author: jakub
Date: Tue Nov 20 16:19:40 2007
New Revision: 130316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130316
Log:
PR c++/34089
* parser.c (cp_parser_class_head): R
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 16:20 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
I am trying to build gcc-4.2.2 using binutils 2.18. binutils seems to build
fine. gcc fails when it hits the gcc directory configuration step. It seems the
problem is that binutils as version string has changed from the past.
I am not sure if it is a gcc or binutils problem. I also wonder if it is
--- Comment #1 from pcarlini at suse dot de 2007-11-20 17:49 ---
No, no, don't worry about that, the syntactic difference is an old workaround
for a front-end limitation, doesn't matter, _Rep doesn't have any non-static
member and the size is the same. By the way, we already received fro
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-20 18:00 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-20 18:03
---
Here is a minimal testcase that reproduces the unclear error message:
subroutine prirelval(nobs, dataset)
type ped_data
integer :: maxsiz
end type ped_data
integer, dimension(dataset%maxsiz) :: nobs
--- Comment #2 from pcarlini at suse dot de 2007-11-20 17:53 ---
... also, I can tell you that at least a couple of times I saw either valgrind
or purify stumbling on basic_string where the actual (real) memory leak was in
user code, elsewhere, the memory was just unpredictably tainted..
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-20 19:30 ---
If you don't build in a combined tree, you'll have to build and install
binutils and newlib before you can build some of the gcc components, such as
libssp. This means building gcc twice; first with --disable-libssp and
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-20 19:38 ---
Guess you should ping that on gcc-patches, or better resend after such a long
while. If you are going to do the latter, I think you should move the
testcase into gcc.dg/, add
/* { dg-do run { target { int32plus } } }
--- Comment #7 from rask at gcc dot gnu dot org 2007-11-20 19:46 ---
*** Bug 34165 has been marked as a duplicate of this bug. ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-20 19:46 ---
*** This bug has been marked as a duplicate of 32287 ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
we get duplicate underscore prefixes on std::string template function calls
generated when using -fleading-underscore
the .stabs entries are fine ("_ZNSs7reserveEm") but the generated assembler
code calls "__ZNSs7reserveEm" with two underscores instead
so the linker gives us a undefined symbol "__
--- Comment #11 from rask at gcc dot gnu dot org 2007-11-20 20:04 ---
> /* { dg-do run { target { int32plus } } } */
Or even better, use types such as uint_least32_t from stdint.h, then use this
dg directive:
/* { dg-do run { target { stdint_types } } } */
--
http://gcc.gnu.org/bu
Trying to compile latest linux-2.6.git with gcc 4.3 trunk as of today results
in :
kernel/built-in.o: In function `getnstimeofday':
(.text+0x1c315): undefined reference to `__umoddi3'
kernel/built-in.o: In function `do_gettimeofday':
(.text+0x1c3cd): undefined reference to `__udivdi3'
kernel/built
--- Comment #26 from ismail at pardus dot org dot tr 2007-11-20 21:19
---
*** Bug 34167 has been marked as a duplicate of this bug. ***
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
---
--- Comment #1 from ismail at pardus dot org dot tr 2007-11-20 21:19
---
*** This bug has been marked as a duplicate of 32044 ***
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-20 21:27 ---
One bug is in gimplification which uses signed comparison to detect and
discard empty ranges. But then expand breaks it again for the same reason.
And then for a different reason, that it segfaults on
Program rece
--- Comment #10 from m-matti-a dot lehtonen at iki dot fi 2007-11-20 21:53
---
This code piece cannot compiled without warnings or errors.
/*! Presentation of transformation matrix */
typedef coordinate_ttransform_matrix_t[ 4 ][ 4 ];
...
void
transform_concat
(
transform_ma
--- Comment #32 from tkoenig at gcc dot gnu dot org 2007-11-20 21:57
---
Subject: Bug 32770
Author: tkoenig
Date: Tue Nov 20 21:57:04 2007
New Revision: 130322
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130322
Log:
2007-11-20 Thomas Koenig <[EMAIL PROTECTED]>
PR
I get
FAIL: gfortran.dg/vect/fast-math-pr33299.f90 execution test
Apparently, the check for dg-require-effective-target vect_double
doesn't work.
This is on my Athlon XP 2600+, which does not have SSE2. The
options for that test case do include the -msse2 flag, which is wrong:
Executing on ho
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-20 22:51 ---
Subject: Bug 34154
Author: rguenth
Date: Tue Nov 20 22:51:23 2007
New Revision: 130324
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130324
Log:
2007-11-20 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-20 22:52 ---
Fixed. Not a regression. 2.95 ICEs for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at rfc1149 dot net 2007-11-20 23:02 ---
Confirmed with current SVN trunk, tentative patch sent to the submitter for
testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
$ gcc -v
Using built-in specs.
Target: i486-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
--with-gxx-include-
I was working on a little routine to generate random vectors of two doubles,
but it produced nothing but {nan,nan}. It was a simple linear congruential
random number generator, so all it did was operate on a seed (a vector of two
integers) and then convert that to double using an SSE2 intrinsic. Th
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-21 00:18 ---
++*(int **)&a1;
++*(int **)&a2;
you are accessing a void* as an int* which violates C/C++ aliasing rules so you
are invoking undefined behavior.
*** This bug has been marked as a dup
--- Comment #122 from pinskia at gcc dot gnu dot org 2007-11-21 00:18
---
*** Bug 34169 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-21 00:19 ---
Not really a bug since you forgot to flush the mmx/x87 registers for fp usage.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from huamama at gmail dot com 2007-11-21 02:01 ---
Created an attachment (id=14586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14586&action=view)
the temp vi.c using -save-temps file
the temp vi.c using -save-temps file when compile busybox using
CONFIG_BUILD_AT_
--- Comment #5 from huamama at gmail dot com 2007-11-21 02:02 ---
I found when i compile busybox using CONFIG_BUILD_AT_ONCE=y, the error will
happen, but if do not use CONFIG_BUILD_AT_ONCE=y, the compile will success.
The temp file using -save-temps is attached with CONFIG_BUILD_AT_ONCE=
--- Comment #6 from huamama at gmail dot com 2007-11-21 02:08 ---
Created an attachment (id=14587)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14587&action=view)
the temp vi.c using -save-temps file, using 4.1.2
the temp vi.c using -save-temps file
--
huamama at gmail dot co
--- Comment #5 from charlet at gcc dot gnu dot org 2007-11-21 06:55 ---
This report is confused: range checking is enabled by default.
-gnato is about overflow checking, not range checking.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from ubizjak at gmail dot com 2007-11-21 07:34 ---
(In reply to comment #6)
> the temp vi.c using -save-temps file
Thanks, but we also need flags that were passed to gcc when editors/vi.c was
compiled. Probably you have to enable verbose output from your compile scripts.
--- Comment #1 from ubizjak at gmail dot com 2007-11-21 07:18 ---
No, the problem is that vectorizer runtime tests require some special
treatment. You can look at gcc.dg/vect/vect-2.c, where check_vect is called to
check for SSE2 support (on x86 targets).
I think that kind of C glue fun
71 matches
Mail list logo
