[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 06:19 --- Created an attachment (id=12477) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12477action=view) Example patch I don't know if it's giving correct results in all cases, or if it works even on platforms without C99 math functions, but the idea is here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518
[Bug target/29443] [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-23 06:39 --- (gdb) p debug_rtx(x) (unspec:DI [ (symbol_ref:DI (_ZN6string20_S_empty_rep_storageE) [flags 0x40] var_decl 0xb7d9c060 _S_empty_rep_storage) ] 2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug target/29443] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 06:47 ---
Reduced testcase:
struct string
{
struct _Rep{}; static _Rep _S_empty_rep_storage[];
void *_M_rep () const{} void _M_destroy () throw ();
~string ()
{
_Rep *a = (_Rep *)((void *)(_S_empty_rep_storage));
if (__builtin_expect (_M_rep ()!= a, false)) _M_destroy ();
}
};
struct ios_base { virtual ~ ios_base (); }; struct ostream : virtual
ios_base{};
struct stringbuf
{
int t()const; string _M_string;
string str () const
{
string __ret;
if (t()) return __ret;
}
};
struct ostringstream : ostream { ostream __ostream_type; stringbuf
_M_stringbuf; };
void sizeString ()
{
ostringstream s;
s._M_stringbuf.str ();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2006-10-23 06:47:45
date||
Summary|[4.1 regression] ICE: |ICE: output_operand: invalid
|output_operand: invalid |expression as operand with -
|expression as operand with -|gstabs
|gstabs |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug target/29443] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-23 06:48 --- Note this looks like a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug middle-end/21032] With -frounding-math, incorrectly reorders unary minus
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-23 07:15 --- Subject: Bug 21032 Author: rguenth Date: Mon Oct 23 07:15:45 2006 New Revision: 117968 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117968 Log: 2006-10-23 Richard Guenther [EMAIL PROTECTED] PR middle-end/21032 * convert.c (convert_to_real): Fold (float)-x to -(float)x only if not flag_rounding_math. * gcc.dg/pr21032.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr21032.c Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug middle-end/21032] With -frounding-math, incorrectly reorders unary minus
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-23 07:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug middle-end/29548] Does not fold b * -2 + a * 6
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 07:19 --- Subject: Bug 29548 Author: rguenth Date: Mon Oct 23 07:19:34 2006 New Revision: 117969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117969 Log: 2006-10-24 Richard Guenther [EMAIL PROTECTED] PR middle-end/27132 PR middle-end/23295 * builtins.c (fold_binary): Remove checks for flag_wrapv and flag_trapv where negate_expr_p covers these cases. * gcc.dg/pr27132.c: New testcase. * gcc.dg/pr23295.c: Likewise. * gcc.dg/tree-ssa/pr23294.c: Adjust patterns. * g++.dg/tree-ssa/pr19807.C: Likewise. 2006-10-23 Richard Guenther [EMAIL PROTECTED] PR middle-end/29548 * fold-const.c (fold_plusminus_mult_expr): Check exact power of two on the absolute value. (fold_binary): Fold x * -C to -x * C if x is easily negatable and negating -C does not overflow. Added: trunk/gcc/testsuite/gcc.dg/pr23295.c trunk/gcc/testsuite/gcc.dg/pr27132.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr19807.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23294.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29548
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-23 07:19 --- Subject: Bug 23295 Author: rguenth Date: Mon Oct 23 07:19:34 2006 New Revision: 117969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117969 Log: 2006-10-24 Richard Guenther [EMAIL PROTECTED] PR middle-end/27132 PR middle-end/23295 * builtins.c (fold_binary): Remove checks for flag_wrapv and flag_trapv where negate_expr_p covers these cases. * gcc.dg/pr27132.c: New testcase. * gcc.dg/pr23295.c: Likewise. * gcc.dg/tree-ssa/pr23294.c: Adjust patterns. * g++.dg/tree-ssa/pr19807.C: Likewise. 2006-10-23 Richard Guenther [EMAIL PROTECTED] PR middle-end/29548 * fold-const.c (fold_plusminus_mult_expr): Check exact power of two on the absolute value. (fold_binary): Fold x * -C to -x * C if x is easily negatable and negating -C does not overflow. Added: trunk/gcc/testsuite/gcc.dg/pr23295.c trunk/gcc/testsuite/gcc.dg/pr27132.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr19807.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23294.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-23 07:19 --- Subject: Bug 27132 Author: rguenth Date: Mon Oct 23 07:19:34 2006 New Revision: 117969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117969 Log: 2006-10-24 Richard Guenther [EMAIL PROTECTED] PR middle-end/27132 PR middle-end/23295 * builtins.c (fold_binary): Remove checks for flag_wrapv and flag_trapv where negate_expr_p covers these cases. * gcc.dg/pr27132.c: New testcase. * gcc.dg/pr23295.c: Likewise. * gcc.dg/tree-ssa/pr23294.c: Adjust patterns. * g++.dg/tree-ssa/pr19807.C: Likewise. 2006-10-23 Richard Guenther [EMAIL PROTECTED] PR middle-end/29548 * fold-const.c (fold_plusminus_mult_expr): Check exact power of two on the absolute value. (fold_binary): Fold x * -C to -x * C if x is easily negatable and negating -C does not overflow. Added: trunk/gcc/testsuite/gcc.dg/pr23295.c trunk/gcc/testsuite/gcc.dg/pr27132.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr19807.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23294.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-23 07:20 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-23 07:20 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug middle-end/29548] Does not fold b * -2 + a * 6
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-23 07:20 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29548
[Bug middle-end/29548] Does not fold b * -2 + a * 6
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29548
[Bug fortran/29523] ICE with some non up-to date .mod files
--- Comment #2 from keinstein_junior at gmx dot net 2006-10-23 07:28 --- (In reply to comment #1) Can you provide some details on the out of date .mod files? Were they compiled with a different compiler version or on a different architecture? Or are they just not up-to-date with the source? In the latter case you should adjust your makefile to honour dependencies and rebuild the .mod files appropriately. The latter case is true. But gfortran should give a useful error message. Up to now it was much easier to do make clean than to track all the dependencies across the different directories as gfortran doesn't offer dependency tracking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29523
[Bug libstdc++/20647] Wrong typeid for incomplete types
--- Comment #16 from nathan at gcc dot gnu dot org 2006-10-23 07:42 --- Subject: Bug 20647 Author: nathan Date: Mon Oct 23 07:42:02 2006 New Revision: 117970 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117970 Log: cp/ PR c++/20647 * rtti.c (tinfo_base_init): The type info string is always global. testsuite/ PR c++/20647 * g++.dg/abi/rtti3.C: New. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/abi/rtti3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/rtti.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20647
[Bug bootstrap/25672] cross build's libgcc picks up CFLAGS
--- Comment #16 from pluto at agmk dot net 2006-10-23 08:11 --- Subject: Re: cross build's libgcc picks up CFLAGS lianghua xu napisaÅ(a): did you save this bug? I am failled in this trouble 2 weeks since I making the cross tools for arm-elf-tools under CYGWIN on XP os. any advise, thank you very much. i'm using this patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672#c5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug bootstrap/29557] New: multilib zlib build broken. wrong path to prev-gcc
(...) Adding multilib support to Makefile in ../../zlib multidirs=32 with_multisubdir= Running configure in multilib subdirs 32 pwd: /home/users/pluto/rpm/BUILD/gcc-4_2-branch/builddir/zlib Running configure in multilib subdir 32 pwd: /home/users/pluto/rpm/BUILD/gcc-4_2-branch/builddir mkdir 32 configure: creating cache ./config.cache checking build system type... x86_64-pld-linux-gnu checking host system type... x86_64-pld-linux-gnu checking target system type... x86_64-pld-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether /usr/bin/make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for x86_64-pld-linux-gcc... /home/users/pluto/rpm/BUILD/gcc-4_2-branch/builddir/32/./prev-gcc/xgcc -B/home/users/pluto/rpm/BUILD/gcc-4_2-branch/builddir/32/./prev-gcc/ -B/usr/x86_64-pld-linux/bin/ -m32 checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage2-zlib] Error 1 the problem is in path to xgcc. /home/users/pluto/rpm/BUILD/gcc-4_2-branch/builddir/32/./prev-gcc/xgcc should be a 32/.. -- Summary: multilib zlib build broken. wrong path to prev-gcc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29557
[Bug target/29558] New: ICE in set_variable_part, at var-tracking.c:2140
We ICE there with the following testcase compiled with -g -O:
void stpi_unpack_16_1(int length,const unsigned char *in,unsigned char
*out0,unsigned char *out1,unsigned char *out2,unsigned char *out3,
unsigned char *out4,unsigned char *out5,unsigned char *out6,
unsigned char *out7,unsigned char *out8,unsigned char *out9,
unsigned char *out10,unsigned char *out11,unsigned char *out12,
unsigned char *out13,unsigned char *out14,unsigned char *out15)
{
unsigned char tempin, bit;
unsigned char temp[16];
for (bit = 128; length 0; length--) {
if (tempin 128)
temp[0] |= bit;
else
{
*out1++ = temp[1];
*out2++ = temp[2];
*out3++ = temp[3];
*out4++ = temp[4];
*out5++ = temp[5];
*out6++ = temp[6];
*out7++ = temp[7];
*out9++ = temp[9];
*out10++ = temp[10];
*out11++ = temp[11];
*out12++ = temp[12];
*out13++ = temp[13];
*out14++ = temp[14];
*out15++ = temp[15];
__builtin_memset (temp, 0, 16);
}
}
}
--
Summary: ICE in set_variable_part, at var-tracking.c:2140
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-10-23 09:23 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01156.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||10/msg01156.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14784
[Bug fortran/29539] ICE in variable_decl
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 09:49 ---
Created an attachment (id=12478)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12478action=view)
Provisional fix for the PR
This not only fixes the PR but the modification to trans-types allows a data
statement to include components of the derived type:
! { dg-compile }
! { dg-options -W -Wall }
block data
common /c/ d(5), cc
type c_t
sequence
integer i
end type c_t
type (c_t) :: cc
data d /5*1./
data cc%i /5/
end
common /c/ d(5), cc
type c_t
sequence
integer i
end type c_t
type (c_t) :: cc
print *, d
print *, cc
end
Works correctly. Putting the data statement before the derived type
declaration produces a syntax error; Lahey warns that the derived type
declaration will have to be confirmed. I will see if it can be fixed easily; if
not I'll throw an error, which says what to do; eg. the derived type is used
before it is defined.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29539
[Bug fortran/29507] INDEX in an array initialization causes ICE
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-23 10:02 --- Created an attachment (id=12479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12479action=view) Provisional general fix for the PR This patch fixes the the following: real, parameter :: a(2,2) = reshape ((/1.0, 2.0, 3.0, 4.0/), (/2,2/)) real, parameter :: b(2,2) = sin (a) character(6), parameter :: ch(3) = (/animal, person, mantee/) character(1), parameter :: ch2(3) = (/n, r, t/) integer, parameter :: i(3) = index (ch, ch2) print *, a, b print *, ch, i end There are still several things to do: (i) Understand why *e needs to be copied to old and then freed; ideally, *e should be assigned to old and expr assigned to it, at exit; (ii) Add conformance checks; (iii) Check if the branch to the new function is in the correct place - it is certainly the earliest opportunity to identify an elemental intrinsic; and (iv) Check that none of the non-elemental intrinsics are screwed up. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
--- Comment #4 from bonzini at gnu dot org 2006-10-23 10:11 ---
Like this?
Index: /Users/bonzinip/cvs/gcc/Makefile.def
===
--- /Users/bonzinip/cvs/gcc/Makefile.def(revision 116745)
+++ /Users/bonzinip/cvs/gcc/Makefile.def(working copy)
@@ -480,7 +480,7 @@ dependencies = { module=all-target-winsu
// Toplevel bootstrap
bootstrap_stage = {
id=1 ;
- stage_configure_flags='--disable-intermodule \
+ stage_configure_flags='--disable-intermodule --enable-checking \
--disable-coverage --enable-languages=$(STAGE1_LANGUAGES)' ;
stage_make_flags='CFLAGS=$(STAGE1_CFLAGS)
LIBCFLAGS=$(STAGE1_CFLAGS)' ; };
bootstrap_stage = {
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug target/29558] ICE in set_variable_part, at var-tracking.c:2140
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-23 10:14 ---
Slightly more reduced:
void stpi_unpack_16_1(int length, unsigned char *out, unsigned char bit)
{
unsigned char tempin;
unsigned char temp[16];
for (bit = 128; length 0; length--) {
if (tempin 128)
temp[0] |= bit;
else
{
*out++ = temp[1];
*out++ = temp[2];
*out++ = temp[3];
*out++ = temp[4];
*out++ = temp[5];
*out++ = temp[6];
*out++ = temp[7];
*out++ = temp[9];
*out++ = temp[10];
*out++ = temp[11];
*out++ = temp[12];
*out++ = temp[13];
*out++ = temp[14];
*out++ = temp[15];
__builtin_memset (temp, 0, 16);
}
}
}
it ICEs on
/* We track only variables whose size is = MAX_VAR_PARTS bytes
thus there are at most MAX_VAR_PARTS different offsets. */
gcc_assert (var-n_var_parts MAX_VAR_PARTS);
because var-n_var_parts is == MAX_VAR_PARTS. It looks like the analysis
part is wrong in trying to track temp[].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug other/29559] New: '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg-1.4.5.
with '-O1 -ftree-vrp -fwrapv' the armencrypt.test from gnupg-1.4.5 release producing an output until ENOSPC. with '-O1 -fno-tree-vrp' test passes. $ cd gnupg-1.4.5/checks/ $ srcdir=. ./armencrypt.test $ ls -l x -rw--- 1 builder2 users 108946 Oct 23 10:32 x this bug is specific for big-endian. gcc-4.1.2-20060928. -- Summary: '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg- 1.4.5. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29559
[Bug other/29559] '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg-1.4.5.
--- Comment #1 from pluto at agmk dot net 2006-10-23 10:35 --- (In reply to comment #0) with '-O1 -ftree-vrp -fwrapv' the armencrypt.test from gnupg-1.4.5 release producing an output until ENOSPC. with '-O1 -fno-tree-vrp' test passes. ^ fix: -O1 -fno-tree-vrp -fwrapv $ cd gnupg-1.4.5/checks/ $ srcdir=. ./armencrypt.test $ ls -l x -rw--- 1 builder2 users 108946 Oct 23 10:32 x this bug is specific for big-endian. gcc-4.1.2-20060928. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29559
[Bug target/29558] ICE in set_variable_part, at var-tracking.c:2140
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 11:29 --- Fails on the 4.2.0 branch. On the 4.1 branch it might be due to packports of 2006-05-23 Alexandre Oliva [EMAIL PROTECTED] * simplify-rtx.c (simplify_subreg): Adjust REG_OFFSET for big-endian paradoxical subregs. * var-tracking.c (struct micro_operation_def): Document that, for modify micro operations, insn is the subsequent instruction. (var_reg_delete_and_set, var_mem_delete_and_set): Split into... (var_reg_set, var_mem_set): ... new functions. (add_stores): Record subsequent insn. (compute_bb_dataflow): Use new functions for MO_USE. (emit_notes_in_bb): Use new functions for MO_USE. Emit use notes after the insn, and modify notes before the insn known to be the subsequent one. (vt_initialize): Invert sorting of MO_CLOBBERs and MO_SETs. from Alexandre Oliva [EMAIL PROTECTED] * var-tracking.c (enum micro_operation_type): Add MO_COPY. (var_debug_decl): New function. (var_reg_set): Follow debug decl link. Add location even if reg is already known to hold some other variable. (var_mem_set): Follow debug decl link. (var_reg_delete_and_set, var_mem_delete_and_set): Follow debug decl link. Delete other known locations of the variable part if requested. (var_reg_delete, var_mem_delete): Delete other known locations of the variable part if requested. (same_variable_part_p): New function. (add_stores): Select MO_COPY when appropriate. (vt_initialize): Handle it. (compute_bb_dataflow, emit_notes_in_bb): Likewise. Delete known locations for MO_SET and MO_CLOBBER. (find_variable_location_part): New function. (set_variable_part, delete_variable_part): Use it. (clobber_variable_part): New function. * dwarf2out.c (dwarf2out_var_location): Do not follow debug decl link. 2006-09-11 Alexandre Oliva [EMAIL PROTECTED] PR target/28672 * var-tracking.c (dump_dataflow_set): Start dumping at register zero. (clobber_variable_part): Kill only the variable part in registers holding it, leaving other variables alone. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Known to fail||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug target/29560] New: Poor optimization for character shifts on Atmel AVR
For setting individual bits of a register, the construct
unsigned char BitLocation = Whatever;
REG |= (1BitLocation);
is commonly used. avr-gcc fails to realize that the target register
is only 8 bits wide and performs an unnecessary 16-Bit shift of 1.
Even if this code snippet is replaced by the following:
unsigned char BitLocation = Whatever;
const unsigned char one = 1;
REG |= (one BitLocation);
The inefficient code will be generated, even with the -Os flag.
I suppose this is because the operator is not defined for 8-bit
wide data types.
Environment:
System: Darwin variable.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh
powerpc
host: powerpc-apple-darwin7.9.0
build: powerpc-apple-darwin7.9.0
target: avr-unknown-none
configured with: ../configure --target=avr --prefix=/usr/local/atmel
--enable-languages=c --disable-libssp --enable-__cxa_atexit
--enable-clocale=gnu --disable-nls : (reconfigured) ../configure --target=avr
--prefix=/usr/local/avr --enable-languages=c --disable-libssp
--enable-__cxa_atexit --enable-clocale=gnu --disable-nls
How-To-Repeat:
Use the following test program, compile with -Os -S to see assembler
code generated by avr-gcc:
#include avr/io.h
void setpin(unsigned char pin, unsigned char val) {
if (val == 1) PORTC |= (1pin);
else PORTC = ~(1pin);
}
void setpin1(unsigned char pin, unsigned char val) {
const unsigned char one = 1;
if (val == 1) PORTC |= (onepin);
else PORTC = ~(onepin);
}
int main(void) {
setpin(3, 1);
setpin1(3, 1);
return 0;
}
--- Comment #1 from r dot leitgeb at x-pin dot com 2006-10-23 11:39 ---
Fix:
Define shift operators for 8 bit wide data types, use if possible.
I'm not a compiler expert but I know that the multiply operator
detects the data types involved, so it should be doable with the
shift operators as well.
--
Summary: Poor optimization for character shifts on Atmel AVR
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot leitgeb at x-pin dot com
GCC build triplet: powerpc-apple-darwin7.9.0
GCC host triplet: powerpc-apple-darwin7.9.0
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560
[Bug other/29559] '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg-1.4.5.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 11:45 --- Testcase? ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29559
[Bug other/29559] '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg-1.4.5.
--- Comment #3 from pluto at agmk dot net 2006-10-23 11:51 --- (In reply to comment #2) Testcase? ;) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.5.tar.bz2 ;) working on reduced version... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29559
[Bug fortran/29561] New: hexadecimal constant problem
The following sample code: program testhexconstant integer, parameter :: i4_ = Selected_Int_Kind( 9) ! works fine integer(i4_), parameter :: pos_nan_lower = z7F81 ! triggers an error integer(i4_), parameter :: pos_nan_lower = zFF81 end program testhexconstant triggers this error: gfortran -o testhex TestHex.F90 In file TestHex.F90:8 integer(i4_), parameter :: b = zFF81 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1) for the gfortran version downloaded today (20061023) from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz while the previous version that I had installed (dated 20060914) downloaded from the same place, just works fine with this code. This hex value should fit nicely anyway in a 4 byte integer, so I don't really understand what is happening here. regards, Jos de Kloe -- Summary: hexadecimal constant problem Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29561
[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-23 11:58 --- Note this is a regression on the 4.1 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 4.2.0 Known to work||4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
[Bug fortran/29561] hexadecimal constant problem
--- Comment #1 from kloedej at knmi dot nl 2006-10-23 12:03 --- Sorry, variable names should differ of course, the sample code should be: program testhexconstant integer, parameter :: i4_ = Selected_Int_Kind( 9) ! works fine integer(i4_), parameter :: a = z7F81 ! triggers an error integer(i4_), parameter :: b = zFF81 end program testhexconstant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29561
[Bug target/29347] i386 mode switching clobbers fp exception handling bits
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-10-23 12:10 --- (In reply to comment #3) Can you provide a testcase where something goes wrong? I was merely documenting a problem that I found while reading the code; I don't have time to write a testcase now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29347
[Bug fortran/29562] New: -malign-double breaks formatted IO
The program program gftest write(*,'(a)') 'Hello World' end program gftest generates the erroneous error report At line 3 of file gftest.f90 Fortran runtime error: Missing initial left parenthesis in format Äø when compiled with the -malign-double flag. In a larger program -malign-double results in various undefined behaviour including segmentation faults. -- Summary: -malign-double breaks formatted IO Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: refson dot temp at ntlworld dot com 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=29562
[Bug fortran/29562] -malign-double breaks formatted IO
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 13:02 --- Keith, You do not report your hardware/OS/gfortran version - your testcase works for me on amd64/SUSE10.1 or Cygwin_NT/gcc-4.3 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562
[Bug fortran/29562] -malign-double breaks formatted IO
--- Comment #2 from refson dot temp at ntlworld dot com 2006-10-23 13:46 --- Sorry. This is on a 32-bit AMD Athlon 1800+ processor. I assume the issue doesn't arise on 64-bit hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562
[Bug fortran/29562] -malign-double breaks formatted IO
--- Comment #3 from refson dot temp at ntlworld dot com 2006-10-23 13:48 --- For the record [EMAIL PROTECTED] New_Code_TCM]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20061023 --enable-languages=c,fortran --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20061023 (experimental) The O/S is Mandriva 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562
[Bug fortran/29563] New: Internal read loses data.
gcc version 4.3.0 20061023 (experimental) Mandriva 2006.0 The program program gfbread character(len=256), dimension(3) :: block_data = (/'1 2 3','4 5 6','7 8 9'/) real(kind=8), dimension(3,3) :: tmp_box read(block_data,*,iostat=iostat)((tmp_box(i,j),j=1,3),i=1,3) write(*,'(3F10.5)') ((tmp_box(i,j),j=1,3),i=1,3) end program gfbread prints the output 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 0.0 instead of the correct 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 -- Summary: Internal read loses data. Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: refson dot temp at ntlworld dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug fortran/29564] New: build of gfortran with --disable-shared fails
I want to build gfortran with --disable-shared so that I can give fortran
programs created with gfortran to people who need to use the programs, but do
not have gfortran installed. I configured with -
../gcc/configure --disable-shared --prefix=/usr/local/gfortran
--enable-languages=c,fortran
and used -
make -j 4
After about 12 minutes the build failed trying to strip shared libraries that
did not exist -
.
.
.
.
done
MLIBS=`/Users/dir/gfortran/ibin2/./gcc/xgcc -B/Users/dir/gfortran/ibin2/./gcc/
-B/usr/local/gfortran/powerpc-apple-darwin8.8.0/bin/
-B/usr/local/gfortran/powerpc-apple-darwin8.8.0/lib/ -isystem
/usr/local/gfortran/powerpc-apple-darwin8.8.0/include -isystem
/usr/local/gfortran/powerpc-apple-darwin8.8.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.4.dylib_T${mlib} \
-s ../../gcc/gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \
./${mlib}/libgcc_s.1.dylib.tmp || exit 1 ; \
done
strip: can't open file: /Users/dir/gfortran/ibin2/gcc/libgcc_s.1.dylib.tmp (No
such file or directory)
make[3]: *** [libgcc_s.10.5.dylib] Error 1
make[3]: *** Waiting for unfinished jobs
strip: can't open file: /Users/dir/gfortran/ibin2/gcc/libgcc_s.1.dylib.tmp (No
such file or directory)
make[3]: *** [libgcc_s.10.4.dylib] Error 1
rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
[dranta:~/gfortran/ibin2] dir%
--
Summary: build of gfortran with --disable-shared fails
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: Darwin 8.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29564
[Bug debug/27017] [4.0/4.1/4.2 Regression] Debug information for static local class members are not emitted
--- Comment #9 from drow at gcc dot gnu dot org 2006-10-23 14:15 --- I haven't had another chance to work on this; update assigned to reflect reality. Hopefully the analysis will be useful to someone. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
[Bug boehm-gc/25652] Java support for amd64-pc-freebsd
--- Comment #6 from arno at heho dot snv dot jussieu dot fr 2006-10-23 14:58 --- Created an attachment (id=12480) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12480action=view) Take III Most of the original patch probably has been commited when adding support for GNU/kFreeBSD. However, this final small patch is still needed to actually recognise freebsd-amd64 and correctly build and run boehm-gc when --enable-libgcj is given -- arno at heho dot snv dot jussieu dot fr changed: What|Removed |Added Attachment #10578|0 |1 is obsolete|| Attachment #11950|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #8 from daney at gcc dot gnu dot org 2006-10-23 15:00 --- The patch is here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01149.html -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2006-10-20 03:51:04 |2006-10-23 15:00:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug fortran/29562] -malign-double breaks formatted IO
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 15:19 --- This is not a bug, -malign-double changes the ABI. -- 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=29562
[Bug fortran/29564] build of gfortran with --disable-shared fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 15:22 --- *** This bug has been marked as a duplicate of 26510 *** -- 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=29564
[Bug bootstrap/26510] --disable-shared broken for darwin platform
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 15:22 --- *** Bug 29564 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
[Bug target/26510] [4.1/4.2 Regression] --disable-shared broken for darwin platform
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:24 --- Caused by: 2005-09-28 Geoffrey Keating [EMAIL PROTECTED] * config/rs6000/t-darwin8: Uncomment contents, allow -m64 multilib to be built. * Makefile.in: Export LIPO_FOR_TARGET, STRIP_FOR_TARGET. (stage1-start): Delete old libgcc and libunwind before moving anything into the stage directory. (stage2-start): Likewise. (stage3-start): Likewise. (stage4-start): Likewise. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|bootstrap |target Ever Confirmed|0 |1 Keywords||build Last reconfirmed|-00-00 00:00:00 |2006-10-23 15:24:19 date|| Summary|--disable-shared broken for |[4.1/4.2 Regression] -- |darwin platform |disable-shared broken for ||darwin platform Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
[Bug bootstrap/19176] [4.0/4.1/4.2 Regression] static gcc cannot be build (libgcc_eh.a required for static gcc)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:26 --- Caused by: 2004-11-03 Andrew Pinski [EMAIL PROTECTED] * config/darwin.h (REAL_LIBGCC_SPEC): Define to use shared libgcc for shared libraries. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||link-failure Last reconfirmed|-00-00 00:00:00 |2006-10-23 15:26:54 date|| Summary|static gcc cannot be build |[4.0/4.1/4.2 Regression] |(libgcc_eh.a required for |static gcc cannot be build |static gcc) |(libgcc_eh.a required for ||static gcc) Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19176
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:44 --- (In reply to comment #4) Like this? Actually thinking about it some more, that will cause stage1 not to be build with the more checking if the user wanted it to be, ie --enable-checking=yes,rtl,gcac when configuring. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug fortran/29565] New: ICE in gimplify_var_or_parm_decl, at gimplify.c
When the attached program is compiled by gfortran bug061023.f90 I get an internal compiler error: gfortran bug061023.f90 bug061023.f90: In function phaml_restore: bug061023.f90:15: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1665 The version is gfortran --version GNU Fortran 95 (GCC) 4.3.0 20061023 (experimental) -- Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: william dot mitchell at nist dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
[Bug fortran/29565] ICE in gimplify_var_or_parm_decl, at gimplify.c
--- Comment #1 from william dot mitchell at nist dot gov 2006-10-23 15:47 --- Created an attachment (id=12481) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12481action=view) this is the program that demonstrates the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
[Bug middle-end/29558] [4.2 Regression] ICE in set_variable_part, at var-tracking.c:2140
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Component|target |middle-end Known to work||4.0.4 3.4.6 Summary|ICE in set_variable_part, at|[4.2 Regression] ICE in |var-tracking.c:2140 |set_variable_part, at var- ||tracking.c:2140 Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug fortran/29565] ICE in gimplify_var_or_parm_decl, at gimplify.c
--- Comment #2 from william dot mitchell at nist dot gov 2006-10-23 15:49 --- This is on Linux Fedora Core 1 with a Linux binary download of gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
[Bug fortran/29565] ICE in gimplify_var_or_parm_decl, at gimplify.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
[Bug fortran/29563] Internal read loses data.
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 15:54 --- program gfbread character(len=256), dimension(3) :: block_data = (/' 1 2 3',' 4 5 6',' 7 8 9'/) real(kind=8), dimension(3,3) :: tmp_box read(block_data,'(3(3f2.0/))',iostat=iostat)((tmp_box(i,j),j=1,3),i=1,3) write(*,'(3F10.5)') ((tmp_box(i,j),j=1,3),i=1,3) end program gfbread works fine - the only difference in the code is the io call, so I would guess that something is awry with list_read.c Any ideas, Jerry? Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug fortran/29565] [4.1/4.2 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 15:58 --- Confirmed, reduced testcase: module hash_mod type element_t integer :: gid end type element_t type grid_type type(element_t), pointer :: element(:) end type grid_type contains subroutine hash_read_key(key) integer, intent(out) :: key(:) end subroutine hash_read_key subroutine phaml_restore(grid) type(grid_type) :: grid call hash_read_key(grid%element(1:1)%gid) call hash_read_key(grid%element(1:1)%gid) call hash_read_key(grid%element(1:1)%gid) end subroutine phaml_restore end module hash_mod --- The problem is that in: atmp.0.data = (void *) A.1; A.1 is not in the BIND_EXPRs at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.2 4.2.0 4.3.0 Known to work||4.0.4 Last reconfirmed|-00-00 00:00:00 |2006-10-23 15:58:29 date|| Summary|ICE in |[4.1/4.2 Regression] ICE in |gimplify_var_or_parm_decl, |gimplify_var_or_parm_decl, |at gimplify.c |at gimplify.c Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
[Bug debug/29558] [4.2 Regression] ICE in set_variable_part, at var-tracking.c:2140
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 16:06 --- It works for me with 4.1.2 20061017 but fails with 4.2.0 20061015 so this only fails on the 4.2 branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |debug Ever Confirmed|0 |1 Known to work|4.0.4 3.4.6 |4.0.4 3.4.6 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-23 16:06:32 date|| Target Milestone|4.1.3 |4.2.0 Version|4.1.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug libstdc++/24025] libstdc++ crashes when out of memory exception thrown
--- Comment #9 from pcarlini at suse dot de 2006-10-23 16:26 --- The issue seems more tricky, even for TLS platforms, see: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00333.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
[Bug fortran/29561] hexadecimal constant problem
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-23 17:10 --- Please the audit trail for Pr 18026. It gives the details. Also, the difference in the earlier version of gfortran to the newer version is due to this patch. 2006-09-07 Steven G. Kargl [EMAIL PROTECTED] * gfortran.h (gfc_integer_info): Eliminate max_int. * arith.c (gfc_arith_init_1): Remove initialization of max_int. (gfc_arith_done_1): Remove clearing of max_int. (gfc_check_integer_range): Fix range chekcing of overflow. * simplify.c (gfc_simplify_not): Construct mask that was max_int. *** This bug has been marked as a duplicate of 18026 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29561
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-23 17:10 --- *** Bug 29561 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/29565] [4.1/4.2 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-23 17:11 --- Further reduced testcase, confirmed on ppc-darwin: type element_t integer :: gid end type element_t type(element_t) :: element(1) call hash_read_key(element%gid) call hash_read_key(element%gid) call hash_read_key(element%gid) contains subroutine hash_read_key(key) integer, intent(out) :: key(1) end subroutine hash_read_key end I'll also note that the following slightly modified testcase segfaults: type element_t integer :: gid end type element_t contains subroutine hash_read_key(key) integer, intent(out) :: key(1) end subroutine hash_read_key type(element_t) :: element(1) call hash_read_key(element%gid) call hash_read_key(element%gid) call hash_read_key(element%gid) end Program received signal SIGSEGV, Segmentation fault. 0x0805b323 in variable_decl (elem=Variable elem is not available. ) at ../../../trunk/gcc/fortran/decl.c:1424 1424 if (current_ts.type == BT_DERIVED (gdb) where #0 0x0805b323 in variable_decl (elem=Variable elem is not available. ) at ../../../trunk/gcc/fortran/decl.c:1424 #1 0x0805bcbc in gfc_match_data_decl () at ../../../trunk/gcc/fortran/decl.c:3381 #2 0x0808716a in match_word (str=Variable str is not available. ) at ../../../trunk/gcc/fortran/parse.c:66 #3 0x0808770d in decode_statement () at ../../../trunk/gcc/fortran/parse.c:135 #4 0x0808809e in next_statement () at ../../../trunk/gcc/fortran/parse.c:499 #5 0x0808a3cd in parse_contained (module=0) at ../../../trunk/gcc/fortran/parse.c:2796 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-10-23 15:58:29 |2006-10-23 17:11:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565
[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-10-23 17:30 ---
(In reply to comment #6)
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=116424
r116424 | amylaar | 2006-08-25 18:51:57 + (Fri, 25 Aug 2006)
When I modify the testcase to have the function defintion after the use:
struct block;
static int remove_out_of_scope_renamings ();
int
ada_lookup_symbol_list (const struct block *block0)
{
return remove_out_of_scope_renamings ((struct block *) block0);
}
static int
remove_out_of_scope_renamings (current_block)
struct block *current_block;
{
return 1;
}
I still see that the cast has been stripped at the point where
c_convert_parm_for_inlining is called:
(gdb) call debug_tree(value)
parm_decl 0xb593c000 block0
type pointer_type 0xb59315c0
type record_type 0xb5931564 block readonly VOID
...
OTOH, if I further change the passed parameter to a plain 0, value contains an
unadorned integer constant.
(gdb) call debug_tree(value)
integer_cst 0xb58aa978 type integer_type 0xb58bb284 int constant invariant
0
I think it is wrong that we are optimizing the expression before converting
it to the required type.
Moreover, why is it right to drop NOP_EXPRESSIONS there? If for some reason
the compiler finds it needs to put the initializer in a temporary variable,
and uses the type of the value for that variable, we'll get an alias set
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug fortran/29567] New: [gfortran, 4.3 regression] ICE in build2_stat, at tree.c:2963
When compiling the following code with current gfortran 4.3, the compiler ICEs module test contains function gn_lc2uc1(string_lc) result(string_uc) character(len = *), intent(in) :: string_lc character(len = len(string_lc)) :: string_uc integer :: ch, nch, i logical :: found nch = len(string_lc) found = .false. do ch = 1, nch i = ichar(string_lc(ch: ch)) if (((i = 97) .and. (i = 122)) .and. (.not. found)) then string_uc(ch: ch) = char(i - 32) found = .true. else if ((i = 65) .and. (i = 92)) then string_uc(ch: ch) = char(i) found = .true. else string_uc(ch: ch) = char(i) end if end do end function gn_lc2uc1 end module test [EMAIL PROTECTED]:~/tmp gfortran -O2 -v test.f90 Driving: gfortran -O2 -v test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/martin/software/gcc/configure --disable-multilib --with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr --prefix=/home/martin/software/ugcc --enable-languages=c++,fortran --enable-checking=release Thread model: posix gcc version 4.3.0 20061023 (experimental) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -O2 -version -I /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/ccsOQohf.s GNU F95 version 4.3.0 20061023 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20061023 (experimental). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128005 test.f90: In function gn_lc2uc1: test.f90:4: internal compiler error: in build2_stat, at tree.c:2963 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The ICE does not occur with the head ov the 4.2 branch, so the probelm must be very new. It does not appear at lower optimisation levels either. -- Summary: [gfortran, 4.3 regression] ICE in build2_stat, at tree.c:2963 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg 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=29567
[Bug fortran/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|[gfortran, 4.3 regression] |[4.3 regression] ICE in |ICE in build2_stat, at |build2_stat, at tree.c:2963 |tree.c:2963 | Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug fortran/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 18:13 --- Can you try the patch in: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01168.html ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug libfortran/29568] New: implement unformatted files with subrecords (Intel style)
There's an on-off discussion on the gfortran mailing list on making 4-byte record markers the default for gfortran. This would only be acceptable if large (2 GB) records could be written that way. I'm taking a shot at this. -- Summary: implement unformatted files with subrecords (Intel style) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: tkoenig at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #12 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-23 18:52 --- Cf. also bug 29471. In the Intel Fortran Compiler real :: r data r/some BOZ/ gives the same result as using the Fortran 2003 statement in ifort: real :: r r = real(some boz) (At least with the -switch fe_new_BOZ_constants.) Therefore, with Fortran 2003 BOZ support in place, implementing this in gfortran should then become easier. (Working around will also become easier.( (As gfortran accepts [integer] BOZ everywhere, it will also have the problem whether real( z'F' ) is meant as convert integer BOZ to integer and then to real or as convert real BOZ to real. Ifort gives a default warning for both -stand f95 and -stand f03, treating the BOZ differently for those two cases.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug c/29569] New: use function name as operand in asm inline statement
(stevenhu) / [159] cat a.c
void func(){}
main(){
int a,b;
/*asm( %ecx %eax);*/
asm(add %0,%1,%2:=r(a):m(func),m(b));
}
(stevenhu) / [160] gcc -S a.c
a.c: In function `main':
a.c:6: Internal compiler error in instantiate_virtual_regs_1, at
function.c:3972
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
(stevenhu) / [161]
--
Summary: use function name as operand in asm inline statement
Product: gcc
Version: 3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stevenhuca at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29569
[Bug target/26510] [4.1/4.2 Regression] --disable-shared broken for darwin platform
--- Comment #6 from dir at lanl dot gov 2006-10-23 19:02 ---
I tried to disable the multilib with -
../gcc/configure --disable-shared --disable-multilib
--prefix=/usr/local/gfortran --enable-languages=c,fortran
but I still about the save errors -
MLIBS=`/Users/dir/gfortran/ibin2/./gcc/xgcc -B/Users/dir/gfortran/ibin2/./gcc/
-B/usr/local/gfortran/powerpc-apple-darwin8.8.0/bin/
-B/usr/local/gfortran/powerpc-apple-darwin8.8.0/lib/ -isystem
/usr/local/gfortran/powerpc-apple-darwin8.8.0/include -isystem
/usr/local/gfortran/powerpc-apple-darwin8.8.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.5.dylib_T${mlib} \
-s ../../gcc/gcc/config/rs6000/darwin-libgcc.10.5.ver -c -u \
./${mlib}/libgcc_s.1.dylib.tmp || exit 1 ; \
done
strip: can't open file: /Users/dir/gfortran/ibin2/gcc/libgcc_s.1.dylib.tmp (No
such file or directory)
make[3]: *** [libgcc_s.10.4.dylib] Error 1
make[3]: *** Waiting for unfinished jobs
strip: can't open file: /Users/dir/gfortran/ibin2/gcc/libgcc_s.1.dylib.tmp (No
such file or directory)
make[3]: *** [libgcc_s.10.5.dylib] Error 1
rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
[dranta:~/gfortran/ibin2] dir%
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
[Bug fortran/24828] Z and negative integers
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:05 --- (In reply to comment #4) Can this PR be closed? I'd say yes. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug fortran/17872] gfortran accepts 255_1 as integer constant
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:07 --- Fixed on 4.2 branch and probably earlier: In file a.f90:1 integer*1 :: i1 = 255_1 1 Error: Integer too big for its kind at (1) In file a.f90:2 integer*2 :: i2 = 65535_2 1 Error: Integer too big for its kind at (1) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17872
[Bug other/29524] Too much RAM used: __clz_tab[] linked
--- Comment #4 from batt at develer dot com 2006-10-23 19:09 --- I have 3 projects involving gcc and avr, and all of these have an increased RAM usage due to __clz_tab linking after switching from gcc 4.1.1 to 4.2. I will try as soon as possible to find a suitable testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug c++/28255] [4.1 regression] ICE with (GNU extension) C99 compund literal (scalar), initializer and templates
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-10-23 19:11 --- As Andrew already noted, this is not fixed on the 4.1 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.1/4.2 regression] ICE|[4.1 regression] ICE with |with (GNU extension) C99|(GNU extension) C99 compund |compund literal (scalar), |literal (scalar), |initializer and templates |initializer and templates http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28255
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #4 from janis at gcc dot gnu dot org 2006-10-23 19:16 --- A regression hunt using the testcase from comment #2 with -O2 using an alpha-linux cross compiler identified this patch which fixed the ICE on mainline: http://gcc.gnu.org/viewcvs?view=revrev=110556 r110556 | rakdver | 2006-02-03 19:28:09 + (Fri, 03 Feb 2006) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug c/29569] use function name as operand in asm inline statement
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 19:27 --- This works for me in 3.0.4 to 3.4.0 and now errors out in 4.0.0 and above with: t.c:5: error: memory input 1 is not directly addressable -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29569
[Bug fortran/25080] ICE/missing error on different ranks for dummy and actual arguments
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:28 --- We now reject the reporter's code as we should. We could still reject the code in comment #1, but none of the other compilers I tried reject it. Marking this as low priority (I think it will be fixed by Paul Thomas' patch for in-file checking). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Keywords|ice-on-invalid-code | Last reconfirmed|2006-06-04 10:26:41 |2006-10-23 19:28:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25080
[Bug c++/29020] [4.0 regression] ICE using AN::A instead of AN in friend declaration
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-10-23 19:32 --- Mark, you accidentally committed the fix in parser.c with your patch for PR 28506 (rev. 117695) to the 4.1 branch: http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00361.html So this is now fixed on the 4.1 branch, too. For completeness sake, would you mind committing also the hunk from friend.c and the testcase? -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE using |using AN::A instead of|AN::A instead of AN in |AN in friend declaration |friend declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2006-10-23 19:39 --- Subject: Re: boz initialization of REALs fails On Mon, Oct 23, 2006 at 06:52:06PM -, tobias dot burnus at physik dot fu-berlin dot de wrote: In the Intel Fortran Compiler real :: r data r/some BOZ/ gives the same result as using the Fortran 2003 statement in ifort: real :: r r = real(some boz) (At least with the -switch fe_new_BOZ_constants.) (1) I'd need to see an example. (2) The 2 code examples are technically invalid F95. (3) The first code example is invalid in F2003. Therefore, with Fortran 2003 BOZ support in place, implementing this in gfortran should then become easier. (Working around will also become easier.( gfortran implements the F2003 intrepetation of a BOZ in a data statement. See the BIG comment in match_boz_constant. What is missing is gfortran does not retain knowledge that a BOZ was seen, so when you hit real r data r/some BOZ/ the assignment to r does not know the value can from a BOZ. Hence, a warning/error can't be issued. (As gfortran accepts [integer] BOZ everywhere, it will also have the problem whether real( z'F' ) is meant as convert integer BOZ to integer and then to real or as convert real BOZ to real. Ifort gives a default warning for both -stand f95 and -stand f03, treating the BOZ differently for those two cases.) I spent a few hours on Friday night and Saturday looking at the F2003 behavior for REAL(z'f'). My first attempt to handle this failed, which I don't understand. I have a plan B. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-23 19:49 --- Thomas, Have you written Adrain about his plans concerning his patch? BTW, I think the Intel subrecord approach is probably the best solution to the large record problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug middle-end/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-10-23 19:50 --- (In reply to comment #1) Can you try the patch in: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01168.html ? Yes, this patch fixes the problem. Thanks for the prompt reply! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug c++/29570] New: [4.1/4.2/4.2 regression] ICE with brace-enclosed initializer
The following valid code snippet triggers a segfault on mainline,
4.1 branch, and 4.0 branch. The regression is recent, since GCC 4.1.1
is not affected.
templateint struct A
{
static const int i;
};
templateint N const int AN::i = { AN::i };
bug.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [4.1/4.2/4.2 regression] ICE with brace-enclosed
initializer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29570
[Bug c++/29571] New: [4.2/4.3 regression] ICE with invalid static const member
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
==
struct A
{
static const int i = 0/0 + ;
static const int j = int(i);
};
==
bug.cc:3: warning: division by zero in '0 / 0'
bug.cc:3: error: invalid conversion from 'const char*' to 'int'
bug.cc:3: error: 'A::i' cannot be initialized by a non-constant expression when
being declared
bug.cc:4: internal compiler error: in build_c_cast, at cp/typeck.c:5491
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3 regression] ICE with invalid static const
member
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29571
[Bug c++/29571] [4.2/4.3 regression] ICE with invalid static const member
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29571
[Bug c++/29573] New: [4.0/4.1/4.2/4.3 regression] ICE after parse error in template argument
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
templateint struct A {};
templatetypename struct B : A sizeof(=) {};
templatetypename struct C : A sizeof(=) {};
==
bug.cc:3: error: parse error in template argument list
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2/4.3 regression] ICE after parse error in
template argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29573
[Bug c++/29573] [4.0/4.1/4.2/4.3 regression] ICE after parse error in template argument
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29573
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #13 from ghazi at gcc dot gnu dot org 2006-10-23 20:25 --- Subject: Bug 29335 Author: ghazi Date: Mon Oct 23 20:24:55 2006 New Revision: 117983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117983 Log: PR middle-end/29335 * builtins.c (fold_builtin_sin, fold_builtin_cos, fold_builtin_tan): Fold all constant arguments. Take a type argument as necessary. (do_mpfr_arg1): New. * real.c, real.h (real_from_mpfr, mpfr_from_real): New. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/real.c trunk/gcc/real.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug c/29574] New: Gcc gives invalid warning about unitialized variable
Compile Linux 2.6.18 kernel. Warns that idx may be uninitialized in
fs/bio.c:bio_alloc_bioset(), but it clearly *is* being initialized
by bvec_alloc_bs.
The kernel team will not allow us to pre-initialize these, as it is
a gcc bug. On the other hand, we're drowned in invalid warnings, so
can't see any real problems. Older versions of gcc (3.x) did not
have this problem.
struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set *bs)
{
struct bio *bio = mempool_alloc(bs-bio_pool, gfp_mask);
if (likely(bio)) {
struct bio_vec *bvl = NULL;
bio_init(bio);
if (likely(nr_iovecs)) {
unsigned long idx;
bvl = bvec_alloc_bs(gfp_mask, nr_iovecs, idx, bs);
if (unlikely(!bvl)) {
mempool_free(bio, bs-bio_pool);
bio = NULL;
goto out;
}
bio-bi_flags |= idx BIO_POOL_OFFSET;
bio-bi_max_vecs = bvec_slabs[idx].nr_vecs;
}
bio-bi_io_vec = bvl;
}
out:
return bio;
}
static inline struct bio_vec *bvec_alloc_bs(gfp_t gfp_mask, int nr, unsigned
long *idx, struct bio_set *bs)
{
struct bio_vec *bvl;
struct biovec_slab *bp;
/*
* see comment near bvec_array define!
*/
switch (nr) {
case 1: *idx = 0; break;
case 2 ... 4: *idx = 1; break;
case 5 ... 16: *idx = 2; break;
case 17 ... 64: *idx = 3; break;
case 65 ... 128: *idx = 4; break;
case 129 ... BIO_MAX_PAGES: *idx = 5; break;
default:
return NULL;
}
/*
* idx now points to the pool we want to allocate from
*/
bp = bvec_slabs + *idx;
bvl = mempool_alloc(bs-bvec_pools[*idx], gfp_mask);
if (bvl)
memset(bvl, 0, bp-nr_vecs * sizeof(struct bio_vec));
return bvl;
}
--
Summary: Gcc gives invalid warning about unitialized variable
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mbligh at mbligh dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-10-23 20:41
---
Just a minor nit: The second error message still contains the - token
which should not have been generated. But that's probably tolerable.
bug.c:2:1: error: pasting - and does not give a valid preprocessing
token
bug.c:2: error: expected identifier or '(' before '-' token
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 20:57 --- How is unlikely defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-23 20:59 --- If it is defined using __builtin_expect, then this is most likely PR 21513 which was fixed for 4.2.0, it is hard to fix correctly for 4.1.0 and 4.0.0 without removing all of loop.c. Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #3 from mbligh at mbligh dot org 2006-10-23 21:08 --- Yeah, is builtin_expect ;-( #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #4 from mbligh at mbligh dot org 2006-10-23 21:19 --- And indeed, if I remove that unlikely(), it does work. There's another set of these where the called initializer is not inlined, ie: int x; initializer(x); Which it seems totally blind to, even if the initializer does x = 0 right at the top. Are those fixable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug tree-optimization/21513] [4.0/4.1/4.2 Regression] __builtin_expect getting in the way of uninitialized warnings
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 21:30 --- *** Bug 29574 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mbligh at mbligh dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21513
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 21:30 --- (In reply to comment #4) And indeed, if I remove that unlikely(), it does work. There's another set of these where the called initializer is not inlined, ie: int x; initializer(x); If initializer is not inlined, you will not get a warning. This is the same as PR 21513 as __builtin_expect is getting in the way. *** This bug has been marked as a duplicate of 21513 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts
--- Comment #8 from pinskia at gmail dot com 2006-10-23 21:37 --- Subject: Re: [4.2 Regression] optmization generates warning for casts On 23 Oct 2006 17:30:22 -, amylaar at gcc dot gnu dot org [EMAIL PROTECTED] wrote: I think it is wrong that we are optimizing the expression before converting it to the required type. Moreover, why is it right to drop NOP_EXPRESSIONS there? If for some reason the compiler finds it needs to put the initializer in a temporary variable, and uses the type of the value for that variable, we'll get an alias set problem. Hmm, This is one of the language hooks which really need to go away for LTO as I understand it. Also I the real problem comes from the inliner or the gimplifier (I am betting the gimplifier) removing the cast as it is useless in our type system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug tree-optimization/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||10/msg01168.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-10-23 21:37:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug tree-optimization/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963
-- pinskia 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29567
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #6 from mbligh at mbligh dot org 2006-10-23 21:42 --- Re the non-inlined functions ... Have been discussing this with Andrew Morton. what do we do then? Adding dead code to fix the fact that gcc can't see into other functions is incorrect and inefficient. Having lots of compiler warnings drowns out real ones, and is not acceptable. How do we get around this? Can we at least get the option to not warn if it's blind to the problem because it goes through another function, if not make that the default? gcc warnings are an incredibly valuable way to find code bugs if they're real. If some are not real, we lose the benefit to all, as the real ones are drowned in the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 21:45 --- (In reply to comment #6) Re the non-inlined functions ... Have been discussing this with Andrew Morton. what do we do then? Adding dead code to fix the fact that gcc can't see into other functions is incorrect and inefficient. Initialize the variable and forget about inefficiency. Again this is fixed for 4.2.0, the warning is only because __builtin_expect gets in the way of figuring out if the variable is used uninitialized, nothing more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #8 from mbligh at mbligh dot org 2006-10-23 21:50 --- Initialize the variable and forget about inefficiency. Again this is fixed for 4.2.0, the warning is only because __builtin_expect gets in the way of figuring out if the variable is used uninitialized, nothing more. I understand the __builtin_expect case is fixed in 4.2, and am fine with that, but I was talking about the ones that aren't inlined, and don't use builtin_expect. Does gcc 4.2 walk through functions as well, or will it always produce an invalid warning there? Thanks, M. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574
Re: [Bug middle-end/29574] Gcc gives invalid warning about unitialized variable
--- Comment #8 from mbligh at mbligh dot org 2006-10-23 21:50 --- Initialize the variable and forget about inefficiency. Again this is fixed for 4.2.0, the warning is only because __builtin_expect gets in the way of figuring out if the variable is used uninitialized, nothing more. I understand the __builtin_expect case is fixed in 4.2, and am fine with that, but I was talking about the ones that aren't inlined, and don't use builtin_expect. Does gcc 4.2 walk through functions as well, or will it always produce an invalid warning there? No, for ones which are not inlined, GCC does not look through other functions to check for the warning. Thanks, Andrew Pinski
