[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-31 06:08 --- See also PR 32703; example found by Paul and compared with other compilers by Dominique and me. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/32703] ICE with [trim(character_variable)]
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-31 06:10 --- (In reply to comment #4) does not generate the runtime error that it should, so I am leaving this PR open. I have unassigned myself for now but might well return to this soon. I think it should be enough to give this diagnostic only with -fbounds-check. Additionally, I filled PR 33254 to track this. I would thus suggest to close this PR as fixed - or at least remove remove the blocking of PR32834. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/32703] ICE with [trim(character_variable)]
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-31 06:21 --- (Close the bug myself.) The ICE mentioned in the subject is FIXED for the trunk. As said, PR 33254 tracks the run-time diagnostic for different string lengths in array constructors. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Keywords|accepts-invalid |ice-on-valid-code Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug c/33256] New: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
I was recompiling the linux kernel on a mips ip32 system (an SGI O2) whith only
on change in config. I changed CONFIG_BUILD_ELF64 to 'n'.
Then, while rebuilding with
sgi:~# gcc -v
Using built-in specs.
Target: mips-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --disable-libssp
--enable-checking=release mips-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
I got this error:
CC [M] net/sched/em_u32.o
CC [M] net/sched/em_meta.o
net/sched/em_meta.c: In function meta_int_loadavg_0:
net/sched/em_meta.c:127: error: PRINT_OPERAND, invalid operand for relocation
(const:DI (plus:DI (symbol_ref:DI (avenrun) [flags 0x40] var_decl 0x2b357f50
avenrun)
(const_int 4 [0x4])))
net/sched/em_meta.c:127: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
{standard input}: Assembler messages:
{standard input}:2436: Warning: end of file not at end of a line; newline
inserted
{standard input}:2547: Warning: missing .end at end of assembly
Preprocessed source stored into /tmp/cc0KjlCH.out file, please attach this to
your bugreport.
make[3]: *** [net/sched/em_meta.o] Error 1
make[2]: *** [net/sched] Error 2
make[1]: *** [net] Error 2
make[1]: Leaving directory `/usr/local/src/linux-2.6.23-rc3'
make: *** [debian/stamp-build-kernel] Error 2
The complete command line used seems to be stored in /tmp/cc0KjlCH.out:
/usr/lib/gcc/mips-linux-gnu/4.1.2/cc1 -quiet -nostdinc -Iinclude
-Iinclude/asm-mips/mach-ip32 -Iinclude/asm-mips/mach-generic -D__KERNEL__
-DVMLINUX_LOAD_ADDRESS=0x80004000 -DMODULE -DKBUILD_STR(s)=#s
-DKBUILD_BASENAME=KBUILD_STR(em_meta) -DKBUILD_MODNAME=KBUILD_STR(em_meta)
-isystem /usr/lib/gcc/mips-linux-gnu/4.1.2/include -include
include/linux/autoconf.h -MD net/sched/.em_meta.o.d net/sched/em_meta.c -quiet
-dumpbase em_meta.c -mabi=64 -msym32 -mno-abicalls -msoft-float -march=r5000
-mlong-calls -auxbase-strip net/sched/.tmp_em_meta.o -g -O2 -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-aliasing
-fno-common -fno-pic -ffreestanding -fomit-frame-pointer -fno-stack-protector
-o - -frandom-seed=0
When I deactivated CONFIG_BUILD_ELF64 I read that it does not work with recent
binutils. My binutils version is 2.17.
The only change due to this config option in Makefile seems to be:
ifdef CONFIG_BUILD_ELF64
cflags-y+= $(call cc-option,-mno-explicit-relocs)
else
cflags-y+= $(call cc-option,-msym32)
endif
Please note that if I compile the kernel with CONFIG_BUILD_ELF64=y then gcc
does not crash.
The preprocessed file /tmp/cc0KjlCH.out is available at
http://eppesuigoccas.homedns.org/~giuseppe/gcc-bug-mips-print_operand_reloc.out.bz2
and it about 110kb.
--
Summary: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giuseppe at eppesuigoccas dot homedns dot org
GCC build triplet: mips-linux-gnu
GCC host triplet: mips-linux-gnu
GCC target triplet: mips-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug debug/32914] [4.2 Regression] ICE in rtl_for_decl_init with -g option
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-31 07:25 --- Subject: Bug 32914 Author: jakub Date: Fri Aug 31 07:25:20 2007 New Revision: 127958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127958 Log: PR debug/32914 * dwarf2out.c (rtl_for_decl_init): If vector decl has CONSTRUCTOR initializer, use build_vector_from_ctor if possible to create VECTOR_CST out of it. If vector initializer is not VECTOR_CST even after this, return NULL. * d++.dg/debug/const3.C: New test. * d++.dg/debug/const4.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/const3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/const4.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/dwarf2out.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32914
[Bug rtl-optimization/33148] [4.2 Regresion] ICE in trunc_int_for_mode, at explow.c:56 during combine
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-31 07:27 --- Subject: Bug 33148 Author: jakub Date: Fri Aug 31 07:27:40 2007 New Revision: 127959 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127959 Log: PR rtl-optimization/33148 * simplify-rtx.c (simplify_unary_operation_1): Only optimize (neg (lt X 0)) if X has scalar int mode. * gcc.c-torture/compile/20070827-1.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/20070827-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/simplify-rtx.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33148
[Bug debug/32914] [4.2 Regression] ICE in rtl_for_decl_init with -g option
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-31 07:30 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32914
[Bug middle-end/33216] [4.1/4.2/4.3 Regression] ICE in named_section_real, at varasm.c:419
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-31 07:33 --- I think the 4.2/4.3 error is just fine, this is mainly a user error. The crtfiles must not be compiled with any options that will cause the special sections to be populated with other stuff (be it .ctors, .dtors, .eh_frame, etc.). The reason for that is then there is absolutely no control over whether the special marker which is supposed to be at the beginning resp. end of the special sections is actually in the beginning resp. end of the section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
[Bug rtl-optimization/33257] New: guaranteed-true test not optimized away when input values later used
I wrote a simple test of division and remainder results that should always be true ((a/b)*b+(a%b)==a, with a hardcoded constant for b). In testing a current source tree (trunk rev 127954), I found that the test properly went away... unless I later printed out the quotient and remainder values. If I passed them to printf, the test is still performed, even though it can't fail, and its intermediate values are not used. -- Summary: guaranteed-true test not optimized away when input values later used Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raeburn at raeburn dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33257
[Bug rtl-optimization/33257] guaranteed-true test not optimized away when input values later used
--- Comment #1 from raeburn at raeburn dot org 2007-08-31 07:46 --- Created an attachment (id=14143) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14143action=view) C test case, with description assembly in comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33257
[Bug rtl-optimization/33258] New: guaranteed-true arithmetic test not optimized away depending on constant
As in 33257, I was playing around with division+remainder code, and found another case gcc didn't optimize. I was using signed and unsigned variants, and tried a couple different constants. The test case was optimized properly with the constant 3 (signed or unsigned math), and with the constant 128 if unsigned math was used. Using 128 with signed math, the test didn't get optimized away. -- Summary: guaranteed-true arithmetic test not optimized away depending on constant Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raeburn at raeburn dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33258
[Bug rtl-optimization/33258] guaranteed-true arithmetic test not optimized away depending on constant
--- Comment #1 from raeburn at raeburn dot org 2007-08-31 07:53 --- Created an attachment (id=14144) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14144action=view) C test case, description and assembly in comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33258
Re: [Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
On 31 Aug 2007 04:33:12 -, michelin60 at gmail dot com [EMAIL PROTECTED] wrote: Regarding the last quote I am led to believe that Mr. Pinski is taking undue credit. PR30758 (marked as a duplicate) is the first addressing the re-appearance of mayalias. there are another 5 PR, all appearing before Mr. Pinski's filing. Wait one minute, did you read PR 28834 (note how the number is lower)? Also read comment #1: Note this is the testcase for 28807 which I was using for testing so the testcase might be added to the testsuite by the time someone gets around to looking into the bug. Also you know what the testcase for PR 28807 is named? (gcc.c-torture/execute/mayalias-2.c). The other testcase was added by me for PR 28812. Notice a pattern here? So how can my PR not be for the the mayalias testcase failure when I filed the bug specifically so I did not get blamed for a testcase failure :). There is no re-appearance of the mayalias failure; just for 4.2, the testcase was marked as xfail. Nothing changed inbetween I filed the bug report and the other one was filed except for the tetcase being xfailed on the 4.2 branch. I think you need to go read more of the history behind this one. Since I know all about this testcase failure as I added the testcases :). If you don't want to give me credit that is not my fault but oh well. I am getting tried of being wrongly accused for stuff I do correctly by unknowns. And again this is the trunk we are talking about so how can Mark be involved for every day breakage? Also if you are using the trunk you have to understand there will be breakage and take it and report it without being all offensive about problems like this. -- Pinski
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-31 07:59 --- Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase On 31 Aug 2007 04:33:12 -, michelin60 at gmail dot com [EMAIL PROTECTED] wrote: Regarding the last quote I am led to believe that Mr. Pinski is taking undue credit. PR30758 (marked as a duplicate) is the first addressing the re-appearance of mayalias. there are another 5 PR, all appearing before Mr. Pinski's filing. Wait one minute, did you read PR 28834 (note how the number is lower)? Also read comment #1: Note this is the testcase for 28807 which I was using for testing so the testcase might be added to the testsuite by the time someone gets around to looking into the bug. Also you know what the testcase for PR 28807 is named? (gcc.c-torture/execute/mayalias-2.c). The other testcase was added by me for PR 28812. Notice a pattern here? So how can my PR not be for the the mayalias testcase failure when I filed the bug specifically so I did not get blamed for a testcase failure :). There is no re-appearance of the mayalias failure; just for 4.2, the testcase was marked as xfail. Nothing changed inbetween I filed the bug report and the other one was filed except for the tetcase being xfailed on the 4.2 branch. I think you need to go read more of the history behind this one. Since I know all about this testcase failure as I added the testcases :). If you don't want to give me credit that is not my fault but oh well. I am getting tried of being wrongly accused for stuff I do correctly by unknowns. And again this is the trunk we are talking about so how can Mark be involved for every day breakage? Also if you are using the trunk you have to understand there will be breakage and take it and report it without being all offensive about problems like this. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug tree-optimization/33259] New: limited range of remainder operation can prove loop runs at most once
The result of a signed remainder operation with a constant divisor is limited in absolute value to less than the value of the divisor. Following it with code to force the remainder to be positive by adjusting the quotient and remainder values is pretty straightforward. However, if it's written as a loop it doesn't get optimized well. The rtl initially generated appears to have the loop transformed into arithmetic to figure out the number of times the loop would run, in a branch conditionalized on whether the loop would be run at all. (Actually, it appears to run the loop body once, and then do math to figure out how many more times.) However, the compiler doesn't figure out that in that branch, the loop body would be run exactly once, either in the tree or rtl optimizations. -- Summary: limited range of remainder operation can prove loop runs at most once Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raeburn at raeburn dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33259
[Bug tree-optimization/33259] limited range of remainder operation can prove loop runs at most once
--- Comment #1 from raeburn at raeburn dot org 2007-08-31 08:06 --- Created an attachment (id=14145) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14145action=view) C test case, description and assembly in comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33259
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-31 08:16:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug libfortran/33253] namelist: reading back a string with apostrophe
--- Comment #1 from anlauf at gmx dot de 2007-08-31 08:20 --- (In reply to comment #0) It does work with ifort, for example. I works with g95, but fails with xlf, unless I add an delim='apostrophe' to the open statement. I the latter case gfortran still fails, so this might be a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253
[Bug middle-end/33216] [4.1/4.2/4.3 Regression] ICE in named_section_real, at varasm.c:419
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-31 08:38 --- Well, but 4.2/4.3 reject the testcase only if you compile with -fprofile-arcs, which is bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
[Bug c++/33255] A warning for unused typedefs?
--- Comment #10 from pcarlini at suse dot de 2007-08-31 08:41 --- (In reply to comment #8) Aren't unused typedefs sometimes useful for static assertions and concept checking, using templates? I understand the general spirit of your concerns. However I'm under the impression that such tricks are becoming *less* common now that we have a real static_assert in the core language and likewise real concepts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c++/33255] A warning for unused typedefs?
--- Comment #11 from pcarlini at suse dot de 2007-08-31 08:44 --- (In reply to comment #7) I did not mean to imply that the problem is unsolvable or NP-complete or something like that. I just pointed out that usually we rely on (1) data flow insfrastructure, (2) uniqueness of entities refered to by variable and functions to warn about unused declarations. Typedefs on the other hand can be folded in very early on. So, one needs to track that folding... I see Gaby, thanks a lot for those details and clarifications. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33255
[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.
--- Comment #15 from andreagrassi at sogeasoft dot com 2007-08-31 08:57 --- Subject: R: Error in compiling when there is a function with a char parameter called before its declaration with inline parameters. Thank you again Bye and good work. Le informazioni contenute in questo messaggio di posta elettronica sono di natura confidenziale; qualsiasi pubblicazione, utilizzo o diffusione anche parziale dello stesso non può essere effettuata senza autorizzazione e potrebbe costituire un illecito penale ai sensi del Decreto Legs.vo N° 196/2003 sulla Protezione dei Dati Personali e del Codice Penale, Art. 617-621-635 bis oltre che della legge 547/93. Qualora non siate tra i legittimi destinatari di questa e-mail Vi preghiamo cortesemente di cancellarla dal Vostro sistema dopo aver notificato al mittente, rispondendo alla comunicazione, l'errore da questi commesso. -Messaggio originale- Da: raeburn at raeburn dot org [mailto:[EMAIL PROTECTED] Inviato: venerdì 31 agosto 2007 6.42 A: [EMAIL PROTECTED] Oggetto: [Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters. --- Comment #14 from raeburn at raeburn dot org 2007-08-31 04:42 --- Subject: Re: Error in compiling when there is a function with a char parameter called before its declaration with inline parameters. On Aug 30, 2007, at 3:55, andreagrassi at sogeasoft dot com wrote: A last thing if you can explain me: Why the compiler report an error in my code, whereas if a modify my invalid code splitting the main() and the a() functions into different sources and the I compile even no warnings !! Why the compiler is so strict (1 error ) and the linker so permissive (0 warnings) ? If the signature was different even the linker should report an error . In C, there just isn't enough information preserved in the object files for the linker to do such a check. For the most part, the object file just has symbol names, executable machine code, and data, without a description of what the data structures are, or what types of arguments are required by the functions. If you compile with debugging flags, some of the information is still there in the file where the function is defined, so the debugger can show you the function's arguments. But the file where the call is made doesn't generally record information about what sort of arguments it expects the function to take, to the best of my recollection. So even if the linker parsed the debugging info, it still wouldn't be able to detect this inconsistency. In terms of the language specification, the program is incorrect, but the compiler is not required to detect the problem in this case, even if it can't give you a program that works. Yes, in some cases this really gives a lot of latitude to the compiler writer, and makes it hard on the application writer. Whether or not the compiler detects problems that it's not required to is called a quality of implementation issue. While gcc can't detect this particular problem you describe above at compile time or link time, it does have some warning options that can help you. For example, you can have it warn you if you call a function that you haven't declared first. Combine that with a practice of declaring any function only once in a program, in a header file included everywhere you use the function and where you define it, and it ensures that you have consistent declarations for your functions. It might be theoretically possible to have the compiler write some additional information into the object files, and change the linker look for that information. But as the object file format and the linker implementation are very system-specific, parts of it would have to be implemented over and over for different kinds of systems. And while the GNU project does have a linker available in the binutils package, it doesn't support all systems, so even once it's done, it would still only get you the warnings you want on some systems and not on others. I won't say no one's going to tackle such a project, but personally I doubt it's going to be a high priority for many people, especially given that coding practices like I described above can take care of most cases of this kind of problem. Ken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219
[Bug c++/33212] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr
--- Comment #1 from paolo at gcc dot gnu dot org 2007-08-31 09:11 --- Subject: Bug 33212 Author: paolo Date: Fri Aug 31 09:11:43 2007 New Revision: 127962 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127962 Log: /cp 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/33212 * parser.c (cp_parser_trait_expr): Check rerurn value of cp_parser_type_id. /testsuite 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/33212 * g++.dg/ext/is_class_error.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/is_class_error.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33212
[Bug c++/33212] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr
--- Comment #2 from pcarlini at suse dot de 2007-08-31 09:12 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33212
[Bug rtl-optimization/33257] guaranteed-true test not optimized away when input values later used
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-31 09:29 ---
We don't optimize the following at the tree level either but only combine get's
this.
void foo_u_3_noprint (unsigned x) {
unsigned q = x / 3, r = x % 3;
if (q * 3 + r != x) abort();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33257
[Bug c++/33260] New: For scope warning despite -ffor-scope
The following program produces a variable scope warning, even when compiled
with -ffor-scope, preventing use of -Werror. The documentation only mentions
warnings being generated if the flag is not given.
int main()
{
int i;
{
for (int i = 0; i 100; ++i);
return i;
}
}
g++ -ffor-scope -Werror -otest test.cpp
cc1plus.exe: warnings being treated as errors
test.cpp: In function 'int main()':
test.cpp:6: warning: name lookup of 'i' changed
test.cpp:3: warning: matches this 'i' under ISO standard rules
test.cpp:5: warning: matches this 'i' under old rules
--
Summary: For scope warning despite -ffor-scope
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33260
[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT
--- Comment #13 from cyberflex at mail dot ru 2007-08-31 09:42 --- (In reply to comment #12) Does GCJ's behavior differ from Sun's in this test? Well.. tried that (jdk1.6 i386) Answer is: at this point NOT. So this is not an issue But while performing this test I found a slight difference in treating of output streams of process for which the waitFor returned. GCJ-compiled program may use output stream of such process: use available(), read(), readLine() e.t.c. In out case readLine() returns null While JDK-compiled class running in SUN's JVM (both are 1.6 version) throws exception: Exception in thread main java.io.IOException: Stream closed at java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:134) at java.io.BufferedInputStream.available(BufferedInputStream.java:381) at java.io.FilterInputStream.available(FilterInputStream.java:142) at test.main(test.java:19) This looks like to be a slight deviation from standard in GCJ :( But that's NOT the problem I stated initially and is to be dealt in othe bug (IMHO) When running shell script the rfcomm program replaces it in process list (accordingly POSIX or something likes that) so I always erroniously considered not killed rfcomm as NOT killed bt_connect.sh I feal myself ashamed, I apologize once again ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
[Bug c++/32113] [4.1/4.2/4.3 regression] ICE with invalid template parameter
--- Comment #1 from paolo at gcc dot gnu dot org 2007-08-31 09:45 --- Subject: Bug 32113 Author: paolo Date: Fri Aug 31 09:44:54 2007 New Revision: 127963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127963 Log: /cp 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/32113 * search.c (lookup_member): Check the name argument for error_mark_node. /testsuite 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/32113 * g++.dg/template/crash70.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash70.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32113
[Bug c++/32113] [4.1/4.2/4.3 regression] ICE with invalid template parameter
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-31 09:55 --- Subject: Bug 32113 Author: paolo Date: Fri Aug 31 09:55:43 2007 New Revision: 127965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127965 Log: /cp 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/32113 * search.c (lookup_member): Check the name argument for error_mark_node. /testsuite 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/32113 * g++.dg/template/crash70.C: New. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash70.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/search.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32113
[Bug c++/32113] [4.1/4.2/4.3 regression] ICE with invalid template parameter
--- Comment #4 from pcarlini at suse dot de 2007-08-31 09:58 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32113
[Bug fortran/33261] New: gfortran 4.3.0 did not start compiling on Windows Vista.
I have installed gfortran 4.3.0 (version 20070813) on Windows Vista Home Premium. Trying to compile simple Fortran programs ( gfortran name.f ) results in the ( first and only ) error message: f951: error: unrecognized command line option -fintrinsic-modules path The same gfortran version on Windows XP Professional works ok! -- Summary: gfortran 4.3.0 did not start compiling on Windows Vista. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joerg dot richter at gedas dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261
[Bug c++/32113] [4.1/4.2/4.3 regression] ICE with invalid template parameter
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-31 09:58 --- Subject: Bug 32113 Author: paolo Date: Fri Aug 31 09:57:50 2007 New Revision: 127966 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127966 Log: /cp 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/32113 * search.c (lookup_member): Check the name argument for error_mark_node. /testsuite 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/32113 * g++.dg/template/crash70.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/crash70.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/search.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32113
[Bug ada/4720] GNAT programs do not support --help and --version
--- Comment #6 from charlet at gcc dot gnu dot org 2007-08-31 10:19 --- Subject: Bug 4720 Author: charlet Date: Fri Aug 31 10:19:18 2007 New Revision: 127967 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127967 Log: 2007-08-30 Vincent Celier [EMAIL PROTECTED] PR ada/4720 * gnatchop.adb, gnatfind.adb, gnatlink.adb, gnatls.adb, gnatname.adb, gnatxref.adb, gprep.adb, clean.adb gnatbind.adb (Check_Version_And_Help): New procedure in package Switch to process switches --version and --help. Use Check_Version_And_Help in GNAT tools * make.adb: Ditto. (Compile_Sources): Make sure that sources that are excluded are not compiled. (Gnatmake): Do not issue -aO. to gnatbind and only issue -I- if a project file is used. (Version_Switch): Remove, moved to Switch (Help_Switch): Remove, moved to Switch (Display_Version): Remove, moved to Switch * switch.ads, switch.adb (Check_Version_And_Help): New procedure in package Switch to process switches --version and --help. (Display_Version): New procedure * gnatvsn.ads, gnatvsn.adb (Copyright_Holder): New function. Modified: trunk/gcc/ada/clean.adb trunk/gcc/ada/gnatbind.adb trunk/gcc/ada/gnatchop.adb trunk/gcc/ada/gnatfind.adb trunk/gcc/ada/gnatlink.adb trunk/gcc/ada/gnatls.adb trunk/gcc/ada/gnatname.adb trunk/gcc/ada/gnatvsn.adb trunk/gcc/ada/gnatvsn.ads trunk/gcc/ada/gnatxref.adb trunk/gcc/ada/gprep.adb trunk/gcc/ada/make.adb trunk/gcc/ada/switch.adb trunk/gcc/ada/switch.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4720
[Bug target/33132] m32r: ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29
--- Comment #1 from nickc at redhat dot com 2007-08-31 10:38 --- Subject: Re: New: m32r: ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29 Hi Rask, This happens building libssp at revision 127638: It appears to have been fixed somewhere. I tried to reproduce the fault with revision 127921 and I could not. (ie libssp compiled correctly). Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-08-31 10:50 --- Works now but still broken with --param max-aliased-vops=0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-08-31 10:59
---
Runtime testcase that fails with --param max-aliased-vops=0:
typedef struct _s {
int a;
int b;
int c;
int d;
} s;
extern void abort(void);
void __attribute__((noinline)) g(s *p)
{
if (p-d != 0)
abort ();
}
char *c = (void*)0;
void __attribute__((noinline)) f(void) { if (c) *c = 1; }
void test_signed_msg_encoding(void)
{
s signInfo = { sizeof(signInfo), 0 };
signInfo.b = 1;
signInfo.c = 0;
g(signInfo);
signInfo.d = 1;
f();
}
int main()
{
test_signed_msg_encoding ();
test_signed_msg_encoding ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista.
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-31 10:32 --- Can you paste (or attach as a file) the output of gfortran -v name.f? In the error message you get: unrecognized command line option -fintrinsic-modules path what exactly is the character between -fintrinsic-modules and path? (There should be a - here, the option name is -fintrinsic-modules-path) Is that a regular space, another character? (if you can't tell, please redirect output to a file, zip it and attach it here; I'm afraid copy-pasting into bugzilla might play games with special characters) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|blocker |normal GCC build triplet||i386-pc-mingw32 GCC host triplet||i386-pc-mingw32 GCC target triplet||i386-pc-mingw32 Summary|gfortran 4.3.0 did not start|gfortran 4.3.0 doesn't work |compiling on Windows Vista. |on Windows Vista. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261
[Bug c++/33210] [4.1/4.2/4.3 Regression] Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl
--- Comment #3 from pcarlini at suse dot de 2007-08-31 10:32 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210
[Bug ada/4720] GNAT programs do not support --help and --version
--- Comment #7 from charlet at gcc dot gnu dot org 2007-08-31 10:32 --- This is now fixed. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4720
[Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista.
--- Comment #2 from joerg dot richter at gedas dot de 2007-08-31 10:44 --- Subject: AW: gfortran 4.3.0 doesn't work on Windows V ista. Dear Sir, The character between modules and path is a -. I just missed to type it into my bugzilla-message. I will send the output of gfortran -v name.f On Monday because the Vista-Computer is at home and currently I am at the office. By the way: I did not found the option -fintrinsic-modules-path in the currently available gfortran / gcc 4.2.0 documentation at all. Is it a hangover from older versions? Regards and many thanks in advance Joerg Richter -Ursprüngliche Nachricht- Von: fxcoudert at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 31. August 2007 12:32 An: [EMAIL PROTECTED] Betreff: [SPAM Verdacht] - [Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista. - Bayesian Filter detected spam --- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-31 10:32 --- Can you paste (or attach as a file) the output of gfortran -v name.f? In the error message you get: unrecognized command line option -fintrinsic-modules path what exactly is the character between -fintrinsic-modules and path? (There should be a - here, the option name is -fintrinsic-modules-path) Is that a regular space, another character? (if you can't tell, please redirect output to a file, zip it and attach it here; I'm afraid copy-pasting into bugzilla might play games with special characters) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|blocker |normal GCC build triplet||i386-pc-mingw32 GCC host triplet||i386-pc-mingw32 GCC target triplet||i386-pc-mingw32 Summary|gfortran 4.3.0 did not start|gfortran 4.3.0 doesn't work |compiling on Windows Vista. |on Windows Vista. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-08-31 11:10
---
Allow me to step in... michelin60, what about discussing constructively? Here
are the comments I can make one the failures and your remarks. Please answer to
them, or ask further questions if something isn't clear.
FAIL: gfortran.dg/fmt_p_1.f90 -O0 execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O0 execution test
FAIL: gfortran.dg/output_exponents_1.f90 -O0 execution test
As explained earlier, these failures are due to a patch that was reverted in
less than 48 hours. This is a good example of why large testing of development
branches is important, as well as a good example of why you shouldn't use a
development branch for production.
FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test
This one has been failing for quite some time. It concerns the output of very
large real(kind=16) numbers, which are output as infinities. What is missing
for Jerry or I to develop a patch is access to such a machine (ppc-darwin,
ppc-linux or a recent sparc-solaris are good candidates). This is considered a
corner case, and thus of lower importance.
FAIL: gfortran.dg/nint_2.f90 -O0 execution test
This one is annoying, I think I had it fixed (I saw it on numerous targets, and
fixed it on most... I believed it was fixed on all targets). If you are willing
to get this fixed, please open a PR specifically for this problem, adding the
relevant output from ${builddir}/gcc/testsuite/gfortran/gfortran.log.
Additionally, you might want to compile and run the testcase outside of the
testsuite framework, see what happens and put that into the bugreport.
Hopefully, I can work on fixing that with you (asking you to perform any
further inquiries).
Please bring this to the attention of the appropriate gfortran people. As a
chemical engineer I am distressed that the gfortran people are not allowed any
more to backport strictly fortran frontend improvements. Both gcc-4.2.x and
gcc-4.3.0 in the eyes of many observers and even GCC maintainers leave a lot
to be desired.
backporting means porting changes, originaly designed for the development
branch [here 4.3], to release branches [branches for which at least one version
was released, like 4.2 and 4.1]. The exact rule in place for GCC development
is that only patches fixing regressions can be backported to release branches
(a regression is a bug that wasn't present in older versions but appeared at
some point). This prevents (among other things) new features to be introduced
in old branches. This is done to keep release branch stables, to avoid
introducing regressions inside a branch. The golden rule here is: all user code
that compiled fine with version 4.2.x should compile fine with later versions
4.2.y (y x). A user should never face negative consequences for upgrading his
compiler inside a given branch.
Now, the backport limitation cannot hurt 4.3, because it is the development
branch. We can (and do) perform any change that we deem necessary to the
development branch, either to introduce new features, to fix bugs (be them
regressions or not).
Now, any judgment on the intrinsic quality of a compiler is very difficult to
make. If there are specific problems you encounter with gfortran, I see
basically 3 ways you can get it improving:
* reporting your specific problems (one PR per bug/misbehaviour encountered)
* contributing time to the project (reporting bugs is one of them, regularly
testing GCC on differents platforms you have access to is another, as is
helping Fortran newbies on the mailing-list; this gives more time to the
maintainers to actually maintain the compiler itself)
* contributing resources to the project (e.g. access to specific hardware)
Short of that, well, you still have the option of using/buying another
compiler.
PS: most developers of gfortran are also end-users of the compiler, and
volunteers. Most of us are academic or private researchers. Writing this long
explanation took 30 minutes of my working day, and thus impacted my own
resarch, so please consider it seriously. (I also am a working in physical
chemistry, have a few friends working with Michelin.)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
GCC build triplet|powerpc |powerpc-unknown-linux-gnu
GCC host triplet|powerpc |powerpc-unknown-linux-gnu
GCC target triplet|powerpc |powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista.
--- Comment #4 from joerg dot richter at gedas dot de 2007-08-31 11:28 --- Subject: AW: gfortran 4.3.0 doesn't work on Windows Vi sta. I must confess that I only found the 4.2.0 documentation but not the gfortran 4.2.0 compiler in a comfortable .exe self installing version (I lost myself in the sourceforge pages). Therefor I downloaded the 4.3.0 version which in fact is easily available as a self-installing .exe version. But I didn't found and did not expect to found documentation for 4.3.0 (which still is in the developing phase). By the way can You tell me where to find a plain and simple .exe self installing file of gfortran 4.2.0? Maybe the error didn't occur at 4.2.0. Regards and thanks in advance, Joerg Richter -Ursprüngliche Nachricht- Von: fxcoudert at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 31. August 2007 13:14 An: [EMAIL PROTECTED] Betreff: [Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista. --- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-31 11:14 --- (In reply to comment #2) The character between modules and path is a -. I just missed to type it into my bugzilla-message. OK. By the way: I did not found the option -fintrinsic-modules-path in the currently available gfortran / gcc 4.2.0 documentation at all. Is it a hangover from older versions? Answer to your question: it's not a user option, it's an internal option used by different parts of the compiler to communicate. (Telling the Fortran front-end where to find intrinsic modules such as the OpenMP module.) Now, I have a question myself: why are you referring to 4.2.0? Aren't you using 4.3.0 compiler? Or do you also have a 4.2 compiler installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261
[Bug fortran/33261] gfortran 4.3.0 doesn't work on Windows Vista.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-31 11:14 --- (In reply to comment #2) The character between modules and path is a -. I just missed to type it into my bugzilla-message. OK. By the way: I did not found the option -fintrinsic-modules-path in the currently available gfortran / gcc 4.2.0 documentation at all. Is it a hangover from older versions? Answer to your question: it's not a user option, it's an internal option used by different parts of the compiler to communicate. (Telling the Fortran front-end where to find intrinsic modules such as the OpenMP module.) Now, I have a question myself: why are you referring to 4.2.0? Aren't you using 4.3.0 compiler? Or do you also have a 4.2 compiler installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33261
[Bug c/33262] New: Disappearing loop conditions
When I compile the attached source file, the s2_multiway_merge function gets apparently miscompiled. The do loop near the end of this function loses both of its terminating conditions and it is compiled to: .L101: addl$1, %esi .L53: movl-76(%ebp), %edi movl-92(%ebp), %eax movl-96(%ebp), %edx movl-32(%ebp), %ecx movl-36(%ebp), %ebx movl%edi, -4(%eax,%esi,4) movl-52(%ebp), %eax movl-100(%ebp), %edi movl%ecx, -4(%edx,%esi,4) movl-40(%ebp), %edx movl%eax, -4(%edi,%esi,4) movl$-1, (%edx) .L88: shrl%ebx je .L101 [... the s2_update_tree loop got inlined here, this test is its correct terminating condition ...] It seems that gcc thinks that `i' never changes in the loop, so it has optimized out every expression which depends in its value. I apologize for submitting a large source file, but the problem appears to be very chaotic and even removing parts of the source which are not referenced anywhere (see for example the block with the MAGIC comment attached) makes the problem disappear. Compilation command: gcc-4.2.1 -v -std=gnu99 -O2 -S xxx.c -Wunused -fgnu89-inline Output: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/opt/gcc-4.2.1 --enable-bootstrap Thread model: posix gcc version 4.2.1 /opt/gcc-4.2.1/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1 -quiet -v xxx.c -quiet -dumpbase xxx.c -mtune=generic -auxbase xxx -O2 -Wunused -std=gnu99 -version -fgnu89-inline -o xxx.s ignoring nonexistent directory /opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /opt/gcc-4.2.1/include /opt/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/include /usr/include End of search list. GNU C version 4.2.1 (i686-pc-linux-gnu) compiled by GNU C version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9831b30df15d36dc669e016cd6c4ba43 -- Summary: Disappearing loop conditions Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mj at ucw dot cz GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33262
[Bug c/33262] Disappearing loop conditions
--- Comment #1 from mj at ucw dot cz 2007-08-31 11:38 --- Created an attachment (id=14146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14146action=view) Source file triggering the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33262
[Bug c++/33210] [4.1/4.2 Regression] Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl
--- Comment #5 from pcarlini at suse dot de 2007-08-31 11:41 --- Fixed in mainline. Frankly, I'm not interested in fixing the issue in the other branches, taking also into account that it dates back to 3_4... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] Broken |Broken diagnostics: |diagnostics: |'bound_template_template_par|'bound_template_template_par |m' not supported by |m' not supported by |pp_cxx_unqualified_id/dump_d|pp_cxx_unqualified_id/dump_d |ecl |ecl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210
[Bug target/33132] m32r: ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29
--- Comment #2 from rask at gcc dot gnu dot org 2007-08-31 11:42 --- It still fails here at revision 127986. I forgot to mention the configure flags: --target m32r-unknown-elf --with-newlib --enable-sim --disable-gdb --disable-nls --enable-checking=yes,rtl Note in particular that I enable RTL checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
[Bug c++/33210] [4.1/4.2/4.3 Regression] Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl
--- Comment #4 from paolo at gcc dot gnu dot org 2007-08-31 11:38 --- Subject: Bug 33210 Author: paolo Date: Fri Aug 31 11:38:45 2007 New Revision: 127987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127987 Log: /cp 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/33210 * cxx-pretty-print.c (pp_cxx_unqualified_id): Deal with BOUND_TEMPLATE_TEMPLATE_PARM. /testsuite 2007-08-31 Paolo Carlini [EMAIL PROTECTED] PR c++/33210 * g++.dg/template/error30.C: New. Added: trunk/gcc/testsuite/g++.dg/template/error30.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210
[Bug rtl-optimization/29950] Generated code changes after unrelated edits in source.
--- Comment #7 from vda dot linux at googlemail dot com 2007-08-31 11:30
---
This is unfortunate, it skews busybox's make bloatcheck results.
In general, I suppose if generated asm sequences are different - one of them
is better (for some definition of better) - gcc generates better/worse
code depending on irrelevant factors.In this case gcc saw
typedef unsigned long int nfds_t;
struct pollfd { int fd; short int events; short int revents; };
extern int poll (...);
extern int ppoll (...);
and decided to spill one register more in function which has nothing to do with
the above.
btw, Andrew, you seem to sit on gcc bugzilla for a long time. Thank you for
your work in such, eh, thankless area!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
[Bug libgcj/33263] New: [4.3 regression] libjava testsuite failures on alpha-linux
seen with trunk 20070829 === libffi Summary === # of expected passes1108 # of unsupported tests 8 === libjava tests === Running target unix FAIL: TestClosureGC run FAIL: /build/buildd/gcc-snapshot-20070829/src/libjava/testsuite/libjava.jar/TestClosureGC.jar execution - gij test FAIL: pr11951 run FAIL: natgetargssize.cc compilation FAIL: natgetlocalvartable.cc compilation FAIL: natgetstacktrace.cc compilation FAIL: natevents.cc compilation FAIL: natgetallthreads.cc compilation FAIL: natgeterrorname.cc compilation FAIL: natgetmethodname.cc compilation FAIL: Array_3 execution - source compiled test FAIL: Array_3 -findirect-dispatch execution - source compiled test FAIL: Array_3 -O3 execution - source compiled test FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test FAIL: G19990303_02 execution - source compiled test FAIL: G19990303_02 -findirect-dispatch execution - source compiled test FAIL: G19990303_02 -O3 execution - source compiled test FAIL: G19990303_02 -O3 -findirect-dispatch execution - source compiled test FAIL: Invoke_1 execution - source compiled test FAIL: Invoke_1 -findirect-dispatch execution - source compiled test FAIL: Invoke_1 -O3 execution - source compiled test FAIL: Invoke_1 -O3 -findirect-dispatch execution - source compiled test FAIL: N19990310_02 -O3 output - source compiled test FAIL: N19990310_02 -O3 -findirect-dispatch output - source compiled test FAIL: PR218 output - source compiled test FAIL: PR218 -O3 output - source compiled test FAIL: StackTrace2 execution - source compiled test FAIL: StackTrace2 -findirect-dispatch execution - source compiled test FAIL: StackTrace2 -O3 execution - source compiled test FAIL: StackTrace2 -O3 -findirect-dispatch execution - source compiled test FAIL: Throw_2 execution - source compiled test FAIL: Throw_2 -findirect-dispatch execution - source compiled test FAIL: Throw_2 -O3 execution - source compiled test FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test FAIL: Throw_3 output - source compiled test FAIL: Throw_3 -findirect-dispatch output - source compiled test FAIL: Throw_3 -O3 output - source compiled test FAIL: Throw_3 -O3 -findirect-dispatch output - source compiled test FAIL: initexc execution - source compiled test FAIL: initexc -findirect-dispatch execution - source compiled test FAIL: initexc -O3 execution - source compiled test FAIL: initexc -O3 -findirect-dispatch execution - source compiled test FAIL: invokethrow execution - source compiled test FAIL: invokethrow -findirect-dispatch output - source compiled test FAIL: invokethrow -O3 execution - source compiled test FAIL: invokethrow -O3 -findirect-dispatch output - source compiled test FAIL: pr83 -findirect-dispatch execution - source compiled test FAIL: pr83 -O3 -findirect-dispatch execution - source compiled test === libjava Summary === # of expected passes2448 # of unexpected failures48 # of untested testcases 31 to compare with 4.1.0: === libjava Summary === # of expected passes4011 # of expected failures 10 # of untested testcases 8 -- Summary: [4.3 regression] libjava testsuite failures on alpha- linux Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33263
[Bug fortran/33264] New: lower index bound incorrect after array pointer assignment
When assigning from an array with lower index bound /=1 the lower index bound is ignored (set to 1). Afaik the lower index bound should be copied from the target. PROGRAM TST IMPLICIT NONE REAL, TARGET :: A(10:20) REAL, POINTER :: B(:) B = A WRITE(*,*) LBOUND(B,1) END PROGRAM TST bash gfortran421 -o tst tst.f90 bash ./tst 1 bash -- Summary: lower index bound incorrect after array pointer assignment Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: enok at lysator dot liu dot se GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33264
[Bug libgcj/33265] New: [4.3 regression] libjava testsuite failures on powerpc-linux
seen with trunk 20070829, not seen with the 4.2 ubuntu branch, not seen with 4.1.0. didn't check with the fedora 4.1 branch. Matthias === libjava tests === Running target unix FAIL: noclass execution - gij test FAIL: pr11951 execution - gij test FAIL: throwit execution - gij test FAIL: pr29812 execution - gij test FAIL: ExtraClassLoader execution - source compiled test FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test FAIL: ExtraClassLoader -O3 execution - source compiled test FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test FAIL: N19990310_02 -O3 output - source compiled test FAIL: N19990310_02 -O3 -findirect-dispatch output - source compiled test === libjava Summary for unix === # of expected passes2528 # of unexpected failures10 # of untested testcases 8 -- Summary: [4.3 regression] libjava testsuite failures on powerpc- linux Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33265
[Bug libgcj/33265] [4.3 regression] libjava testsuite failures on powerpc-linux
--- Comment #1 from andreast at gcc dot gnu dot org 2007-08-31 12:57 --- The failures are solved with PR32758 except the N19990310_02 ones. These happen on every other arch I have access to. (sparc, darwin, hppa, x86). The N19990310_02 failures are here since http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00523.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33265
[Bug libgcj/33266] New: [4.3 regression] N19990310_02 test failure
seen with trunk 20070829, on linux targets === libjava tests === Running target unix FAIL: N19990310_02 -O3 output - source compiled test FAIL: N19990310_02 -O3 -findirect-dispatch output - source compiled test -- Summary: [4.3 regression] N19990310_02 test failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: *-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33266
[Bug libgomp/33267] New: libgomp testsuite timeouts
trunk 20070829, configured with --enable-targets=all, and tested with
RUNTESTFLAGS=--target_board=unix\{,-m64\}:
Matthias
Running target unix/-m64
WARNING: program timed out.
FAIL: libgomp.c/loop-1.c execution test
WARNING: program timed out.
FAIL: libgomp.c/loop-2.c execution test
WARNING: program timed out.
FAIL: libgomp.c/nestedfn-5.c execution test
WARNING: program timed out.
FAIL: libgomp.c/ordered-1.c execution test
WARNING: program timed out.
FAIL: libgomp.c/ordered-2.c execution test
WARNING: program timed out.
FAIL: libgomp.c/pr29947-1.c execution test
WARNING: program timed out.
FAIL: libgomp.c/pr29947-2.c execution test
WARNING: program timed out.
FAIL: libgomp.c/sections-1.c execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -O0 execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -O1 execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -O2 execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -O3 -fomit-frame-pointer execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -O3 -fomit-frame-pointer -funroll-loops execution
test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -O3 -g execution test
WARNING: program timed out.
FAIL: libgomp.c++/pr26943.C -Os execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -O0 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -O1 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -O2 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -O3 -fomit-frame-pointer execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -O3 -g execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do1.f90 -Os execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O0 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O1 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O2 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O3 -fomit-frame-pointer execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -O3 -g execution test
WARNING: program timed out.
FAIL: libgomp.fortran/do2.f90 -Os execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -O0 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -O1 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -O2 execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -O3 -fomit-frame-pointer execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -O3 -g execution test
WARNING: program timed out.
FAIL: libgomp.fortran/omp_parse1.f90 -Os execution test
=== libgomp Summary for unix/-m64 ===
# of expected passes1567
# of unexpected failures40
--
Summary: libgomp testsuite timeouts
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33267
[Bug tree-optimization/33245] Missed opportunities for vectorization due to invariant condition
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-31 13:39 ---
(In reply to comment #0)
The innermost loop in j cannot be vectorized because of the
irregular code in that loop, i.e. the condition IF ( l.NE.k ). But
the cond expression is invariant in that loop, so the whole condition
can be hoisted outside that loop, versioning the loop, and potentially
allowing the vectorization of the innermost loop.
if you use -O3 the condition *is* taken out of the loop by loop-unswitch (at
least that's what I see with revision 127623).
SUBROUTINE DGEFA(A,Lda,N,Ipvt,Info)
INTEGER Lda , N , Ipvt(*) , Info
DOUBLE PRECISION A(Lda,*)
DOUBLE PRECISION t
INTEGER IDAMAX , j , k , kp1 , l , nm1
Info = 0
nm1 = N - 1
IF ( nm1.GE.1 ) THEN
DO k = 1 , nm1
kp1 = k + 1
l = IDAMAX(N-k+1,A(k,k),1) + k - 1
Ipvt(k) = l
IF ( A(l,k).EQ.0.0D0 ) THEN
Info = k
ELSE
IF ( l.NE.k ) THEN
t = A(l,k)
A(l,k) = A(k,k)
A(k,k) = t
ENDIF
t = -1.0D0/A(k,k)
CALL DSCAL(N-k,t,A(k+1,k),1)
DO j = kp1 , N
t = A(l,j)
IF ( l.NE.k ) THEN
A(l,j) = A(k,j)
A(k,j) = t
ENDIF
CALL DAXPY(N-k,t,A(k+1,k),1,A(k+1,j),1)
ENDDO
ENDIF
ENDDO
ENDIF
Ipvt(N) = N
IF ( A(N,N).EQ.0.0D0 ) Info = N
CONTINUE
END
The result of the vectorizer on this testcase is:
/home/seb/ex/linpk.f90:24: note: not vectorized: too many BBs in loop.
/home/seb/ex/linpk.f90:24: note: bad loop form.
/home/seb/ex/linpk.f90:1: note: vectorized 0 loops in function.
Okay, if I'm versioning that loop by hand, I get the same error due to
the PRE as for capacita.f90: the PRE inserts in the loop-latch block
some code:
bb 11:
# VUSE PARM_NOALIAS.16_252 { PARM_NOALIAS.16 }
pretmp.47_297 = *n_13(D);
goto bb 10;
Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then sink
does it. When I use -O3 -ftree-vectorize -msse2 -fno-tree-pre -fno-tree-sink
I get the dataref problem you report below, without manual modifications to the
code
And with PRE disabled, the fail occurs in the data ref analysis:
./linpk_corrected.f90:26: note: not vectorized: data ref analysis failed
t.8_70
= (*a_25(D))[D.1406_69]
./linpk_corrected.f90:26: note: bad data references.
Just for the record, this is the dataref problem that the dataref analyzer
reports:
Creating dr for t
analyze_innermost: (analyze_scalar_evolution
(loop_nb = 3)
(scalar = t)
(get_scalar_evolution
(scalar = t)
(scalar_evolution = ))
)
success.
base_address: t
offset from base address: 0
constant offset from base address: 0
step: 0
aligned to: 128
base_object: t
symbol tag: t
FAILED as dr address is invariant
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33245
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-08-31 13:56
---
We are clearly missing the use of signInfo.d by the call, thus we should
from the bitmap of clobbered parts of signInfo remove the used parts once we
encounter the call. But somehow we never remove bits from this bitmap and
I have no clue how this should work with other intermediate uses, but it
somehow does. And indeed, it also happily removes the whole-aggregate store
for
s signInfo = { sizeof(signInfo), 0 };
signInfo.b = 1;
signInfo.c = 0;
h(signInfo.d);
signInfo.d = 1;
if you disable other optimizations before DSE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug fortran/33264] lower index bound incorrect after array pointer assignment
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-31 13:56 --- This was PR33139. It's fixed on mainline (4.3), but as it's actually not a regression, it will probably not be backported to the 4.2 branch. Sorry. *** This bug has been marked as a duplicate of 33139 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33264
[Bug fortran/33139] array pointer assignment gives incorrect dimensions
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-31 13:56 --- *** Bug 33264 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||enok at lysator dot liu dot ||se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33139
[Bug tree-optimization/33246] Missed opportunities for vectorization due to data ref analysis
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 13:57 --- ... This is due to data ref analysis problems: ./fatigue.f90:14: note: not vectorized: data ref analysis failed (*stress_tensor.0_16)[D.1508_168] = D.1513_173 ./fatigue.f90:14: note: bad data references. and ./fatigue.f90:14: note: not vectorized: data ref analysis failed D.1489_133 = (*strain_tensor.0_41)[D.1488_132] ./fatigue.f90:14: note: bad data references. The data-ref analyzer reports: failed: evolution of offset is not affine. As a result, the DR fields that represent the access relative to the inner-most loop are almost all empty: base_address: offset from base address: constant offset from base address: step: aligned to: base_object: (*(real8[0:D.1433] *) D.1437_15)[0] symbol tag: SMT.79 However note that the DR fields relative to the outer-loop are computable: outer base_address: A.23 outer offset from base address: 0 outer constant offset from base address: 0 outer step: 24 outer aligned to: 128 If the data-ref analyzer can return the expression for the evolution in the inner-loop, instead of failing, we would at least have a chance to do outer-loop vectorization. This is a duplicate of PR33113. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33246
[Bug fortran/33268] New: read ('(f3.3)'), a rejected due to the extra (...)
gfortran rejects the following due to the extra (), the same is accepted for
PRINT. I believe this is valid (or if it is invalid, it is also invalid for
PRINT).
print('a'), 'Hello'
write(*,('(a)')) 'Hello'
read (*,('(f3.3)')) a
read '(f3'//'.3)', a
read ('(f3.3)'), a ! Rejected
end
read ('(f3.3)'), a ! Rejected
1
Error: UNIT specification at (1) must be an INTEGER expression or a CHARACTER
variable
ifort behaves the same as gfortran; NAG f95 accept it.
--
Summary: read ('(f3.3)'), a rejected due to the extra (...)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33232] Diagnose comma in read(), and write(),
--- Comment #1 from patchapp at dberlin dot org 2007-08-31 14:05 --- Subject: Bug number PR 33232 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02276.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33232
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-08-31 14:13 --- DSE would need to keep track of the last partial store to the aggregate and use that for memory_address_same () check to make The single use of the store's virtual definition ensures that there are no intervening aliased loads and the requirement that the second load post dominate the first ensures that if the earlier store executes, then the later stores will execute before the function exits. true for aggregate stores. last as in not otherwise dead last store, in the testcase that would be signInfo.d = 1; stmt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug fortran/33269] Diagnose missing ( in PRINT ('a'),
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-31 14:16 ---
Actually, all of the following is affected. The last one fails before
due to PR 33268.
print ('a'), 'Hello'
write(*,('a')) 'Hello'
read (*,('f3.3')) a
read ('f3.3'), a
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33269
[Bug target/33132] m32r: ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29
--- Comment #3 from nickc at redhat dot com 2007-08-31 14:18 --- Created an attachment (id=14147) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14147action=view) Fix length calculation for get_pc pattern -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
[Bug tree-optimization/33245] Missed opportunities for vectorization due to invariant condition
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 14:18 --- (In reply to comment #2) Subject: Re: Missed opportunities for vectorization due to invariant condition Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then sink does it. When I use -O3 -ftree-vectorize -msse2 -fno-tree-pre -fno-tree-sink I get the dataref problem you report below, without manual modifications to the code Apparently this is sink is triggered on -O3, Daniel also warned yesterday about the fact that it's not PRE specific. Actually, can't we move that code back in the loop body when the vectorizer detects that code in the latch bb? here's a related discussion from a couple years ago: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02045.html (and also a somewhat related PR - PR28643) I'm thinking that it is not really difficult to consider these scalars as arrays with a single element, and then just pass these to the rest of data deps. I'll try to figure out a patch for this problem that would bring us more vectorized cases. great. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33245
[Bug target/33132] m32r: ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29
--- Comment #4 from nickc at redhat dot com 2007-08-31 14:19 --- Hi Rask, Ah, yes, I see what you mean. The uploaded patch should fix this for you. Please let me know if you have any problems with it. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant
--- Comment #4 from spop at gcc dot gnu dot org 2007-08-31 14:19 --- *** Bug 33246 has been marked as a duplicate of this bug. *** -- spop at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113
[Bug tree-optimization/33246] Missed opportunities for vectorization due to data ref analysis
--- Comment #4 from spop at gcc dot gnu dot org 2007-08-31 14:19 --- Duplicate. *** This bug has been marked as a duplicate of 33113 *** -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33246
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-08-31 14:26 --- Ugh. But of course memory_address_same only checks what the name suggests. Nowhere do we check for intermediate uses. That whole-aggregate DSE just cannot work at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
Re: [Bug middle-end/33216] [4.1/4.2/4.3 Regression] ICE in named_section_real, at varasm.c:419
On 31 Aug 2007 08:38:43 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-31 08:38 --- Well, but 4.2/4.3 reject the testcase only if you compile with -fprofile-arcs, which is bogus. With your testcase ...
[Bug middle-end/33216] [4.1/4.2/4.3 Regression] ICE in named_section_real, at varasm.c:419
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-31 14:31 --- Subject: Re: [4.1/4.2/4.3 Regression] ICE in named_section_real, at varasm.c:419 On 31 Aug 2007 08:38:43 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-31 08:38 --- Well, but 4.2/4.3 reject the testcase only if you compile with -fprofile-arcs, which is bogus. With your testcase ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-08-31 14:34 --- Aldy, can you look into this again? I tried to simply revert the whole-aggregate DSE change, but it went in with the mem-ssa merge :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug fortran/33269] New: Diagnose missing ( in PRINT ('a'),
The format must be '(a)' and not 'a', however, gfortran does not diagnose this
in
PRINT ('a'), 'Hello'
NAG f95:
Error: a.f90, line 1: Missing left parenthesis in format specification
ifort:
Error: First non-blank character in a character type format specifier must be a
left parenthesis.
Without the outer parenthesis, gfortran detects this:
print 'a', 'Hello'
1
Error: Missing leading left parenthesis in format string at (1)
[The position of the 1 could also be better.]
--
Summary: Diagnose missing ( in PRINT ('a'),
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33269
[Bug tree-optimization/33245] Missed opportunities for vectorization due to invariant condition
--- Comment #2 from spop at gcc dot gnu dot org 2007-08-31 14:06 --- Subject: Re: Missed opportunities for vectorization due to invariant condition Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then sink does it. When I use -O3 -ftree-vectorize -msse2 -fno-tree-pre -fno-tree-sink I get the dataref problem you report below, without manual modifications to the code Apparently this is sink is triggered on -O3, Daniel also warned yesterday about the fact that it's not PRE specific. Actually, can't we move that code back in the loop body when the vectorizer detects that code in the latch bb? And with PRE disabled, the fail occurs in the data ref analysis: ./linpk_corrected.f90:26: note: not vectorized: data ref analysis failed t.8_70 = (*a_25(D))[D.1406_69] ./linpk_corrected.f90:26: note: bad data references. Just for the record, this is the dataref problem that the dataref analyzer reports: Creating dr for t analyze_innermost: (analyze_scalar_evolution (loop_nb = 3) (scalar = t) (get_scalar_evolution (scalar = t) (scalar_evolution = )) ) success. base_address: t offset from base address: 0 constant offset from base address: 0 step: 0 aligned to: 128 base_object: t symbol tag: t FAILED as dr address is invariant I'm thinking that it is not really difficult to consider these scalars as arrays with a single element, and then just pass these to the rest of data deps. I'll try to figure out a patch for this problem that would bring us more vectorized cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33245
[Bug target/33132] m32r: ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in insn_current_length, at insn-attrtab.c:29
--- Comment #5 from nickc at gcc dot gnu dot org 2007-08-31 14:27 --- Subject: Bug 33132 Author: nickc Date: Fri Aug 31 14:27:19 2007 New Revision: 127992 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127992 Log: PR target/33132 * config/m32r/constraints.md: Add W constraint for integer zero. * config/m32r/m32r.md (get_pc): Use W and i constraints. Fix length calculation by using alternatives. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32r/constraints.md trunk/gcc/config/m32r/m32r.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33132
[Bug middle-end/33216] [4.1/4.2/4.3 Regression] ICE in named_section_real, at varasm.c:419
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-31 14:38 --- ... how so? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33216
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #14 from michelin60 at gmail dot com 2007-08-31 14:52 ---
FAIL: gfortran.dg/nint_2.f90 -O0 execution test
This one is annoying, I think I had it fixed (I saw it on numerous targets, and
fixed it on most... I believed it was fixed on all targets). If you are willing
to get this fixed, please open a PR specifically for this problem, adding the
relevant output from ${builddir}/gcc/testsuite/gfortran/gfortran.log.
Additionally, you might want to compile and run the testcase outside of the
testsuite framework, see what happens and put that into the bugreport.
Hopefully, I can work on fixing that with you (asking you to perform any
further inquiries).
PS: most developers of gfortran are also end-users of the compiler, and
volunteers. Most of us are academic or private researchers. Writing this long
explanation took 30 minutes of my working day, and thus impacted my own
resarch, so please consider it seriously. (I also am a working in physical
chemistry, have a few friends working with Michelin.)
Thank you for your detailed and informative response. Glad to work with sombody
in the physical sciences. I was/am not smart enough to get into physical
chemistry. My family background is Northern Italy and any connection to the
French branch must have occurred centuries ago.
Let us start with the easiest one for me as this is the last working day of my
vacation, I cannot give access to to my dual G4 machine as my Internet
connection does not allow outside initiated connection. I will immediately
gather data on nint_2.f90 and open an PR.
Thanks again
Armando
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug c/33270] New: Wrong evaluation
The following code generates a 1 with gcc-4.1 and generates a 2 with a lot
of other compilers (Visual Studio, gcc-3.2, ...). I have read the non-bugs
section on http://gcc.gnu.org/bugs.html (also bug 11751) and I have read about
sequence points on http://c-faq.com/expr/seqpoints.html. Still I feel that
this is really a bug rather than a non-bug as in the many examples. Why?
Because a function call is also a sequence point.
Here is a small code snippet, that is compiled with no special settings:
#include stdio.h
int inca_and_ret1(int *p_a)
{
++(*p_a);
return 1;
}
int main()
{
int a = 0;
int *p_a = a;
(*p_a) += inca_and_ret1(p_a);
printf(%d\n, a);
return 0;
}
The function call to inca_and_ret1 is a sequence point, this the value pointed
to by p_a should be correct after the call. And then the expression (*p_a) +=
return value should be evaluated (I think).
The example snippet I present here looks very simple and stupid, but I have a
similar situation in my code and there it is far less obvious. I stumbled
across this problem by accident and I have no clue how many of these problems
exist in my code (or other people's code).
The command gcc -v -save-temps -o bug bug.c gave the following output:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -E -quiet -v bug.c -mtune=generic
-fpch-preprocess -o bug.i
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.1.2/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -fpreprocessed bug.i -quiet -dumpbase
bug.c -mtune=generic -auxbase bug -version -fstack-protector -fstack-protector
-o bug.s
GNU C version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) (i486-linux-gnu)
compiled by GNU C version 4.1.2 (Ubuntu 4.1.2-0ubuntu4).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c0d954aeefbb96d795ff3f6b3b72ef51
as -V -Qy -o bug.o bug.s
GNU assembler version 2.17.50 (i486-linux-gnu) using BFD version 2.17.50
20070103 Ubuntu
/usr/lib/gcc/i486-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o bug
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.1.2/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.1.2 -L/usr/lib/gcc/i486-linux-gnu/4.1.2
-L/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib -L/lib/../lib
-L/usr/lib/../lib bug.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.1.2/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crtn.o
--
Summary: Wrong evaluation
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim dot bruylants at vub dot ac dot be
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33270
[Bug fortran/33271] New: nint_2.f90 abort compiled with -O0
This is at the specific request of Mr. Coudert. Testsuite output: Executing on host: /var/tmp/43/build-159/gcc/testsuite/gfortran/../../gfortran -B/var/tmp/43/build-159/gcc/testsuite/gfortran/../../ /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90 -O0 -pedantic-errors -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty -lm -o ./nint_2.exe(timeout = 300) PASS: gfortran.dg/nint_2.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/gcc:.:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/gcc:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/libstdc++-v3/.libs:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/libgomp/.libs:/var/tmp/43/build-159/./gcc:/var/tmp/43/build-159/./prev-gcc FAIL: gfortran.dg/nint_2.f90 -O0 execution test This is the compile command for the standard standard x.i file /var/tmp/43/build-159/gcc/testsuite/gfortran/../../gfortran -v -save-temps -B/var/tmp/43/build-159/gcc/testsuite/gfortran/../../ /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90 -O0 -pedantic-errors -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty -lm -o ./nint_2.exe The resulting compiler message: Driving: /var/tmp/43/build-159/gcc/testsuite/gfortran/../../gfortran -v -save-temps -B/var/tmp/43/build-159/gcc/testsuite/gfortran/../../ /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90 -O0 -pedantic-errors -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty -lgfortranbegin -lgfortran -lm -o ./nint_2.exe -lgfortran -lm -shared-libgcc Reading specs from /var/tmp/43/build-159/gcc/testsuite/gfortran/../../specs Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-clocale=gnu --enable-bootstrap --enable-languages=c,fortran,c++ --enable-altivec --disable-libssp --disable-decimal-float --disable-libmudflap --disable-nls --disable-werror --disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu --with-system-zlib Thread model: posix gcc version 4.3.0 20070831 (experimental) (GCC) /var/tmp/43/build-159/gcc/testsuite/gfortran/../../f951 /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90 -quiet -dumpbase nint_2.f90 -mcpu=G4 -auxbase nint_2 -O0 -pedantic-errors -version -fintrinsic-modules-path /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/finclude -o nint_2.s GNU F95 (GCC) version 4.3.0 20070831 (experimental) (powerpc-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070831 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 /var/tmp/43/build-159/gcc/testsuite/gfortran/../../as -mppc -maltivec -many -V -Qy -o nint_2.o nint_2.s GNU assembler version 2.18 (powerpc-unknown-linux-gnu) using BFD version (GNU Binutils) 2.18 /var/tmp/43/build-159/gcc/testsuite/gfortran/../../collect2 --eh-frame-hdr -V -Qy -m elf32ppclinux -dynamic-linker /lib/ld.so.1 -o ./nint_2.exe /usr/lib/crt1.o /usr/lib/crti.o /var/tmp/43/build-159/gcc/testsuite/gfortran/../../crtbegin.o -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs -L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty -L/var/tmp/43/build-159/gcc/testsuite/gfortran/../.. -L/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0 nint_2.o -lgfortranbegin -lgfortran -lm -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /var/tmp/43/build-159/gcc/testsuite/gfortran/../../crtsavres.o /var/tmp/43/build-159/gcc/testsuite/gfortran/../../crtend.o /usr/lib/crtn.o GNU ld (GNU Binutils) 2.18 Supported emulations: elf32ppclinux elf32ppc elf32ppcsim elf64ppc This is the resulting nint_2.s: .file nint_2.f90 .gnu_attribute 4, 1 .gnu_attribute 8, 1 .section.rodata .align 2 .type options.0.1387, @object .size options.0.1387, 28 options.0.1387: .long 102 .long 127 .long 1 .long 0 .long 0 .long 1 .long 0 .section.text .align 2 .globl MAIN__
[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)
--- Comment #12 from rakdver at gcc dot gnu dot org 2007-08-31 15:34 --- Subject: Bug 33224 Author: rakdver Date: Fri Aug 31 15:34:45 2007 New Revision: 127996 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127996 Log: PR rtl-optimization/33224 * loop-iv.c (latch_dominating_def): Check that the definition belongs to the analysed region. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #1 from michelin60 at gmail dot com 2007-08-31 15:36 --- While I am properly logged in I did not even try using the attachment ptocess given the difficulties Torsten and myself had with PR33126 and PR33252 -- michelin60 at gmail dot com changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #15 from michelin60 at gmail dot com 2007-08-31 15:52 --- Regarding the last quote I am led to believe that Mr. Pinski is taking undue credit. PR30758 (marked as a duplicate) is the first addressing the re-appearance of mayalias. there are another 5 PR, all appearing before Mr. Pinski's filing. Wait one minute, did you read PR 28834 (note how the number is lower)? Also read comment #1: Note this is the testcase for 28807 which I was using for testing so the testcase might be added to the testsuite by the time someone gets around to looking into the bug. What confused me (and I take full blame for it) was the following: --- Comment #7 From Andrew Pinski 2006-08-24 15:16 [reply] --- Mine, all mine. --- Comment #8 From [EMAIL PROTECTED] 2006-08-24 15:18 [reply] --- Subject: Bug number PR 28807 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00878.html --- Comment #9 From Andrew Pinski 2006-08-25 07:14 [reply] --- Fixed. Any further discussion with Mr Pinski and Mr. Kargl seems pointless as thanks to Mr. Coudert I am engaged in doing something constructive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33232] Diagnose comma in read(), and write(),
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-31 16:02 --- Subject: Bug 33232 Author: burnus Date: Fri Aug 31 16:01:57 2007 New Revision: 127997 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127997 Log: 2007-08-31 Tobias Burnus [EMAIL PROTECTED] PR fortran/33232 * io.c (match_io): Also diagnose extra comma for READ. 2007-08-31 Tobias Burnus [EMAIL PROTECTED] PR fortran/33232 * gfortran.dg/eor_handling_2.f90: Add dg-warnings. * gfortran.dg/read_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/read_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/eor_handling_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33232
[Bug c/11751] wrong evaluation order of an expression
--- Comment #81 from pinskia at gcc dot gnu dot org 2007-08-31 16:09 --- *** Bug 33270 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tim dot bruylants at vub dot ||ac dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c/33270] Wrong evaluation
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-31 16:09 --- *** This bug has been marked as a duplicate of 11751 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33270
[Bug fortran/33232] Diagnose comma in read(), and write(),
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-31 16:22 --- FIXED for the trunk. Contrary what I claimed in comment 0, only READ was affected - WRITE was already properly diagnosed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33232
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-31 16:36 --- Could you compile with -O0 -fdump-tree-original and attach the nint_3.f90.003t.original file (or similarly named)? Could you also run with -O1 -fdump-tree-optimized and attach nint_3.f90.115t.optimized (or similarly named)? Thanks! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc |powerpc-unknown-linux-gnu GCC host triplet|powerpc |powerpc-unknown-linux-gnu GCC target triplet|powerpc |powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236
--- Comment #12 from debian-gcc at lists dot debian dot org 2007-08-31 17:24 --- a hppa-linux-gnu - hppa64-linux-gnu cross compiler builds with this patch. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #3 from michelin60 at gmail dot com 2007-08-31 17:24 ---
Could you compile with -O0 -fdump-tree-original and attach the
nint_3.f90.003t.original file (or similarly named)? Could you also run with
-O1 -fdump-tree-optimized and attach nint_3.f90.115t.optimized (or similarly
named)?
No problem but some questions:
A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it? If an earlier version is acceptable do
you want using the test command as amended per above can I do outside of the
gcc tree?
If outside the tree I can do it right now. I also hope that the attachment
process works again. personally I had no problems until PR33252. I presume you
are in Europe with a 6 hour time difference.
I will do it on nint_2.f90 right now to try the attachment nint_3.f90 migh have
been a slip on your part. They are small thus not attached.
Original:
MAIN__ ()
{
real8 a;
int4 j2;
int8 i2;
int8 i1;
real4 b;
int4 j1;
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (7, (void *) options.0);
a = 4.99944488848768742172978818416595459e-1;
i2 = 0;
i1 = (int8) __builtin_lround (a);
if (i1 != 0 || i2 != 0)
{
_gfortran_abort ();
}
a = 5.0e-1;
i2 = 1;
i1 = (int8) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
{
_gfortran_abort ();
}
a = 5.00111022302462515654042363166809082e-1;
i2 = 1;
i1 = (int8) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
{
_gfortran_abort ();
}
b = 4.99701976776123046875e-1;
j2 = 0;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 0 || j2 != 0)
{
_gfortran_abort ();
}
b = 5.0e-1;
j2 = 1;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
{
_gfortran_abort ();
}
b = 5.0059604644775390625e-1;
j2 = 1;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
{
_gfortran_abort ();
}
a = 4.503599627370497e+15;
i1 = __builtin_llround (a);
i2 = 4503599627370497;
if (i1 != i2 || i1 != 4503599627370497)
{
_gfortran_abort ();
}
a = -4.503599627370497e+15;
i1 = __builtin_llround (a);
i2 = -4503599627370497;
if (i1 != i2 || i1 != -4503599627370497)
{
_gfortran_abort ();
}
}
Optimized: ?
;; Function MAIN__ (MAIN__)
Analyzing Edge Insertions.
MAIN__ ()
{
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
bb 2:
_gfortran_set_options (7, options.0);
return;
}
Invalid sum of incoming frequencies 1, should be 9053
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug middle-end/31490] Compile error section type conflict
--- Comment #15 from drow at gcc dot gnu dot org 2007-08-31 17:42 --- Has Segher's patch been sent to gcc-patches? I've just encountered the ppc64 bootstrap failure too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug libgcj/33265] [4.3 regression] libjava testsuite failures on powerpc-linux
--- Comment #2 from debian-gcc at lists dot debian dot org 2007-08-31 18:48 --- fixed in trunk 20070831, the N19990310_02 failures are tracked in PR33266 -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33265
[Bug libgcj/33266] [4.3 regression] N19990310_02 test failure
--- Comment #1 from andreast at gcc dot gnu dot org 2007-08-31 18:53
---
The N19990310_02 failures are here since
http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00523.html.
The failures I see on darwin{x86|ppc} sparc-solaris8, HPUX11.11, ppc-linux and
x86-linux.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet|*-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2007-08-31 18:53:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33266
[Bug c/33270] Wrong evaluation
--- Comment #2 from raeburn at raeburn dot org 2007-08-31 19:04 --- Subject: Re: New: Wrong evaluation On Aug 31, 2007, at 11:05, tim dot bruylants at vub dot ac dot be wrote: The following code generates a 1 with gcc-4.1 and generates a 2 with a lot of other compilers (Visual Studio, gcc-3.2, ...). I have read the non-bugs section on http://gcc.gnu.org/bugs.html (also bug 11751) and I have read about sequence points on http://c-faq.com/expr/seqpoints.html. Still I feel that this is really a bug rather than a non-bug as in the many examples. Why? Because a function call is also a sequence point. (*p_a) += inca_and_ret1(p_a); The function call to inca_and_ret1 is a sequence point, this the value pointed to by p_a should be correct after the call. And then the expression (*p_a) += return value should be evaluated (I think). The sequence point at the function call means that side-effects in the argument list have to be completed before the execution of the function body starts. It doesn't force sequencing on other parts of the expression containing the call, specifically when the old value of the left-hand side of the += would be read (or when the address is computed, if inca_and_ret1 could modify the pointer p_a itself). Ken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33270
[Bug c/33270] Wrong evaluation
--- Comment #3 from tim dot bruylants at vub dot ac dot be 2007-08-31 19:05 --- Can someone please explain me why this behavior is correct according to the specifications? Isn't the function call issuing a new sequence point? Isn't the ++(*p_a); statement in the function a separate sequence point? Isn't the return a sequence point? From what I can see is that the statement: (*p_a) += inca_and_ret1(p_a); is evaluated in an undefined order. That's ok. No problems there. Except that the (*p_a) is evaluated by already taking the value at that memory location and caching it somewhere, then calling the function, and then performing the math on the cached value, thus skipping the increment inside the function. It feels to me that it is a bug and that it is caused by internal caching of values rather than undefined evaluation order (which indeed is allowed). And besides the discussion on this being correct behaviour or not, these kind of issues make some compilers (like GCC-4) a real pain to use safely. I know the example here is straight forward and that it is plain easy to see that this is not the best code, but I bumped into this with a much less obvious construction (involving a struct variable). Wouldn't at least a warning be a nice thing to generate in such cases? Don't get me wrong, I'm not trying to start the discussion about evaluation order all over. I just think this has nothing to do with that. I hope someone cares enough to explain this case to me and why GCC is correct (or not).(In reply to comment #1) *** This bug has been marked as a duplicate of 11751 *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33270
[Bug c++/32597] New operation with empty parameter pack does not value-initialize
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-08-31 19:18 --- Subject: Bug 32597 Author: dgregor Date: Fri Aug 31 19:18:20 2007 New Revision: 128000 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128000 Log: 2007-08-31 Douglas Gregor [EMAIL PROTECTED] PR c++/32597 * init.c (build_default_init): Make extern. * cp-tree.h (build_default_init): Declare here. * pt.c (tsubst_expr): When the instantiation of the initializer of a variable results in an empty list, default-initialize the variable. (tsubst_copy_and_build): When the instantiation of the initializer in a new expression results in an empty initializer list, default-initialize it. 2007-08-31 Douglas Gregor [EMAIL PROTECTED] PR c++/32597 * gcc/testsuite/g++.dg/cpp0x/variadic-new2.C: New. * gcc/testsuite/g++.dg/cpp0x/variadic-new.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic-new.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-new2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32597
[Bug c++/32597] New operation with empty parameter pack does not value-initialize
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-08-31 19:19 --- Fixed -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32597
[Bug c/33270] Wrong evaluation
--- Comment #4 from tim dot bruylants at vub dot ac dot be 2007-08-31 19:30 --- Thank you for this explanation. A friend of me also found an explaining document on http://www.open-std.org/jtc1/sc22/wg14/www/docs/n926.htm. Looking at 12.4.1 seems to be the case that I am in... and it's undefined. Kind regards, Tim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33270
[Bug target/33267] [4.3 Regression] libgomp testsuite timeouts
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-31 19:35 --- They failed with 127910 but now pass with revision 127935. So closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|libgomp |target Resolution||FIXED Summary|libgomp testsuite timeouts |[4.3 Regression] libgomp ||testsuite timeouts Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33267
