--- Comment #7 from irar at il dot ibm dot com 2008-04-07 07:06 ---
I am testing the following patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 132478)
+++ tree-vect-transform.c (worki
// Test case: should print 0 but it prints 10 when compiled at -O or -O2. The
culprit is very likely ccp1.
#include
int g;
int foo(int i, int j, int* flag)
{
int t;
if (i > 0 || j > 0)
{
t = 10;
*flag = 1;
}
if (*flag)
g+= t;
}
int main()
{
int flag =
Sent from my iPhone
On Apr 7, 2008, at 0:06, "xinliangli at gmail dot com" <[EMAIL PROTECTED]
> wrote:
// Test case: should print 0 but it prints 10 when compiled at -O
or -O2. The
culprit is very likely ccp1.
I don't think it should t used uninitialized if *flag is true and both
I a
--- Comment #1 from pinskia at gmail dot com 2008-04-07 07:10 ---
Subject: Re: New: Wrong CCP -- yielding wrong results at O1 and above
Sent from my iPhone
On Apr 7, 2008, at 0:06, "xinliangli at gmail dot com"
<[EMAIL PROTECTED]
> wrote:
> // Test case: should print 0 but it p
--- Comment #2 from xinliangli at gmail dot com 2008-04-07 07:30 ---
Right, the source is buggy, but looks the compiler misses uninitialized warning
-- with -Wuninitialized -- no warning is given.
(In reply to comment #1)
> Subject: Re: New: Wrong CCP -- yielding wrong results at O1
--- Comment #3 from xinliangli at gmail dot com 2008-04-07 07:39 ---
It is debatable whether the const prop should happen in the presence of
unitilaized variable, but a warning should be given.
--
xinliangli at gmail dot com changed:
What|Removed |
--- Comment #3 from singler at gcc dot gnu dot org 2008-04-07 08:28 ---
Subject: Bug 35588
Author: singler
Date: Mon Apr 7 08:27:34 2008
New Revision: 133975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133975
Log:
2008-04-07 Johannes Singler <[EMAIL PROTECTED]>
*
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-07 08:51 ---
Only if you extend refs_may_alias_p, as for pointers you have
p_2 = p_1 + 1;
*p_2
*p_1
and it doesn't follow def-use chains to see the pointer-plus to disambiguate
both pointer de-references. With arrays you se
--- Comment #8 from oder at eleks dot lviv dot ua 2008-04-07 08:58 ---
Created an attachment (id=15438)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15438&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-04-07 09:00
---
This is because the oracle is confused by the link_error () call which clobbers
*ex2 and *ex1. Note that SCCVN does not consider control-dependence as it
considers all edges executable all the time.
--
http:/
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-07 10:52 ---
I've tried the first step - putting the attributes that require type to
TYPE_ATTRIBUTES rather than DECL_ATTRIBUTES, see below.
Unfortunately tsubst doesn't call apply_late_template_attributes in that case
(the only p
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-07 10:10 ---
It's all optimized away before the may-be-used-uninitialized warning is emitted
(we only execute warn_uninitialized_phi in the late pass).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-07 11:56 ---
Eventually a fallout from rvalue references? CCing Dough.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
i noticed that --disable-shared also disables the libgcc_eh.a
in libgcc/Makefile.in:
(...)
ifeq ($(enable_shared),yes)
all: libgcc_eh.a libgcc_s$(SHLIB_EXT)
ifneq ($(LIBUNWIND),)
all: libunwind$(SHLIB_EXT)
endif
endif
(...)
imho this looks like a bug.
libgcc_eh.a is used with libgcc.a in cross-to
--- Comment #9 from ktietz at gcc dot gnu dot org 2008-04-07 13:35 ---
Committed revision 133981.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
i've checked 4.1 vs 4.3 on my c++ codebase and 4.3 doesn't look good.
more time/mem details are in attached logs.
testcase was compiled with following options:
-m32 -D_STLP_DEBUG -D_STLP_DEBUG_MODE_THROWS -D_DEBUG -pthread \
-Wall -Wno-uninitialized -Woverloaded-virtual -Werror \
-march=i686 -mtu
--- Comment #1 from pluto at agmk dot net 2008-04-07 14:58 ---
Created an attachment (id=15439)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15439&action=view)
4.1 stats.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #2 from pluto at agmk dot net 2008-04-07 14:58 ---
Created an attachment (id=15440)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15440&action=view)
4.3 stats.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #3 from pluto at agmk dot net 2008-04-07 14:59 ---
Created an attachment (id=15441)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15441&action=view)
testcase for 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-07 15:29 ---
Please try --param max-fields-for-field-sensitive=0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #3 from janis at gcc dot gnu dot org 2008-04-07 16:48 ---
Argh, this is an excellent of example of why full testing is necessary for
small changes to a patch that has been fully tested; I thought I could get away
with just bootstrapping C and running tests that use decimal fl
--- Comment #8 from jason at redhat dot com 2008-04-07 17:29 ---
Subject: Re: namespace association doesn't handle parallel
namespaces
bkoz at gcc dot gnu dot org wrote:
> Hey Jason, can we get this fixed on 4_3-branch? (Could probably get away with
> just gcc/cp/name-lookup.c fix, no
Build command: cat M
--
Summary: preprocessor segfaults when #include directive passed to
macro
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: preprocessor
--- Comment #1 from kulhanek dot 5 at wright dot edu 2008-04-07 19:29
---
(oops, hit enter on the wrong screen)
Error message:
In file included from test.h:2:
test.def:2:2: warning: embedding a directive within macro arguments is not
portable
In file included from /usr/include/features
--- Comment #5 from pluto at agmk dot net 2008-04-07 20:25 ---
(In reply to comment #4)
> Please try --param max-fields-for-field-sensitive=0
>
it helps.
TOTAL: 67.59 3.99 71.69 1220782 kB
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
--- Comment #2 from jason at gcc dot gnu dot org 2008-04-07 20:51 ---
Subject: Bug 35734
Author: jason
Date: Mon Apr 7 20:50:21 2008
New Revision: 133987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133987
Log:
PR c++/35734
* class.c (type_has_user_nondefault_
Command:
avr-gcc -O1 -S div32_7.c
or
avr-gcc -O1 -fno-split-wide-types -S div32_7.c
Code size 4.1.2: 0x28
Code size 4.3.0: 0x68
Code size 4.3.0: 0x28 with -fno-split-wide-types
//
unsigned long udivr32_7( unsigned long a, unsigned char b, unsigned char *r )
{
unsigned char i
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-07 21:38 ---
I think this is already fixed on the trunk, fword prop was not proping as much
as it should have.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
In 4.3.0 -finline-small-functions cause excessive code bloat even though
according to the docs this option should not significantly increase code size.
Code size 4.1.2: 0x8A
Code size 4.3.0: 0x1EA
Code size 4.3.0: 0x88 with -fno-inline-small-functions
Command line:
avr-gcc -Os -c rf12.c
or
av
--- Comment #1 from a dot kaiser at gmx dot net 2008-04-07 21:54 ---
Created an attachment (id=15442)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15442&action=view)
sample code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35861
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-07 21:59 ---
I think this is just a miscounting of inline-asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from jaydub66 at gmail dot com 2008-04-07 22:01 ---
Another thing I just noticed is that dummy procedures are currently not checked
for being called with the right arguments (-> compare_actual_formal), e.g. in
the above test case "call f([1,2,3])" could also be called with
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:06
---
Subject: Bug 25829
Author: jvdelisle
Date: Mon Apr 7 22:05:52 2008
New Revision: 133988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133988
Log:
2008-04-07 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:08
---
Subject: Bug 25829
Author: jvdelisle
Date: Mon Apr 7 22:07:44 2008
New Revision: 133989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133989
Log:
2008-04-07 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:11
---
Subject: Bug 25829
Author: jvdelisle
Date: Mon Apr 7 22:10:41 2008
New Revision: 133991
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133991
Log:
2008-04-07 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from a dot kaiser at gmx dot net 2008-04-07 22:14 ---
Created an attachment (id=15443)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15443&action=view)
sample code w/o inline assembly
Same situation when inline asm is removed.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:29
---
Now completed. INQUIRE functions work. Closing this PR will open seorate PRS
for the run time items UTF-8 and ROUNDing modes.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
The front-end parsing and translation are completed. We now need to determine
how to implement UP, DOWN, COMPATIBLE, NEAREST, etc. in output_float.
--
Summary: [F2003] Implement new rounding modes for run time
Product: gcc
Version: 4.4.0
Status: UNCO
Front end and library are ready to handle this when implemented.
--
Summary: [F2003] Implement ENCODING="UTF-8"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
As
--- Comment #7 from hutchinsonandy at gcc dot gnu dot org 2008-04-07 23:16
---
Subject: Bug 34210
Author: hutchinsonandy
Date: Mon Apr 7 23:15:35 2008
New Revision: 133993
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133993
Log:
PR target/34210 PR target/35508 * config.host
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-04-07 23:16
---
Subject: Bug 35508
Author: hutchinsonandy
Date: Mon Apr 7 23:15:35 2008
New Revision: 133993
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133993
Log:
PR target/34210 PR target/35508 * config.host
With r133964, this test passed. With 133965 I see:
f951: internal compiler error: Segmentation fault
Backtrace (f951 recompiled with CFLAGS=-g)
(gdb) bt
#0 splay_tree_delete (sp=0x103f880) at
/home/hp/combh/combined/libiberty/splay-tree.c:67
#1 0x00423c96 in gfc_free_expr (e=0x7fff4d8a3
Yevgeniy Litvinenko wrote:
I've found out that two configure scripts can not determine the linker
version. These scripts are:
gcc-4.3.0/libstdc++-v3/configure
and
gcc-4.3.0/libgomp/configure
We don't track bugs mailed to the gcc-bugs mailing list. File a problem
in bugzilla, or ask on gcc-hel
--- Comment #7 from wilson at gcc dot gnu dot org 2008-04-07 23:48 ---
Anyone care whether this gets fixed in 4.3? If so, are you willing to test it?
I'll approve it for 4.3 with proper testing, which is not easy for me to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
--- Comment #1 from jvdelisle at verizon dot net 2008-04-07 23:49 ---
Subject: Re: New: [4.4 Regression] Revision 133965broke
gfortran.dg/initialization_1.f90 for cris-elf
On Mon, 2008-04-07 at 23:18 +, hp at gcc dot gnu dot org wrote:
> With r133964, this test passed. With
--- Comment #2 from hp at gcc dot gnu dot org 2008-04-08 00:12 ---
(In reply to comment #1)
>
> It is not target specific.
Ah, I was a bit worried that it was. Since the failure had been there all day,
and noone have entered a matching PR or mentioning it on the lists, I just
*assumed
In the code below, the following warning is produced
"Waring: Actual argument contains too few elements for dummy argument 'func'
(1/3) at (1)"
If the function result is changed to a scalar instead of a vector, no warning
is produced. I do not know the standard well enough to know if this is a
p
--- Comment #1 from john dot young at jrc dot co dot jp 2008-04-08 01:42
---
Created an attachment (id=15444)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15444&action=view)
code to produce spurious warning described in bug report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
Testcase:
#define vector __attribute__((vector_size(16) ))
#pragma pack(push, r1, 1)
struct a
{
char t;
vector float f;
};
#pragma pack(push, r1, 1)
vector float f(struct a * b, vector float a)
{
return b->f = a;
}
CUT ---
We use directly a stvx instruction here and this will store i
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-08 02:00 ---
(In reply to comment #0)
> We use directly a stvx instruction here and this will store in the incorrect
> position.
as stvx masks out the lower bits for a 16byte aligned address.
--
pinskia at gcc dot gnu dot or
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-08 02:04 ---
With -mstrict-align, we get the correct (but suboptimal) answer as the
middle-end knows that load and stores cannot handled unaligned addresses.
I think we need more flexible TARGET_STRICT_ALIGN which is based on a
--- Comment #1 from vmakarov at redhat dot com 2008-04-08 02:39 ---
I think the problem has been solved by
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00469.html
I need some time to check it because my sun machine is too slow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35841
With revision134001 , I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.target/i386/addr-sel-1.c -O2
-mtune=i686 -fno-show-column -S -m32 -o addr-sel-1.s(timeout = 300)
PASS: g
--- Comment #1 from ubizjak at gmail dot com 2008-04-08 06:37 ---
Caused by:
http://gcc.gnu.org/viewcvs?view=rev&revision=133985,
this particular change:
http://gcc.gnu.org/viewcvs/trunk/gcc/rtlanal.c?r1=133985&r2=133984&pathrev=133985
--
ubizjak at gmail dot com changed:
--- Comment #47 from ubizjak at gmail dot com 2008-04-08 06:39 ---
Author: bergner
Date: Mon Apr 7 17:36:59 2008
New Revision: 133985
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133985
Log:
PR middle-end/PR28690
* rtlanal.c: Update copyright years.
(co
--- Comment #48 from ubizjak at gmail dot com 2008-04-08 06:43 ---
(In reply to comment #47)
>* rtlanal.c: Update copyright years.
>(commutative_operand_precedence): Give SYMBOL_REF's the same precedence
This change causes regression in i686-pc-linux-gnu testsuite:
FAI
--- Comment #23 from charlet at gcc dot gnu dot org 2008-04-08 06:46
---
Subject: Bug 10768
Author: charlet
Date: Tue Apr 8 06:46:04 2008
New Revision: 134013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134013
Log:
2008-04-08 Tristan Gingold <[EMAIL PROTECTED]>
PR ada/10
57 matches
Mail list logo
