[Bug fortran/44614] [OOP] Wrongly importing a symbol into an interface without IMPORT
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-24 07:51 --- Subject: Bug 44614 Author: burnus Date: Thu Jun 24 07:51:22 2010 New Revision: 161310 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161310 Log: 2010-06-24 Tobias Burnus bur...@net-b.de PR fortran/44614 * decl.c (variable_decl): Fix IMPORT diagnostic for CLASS. 2010-06-24 Tobias Burnus bur...@net-b.de PR fortran/44614 * gfortran.dg/import8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/import8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44614
[Bug fortran/44614] [OOP] Wrongly importing a symbol into an interface without IMPORT
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-24 08:01 --- FIXED on the trunk (4.6). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44614
[Bug preprocessor/44652] New: Column numbers in error messages are wrong
If i compile the attached args.c, i get the following errror message in mainline GCC. In file included from args.c:2:0: structdef.h:5:3: error: expected :, ,, ;, } or __attribute__ before unsigned Note that it says args.c:2:0. We used to use GCC 4.3.2, which used to only say args.c:2. The extra :0, which is supposed to represent column number, is just wrong. In the attached test, the actual column number is 3. I am happy for the compiler to not give any column number, but giving the wrong column number looks wrong. I saw this in picochip code, but i am guessing this is not specific to picochip. Please let me know if you need any more information. Thanks -- Summary: Column numbers in error messages are wrong Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hariharans at picochip dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: picochip-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652
[Bug preprocessor/44652] Column numbers in error messages are wrong
--- Comment #1 from hariharans at picochip dot com 2010-06-24 08:30 --- Created an attachment (id=20991) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20991action=view) c file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652
[Bug preprocessor/44652] Column numbers in error messages are wrong
--- Comment #2 from hariharans at picochip dot com 2010-06-24 08:30 --- Created an attachment (id=20992) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20992action=view) struct definition header file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652
[Bug preprocessor/44652] Column numbers in error messages are wrong
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-24 08:34 --- I think column 0 is correct for the start of all preprocessor directives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652
[Bug middle-end/12392] very long optimized compile
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-06-24 08:42 --- Surely not. g++-4.5 -S -o /dev/null MRApStyle.cc -O2 -g -ftime-report MRApStyle.cc: In constructor MRApStyle::MRApStyle(): MRApStyle.cc:2409:1: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without variable tracking : 88.42 (55%) usr 0.52 (20%) sys 89.28 (54%) wall 82333 kB (14%) ggc TOTAL : 161.23 2.64 164.58 579368 kB on the top of the 4.5 branch. Everything else looks good now, so we can as well claim its one of the dups of the var-tracking-is-slow-and-memory-hungry bugs. 90s var-tracking and then giving up is quite bad. Can't we estimate instead of compute and give up? 4.4 needed 186s even without the var-tracking slowness, so at least we have recovered for that elsewhere... (in operand-scan, aka alias-improvements) Biggest offenders in 4.5 without -g are df live regs : 4.66 ( 7%) usr 0.04 ( 2%) sys 4.77 ( 7%) wall 0 kB ( 0%) ggc df liveinitialized regs: 3.17 ( 5%) usr 0.03 ( 1%) sys 3.28 ( 5%) wall 0 kB ( 0%) ggc expand: 4.51 ( 7%) usr 0.11 ( 5%) sys 4.56 ( 7%) wall 45724 kB (14%) ggc CPROP : 2.36 ( 4%) usr 0.08 ( 4%) sys 2.43 ( 4%) wall 10379 kB ( 3%) ggc PRE : 3.80 ( 6%) usr 0.18 ( 9%) sys 4.03 ( 6%) wall 9490 kB ( 3%) ggc integrated RA : 5.56 ( 8%) usr 0.06 ( 3%) sys 5.64 ( 8%) wall 3140 kB ( 1%) ggc reload: 2.79 ( 4%) usr 0.08 ( 4%) sys 2.93 ( 4%) wall 14680 kB ( 4%) ggc reload CSE regs : 6.40 (10%) usr 0.09 ( 4%) sys 6.53 (10%) wall 13311 kB ( 4%) ggc scheduling 2 : 2.64 ( 4%) usr 0.05 ( 2%) sys 2.69 ( 4%) wall 278 kB ( 0%) ggc TOTAL : 65.64 2.0168.05 338657 kB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
[Bug libstdc++/44653] New: A uniform_real random distribution produces invalid floating-point random numbers
According to:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1452.html
[quote] A uniform_real random distribution produces floating-point random
numbers x in the range min = x = max, with equal probability. min and max are
the parameters of the distribution. [/unqoute]
Following code (with either -std=c++0x or -std=gnu++0x):
#include tr1/random
#include iostream
int main()
{
std::tr1::mt19937 e;
std::tr1::uniform_realdouble dist(0.0, 1.0);
std::cout dist(e) std::endl;
return 0;
}
Produces: 3.49921e+09. It should produce a value between [0.0, 1.0). Not some
wild int.
--
Summary: A uniform_real random distribution produces invalid
floating-point random numbers
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dchichkov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44653
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #7 from sebastian dot huber at embedded-brains dot de 2010-06-24 09:41 --- Created an attachment (id=20993) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20993action=view) Implementation, configure and documentation Is libstdc++-v3/doc/xml/manual/configure.xml the main source for documentation? -- sebastian dot huber at embedded-brains dot de changed: What|Removed |Added Attachment #20463|0 |1 is obsolete|| Attachment #20471|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug tree-optimization/44539] [4.6 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-14 21:39:14 |2010-06-24 09:43:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44539
[Bug libstdc++/44653] A uniform_real random distribution produces invalid floating-point random numbers
--- Comment #1 from dchichkov at gmail dot com 2010-06-24 09:53 ---
Update. Following code produces the correct value:
#include functional
#include random
#include iostream
int main()
{
typedef std::mt19937 eng_t;
typedef std::uniform_realdouble dist_t;
typedef std::variate_generator eng_t, dist_t gen_t;
eng_t eng;
dist_t dist(0.0, 1.0);
gen_t gen(eng, dist);
std::cout gen() std::endl;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44653
[Bug tree-optimization/44539] [4.6 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-24 09:55 --- Created an attachment (id=20994) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20994action=view) gcc46-pr44539.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44539
[Bug libstdc++/44653] A uniform_real random distribution produces invalid floating-point random numbers
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-24 09:57 --- Indeed, that is what you should use for the TR1 random. Note that we have been trying to also deliver a conforming C++0x (thus, in std::) random only lately, in 4.3.x we delivered the TR1 code in the std:: namespace too. Thus, if you want to experiment with the C++0x version, use 4.5.x or mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44653
[Bug libstdc++/44653] A uniform_real random distribution produces invalid floating-point random numbers
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-24 10:00 --- Reopen... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44653
[Bug libstdc++/40263] random unform real distro: tr1 vs c++0x
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-24 10:00 --- *** Bug 44653 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||dchichkov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40263
[Bug libstdc++/44653] A uniform_real random distribution produces invalid floating-point random numbers
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-24 10:00 --- ... to resolve as duplicate. *** This bug has been marked as a duplicate of 40263 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44653
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-24 10:02 --- Jon, can you follow this one too? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #9 from sebastian dot huber at embedded-brains dot de 2010-06-24 10:09 --- Created an attachment (id=20995) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20995action=view) Implementation, configure and documentation Sorry, the config.h.in was missing. -- sebastian dot huber at embedded-brains dot de changed: What|Removed |Added Attachment #20993|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug tree-optimization/44539] [4.6 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-24 10:13 --- I would simply move the update_stmt call down to be called unconditionally before returning. Setting changed to true isn't needed, as iterating will not discover more things just because we remove a vop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44539
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-24 10:19 --- In general, regenerated files should not be posted at all, when submitting patches / changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug tree-optimization/44539] [4.6 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-24 10:44 --- Created an attachment (id=20996) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20996action=view) gcc46-pr44539.patch This works too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44539
[Bug rtl-optimization/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-24 10:57 --- The cas/casx insns only allow (mem (reg)) addressing: (match_operand:I48MODE 1 memory_reg_operand +m) (match_operand:DI 1 memory_reg_operand +m) The memory_reg_operand predicate checks this and fails if it is not a memory with a single reg, but apparently there is no constraint letter that would require the same. So, either we need to add a new constraint letter for memory that satisfies memory_reg_operand, or find out why predicate hasn't been consulted. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-24 11:00 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44412
[Bug rtl-optimization/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-06-24 11:06 --- The memory_reg_operand predicate checks this and fails if it is not a memory with a single reg, but apparently there is no constraint letter that would require the same. So, either we need to add a new constraint letter for memory that satisfies memory_reg_operand, or find out why predicate hasn't been consulted. Adding a new constraint letter yields reload failures, presumably because reload doesn't know how to go from MEM[reg+offset] to MEM[reg] on its own. Bernd, are you really sure the predicate can be bypassed like that? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug middle-end/44203] [4.6 regression] New prefetch test failures
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-24 11:24 --- Is this now fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44203
[Bug middle-end/44197] [4.6 Regresssion] varpool SEGV
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-24 11:25 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44197
[Bug bootstrap/43767] [4.6 regression] Revision 158401 failed to bootstrap
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-24 11:33 --- 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=43767
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-24 11:51 --- note-type == 10 is: *d = '\n'; /* A sentinel note that should never be processed. */ add_line_note (buffer, d + 1, '\n'); buffer-next_line = s + 1; created. But, as this PR lacks a testcase (well, the testcase depends on a proprietary header file not included here), it is hard to guess what's going on. Can you see if doing just cp /usr/include/stdlib.h /tmp/stdlib.h gcc -E -traditional-cpp /tmp/stdlib.h If yes, can you distill a smaller testcase from it (ideally at most a few lines)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug testsuite/44654] New: check-fortran / gfortran.dg/dg.exp ignores test specification in RUNTESTFLAGS
When I do: make check-fortran RUNTESTFLAGS='gfortran.dg/dg.exp=data_invalid.f90' the entire gfortran.dg/dg.exp testsuite is run. -- Summary: check-fortran / gfortran.dg/dg.exp ignores test specification in RUNTESTFLAGS Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44654
[Bug tree-optimization/43905] [4.5 Regression] duplicate __PRETTY_FUNCTION__ symbol for functions differing in const-ness
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-24 11:58 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 Regression]|[4.5 Regression] duplicate |duplicate |__PRETTY_FUNCTION__ symbol |__PRETTY_FUNCTION__ symbol |for functions differing in |for functions differing in |const-ness |const-ness | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43905
[Bug preprocessor/44652] Column numbers in error messages are wrong
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-24 12:03 --- (In reply to comment #3) I think column 0 is correct for the start of all preprocessor directives. But the #include does not start at column 0, so there is something wrong there. We know that libcpp column information sucks in many places. Tom and I have several patches but we never got around to finish them. To not get column info just use -fno-show-column -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-24 12:03:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44652
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-24 12:20 --- Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp --- Comment #4 from jakub at gcc dot gnu dot org 2010-06-24 11:51 --- created. But, as this PR lacks a testcase (well, the testcase depends on a proprietary header file not included here), it is hard to guess what's going on. I could include the OpenSolaris header, which is licensed under CDDL, but I've just been able to construct a minimal testcase: $ cat include.c #include stdlib.h $ cat stdlib.h #pragma redefine_extnamemkstemp64 mkstemp $ ./cc1 -E -traditional-cpp ./include.c -o include.i -I . -m64 In file included from ./include.c:2:0: ./stdlib.h:1:0: internal compiler error: Abort This should make it easier to find what's going on. Unlike the original test case from the GCC testsuite, this one fails even without -m64. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #11 from redi at gcc dot gnu dot org 2010-06-24 12:21 --- (In reply to comment #7) Is libstdc++-v3/doc/xml/manual/configure.xml the main source for documentation? Yes, however as you don't have a copyright assignment in place, submitting these patches might actually make it *harder* for us, as we can't use your work if it's anything substantial. I'll get this and Bug 44647 done for 4.6.0 -- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-23 09:37:15 |2010-06-24 12:21:35 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug middle-end/44203] [4.6 regression] New prefetch test failures
--- Comment #6 from borntraeger at de dot ibm dot com 2010-06-24 12:35 --- HJ confirmed that the patch worked and Andreas applied the patch. So from my point of view, the problem is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44203
[Bug libstdc++/43852] Embedded systems friendly libstdc++
--- Comment #12 from sebastian dot huber at embedded-brains dot de 2010-06-24 12:49 --- (In reply to comment #11) [...] I'll get this and Bug 44647 done for 4.6.0 Please have a look at Bug 43863 also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-24 12:56 --- Can't reproduce on x86_64-linux (and, #pragma redefine_extname seems to be handled on all targets, not just Solaris). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug testsuite/44654] check-fortran / gfortran.dg/dg.exp ignores test specification in RUNTESTFLAGS
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-24 13:24 --- Confirmed. Yet another bug or feature dilemma!-) Using make check-fortran RUNTESTFLAGS='dg.exp=data_invalid.f90' works for me. I don't know what gfortran.dg/ is supposed to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44654
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-24 13:31 --- This looks like a bug in the source to me, certainly not a middle-end or tree-optimization bug. The a_sp = matrix%local_data_sp assignment when matrix%local_data_sp is uninitialized means you are copying uninitialized data. Either nullify it in the caller or do this assignment only if (use_sp). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug testsuite/44654] check-fortran / gfortran.dg/dg.exp ignores test specification in RUNTESTFLAGS
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-24 13:36 --- (In reply to comment #1) Confirmed. Yet another bug or feature dilemma!-) Using make check-fortran RUNTESTFLAGS='dg.exp=data_invalid.f90' works for me. I don't know what gfortran.dg/ is supposed to do. It's supposed to specify the testsuite driver. That it does, but then it forgets that it was supposed to run a specific test. E.g.: make check-gcc RUNTESTFLAGS='execute.exp=arith-rand.c' Will run the driver execute.exp, telling it to only run tests that match arith-rand.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44654
[Bug libstdc++/43863] Unused recursive_init_error class defined with -fno-exceptions
-- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-23 09:36:22 |2010-06-24 13:44:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-24 13:50 --- Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp --- Comment #6 from jakub at gcc dot gnu dot org 2010-06-24 12:56 --- Can't reproduce on x86_64-linux (and, #pragma redefine_extname seems to be handled on all targets, not just Solaris). This seems to be extremely sensitive to command line parameters. E.g. on mips-sgi-irix6.5 it works (no ICE) with $ cc1 -E -tditional-cpp include.c -o include.i -I . When I add either -mabi=n32 or -mabi=64, cc1 aborts. Similarly, on sparc-sun-solaris2.11: $ cc1 -E -traditional-cpp include.c -o include.i -I . ICEs $ cc1 -E -traditional-cpp `pwd`/include.c -o include.i -I . works. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug testsuite/44654] check-fortran / gfortran.dg/dg.exp ignores test specification in RUNTESTFLAGS
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-24 14:52 --- It's supposed to specify the testsuite driver. That it does, but then it forgets that it was supposed to run a specific test. dg.exp=files_to_test does it (without path). What is not clear to me is what 'gfortran.dg/dg.exp=files_to_test' (with partial path) is supposed to do. Presently it acts as if 'gfortran.dg/dg.exp=files_to_test' is just dropped and the full test is run. May be one could want that it emits an error and stop, or matches the partial path, or ... . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44654
[Bug bootstrap/44655] New: bootstrap failure, stage1 xgcc miscompiles gengtype-lex.l gengtype SEGVs
Building released gcc-4.4.4 on ia64-hp-hpux11.23 and 11.31 fails: echo timestamp s-gtyp-input build/gengtype /opt/build/gcc-4.4.4/gcc gtyp-input.list gmake[3]: *** [s-gtype] Segmentation fault (core dumped) Program terminated with signal 11, Segmentation fault. SEGV_MAPERR - Address not mapped to object #0 0x401dd80:0 in yylex (yylval=0x40011a0c) at gengtype-lex.l:193 193 gengtype-lex.l: No such file or directory. in gengtype-lex.l Rebuilding gengtype-lex.o and gengtype with -O2 -fno-schedule-insns works. The build was bootstrapped with gcc-4.2.4. -- Summary: bootstrap failure, stage1 xgcc miscompiles gengtype- lex.l gengtype SEGVs Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla-gcc at thewrittenword dot com GCC build triplet: ia64-hp-hpux11.31 GCC host triplet: ia64-hp-hpux11.31 GCC target triplet: ia64-hp-hpux11.31 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44655
[Bug testsuite/44654] check-fortran / gfortran.dg/dg.exp ignores test specification in RUNTESTFLAGS
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-24 15:22 --- (In reply to comment #3) It's supposed to specify the testsuite driver. That it does, but then it forgets that it was supposed to run a specific test. dg.exp=files_to_test does it (without path). Well, an awfulk lot of drivers are named dg.exp, so I wasn't sure it it was specific enough. I know when I do this with check-gcc one level up, I get lots of matches. When I try an absolute pathname, I get an error. A relative pathname with anything more that gfortran/dg.exp doesn't match anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44654
[Bug testsuite/44654] check-fortran / gfortran.dg/dg.exp ignores test specification in RUNTESTFLAGS
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-24 15:31 --- See comment #1. check-fortran already selects from the various dg.exps. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44654
[Bug fortran/40158] Misleading error message for passing a scalar to an array
--- Comment #3 from pault at gcc dot gnu dot org 2010-06-24 15:31 --- (In reply to comment #2) Paul, any reason not to commit the patch in comment #1? No! I'll try to get to it on Sunday. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40158
[Bug fortran/43179] ICE invalid if accessing array member of non-array
--- Comment #5 from pault at gcc dot gnu dot org 2010-06-24 15:42 --- (In reply to comment #4) (In reply to comment #2) OK for trunk with the usual embellishments of ChangeLogs and testcase? Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim that EXPR_VARIABLE is enough. Paul, any plans to wrap this up? :) Daniel, Another one for Sunday, or thereabouts. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
[Bug fortran/43841] Missing temporary for ELEMENTAL function call
--- Comment #11 from pault at gcc dot gnu dot org 2010-06-24 15:44 --- (In reply to comment #10) Any backport ? Ah yes, thanks, Mikael I have drawn up a list of PRs for which I have fixes but have not made commits. I'll try to get through them next week. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43841
[Bug tree-optimization/44656] New: VN should value-replace operands during alias-oracle walk
For gcc.dg/tree-ssa/loadpre6.c we see at FRE time
# PT = { HEAP.9 } (glob)
# USE = anything
# CLB = anything
unexpanded_var_list.0_25 = malloc (16);
unexpanded_var_list = unexpanded_var_list.0_25;
# PT = nonlocal escaped { HEAP.9 HEAP.10 } (glob)
unexpanded_var_list.1_27 = unexpanded_var_list;
unexpanded_var_list.1_27-list.value = 0B;
# PT = nonlocal escaped { HEAP.9 HEAP.10 } (glob)
unexpanded_var_list.1_32 = unexpanded_var_list;
unexpanded_var_list.1_32-common.chain = 0B;
# PT = nonlocal escaped { HEAP.9 HEAP.10 } (glob)
last_34 = unexpanded_var_list;
where when looking up the load in the stmt setting last_34 it is
not disambiguated against unexpanded_var_list.1_32-common.chain
as unexpanded_var_list.1_32 is not value-replaced by
unexpanded_var_list.0_25 and thus stays with the weaker points-to
information.
--
Summary: VN should value-replace operands during alias-oracle
walk
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization, alias
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44656
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-24 16:21 ---
Created an attachment (id=20997)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20997action=view)
unswitch-tuplification.patch
While the validity of the testcase is questionable, what unswitching does looks
certainly wrong.
I'm attaching two small patches that fix things I've found while reading
tree-ssa-loop-unswitch.
The real problem for this testcase though seems to be that there is no
unreachable block removal in between the unswitching levels, so it can very
well choose to unswitch on a condition that is never reachable in the
unswitched loop.
Say there is
while (...)
{
if (cond1)
{
if (cond2)
A
else
B
}
else
{
if (cond3)
C
else
D
}
E
}
The first level chooses to unswitch on the cond1 condition, so we have:
if (cond1)
while (...)
{
if (1 != 0)
{
if (cond2)
A
else
B
}
else
{
if (cond3)
C
else
D
}
E
}
else
while (...)
{
if (0 != 0)
{
if (cond2)
A
else
B
}
else
{
if (cond3)
C
else
D
}
E
}
Now, in the first loop if we decide to unswitch on cond3, it transforms this
into:
if (cond1)
{
if (cond3)
while (...)
{
if (1 != 0)
{
if (cond2)
A
else
B
}
else
{
if (1 != 0)
C
else
D
}
E
}
else
while (...)
{
if (1 != 0)
{
if (cond2)
A
else
B
}
else
{
if (0 != 0)
C
else
D
}
E
}
}
else
while (...)
{
if (0 != 0)
{
if (cond2)
A
else
B
}
else
{
if (cond3)
C
else
D
}
E
}
If cond3 tests some variable that is initialized only if cond1 is false, this
unswitching (besides not being very useful because cond3 is never tested when
cond1 is false in the original program) results in jumps on uninitialized
values comparison.
Anyway, this first patch tries to fix a bug caused by tuplification. Before
tuplification, COND_EXPR_COND would be 0 or 1 when optimized, but 0 != 0 or 1
!= 0 condition never satisfies integer_zerop nor integer_nonzerop. We could
fold it, but we already have predicates for this stuff.
This patch actually causes more unswitching to happen, because it never
unswitches on 0 != 0 or 1 != 0 conditions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #12 from jakub at gcc dot gnu dot org 2010-06-24 16:24 --- Created an attachment (id=20998) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20998action=view) level-opt.patch When we reach the max-unswitch-level param, the function returns immediately, which means the conditions the last unswitching optimized aren't simplified (likely that happens in some later optimization passes, but unswitching has code to handle it, so I think it won't hurt to do it immediately). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #13 from jakub at gcc dot gnu dot org 2010-06-24 16:47 ---
For the last issue, perhaps doing delete_unreachable_blocks in between the
levels wouldn't work too well, loops would need to be discovered again etc.
Maybe we can just do something similar to find_unreachable_blocks
limited only to the loop bbs and ignoring false resp. true edges if
gimple_cond_{true,false}_p on the last stmt and not consider as loop
unswitching candidate any bb's that aren't reachable from the header in the
loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug c/44657] New: GCCSense: merge code-assist branch, or plugin
Some impressive code-completion features have been implemented as part of GCCSense, providing accurate editor-agnostic code completion. http://cx4a.org/software/gccsense/ This required some GCC modifications, and thus requires a customized compiler. It would be very useful if these modifications were merged upstream, or could at least be implemented as a plugin. Repository here: http://cx4a.org/repo/gcc.git -- Summary: GCCSense: merge code-assist branch, or plugin Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugs at 59A2 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44657
[Bug other/44658] New: ARM/NEON VSHLL instruction/intrinsic must allow shifts by 0
This is really a reopen of bug #41196 vshll, q3, d7, #0 is valid but the compiler and assembler choke on it and/or intrinsic. I assume that is because the fix from #41196 tests for shifts greater than 0. However, the zero shift is valid and needed for cheap precision expansion (i.e., vmovl). -- Summary: ARM/NEON VSHLL instruction/intrinsic must allow shifts by 0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gmcgrath at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44658
[Bug other/44658] ARM/NEON VSHLL instruction/intrinsic must allow shifts by 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-24 17:34 --- If the assembler is choping on it, please report it to binutils: http://sourceware.org/bugzilla . GCC is not the assembler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44658
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- Comment #23 from jakub at gcc dot gnu dot org 2010-06-24 17:48 ---
Subject: Bug 44492
Author: jakub
Date: Thu Jun 24 17:48:16 2010
New Revision: 161328
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161328
Log:
PR middle-end/44492
* recog.h (struct recog_data): Add is_asm field.
* recog.c (asm_operand_ok, constrain_operands): If neither nor is
present in constraints of inline-asm operand and memory operand
contains {PRE,POST}_{INC,DEC,MODIFY}, return 0.
(extract_insn): Initialize recog_data.is_asm.
* doc/md.texi (Constraints): Document operand side-effect rules.
* g++.dg/torture/pr44492.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/torture/pr44492.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/md.texi
trunk/gcc/recog.c
trunk/gcc/recog.h
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug c/44657] GCCSense: merge code-assist branch, or plugin
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-24 17:56 --- Nice! But to get anything merged to GCC you need first a copyright assignment. Otherwise, we cannot even look at your code. http://gcc.gnu.org/contribute.html#legal For implementing this as a plugin, you do not need anything from the GCC project (do you?). So there is no need to open a PR. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44657
[Bug target/44659] New: Combiner fails to match cmp patterns with upper 8bit register
After fixing PR 44588, I got
[...@gnu-6 divb]$ cat umod-4.c
int
foo (unsigned char x, unsigned char y)
{
return (x % y) != 0;
}
[...@gnu-6 divb]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -c -o umod-4.o umod-4.c
[...@gnu-6 divb]$ cat umod-4.s
.file umod-4.c
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movzbl %dil, %eax
divb%sil
movzbl %ah, %eax
testb %al, %al
setne %al
movzbl %al, %eax
ret
We can generate
testb %ah, %ah
instead of
movzbl %ah, %eax
testb %al, %al
The combine pass shows
Trying 11 - 13:
Failed to match this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (subreg:QI (lshiftrt:SI (subreg:SI (reg:HI 69) 0)
(const_int 8 [0x8])) 0)
(const_int 0 [0])))
with
(insn 11 10 13 2 umod-4.c:4 (set (reg:QI 67)
(subreg:QI (zero_extract:SI (reg:HI 69)
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)) 90 {*movqi_extzv_2_rex64}
(expr_list:REG_DEAD (reg:HI 69)
(expr_list:REG_EQUAL (umod:QI (reg/v:QI 61 [ x ])
(reg/v:QI 63 [ y ]))
(nil
(insn 13 11 14 2 umod-4.c:4 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 67)
(const_int 0 [0]))) 0 {*cmpqi_ccno_1} (expr_list:REG_DEAD (reg:QI
67)
(nil)))
i386.md has
(define_insn *cmpqi_ext_2
[(set (reg FLAGS_REG)
(compare
(subreg:QI
(zero_extract:SI
(match_operand 0 ext_register_operand Q)
(const_int 8)
(const_int 8)) 0)
(match_operand:QI 1 const0_operand )))]
ix86_match_ccmode (insn, CCNOmode)
test{b}\t%h0, %h0
[(set_attr type test)
(set_attr length_immediate 0)
(set_attr mode QI)])
According to
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02477.html
(set (reg:CCZ 17 flags)
(compare:CCZ (subreg:QI (lshiftrt:SI (subreg:SI (reg:HI 69) 0)
(const_int 8 [0x8])) 0)
(const_int 0 [0])))
is the standard form within combine.c. The questions are
1. Why doesn't combiner match QI cmp patterns with zero_extract?
2. Should i386.md provide QI cmp patterns with lshiftrt for
combiner?
3. Does i386.md need QI cmp patterns with zero_extract if they aren't
used by combiner?
--
Summary: Combiner fails to match cmp patterns with upper 8bit
register
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44659
[Bug middle-end/12392] very long optimized compile
--- Comment #32 from aoliva at gcc dot gnu dot org 2010-06-24 17:58 --- I don't see how a bug reported in 2003 against 3.2 and marked as failing up to 4.0 could possibly be related in any way with VTA. Clearly that bug was fixed. Sure, VTA does perform poorly with these testcases, but this is not the bug that was reported, and we already have other bugs about VTA performance. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
[Bug c/44657] GCCSense: merge code-assist branch, or plugin
--- Comment #2 from bugs at 59A2 dot org 2010-06-24 18:08 --- Thanks, I have notified the author. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44657
[Bug other/44658] ARM/NEON VSHLL instruction/intrinsic must allow shifts by 0
--- Comment #2 from gmcgrath at yahoo dot com 2010-06-24 18:16 --- It is seen at the highest level in GCC using the ARM NEON intrinsic: uint16x8_t vshll_n_u8(uint8x8_t a, __constrange(0,8) int b); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44658
[Bug target/44588] Very inefficient 8bit mod/div
--- Comment #5 from hjl at gcc dot gnu dot org 2010-06-24 18:20 --- Subject: Bug 44588 Author: hjl Date: Thu Jun 24 18:20:28 2010 New Revision: 161329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161329 Log: Implement 8bit divmod patterns. gcc/ 2010-06-24 H.J. Lu hongjiu...@intel.com PR target/44588 * config/i386/i386.md (extract_code): New. (udivmodqi4): Likewise. (divmodhiqi3): Likewise. (udivmodhiqi3): Likewise. (udivqi3): Remvoved. gcc/testsuite/ 2010-06-24 H.J. Lu hongjiu...@intel.com PR target/44588 * gcc.target/i386/mod-1.c: New. * gcc.target/i386/umod-1.c: Likewise. * gcc.target/i386/umod-2.c: Likewise. * gcc.target/i386/umod-3.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44588
[Bug target/44588] Very inefficient 8bit mod/div
--- Comment #6 from hjl at gcc dot gnu dot org 2010-06-24 18:21 --- Subject: Bug 44588 Author: hjl Date: Thu Jun 24 18:21:21 2010 New Revision: 161330 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161330 Log: Add missing testcases for PR 44588. Added: trunk/gcc/testsuite/gcc.target/i386/mod-1.c trunk/gcc/testsuite/gcc.target/i386/umod-1.c trunk/gcc/testsuite/gcc.target/i386/umod-2.c trunk/gcc/testsuite/gcc.target/i386/umod-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44588
[Bug other/44658] ARM/NEON VSHLL instruction/intrinsic must allow shifts by 0
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-24 18:28 --- Can you provide a full example that gives the error? And what is the exact error that is being generated? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44658
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-06-24 20:49 --- Both patches look ok. For the remaining issue it would probably work to not copy unreachable blocks during unswitching? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug c++/44625] [4.3/4.4/4.5/4.6 Regression] ICE after error: anonymous struct not inside named type
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44625
[Bug c++/44645] [4.5 Regression] wrong debug info for nested typedef
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug target/44531] [4.5/4.6 Regression] [SH] Multilib configuration does not work as expected on darwin
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44531
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug tree-optimization/44137] [4.6 Regression]: objc.dg/torture/tls/thr-init-2.m and thr-init.m
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44137
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug bootstrap/44335] [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
[Bug libgcj/44341] [4.6 Regression] libjava cross build fails when configured with --with-gmp=
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44341
[Bug bootstrap/44458] [4.6 Regression] Bootstrap fails on arm_float_words_big_endian implicit declaration when Ada on arm-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458
[Bug lto/44533] [4.6 Regression] Revision 160679 miscompiles capacita.f90 with -O3 -finline-limit=600 -flto
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44533
[Bug tree-optimization/44562] [4.6 Regression] ICE: in get_alias_set, at alias.c:716 with -flto -fstrict-aliasing -fgraphite-identity
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44562
[Bug fortran/44565] [4.6 Regression] [OOP] ICE in gimplify_expr with array-valued generic TBP
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44565
[Bug fortran/44584] [4.6 Regression] Invalid memory access with gfortran.dg/typebound_proc_15.f03
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug c++/44590] [4.6 Regression] Revision 159362 caused multiple failures on the libstdc++-v3 tests
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44590
[Bug target/44597] [4.6 Regression] FAIL: gcc.c-torture/execute/builtin-prefetch-2.c compilation, ICE
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44597
[Bug fortran/44622] [4.6 Regression] ICE in gfc_typenode_for_spec
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44622
[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-24 21:38 --- If nobody tests and submits this patch the issue will be not fixed for 4.5.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44393
[Bug rtl-optimization/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-24 21:40 --- Seems to be confirmed at least. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|bootstrap |rtl-optimization Ever Confirmed|0 |1 Keywords||build Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2010-06-24 21:40:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469
[Bug target/44531] [4.5/4.6 Regression] [SH] Multilib configuration does not work as expected on darwin
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44531
[Bug tree-optimization/44545] [4.5/4.6 Regression] internal compiler error: in remove_unreachable_handlers, at tree-eh
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44545
[Bug c/44555] [4.3/4.4/4.5 Regression] Pointer evalutions, is that expected ?
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44555
[Bug target/44575] [4.5 Regression] __builtin_va_arg overwrites into adjacent stack location
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.6.0 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
[Bug c++/44587] [4.4/4.5/4.6 Regression] ICE in instantiate_decl
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-24 21:45 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid, ice-on- ||invalid-code Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2010-06-24 21:45:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug middle-end/44592] [4.5/4.6 Regression] wrong code at -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-24 21:58 --- Fails also at -O2 -funroll-loops. I can't see anything wrong with the tree-level code. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2010-06-24 21:58:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
[Bug c++/44625] [4.3/4.4/4.5/4.6 Regression] ICE after error: anonymous struct not inside named type
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44625
[Bug c++/44628] [4.3/4.4/4.5/4.6 Regression] ICE in cp_build_unary_op at cp/typeck.c:4671
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44628
[Bug c++/44629] [4.3/4.4/4.5/4.6 Regression] ICE in unify, at cp/pt.c:15155
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44629
[Bug target/44632] [4.4/4.5/4.6 regression] wrong code for complex division
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug c++/44645] [4.5 Regression] wrong debug info for nested typedef
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug fortran/44622] [4.6 Regression] ICE in gfc_typenode_for_spec
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-24 22:04 --- can reproduce this anymore, closing as fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44622
[Bug testsuite/43283] ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o
--- Comment #7 from sje at gcc dot gnu dot org 2010-06-24 22:31 --- Subject: Bug 43283 Author: sje Date: Thu Jun 24 22:31:23 2010 New Revision: 161342 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161342 Log: 2010-06-24 Steve Ellcey s...@cup.hp.com PR testsuite/43283 * gcc.dg/lto/20091216-1_0.c: Use newline instead of semicolon and add argument to nop for IA64. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lto/20091216-1_0.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43283
[Bug rtl-optimization/44659] Combiner fails to match QI cmp patterns with upper 8bit register
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-24 22:41 --- X86 backend has special support for (zero_extract:SI (reg:M N) (const_int 8) (const_int 8)) If backend provides zero_extract, shouldn't we preserve it? -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44659
[Bug rtl-optimization/44659] Combiner fails to match QI cmp patterns with upper 8bit register
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-24 22:43 ---
Created an attachment (id=20999)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20999action=view)
A patch
With this patch, I got
[...@gnu-6 divb]$ cat umod-4.c
int
foo (unsigned char x, unsigned char y)
{
return (x % y) != 0;
}
[...@gnu-6 divb]$ make umod-4.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -S umod-4.c
[...@gnu-6 divb]$ cat umod-4.s
.file umod-4.c
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movzbl %dil, %eax
divb%sil
testw $-256, %ax
setne %al
movzbl %al, %eax
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44659
