[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert
-- rwild at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 06:03:08 date|| Summary|gcc.misc-tests/help.exp |gcc.misc-tests/help.exp |doesn't work when configured|doesn't work when configured |with --enable- |with --enable- |checking=assert |checking=assert http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710
[Bug c++/39711] New: fail to use template template parameter with default values
$g++ -v -save-temps test1.cpp Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-7' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Debian 4.3.3-7) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -E -quiet -v -D_GNU_SOURCE test1.cpp -mtune=generic -fpch-preprocess -o test1.ii ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../i486-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/include/c++/4.3 /usr/include/c++/4.3/i486-linux-gnu /usr/include/c++/4.3/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -fpreprocessed test1.ii -quiet -dumpbase test1.cpp -mtune=generic -auxbase test1 -version -o test1.s GNU C++ (Debian 4.3.3-7) version 4.3.3 (i486-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.1-p2. warning: GMP header version 4.2.4 differs from library version 4.2.2. warning: MPFR header version 2.4.1-p2 differs from library version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c88e63435cdcbb6cdbdd73c6b0b8618a test1.cpp: In function âint main()â: test1.cpp:14: error: type/value mismatch at argument 3 in template parameter list for âtemplateclass Key, class Data, templateclass, class class Map class Aâ test1.cpp:14: error: expected a template of type âtemplateclass, class class Mapâ, got âtemplateclass _Key, class _Tp, class _Compare, class _Alloc class std::mapâ test1.cpp:14: error: invalid type in declaration before â;â token ps: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) have no problems here. -- Summary: fail to use template template parameter with default values Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: urykhy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #1 from urykhy at gmail dot com 2009-04-10 06:11 --- Created an attachment (id=17610) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17610action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #2 from urykhy at gmail dot com 2009-04-10 06:12 --- Created an attachment (id=17611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17611action=view) preprocessed code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert
--- Comment #1 from rwild at gcc dot gnu dot org 2009-04-10 06:12 --- patch at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00769.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #3 from urykhy at gmail dot com 2009-04-10 06:15 --- please, let me know if you need more information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #2 from bonzini at gnu dot org 2009-04-10 06:42 --- The Fortran problem is a real bug in the front-end that was masked by folding. The problem is that we're folding less than without my patch. I'll prepare a patch to both fix the Fortran problem and reestablish the folding. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 06:42:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug c/39712] New: type mismatch in address expression
Hi, i have problem when compiling mplayer-svn. TIA == bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090409 (experimental) (GCC) bash-4.0$ pwd /home/user/d/mplayer/libavcodec bash-4.0$ cc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I.. -I.. -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -Ilibdvdread4 -I/0/include/freetype2 -I/0/include -c -o mpegaudiodec.o mpegaudiodec.c mpegaudiodec.c: In function : mpegaudiodec.c:1647: error: type mismatch in address expression int32_t[16] * int32_t[2][16] * is_tab = is_table; mpegaudiodec.c:1647: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: type mismatch in address expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug c/39712] type mismatch in address expression
--- Comment #1 from happyarch at gmail dot com 2009-04-10 06:50 --- Created an attachment (id=17612) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17612action=view) preprocessed output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #3 from bonzini at gnu dot org 2009-04-10 06:55 --- The pr36901-* are correct to fail IMO -- they now give an initializer is not constant error which they weren't giving before -- because you cannot know in principle that sc 0 at compile-time, you have to wait for linking. -- bonzini at gnu dot org changed: What|Removed |Added Last reconfirmed|2009-04-10 06:42:47 |2009-04-10 06:55:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #11 from jb at gcc dot gnu dot org 2009-04-10 07:23 --- Subject: Bug 39665 Author: jb Date: Fri Apr 10 07:23:25 2009 New Revision: 145875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145875 Log: 2009-04-10 Janne Blomqvist j...@gcc.gnu.org PR libfortran/39665 libfortran/39702 libfortran/39709 * io/io.h (st_parameter_dt): Revert aligned attribute from u.p.value. * io/list_read.c (read_complex): Read directly into user pointer. (read_real): Likewise. (list_formatted_read_scalar): Update read_complex and read_real calls. (nml_read_obj): Read directly into user pointer. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug c/39712] [4.5 Regression] type mismatch in address expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 08:18 --- Likely due to my patch. I'll have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-on-valid-code, wrong- ||code Last reconfirmed|-00-00 00:00:00 |2009-04-10 08:18:15 date|| Summary|type mismatch in address|[4.5 Regression] type |expression |mismatch in address ||expression Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug c/39712] [4.5 Regression] type mismatch in address expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-10 08:56 ---
Reduced testcase:
int is_table[2][16];
int is_table_lsf[2][2][16];
void compute_stereo()
{
int (*is_tab)[16];
is_tab = is_table;
}
interestingly removing the unrelated is_table_lsf decl makes the error go away.
Which is maybe a type sharing issue and due to the fact that we eventually
end up asking the FE about array type compatibility.
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-10 09:40 --- This is illegal in C++03, because std::map has 4 template parameters, no matter the defaults. Changing class A like the below works. In c++0x, thanks to typedef templates neater solutions will be possible. template typename Key, typename Data, template typename Key, typename Data, typename = std::lessKey, typename = std::allocatorstd::pairconst Key, Data class Map ... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug tree-optimization/39713] New: [4.4/4.5 Regression] ICE in get_expr_value_id
Since r141534 (PR37542), the following testcase segfaults during fre at -O1 and
higher:
template typename To, typename From
static inline To
bitwise_cast (From from)
{
union
{
From f;
To t;
} u;
u.f = from;
return u.t;
}
extern void foo (unsigned char *);
double
bar ()
{
unsigned char b[sizeof (unsigned long long)];
foo (b);
return bitwise_castdouble (*(unsigned long long *) b);
}
--
Summary: [4.4/4.5 Regression] ICE in get_expr_value_id
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug tree-optimization/39713] [4.4/4.5 Regression] ICE in get_expr_value_id
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug c++/39699] No error reporting when function and variable have the same name
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-10 11:46 ---
Subject: Re: No error reporting when function and variable
have the same name
alpha dot super-one at laposte dot net a écrit :
--- Comment #2 from alpha dot super-one at laposte dot net 2009-04-10
04:47 ---
So I compiled this program:
1 class toto
2 {
3enum e {a,b};
4e test_example();
5e test_example;
6 };
7
8 toto t;
with the -Wall option of g++ 4.3.2, I got:
test.cc:5: error: declaration of 'toto::e toto::test_example'
test.cc:4: error: conflicts with previous declaration 'toto::e
toto::test_example()'
So that does what you want I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
[Bug target/39714] New: cond-optab fallout meta-bug
This bug groups testcases that worsen or (in one case) ICE on cond-optab branch. -- Summary: cond-optab fallout meta-bug Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39714
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-10 12:43 --- Created an attachment (id=17613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17613action=view) rewrite of dispatch table installation I agree with the approach you describe, in that we need a look-a-side buffer for the dispatch table to send messages during +initialize and install the dtable after +initialize returns. I was not comfortable with the patch because: /* Assumes that __objc_runtime_mutex is locked down. * If receiver is not null, it is the object whos supercalss must be * initialised if the superclass of the one we are installing the * dispatch table for is not already installed. */ __objc_begin_install_dispatch_table_for_class (Class class, Class receiver) I still have a hard time groking what was intended with the receiver. It all seems very intertwined and I think there is a more straight forward way to implement this. Also, with this patch get_imp fails on class methods. (get_imp also has the nasty effect of installing the dispatch table without calling +initialize and the same goes for __objc_responds_to). I'm not to fond of introducing InitializingList as special type. I think should be fine with using the existing hash map tables for this. I don't think we really need to introduce a new type. Do you really think that method dispatch for partially installed dispatch tables is performance critical? Well... after all this complaining, let's get to something more constructive :-). I've attached a patch (including some test cases which still need to be augmented) that I'd like to propose for a reimplementation originally based on your code. I hope I've added enough comments and asserts to insure the assumptions and prerequisites are met. For the final submission I'll remove some of the asserts. It combines __objc_install_dispatch_table_for_class and __objc_init_install_dtable into: /* This function is called by: objc_msg_lookup, get_imp and __objc_responds_to (and the dispatch table installation functions themselves) to install a dispatch table for a class. If CLS is a class, it installs instance methods. If CLS is a meta class, it installs class methods. In either case +initialize is invoked for the corresponding class. The implementation must insure that the dispatch table is not installed until +initialize completes. Otherwise it opens a potential race since the installation of the dispatch table is used as gate in regular method dispatch and we need to guarantee that +initialize is the first method invoked an that no other thread my dispatch messages to the class before +initialize completes. */ static void __objc_install_dtable_for_class (Class cls) Which implements your suggestion with the following helper functions: static void __objc_prepare_dtable_for_class (Class cls); - builds the dispatch table and stores it in a look-a-side buffer (I used the hash tables instead of a custom type). static struct sarray *__objc_prepared_dtable_for_class (Class cls); - access the prepared table: this is used to identify whether the dispatch table is currently being installed (akin to the __objc_is_initializing_dispatch_table of the proposed patch) and is also used for subclasses that may be +initialized during the +initialize of the super class (i.e. class clusters when NSString's +initialize invokes GSString methods an need to copy NSString's dtable. static void __objc_install_prepared_dtable_for_class (Class cls); - static IMP __objc_get_prepared_imp (Class cls,SEL sel); Could you please have a look and let me know what you think? I'm still going to write some more test, checking the class cluster behavior mentioned above and I'll need some tests wrt to categories. So this is not final but it should address the main issue and the get_imp/__objc_responds_to issue. Cheers, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug target/39715] New: [cond-optab] extra sign extensions on Thumb
/* -O1 -mthumb -march=armv5t */
struct foo
{
unsigned b31 : 1;
unsigned b30 : 1;
unsigned b29 : 1;
unsigned b28 : 1;
unsigned rest : 28;
};
foo(a)
struct foo a;
{
return a.b30;
}
should have only one lsl and lsr
--
Summary: [cond-optab] extra sign extensions on Thumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug target/39716] New: [cond-optab] worse MAX_EXPR expansion for Thumb
/* -O1 -mthumb -march=armv6t2 -ffinite-math-only */
float repl1 (float varx)
{
if (varx 0.0)
return 0.0;
return varx;
}
--
Summary: [cond-optab] worse MAX_EXPR expansion for Thumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 12:44:38 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug target/39717] New: [cond-optab] CSE does not put subregs into COMPAREs on many CC0 machines
/* cris and mn10300 -O2 */
foo (float *c)
{
union
{
float r;
unsigned int i;
}
e;
e.r = c[0];
if (e.i 0x3f7f) return (e.r = e.r / 2.0f, e.i);
return ((int) e.i 0) ? 0 : 255;
}
Probably this is a duplicate too for vax:
int a, b;
int baz (short x) { return x; }
int bar (int x) {
if (baz (a ^ x ^ a)) return b;
return 0;
}
int foo (void) {
return bar (a == 0 || 1 == 1 - a) ? 1 : bar (1 a);
}
--
Summary: [cond-optab] CSE does not put subregs into COMPAREs on
many CC0 machines
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39717
[Bug target/39718] New: [cond-optab] crash on crx in IRA
/* -O3 -funroll-loops */
int foo (long b, int c)
{
int d = 0, e;
while (b--)
{
e = 0;
if (!d) e = d = 1; else e = 0;
if (!(c 0x10) || !(c 0x4000) || !e) continue;
if (c 0x80) break;
}
}
--
Summary: [cond-optab] crash on crx in IRA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39718
[Bug target/39719] New: [cond-optab] uses libcall instead of branch on m68hc11
Note that this is a win on most targets:
int
foo ()
{
extern long long Y;
return (0 Y++);
}
--
Summary: [cond-optab] uses libcall instead of branch on m68hc11
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39719
[Bug target/39720] New: [cond-optab] combine does not use LOAD_EXTEND_OP?
/* -O1 mn10300 */
int f (int a, int b, int c, _Bool d, _Bool e, _Bool f, char g)
{
if (g != 1 || d != 1 || e != 1 || f != 1) abort ();
return a + b + c;
}
int main (void)
{
if (f (1, 2, -3, 1, 1, 1, '\001'))
abort ();
exit (0);
}
--
Summary: [cond-optab] combine does not use LOAD_EXTEND_OP?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39720
[Bug c++/20118] missing template causes weird errors
--- Comment #8 from manu at gcc dot gnu dot org 2009-04-10 12:48 --- Subject: Bug 20118 Author: manu Date: Fri Apr 10 12:47:58 2009 New Revision: 145892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145892 Log: 2009-04-10 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/20118 cp/ * parser.c (cp_parser_check_template_parameters): Take a cp_declarator parameter. (cp_parser_elaborated_type_specifier): Update to cp_parser_check_template_parameters. (cp_parser_class_head): Likewise. (cp_parser_check_declarator_template_parameters): Likewise. (cp_parser_check_template_parameters): Handle first the non-error conditions. Give more accurate diagnostics if a declarator is given. testsuite/ * g++.dg/parse/pr20118.C: New. * g++.dg/template/spec16.C: Update. Added: trunk/gcc/testsuite/g++.dg/parse/pr20118.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/spec16.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
[Bug target/39721] New: [cond-optab] worse register allocation on mn10300
/* -O2 */
int dialog_calendar(int state)
{
int *obj = (state == 1 ? state : 0);
return (obj == state);
}
--
Summary: [cond-optab] worse register allocation on mn10300
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39721
[Bug target/39722] New: [cond-optab] worse code with bitfields on v850 and mn10300
struct S
{
unsigned int s;
};
struct T
{
struct S t[2];
unsigned int u : 1;
};
void
foo (int x, int y, int z)
{
int i;
struct T t;
t.u = t.u;
for (i = 0; i x; i++)
if (z != 1)
t.t[i].s = y || t.u;
}
--
Summary: [cond-optab] worse code with bitfields on v850 and
mn10300
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39722
[Bug c++/20118] missing template causes weird errors
--- Comment #9 from manu at gcc dot gnu dot org 2009-04-10 12:51 --- Fixed in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-10 12:54 --- (In reply to comment #3) The pr36901-* are correct to fail IMO -- they now give an initializer is not constant error which they weren't giving before -- because you cannot know in principle that sc 0 at compile-time, you have to wait for linking. I think it is target specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug target/39723] New: [cond-optab] worse code with long long shifts on v850
long long xlrandom (long long x)
{
int bits = 64;
do
{
unsigned b = (random () 15) + 1;
x = b; /* shift up 1-16 steps */
bits -= b;
}
while (bits = 0);
return x;
}
--
Summary: [cond-optab] worse code with long long shifts on v850
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723
[Bug target/39724] New: [cond-optab] reload_cse_simplify_operands complicates code on vax
reload_cse_simplify_operandss likes to change (compare REG (const_int 0)) to a
compare between registers on VAX, when it has a register at hand whose value is
zero. This pessimizes code and in some cases even introduces spurious compares
instead of using CC0.
/* -Os */
f(int count,double r,double *rho)
{
int i, j, miny, maxy, hy;
float help, d;
for (hy = miny; hy= maxy; hy++)
while(j =0)
if ( d = r) abort ();
}
--
Summary: [cond-optab] reload_cse_simplify_operands complicates
code on vax
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39724
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-04-10 14:04 --- Subject: Bug 25104 Author: dfranke Date: Fri Apr 10 14:04:16 2009 New Revision: 145907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145907 Log: gcc/fortran/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * array.c (gfc_append_constructor): Added NULL-check. * check.c (gfc_check_spread): Check DIM. (gfc_check_unpack): Check that the ARRAY arguments provides enough values for MASK. * intrinsic.h (gfc_simplify_spread): New prototype. (gfc_simplify_unpack): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (gfc_simplify_spread): New. (gfc_simplify_unpack): New. * expr.c (check_transformational): Allow additional transformational intrinsics in initialization expression. gcc/testsuite/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * gfortran.dg/spread_init_expr.f03: New. * gfortran.dg/unpack_init_expr.f03: New. * gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error message. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/spread_init_expr.f03 branches/fortran-dev/gcc/testsuite/gfortran.dg/unpack_init_expr.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.dev branches/fortran-dev/gcc/fortran/array.c branches/fortran-dev/gcc/fortran/check.c branches/fortran-dev/gcc/fortran/expr.c branches/fortran-dev/gcc/fortran/intrinsic.c branches/fortran-dev/gcc/fortran/intrinsic.h branches/fortran-dev/gcc/fortran/simplify.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev branches/fortran-dev/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/38709] ICE on zero-sized array in initialization expression
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-10 14:12 --- Subject: Bug 38709 Author: dfranke Date: Fri Apr 10 14:12:01 2009 New Revision: 145909 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145909 Log: gcc/fortran/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/38709 * expr.c (find_array_section): Leave early on zero-sized arrays. gcc/testsuite/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/38709 * gfortran.dg/zero_sized_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/zero_sized_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38709
[Bug fortran/38709] ICE on zero-sized array in initialization expression
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-04-10 14:13 --- Fixed in trunk. Not a regression, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38709
[Bug target/39725] New: [cond-optab] MIPS pessimizations on floating-point
MIPS floating-point comparisons are sometimes improved, sometimes pessimized. Here are the tests that are pessimized more: gcc.c-torture/execute/ieee/compare-fp-1.c gcc.c-torture/execute/ieee/compare-fp-4.c (-fno-trapping-math) gcc.c-torture/unsorted/DFcmp.c (not for all versions, but for example at -O1 -mfp32 -mgp32 they are affected). Just removing these three is enough to change from a depressing 513 files changed, 24582 insertions(+), 20790 deletions(-) to a decent 467 files changed, 15738 insertions(+), 15818 deletions(-) -- Summary: [cond-optab] MIPS pessimizations on floating-point Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org OtherBugsDependingO 39714 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725
[Bug fortran/29962] Initialization expressions
--- Comment #16 from dfranke at gcc dot gnu dot org 2009-04-10 14:04 --- Subject: Bug 29962 Author: dfranke Date: Fri Apr 10 14:04:16 2009 New Revision: 145907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145907 Log: gcc/fortran/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * array.c (gfc_append_constructor): Added NULL-check. * check.c (gfc_check_spread): Check DIM. (gfc_check_unpack): Check that the ARRAY arguments provides enough values for MASK. * intrinsic.h (gfc_simplify_spread): New prototype. (gfc_simplify_unpack): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (gfc_simplify_spread): New. (gfc_simplify_unpack): New. * expr.c (check_transformational): Allow additional transformational intrinsics in initialization expression. gcc/testsuite/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * gfortran.dg/spread_init_expr.f03: New. * gfortran.dg/unpack_init_expr.f03: New. * gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error message. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/spread_init_expr.f03 branches/fortran-dev/gcc/testsuite/gfortran.dg/unpack_init_expr.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.dev branches/fortran-dev/gcc/fortran/array.c branches/fortran-dev/gcc/fortran/check.c branches/fortran-dev/gcc/fortran/expr.c branches/fortran-dev/gcc/fortran/intrinsic.c branches/fortran-dev/gcc/fortran/intrinsic.h branches/fortran-dev/gcc/fortran/simplify.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev branches/fortran-dev/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #13 from pault at gcc dot gnu dot org 2009-04-10 14:27 --- (In reply to comment #12) Comment #11 should probably go to PR38802. Indeed - sorry. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug target/39726] New: [cond-optab] ColdFire pessimizations on QImode/HImode tests
unsigned char v;
int baz (unsigned char u, unsigned char w)
{
if ((u - w) 0x80)
v = 1;
}
Combine does not like as much as for m68k the RTL produced by the optimizers,
because of the lack of byte operations:
(insn 10 9 11 f.c:5 (set (reg:QI 35)
-(and:QI (subreg:QI (reg:SI 34) 3)
-(insn 11 10 12 f.c:5 (set (cc0)
-(compare (reg:QI 35)
(const_int 0 [0x0]))) -1 (nil))
vs.
(insn 10 9 11 f.c:5 (set (reg:QI 35)
+(subreg:QI (reg:SI 34) 3)) -1 (nil))
+
+(insn 11 10 12 f.c:5 (set (reg:SI 36)
+(and:SI (subreg:SI (reg:QI 35) 0)
(const_int -128 [0xff80]))) -1 (nil))
+(insn 12 11 13 f.c:5 (set (reg:QI 37)
+(subreg:QI (reg:SI 36) 3)) -1 (nil))
+
+(insn 13 12 14 f.c:5 (set (cc0)
+(compare (reg:QI 37)
(const_int 0 [0x0]))) -1 (nil))
The extra insn 12 is present because of this in dojump.c:
564 /* The RTL optimizers prefer comparisons against pseudos. */
565 if (GET_CODE (temp) == SUBREG)
566 {
567 /* Compare promoted variables in their promoted mode. */
568 if (SUBREG_PROMOTED_VAR_P (temp)
569REG_P (XEXP (temp, 0)))
570 temp = XEXP (temp, 0);
571 else
572 temp = copy_to_reg (temp);
573 }
--
Summary: [cond-optab] ColdFire pessimizations on QImode/HImode
tests
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39726
[Bug target/39727] New: [cond-optab] pessimization for FP compare with 0 on ColdFire
double testit(double _Complex* t)
{
return *t==0.0?0.0:-*t;
}
includes useless sequence like
clr.l -(%sp);clr.l -(%sp);fdmove.d (%sp)+,%fp1
fdmove.d (%a0),%fp0
fcmp.d %fp1,%fp0
where the first and last line are useless -- GCC could instead be using the
flags as set by a fdmove.d instruction.
--
Summary: [cond-optab] pessimization for FP compare with 0 on
ColdFire
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39727
[Bug target/39718] [cond-optab] crash on crx in IRA
--- Comment #1 from bonzini at gnu dot org 2009-04-10 15:25 ---
Another testcase, this one failing at -O2:
void foo (unsigned int n)
{
int i, j = -1;
for (i = 0; i 10 j 0; i++)
if ((1UL i) == n)
j = i;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39718
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #5 from hp at gcc dot gnu dot org 2009-04-10 15:28 --- For the record, seeing the same regressions for cris-elf, 145839:145857. Wrt. comment #3, if addresses were unsigned before (or this'd have failed), they should still be so, and this still be constant true, right? Regardless of target. (We know it's not NULL.) -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug c++/39699] No error reporting when function and variable have the same name
--- Comment #4 from alpha dot super-one at laposte dot net 2009-04-10 15:42 --- I have not that's in lot of version, my code tested is here: http://www.developpez.net/forums/m4191192-3/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #6 from bonzini at gnu dot org 2009-04-10 16:05 --- We know it's not NULL. I don't think the compiler can say so if not -fdelete-null-pointer-checks, and the flag is off at -O0 and -O1 (which is a separate bug and a separate patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #7 from bonzini at gnu dot org 2009-04-10 16:06 --- Subject: Bug 39701 Author: bonzini Date: Fri Apr 10 16:06:43 2009 New Revision: 145927 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145927 Log: 2009-04-10 Paolo Bonzini bonz...@gnu.org PR middle-end/39701 * fold-const.c (tree_single_nonzero_warnv_p): Pass non-static variables as non-NULL even with -fdelete-null-pointer-checks. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-10 17:35 --- Fixed as of revision 145878. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39702
[Bug tree-optimization/39713] [4.4/4.5 Regression] ICE in get_expr_value_id
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-10 18:31 --- I will have a looksee. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 18:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug tree-optimization/39713] [4.4/4.5 Regression] ICE in get_expr_value_id
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 18:43 ---
I am testing the following
Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 145876)
+++ tree-ssa-sccvn.c(working copy)
@@ -257,9 +257,10 @@ vn_get_expr_for (tree name)
switch (TREE_CODE_CLASS (gimple_assign_rhs_code (def_stmt)))
{
case tcc_reference:
- if (gimple_assign_rhs_code (def_stmt) == VIEW_CONVERT_EXPR
- || gimple_assign_rhs_code (def_stmt) == REALPART_EXPR
- || gimple_assign_rhs_code (def_stmt) == IMAGPART_EXPR)
+ if ((gimple_assign_rhs_code (def_stmt) == VIEW_CONVERT_EXPR
+ || gimple_assign_rhs_code (def_stmt) == REALPART_EXPR
+ || gimple_assign_rhs_code (def_stmt) == IMAGPART_EXPR)
+ TREE_CODE (gimple_assign_rhs1 (def_stmt)) == SSA_NAME)
expr = fold_build1 (gimple_assign_rhs_code (def_stmt),
gimple_expr_type (def_stmt),
TREE_OPERAND (gimple_assign_rhs1 (def_stmt), 0));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #9 from hjl at gcc dot gnu dot org 2009-04-10 18:56 --- Subject: Bug 28301 Author: hjl Date: Fri Apr 10 18:56:07 2009 New Revision: 145936 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145936 Log: gcc/cp/ 2009-04-10 Jason Merrill ja...@redhat.com PR c++/28301 * parser.c (cp_parser_skip_to_end_of_block_or_statement): Return if we see a close brace without an open brace. gcc/testsuite/ 2009-04-10 H.J. Lu hongjiu...@intel.com PR c++/28301 * g++.dg/cpp0x/enum2.C: Updated. * g++.dg/debug/pr22514.C: Likewise. * g++.dg/parse/enum2.C: Likewise. * g++.dg/parse/enum3.C: Likewise. * g++.dg/template/crash79.C: Likewise. * g++.old-deja/g++.jason/cond.C: Likewise. * g++.dg/template/pr28301.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr28301.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/enum2.C trunk/gcc/testsuite/g++.dg/debug/pr22514.C trunk/gcc/testsuite/g++.dg/parse/enum2.C trunk/gcc/testsuite/g++.dg/parse/enum3.C trunk/gcc/testsuite/g++.dg/template/crash79.C trunk/gcc/testsuite/g++.old-deja/g++.jason/cond.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #13 from hjl at gcc dot gnu dot org 2009-04-10 18:58 --- Subject: Bug 39701 Author: hjl Date: Fri Apr 10 18:58:12 2009 New Revision: 145937 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145937 Log: 2009-04-10 H.J. Lu hongjiu...@intel.com PR middle-end/39701 * common.opt (-fdelete-null-pointer-checks): Initialize to 1. * opts.c (decode_options): Don't set flag_delete_null_pointer_checks here. * doc/invoke.texi: Update -fdelete-null-pointer-checks. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #10 from hjl at gcc dot gnu dot org 2009-04-10 19:01 --- Subject: Bug 28301 Author: hjl Date: Fri Apr 10 19:01:16 2009 New Revision: 145938 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145938 Log: gcc/cp/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 Jason Merrill ja...@redhat.com PR c++/28301 * parser.c (cp_parser_skip_to_end_of_block_or_statement): Return if we see a close brace without an open brace. gcc/testsuite/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 H.J. Lu hongjiu...@intel.com PR c++/28301 * g++.dg/cpp0x/enum2.C: Updated. * g++.dg/debug/pr22514.C: Likewise. * g++.dg/parse/enum2.C: Likewise. * g++.dg/parse/enum3.C: Likewise. * g++.dg/template/crash79.C: Likewise. * g++.old-deja/g++.jason/cond.C: Likewise. * g++.dg/template/pr28301.C: New. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/pr28301.C - copied unchanged from r145937, trunk/gcc/testsuite/g++.dg/template/pr28301.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum2.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/pr22514.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/enum2.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/enum3.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash79.C branches/gcc-4_4-branch/gcc/testsuite/g++.old-deja/g++.jason/cond.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #14 from pault at gcc dot gnu dot org 2009-04-10 19:06 --- (In reply to comment #9) The code in comment #1 still does not give the right result. I get (intel-darwin): No, it's not right. We have seen this before with module assignments involving derived types. It should be noted that this is an entirely different bug to the original one. In the case of the first, the dependency was missed. In this second, it is detected OK but the components of the lhs that are not assigned to by the module procedure are left indeterminate. Daniel, I expect this looks familiar Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||d at domob dot eu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #11 from hjl at gcc dot gnu dot org 2009-04-10 19:36 --- Subject: Bug 28301 Author: hjl Date: Fri Apr 10 19:36:19 2009 New Revision: 145939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145939 Log: gcc/cp/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 Jason Merrill ja...@redhat.com PR c++/28301 * parser.c (cp_parser_skip_to_end_of_block_or_statement): Return if we see a close brace without an open brace. gcc/testsuite/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 H.J. Lu hongjiu...@intel.com PR c++/28301 * g++.dg/debug/pr22514.C: Updated. * g++.dg/parse/enum2.C: Likewise. * g++.dg/parse/enum3.C: Likewise. * g++.dg/template/pr28301.C: New. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/pr28301.C - copied unchanged from r145938, trunk/gcc/testsuite/g++.dg/template/pr28301.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/g++.dg/debug/pr22514.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/enum2.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/enum3.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #12 from hjl dot tools at gmail dot com 2009-04-10 19:37 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug target/39727] [cond-optab] pessimization for FP compare with 0 on ColdFire
--- Comment #1 from bonzini at gnu dot org 2009-04-10 20:06 --- This was actually fixed already with local patches, at least above -O1. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|[cond-optab] pessimization |[cond-optab] pessimization |for FP compare with 0 on|for FP compare with 0 on |ColdFire|ColdFire http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39727
[Bug c++/39728] New: C++ diagnostic for private operator= is voluminous and unhelpful
For this test case:
# include fstream
# include istream
using namespace std;
ifstream x;
ifstream y = x;
int main(int argc, char** argv) {
y = x;
return 0;
}
current mainline g++ produces:
In file included from
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/ios:39,
from
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/istream:40,
from
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/fstream:40,
from foo.cc:1:
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/ios_base.h:
In member function std::basic_ioschar std::basic_ioschar::operator=(const
std::basic_ioschar):
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/ios_base.h:793:
error: std::ios_base std::ios_base::operator=(const std::ios_base) is
private
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:47:
error: within this context
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:
In member function std::basic_istreamchar
std::basic_istreamchar::operator=(const std::basic_istreamchar):
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:53:
note: synthesized method std::basic_ioschar
std::basic_ioschar::operator=(const std::basic_ioschar) first required
here
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:
In member function std::basic_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar):
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:81:
note: synthesized method std::basic_istreamchar
std::basic_istreamchar::operator=(const std::basic_istreamchar) first
required here
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/streambuf:
In member function std::basic_filebufchar
std::basic_filebufchar::operator=(const std::basic_filebufchar):
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/streambuf:778:
error: std::basic_streambuf_CharT, _Traits::__streambuf_type
std::basic_streambuf_CharT, _Traits::operator=(const
std::basic_streambuf_CharT, _Traits::__streambuf_type) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_streambuf_CharT,
_Traits::__streambuf_type = std::basic_streambufchar] is private
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:78:
error: within this context
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:
In member function std::basic_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar):
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:81:
note: synthesized method std::basic_filebufchar
std::basic_filebufchar::operator=(const std::basic_filebufchar) first
required here
foo.cc: In function int main(int, char**):
foo.cc:10: note: synthesized method std::basic_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar) first
required here
Walking back from the point of error to the point of use can be helpful in some
scenarios. However, for an example like this one it is unhelpful and serves to
disguise the real problem.
I think we can use the walkback more intelligently and say something like:
foo.cc:10: error: cannot synthesize method std::basic_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar)
foo.cc:10: note: because std::ios_base std::ios_base::operator=(const
std::ios_base) is private
foo.cc:10: note: for details use -fvery-long-error-messages
--
Summary: C++ diagnostic for private operator= is voluminous and
unhelpful
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728
[Bug c++/39729] New: C++ does not name a type error message can be misleading
For this C++ example:
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says this:
foo.cc:3: error: ifstream does not name a type
foo.cc:4: error: ifstream does not name a type
ifstream not only does not name a type, it is not defined at all in any way.
Let's say that instead of leading the user into trying to figure out what is
wrong with ifstream.
foo.cc:3: error: ifstream not defined
--
Summary: C++ does not name a type error message can be
misleading
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39729
[Bug c++/39730] New: C++ incomplete type error can be misleading
For this example:
# include istream
# include istream
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says:
foo.cc:6: error: aggregate std::ifstream x has incomplete type and cannot be
defined
This is accurate but confusing for the uninitiated. How about something like
foo.cc:6: error: std::ifstream was declared but not defined
--
Summary: C++ incomplete type error can be misleading
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39730
[Bug fortran/34040] relation between kinds and C types (for math builtins) shouldn't be hardcoded
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 20:44 --- Is this still valid? Is there a relation to PR21203? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
[Bug fortran/36553] Missing interface not detected in call to same file function
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-04-10 20:50 --- Dominique, any improvements here with -fwhole-file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:03 --- Closing as this seems to be completed. Please reopen if there's an issue left. Thanks for the reports! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug fortran/25829] [F2003] Asynchronous IO support
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 21:23 --- Jerry, is this complete? If not, could you please summarize what's left? Thanks. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-12 21:18:24 |2009-04-10 21:26:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/24886] different character length in actual and formal argument not detected
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:35 --- With the commit in comment #9 we get: $ gfortran-svn -fwhole-file -Wall pr24886.f [...] pr24886.f:8.20: call foo(x) 1 Warning: Character length of actual argument shorter than of dummy argument 'y' (10/20) at (1) Paul, can we close this one? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug fortran/29635] debug info of modules
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 21:38 --- Jakub, is anything left to do? Can this one be closed? How about PR24526, is this fixed as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
[Bug c/39731] New: Separate warning classes for maybe-uninitialized and known-uninitialized variables.
It would be nice to provide separate -W flags for the is used uninitialized and may be used uninitialized variants of -Wuninitialized. The former is always a problem, while the latter is often noise. See this thread: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070540.html -- Summary: Separate warning classes for maybe-uninitialized and known-uninitialized variables. Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scottwood at freescale dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731
[Bug fortran/13615] -Wuninitialized produces wrong error message for characters
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:53 --- To assess whether this is a middle-end issue, the alias dump (with VOPS and linenumbers) would be relevant. The testcase in #8 still gives the same warning. Manuel, you refer to the output of -fdump-tree-alias or another one? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615
[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 22:12 --- Testcase of comment #9 now gives: $ gfortran-svn -fwhole-file -g -Wall -c pr22571.f90 pr22571.f90:13.9: call a(q) 1 Error: Type mismatch in argument 'p' at (1); passed TYPE(u) to TYPE(t) Paul, can we close this one? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, pault at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22571
[Bug gcov-profile/39732] New: -fprofile-generate -O1: ICE: verify_stmts failed, ADDRESSABLE bit not set on pointers passed to std::copy
g++ -O1 -fprofile-generate gcc-bug/test-case.ii gcc-bug/test-case.cpp: In function int f(const int*): gcc-bug/test-case.cpp:14: error: address taken, but ADDRESSABLE bit not set D.27568 gcc-bug/test-case.cpp:14: note: in statement D.27611 = D.27568; gcc-bug/test-case.cpp:14: internal compiler error: verify_stmts failed It is very simple code that I have used in C++ for a long time. Like this: std::copy(array[0], array[5], ostream_iteratorint(cout, \n); I accidentally built GCC 4.5.0 from SVN instead of 4.4 (it branched when I wasn't looking) and hit this bug. It only seems to happen with optimization and profile generation. -O1 -fprofile-generate will trigger it. -O3 without profiling will not. I have not tried to reproduce with GCC 4.4 or GCC 4.5 on i686 or x86_64. Preprocessed source will be attached. -- Summary: -fprofile-generate -O1: ICE: verify_stmts failed, ADDRESSABLE bit not set on pointers passed to std::copy Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zlynx at acm dot org GCC host triplet: ia64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39732
[Bug gcov-profile/39732] -fprofile-generate -O1: ICE: verify_stmts failed, ADDRESSABLE bit not set on pointers passed to std::copy
--- Comment #1 from zlynx at acm dot org 2009-04-10 22:22 --- Created an attachment (id=17615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17615action=view) preprocessed C++ test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39732
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #14 from dominiq at lps dot ens dot fr 2009-04-10 22:33 --- Could the patches in comments #11 to #13 be applied to trunk too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/36553] Missing interface not detected in call to same file function
--- Comment #9 from dominiq at lps dot ens dot fr 2009-04-10 22:41 --- Dominique, any improvements here with -fwhole-file? AFAICT the answer is no: the invalid code in comment #0 is not rejected (see comment #6 for the kind of expected diagnostic). I think this PR should be closed as invalid and a new one open against -fwhole-file with the keyword accept-invalid. BTW the ice-on-invalid-code does not seem correct: the seg fault (or bus error) occurs at run time depending on the flags (and the revision). Note also that the result is mostly 'T' when the compiled code is executed (instead if 'F' when the comments for 'module' are removed) . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
[Bug testsuite/39733] New: gcc.misc-tests/help.exp doesn't work with multilib
On Linux/x86-64 with multilib, gcc.misc-tests/help.exp failed: http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01053.html FAIL: compiler driver -v --help option(s) (assembler options) FAIL: compiler driver -v --help option(s) (linker options) FAIL: compiler driver -v --help option(s) (assembler options) FAIL: compiler driver --help=optimizers option(s) (assembler options) FAIL: compiler driver --help=params option(s) (assembler options) FAIL: compiler driver --help=C option(s) (assembler options) FAIL: compiler driver --help=C++ option(s) (assembler options) FAIL: compiler driver --help=common option(s) (assembler options) FAIL: compiler driver --help=undocumented option(s) (linker options) FAIL: compiler driver --help=^undocumented option(s) (compiler options) FAIL: compiler driver --help=target,undocumented option(s) (linker options) FAIL: compiler driver --help=target,optimizers option(s) (linker options) FAIL: compiler driver --help=warnings,^joined,^undocumented option(s) (linker options) FAIL: compiler driver -Q -O2 --help=optimizers option(s) (compiler options) FAIL: compiler driver -Q -O3 --help=optimizers option(s) (compiler options) FAIL: compiler driver --help=params --help=optimizers option(s) (compiler options) FAIL: compiler driver --help=joined option(s) (assembler options) FAIL: compiler driver --help=separate option(s) (assembler options) FAIL: compiler driver --help=warnings,joined option(s) (assembler options) FAIL: compiler driver --help=warnings,^joined option(s) (assembler options) FAIL: compiler driver --help=joined,separate option(s) (linker options) FAIL: compiler driver --help=^joined,separate option(s) (linker options) FAIL: compiler driver --help=joined,^separate option(s) (linker options) FAIL: compiler driver --help=joined,undocumented option(s) (linker options) FAIL: compiler driver --help=^joined,^separate option(s) (linker options) on the second run, which has has Running /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.misc-tests/help.exp ... Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ test-17145.c --help -v -lm -o test-17145.x(timeout = 300) That is an extra -v after --help. -- Summary: gcc.misc-tests/help.exp doesn't work with multilib Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #14 from hjl at gcc dot gnu dot org 2009-04-11 00:43 --- Subject: Bug 39701 Author: hjl Date: Sat Apr 11 00:43:33 2009 New Revision: 145948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145948 Log: 2009-04-10 Paolo Bonzini bonz...@gnu.org PR tree-optimization/39701 * doc/invoke.texi (Optimization Options): Document change in meaning and initialization of -fdelete-null-pointer-checks. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-11 00:55 --- The problem is both lib/options.exp and gcc.misc-tests/options.exp define check_for_options. But they take different parameters and are different. gcc.misc-tests/help.exp has load_lib options.exp But you really don't know for sure which check_for_options is used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-11 01:05 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00852.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||04/msg00852.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
