--- Comment #16 from bonzini at gnu dot org 2009-02-02 08:26 ---
Subject: Re: [4.2/4.3 Regression] NULL pointers
always considered distinct by PTA, even with -fno-delete-null-pointer-checks
rguenth at gcc dot gnu dot org wrote:
--- Comment #15 from rguenth at gcc dot gnu dot org
--- Comment #19 from pluto at agmk dot net 2009-02-02 08:55 ---
(In reply to comment #16)
Subject: Bug 38503
Author: rguenth
Date: Tue Jan 27 10:42:59 2009
New Revision: 143700
this patch doesn't fix testcase that i found yesterday.
i found another testcase for
I find that I can not print local variables (none that is) if I use 4.4 for
compiling CP2K, while it goes fine with 4.3.
Reproducing requires these steps:
wget http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz
tar -xzvf CP2K_2008_12_03.tgz
cd CP2K_2008_12_03/
#
# change FCFLAGS to read
--- Comment #1 from jv244 at cam dot ac dot uk 2009-02-02 08:59 ---
gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,fortran
--disable-multilib
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #10 from jzb2 at aexorsyst dot com 2009-02-02 09:31 ---
I can confirm this is a real problem. I have hit this exact same bug on
gcc-4.2.2. However, one difference in my setup is that I _do_ have
libstdc++.so available as part of my cross toolchain, with the result the
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-02-02 13:48
---
Confirming it is a GDB bug, DW_TAG_module is completely ignored by
dwarf2read.c.
Older GCCs did not support module namespaces so it may look as a regression.
I hope to patch it soon although I have no such
--
Summary: alignment for unsigned short a[1
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2009-02-02
14:50 ---
This code:
unsigned short a[1];
void test()
{
int i;
for (i = 0; i 1; ++i) a[i] = 5;
}
will be vectorized with -O3 -march=core2 to this:
.L2:
movdqa %xmm0, a(%eax)
addl
I am trying to cross-compile flac 1.2.1 (from
http://downloads.sourceforge.net/flac/) for an ARM processor. The toolchain I
am using is based on a pretty recent buildroot snapshot (20090130).
Here's the output of gcc -v:
Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with:
--- Comment #1 from s dot neumann at phase-zero dot de 2009-02-02 16:08
---
Created an attachment (id=17228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17228action=view)
preprocessed file that triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
--- Comment #11 from jzb2 at aexorsyst dot com 2009-02-02 16:26 ---
Well, I answered my own question, sort of...
In my /usr/bin/libtool, in the CXX tag section, I have
postdeps=-lstdc++ -lm -lgcc_s -lc -lgcc_s
so voila, that's where it comes from, probably.
So this issue can now be
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2009-02-02
16:42 ---
(In reply to comment #2)
(reminds me of a couple missed-optimization PRs where vectorization is also
failing due to casts - PR31873 , PR26128 - don't know if this is related)
Are the casts actually
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-02 16:46
---
I'll see if it helps bash.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
We expand __builtin___clear_cache() to a 'synci' instruction on ISA_HAS_SYNCI
systems, which invalidates the icache only on the local CPU.
On an SMP system, the caches on all CPUs should be invalidated. To achieve
this we need to drop back to the old way of doing things by using the cache
flush
This command produces dependencies for several source files and write them to
the standard output:
gcc -M -MM file1.c file2.c file3.c
Problem appears when I try to save them to file using -MF option:
gcc -M -MM -MF makefile.dep file1.c file2.c file3.c
In this case gcc write dependencies for
The following block of code appears to produce an un-needed memcpy on both
Intel and PowerPC platforms. There is no aliasing or side-effect that I can
think of that could possibly force such copying to occur -- the problem seems
to be that gcc is not aware of the lifetime of large structures kept
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-02 13:24 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-02-02 18:26 ---
This looks like it happens on FreeBSD 7.1 as well:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00142.html
Any news on what is going on here?
Please note that i386-bsd is a primary platform for a release, as
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
if the solution of x includes ANYTHING we fail to add the solution of y to all
variables. Testcase (fails on a-i branch):
int i;
void __attribute__((noinline))
foo(long b, long q)
{
int *y;
int **a = y, **x;
int ***p;
if (b)
p = (int ***)q;
else
p = a;
x = *p;
*x = i;
*y
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-02 09:36 ---
Jakub, do you have an idea? This might be a side effect of one of your DWARF
patches.
Reduced test case:
module m
contains
subroutine a()
integer :: i
--- Comment #1 from jason at gcc dot gnu dot org 2009-02-02 18:38 ---
Subject: Bug 39054
Author: jason
Date: Mon Feb 2 18:38:10 2009
New Revision: 143876
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143876
Log:
PR c++/39054
* parser.c
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-02 18:38 ---
Fixed in 4.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from aaw at gcc dot gnu dot org 2009-02-02 19:13 ---
There were problems with my original patch (Sadly, I don't recall the
details.). I haven't looked at this in a while and am unlikely to do so soon.
If someone else wants to look at this, please feel free to do so.
--- Comment #60 from pthaugen at gcc dot gnu dot org 2009-02-02 19:16
---
I tried leslie3d on PPC. The alias-improvements branch does indeed seem to fix
the issue. The version of leslie3d built with the alias-improvements branch is
about 10% faster than a version built with trunk, and
--- Comment #3 from dberlin at gcc dot gnu dot org 2009-02-02 19:42 ---
Eyeballing this, I think y should not end up empty anyway.
Shouldn't it have i in it's points-to set?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-02 19:57 ---
Subject: Bug 39054
Author: jason
Date: Mon Feb 2 19:57:29 2009
New Revision: 143879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143879
Log:
PR c++/39054
* parser.c
--- Comment #24 from amylaar at gcc dot gnu dot org 2009-02-02 20:02
---
(In reply to comment #22)
If you post a patch to add the option to enable/disable partial-PRE I will
happily review and approve it for 4.4.
I experimented using Seteven Bosscher's patch as a starting point and
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-02-02 20:10 ---
Subject: Bug 38263
Author: ghazi
Date: Mon Feb 2 20:10:04 2009
New Revision: 143880
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143880
Log:
PR testsuite/38263
* gcc.dg/ipa/ipacost-2.c: Add
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-02 09:51 ---
The generated unwind info looks good to me, so it is likely a gdb issue.
[58]module
name m
decl_file1
decl_line1
--- Comment #74 from jason at gcc dot gnu dot org 2009-02-02 20:27 ---
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
fall back on the simpler solution that Howard proposed in the initial bug
report; it is inappropriate for library headers to redefine
--- Comment #5 from cnstar9988 at gmail dot com 2009-02-02 13:19 ---
ping 4.3.4, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38957
--- Comment #76 from paolo dot carlini at oracle dot com 2009-02-02 21:11
---
Ok, let's wait a couple of days and, assuming there are no objections, I
volunteer to implement that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-02 10:39
---
Subject: Bug 38937
Author: rguenth
Date: Mon Feb 2 10:39:12 2009
New Revision: 143864
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143864
Log:
2009-02-02 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-02 13:23 ---
Subject: Bug 39058
Author: jakub
Date: Mon Feb 2 13:23:43 2009
New Revision: 143867
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143867
Log:
PR inline-asm/39058
* recog.h (asm_operand_ok):
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-02-02 10:23
---
Same issue. Only possible fix is to not apply TBAA pruning to escaped
symbols, which will - well - basically disable TBAA. Testcase:
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
--- Comment #75 from mark at codesourcery dot com 2009-02-02 20:29 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
fall back on the simpler solution that Howard
--- Comment #2 from dj at redhat dot com 2009-02-02 21:52 ---
You should put the new code in a #ifdef HAVE_STDINT and use the old code
otherwise. Else, any platforms without stdint.h would not compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-02 14:53 ---
The ABI does not guarantee alignment bigger than 2 for the external array. The
vectorizer adjusts the alignment for the internal one.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jv244 at cam dot ac dot uk 2009-02-02 09:49 ---
(In reply to comment #3)
thanks for the reduced testcase... will help :-)
Hmm, maybe this is only a gdb bug / missing feature.
just as a note, I tried gdb 6.8 and it failed as well.
--
--- Comment #46 from mmitchel at gcc dot gnu dot org 2009-02-02 22:00
---
As I understand it, the complaint here is that GCC_EXEC_PREFIX being set
affects HOSTCC, when HOSTCC is itself some other GCC.
But, we have to make sure that the newly built compiler searches the right
--- Comment #6 from jv244 at cam dot ac dot uk 2009-02-02 11:09 ---
(In reply to comment #5)
The generated unwind info looks good to me, so it is likely a gdb issue.
1) how does one get this generated unwind info (I'd like to see what is
different from 4.3)?
2) Do you see a way to
--- Comment #2 from falk at debian dot org 2009-02-02 19:02 ---
No problem with the trunk, but it's still there in the 4.3 branch.
Here's a test case. Requires -funroll-loops -Os, no problem with any other -O,
or without -funroll-loops, curiously.
int f(int x, int y) {
int bytes
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |middle-end
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-02 14:03 ---
We could for example warn for
/* { dg-do compile } */
/* { dg-options -O -Wuninitialized } */
int i;
int __attribute((const,noinline))
foo (int **p)
{
return i;
}
int bar(int *q)
{
int *p;
*q = 0;
int j =
x86-64 psABI says:
The 64-bit mantissa of arguments of type {long double
belongs to class X87, the 16-bit exponent plus 6 bytes of padding
belongs to class X87UP.
...
If one of the classes is X87, X87UP, COMPLEX\_X87 class,
MEMORY is used as class.
But I got
[...@gnu-6 avx-abi]$ cat u4.i
--- Comment #8 from jv244 at cam dot ac dot uk 2009-02-02 12:14 ---
(In reply to comment #7)
2) report this to gdb and help them fix it.
OK, I've at least been able to add a PR for this in the gdb bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=9806
--
--- Comment #1 from s dot gesemann at gmail dot com 2009-02-02 15:18
---
This is probably just another manifestation of the same bug (#36744)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39050
--- Comment #11 from sje at cup dot hp dot com 2009-02-02 16:27 ---
Has anyone tested the patch in comment #9. I didn't test it with bash but I
did test it with Python (PR 38292) because I was looking at that bug and it
seemed to fix the problem.
--
sje at cup dot hp dot com
--- Comment #1 from comer352l at googlemail dot com 2009-02-02 16:22
---
Created an attachment (id=17229)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17229action=view)
Preprocessed file (created with gcc4.3.2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-02 11:18 ---
I think this depends on whether we want as an exception allow this or not.
If not, e.g.:
--- typeck2.c.jj22009-01-13 18:32:14.0 +0100
+++ typeck2.c2009-02-02 12:15:58.0 +0100
@@ -789,7 +789,8 @@
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-02 10:24 ---
Nice testcase from PR38503:
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
struct Y {
Y() {}
int i;
};
struct X {
X() {}
void construct(const Y y)
{
new (m_data[0])
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-02 14:07 ---
Created an attachment (id=17227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17227action=view)
patch to warn about uninitialized pointer dereferences
This patch causes a warning for both testcases, the
--- Comment #3 from sezeroz at gmail dot com 2009-02-02 22:59 ---
(In reply to comment #2)
You should put the new code in a #ifdef HAVE_STDINT and use the old code
otherwise. Else, any platforms without stdint.h would not compile.
I would do that and it would be easy, but then one
--- Comment #4 from bje at gcc dot gnu dot org 2009-02-02 23:03 ---
Subject: Bug 39034
Author: bje
Date: Mon Feb 2 23:03:20 2009
New Revision: 143884
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143884
Log:
PR c/39034
* gcc.dg/dfp/pr39034.c: New test.
Added:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-02 14:55 ---
Err, it seems at least the x86_64 ABI guarantees alignment of 16 bytes for
arrays bigger than 16 bytes (including variable length arrays).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2009-02-02 09:45 ---
Hmm, maybe this is only a gdb bug / missing feature.
$ gfortran-4.4 -O0 -g aaa.f90
$ idbc a.out
Intel(R) Debugger for applications running on Intel(R) 64, Version 11.1 Beta,
Build [1.2097.2.21]
[...]
(idb) b 6
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-02 10:19
---
Ok Mark, agreed, thanks. For the moment, I'm not going to work on this one and
I'm unassigning myself in order not to prevent anyone else quicker than me...
--
paolo dot carlini at oracle dot com changed:
Source file:
file test.c
===
#define __NR_close 2
#define CLOBBER_LIST memory, cc, r11, r12, r13, r14, r15, rbx
#define MY_SYSCALL_1(ARG)
\
__extension__ ((
--- Comment #7 from jakub at gcc dot gnu dot org 2009-02-02 11:57 ---
1) eu-readelf -w info. If you don't have elfutils, binutils readelf -wi
generates similar output, though without the indentation, so it is harder to
find out the parent/child/sibling relation between consecutive
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-02 19:02 ---
Jakub's patch looks fine to me.
Benjamin, does you have an opinion about initializer-lists and complex? I
guess the library complex class will accept { real, imag } naturally because it
has a suitable constructor.
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-02-02 16:35
---
try_inline should not recurse when edge is already inlined. The following
patch should fix the problem, I will benchmark it tonight
Index: ipa-inline.c
The example attached is a simple data-container-class. The data is stored as
Qt4-QStringLists.
Everything was fine with gcc 4.1 (330KB). 4.2 already caused a significant
increase. With 4.3, the binary size increased enormously again (6.7MB !).
When I disable GCSE-optimization using the additional
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-02 10:06 ---
I think the bug is in check_asm_operands/asm_operand_ok.
The latter has:
case '0': case '1': case '2': case '3': case '4':
case '5': case '6': case '7': case '8': case '9':
/* For best
--- Comment #1 from ro at gcc dot gnu dot org 2009-02-02 23:43 ---
It turns out that there are two problems here:
* If you invoke cc1 conftest.c (i.e. without -quiet), you get the ICE from the
assertion failure in c-decl.c:6225:
/* This is the earliest point at which we might know
--- Comment #14 from av1474 at comtv dot ru 2009-02-02 23:44 ---
(In reply to comment #8)
Please provide a preprocessed reduced testcase as similar to the original as
possible.
I think this is not only predicated PHI but our representation of loops may
also have something to do.
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-02-02 23:46
---
Looks indeed like a duplicate.
I can reproduce the bug with GCC 4.4-20090123, but not with GCC 4.4-20090131.
*** This bug has been marked as a duplicate of 38926 ***
--
reichelt at gcc dot gnu dot org
--- Comment #11 from reichelt at gcc dot gnu dot org 2009-02-02 23:46
---
*** Bug 39017 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from manu at gcc dot gnu dot org 2009-02-03 00:27 ---
(In reply to comment #14)
I'm not sure whether following warrants a new bug entry so doing it here,
sorry,
if it was inappropriate.
That is a different case. This PR is about loops. Your case is about
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-03
02:02 ---
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -quiet -v -D__CYGWIN32__
-D__CYGWIN__ -Dunix -
D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -i
--- Comment #4 from schaub-johannes at web dot de 2009-02-03 02:02 ---
Yes, sorry for not mentioning it. I also think the code is valid. In the link
to stackoverflow.com, where i answered that guys question, i gave reasons why i
think so. Next time i will put what i think about that
appears to be similar to reported bug against 4.3.2
--
Summary: stage 3 libgfortran build fails
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo:
--- Comment #1 from tony_eckert at umsl dot edu 2009-02-03 04:33 ---
appears similar to bug 37865, but without --enable-intermodule.
Only departure from defaults is --prefix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
Sent from my iPhone
On Feb 2, 2009, at 8:33 PM, tony_eckert at umsl dot edu gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from tony_eckert at umsl dot edu 2009-02-03
04:33 ---
appears similar to bug 37865, but without --enable-intermodule.
Only departure from defaults is
--- Comment #2 from pinskia at gmail dot com 2009-02-03 04:35 ---
Subject: Re: stage 3 libgfortran build fails
Sent from my iPhone
On Feb 2, 2009, at 8:33 PM, tony_eckert at umsl dot edu
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from tony_eckert at umsl dot edu
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-02-03 04:43
---
I believe gfortran is correct as far as giving an error. The last logical
value does not begin with a T(t) or F(f).
On the commented out case gfortran agrees with g77. The string has one extra
space in it so
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-02-03 07:12
---
The ICE reappeared on the trunk:
bug.c:5: internal compiler error: output_operand: floating constant misused
Please submit a full bug report, [etc.]
Jakub, this was probably caused by your the patch for PR39058.
79 matches
Mail list logo
