[Bug tree-optimization/35821] Internal compiler error: segmentation fault
--- 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 (working copy)
@@ -1102,8 +1103,12 @@ vect_create_data_ref_ptr (tree stmt, str
new_temp = vect_create_addr_base_for_vector_ref (stmt, &new_stmt_list,
offset, loop);
pe = loop_preheader_edge (loop);
- new_bb = bsi_insert_on_edge_immediate (pe, new_stmt_list);
- gcc_assert (!new_bb);
+ if (new_stmt_list)
+{
+ new_bb = bsi_insert_on_edge_immediate (pe, new_stmt_list);
+ gcc_assert (!new_bb);
+}
+
*initial_address = new_temp;
/* Create: p = (vectype *) initial_base */
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-04-07 07:06:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35821
[Bug middle-end/35856] New: Wrong CCP -- yielding wrong results at O1 and above
// 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 = 1;
g = 0;
foo(-1,-1,&flag);
printf("g = %d \n",g );
return g;
}
--
Summary: Wrong CCP -- yielding wrong results at O1 and above
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
Re: [Bug middle-end/35856] 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 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 and j is less than zero which is true in this case.
#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 = 1;
g = 0;
foo(-1,-1,&flag);
printf("g = %d \n",g );
return g;
}
--
Summary: Wrong CCP -- yielding wrong results at O1 and above
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
[Bug middle-end/35856] Wrong CCP -- yielding wrong results at O1 and above
--- 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 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 and j is less than zero which is true in this case.
>
>
> #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 = 1;
> g = 0;
>
> foo(-1,-1,&flag);
>
> printf("g = %d \n",g );
>
> return g;
> }
>
>
> --
> Summary: Wrong CCP -- yielding wrong results at O1 and above
> Product: gcc
> Version: 4.4.0
>Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: middle-end
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: xinliangli at gmail dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
[Bug middle-end/35856] Wrong CCP -- yielding wrong results at O1 and above
--- 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 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 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 and j is less than zero which is true in this case.
>
> >
> >
> > #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 = 1;
> > g = 0;
> >
> > foo(-1,-1,&flag);
> >
> > printf("g = %d \n",g );
> >
> > return g;
> > }
> >
> >
> > --
> > Summary: Wrong CCP -- yielding wrong results at O1 and above
> > Product: gcc
> > Version: 4.4.0
> >Status: UNCONFIRMED
> > Severity: normal
> > Priority: P3
> > Component: middle-end
> >AssignedTo: unassigned at gcc dot gnu dot org
> >ReportedBy: xinliangli at gmail dot com
> >
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
> >
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
[Bug middle-end/35856] missing unitialized variable warning
--- 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 |Added Summary|Wrong CCP -- yielding wrong |missing unitialized variable |results at O1 and above |warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()
--- 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]> * include/parallel/multiway_merge.h: Moved decisions to compiletime instead of runtime. * include/parallel/losertree.h: Removed obsolete variants, added variant that uses pointers in the loser tree. * include/parallel/types.h: Remove obsolete settings options from enum. * include/parallel/features.h: Remove obsolete compile-time switches. * include/parallel/compiletime_settings.h: Remove obsolete variant that copies back *after* sorting. * include/parallel/tags.h: Add one new tag for compile-time switch. * include/parallel/merge.h: Adapt to changes in multiway_merge.h. * include/parallel/multiway_mergesort.h: Adapt to changes in multiway_merge.h. Factor out splitting variants. Remove obsolete variant that copies back *after* sorting. * include/parallel/sort.h: Adapt to changes in multiway_mergesort.h. * testsuite/25_algorithms/sort/35588.cc: Added test case from / for PR 35588. Added: trunk/libstdc++-v3/testsuite/25_algorithms/sort/35588.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/compiletime_settings.h trunk/libstdc++-v3/include/parallel/features.h trunk/libstdc++-v3/include/parallel/losertree.h trunk/libstdc++-v3/include/parallel/merge.h trunk/libstdc++-v3/include/parallel/multiway_merge.h trunk/libstdc++-v3/include/parallel/multiway_mergesort.h trunk/libstdc++-v3/include/parallel/sort.h trunk/libstdc++-v3/include/parallel/tags.h trunk/libstdc++-v3/include/parallel/types.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35588
[Bug tree-optimization/29751] not optimizing access a[0] , a[1]
--- 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 see a[0] a[1] which it handles fine. It also should handle (*p_2)[0] (*p_2)[1] fine (if you convert p_! to (int *)[] first). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29751
[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
--- 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
[Bug tree-optimization/2480] aliasing problem with global structures
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=2480
[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates
--- 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 place which calls it on TYPE_ATTRIBUTES is instantiate_class_template
on the fn type). So I'm giving up on this.
The patch was:
--- decl2.c.jj 2008-03-25 23:31:25.0 +0100
+++ decl2.c 2008-04-07 12:40:19.0 +0200
@@ -1041,12 +1041,13 @@ is_late_template_attribute (tree attr, t
at instantiation time. */
static tree
-splice_template_attributes (tree *attr_p, tree decl)
+splice_template_attributes (tree *attr_p, tree *type_attr_p, tree decl)
{
tree *p = attr_p;
tree late_attrs = NULL_TREE;
tree *q = &late_attrs;
+ *type_attr_p = NULL_TREE;
if (!p)
return NULL_TREE;
@@ -1054,11 +1055,28 @@ splice_template_attributes (tree *attr_p
{
if (is_late_template_attribute (*p, decl))
{
- ATTR_IS_DEPENDENT (*p) = 1;
- *q = *p;
+ const struct attribute_spec *spec
+ = lookup_attribute_spec (TREE_PURPOSE (*p));
+
+ /* Put attributes that require type into TYPE_ATTRIBUTES,
+rather than DECL_ATTRIBUTES. */
+ if (DECL_P (decl)
+ && spec
+ && spec->type_required
+ && !CLASS_TYPE_P (TREE_TYPE (decl)))
+ {
+ *type_attr_p = *p;
+ type_attr_p = &TREE_CHAIN (*type_attr_p);
+ *type_attr_p = NULL_TREE;
+ }
+ else
+ {
+ ATTR_IS_DEPENDENT (*p) = 1;
+ *q = *p;
+ q = &TREE_CHAIN (*q);
+ *q = NULL_TREE;
+ }
*p = TREE_CHAIN (*p);
- q = &TREE_CHAIN (*q);
- *q = NULL_TREE;
}
else
p = &TREE_CHAIN (*p);
@@ -1071,12 +1089,17 @@ splice_template_attributes (tree *attr_p
DECL_P. */
static void
-save_template_attributes (tree *attr_p, tree *decl_p)
+save_template_attributes (tree *attr_p, tree *decl_p, int flags)
{
- tree late_attrs = splice_template_attributes (attr_p, *decl_p);
+ tree type_attrs;
+ tree late_attrs = splice_template_attributes (attr_p, &type_attrs, *decl_p);
tree *q;
tree old_attrs = NULL_TREE;
+ if (type_attrs)
+cplus_decl_attributes (&TREE_TYPE (*decl_p), type_attrs,
+ flags & ~(int) ATTR_FLAG_TYPE_IN_PLACE);
+
if (!late_attrs)
return;
@@ -1135,7 +1158,7 @@ cplus_decl_attributes (tree *decl, tree
if (check_for_bare_parameter_packs (attributes))
return;
- save_template_attributes (&attributes, decl);
+ save_template_attributes (&attributes, decl, flags);
if (attributes == NULL_TREE)
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
[Bug middle-end/35856] missing unitialized variable warning
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35856
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
--- 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 CC||rguenth at gcc dot gnu dot ||org, dgregor at gcc dot gnu ||dot org Keywords||rejects-valid Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug other/35857] New: --disable-shared doesn't build libgcc_eh.a
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-toolchains. -- Summary: --disable-shared doesn't build libgcc_eh.a Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35857
[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35842
[Bug other/35858] New: time/memory hog for large c++ source.
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 -mtune=pentium4 -O1 -gdwarf-2 -g2 -fPIC -- Summary: time/memory hog for large c++ source. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: i486-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858
[Bug other/35858] time/memory hog for large c++ source.
--- 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
[Bug other/35858] time/memory hog for large c++ source.
--- 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
[Bug other/35858] time/memory hog for large c++ source.
--- 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
[Bug other/35858] time/memory hog for large c++ source.
--- 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
[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode
--- 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 float types for the modified patch. My build of libgfortran on powerpc64-linux succeeds, but I get lots of failures in vect tests. I'll get to this right away. -- janis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-06 19:19:04 |2008-04-07 16:48:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35839
[Bug c++/33486] namespace association doesn't handle parallel namespaces
--- 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?) Yes, only the name-lookup.c change would be necessary. But I'm not the one to ask about fixing it on the 4.3 branch; poke the release managers for permission. It should be quite safe. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
[Bug preprocessor/35859] New: preprocessor segfaults when #include directive passed to macro
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 AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kulhanek dot 5 at wright dot edu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35859
[Bug preprocessor/35859] preprocessor segfaults when #include directive passed to macro
--- 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.h:308, from /usr/include/ctype.h:27, from test.def:2, from test.h:2: g @/inc8 :8404883:10: :0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make: *** [test] Error 1 Build command: gcc --std=c99 -pedantic -E -P -x c test.h An internal compiler error is still reported if -pedantic is removed, but it no longer specifically mentions a segfault. Source files: -test.h--- #define FOO(defs) /* ignored here */ #include "test.def" -- -test.def- FOO( #include ) -- As with removing -pedantic from the build command, combining the two files into one still yields the error, but only when one is #included is the segfault reported. gcc version: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) --- The fact that it's failing to compile is of course the fault of my code. But since it's segfaulting instead of just returning an error message, I thought I'd report it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35859
[Bug other/35858] time/memory hog for large c++ source.
--- 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
[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class
--- 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_constructor): A template counts as a nondefault constructor. Added: trunk/gcc/testsuite/g++.dg/warn/ctor1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35734
[Bug c/35860] New: code bloat caused by -fsplit-wide-types
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, t;
for( t = 0, i = 32; i ; i-- ){
t += t;
if( a & 0x8000UL )
t++;
a += a;
if( t >= b ){
t -= b;
a |= 1;
}
}
*r = t;
return a;
}
//
--
Summary: code bloat caused by -fsplit-wide-types
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot kaiser at gmx dot net
GCC host triplet: winavr 20080402 release
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug target/35860] code bloat caused by -fsplit-wide-types
--- 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 Component|c |target Known to fail|4.3.0 | Known to work|4.1.2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug c/35861] New: code bloat due to -finline-small-functions
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 avr-gcc -Os -fno-inline-small-functions -c rf12.c -- Summary: code bloat due to -finline-small-functions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: a dot kaiser at gmx dot net GCC host triplet: winavr 20080402 release GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35861
[Bug c/35861] code bloat due to -finline-small-functions
--- 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
[Bug middle-end/35861] code bloat due to -finline-small-functions
--- 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 Component|c |middle-end Known to fail|4.3.0 | Known to work|4.1.2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35861
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- 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 a different
number of arguments like "call f(1,2)" without any error message.
In fact this check is currently omitted for any procedure which has the
EXTERNAL attribute (which includes all procedures declared via the
"PROCEDURE()::" statement). But I guess this check should better be omitted
only for procedures which have an implicit interface, right?
This can be cured with the following patch:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 133905)
+++ gcc/fortran/interface.c (working copy)
@@ -2419,8 +2419,7 @@ gfc_procedure_use (gfc_symbol *sym, gfc_
}
}
- if (sym->attr.external
- || sym->attr.if_source == IFSRC_UNKNOWN)
+ if (sym->attr.if_source == IFSRC_UNKNOWN)
{
gfc_actual_arglist *a;
for (a = *ap; a; a = a->next)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/25829] [F2003] Asynchronous IO support
--- 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]> PR fortran/25829 28655 * io/open.c (edit_modes): Set flags.async. (new_unit) Set flags.async and flags.status. (st_open): Initialize flags.async. * io/list_read.c (read_charactor): Use delim_status instead of flags.delim. * io/read.c (read_x): Use pad_status instead of flags.pad. * io/inquire.c (inquire_via_unit): Add new checks. (inquire_via_filename): Likewise. * io/io.h (st_parameter_inquire): Add new flags. (st_parameter_dt): Likewise. * io/unit.c (get_internal_unit): Set flags.async. (init_units): Set flags.async. * io/transfer.c: Add delim and pad option arrays. (read_sf): Use pad_status instead of flags.pad. (read_block): Likewise. (data_transfer_init): Set flags.async and add checks. * io/write.c (write_character): Use delim_status. (list_formatted_write_scalar): Likewise. (nml_write_obj): Likewise. (namelist_write): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/inquire.c trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/open.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/25829] [F2003] Asynchronous IO support
--- 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]> PR fortran/25829 28655 * io.c (io_tag): Add new tags for decimal, encoding, asynchronous, round, sign, and id. (match_open_element): Match new tags. (gfc_resolve_open): Resolve new tags. (gfc_match_open): Enable encoding for DEFAULT only. Update error messages. (match_dt_element): Fix match tag for asynchronous. Update error messages. (gfc_free_inquire): Free new expressions. (match_inquire_element): Match new tags. (gfc_match_inquire): Add constraint for ID and PENDING. (gfc_resolve_inquire): Resolve new tags. * trans-io.c (gfc_trans_inquire): Clean up whitespace and fix setting of mask for ID parameter. * ioparm.def: Fix order of parameters for pending, round, and sign. NOTE: These must line up with the definitions in libgfortran/io/io.h. or things don't work. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/25829] [F2003] Asynchronous IO support
--- 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]> PR fortran/25829 28655 * gfortran.dg/write_check2.f90: Update dg-error. * gfortran.dg/io_constraints_1.f90: Udate dg-error. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/io_constraints_1.f90 trunk/gcc/testsuite/gfortran.dg/write_check2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug middle-end/35861] code bloat due to -finline-small-functions
--- 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/show_bug.cgi?id=35861
[Bug fortran/28655] [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=
--- 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 |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28655
[Bug libfortran/35862] New: [F2003] Implement new rounding modes for run time
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: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
[Bug libfortran/35863] New: [F2003] Implement ENCODING="UTF-8"
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 AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug target/34210] ffs builtin calls undefined __ffshi2
--- 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 (avr-*-*): Add avr cpu_type and avr tmake_file. * config/t-avr: New file. Build 16bit libgcc functions. Added: trunk/libgcc/config/avr/ trunk/libgcc/config/avr/t-avr Modified: trunk/libgcc/ChangeLog trunk/libgcc/config.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34210
[Bug target/35508] [avr] 4.3.0: undefined reference to `__ffshi2'
--- 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 (avr-*-*): Add avr cpu_type and avr tmake_file. * config/t-avr: New file. Build 16bit libgcc functions. Added: trunk/libgcc/config/avr/ trunk/libgcc/config/avr/t-avr Modified: trunk/libgcc/ChangeLog trunk/libgcc/config.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35508
[Bug fortran/35864] New: [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90 for cris-elf
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=0x7fff4d8a3d00) at /home/hp/combh/combined/gcc/fortran/expr.c:227 #2 0x00426f1e in scalarize_intrinsic_call (e=0x103f7b0) at /home/hp/combh/combined/gcc/fortran/expr.c:1827 #3 0x004278c9 in check_init_expr (e=0x103f7b0) at /home/hp/combh/combined/gcc/fortran/expr.c:2204 #4 0x0042705f in check_intrinsic_op (e=0x103f880, check_function=0x427737 ) at /home/hp/combh/combined/gcc/fortran/expr.c:1879 #5 0x00427784 in check_init_expr (e=0x103f880) at /home/hp/combh/combined/gcc/fortran/expr.c:2170 #6 0x00426f79 in check_intrinsic_op (e=0x103f950, check_function=0x427737 ) at /home/hp/combh/combined/gcc/fortran/expr.c:1839 #7 0x00427784 in check_init_expr (e=0x103f950) at /home/hp/combh/combined/gcc/fortran/expr.c:2170 #8 0x00427c07 in gfc_match_init_expr (result=0x7fff4d8a3ed8) at /home/hp/combh/combined/gcc/fortran/expr.c:2341 #9 0x00416429 in variable_decl (elem=1) at /home/hp/combh/combined/gcc/fortran/decl.c:1743 #10 0x00418e93 in gfc_match_data_decl () at /home/hp/combh/combined/gcc/fortran/decl.c:3674 #11 0x0045d5bc in match_word (str=0x0, subr=0x418cd1 , old_locus=0x7fff4d8a3fd0) at /home/hp/combh/combined/gcc/fortran/parse.c:64 #12 0x0045dd3e in decode_statement () at /home/hp/combh/combined/gcc/fortran/parse.c:280 #13 0x0045f0dc in next_free () at /home/hp/combh/combined/gcc/fortran/parse.c:653 #14 0x0045f44e in next_statement () at /home/hp/combh/combined/gcc/fortran/parse.c:830 #15 0x00460b88 in parse_spec (st=ST_NONE) at /home/hp/combh/combined/gcc/fortran/parse.c:2092 #16 0x004625d7 in parse_module () at /home/hp/combh/combined/gcc/fortran/parse.c:3397 #17 0x004629c4 in gfc_parse_file () at /home/hp/combh/combined/gcc/fortran/parse.c:3548 #18 0x00491982 in gfc_be_parse_file (set_yydebug=0) at /home/hp/combh/combined/gcc/fortran/f95-lang.c:258 #19 0x0087151f in compile_file () at /home/hp/combh/combined/gcc/toplev.c:962 #20 0x00873160 in do_compile () at /home/hp/combh/combined/gcc/toplev.c:2163 #21 0x008731c4 in toplev_main (argc=15, argv=0x7fff4d8a4338) at /home/hp/combh/combined/gcc/toplev.c:2195 #22 0x004fca07 in main (argc=15, argv=0x7fff4d8a4338) at /home/hp/combh/combined/gcc/main.c:35 Author of 133965 CC:ed. -- Summary: [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90 for cris-elf Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
Re: gcc-4.3.0 configure can't identify ld 2.18 version
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-help. You can find the code to extract the ld version number in the configure scripts. Try running it by hand to see what happens. Maybe you have a broken sed or awk program installed on your machine. Jim
[Bug target/35695] [4.3 Regression] -funroll-loops breaks inline float divide
--- 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
[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90 for cris-elf
--- 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 133965 I see: > f951: internal compiler error: Segmentation fault > It is not target specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90 for cris-elf
--- 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* that it was... ;) -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-08 00:12:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
[Bug fortran/35865] New: Spurious warning for vector-valued functions passed as arguments
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 problem, but other compilers (G95,Intel) do not produce a warning. The function arguments do match however. I obtained this from "GCC 4.3.0 20080212 (experimental) [trunk revision 132252]" using cygwin under WinXP. !=== module vec_func implicit none contains !=== !=== !function vector_func(func,r1) result(res) function vector_func(func) result(res) implicit none interface function func(r) result(res) implicit none real, intent(in) :: r real :: res(3) end function func end interface real :: res(3) res = func(0.) end function vector_func !== function test_func(r) result(res) implicit none real,intent(in) :: r real :: res(3) res = r end function test_func != end module vec_func != program a use vec_func implicit none real :: z(3) z = vector_func(test_func) print*, z end program a != -- Summary: Spurious warning for vector-valued functions passed as arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot young at jrc dot co dot jp GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35865
[Bug fortran/35865] Spurious warning for vector-valued functions passed as arguments
--- 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?id=35865
[Bug target/35866] New: Vector load/store from a packed struct does not work (without -mstrict-align)
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 in the incorrect
position.
--
Summary: Vector load/store from a packed struct does not work
(without -mstrict-align)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35866
[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)
--- 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 org changed: What|Removed |Added Version|4.3.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35866
[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)
--- 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 mode rather than just true or false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35866
[Bug rtl-optimization/35841] [ira] segfault while building libgcc
--- 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
[Bug target/35867] New: [4.4 Regression]: gcc.target/i386/addr-sel-1.c
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: gcc.target/i386/addr-sel-1.c (test for excess errors) FAIL: gcc.target/i386/addr-sel-1.c scan-assembler a\\+1 FAIL: gcc.target/i386/addr-sel-1.c scan-assembler b\\+1 Revision 133981 is OK. -- Summary: [4.4 Regression]: gcc.target/i386/addr-sel-1.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35867
[Bug target/35867] [4.4 Regression]: gcc.target/i386/addr-sel-1.c
--- 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: What|Removed |Added CC||bergner at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-08 06:37:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35867
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- 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. (commutative_operand_precedence): Give SYMBOL_REF's the same precedence as REG_POINTER and MEM_POINTER operands. * emit-rtl.c (gen_reg_rtx_and_attrs): New function. (set_reg_attrs_from_value): Call mark_reg_pointer as appropriate. * rtl.h (gen_reg_rtx_and_attrs): Add prototype for new function. * gcse.c: Update copyright years. (pre_delete): Call gen_reg_rtx_and_attrs. (hoist_code): Likewise. (build_store_vectors): Likewise. (delete_store): Likewise. * loop-invariant.c (move_invariant_reg): Likewise. Update copyright years. Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c trunk/gcc/gcse.c trunk/gcc/loop-invariant.c trunk/gcc/rtl.h trunk/gcc/rtlanal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- 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: FAIL: gcc.target/i386/addr-sel-1.c scan-assembler a\\+1 FAIL: gcc.target/i386/addr-sel-1.c scan-assembler b\\+1 Tracked in PR 35867. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug target/10768] ICEs on compilation of ada support library for avr
--- 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/10768 * cuintp.c: Fix 16 bits issue for AVR. On AVR, integer is 16 bits, so it can't be used to do math with Base (=32768). So use long_integer instead. Modified: trunk/gcc/ada/cuintp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
