--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-19 06:40 ---
Mine. Patch: http://gcc.gnu.org/ml/fortran/2010-06/msg00199.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from andi-gcc at firstfloor dot org 2010-06-19 07:39
---
Technically I would say it was a kernel bug.
gcc can't really know how many instructions are there inside inline asm
so it's probably very conservative in its estimation.
So I would recommend to close it.
Follow up to PR 44582
No warning is printed for the following program. Expected:
a) A warning about the unset return value
b) A warning about using the variable uninitialized.
There are two issues:
a) It should be found by the front end
b) It should be found by the middle end. The reason that
--- Comment #6 from burnus at gcc dot gnu dot org 2010-06-19 09:47 ---
(In reply to comment #0)
the function with array return must create a temporary array to hold the
returned value and transfer the value to destination array after function
call.
gfortran returns 5.0
it should
--- Comment #1 from kkojima at gcc dot gnu dot org 2010-06-19 09:50 ---
I can't reproduce it on my i686-pc-linux-gnu host with
a similar configuration
/home/kkojima/kaz/xsh-elf-combined-450/combined/configure
--target=sh-unknown-elf --disable-libmudflap --disable-libssp
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-06-19 10:37
---
GCC improved estimation of asm size from all-asms-are-size-1 we did in 4.4
to count the number of lines estimate that is also used by RTL optimizers.
--
rguenth at gcc dot gnu dot org changed:
What
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-19 10:39 ---
Likely mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Revision 159362 caused the following failures of the libstdc++-v3
testsuite on powerpc-apple-darwin9 and x86_64-apple-darwin10:
FAIL: 27_io/basic_stringbuf/in_avail/char/1.cc (test for excess errors)
FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors)
FAIL:
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-19 10:58 ---
Bah - gigantic testcases.
And maybe not mine (I tought r160903 is the cause). But the testcase
do not even run into gimplify_modify_expr_complex_part. And I do not
see any references to uninitialized data in the
--- Comment #30 from armin76 at gentoo dot org 2010-06-19 11:31 ---
So...? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #21 from andi-gcc at firstfloor dot org 2010-06-19 12:23
---
This is the inline (after preprocessor)
I guess the many asm meta commands confuse the heuristic. Maybe it could
be fixed to ignore such commands.
static inline void rdtsc_barrier(void)
{
asm volatile
--- Comment #7 from pault at gcc dot gnu dot org 2010-06-19 12:30 ---
(In reply to comment #6)
The program below should print twice 10 10 10 10 10 but due to the bug, it
prints zeros for the first print and the tens only for the second print
Yes, indeed. This goes back to gcc-4.3
--- Comment #10 from sandra at codesourcery dot com 2010-06-19 12:56
---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01920.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-06-19 12:58
---
(In reply to comment #21)
This is the inline (after preprocessor)
I guess the many asm meta commands confuse the heuristic. Maybe it could
be fixed to ignore such commands.
static inline void
--- Comment #23 from andi-gcc at firstfloor dot org 2010-06-19 13:13
---
It's two instructions with some metadata that controls patching these
instructions depending on the CPU capabilities.
Detecting that for gcc would be likely hard.
What would have also prevented this problem
--- Comment #8 from pault at gcc dot gnu dot org 2010-06-19 14:55 ---
Created an attachment (id=20942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20942action=view)
Fix for PR, with testcase
This is less restrictive than requiring pure functions but is still correct, I
believe.
--- Comment #2 from ljsebald at gmail dot com 2010-06-19 15:58 ---
Judging by what I see from my gcc/tm.h file, I'm guessing it might well be a
host-specific problem (I'm on x86_64-apple-darwin10.3.1). Here's the start of
my gcc/tm.h file:
#ifndef GCC_TM_H
#define GCC_TM_H
#define
--- Comment #9 from pault at gcc dot gnu dot org 2010-06-19 16:42 ---
(In reply to comment #8)
Created an attachment (id=20942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20942action=view) [edit]
Tobias correctly points out various cases that are still not correct.
It looks
FAIL: gcc.dg/guality/pr41404-1.c -O1 line 10 *foo == 'f'
FAIL: gcc.dg/guality/pr41404-1.c -O2 line 10 *foo == 'f'
FAIL: gcc.dg/guality/pr41404-1.c -Os line 10 *foo == 'f'
FAIL: gcc.dg/guality/pr41404-1.c -O2 -flto line 10 *foo == 'f'
FAIL: gcc.dg/guality/pr41404-1.c -O2 -fwhopr line 10
The following code is miscompiled at -O3 with trunk and 4.5.0:
! From forall_12.f90
! Fails with loop reversal at -O3
!
character(len=1) :: b(4) = (/1,2,3,4/), c(4)
c = b
i = 1
! This statement must be here for the abort below
b(1:3)(i:i) = b(2:4)(i:i)
b = c
b(4:2:-1)(i:i) =
FAIL: gcc.dg/guality/pr43479.c -O1 line 13 h == 9
FAIL: gcc.dg/guality/pr43479.c -O2 line 13 h == 9
FAIL: gcc.dg/guality/pr43479.c -O3 -fomit-frame-pointer line 13 h == 9
FAIL: gcc.dg/guality/pr43479.c -O3 -g line 13 h == 9
FAIL: gcc.dg/guality/pr43479.c -Os line 13 h == 9
FAIL:
--- Comment #2 from ubizjak at gmail dot com 2010-06-19 17:23 ---
Confirmed with 4.4. This is fixed in 4.5, so 4.5 and 4.6 work OK.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from danglin at gcc dot gnu dot org 2010-06-19 17:24 ---
Spawning: gdb -nx -nw -quiet -x pr41404-1.gdb ./pr41404-1.exe
Reading symbols from
/home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gcc/pr41404-1.e
xe...done.
Breakpoint 1 at 0x104f4: file
FAIL: gcc.dg/guality/vla-1.c -O0 line 17 sizeof (a) == 6
FAIL: gcc.dg/guality/vla-1.c -O0 line 24 sizeof (a) == 17 * sizeof (short)
FAIL: gcc.dg/guality/vla-1.c -O1 line 17 i == 5
FAIL: gcc.dg/guality/vla-1.c -O1 line 17 sizeof (a) == 6
FAIL: gcc.dg/guality/vla-1.c -O1 line 24 i == 5
gfortran compiles the following code
subroutine reset_seed(iseed)
implicit none
integer, intent(in) :: iseed
call random_seed(iseed)
end subroutine reset_seed
SIZE (optional) shall be scalar and of type default integer.
It is an INTENT (OUT) argument. It is assigned
--- Comment #4 from mikpe at it dot uu dot se 2010-06-19 17:56 ---
I my earlier tests I failed to notice that this test case triggers one of two
different ICEs, depending on options and compiler version. I also mistakenly
tested with a locally modified gcc-4.4.
The ICE in this PR, in
--- Comment #6 from danglin at gcc dot gnu dot org 2010-06-19 18:25 ---
Subject: Bug 44261
Author: danglin
Date: Sat Jun 19 18:25:28 2010
New Revision: 161034
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161034
Log:
Backport from mainline
2010-05-29 John David
--- Comment #7 from danglin at gcc dot gnu dot org 2010-06-19 18:28 ---
Subject: Bug 44261
Author: danglin
Date: Sat Jun 19 18:28:28 2010
New Revision: 161035
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161035
Log:
Backport from mainline
2010-05-29 John David
--- Comment #1 from danglin at gcc dot gnu dot org 2010-06-19 18:40 ---
Fails for similar reasons on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-19 19:03 ---
Created an attachment (id=20943)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20943action=view)
An updated patch
8bit divide is AX / r/m8. Here is the updated patch.
Now it generates:
foo:
.LFB0:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44195
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|rguenther at suse dot de|rguenth at gcc dot gnu dot
|
On mem-ref2 branch gfortran.dg/dynamic_dispatch_6.f03 is miscompiled due
to TBAA issues as the Frontend uses two completely unrelated structure
types to access the same vtable pointer.
That of course can't work.
--
Summary: Dynamic dispatch uses broken types
Product: gcc
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-19 19:16 ---
static struct vtype$periodic_5th_factory vtab$periodic_5th_factory =
{.$hash=9935896, .$size=0, .$extends=vtab$field_factory};
...
if (vtab$periodic_5th_factory.create == 0B)
{
--- Comment #4 from danglin at gcc dot gnu dot org 2010-06-19 19:34 ---
Still fails.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-06-19 19:57
---
I'm working on this bug among other improvements to RTL hoist pass.
My plan is to enable hoisting of such simple constants, but only on very short
distances, like 3-5 instructions, tunable through a new
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/builtin-prefetch-2.c -w
-O1
-lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/builtin-prefetch-2.x1
(tim
eout = 300)
gcc-trunk rev. 161008
# cat 2010_06_19.c
static const char x[] = ;
static const char* b = ;
# gcc -Wall -c 2010_06_19.c
2010_06_19.c:2:20: warning: b defined but not used [-Wunused-variable]
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-06-19 23:00
---
Subject: Bug 44072
Author: rearnsha
Date: Sat Jun 19 23:00:31 2010
New Revision: 161040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161040
Log:
PR target/44072
* arm.md (cmpsi2_addneg):
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-06-19 23:18
---
Fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
the following program with a very basic recurring template compiles with no
message but only return the expected value zero when using g++ -O optimize
option
the output of g++ -v -save-temps follows the source file bug_report.cpp
the preprocessed file bug_report.ii is at the end of this report
--- Comment #179 from schaub-johannes at web dot de 2010-06-20 00:01
---
(In reply to comment #158)
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de gcc-bugzi...@gcc.gnu.org writes:
[...]
| Now,
--- Comment #7 from janus at gcc dot gnu dot org 2010-06-20 00:06 ---
Subject: Bug 44584
Author: janus
Date: Sun Jun 20 00:05:35 2010
New Revision: 161041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161041
Log:
2010-06-19 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-20 00:12 ---
(In reply to comment #6)
It will be while before I can check it on ia64. However if your patch fixes
valgrind issue on x86, it won't hurt to check it in. Thanks.
Ok, the patch has landed on trunk. Please let me
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-20 00:37 ---
Well I think this is on purpose really. In the array case, we can inline the
value while in the other case, b itself is not const so it can be changed; that
is be assigned to in normal code.
--
Various warnings about possibly uninitialized locals.
../../gcc-4.5/gcc/ira-conflicts.c -o ira-conflicts.o
../../gcc-4.5/gcc/ira-conflicts.c: In function print_conflicts:
../../gcc-4.5/gcc/ira-conflicts.c:698: warning: conflict_a may be used
uninitialized in this function
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-20 01:02 ---
I think this code is undefined as the type of this at the point which getI is
called is only InterfaceS* and not S* as f takes a non pointer/reference type
of InterfaceC.
--
--- Comment #2 from gcc at razorcam dot com 2010-06-20 01:37 ---
Thanks. Yes, using obj does work.
Sorry for this bug report from me.
Bug resolved: invalid.
--
gcc at razorcam dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-20 01:59 ---
Created an attachment (id=20944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20944action=view)
Another update
This patch removes EFLAGS clobber for sign extend.
--
hjl dot tools at gmail dot com changed:
--- Comment #20 from rob1weld at aol dot com 2010-06-20 02:05 ---
(In reply to comment #16)
Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9.
Thanks for looking into this,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #2 from rob1weld at aol dot com 2010-06-20 02:10 ---
(In reply to comment #1)
Fails on 64-bit Solaris 10, 11/SPARC, too.
Tossing Regression onto the Summary, thanks for confirming,
Rob
--
rob1weld at aol dot com changed:
What|Removed
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-20 03:53 ---
Update the summary.
AFAICT, for intrinsics procedure that specify an INTENT for its
arguments, the INTENT isn't checked.
Sigh. This is opening a can of worms. More later. :(
--
kargl at gcc dot gnu dot org
--- Comment #3 from lists at eitanadler dot com 2010-06-20 04:51 ---
Is there any more information I could provide to help diagnose the issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44573
55 matches
Mail list logo
