[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-27 08:06
---
Here is the patch which fixes the PHI issue but I don't know if it will always
fix the PRE issue but I think it will as the PRE issue is always with VOPs:
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 119245)
+++ tree-ssa-dom.c (working copy)
@@ -1700,8 +1700,10 @@ cprop_operand (tree stmt, use_operand_p
depth than the propagatee. Otherwise, this may move loop variant
variables outside of their loops and prevent coalescing
opportunities. If the value was loop invariant, it will be hoisted
-by LICM and exposed for copy propagation. */
- if (loop_depth_of_name (val) > loop_depth_of_name (op))
+by LICM and exposed for copy propagation. We don't care much about
+ virtual operands. */
+ if (loop_depth_of_name (val) > loop_depth_of_name (op)
+ && is_gimple_reg (val))
return false;
/* Dump details. */
@@ -2136,12 +2138,13 @@ static void
propagate_rhs_into_lhs (tree stmt, tree lhs, tree rhs, bitmap
interesting_names)
{
/* First verify that propagation is valid and isn't going to move a
- loop variant variable outside its loop. */
+ loop variant variable outside its loop except for vops. */
if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs)
&& (TREE_CODE (rhs) != SSA_NAME
|| ! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs))
&& may_propagate_copy (lhs, rhs)
- && loop_depth_of_name (lhs) >= loop_depth_of_name (rhs))
+ && (loop_depth_of_name (lhs) > loop_depth_of_name (rhs)
+ || !is_gimple_reg (lhs)))
{
use_operand_p use_p;
imm_use_iterator iter;
Index: tree-ssa-copy.c
===
--- tree-ssa-copy.c (revision 119245)
+++ tree-ssa-copy.c (working copy)
@@ -801,8 +801,10 @@ copy_prop_visit_phi_node (tree phi)
Otherwise, this may move loop variant variables outside of
their loops and prevent coalescing opportunities. If the
value was loop invariant, it will be hoisted by LICM and
-exposed for copy propagation. */
- if (loop_depth_of_name (arg) > loop_depth_of_name (lhs))
+exposed for copy propagation. We don't much about virtual
+operands as they don't cause any LICM to happen. */
+ if (loop_depth_of_name (arg) > loop_depth_of_name (lhs)
+ && is_gimple_reg (arg))
{
phi_val.value = lhs;
break;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug tree-optimization/22372] Vectorizer produces mis-match types
--- Comment #4 from irar at gcc dot gnu dot org 2006-11-27 08:10 --- Subject: Bug 22372 Author: irar Date: Mon Nov 27 08:10:23 2006 New Revision: 119247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119247 Log: PR tree-optimization/22372 * tree-vect-transform.c (vect_create_addr_base_for_vector_ref): Convert the type of the base address. (vect_create_data_ref_ptr): Add an argument, type of the data-ref. Use it in the data-ref pointer creation. (vect_init_vector): Add an argument, type of the init vector. Use it in the stmt creation. (vect_get_vec_def_for_operand): Fix calls to vect_init_vector. (get_initial_def_for_reduction): Likewise. (vect_create_epilog_for_reduction): Change type of MODIFY_EXPR to void_type_node. (vectorizable_assignment, vect_permute_store_chain): Likewise. (vectorizable_store): Fix call to vect_create_data_ref_ptr. Use the correct type in stmt creation. (vect_setup_realignment): Use the correct type in stmt creation. (vect_permute_load_chain): Change type of MODIFY_EXPR to void_type_node. (vectorizable_load): Fix calls to vect_create_data_ref_ptr. Change type of MODIFY_EXPR to void_type_node. (vectorizable_condition): Change type of MODIFY_EXPR to void_type_node. (vect_update_ivs_after_vectorizer): Use the correct type in stmt creation. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
[Bug fortran/29951] [4.3 Regression] incorrect conversion from string to integer by TRANSFER()
--- Comment #10 from kloedej at knmi dot nl 2006-11-27 08:21 --- thanks for your effort to fix this bug! I can confirm todays binary version, downloaded from "http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz works fine for me. best regards, Jos de kloe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2006-11-27 08:24 --- I have successfully completed testing to the extent I can including large numbers of I/O operations and huge records (> 5 gigabyte) and large file (50 gigabyte). All looks Good. I have performance checked against ifort and gfortran is comparable at least for my simple tests. With my minor comments offlist I think this is ready to submit for approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug c++/29991] New: double: conversion to bits
Compiling the Code
---
#include
#include
typedef long long unsigned Significant;
Significant conv(double v)
{
return *(Significant*)&v;
}
double v=1.0;
int main(unsigned argc,char* args[])
{
std::cerr
[Bug c++/29991] double: conversion to bits
--- Comment #1 from pluto at agmk dot net 2006-11-27 09:07 --- did you ever read the gcc warnings? `-Wall' tells you what's wrong. use -fno-strict-aliasing or memcpy() for such conversions. -- pluto at agmk dot net changed: What|Removed |Added GCC build triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC host triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC target triplet| i686-pc-linux-gnu |i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29991
[Bug fortran/29992] New: INTERFACE equivalent to MODULE PROCEDURE?!
The following code is accepted by gfortran while ifort rejects it with error messages as quoted below. $> cat foo.f90 MODULE class_foo_type TYPE :: foo INTEGER :: dummy END TYPE END MODULE MODULE class_foo USE class_foo_type, ONLY: foo INTERFACE foo_init MODULE PROCEDURE foo_init_default END INTERFACE INTERFACE SUBROUTINE foo_init_default(this) USE class_foo_type, ONLY: foo TYPE(foo), INTENT(out) :: this END SUBROUTINE END INTERFACE END MODULE $> gfortran-4.3 -g -Wall -pedantic -std=f95 -c foo.f90 && echo "ok" ok $> gfortran-4.3 -v version 4.3.0 20061116 (experimental) $> ifort -g -warn all -c foo.f90 fortcom: Error: foo.f90, line 15: The procedure name of the INTERFACE block conflicts with a name in the encompassing scoping unit. [FOO_INIT_DEFAULT] SUBROUTINE foo_init_default(this) -^ fortcom: Error: foo.f90, line 11: Unresolved MODULE PROCEDURE specification name. [FOO_INIT_DEFAULT] MODULE PROCEDURE foo_init_default ---^ compilation aborted for foo.f90 (code 1) The following is accepted likewise: -- Summary: INTERFACE equivalent to MODULE PROCEDURE?! Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29992
[Bug fortran/29992] INTERFACE equivalent to MODULE PROCEDURE?!
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-27 09:28 --- (report continued) $> cat foo2.f90 MODULE class_foo_type TYPE :: foo INTEGER :: dummy END TYPE END MODULE MODULE class_foo USE class_foo_type, ONLY: foo INTERFACE foo_init SUBROUTINE foo_init_default(this) USE class_foo_type, ONLY: foo TYPE(foo), INTENT(out) :: this END SUBROUTINE END INTERFACE END MODULE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29992
[Bug c++/29991] double: conversion to bits
--- Comment #2 from schwab at suse dot de 2006-11-27 09:51 --- *** This bug has been marked as a duplicate of 21920 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29991
[Bug c/21920] alias violating
--- Comment #108 from schwab at suse dot de 2006-11-27 09:51 --- *** Bug 29991 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||hans dot buchmann at fhso ||dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #5 from patchapp at dberlin dot org 2006-11-27 10:15 --- Subject: Bug number PR29962 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-11/msg01799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug c++/29993] New: typdef declaration of cv-qualified function in class
gcc rejects following valid code.
class bar
{
typedef int func_type() const;
};
--
Summary: typdef declaration of cv-qualified function in class
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993
[Bug tree-optimization/22372] Vectorizer produces mis-match types
--- Comment #5 from irar at il dot ibm dot com 2006-11-27 11:19 --- The patch I committed (comment #4) fixes almost all the type mismatch occurrences in the vectorizer, but there's one occurrence that still remains - one of the vectorizer testcases (vect-reduc-dot-u8b.c) still fails with modify.diff.txt on MODIFY_EXPR where the right hand side is a call to a builtin function (rs6000_builtin_mul_widen_even). For Altivec, the return value of the builtin function is always signed (while the left hand side of the assignment is unsigned). Is the check in modify.diff.txt too strict or is the problem with the return type of the Altivec builtin (shouldn't it be signed/unsigned as relevant, instead of always signed? Specifically - shouldn't builtin vmuloub return an unsigned type)? Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
[Bug middle-end/25620] Missed optimization with power
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-11-27 11:38 --- Subject: Bug 25620 Author: rguenth Date: Mon Nov 27 11:38:42 2006 New Revision: 119248 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119248 Log: 2006-11-27 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/25620 * builtins.c (expand_builtin_pow): Optimize non integer valued constant exponents using sqrt or cbrt if possible. Always fall back to expanding via optabs. * gcc.target/i386/pow-1.c: New testcase. * gcc.dg/builtins-58.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/builtins-58.c trunk/gcc/testsuite/gcc.target/i386/pow-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
[Bug fortran/25620] Missed optimization with power
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-11-27 11:52 --- Fixed (partly) on the mainline. We can now expand pow (x, n/2) and pow (x, n/3) properly using sqrt and/or cbrt, but cbrt is not available from the fortran frontend (it misses to define __builtin_cbrt). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Component|middle-end |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
[Bug tree-optimization/28544] [4.2/4.3 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #14 from bero at arklinux dot org 2006-11-27 12:58 --- Created an attachment (id=12700) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12700&action=view) Different code triggering the same error Different code extracted from dirac, triggering the same error (goes away with -fno-strict-aliasing) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/29718] [4.2/4.3 Regression] ice in add_virtual_operand with some C++ code
--- Comment #4 from bero at arklinux dot org 2006-11-27 12:59 --- Might be a dup of bug 28544 -- bero at arklinux dot org changed: What|Removed |Added CC||bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29718
[Bug fortran/29992] INTERFACE equivalent to MODULE PROCEDURE?!
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-27 13:02 --- Confirm. Currently, the two interfaces clash: MODULE PROCEDURE foo_init_default SUBROUTINE foo_init_default(this) The latter needs to be "contains"ed in the module not put into an interface. * * * Error message from NAG f95: SUBROUTINE foo_init_default(this) ^ "afdf.f90", Line = 15, Column = 14: ERROR: "FOO_INIT_DEFAULT" is a module-subprogram, therefore it must not be a subroutine in an interface block. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-27 13:02:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29992
[Bug tree-optimization/28544] [4.2/4.3 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #15 from dberlin at gcc dot gnu dot org 2006-11-27 13:54 --- Subject: Re: [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309 I assume the attached fixes this? On 15 Oct 2006 09:01:42 -, tbm at cyrius dot com <[EMAIL PROTECTED]> wrote: > > > --- Comment #13 from tbm at cyrius dot com 2006-10-15 09:01 --- > (In reply to comment #8) > > I can trivially fix this, but the code isn't going to do what you want when > > i'm > > done, since it is an aliasing violation :) > > > > The assert in question just happens to be good at catching them. > > *ping* > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > You are the assignee for the bug, or are watching the assignee. > --- Comment #16 from dberlin at gcc dot gnu dot org 2006-11-27 13:54 --- Created an attachment (id=12701) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12701&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug c/29994] New: __STRICT_ANSI__ meaning incorrectly documented
What does __STRICT_ANSI__ mean in C (not C++) mode? The doc says: "The macro `__STRICT_ANSI__' is predefined when the `-ansi' option is used." I.e. when the compiler is implementing strict ISO C90. But it is also defined when the compiler is implementing strict ISO C99. $ touch empty.c $ gcc -std=c99 -E -dM empty.c | grep '\(__STRICT\|__STDC_V\)' #define __STRICT_ANSI__ 1 #define __STDC_VERSION__ 199901L And -ansi is not implied in this mode: -std=c99 -ansi apparently means strict ISO C90: $ gcc -std=c99 -ansi -E -dM empty.c | grep '\(__STRICT\|__STDC_V\)' #define __STRICT_ANSI__ 1 Possible resolutions: A) Document that __STRICT_ANSI__ can also mean strict ISO C99. B) Change "gcc -std=c99" to define __STRICT_C99__ instead of __STRICT_ANSI__. -- Summary: __STRICT_ANSI__ meaning incorrectly documented Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruno at clisp dot org GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29994
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #12 from hjl at lucon dot org 2006-11-27 14:58 --- This patch http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01608.html works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug fortran/20441] -finit-local-zero is missing from gfortran
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-27 16:02 --- > > Besides zero initialization [...] a initialization to a (signaling) NaN > > (for > > complex, real) would be also nice to find uninitialized variables. > > Why use -Wuninitialize will warn about those cases (though it can produce some > false positives). -Wuninitialize does not always work (false negative). Or how do you expect a compiler to find the problem in such cases: real :: r call myFunc(r, .true.) contains subroutine myFunc(r,l) real, intent(inout) :: r logical :: l if(l) then r = r**2 else r = 5 end if end subroutine -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug target/29995] New: sh-elf: precompiled headers won't match
The encoded information about machine-specific options with default values (e.g -mdiv=...) is wrong, causing spurious header mismatches. (Note : I have set the component to 'target' instead of 'pch' because I think this can probably be fixed by adjusting the pch target hooks.) We should also make sure that we build pch for every multilib for which library building is enabled, suitable for -O0 -g and -O2 -g compilations. -- Summary: sh-elf: precompiled headers won't match Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-elf OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29995
[Bug target/29996] New: sh-elf: should enable -fomit-frame-pointer
-fomit-frame-pointer should be enabled by setting CAN_DEBUG_WITHOUT_FP, but only after thorough testing for every multilib that that debugging is not impeded, and that average benchmark scores are indeed improved. -- Summary: sh-elf: should enable -fomit-frame-pointer Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-*-* OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29996
[Bug c/29994] __STRICT_ANSI__ meaning incorrectly documented
--- Comment #1 from joseph at codesourcery dot com 2006-11-27 16:16 ---
Subject: Re: New: __STRICT_ANSI__ meaning incorrectly documented
On Mon, 27 Nov 2006, bruno at clisp dot org wrote:
> What does __STRICT_ANSI__ mean in C (not C++) mode?
>
> The doc says: "The macro `__STRICT_ANSI__' is predefined when the `-ansi'
> option is used." I.e. when the compiler is implementing strict ISO C90.
Only in invoke.texi under the documentation of -ansi - i.e. this
particular documentation has no real reason to describe what effect other
options might have, it's documenting a particular option (-ansi) only.
The documentation in cpp.texi, and that in trouble.texi, specifically
mention "or a @option{-std} switch specifying strict conformance to some
version of ISO C". I'd say the cpp.texi documentation is the main
documentation of what a particular predefined macro means (as opposed to
the effects of a particular option on predefined macros).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29994
[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)
--- Comment #5 from krebbel at gcc dot gnu dot org 2006-11-27 16:20 --- Subject: Bug 29319 Author: krebbel Date: Mon Nov 27 16:20:24 2006 New Revision: 119254 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119254 Log: 2006-11-27 Michael Matz <[EMAIL PROTECTED]> Andreas Krebbel <[EMAIL PROTECTED]> PR target/29319 * config/s390/predicates.md (larl_operand): Check addend of larl operand to be in range of -/+2GB. * config/s390/s390.c (legitimize_pic_address): Likewise. Changed type of variable even to HOST_WIDE_INT. 2006-11-27 Michael Matz <[EMAIL PROTECTED]> Andreas Krebbel <[EMAIL PROTECTED]> PR target/29319 * gcc.dg/20061127-1.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20061127-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/s390/predicates.md branches/gcc-4_1-branch/gcc/config/s390/s390.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)
--- Comment #6 from krebbel at gcc dot gnu dot org 2006-11-27 16:27 --- Subject: Bug 29319 Author: krebbel Date: Mon Nov 27 16:26:53 2006 New Revision: 119255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119255 Log: 2006-11-27 Michael Matz <[EMAIL PROTECTED]> Andreas Krebbel <[EMAIL PROTECTED]> PR target/29319 * config/s390/predicates.md (larl_operand): Check addend of larl operand to be in range of -/+2GB. * config/s390/s390.c (legitimize_pic_address): Likewise. Changed type of variable even to HOST_WIDE_INT. 2006-11-27 Michael Matz <[EMAIL PROTECTED]> Andreas Krebbel <[EMAIL PROTECTED]> PR target/29319 * gcc.dg/20061127-1.c: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/20061127-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/s390/predicates.md branches/gcc-4_2-branch/gcc/config/s390/s390.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug target/29997] New: various targets: GCC fails to encode epilogues in unwind-info
See the discussion started with this message: http://gcc.gnu.org/ml/gcc/2005-10/msg00808.html According to Jim Wilson in http://gcc.gnu.org/ml/gcc/2005-10/msg00858.html, we now have the infrastructure to properly encode prologues / epilogues. The ia64 port is using this. -- Summary: various targets: GCC fails to encode epilogues in unwind-info Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code, meta-bug, EH, wrong-debug Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org BugsThisDependsOn: 18749 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29997
[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)
--- Comment #7 from krebbel at gcc dot gnu dot org 2006-11-27 16:34 --- Subject: Bug 29319 Author: krebbel Date: Mon Nov 27 16:34:19 2006 New Revision: 119256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119256 Log: 2006-11-27 Michael Matz <[EMAIL PROTECTED]> Andreas Krebbel <[EMAIL PROTECTED]> PR target/29319 * config/s390/predicates.md (larl_operand): Check addend of larl operand to be in range of -/+2GB. * config/s390/s390.c (legitimize_pic_address): Likewise. Changed type of variable even to HOST_WIDE_INT. 2006-11-27 Michael Matz <[EMAIL PROTECTED]> Andreas Krebbel <[EMAIL PROTECTED]> PR target/29319 * gcc.dg/20061127-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/20061127-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/predicates.md trunk/gcc/config/s390/s390.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug target/29998] New: sh-elf: GCC fails to encode epilogues in unwind-info
The sh port does not encode information about epilogues in the unwind info. See PR target/29997 for context. In addition to adding saving / restoring state around epilogues, the current measures to prevent unwind info for epilogues to be emitted must be reverted: output_stack_adjust: set emit_fn depending always to frame_insn add REG_FRAME_RELATED_EXPR notes independent of epilogue_p pop: use frame_insn instead of emit_insn sh_expand_epilogue: should add REG_FRAME_RELATED_EXPR notes and use frame_insn like sh_expand_prologue does. -- Summary: sh-elf: GCC fails to encode epilogues in unwind-info Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-*-* OtherBugsDependingO 29842,29997 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29998
[Bug fortran/20441] -finit-local-zero is missing from gfortran
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-27 16:47 --- (In reply to comment #5) > > > Besides zero initialization [...] a initialization to a (signaling) NaN > > > (for > > > complex, real) would be also nice to find uninitialized variables. > > > > Why use -Wuninitialize will warn about those cases (though it can produce > > some > > false positives). > > -Wuninitialize does not always work (false negative). Or how do you expect a > compiler to find the problem in such cases: Well in that case r is unused so .. but if you made it used by a write(*,*) r in the program, this becomes another PR with a C example which I cannot find right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug fortran/25620] Missed optimization with power
--- Comment #16 from jv244 at cam dot ac dot uk 2006-11-27 16:49 --- (In reply to comment #15) > Fixed (partly) on the mainline. We can now expand pow (x, n/2) and pow (x, > n/3) > properly using sqrt and/or cbrt, but cbrt is not available from the fortran > frontend (it misses to define __builtin_cbrt). > Thanks Richard, for this patch, and your other efforts to improve performance for number crunching applications... hopefully the fortran frontend will be fixed as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
[Bug c/29994] __STRICT_ANSI__ meaning incorrectly documented
--- Comment #2 from bruno at clisp dot org 2006-11-27 16:50 --- You're right, it's well documented in cpp.info. I looked only in gcc.info. -- bruno at clisp dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29994
[Bug c/29999] New: preprocessor documentation is missing from gcc.info
A user that uses "info gcc" to look for details about the preprocessor doesn't find them. Example: [Bug c/29994]. The user did "info gcc", was looking for a section that explains all the predefined preprocessor macros, but didn't find it. The reason was that they are in a separate manual. Nowadays the preprocessor is rarely used on its own. To the user, it appears as part of the compiler. Suggestion: Integrate the parts of cpp.info that don't apply to other C/C++ implementations (such as "Predefined Macros" and "Invocation", and possibly others) into the gcc.info manual. -- Summary: preprocessor documentation is missing from gcc.info Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruno at clisp dot org GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug tree-optimization/29718] [4.2/4.3 Regression] ice in add_virtual_operand with some C++ code
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-27 16:59 --- (In reply to comment #4) > Might be a dup of bug 28544 No because 28544 violates the alias rules while this one does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29718
[Bug other/29999] preprocessor documentation is missing from gcc.info
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-27 17:06 --- I don't see why it has to be part of the GCC manual. This is like saying users think as and ld are part of the compiler and really should also be included in the manual. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |other Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug tree-optimization/30000] New: dummy to get 30,000
I win. -- Summary: dummy to get 30,000 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug tree-optimization/30000] dummy to get 30,000
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-27 17:07 --- I win, win, win. Anyways invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug c++/29993] typdef declaration of cv-qualified function in class
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-27 17:16 --- Related to PR 6628. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||6628 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993
[Bug ada/29958] Ada: gcc bug box with an inherited generic package
--- Comment #3 from chevallier_sylvain at yahoo dot fr 2006-11-27 17:21 --- Okay, I have a *more* compact version of this bug : $ cat example.ads package Example is type I is tagged record N : Integer; end record; private procedure P_Private (X : in out I); end Example; $ cat example-generic_child.ads generic type EI is new I with private; package Example.Generic_Child is procedure P_Private (X : in out EI); end Example.Generic_Child; $ gcc -c example-generic_child.ads +===GNAT BUG DETECTED==+ | 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) (i486-pc-linux-gnu)| | Assert_Failure sem_ch7.adb:1313 | | Error detected at example-generic_child.ads:3:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.1 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. list may be incomplete compilation abandoned It seems gcc dislikes the fact that the "public" procedure Example.Generic_Child.P_Private share the same name that the private procedure Example.P_Private. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29958
Re: [Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
On Mon, 2006-11-27 at 08:06 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-27 08:06 > --- > Here is the patch which fixes the PHI issue but I don't know if it will always > fix the PRE issue but I think it will as the PRE issue is always with VOPs: I am hiding a PRE bug but there is no reason for these PHIs to be there anyways as far as I can tell so I am still going to submit my patch for the PHIs but will keep this bug opened. Thanks, Andrew Pinski
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #12 from pinskia at gmail dot com 2006-11-27 17:23 --- Subject: Re: [4.3 Regression] [Linux] ICE in insert_into_preds_of_block On Mon, 2006-11-27 at 08:06 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-27 08:06 > --- > Here is the patch which fixes the PHI issue but I don't know if it will always > fix the PRE issue but I think it will as the PRE issue is always with VOPs: I am hiding a PRE bug but there is no reason for these PHIs to be there anyways as far as I can tell so I am still going to submit my patch for the PHIs but will keep this bug opened. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug preprocessor/30001] New: out-of-bounds access when processing empty file
valgrind on Linux the reports the following error: Invalid read of size 1 for the function _cpp_convert_input (at line 1631 in charset.c) when an empty source file is compiled. libcpp/charset.c:_cpp_convert_input line 1631 is: if (to.text[to.len - 1] == '\r') and if to.len is zero, this is an out-of-bounds access. -- Summary: out-of-bounds access when processing empty file Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30001
[Bug c++/29928] typeid of unknown bound array
--- Comment #2 from sebor at roguewave dot com 2006-11-27 17:37 ---
Here are some other cases to consider:
#include
struct S;
int main ()
{
typeid (void);
typeid (int []);
typeid (S);
typeid (S&);
}
--
sebor at roguewave dot com changed:
What|Removed |Added
CC||sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29928
[Bug c++/29928] typeid of unknown bound array
--- Comment #3 from sebor at roguewave dot com 2006-11-27 19:07 --- Never mind. The last two cases in my comment #2 are disallowed by the second to last sentence in 5.2.8, p4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29928
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #26 from tkoenig at gcc dot gnu dot org 2006-11-27 20:43 --- (In reply to comment #24) > Subject: Re: implement unformatted files with subrecords > (Intel style) > > I have reviewed the patch and I have one minor comment. I suggest that the > continued flag be placed in with the unit flags similar to has_recl. Only > for > consistency. I am in the process of testing still. Hi Jerry, looking at the unit_flags struct, I notice that all components are determined by flags set on the I/O statement. Putting the continued flag doesn't seem right to me. Apart from that, I have put in a better error message and am currently in the process of bootstrapping and regtesting. Hopefully, I'll be able to submit tomorrow. Thanks for your help! Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug preprocessor/30001] out-of-bounds access when processing empty file
--- Comment #1 from fang at csl dot cornell dot edu 2006-11-27 20:49 --- Is this related to the standard requirement that a source file must end with a newline character? (and thus cannot be empty?) -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30001
[Bug tree-optimization/30000] dummy to get 30,000
--- Comment #2 from fang at csl dot cornell dot edu 2006-11-27 20:52 --- Funny, I was thinking the same thing, but "you snooze, you lose..." -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug inline-asm/30002] New: Problem with call directive in inline ASM
Hi,
I've written this program to try a shellcode made by me:
char shell[] =
"\xeb\x25\x5e\xb8\x46\x00\x00\x00"
"\xbb\x00\x00\x00\x00\xb9\x00\x00"
"\x00\x00\xcd\x80\xb8\x0b\x00\x00"
"\x00\x89\xf3\x6a\x00\x56\x89\xe4"
"\xba\x00\x00\x00\x00\xcd\x80\xe8"
"\xd6\xff\xff\xff"
"/bin/sh";
main() {
printf ("%p\n",shell);
__asm__("call 0x08049600");
}
Where, of course, 0x08049600 is the address of my shellcode.
But when I compile and run the program I get a segmentation fault.
This is what I get disassembling the program with Gdb:
0x080483a4 :push %ebp
0x080483a5 :mov%esp,%ebp
0x080483a7 :sub$0x8,%esp
0x080483aa :and$0xfff0,%esp
0x080483ad :mov$0x0,%eax
0x080483b2 : add$0xf,%eax
0x080483b5 : add$0xf,%eax
0x080483b8 : shr$0x4,%eax
0x080483bb : shl$0x4,%eax
0x080483be : sub%eax,%esp
0x080483c0 : sub$0x8,%esp
0x080483c3 : push $0x8049600
0x080483c8 : push $0x80484e4
0x080483cd : call 0x80482b8 <[EMAIL PROTECTED]>
0x080483d2 : add$0x10,%esp
0x080483d5 : call 0x4
0x080483da : leave
0x080483db : ret
Why do I have a call 0x4 on main+49 instead of call 0x08049600?
--
Summary: Problem with call directive in inline ASM
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: blacklight86 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30002
[Bug inline-asm/30002] Problem with call directive in inline ASM
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-27 21:33 --- Why do you think this will work? The linker is what places the address and since you have not shown how you used a linker script and for sure that the shell is placed at 0x08049600 I don't trust this at all. Also I bet the section for shell is not marked as executable which means it will not be able to run anyways. -- 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=30002
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #2 from janis at gcc dot gnu dot org 2006-11-27 22:12 --- The functionality to support dg-error and dg-warning is in proc dg-test in file dg.exp from the DejaGnu project. It treats these two directives the same except for the failure message. The GCC testsuite infrastructure overrides some small DejaGnu procs to get them to do what we want, but dg-test is very large. Eventually we should work with the DejaGnu developers to get changes we need into that product, including the ability to provide callbacks for project-specific support for things like checking error and warning messages. In the meantime we're stuck with including "error" or "warning" in the regular expression being checked. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-27 22:21 --- Joost, all_cp2k_gfortran.f90:128714: internal compiler error: in build_int_cst_wide, at tree.c:852 Is this the same as PR29976 by any chance? Paul PS I should change your email address on testcases! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-11-27 22:24 --- (In reply to comment #3) > Is this the same as PR29976 by any chance? Hi Paul, This PR is a metabug for CP2K issues; PR29976 is one of those (I'm in a middle of a workshop frenzy right now, so I don't have time to reduce the other issues mentionned by Joost, although I can confirm at least the second one (the segfault)). I think it's a good thing to have that metabug PR, because CP2K is a very good test for a Fortran95 compiler, as it heavily uses many F95 features. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/30003] New: Expressions with side effects in array references
(This bug was discovered during a discussion on the mailinglist starting here: http://gcc.gnu.org/ml/fortran/2006-11/msg00636.html) This short program erik:~$ cat foo.f90 program foo implicit none integer :: a(5), b(3) b = [ 1, 2, 3 ] a(1:bar(3)) = b contains integer function bar(n) integer, intent(in) :: n print *, 'Hello!' bar = n end function bar end program foo should, when compiled and run, call bar() once, and, hence, print 'hello!' once. But when compiled without -fbounds-check, it doesn't print anything: erik:~$ gfortran foo.f90 erik:~$ a.out This is because gfortran will actually never evaluate the expression of the size of the LHS; it will just assume the LHS has the same size as the RHS. That would be OK if the expression of the size didn't have side effects, but in a case like this, it gives wrong results. If we compile with -fbounds-check, it gets really strange: erik:~$ gfortran foo.f90 -fbounds-check erik:~$ a.out Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Hello! Here, bar() is called 13 times! This is because bar() is called separately for every check that the value of bar() is within bounds etc. Again, this would be OK (albeit a bit inefficient) if bar() had no side effects, but with side effects it gives wrong results. Also consider the case where bar():s result value depends on e.g. a SAVEd variable, so that it returns different values every time it's called (even if called with the same argument). That could give _really_ wierd behaviour. -- Summary: Expressions with side effects in array references Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: eedelman at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30003
[Bug fortran/29976] [4.2/4.3 regression] ICE on optional arg
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-27 22:25 --- I will submit the patch as 'obvious' tomorrow morning - see: http://gcc.gnu.org/ml/fortran/2006-11/msg00686.html Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-11-25 21:19:38 |2006-11-27 22:25:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29976
[Bug rtl-optimization/30004] New: overzealous alignment of structure - 32 bytes (not bits!)
Hello. I am a maintainer of busybox project. One of our goals is to optimize
our code for size. The following testcase was derived from busybox source:
struct client_config_t {
char foreground;
char quit_after_lease;
char release_on_quit;
char abort_if_no_lease;
char *interface;
char *script;
char *clientid;
char *fqdn;
int retries;
int timeout;
char arp[6];
};
struct client_config_t udhcp_client_config1;
struct client_config_t client_config2 = {
/* Default options. */
.abort_if_no_lease = 0,
.foreground = 0,
.quit_after_lease = 0,
.release_on_quit = 0,
.interface = "eth0",
.script = "/share/udhcpc/default.script",
.clientid = 0,
.fqdn = 0,
.retries = 3,
.timeout = 3,
.arp = "\0\0\0\0\0\0", /* appease gcc-3.0 */
};
int udhcpc_main(int argc, char *argv[])
{
udhcp_client_config1.interface = "eth0";
udhcp_client_config1.script = "/share/udhcpc/default.script";
udhcp_client_config1.retries = udhcp_client_config1.timeout = 3;
return 0;
}
Even when compiled with optimisation for size (gcc -Os -S -fomit-frame-pointer
dhcpc.c), both data- and bss-placed structures are aligned to 32 _bytes_.
The structs are itself only _36 bytes_ large! When a lot of structures from
different .o modules are combined into final executable, we waste a lot of
space (on average, 15.5 bytes per structure):
.file "dhcpc.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "eth0"
.LC1:
.string "/share/udhcpc/default.script"
.text
.globl udhcpc_main
.type udhcpc_main, @function
udhcpc_main:
movl$.LC0, udhcp_client_config1+4
movl$.LC1, udhcp_client_config1+8
movl$3, udhcp_client_config1+24
movl$3, udhcp_client_config1+20
xorl%eax, %eax
ret
.size udhcpc_main, .-udhcpc_main
.globl client_config2
.data
.align 32<-HERE
.type client_config2, @object
.size client_config2, 36
client_config2:
.byte 0
.byte 0
.byte 0
.byte 0
.long .LC0
.long .LC1
.long 0
.long 0
.long 3
.long 3
.string ""
.string ""
.string ""
.string ""
.string ""
.string ""
.zero 2
.comm udhcp_client_config1,36,32 < HERE
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
Is it possible to instruct gcc to use smaller alignment?
BTW, is there any progress on bug 22158 (also related to data alignment)? I
have a patch there...
--
Summary: overzealous alignment of structure - 32 bytes (not
bits!)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30004
[Bug rtl-optimization/30004] overzealous alignment of structure - 32 bytes (not bits!)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-27 22:57 --- I think this was fixed by: 2006-01-10 Jan Beulich <[EMAIL PROTECTED]> * config/i386/i386.c (ix86_data_alignment): Don't force alignment to 256 bits when optimize_size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30004
[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-11-27 22:57 --- I think this was fixed by: 2006-01-10 Jan Beulich <[EMAIL PROTECTED]> * config/i386/i386.c (ix86_data_alignment): Don't force alignment to 256 bits when optimize_size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158
[Bug rtl-optimization/30004] overzealous alignment of structure - 32 bytes (not bits!)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-27 22:59 --- Yes it was fixed: .comm udhcp_client_config1,36,4 . .align 4 .type client_config2, @object .size client_config2, 36 client_config2: -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30004
[Bug rtl-optimization/30004] overzealous alignment of structure - 32 bytes (not bits!)
--- Comment #3 from vda dot linux at googlemail dot com 2006-11-27 23:03 --- Super! Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30004
[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-27 23:03 --- This was also fixed. s2: .long .LC0 .data .align 4 .type s3, @object .size s3, 49 s3: .string "" -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158
[Bug web/20588] gcc-patches 2004-02 archives broken
--- Comment #3 from gary at intrepid dot com 2006-11-28 00:26 --- I ran into this today, following up on a thread posted to the GDB discussion list, regarding Bug #8354: http://sourceware.org/ml/gdb/2006-11/msg00185.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20588
[Bug debug/8354] Incorrect DWARF-2/3 emitted for const + array
--- Comment #10 from gary at intrepid dot com 2006-11-28 00:58 --- Created an attachment (id=12702) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12702&action=view) PR/8354 patch discussion thread As reported in Bug #20588, the referenced links to the gcc-patch mailing list archives are broken. The referenced mail messages are included in this attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8354
[Bug fortran/29976] [4.2/4.3 regression] ICE on optional arg
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-11-28 01:18 --- I think wrong url in comment #3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29976
[Bug tree-optimization/29984] [4.2/4.3 Regression] SPE GCC segfaults with MAX_EXPR
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|SPE GCC segfaults with |[4.2/4.3 Regression] SPE GCC |MAX_EXPR |segfaults with MAX_EXPR Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29984
[Bug fortran/29976] [4.2/4.3 regression] ICE on optional arg
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-11-28 05:25 --- Subject: Re: [4.2/4.3 regression] ICE on optional arg jvdelisle at gcc dot gnu dot org wrote: > --- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-11-28 01:18 > --- > I think wrong url in comment #3 > > > 'tis not read (ii). :-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29976
[Bug fortran/20880] USE association of procedure's own interface
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-28 05:36 --- Subject: Bug 20880 Author: pault Date: Tue Nov 28 05:36:07 2006 New Revision: 119272 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119272 Log: 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20880 * resolve.c (resolve_fl_procedure): Error if procedure is ambiguous modified to require attr.referenced. 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20880 * gfortran.dg/interface_3.f90: Modify errors. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/interface_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20880
[Bug fortran/29976] [4.2/4.3 regression] ICE on optional arg
--- Comment #6 from pault at gcc dot gnu dot org 2006-11-28 05:39 --- Subject: Bug 29976 Author: pault Date: Tue Nov 28 05:39:42 2006 New Revision: 119273 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119273 Log: 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29976 * trans-expr.c (gfc_conv_missing_dummy): Remove build_int_const and replace with cast to type of se->expr of integer_zero_node. 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29976 * gfortran.dg/missing_optional_dummy_3.f90 Added: trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29976
[Bug fortran/20880] USE association of procedure's own interface
--- Comment #6 from pault at gcc dot gnu dot org 2006-11-28 05:50 --- Subject: Bug 20880 Author: pault Date: Tue Nov 28 05:50:21 2006 New Revision: 119274 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119274 Log: 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20880 * resolve.c (resolve_fl_procedure): Error if procedure is ambiguous modified to require attr.referenced. 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/20880 * gfortran.dg/interface_3.f90: Modify errors. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20880
[Bug fortran/29976] [4.2/4.3 regression] ICE on optional arg
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-28 05:52 --- Subject: Bug 29976 Author: pault Date: Tue Nov 28 05:52:02 2006 New Revision: 119275 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119275 Log: 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29976 * trans-expr.c (gfc_conv_missing_dummy): Remove build_int_const and replace with cast to type of se->expr of integer_zero_node. 2006-11-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/29976 * gfortran.dg/missing_optional_dummy_3.f90 Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_3.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29976
