[Bug tree-optimization/26821] [4.1/4.2 Regression] ice in varasm.c with certain flags
--- Comment #5 from bonzini at gnu dot org 2006-04-18 08:08 --- Subject: Bug 26821 Author: bonzini Date: Tue Apr 18 08:08:47 2006 New Revision: 113025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113025 Log: 2006-04-18 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/26821 * tree-ssa-math-opts.c (get_constant_one): New. (insert_reciprocals): Use it. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-recip.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26821
[Bug ada/27194] New: raised CONSTRAINT_ERROR : gnatvsn.adb:60 index check failed
gcc/ada/gnatvsn.adb assumes that the version_string defined in gcc/version.c never exceeds a maximum length which it defines to be 32 (in gcc/ada/gnatvsn.ads). Under certain circumstances (e.g. experimental GCC with a date, plus a version suffix), this assumption is wrong. The function GNATVSN.Gnat_Version_String has a bug whereby it will raise Constraint_Error if it reaches the end of the 32 characters before finding a null character. The attached patch fixes both problems by increasing the maximum length, and fixing the function so it never raises an exception. -- Ludovic Brenta. -- Summary: raised CONSTRAINT_ERROR : gnatvsn.adb:60 index check failed Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27194
[Bug ada/27194] raised CONSTRAINT_ERROR : gnatvsn.adb:60 index check failed
--- Comment #1 from ludovic at ludovic-brenta dot org 2006-04-18 08:13 --- Created an attachment (id=11290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11290&action=view) Proposed fix for PR 27194 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27194
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #9 from bonzini at gnu dot org 2006-04-18 08:13 --- I'm reverting the PR19653 regclass.c patch for now. Joern of course if you want to post your patch for testing, it'll help reinstating the patch in 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug preprocessor/27195] New: hex and oct constants are converted to wrong type
The C99 standard states (6.4.4.1) that integer constants without a suffix are converted to the first of the following types that can represent their value: decimal constants: 1) int 2) long 3) long long hex/oct constants: 1) int 2) unsigned int 3) long 4) unsigned long 5) long long 6) unsigned long long This works fine in the preprocessed code, but not within constant preprocessor expressions, e.g.: #define XS 0x7fff #if XS > -1 int xs = 1; #else int xs = 0; #endif In this case, XS fits into an (int) and thus the comparison is signed, resulting in xs == 1. #define XU 0x8000 #if XU > -1 int xu = 1; #else int xu = 0; #endif In this case, XU does not fit into an (int) and should rather be an (unsigned), causing the -1 to be promoted and causing the comparison to be unsigned, resulting in xu == 0. However, it seems that the second case isn't handled correctly by the gcc preprocessor, as it takes the xu == 1 path. The attached code snippet shows that the gcc preprocessor doesn't make a difference between dec/hex/oct constants, while the gcc compiler does. The behaviour of the compiler looks correct to me. Compile and run with: gcc -std=c99 -o const const.c ./const I'd expect the output to be: 1 - 0 1 - 0 1 - 0 1 - 0 1 - 1 1 - 1 However, the output of my gcc-4.2 is $ gcc-4.2 -std=c99 -o const const.c && ./const 1 - 1 1 - 0 1 - 1 1 - 0 1 - 1 1 - 1 My gcc was compiled with: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20060225/configure --program-suffix=-4.2 --prefix=/home/mhx/gcc/gcc-4.2-20060225 --enable-languages=c,c++ --disable-nls Thread model: posix gcc version 4.2.0 20060225 (experimental) I've checked that the Intel C/C++ compiler (version 9.0) produces the correct output: $ icc -std=c99 -o const const.c && ./const 1 - 0 1 - 0 1 - 0 1 - 0 1 - 1 1 - 1 Marcus -- Summary: hex and oct constants are converted to wrong type Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mhx-perl at gmx dot net 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=27195
[Bug preprocessor/27195] hex and oct constants are converted to wrong type
--- Comment #1 from mhx-perl at gmx dot net 2006-04-18 08:17 --- Created an attachment (id=11291) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11291&action=view) test code to reproduce the described behaviour -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27195
[Bug preprocessor/27195] hex and oct constants are converted to wrong type
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-18 08:21 --- 6.10.1/3 The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6, except that all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header . -- 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=27195
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #10 from bonzini at gnu dot org 2006-04-18 08:23 --- Subject: Bug 27117 Author: bonzini Date: Tue Apr 18 08:23:39 2006 New Revision: 113026 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113026 Log: 2006-04-18 Paolo Bonzini <[EMAIL PROTECTED]> PR target/27117 Partial revert of revision 112637 2006-04-03 Paolo Bonzini <[EMAIL PROTECTED]> Dale Johannesen <[EMAIL PROTECTED]> PR target/19653 * regclass.c (struct reg_pref): Update documentation. (regclass): Set prefclass to NO_REGS if memory is the best option. (record_reg_classes): Cope with a prefclass set to NO_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/regclass.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Comment #26 from bonzini at gnu dot org 2006-04-18 08:23 --- Subject: Bug 19653 Author: bonzini Date: Tue Apr 18 08:23:39 2006 New Revision: 113026 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113026 Log: 2006-04-18 Paolo Bonzini <[EMAIL PROTECTED]> PR target/27117 Partial revert of revision 112637 2006-04-03 Paolo Bonzini <[EMAIL PROTECTED]> Dale Johannesen <[EMAIL PROTECTED]> PR target/19653 * regclass.c (struct reg_pref): Update documentation. (regclass): Set prefclass to NO_REGS if memory is the best option. (record_reg_classes): Cope with a prefclass set to NO_REGS. Modified: trunk/gcc/ChangeLog trunk/gcc/regclass.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug c/27190] Support for multiline string constant
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-18 08:34 --- Support for this was ripped out of gcc in 3.4 I think. It won't come back. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27190
[Bug middle-end/27095] [4.1 Regression] O2 produces duplicate code
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-18 09:02 --- Fixed on the mainline. Btw, this is really wrong-code. Can you apply to the 4.1 branch, too, please? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc-*-* | Keywords|missed-optimization |wrong-code Summary|[4.1/4.2 Regression] O2 |[4.1 Regression] O2 produces |produces duplicate code |duplicate code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-18 10:43
---
Hi Mark,
I was just testing the following btw.:
===
--- gcc/gcc/cp/parser.c (revision 112814)
+++ gcc/gcc/cp/parser.c (working copy)
@@ -10930,6 +10930,12 @@ cp_parser_init_declarator (cp_parser* parser,
we compute it now. */
scope = get_scope_of_declarator (declarator);
+ if (scope && TYPE_P (scope) && !CLASS_TYPE_P (scope))
+{
+ error ("type %qT is not allowed in declaration", scope);
+ return error_mark_node;
+}
+
/* If we're allowing GNU extensions, look for an asm-specification
and attributes. */
if (cp_parser_allow_gnu_extensions_p (parser))
===
This should also fix PR 11471.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00658.html Status|REOPENED|ASSIGNED Last reconfirmed|2006-03-13 17:15:39 |2006-04-18 10:59:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug c/27153] function result is dereferenced error
--- Comment #11 from joseph at codesourcery dot com 2006-04-18 11:17 --- Subject: Re: function result is dereferenced error On Tue, 18 Apr 2006, falk at debian dot org wrote: > Uhm, this has nothing to do at all with evaluation order. Evaluation > order of arguments is unspecified (not undefined, which wouldn't make a > lot of sense), but that is in fact irrelevant here, it could lead to, > say, 3 1 2, but not 1 1 1. > > The actual problem is that val is modified more than once without an > intervening sequence point, which makes the behavior undefined. No, this testcase is unspecified, not undefined. There are intervening sequence points at the start and end of each call to function, and function calls do not overlap (DR#087); each call to func suspends the execution of main until func returns. However, the evaluation of the arguments to printf may overlap and the order is unspecified, so there are many possible outputs from the program (but "3 2 1" and "3 1 1", for example, are not possible). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug preprocessor/27195] hex and oct constants are converted to wrong type
--- Comment #3 from joseph at codesourcery dot com 2006-04-18 11:22 --- Subject: Re: hex and oct constants are converted to wrong type On Tue, 18 Apr 2006, rguenth at gcc dot gnu dot org wrote: > 6.10.1/3 > > The resulting tokens > compose the controlling constant expression which is evaluated according to > the > rules of > 6.6, except that all signed integer types and all unsigned integer types act > as > if they have > the same representation as, respectively, the types intmax_t and uintmax_t > defined > in the header . I recommend quoting the current standard as amended by TC2, which makes this specific case even clearer in response to DR#265: The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. For the purposes of this token conversion and evaluation, all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header .142) 142) Thus, on an implementation where INT_MAX is 0x7FFF and UINT_MAX is 0x, the constant 0x8000 is signed and positive within a #if expression even though it would be unsigned in translation phase 7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27195
[Bug middle-end/27095] [4.1 Regression] O2 produces duplicate code
--- Comment #7 from amodra at gcc dot gnu dot org 2006-04-18 12:34 --- Subject: Bug 27095 Author: amodra Date: Tue Apr 18 12:34:07 2006 New Revision: 113030 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113030 Log: PR middle-end/27095 * builtins.c: (expand_builtin_memset): Stabilize args before expansion and emit libcall here in case the builtin fails. (expand_builtin_strcmp): Always emit the libcall here on failure. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug middle-end/27095] [4.1 Regression] O2 produces duplicate code
--- Comment #8 from amodra at bigpond dot net dot au 2006-04-18 12:35 --- As Roger requested, I was waiting a few days to apply the patch on the 4.1 branch. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Priority|P2 |P3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug c/27153] function result is dereferenced error
--- Comment #12 from falk at debian dot org 2006-04-18 12:37 --- (In reply to comment #11) > No, this testcase is unspecified, not undefined. There are intervening > sequence points at the start and end of each call to function OK. > However, the evaluation of the > arguments to printf may overlap and the order is unspecified, so there are > many possible outputs from the program (but "3 2 1" and "3 1 1", for > example, are not possible). I don't understand why is "3 2 1" is not possible. How about "1 1 1"? Is this a bug in gcc after all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
Re: [Bug c/27153] function result is dereferenced error
On Tue, 18 Apr 2006, falk at debian dot org wrote: > > However, the evaluation of the > > arguments to printf may overlap and the order is unspecified, so there are > > many possible outputs from the program (but "3 2 1" and "3 1 1", for > > example, are not possible). > > I don't understand why is "3 2 1" is not possible. How about "1 1 1"? Is > this a bug in gcc after all? "1 1 1" is possible: first evaluate func(3), then func(2), then func(1), then do all the dereferences. To get "3 2 1", the initial "3" requires func(3) to be evaluated between the evaluation of func(1) and its dereference, so func(3) is evaluated after func(1); but likewise the final "1" requires func(1) to be evaluated after func(3). -- Joseph S. Myers [EMAIL PROTECTED]
[Bug c/27153] function result is dereferenced error
--- Comment #13 from joseph at codesourcery dot com 2006-04-18 12:57 --- Subject: Re: function result is dereferenced error On Tue, 18 Apr 2006, falk at debian dot org wrote: > > However, the evaluation of the > > arguments to printf may overlap and the order is unspecified, so there are > > many possible outputs from the program (but "3 2 1" and "3 1 1", for > > example, are not possible). > > I don't understand why is "3 2 1" is not possible. How about "1 1 1"? Is > this a bug in gcc after all? "1 1 1" is possible: first evaluate func(3), then func(2), then func(1), then do all the dereferences. To get "3 2 1", the initial "3" requires func(3) to be evaluated between the evaluation of func(1) and its dereference, so func(3) is evaluated after func(1); but likewise the final "1" requires func(1) to be evaluated after func(3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-04-18 13:14 --- Subject: Re: [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009 > Preprocessed source? Attached. Dave --- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-04-18 13:14 --- Created an attachment (id=11293) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11293&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug tree-optimization/26821] [4.1 Regression] ice in varasm.c with certain flags
--- Comment #6 from bonzini at gnu dot org 2006-04-18 13:24 --- Subject: Bug 26821 Author: bonzini Date: Tue Apr 18 13:24:45 2006 New Revision: 113036 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113036 Log: 2006-04-18 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/26821 Backport from mainline: 2006-04-18 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/26821 * tree-ssa-math-opts.c (get_constant_one): New. (insert_reciprocals): Use it. 2006-02-02 Paolo Bonzini <[EMAIL PROTECTED]> * tree-flow-inline.h (bsi_after_labels): Rewrite, return what its name says. * lambda-code.c (perfect_nestify): Use bsi_insert_before on bsi_after_labels iterator. * tree-if-conv.c (find_phi_replacement_condition, replace_phi_with_cond_modify_expr): Likewise. * tree-scalar-evolution.c (scev_const_prop): Likewise. * tree-ssa-loop-ivopts.c (compute_phi_arg_on_exit): Likewise. 2006-04-18 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/26821 * gcc.dg/vect/vect-recip.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/vect-recip.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/lambda-code.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-flow-inline.h branches/gcc-4_1-branch/gcc/tree-if-conv.c branches/gcc-4_1-branch/gcc/tree-scalar-evolution.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c branches/gcc-4_1-branch/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26821
[Bug tree-optimization/26821] [4.1 Regression] ice in varasm.c with certain flags
--- Comment #7 from bonzini at gnu dot org 2006-04-18 13:25 --- patch committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.3 4.2.0 |4.0.3 4.1.1 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26821
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #11 from bonzini at gnu dot org 2006-04-18 13:26 --- bug is latent again :-) -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug preprocessor/27195] hex and oct constants are converted to wrong type
--- Comment #4 from mhx-perl at gmx dot net 2006-04-18 13:26 --- Subject: Re: hex and oct constants are converted to wrong type On 2006-04-18, at 11:22:00 -, joseph at codesourcery dot com wrote: > 142) Thus, on an implementation where INT_MAX is 0x7FFF and UINT_MAX is > 0x, the constant 0x8000 is signed and positive within a #if > expression even though it would be unsigned in translation phase 7. Thanks for that quote! So it's the Intel compiler that is actually wrong (even though its behaviour seemed more consistent to me in the first place), as it reuses the system's stdint.h, which defines intmax_t and uintmax_t as 64-bit types. Thanks again and sorry for the bogus report, Marcus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27195
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #8 from bonzini at gnu dot org 2006-04-18 13:47 --- Seems similar to PR24230, but cannot be fixed really in the same way. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug middle-end/26913] ICE with -fopenmp and -O1
-- 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 | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00662.html Status|NEW |ASSIGNED Last reconfirmed|2006-03-29 15:44:04 |2006-04-18 13:50:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26913
[Bug middle-end/26869] [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands.
--- Comment #4 from bonzini at gnu dot org 2006-04-18 13:55 --- richi: if bD.1520 does not have a default def because it is unused, your fix makes sense. Can you confirm that it is "b" and not "c" that does not have a default def, i.e. that "c" does have a default def? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26869
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #6 from bonzini at gnu dot org 2006-04-18 14:07 --- pinskia: You're right in some sense but, shudder, this will make things slw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug middle-end/26869] [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands.
--- Comment #5 from rguenther at suse dot de 2006-04-18 14:07 --- Subject: Re: [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands. On Tue, 18 Apr 2006, bonzini at gnu dot org wrote: > richi: if bD.1520 does not have a default def because it is unused, your fix > makes sense. Can you confirm that it is "b" and not "c" that does not have a > default def, i.e. that "c" does have a default def? Yes, c has a default def. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26869
[Bug middle-end/26643] [4.1 Regression] Linux matroxfb_probe miscompiled
--- Comment #15 from bonzini at gnu dot org 2006-04-18 14:12 --- running a 4.1 bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug middle-end/26643] [4.1 Regression] Linux matroxfb_probe miscompiled
--- Comment #16 from rguenther at suse dot de 2006-04-18 14:14 --- Subject: Re: [4.1 Regression] Linux matroxfb_probe miscompiled > --- Comment #15 from bonzini at gnu dot org 2006-04-18 14:12 --- > running a 4.1 bootstrap. It's been in our SUSE tree for some while and so survived bootstrapping and testing on x86_64, i686, ppc, ppc64, s390, s390x and ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #8 from bonzini at gnu dot org 2006-04-18 14:15 --- Mark, I don't believe there is any chance that it be fixed in 4.0/4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug middle-end/20983] [4.0/4.1/4.2 Regression] varargs functions force va_list variable to stack unnecessarily
--- Comment #7 from bonzini at gnu dot org 2006-04-18 14:16 --- Caused by removing ADDRESSOF. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug middle-end/26643] [4.1 Regression] Linux matroxfb_probe miscompiled
--- Comment #18 from bonzini at gnu dot org 2006-04-18 14:23 --- patch committed to 4.1 too. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug middle-end/26643] [4.1 Regression] Linux matroxfb_probe miscompiled
--- Comment #17 from bonzini at gnu dot org 2006-04-18 14:23 --- Subject: Bug 26643 Author: bonzini Date: Tue Apr 18 14:22:59 2006 New Revision: 113041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113041 Log: 2006-04-18 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/26643 Backport from mainline: 2006-03-29 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/26643 * tree-ssa-loop-ivopts.c (find_interesting_uses_address): Do not handle bit_field_refs. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #9 from bonzini at gnu dot org 2006-04-18 14:29 --- The mem is for a (const_vector:V4SF [ (const_double:SF -NaN [-NaN]) (const_double:SF -NaN [-NaN]) (const_double:SF -NaN [-NaN]) (const_double:SF -NaN [-NaN]) ]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #10 from bonzini at gnu dot org 2006-04-18 14:39 --- It's probably two different bugs, since the 4.1 bug is in loop.c. We need to add a can_assign_to_reg_p call before creating a movable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug middle-end/26869] [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands.
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-18 14:46 --- I'll bootstrap & test the obvious patch then. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-25 20:54:30 |2006-04-18 14:46:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26869
[Bug middle-end/26869] [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands.
--- Comment #7 from paolo dot bonzini at lu dot unisi dot ch 2006-04-18 14:47 --- Subject: Re: [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands. rguenth at gcc dot gnu dot org wrote: > --- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-18 14:46 > --- > I'll bootstrap & test the obvious patch then. > It's *NOT* obvious. Please have it reviewed! Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26869
[Bug middle-end/26869] [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands.
--- Comment #8 from rguenther at suse dot de 2006-04-18 15:03 --- Subject: Re: [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands. On Tue, 18 Apr 2006, paolo dot bonzini at lu dot unisi dot ch wrote: > > I'll bootstrap & test the obvious patch then. > > > It's *NOT* obvious. Please have it reviewed! Oh, of course. I didn't mean it be interpreted this way ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26869
[Bug libstdc++/6257] C-library symbols enter global namespace
--- Comment #17 from marc dot glisse at normalesup dot org 2006-04-18 15:10 --- (In reply to comment #15) > So there's a problem with the multiple-include-protection in glibc! Yes, the way it is done in solaris is way more convenient. There, stdlib.h includes a file iso/stdlib_iso.h that has all the meat, and then stdlib.h does all the using std::foo; stuff, so cstdlib can just include iso/stdlib_iso.h directly. On solaris, I get quite satisfactory results with: g++ -I/opt/SUNWspro/prod/include/CC/std -D__cplusplus=199711L -U__EXTENSIONS__ -D__STDC__=0 (the include directory contains the cstd headers from sunpro, but they are just one or 2 #include lines) > But we can't do this in any manner because they have multiple-include > protection which can't tell the difference. gcc could come with its own stdlib.h. Both this stdlib.h and cstdlib would include /usr/include/stdlib.h (always with _GLIBCPP_USE_NAMESPACES) and the gcc provided stdlib.h would additionally contain the appropriate using std::foo; lines. The 2 problems I see with this approach are: 1) it means having 2 files with the same name in the search path, and inclusion of the glibc file has to be done with an explicit path of /usr/include (or some other compile time constant) 2) This will do what we want for standard functions, but what about extensions that are declared in stdlib.h in glibc (protected by __USE_ISOC99 or __USE_GNU for example), what happens to them? It might work well, I have not tested. > At the beginning of stdio.h, instead of: > #ifndef _STDIO_H > #define _STDIO_H > we would have: > #if ( ( defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES ) \ > && ! defined _STDIO_H_WITH_NAMESPACES ) \ >|| ( (! defined __cplusplus || ! defined _GLIBCPP_USE_NAMESPACES )\ > && ! defined _STDIO_H ) > #if defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES > # define _STDIO_H_WITH_NAMESPACES > #else > # define _STDIO_H > #endif This way you get 2 declarations instead of one and a using directive, I am not sure it won't cause problems (but I don't know). -- marc dot glisse at normalesup dot org changed: What|Removed |Added CC||marc dot glisse at ||normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #11 from bonzini at gnu dot org 2006-04-18 15:20 ---
... but then anyway the bug pops up in reload. So it is definitely the same
bug as PR24230, and here is a modified version of the PR24230 testcase:
/* Compile with -O2 -maltivec */
#define REGLIST \
"77", "78", "79", "80", "81", "82", "83", "84", "85", "86",\
"87", "88", "89", "90", "91", "92", "93", "94", "95", "96",\
"97", "98", "99", "100", "101", "102", "103", "104", "105", "106",\
"107", "108"
typedef __attribute__ ((vector_size (16))) float v4sf;
void
foo (int H)
{
volatile v4sf tmp;
while (H-- > 0)
{
asm ("" : : : REGLIST);
tmp = (v4sf) __builtin_altivec_vspltisw (1);
}
}
fails on 4.1, didn't test on 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug c++/27198] New: fstream is using fopen underly for 32b applictaions
There is 256 file descriptors limition for fopen(32 bits) under solaris.
Even worse these files descriptions has to be [0,255].
which means if you use open first than fopen, you get even less available file
descriptions for fopen. It is common for a server has more than 256 file
descrptions.
So I would think using open instead of fopen for solaris.
Here is the code I found
"basic_file.cc" line 250 of 362 --69%--
__basic_file*
__basic_file::open(const char* __name, ios_base::openmode __mode,
int /*__prot*/)
{
__basic_file* __ret = NULL;
const char* __c_mode = __gnu_internal::fopen_mode(__mode);
if (__c_mode && !this->is_open())
{
#ifdef _GLIBCXX_USE_LFS
if ((_M_cfile = fopen64(__name, __c_mode)))
#else
if ((_M_cfile = fopen(__name, __c_mode))) /// file description limited
to <256
#endif
{
_M_cfile_created = true;
__ret = this;
}
}
return __ret;
}
Thanks,
--
Summary: fstream is using fopen underly for 32b applictaions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zhong dot xie at yahoo dot ca
GCC build triplet: solaris
GCC host triplet: solaris
GCC target triplet: solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27198
[Bug c++/26534] [4.1/4.2 Regression] bitfield wrong optimize
--- Comment #4 from bonzini at gnu dot org 2006-04-18 15:27 --- And is the precision only encoded in FIELD_DECLs, for the C front-end as well? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #12 from tbm at cyrius dot com 2006-04-18 15:26 --- also fails on 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug libstdc++/27199] New: ptrdiff_t and size_t outside of namespace std
In ext/new_allocator.h and a few other files that declare things in namespace __gnu_cxx, size_t and ptrdiff_t are missing a std::. I know it does not break anything for a standard use, but such corrections will be necessary in order to clean the global namespace for systems like glibc or solaris where it is possible. Besides, there are files like bitmap_allocator.h where half the occurences of size_t have std:: in front and not the others. Thanks to people who work on g++, great tool. -- Summary: ptrdiff_t and size_t outside of namespace std Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marc dot glisse at normalesup dot org GCC host triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27199
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-18 16:05 --- Now it is a blocker if it happens on x86-linux-gnu also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker GCC target triplet|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||i386-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug c/27193] dump-tree-original-raw does not print the linkage for a variable with file scope.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-18 16:07 --- These files are for debuging gcc only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27193
[Bug fortran/27113] TODO: Complex array constructors in tonto-2.2
--- Comment #2 from pault at gcc dot gnu dot org 2006-04-18 16:10 ---
The fix turns out to be almost insulting: One type and one unnecessary gfc_todo
(not the original one, by the way!)
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 112981)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_trans_array_constructor_subarray (st
*** 1035,1043
gfc_copy_loopinfo_to_se (&se, &loop);
se.ss = ss;
- if (expr->ts.type == BT_CHARACTER)
- gfc_todo_error ("character arrays in constructors");
-
gfc_trans_array_ctor_element (&body, desc, *poffset, &se, expr);
gcc_assert (se.ss == gfc_ss_terminator);
--- 1035,1040
*** get_array_ctor_var_strlen (gfc_expr * ex
*** 1311,1317
/* Array references don't change the string length. */
break;
! case COMPONENT_REF:
/* Use the length of the component. */
ts = &ref->u.c.component->ts;
break;
--- 1308,1314
/* Array references don't change the string length. */
break;
! case REF_COMPONENT:
/* Use the length of the component. */
ts = &ref->u.c.component->ts;
break;
I will try to compile tonto-2.2 before submitting
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27113
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #3 from bonzini at gnu dot org 2006-04-18 16:12 --- Without getting in the merit of the bug, let me point out that GCC is *not* free to make hard errors at its own will. What is an error and what isn't is regulated by the standard, and GCC aims at adhering to the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-18 16:15 --- (In reply to comment #6) > pinskia: You're right in some sense but, shudder, this will make things > slw. No it will not. I and others have sped up the HWI being 64bit case as PPC-darwin was 32bit until the 64 in 32 mode came around and had to change. Please come back with real prove that GCC will slow down with the change instead of just saying it will because I have already speed it up at least twice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names
--- Comment #10 from bonzini at gnu dot org 2006-04-18 16:18 --- No, except in the unlikely case that the fix is hard to backport to 4.0.x. Backports to older release branches (in this case 4.0.x) are evaluated on a case-by-case basis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug rtl-optimization/26069] [4.0/4.1/4.2 Regression] Runtime endian-ness check is no longer optimized out.
--- Comment #8 from bonzini at gnu dot org 2006-04-18 16:22 --- Richard, Roger's patch for VIEW_CONVERT_EXPR folding hit mainline now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #16 from janis at gcc dot gnu dot org 2006-04-18 16:23 --- I verified that the failure starts with Jeff's patch: r110705 | law | 2006-02-07 10:31:27 -0800 (Tue, 07 Feb 2006) http://gcc.gnu.org/viewcvs?view=rev&rev=110705 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug target/11594] testcase gcc.dg/20020103-1.c fails with "scan-assembler-not LC"
--- Comment #5 from janis at gcc dot gnu dot org 2006-04-18 16:52 --- As of mainline 20060417 the test is still failing on powerpc-linux, although it passes for AIX and Darwin. Until December 2005 when Alan fixed the target specifier, the test had not been run on powerpc64-linux with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11594
[Bug libgcj/26858] NullPointerException not generated for large classes...
-- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug tree-optimization/27087] [4.1 regression] ICE in merge_alias_info
--- Comment #9 from law at gcc dot gnu dot org 2006-04-18 17:22 --- Subject: Bug 27087 Author: law Date: Tue Apr 18 17:22:05 2006 New Revision: 113051 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113051 Log: PR tree-optimization/27087 * tree-ssa-copy.c (may_propagate_copy): Test flow sensitive alias information too. * gcc.c-torture/compile/pr27087.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr27087.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-copy.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
[Bug tree-optimization/27087] [4.1 regression] ICE in merge_alias_info
--- Comment #10 from law at redhat dot com 2006-04-18 17:24 --- Patch installed on 4.1 branch too. -- law at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
[Bug c/27200] New: does not bootstrap: ICE in prune_unused_types_update_strings, at dwarf2out.c:14009
make[5]: Leaving directory `/home/marcus/projects/gcc/build/gcc' /home/marcus/projects/gcc/build/./gcc/xgcc -B/home/marcus/projects/gcc/build/./gcc/ -B/home/marcus/projects/gcc/BIN//x86_64-unknown-linux-gnu/bin/ -B/home/marcus/projects/gcc/BIN//x86_64-unknown-linux-gnu/lib/ -isystem /home/marcus/projects/gcc/BIN//x86_64-unknown-linux-gnu/include -isystem /home/marcus/projects/gcc/BIN//x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/home/marcus/projects/gcc/gcc -I/home/marcus/projects/gcc/gcc/. -I/home/marcus/projects/gcc/gcc/../include -I/home/marcus/projects/gcc/gcc/../libcpp/include -I/home/marcus/projects/gcc/gcc/../libdecnumber -I../libdecnumber -DL_muldi3 -fvisibility=hidden -DHIDE_EXPORTS -c /home/marcus/projects/gcc/gcc/libgcc2.c -o libgcc/./_muldi3.o /home/marcus/projects/gcc/gcc/libgcc2.c:520: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [libgcc/./_muldi3.o] Error 1 make[4]: Leaving directory `/home/marcus/projects/gcc/build/gcc' make[3]: *** [stmp-multilib] Error 2 make[3]: Leaving directory `/home/marcus/projects/gcc/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/marcus/projects/gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/marcus/projects/gcc/build' make: *** [all] Error 2 -- Summary: does not bootstrap: ICE in prune_unused_types_update_strings, at dwarf2out.c:14009 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27200
[Bug c/27200] does not bootstrap: ICE in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #1 from marcus at jet dot franken dot de 2006-04-18 17:35 --- this is Revision 113051. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27200
[Bug c/27200] does not bootstrap: ICE in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-18 17:35 --- *** This bug has been marked as a duplicate of 27188 *** -- 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=27200
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-18 17:35 --- *** Bug 27200 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||marcus at jet dot franken ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug tree-optimization/25737] [4.1/4.2 Regression] ACATS c974001 c974013 hang with struct aliasing
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2006-04-18 17:36 --- > It looks like there was a C testcase, which has now been fixed; is there still > an issue for languages other than Ada? I presume you meant is there still an issue for languages where everything is addressable? If so, very likely not. Now, for other languages, Daniel's patch has made things worse. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug libstdc++/6257] C-library symbols enter global namespace
--- Comment #18 from pcarlini at suse dot de 2006-04-18 17:49 --- Probably this PR should be suspended, while waiting for the resolution of DR 456: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug debug/27188] [4.2 Regression] libgcc2.c:382: internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14009
--- Comment #8 from sje at cup dot hp dot com 2006-04-18 18:34 --- I tried Geoff's patch from http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00651.html and that fixed my bootstrap failure on ia64-hp-hpux11.23. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27188
[Bug libgcj/27201] New: can't include cni.h and jni.h in the same file
Right now an external-to-libgcj program can't include both cni.h and jni.h from the same file. This is wrong. -- Summary: can't include cni.h and jni.h in the same file Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27201
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #5 from mark at codesourcery dot com 2006-04-18 19:41 --- Subject: Re: [4.0/4.1/4.2 regression] ICE with invalid class name in function template reichelt at gcc dot gnu dot org wrote: > --- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-18 10:43 > --- > Hi Mark, > I was just testing the following btw.: Thanks. I've got a rather more involved changed (with some other good cleanups) that I think is almost ready. I'm concerned that your change wouldn't be correct for friends in templates, which is usually the nasty case for these kinds of things. For example, I think "friend void T::f();" is valid, even if "T" is a template type parameter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug tree-optimization/27202] New: Missing optimiations with uint64_t
Consider the following code:
$ cat t.cc
#include
static inline uint32_t delinearize(uint32_t d)
{
return d*0x8088405+1;
}
uint64_t delinearize64(uint64_t d)
{
return (uint64_t(delinearize(d))<<32) | delinearize(d>>32);
}
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.1.0/work/gcc-4.1.0/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 4.1.0 (Gentoo 4.1.0)
$ g++ -fomit-frame-pointer -O2 -o t.S -S t.cc
$ cat t.S
.file "t.cc"
.text
.align 2
.p2align 4,,15
.globl _Z13delinearize64y
.type _Z13delinearize64y, @function
_Z13delinearize64y:
.LFB3:
pushl %ebx
.LCFI0:
xorl%edx, %edx
movl8(%esp), %ecx
movl12(%esp), %ebx
imull $134775813, %ecx, %eax
movl%ebx, %ecx
xorl%ebx, %ebx
imull $134775813, %ecx, %ecx
popl%ebx
incl%eax
movl%eax, %edx
movl$0, %eax
incl%ecx
orl %ecx, %eax
ret
.LFE3:
.size _Z13delinearize64y, .-_Z13delinearize64y
.globl __gxx_personality_v0
.ident "GCC: (GNU) 4.1.0 (Gentoo 4.1.0)"
.section.note.GNU-stack,"",@progbits
Well, that's way to complicated for such a "simple" operation. The whole
function can be written as:
_Z13delinearize64y:
imull $134775813, 8(%esp), %edx
imull $134775813, 12(%esp), %eax
incl%edx
incl%eax
ret
I also tested some gnu-4.2.0-alpha20060415 snapshot which generates different
(but not really better) code.
--
Summary: Missing optimiations with uint64_t
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sb at biallas dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27202
[Bug rtl-optimization/27202] Missing optimiations with uint64_t
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-18 20:42 --- I am 90% sure this is the normal subregister issue with 64bit on 32bit targets. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|tree-optimization |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27202
[Bug fortran/27113] TODO: Complex array constructors in tonto-2.2
--- Comment #3 from patchapp at dberlin dot org 2006-04-18 21:15 --- Subject: Bug number PR27113 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-04/msg00681.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27113
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-04-18 21:20 --- > For example, I think "friend void T::f();" is valid, even if "T" is a > template type parameter. Indeed. Ouch... We probably should have a testcase to cover this. Apparently, we don't have one yet. Otherwise, my invalid patch wouldn't have passed regtesting. But I guess, you already took care of this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/10385] Internal compiler error in build_up_reference, at cp/cvt.c:353, on invalid dynamic_cast
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-18 21:22 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10385
[Bug c++/26739] [4.2 regression] ICE in g++.old-deja/g++.pt/friend36.C
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-18 21:23 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26739
[Bug tree-optimization/27207] New: ICE: verify_cgraph_node failed
[ forwarded from http://bugs.debian.org/361602 ] I get the following ICE with gcc 4.2.0 20060415: (sid)4048:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -O2 -Werror mini.c cc1plus: warnings being treated as errors mini.c: In function 'void do_update(int)': mini.c:278: warning: deprecated conversion from string constant to 'char*'' mini.c: At global scope: mini.c:340: error: inlined_to pointer is set but no predecesors found virtual SlaveProgress::~SlaveProgress()/96: (inline copy in void do_update(int)/17) availability:available(15) 35 insns (309 after inlining) tree externally_visible finalized inlinable called by: calls: OpProgress::~OpProgress()/2 (inlined) void operator delete(void*)/64 mini.c:340: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -O2 -Werror mini.c (sid)4049:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -Werror mini.c cc1plus: warnings being treated as errors mini.c: In function 'void do_update(int)': mini.c:278: warning: deprecated conversion from string constant to 'char*'' zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -Werror mini.c (sid)4050:[EMAIL PROTECTED]: ~] Unfortunately, the test case reduced with delta is still fairly large. -- Summary: ICE: verify_cgraph_node failed Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27207
[Bug tree-optimization/27207] ICE: verify_cgraph_node failed
--- Comment #1 from tbm at cyrius dot com 2006-04-18 21:27 --- Created an attachment (id=11296) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11296&action=view) test case from delta -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27207
[Bug tree-optimization/27207] ICE: verify_cgraph_node failed
--- Comment #2 from tbm at cyrius dot com 2006-04-18 21:36 --- For the record, this happens on x86_64, but not on i386 or powerpc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27207
[Bug rtl-optimization/26026] power of 2 mod missing optimisation
--- Comment #3 from amodra at gcc dot gnu dot org 2006-04-18 23:45 --- Subject: Bug 26026 Author: amodra Date: Tue Apr 18 23:45:47 2006 New Revision: 113060 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113060 Log: PR rtl-optimization/26026 * fold-const.c (fold_binary): Optimize div and mod where the divisor is a known power of two shifted left a variable amount. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26026
[Bug rtl-optimization/26026] power of 2 mod missing optimisation
--- Comment #4 from amodra at bigpond dot net dot au 2006-04-18 23:46 --- Patch applied mainline -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26026
[Bug target/11594] testcase gcc.dg/20020103-1.c fails with "scan-assembler-not LC"
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|amodra at bigpond dot net |unassigned at gcc dot gnu |dot au |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11594
[Bug middle-end/27181] Does not fold access to base with cast to different derived type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27181
[Bug other/27156] SIGSEGV in operator delete() / wrong-code?
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-19 00:36 --- Well this works with just compiling like: g++ -O2 -pthread t.ii With 4.1.0 (4.1.0 20051026). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
[Bug other/27156] SIGSEGV in operator delete() / wrong-code?
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-19 00:38 --- Are you sure that you are not mixing operator new and deletes up so the stlport's operator delete is being called on memory allocated from operator new from libstdc++? Also is there a reason why you are using stlport? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
[Bug debug/27160] Debugging output forgets scope for typedefs.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 00:39 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-19 00:39:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27160
[Bug target/27179] libgomp bootstrap failure: unhandled reloc type 67
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-19 00:49 --- Does Sparc-FreeBSD have working TLS support? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27179
[Bug c/27193] dump-tree-original-raw does not print the linkage for a variable with file scope.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-19 02:42 --- Hiroshi-san, What are you trying to use this dump file for? Is it for other processing or just debugging GCC itself? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27193
[Bug libstdc++/27198] fstream is using fopen underly for 32b applictaions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 02:44 --- Isn't this really a Solaris bug in that fopen is limited and not really a libstdc++ bug? And that libstdc++ is just limited by the OS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27198
[Bug libgcj/27201] can't include cni.h and jni.h in the same file
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 02:45 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-19 02:45:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27201
[Bug rtl-optimization/27202] Missing optimiations with uint64_t
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-19 02:50 --- This is just the normal subreg issue. This is a dup of PR 23812 really. The problem is the shifts and such and really this is the same issue. *** This bug has been marked as a duplicate of 23812 *** -- 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=27202
[Bug rtl-optimization/23812] swapping DImode halves produces poor x86 register allocation
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-19 02:50 --- *** Bug 27202 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sb at biallas dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23812
[Bug c++/26974] hidden declarations klobber STL
--- Comment #3 from bangerth at dealii dot org 2006-04-19 02:57 --- As usual, a shorter testcase would have been appreciated. However, here there is really nothing that we can do: the executable doesn't link at all. I have plenty of missing symbols, for example hide::notAssembler hide::inv::count and six or eight others. Can you actually link your preprocessed sources? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug tree-optimization/27207] ICE: verify_cgraph_node failed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-19 03:00 --- This worked with "4.2.0 20060409". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27207
[Bug tree-optimization/27207] [4.2 Regression] ICE: verify_cgraph_node failed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-19 03:02 --- Actually never mind, it is the -Werror I missed which makes this is a dup of bug 25776. *** This bug has been marked as a duplicate of 25776 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Resolution||DUPLICATE Summary|ICE: verify_cgraph_node |[4.2 Regression] ICE: |failed |verify_cgraph_node failed Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27207
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-19 03:02 --- *** Bug 27207 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-19 03:03 --- This also can ICE with valid code with -Werror and a warning was emitted, PR 27207 was that case. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug c++/27209] New: Call to template method of template superclass of template does not parse
[EMAIL PROTECTED] /tmp]$ /usr/misc/pkg/gcc-4.0.2/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --prefix=/usr/misc/pkg/gcc-4.0.2
--enable-shared --enable-threads=posix --with-system-zlib --with-gnu-as
--with-as=/usr/misc/pkg/binutils-2.16/bin/as --with-gnu-ld
--with-ld=/usr/misc/pkg/binutils-2.16/bin/ld --enable-__cxa_atexit
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.2
Compile the following file:
start of file==
template
struct JIG {
template
void io() {}
};
template
struct TIG : public JIG {
void m() {
this->io();
JIG::io();
}
};
end of file==
[EMAIL PROTECTED] /tmp]$ /usr/misc/pkg/gcc-4.0.2/bin/g++ foo2.cc
foo2.cc: In member function void TIG::m():
foo2.cc:10: error: expected primary-expression before int
foo2.cc:10: error: expected `;' before int
foo2.cc:11: error: expected primary-expression before int
foo2.cc:11: error: expected `;' before int
This shows that an attempt to call io fails to parse. However, both calls
above are valid calls. Making any of the above not a template allows the file
to compile.
This seems to be reproduced in the 3.4 series as well.
--
Summary: Call to template method of template superclass of
template does not parse
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jjamison at cs dot berkeley dot edu
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27209
[Bug c++/27209] Call to template method of template superclass of template does not parse
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-19 03:24 --- You missed the template keyword in that the function should look like: this->template io(); JIG::template io(); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27209
[Bug c++/26838] Legal program rejection - protected base method addressing fails from grandchild class
--- Comment #5 from Simon80 at gmail dot com 2006-04-19 04:54 --- (In reply to comment #4) > This is not a bug. While the name in a function call is looked up from > inside the class, the name of a member function is looked up in the > global scope. There, the member in question here is inaccessible. > > W. > If that were the case, wouldn't the program in comment #3 fail as well? or am I misunderstanding something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26838
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- Comment #18 from pault at gcc dot gnu dot org 2006-04-19 04:59 --- (In reply to comment #15) > I can now compile tonto-1.0 without any kludges or tricks. That said, it > segfaults immediately after reading the input data. I will endeavour to find > the cause. This happens in a call to intrinsic flush, during the initial input. > > tonto-2.x is blocked by complex(ie. complicated) constructors, which in the > words of "Hitch-hikers Guide to the Galaxy", "will take a little while"; > although I hope to improve on the 4 million years of the story > > Paul > Please see yesterday's submission of a patch for this: http://gcc.gnu.org/ml/fortran/2006-04/msg00221.html Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug c++/26974] hidden declarations klobber STL
--- Comment #4 from igodard at pacbell dot net 2006-04-19 06:36 --- I can send you a linked binary with symbols, for either x86 Linux or Cygwin. Would that help? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
