--- Comment #2 from kargl at gcc dot gnu dot org 2009-12-29 19:57 ---
(In reply to comment #1)
(In reply to comment #0)
I have not checked for the other issues reported in the thread such as
writing
NUL ('\0') characters instead of spaces ( ). The issue is allegedly
related
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-29 20:19 ---
The commit in comment #2 contains the patch in comment #1 and disables
recursion checking if -fopenmp is given.
In the long run, the checking should be modified so that it can work with
multiple threads. It has been
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-12-29 20:21
---
Patch for current trunk:
Index: gcc/config/i386/i386.h
===
--- gcc/config/i386/i386.h (revision 155505)
+++ gcc/config/i386/i386.h
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-29 20:48 ---
-ftree-vectorize -msse4 works fine since it generates pmaxud in SSE4.1.
It seems that gcc doesn't properly emulate pmaxud.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
--- Comment #6 from hjl dot tools at gmail dot com 2009-12-29 20:52 ---
The bug may be in umaxv4si3 pattern.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2009-12-29 21:34
---
This is not a Fortran issue, but a generic Darwin issue:
$ cat a.c
int x[999] = { 0 };
$ gcc -c a.c ll a.o
-rw-r--r-- 1 fx wheel38M Dec 29 22:32 a.o
On Linux, for example, we don't get such a large
--- Comment #7 from hjl dot tools at gmail dot com 2009-12-29 21:40 ---
Here is a testcase in C:
[...@gnu-6 tmp]$ cat y.c
unsigned int foo[] __attribute__ ((aligned(16))) =
{
0x8000, 1, 0xa000, 2,
3, 0xd000, 0xf000, 0xe000
};
unsigned int bar[] __attribute__
--- Comment #21 from joseph at codesourcery dot com 2009-12-29 21:44
---
Subject: Re: gcc 4.4.0 error at postreload.c:396
On Tue, 29 Dec 2009, bonzini at gnu dot org wrote:
True, it is P5 but it is not invalid. Andreas, if you want to close this as
invalid you should first follow
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36903
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2009-12-29 21:51
---
Confirming this as generic, non Darwin-specific bug. On i686-linux with current
trunk:
$ cat a.c
#include stdio.h
#include math.h
#include fenv.h
main()
{
unsigned flags;
feclearexcept(FE_ALL_EXCEPT);
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-29 22:08 ---
See also
http://groups.google.com/group/comp.lang.fortran/msg/08e908ae0bdab026
http://groups.google.com/group/comp.lang.fortran/msg/fa62b76f8ef39b83
for other things which could be changed in the manual
--
--- Comment #8 from echristo at apple dot com 2009-12-29 22:21 ---
That patch looks correct for at least x86-32
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
--- Comment #2 from sergei dot yakovlev at gmail dot com 2009-12-29 22:22
---
@fxcoudert: This is not an enhancement, this is a bug. Objective-C is declared
as a strict superset of C. Everything that works in C should work in
Objective-C. In this case, it doesn't, which means it's a
[forwarded from http://bugs.debian.org/560812]
With the following simple test file, the 3DNow! generated code is
incorrect, with final _m_pfsub generated as pfsubr %mm0,%mm0, thus
producing completely incorrect result.
seen with current branches and trunk.
Matthias
*** main.c
#include
--- Comment #14 from mikpe at it dot uu dot se 2009-12-29 23:15 ---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01192.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
--- Comment #8 from castet dot matthieu at free dot fr 2009-12-29 23:20
---
What's the status of this bug ?
The same things can happen in libraries with fpic
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-29 23:21 ---
This looks like a DUP of PR29274.
*** This bug has been marked as a duplicate of 29274 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ramana at gcc dot gnu dot org 2009-12-29 23:21 ---
*** Bug 42498 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-29
23:37 ---
(In reply to comment #8)
--build=xxx means you're using a xxx compiler to build. Since you apparently
don't have a x86_64 compiler at hand but only a i386, you cannot do that.
You first need to build
--- Comment #8 from hjl dot tools at gmail dot com 2009-12-29 23:50 ---
Created an attachment (id=19420)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19420action=view)
A patch
I don't see how we can easily check unsigned underflow in vector
integer subtraction. This patch simply
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-12-29
23:51 ---
not reproducible anymore with 4.4.2 and current 4.5.0
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29
23:54 ---
wouldn't it be better to deprecate the -V switch altogether?
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-30 00:03 ---
(In reply to comment #1)
wouldn't it be better to deprecate the -V switch altogether?
Well it works on the trunk ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-30 00:07 ---
(In reply to comment #2)
(In reply to comment #1)
wouldn't it be better to deprecate the -V switch altogether?
Well it works on the trunk ...
I am wrong. And it is useful thing for GCC developers really.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-30 00:08 ---
What architecture options are you using ? With .ident GCC: (GNU)
4.5.0 20091229 (experimental) and -O2 I get the redundant move into r4 of sp .
But for -Os I get the following very different code. I
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-30 00:10 ---
(In reply to comment #1)
What architecture options are you using ? With .ident GCC: (GNU)
4.5.0 20091229 (experimental) and -O2 I get the redundant move into r4 of sp
.
But for -Os I get
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-30 00:19 ---
This appears to be a 4.4 only size regression and this appears to be fixed on
trunk.
With -Os -march=armv5te -mthumb size is 44 bytes on trunk as of today. gcc
version 4.5.0 20091229 (experimental) (GCC
--- Comment #7 from burnus at gcc dot gnu dot org 2009-12-30 00:20 ---
Created an attachment (id=19421)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19421action=view)
Patch
- Nullifies local variables
- Fixes double-allocation check in ALLOCATE statement
TODO:
- INTENT(OUT)
--- Comment #10 from kargl at gcc dot gnu dot org 2009-12-30 00:33 ---
(In reply to comment #9)
Some addition information from valgrind.
Error: Different shape for array assignment at (1) on dimension 1 (0 and 2)
==13911== Invalid read of size 8
==13911==at 0x1C108F8:
not seen on trunk, 4.4 branch prints an error message, 4.3 ICEs:
$ cat myProg.f95
PROGRAM myProg
REAL :: sqrt2 = 2**0.5
PRINT*, sqrt2
END PROGRAM myProg
$ gfortran-4.3 myProg.f95
myProg.f95: In function 'myprog':
myProg.f95:1: internal compiler error: in gfc_conv_constant, at
--- Comment #11 from kargl at gcc dot gnu dot org 2009-12-30 00:44 ---
The following patch cures the segfault but it sure feels like an ugly hack.
Note cut-n-paste tab corruption is likely.
troutmask:sgk[212] svn diff interface.c
Index: interface.c
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-30 00:46 ---
(In reply to comment #4)
No, I didn't build this compiler version; this is what I got when I
reinstalled CygWin from scratch on 11/29/2009. I tried to install the latest
version before
sending this, but all I
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-30 00:54 ---
Confirmed for 4.4.3 (20091229).
If sqrt2 is marked as PARAMETER, both 4.3.4 and 4.4.3 accept the code without
further problems.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from kargl at gcc dot gnu dot org 2009-12-30 00:55 ---
Code compiles fine on trunk, and a sensible error is emitted
when compiled with -std=f95.
troutmask:sgk[215] cat we.f90
PROGRAM myProg
REAL :: sqrt2 = 2**0.5
PRINT*, sqrt2
END PROGRAM myProg
troutmask:sgk[216]
--- Comment #3 from kargl at gcc dot gnu dot org 2009-12-30 00:59 ---
Note comment #16 from PR 38823.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42550
--- Comment #20 from debian-gcc at lists dot debian dot org 2009-12-30
01:00 ---
reconfirmed with 4.5 20091228. please could somebody update the Known to fail
field?
Matthias
$ /usr/lib/gcc-snapshot/bin/gcc foo.m
foo.m: In function 'main':
foo.m:15:18: internal compiler error: in
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-30 01:21
---
Matthias, please apply your doc patchlet, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
--- Comment #21 from paolo dot carlini at oracle dot com 2009-12-30 01:25
---
Done (I'm trusting you blindly)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from manu at gcc dot gnu dot org 2009-12-30 01:43 ---
(In reply to comment #8)
So the answer is that Clang also warns. I was wondering whether the minimal ccp
propagation that Clang does in the front-end would catch this. I guess the
answer is no.
As for GCC, the
--- Comment #10 from sabre at nondot dot org 2009-12-30 01:46 ---
Yes, clang warns:
$ clang t.c
t.c:7:1: warning: control may reach end of non-void function [-Wreturn-type]
}
^
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
--- Comment #28 from manu at gcc dot gnu dot org 2009-12-30 01:49 ---
Seems to be working according to the original specification (in particular
points 1 and 2). The debian bug report is still closed as fixed.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-30 02:01
---
Matthias, sorry, please apply only the first hunk, I'm applying momentarily the
patch from Ed fixing the second issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-12-30 02:03
---
Confirmed, this is very interesting.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mckelvey at maskull dot com 2009-12-30 02:28 ---
Here's what I get in the debugger with -v:
(gdb) run -B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/
-B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/include -isystem
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-12-30 02:37
---
Closing as invalid. See the STOP statement at the end of the writeit
subroutine. Gads!
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fang at csl dot cornell dot edu 2009-12-30 03:57
---
Also fails with g++-4.0.1 and g++-4.2.1 (i686-darwin10).
g++-3.4.6 rejects the example:
error: invalid type qualifier for non-member function type
--
fang at csl dot cornell dot edu changed:
What
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-30
04:14 ---
Appending -gno-strict-dwarf to the dg-options doesn't change the assembly
generated on x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
--- Comment #10 from bdavis at gcc dot gnu dot org 2009-12-30 04:25 ---
let's give this a try:
Index: gcc/gcc/testsuite/gfortran.dg/fmt_with_extra.f
===
--- gcc/gcc/testsuite/gfortran.dg/fmt_with_extra.f (revision
): Don't shift HOST_WIDE_INT value more
than HOST_BITS_PER_WIDE_INT.
testsuite/:
PR middle-end/42099
* gcc.c-torture/execute/20091229-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20091229-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
--- Comment #9 from hjl dot tools at gmail dot com 2009-12-30 04:47 ---
Hi Richard, the code in question is added by
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02185.html
I don't quite understand how it can properly handle unsigned V4SI
underflow in V4SI vector subtraction.
--
--- Comment #10 from hjl dot tools at gmail dot com 2009-12-30 04:49
---
Created an attachment (id=19422)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19422action=view)
An updated patch
I am testing this patch now.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #11 from bdavis at gcc dot gnu dot org 2009-12-30 05:23 ---
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01200.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
--- Comment #3 from carrot at google dot com 2009-12-30 06:46 ---
My complete command line:
/home/carrot/compiler/armobj/gcc/cc1plus -fpreprocessed testH.ii -quiet
-dumpbase testH.cpp -auxbase-strip obj/./testH.o -Os -o testH.s
Please compile it as C++ program. When I compiled it as C
--- Comment #2 from fierevere at ya dot ru 2009-12-30 07:12 ---
Created an attachment (id=19423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19423action=view)
preprocessed source (gzipped)
to trigger ICE compile with:
g++ -mmmx -msse2 -march=pentium-m -mfpmath=sse -g0
--- Comment #5 from ian at airs dot com 2009-12-30 07:24 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
101 - 159 of 159 matches
Mail list logo
