resource.c:1142: internal compiler error: Segmentation fault: 11
cc -O -pipe -funroll-loops -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/tmp/usr\ -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermydesk-freebsd\ -DIN_GCC -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/rtlanal.c /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/resource.c: In function `mark_target_live_regs': /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/resource.c:1142: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error root: gcc -v uname -a Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 FreeBSD ws3-plovdiv.digsys.bg 6.1-RC FreeBSD 6.1-RC #0: Tue Apr 18 15:12:58 EEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec i386 root: signature.asc Description: OpenPGP digital signature
[Bug target/27125] optimize array bit shift
--- Comment #2 from ajrobb at bigfoot dot com 2006-05-10 09:45 --- Created an attachment (id=11428) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11428action=view) multi-word bit shift This is my loop - using a single index that decrements to zero I have seen simpler loops perform twice as fast with decrement to zero compared with increment to value. .L8: movl-4(%ebp,%ebx,4), %eax movl%edi, %ecx movl(%ebp,%ebx,4), %edx sall%cl, %eax movl%esi, %ecx shrl%cl, %edx orl %eax, %edx movl%edx, (%ebp,%ebx,4) decl%ebx jne .L8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27125
[Bug c++/27519] Another's class destructor name
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-10 08:06 --- Fixed in 4.0.3: /tmp /space/rguenther/install/gcc-4.0.3/bin/g++ -Wall -S t.C t.C:11: error: declaration of '~TPoligon' as member of 'TPoints' -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.0.0 4.0.1 4.0.2 Known to work|4.1.0 4.2.0 3.4.0 |4.1.0 4.2.0 3.4.0 3.4.6 ||4.0.3 Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27519
[Bug middle-end/27529] New: Does not fold (char *)(size_t)char_ptr or (size_t)(char *)size_t_var
Fold does not fold two comparisons in a row if the intermediate type differs in being a pointer vs. an integer variable. This also is the reason for not folding (Foo *)(char *)foo with foo being of Foo type (we can fold that to (Foo *)foo). There's code to do that I think, but it's just missing adjustment for pointers: /* In addition to the cases of two conversions in a row handled below, if we are converting something to its own type via an object of identical or wider precision, neither conversion is needed. */ if (TYPE_MAIN_VARIANT (inside_type) == TYPE_MAIN_VARIANT (type) ((inter_int final_int) || (inter_float final_float)) inter_prec = final_prec) return fold_build1 (code, type, TREE_OPERAND (op0, 0)); I have a patch. Of course RTL doesn't care. -- Summary: Does not fold (char *)(size_t)char_ptr or (size_t)(char *)size_t_var Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization, TREE Severity: enhancement Priority: P3 Component: middle-end AssignedTo: rguenth at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27529
[Bug fortran/24549] ICE with invalid pseudo-declaration statement
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-10 09:07
---
I can reproduce this ICE with mainline on i686-linux. I propose the following
patch:
Index: parse.c
===
--- parse.c (revision 113603)
+++ parse.c (working copy)
@@ -1292,7 +1292,7 @@
static void
reject_statement (void)
{
-
+ gfc_new_block = NULL;
gfc_undo_symbols ();
gfc_clear_warning ();
undo_new_statement ();
(see http://gcc.gnu.org/ml/fortran/2006-05/msg00122.html for details).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
URL||http://gcc.gnu.org/ml/fortra
||n/2006-05/msg00122.html
Status|NEW |ASSIGNED
Keywords||patch
Last reconfirmed|2006-01-27 20:52:12 |2006-05-10 09:07:27
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24549
[Bug target/27521] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:10613
--- Comment #2 from christophe dot gengembre at paris dot ensam dot fr 2006-05-10 08:28 --- Created an attachment (id=11427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11427action=view) source that triggered the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
[Bug middle-end/27302] Fold does not fold (i j) == (j i) to 1
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-10 10:22 --- Subject: Bug 27302 Author: rguenth Date: Wed May 10 10:22:39 2006 New Revision: 113670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113670 Log: 2006-05-10 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27302 * fold-const.c (operand_equal_p): For two comparisons, try comparison of one comparison code swapped if that yields the same code. * gcc.dg/torture/pr27302.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr27302.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
[Bug middle-end/27302] Fold does not fold (i j) == (j i) to 1
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 11:03 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
[Bug libstdc++/27530] New: Polible memory leak in std::vectorint::reserve() or std::vectorint::clear()
Hello.
We have Client/server socket application (multiple clients and servers).
Servers are multiplatform can be compiled for Windows (MSVC) and for Linux
(GCC).
Recently we detected memory leak in one of kinde of our servers. At the start
it uses only 15m (that is normally). Then it slowly grows up to 2000m within 2
weeks.
Only Linux+GCC version was affected by this problem. We have checked
our server by valgrind. It detected leak. The leak is possible in
std::vectotint::reserve()or in std::vectotint::clear()
I use GCC 3.4.5 builded and installed on Fedora Core 2
REproduceable: Always.
The code producing leak:
...
typedef int card_type;
typedef int Funds;
.
const size_t MAX_CARDS_ON_HAND = 7;
typedef std::vectorcard_type CardsSet;
...
//
class CBaseSeat : public ISerializable
{
public:
CBaseSeat();
void standUpSeat();
...
protected:
unsigned m_flags;
Funds m_cash;
Funds m_bet;
CardsSet m_cardsSet;
};
//
CBaseSeat::CBaseSeat()
: m_flags(0), m_cash(0), m_bet(0), m_cardsSet()
{
m_cardsSet.reserve( MAX_CARDS_ON_HAND );
standUpSeat();
}
//
void CBaseSeat::standUpSeat()
{
m_flags = 0;
m_cash = 0;
m_bet = 0;
m_cardsSet.clear();
}
When we comment this line
//m_cardsSet.reserve( MAX_CARDS_ON_HAND );
The leak is Gone. I just can suppose that the problem in reserve() or in
clear() method whick called imediately after reserve();
Please see Valgrind report: (after several minutes of work)
==22501== 124,376 bytes in 4,442 blocks are definitely lost in loss record 6 of
6
==22501==at 0x43B8B10: operator new(unsigned) (vg_replace_malloc.c:164)
==22501==by 0x806B2F9: __gnu_cxx::new_allocatorint::allocate(unsigned,
void const*) (new_allocator.h:81)
==22501==by 0x806B191: std::_Vector_baseint, std::allocatorint
::_M_allocate(unsigned) (stl_vector.h:113)
==22501==by 0x807DD9C: int* std::vectorint, std::allocatorint
::_M_allocate_and_copyint*(unsigned, int*, int*) (stl_vector.h:715)
==22501==by 0x807DC96: std::vectorint, std::allocatorint
::reserve(unsigned) (vector.tcc:78)
==22501==by 0x80842E7: Poker::CBaseSeat::CBaseSeat() (seat.cpp:20)
==22501==by 0x807123D: Poker::CClientSeat::CClientSeat(Poker::CClientSeat
const) (seat.h:134)
==22501==by 0x80711FC: void std::_ConstructPoker::CClientSeat,
Poker::CClientSeat(Poker::CClientSeat*, Poker::CClientSeat const)
(stl_construct.h:81)
==22501==by 0x8072FB8: __gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat
std::__uninitialized_fill_n_aux__gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat ,
unsigned, Poker::CClientSeat(__gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat ,
unsigned, Poker::CClientSeat const, __false_type) (stl_uninitialized.h:194)
==22501==by 0x8072C5B: __gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat
std::uninitialized_fill_n__gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat ,
unsigned, Poker::CClientSeat(__gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat ,
unsigned, Poker::CClientSeat const) (stl_uninitialized.h:219)
==22501==by 0x8072682: std::vectorPoker::CClientSeat,
std::allocatorPoker::CClientSeat
::_M_fill_insert(__gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat ,
unsigned, Poker::CClientSeat const) (vector.tcc:314)
==22501==by 0x8071CF3: std::vectorPoker::CClientSeat,
std::allocatorPoker::CClientSeat
::insert(__gnu_cxx::__normal_iteratorPoker::CClientSeat*,
std::vectorPoker::CClientSeat, std::allocatorPoker::CClientSeat ,
unsigned, Poker::CClientSeat const) (stl_vector.h:612)
==22501==by 0x8070CAC: std::vectorPoker::CClientSeat,
std::allocatorPoker::CClientSeat ::resize(unsigned, Poker::CClientSeat
const) (stl_vector.h:398)
==22501==by 0x806FE22: std::vectorPoker::CClientSeat,
std::allocatorPoker::CClientSeat ::resize(unsigned) (stl_vector.h:412)
==22501==by 0x806C0AB: Poker::CClientGameState::read(std::istream)
(clientgamestate.cpp:144)
==22501==by 0x80B4430:
Poker::CSelfHolderPoker::CClientGameState::read(std::istream) (holder.h:147)
==22501==by 0x808BE86: Poker::CMessage::read(std::istream)
(message.cpp:71)
==22501==by 0x80A8D54:
Poker::CMessageFactory::createFromStream(Poker::CSession*, std::istream)
(messagesfactory.cpp:1206)
==22501==by 0x80E49F1:
[Bug libstdc++/27530] Polible memory leak in std::vectorint::reserve() or std::vectorint::clear()
--- Comment #1 from chris at bubblescope dot net 2006-05-10 11:31 --- Can you provide a complete program which demonstrates this link? I've tried looking at the code in question myself, and cannot observe a memory leak myself. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
[Bug fortran/27524] -fbounds-check interracts *strangely* with an array of size 1
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de 2006-05-10 11:34 --- Sorry, I missed it before, but this could definitly be a dupplicate of 19777. Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
[Bug libstdc++/27530] Possible memory leak in std::vectorint::reserve() or std::vectorint::clear()
--- Comment #2 from pcarlini at suse dot de 2006-05-10 12:10 --- Chris is right. Certainly we are not aware of any problem in that code, in particular the 3.4.5 version, very close to the original HP/SGI code and very well tested from that point of view (at least). Please provide a self-contained testcase (as small as possible, of course), otherwise the PR, not really useful, likely will be soon closed, sorry. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|Polible memory leak in |Possible memory leak in |std::vectorint::reserve() |std::vectorint::reserve() |or std::vectorint::clear()|or std::vectorint::clear() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
[Bug tree-optimization/27332] [4.2 Regression] ICE in try_interchange_loops with -ftree-loop-linear
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10 12:26 --- Created an attachment (id=11429) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11429action=view) fix proposed fix. I didn't tested it other than making sure it fixed the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27332
[Bug tree-optimization/26435] [4.1/4.2 regression] ICE with -O1 -ftree-loop-linear and higher optimization
--- Comment #5 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10 12:32 --- Created an attachment (id=11430) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11430action=view) first shot at fixing this didn't tested the patch, other than with RUNTESTFLAGS=tree-ssa.exp and the current pr report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26435
[Bug libstdc++/27530] Possible memory leak in std::vectorint::reserve() or std::vectorint::clear()
--- Comment #3 from ksharenkov at ya dot ru 2006-05-10 12:48 --- Ok, i will try to create a short program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
[Bug fortran/17741] ICE in gfc_free_namespace, at fortran/symbol.c:2208
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
12:59 ---
I think that it is not correct to emit an ICE on this one. The patch below
emits an error and bails out.
I will submit in the next 24hours.
Paul
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(r#9500;®vision 113111)
+++ gcc/fortran/symbol.c(copie de travail)
@@ -2490,8 +2490,15 @@
ns-refs--;
if (ns-refs 0)
return;
- gcc_assert (ns-refs == 0);
+ if (ns-refs != 0)
+{
+ gfc_error_now (namespace %s has %d references on being freed,
+ns-proc_name-name ? ns-proc_name-name : MAIN,
+ns-refs + 1);
+ return;
+}
+
gfc_free_statements (ns-code);
free_sym_tree (ns-sym_root);
--
paul dot richard dot thomas at cea dot fr changed:
What|Removed |Added
CC||paul dot richard dot thomas
||at cea dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17741
[Bug target/27521] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:10613
--- Comment #3 from christophe dot gengembre at paris dot ensam dot fr 2006-05-10 13:49 --- the bug is trigged in Subroutine RecupValLuesDsCmdLC. A .f source file with only Subroutine RecupValLuesDsCmdLC code trigger the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
[Bug target/27531] New: [4.2 regression] sparc: undefined reference to .LL226 with -O2
I get a undefined reference to `.LL226' error when compiling RCS with -O2 on sparc using gcc 4.2. This problem goes away when I use -O2. The assembler output shows that .LL226 is referenced but not defined anywhere. I'll attach the .i file and the .s file with -O1 (works) and -O2 (fails). Unfortunately I don't have a smaller test case. Automatic build of rcs_5.7-18 on bilbao by sbuild/sparc 85 ... gcc -O2 -g rlog.o rcslex.o rcsmap.o rcssyn.o rcsrev.o rcsutil.o maketime.o partime.o rcstime.o rcsf nms.o rcskeep.o rcskeys.o version.o -o rlog rlog.o: In function `getrevpairs'://build/tbm/rcs-5.7/src/rlog.c:1214: undefined reference to `.LL226' ://build/tbm/rcs-5.7/src/rlog.c:1214: undefined reference to `.LL226' ://build/tbm/rcs-5.7/src/rlog.c:1217: undefined reference to `.LL226' ://build/tbm/rcs-5.7/src/rlog.c:1218: undefined reference to `.LL226' ://build/tbm/rcs-5.7/src/rlog.c:1218: undefined reference to `.LL226' collect2: ld returned 1 exit status make[2]: *** [rlog] Error 1 -- Summary: [4.2 regression] sparc: undefined reference to .LL226 with -O2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: sparc-linux-gnu GCC host triplet: sparc-linux-gnu GCC target triplet: sparc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #1 from tbm at cyrius dot com 2006-05-10 13:51 --- Created an attachment (id=11431) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11431action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #2 from tbm at cyrius dot com 2006-05-10 13:52 --- Created an attachment (id=11432) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11432action=view) assembler with -O1 (works) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/25514] [m68k] internal consistency failure
--- Comment #7 from patchapp at dberlin dot org 2006-05-10 13:52 --- Subject: Bug number PR25514 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00958.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #3 from tbm at cyrius dot com 2006-05-10 13:52 --- Created an attachment (id=11433) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11433action=view) assembler with -O2 (fails) - .LL226 is not defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug fortran/23375] show location for runtime errors
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2006-05-10 13:54 ---
(In reply to comment #1)
Confirmed. Though sometimes I wonder if this is an over use of printf style
debugging.
rantWell, I have a fortran program. It ran fine for the first 10 and a half
hours. Then it died with the error: Fortran runtime error: Array reference
out of bounds Any hints on debugging it?/rant
The front end seems to support filenames and line numbers. bad_array.f90:
program bad_array
integer,dimension(8) :: array
array(9) = 123
array(10) = 321
end program bad_array
gfortran -fdump-tree-all -fbounds-check bad_array.f90
bad_array.f90.t02.original:
MAIN__ ()
{
int4 array[8];
_gfortran_set_std (86, 127, 0);
_gfortran_runtime_error (Array reference out of bounds, bad_array.f90,
1);
array[8] = 123;
_gfortran_runtime_error (Array reference out of bounds, bad_array.f90,
3);
array[9] = 321;
}
So in GCC 4.1.0, the only problem seems to be that _gfortran_runtime_error is
not printing the filename and the line number and the line number seems to be
the line number of the previous statement, not the one that errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug tree-optimization/27003] [4.0 Regression] ivcanon bug
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-10 13:59:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug rtl-optimization/27477] The H8 port doesn't build
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-10 14:21 ---
Reduced down to:
extern void bar (int);
int
foo (int a, int b)
{
int c = a == b;
if (c)
bar (c);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27477
[Bug tree-optimization/27532] New: CCP produces non-gimple statements
Reduced testcase from gcc.dg/builtin-object-size-1.c:
void abort(void);
int main (void)
{
void *b = Labcd;
if (__builtin_object_size (b + 2, 0) != sizeof (Labcd) - 2)
abort ();
return 0;
}
now, CCP propagates the constant Labcd[0] to the addition stmt:
b_1 = a[0];
D.1526_2 = a[0] + 2B;
which does not simplify (it can't, array element size is four). Now,
the objsz pass does not deal with this (non-gimple?) form and punts:
Computing maximum object size for D.1526_2:
D.1526_2: maximum object size 4294967293
test ()
{
unsigned int D.1527;
void * D.1526;
bb 2:
D.1526_2 = a[0] + 2B;
D.1527_3 = 0fffd;
if (D.1527_3 != 14) goto L0; else goto L1;
L0:;
abort ();
L1:;
return;
}
With fixing PR27529, this triggers for all the regular builtin-object-size-?.c
tests.
--
Summary: CCP produces non-gimple statements
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27532
[Bug fortran/27487] [4.1/4.2 regression] ICE after invalid variable declaration
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37 --- This is a duplicate of PR24549 (it's fixed by the same one-line patch). *** This bug has been marked as a duplicate of 24549 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27487
[Bug fortran/24549] ICE with invalid pseudo-declaration statement
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37 --- *** Bug 27487 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24549
[Bug tree-optimization/27532] CCP produces non-gimple statements
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-10 14:37 --- CCP produces this tree since forever. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.3 4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27532
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #5 from malitzke at metronets dot com 2006-05-10 14:43 --- To A Pinski While I am _not_ a C lawyer, the following seems pertinent: 1 __FUNCTION__ is _not_ a predefined macro. However __func__ a predefined identifier and I will take this up with the kernel people. However, even changing__FUNCTION__ to __func__ still produces an error. Let the language lawyer sort this out. 2 Taking __FUNCTION__ entirely out of the original Macro Definition and using all of the kernel paraphernalia produces valid code. Out of that context I can not get even __FILE__ to work properly; only __line__ 3 Your Hi misses the point because it is certainly not a predefined macro and not even a predefined identifier. Therefore the comparison seems invalid to me. I am reopening this because I believe that the raised by __func__ should be addressed. Also it is not the first time that the kernel people found ways to get GCC closer to the standards. -- malitzke at metronets dot com changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug c++/27533] New: wrong result after reinterpret_cast from float* to int*
The code
inline int almost_equal(float a, float b, int maxUlps = 16) {
int intDiff = *(reinterpret_castint*(a)) -
*(reinterpret_castint*(b));
printf(intDiff %d\n,intDiff);
return intDiff;
}
gives different results when compiled with and without -O2
(yes, floats are involved, but it has nothing to do with rounding)
--
Summary: wrong result after reinterpret_cast from float* to int*
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ulrich dot lauther at siemens 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=27533
[Bug tree-optimization/27532] __builtin_object_size does not handle a + b.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-10 14:48 ---
Looks more like a typo in tree-object-size.c:plus_expr_object_size
Index: tree-object-size.c
===
*** tree-object-size.c (revision 113669)
--- tree-object-size.c (working copy)
*** plus_expr_object_size (struct object_siz
*** 595,601
{
unsigned HOST_WIDE_INT off = tree_low_cst (op1, 1);
! bytes = compute_builtin_object_size (value, object_size_type);
if (off offset_limit)
bytes = unknown[object_size_type];
else if (off bytes)
--- 595,601
{
unsigned HOST_WIDE_INT off = tree_low_cst (op1, 1);
! bytes = compute_builtin_object_size (op0, object_size_type);
if (off offset_limit)
bytes = unknown[object_size_type];
else if (off bytes)
mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|dnovillo at redhat dot com |
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-05-10 14:48:34
date||
Summary|CCP produces non-gimple |__builtin_object_size does
|statements |not handle a + b.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27532
[Bug fortran/24549] ICE with invalid pseudo-declaration statement
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:51 --- Subject: Bug 24549 Author: fxcoudert Date: Wed May 10 14:51:26 2006 New Revision: 113671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113671 Log: PR fortran/24549 * parse.c (reject_statement): Clear gfc_new_block. * gfortran.dg/error_recovery_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/error_recovery_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24549
[Bug c++/27533] wrong result after reinterpret_cast from float* to int*
--- Comment #1 from pluto at agmk dot net 2006-05-10 14:51 --- you're violating the aliasing rules, so use -fno-strict-aliasing option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
[Bug c++/27533] wrong result after reinterpret_cast from float* to int*
--- Comment #2 from ulrich dot lauther at siemens dot com 2006-05-10 14:53 --- Created an attachment (id=11434) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11434action=view) Complete tiny example exposing the problem I submit this version that includes stdio.h for readability, expanded version will follow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
[Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-10 14:56 --- I have a patch that needs PR27529 fixed first, that needs PR27532 fixed first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #6 from dje at gcc dot gnu dot org 2006-05-10 14:56 --- The section anchors feature does not like __FUNCTION__ or __func__ as an inlined asm argument. Also, some rs6000 work is not very informative or useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug c++/27533] wrong result after reinterpret_cast from float* to int*
--- Comment #3 from ulrich dot lauther at siemens dot com 2006-05-10 14:55 --- Created an attachment (id=11435) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11435action=view) same as before, but stdio.h expanded -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
[Bug fortran/27229] char_transpose_1.f90 fails with ICE in gfc_conv_array_transpose
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10 14:58 --- (In reply to comment #2) Very odd; I do nightly builds of mainline on two different systems. On one of them this failure stopped on 20060430 and on the other it stopped on 20060503, but failed on 20060502. Can this now be closed? Paul Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27229
[Bug fortran/20460] Nasty extensions that should always warn
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:58 --- Subject: Bug 20460 Author: fxcoudert Date: Wed May 10 14:58:48 2006 New Revision: 113672 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113672 Log: PR fortran/20460 * resolve.c (gfc_resolve_index): Make REAL array indices a GFC_STD_LEGACY feature. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460
[Bug c++/27533] wrong result after reinterpret_cast from float* to int*
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-10 14:59 --- As Pawel already pointed out: Your code is brokan as you are violating the aliasing rules. Please read about this in the non-bug section of http://gcc.gnu.org/bugs.html : Casting does not work as expected when optimization is turned on. *** This bug has been marked as a duplicate of 21920 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
[Bug c/21920] alias violating
--- Comment #96 from reichelt at gcc dot gnu dot org 2006-05-10 14:59 --- *** Bug 27533 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||ulrich dot lauther at ||siemens dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug rtl-optimization/27477] The H8 port doesn't build
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-10 15:00 ---
The combiner seems to be doing something strange:
(insn 13 12 16 2 (set (reg:HI 21)
(eq:HI (cc0)
(const_int 0 [0x0]))) 237 {*bstzhireg} (nil)
(nil))
(insn 16 13 17 2 (set (cc0)
(reg:HI 21)) 114 {tsthi} (insn_list:REG_DEP_TRUE 13 (nil))
(nil))
(jump_insn 17 16 19 2 (set (pc)
(if_then_else (eq (cc0)
(const_int 0 [0x0]))
(label_ref:SI 39)
(pc))) 181 {branch_true} (nil)
(expr_list:REG_BR_PROB (const_int 5347 [0x14e3])
(nil)))
is transformed to
(insn 16 13 17 2 (set (pc)
(if_then_else (ne (cc0)
(const_int 0 [0x0]))
(label_ref:SI 39)
(pc))) 181 {branch_true} (nil)
(nil))
(jump_insn 17 16 19 2 (set (reg:HI 21)
(eq:HI (cc0)
(const_int 0 [0x0]))) 237 {*bstzhireg} (nil)
(expr_list:REG_BR_PROB (const_int 5347 [0x14e3])
(nil)))
Note that the combiner puts a branch instruction one insn
before the last insn in the basic block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27477
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-10 15:06 ---
(In reply to comment #5)
To A Pinski
While I am _not_ a C lawyer, the following seems pertinent:
Why do you think this is related to the C standard?
1 __FUNCTION__ is _not_ a predefined macro. However __func__ a predefined
identifier and I will take this up with the kernel people. However, even
changing__FUNCTION__ to __func__ still produces an error. Let the language
lawyer sort this out.
So what?
2 Taking __FUNCTION__ entirely out of the original Macro Definition and using
all of the kernel paraphernalia produces valid code. Out of that context I can
not get even __FILE__ to work properly; only __line__
3 Your Hi misses the point because it is certainly not a predefined macro
and not even a predefined identifier. Therefore the comparison seems invalid
to
me.
HUH? Look at how __FILE__ gets subsituted.
I am reopening this because I believe that the raised by __func__ should be
addressed. Also it is not the first time that the kernel people found ways to
get GCC closer to the standards.
__func__ is a static variable and that is how the C standard defines it. It
will be put into the section anchor.
You will also have issues with:
static int t;
void f(void)
{
asm ( : : I(t));
}
=
But all of that is undefined as explained by how the documentation is defined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|dje at gcc dot gnu dot org |
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug tree-optimization/27532] __builtin_object_size does not handle a + b.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-10 15:10 --- Just to explain why a[0] + 2B is valid gimple: a[0] is a gimple invariant and likewise for 2b. Therefor the two sides of the Plus expression are going to valid for it. Therefor valid gimple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27532
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||link-failure Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug c++/27533] wrong result after reinterpret_cast from float* to int*
--- Comment #5 from pluto at agmk dot net 2006-05-10 15:26 ---
(In reply to comment #0)
The code
inline int almost_equal(float a, float b, int maxUlps = 16) {
int intDiff = *(reinterpret_castint*(a)) -
*(reinterpret_castint*(b));
if you really need such casting and still use strict-aliasing
you should rewrite almost_equal().
/*inline*/ int almost_equal( float a, float b )
{
int ia;
memcpy( ia, a, sizeof(int) );
int ib;
memcpy( ib, b, sizeof(int) );
return ( ia - ib );
}
compiler will optimize it nicely ;)
almost_equal(float, float):
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 ec 10sub$0x10,%esp
6: 8b 45 08mov0x8(%ebp),%eax===
9: 2b 45 0csub0xc(%ebp),%eax===
c: c9 leave
d: c3 ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
[Bug c/27534] New: Warning on passing pointer to va_list
Attempting to pass a pointer to a va_list variable to a function expecting such
a pointer causes a warning about passing a pointer of incompatible type.
[EMAIL PROTECTED] ~/work/ffdev $ gcc -v -save-temps -ansi -pedantic -Wall -W -O
-c t.c
Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/specs
Configured with: /var/tmp/portage/gcc-3.4.5-r1/work/gcc-3.4.5/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.5
--includedir=/usr/lib/gcc/powerpc-unknown-linux
-gnu/3.4.5/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/man
--infodir=/usr/share/gcc-data/powerpc-unk
nown-linux-gnu/3.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/g++-v3
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --disable-a
ltivec --enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --disable-libunwind-exceptions
--disable-multilib --enable-languages=c,c++,java,f77 -
-enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu
Thread model: posix
gcc version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/3.4.5/cc1 -E -quiet -v -D__unix__
-D__gnu_linux__ -D__linux__ -Asystem=linux -Asystem=unix -Asystem=posix t.c
-ansi -pedantic -Wall -W -O -o t.
i
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/../../../../powerpc-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include
/usr/include
End of search list.
/usr/libexec/gcc/powerpc-unknown-linux-gnu/3.4.5/cc1 -fpreprocessed t.i -quiet
-dumpbase t.c -ansi -auxbase t -O -pedantic -Wall -W -ansi -version -o t.s
GNU C version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)
(powerpc-unknown-linux-gnu)
compiled by GNU C version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0,
pie-8.7.8).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64407
t.c:3: warning: unused parameter 'arg'
t.c: In function `bar':
t.c:9: warning: passing arg 1 of `foo' from incompatible pointer type
/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/../../../../powerpc-unknown-linux-gnu/bin/as
-mppc -many -V -Qy -o t.o t.s
GNU assembler version 2.16.1 (powerpc-unknown-linux-gnu) using BFD version
2.16.1
[EMAIL PROTECTED] ~/work/ffdev $ cat t.i
# 1 t.c
# 1 built-in
# 1 command line
# 1 t.c
# 1 /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/stdarg.h 1 3 4
# 43 /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/stdarg.h 3 4
typedef __builtin_va_list __gnuc_va_list;
# 105 /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/stdarg.h 3 4
typedef __gnuc_va_list va_list;
# 2 t.c 2
void foo(va_list *arg)
{
}
void bar(va_list arg)
{
foo(arg);
}
[EMAIL PROTECTED] ~/work/ffdev $ gcc -v
Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/specs
Configured with: /var/tmp/portage/gcc-3.4.5-r1/work/gcc-3.4.5/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.5
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/g++-v3
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--disable-altivec --enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --disable-libunwind-exceptions
--disable-multilib --enable-languages=c,c++,java,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)
[EMAIL PROTECTED] ~/work/ffdev $
The warning about the unused variable is expected. The real code (much more
complex) from which this was cut down used the variable and still generated the
warning about incompatible pointer type.
The standard says that vl_list should be an object type, and others on the news
group comp.lang.c agree that my code is valid. See thread
http://groups.google.com/group/comp.lang.c/browse_frm/thread/e64d6ffd19ab7ae3/faf78d3f5fb3acfe?lnk=stq=group%3Acomp.lang.c+insubject%3Ava_listrnum=1hl=en#faf78d3f5fb3acfe
--
Summary: Warning on passing pointer to va_list
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at flash-gordon dot me dot uk
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
[Bug c/27534] Warning on passing pointer to va_list
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:46 --- It is an object type. An array is an object type. *** This bug has been marked as a duplicate of 14557 *** -- 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=27534
[Bug target/14557] va_list is automatically taken address-of when passed as argument
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-05-10 15:46 --- *** Bug 27534 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc at flash-gordon dot me ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14557
[Bug middle-end/27529] Does not fold (char *)(size_t)char_ptr or (size_t)(char *)size_t_var
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:47 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-10 15:47:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27529
[Bug libstdc++/27530] Possible memory leak in std::vectorint::reserve() or std::vectorint::clear()
--- Comment #4 from ksharenkov at ya dot ru 2006-05-10 15:58 --- I have tried to create simple test case (about 200 rows) where I tried to reproduce key code fragments. In simple test case leak not reproduced. But I have easy reproduced it with very small application based on main project code. Code like CMessage* m1 = theMessageFactory.createInstance( ) CMessage* m2 = m1-clone(); delete m2; delete m1; I am staring think that problem in templates instantiation. Also I already had problem with proper template instantiation in my Project. For some copy operations with vector of objects, vptr were set to 0 (caused SEG FAULT). I have not reported on It. I have resolved it by equal code but without copy operation. (2 weeks spent to detect cause, I though I am was wrong somewhere #61516; ) I have a test executable with full debug info (27M) (necessary libs statically linked) Depends only ldd ./leaktest linux-gate.so.1 = (0x00f56000) libstdc++.so.6 = /usr/local/lib/libstdc++.so.6 (0x00111000) libm.so.6 = /lib/tls/libm.so.6 (0x0045c000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x005a5000) libc.so.6 = /lib/tls/libc.so.6 (0x00339000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x0032) Will it be usefull for you? To analyze generated code. -- ksharenkov at ya dot ru changed: What|Removed |Added CC||ksharenkov at ya dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
[Bug fortran/27229] char_transpose_1.f90 fails with ICE in gfc_conv_array_transpose
--- Comment #4 from janis at gcc dot gnu dot org 2006-05-10 16:03 --- The test passes on both of my nightly builds now, so I'm closing this. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27229
[Bug c/27489] [4.1/4.2 regression] ICE on broken switch condition
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-10 16:49 --- Assigning to Volker as he posted a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00337.html Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27489
[Bug middle-end/27488] [4.1/4.2 regression] ICE in tree_expr_nonnegative_p
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:52 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27488
[Bug c++/27384] [4.0/4.1/4.2 regression] ICE with invalid array size
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:55 --- Testing a patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27384
[Bug target/26415] [4.2 regression] m68k-linux bootstrap error during stage2
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:00 --- Could you submit a preprocessed testcase? Many of us do not have m68k hardware that can be used for bootstrap. Thanks, -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26415
[Bug target/24949] FAIL: gcc.c-torture/compile/20000403-2.c -O0
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:35 --- Subject: Bug 24949 Author: kazu Date: Wed May 10 17:35:24 2006 New Revision: 113675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113675 Log: PR target/24949 * config/m68k/m68k.md (ashrdi_const32, ashrdi_const32_mem, ashrdi_const, ashrdi3): Use a scratch register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24949
[Bug target/24949] FAIL: gcc.c-torture/compile/20000403-2.c -O0
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-10 17:35 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24949
[Bug java/12257] Inner classes with same name causes crash.
--- Comment #3 from aph at gcc dot gnu dot org 2006-05-10 17:41 --- Xref: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191211 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12257
[Bug bootstrap/18058] [4.2 Regression] Bootstrap fails with BOOTCFLAGS=-O0
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-05-10 17:48 --- Since Honza's patch to emit static and inline functions at -O0, this now fails with BOOTCFLAGS as -O0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|blocker Summary|[4.2 Regression] Sun CC |[4.2 Regression] Bootstrap |cannot bootstrap GCC (static|fails with BOOTCFLAGS=-O0 |inline) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
[Bug fortran/27470] [4.1/4.2 regression] wrong memory allocator for derived types
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-10 18:27 --- Subject: Bug 27470 Author: tkoenig Date: Wed May 10 18:26:51 2006 New Revision: 113680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113680 Log: 2005-05-10 Thomas Koenig [EMAIL PROTECTED] PR fortran/27470 * trans-array.c(gfc_array_allocate): If ref-next exists that is if there is a statement like ALLOCATE(foo%bar(2)), F95 rules require that bar should be a pointer. 2005-05-10 Thomas Koenig [EMAIL PROTECTED] PR fortran/27470 * gfortran.dg/multiple_allocation_2.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/multiple_allocation_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27470
[Bug c/27535] New: ICE, Regression from gcc-4.1.0
/*
ICE using gcc-4.2-20060506 on x86_64-unknown-linux-gnu
Regression from gcc-4.1.0
Source cut down from gmp-4.2.1/tests/refmpf.c
% gcc-4.2-20060506 -O3 -c foo.c
foo.c: In function âfooâ:
foo.c:27: 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.
%
% gcc-4.2-20060506 -O2 -c foo.c
%
% gcc-4.2-20060506 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/kate/test/gcc-4.2-20060506/configure
--enable-languages=c --prefix=/home/kate/test/bin/x86_64-Linux
Thread model: posix
gcc version 4.2.0 20060506 (experimental)
%
%
% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.1.0/src/gcc-4.1.0/configure
--enable-languages=c,c++
--prefix=/usr/local/gcc-4.1.0/x86_64-Linux-g++
Thread model: posix
gcc version 4.1.0
%
% gcc -O3 -c foo.c
%
*/
#include stdlib.h
typedef struct
{
int a;
} strt;
typedef strt *ptr;
void
foo (ptr w, int u, int v)
{
int b;
if (u == 0)
{
b = v 0;
goto done;
}
if (v == 0)
{
b = u 0;
}
done:
w-a = b == 0 ? 1 : -1;
}
--
Summary: ICE, Regression from gcc-4.1.0
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kminola at eng dot umd dot edu
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=27535
[Bug rtl-optimization/27535] ICE with -O2 -fsee
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 19:06 --- Oh, this is no longer a regression as -fsee is not enabled by default in newer versions of 4.2 (a day after it was enabled by default for -O3, it was turned off to fix some regressions at -O3). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Keywords||ice-on-valid-code Summary|ICE, Regression from gcc- |ICE with -O2 -fsee |4.1.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27535
[Bug tree-optimization/27532] __builtin_object_size does not handle a + b.
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 19:41 --- Subject: Bug 27532 Author: rguenth Date: Wed May 10 19:41:46 2006 New Revision: 113682 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113682 Log: 2006-05-10 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27532 * tree-object-size.c (plus_expr_object_size): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-object-size.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27532
[Bug tree-optimization/27532] __builtin_object_size does not handle a + b.
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-10 19:42 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27532
[Bug ada/27536] New: -fsection-anchors breaks Ada
$ /tmp/cvs/gcc-test-r113398/Build/./gcc/xgcc -B/tmp/cvs/gcc-test-r113398/Build/./gcc/ -B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/bin/ -B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/lib/ -isystem /tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/include -isystem /tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/sys-include -c -g -O2 -fPIC -specs=ldblspecs -mno-minimal-toc -W -Wall -gnatpg g-os_lib.adb -o g-os_lib.o -v Reading specs from /tmp/cvs/gcc-test-r113398/Build/./gcc/specs Reading specs from /tmp/cvs/gcc-test-r113398/Build/./gcc/ldblspecs Target: powerpc64-suse-linux Configured with: ../configure --prefix=/tmp/cvs/gcc-test-r113398/Build/root --host=powerpc64-suse-linux --enable-shared --enable-threads --enable-__cxa_atexit --with-system-zlib --with-cpu=default32 --enable-languages=ada --disable-bootstrap Thread model: posix gcc version 4.2.0 20060430 (experimental) /tmp/cvs/gcc-test-r113398/Build/./gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O2 -W -Wall -fPIC -g -mno-minimal-toc -gnatpg -gnatO g-os_lib.o g-os_lib.adb -o /tmp/ccGycApt.s +===GNAT BUG DETECTED==+ | 4.2.0 20060430 (experimental) (powerpc64-suse-linux-gnu) GCC error: | | in change_address_1, at emit-rtl.c:1784 | | Error detected at g-os_lib.adb:2603:1| Regression hunting is pointing its finger at this change: * config/rs6000/rs6000.c (rs6000_override_options): Enable TARGET_NO_FP_IN_TOC for section anchors. (optimization_options): Enable section anchors for all non-Objective languages. In fact, -fno-section-anchors lets it compile again. -- Summary: -fsection-anchors breaks Ada Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: powerpc-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug c++/27537] New: XMM alignment fault when compiling for i386 with -Os. Needs ABI specification.
The g++ compiler for i386 target assumes that the stack is aligned by 16 when
storing xmm registers to the stack. However, the stack is not aligned when
compiling with option -Os (or with the Intel compiler). A misaligned memory
operand to an XMM instruction causes a general protection exception. An example
to reproduce the error is included below.
Suggested remedies:
Either (1): Keep the stack pointer aligned by 16, even when compiling with
option -Os and make this alignment an official requirement in the ABI (the ABI
for IA32 Gnu is shamefully poorly documented!). This alignment is already a
requirement in the Mac OS X IA32 ABI
(http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/index.html#//apple_ref/doc/uid/TP40002521).
It is preferred to have the same ABI for IA32/i386 on MacOS and Linux, BSD,
etc. since they all use the Gnu compiler.
Or (2): Make no assumptions about alignment of the stack. Align the stack
pointer with an AND-instruction whenever an alignment higher than 4 is needed.
(This is in accordance with the Windows IA32 ABI).
Steps to reproduce:
-- begin file e1.cpp -
#include stdio.h
#include emmintrin.h
// Example showing stack alignment error
// compile with g++ v. 4.1.0:
// g++ -m32 -Os -msse2 e1.cpp
// ./a.out
char * e1() { // This function assumes that the stack is aligned by 16
// This puts 0 in an XMM register and stores it on the stack:
volatile __m128 dummy = _mm_set_ps1(0.f);
return OK;
}
int main() { // This function calls e1() without proper alignment
printf(%s %s \n, e1(), e1());
return 0;
}
-- end file e1.cpp -
compile this file with:
g++ -m32 -Os -msse2 e1.cpp
./a.out
--
Expected output:
OK OK
Actual output:
Segmentation fault
-
Cause of error:
The instruction that generates the error is:
movaps %xmm0,-16(%ebp)
This instruction requires that the memory operand is aligned by 16, but there
is only a 25% chance that %ebp is divisible by 16 when compiling with option
-Os. The program works correctly when compiled with any other optimization
option. Also works correctly when compiling for x64 platform.
I have submitted a bug report about the same issue to the Intel compiler
developers. Issue # 369990 at premier.intel.com
Whether you choose remedy (1) or (2) above should preferably be coordinated
with the Intel compiler developers and with Apple, because this is an ABI issue
and the solution must be standardized.
[EMAIL PROTECTED] t]# g++ -v -save-temps -m32 -Os -msse2 e1.cpp
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.0/cc1plus -E -quiet -v -D_GNU_SOURCE
e1.cpp -m32 -msse2 -mtune=generic -Os -fpch-preprocess -o e1.ii
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../include/c++/4.1.0
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../include/c++/4.1.0/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../include/c++/4.1.0/backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/include
/usr/include
End of search list.
/usr/libexec/gcc/x86_64-redhat-linux/4.1.0/cc1plus -fpreprocessed e1.ii -quiet
-dumpbase e1.cpp -m32 -msse2 -mtune=generic -auxbase e1 -Os -version -o e1.s
GNU C++ version 4.1.0 20060304 (Red Hat 4.1.0-3) (x86_64-redhat-linux)
compiled by GNU C version 4.1.0 20060304 (Red Hat 4.1.0-3).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=63766
Compiler executable checksum: 145c15e175e7b5491c5723c9bdb452f1
as -V -Qy --32 -o e1.o e1.s
GNU assembler version 2.16.91.0.6 (x86_64-redhat-linux) using BFD version
2.16.91.0.6 20060212
/usr/libexec/gcc/x86_64-redhat-linux/4.1.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../lib/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/32/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.0/32
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.0/32
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../lib -L/lib/../lib
-L/usr/lib/../lib e1.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
[Bug target/27538] New: execute/20030128-1.c FAILs
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O1 FAIL: gcc.c-torture/execute/20030128-1.c execution, -O2 FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/20030128-1.c execution, -Os -- Summary: execute/20030128-1.c FAILs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at gcc dot gnu dot org GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27538
[Bug target/27539] New: gcc.c-torture/execute/941014-2.c FAILs
FAIL: gcc.c-torture/execute/941014-2.c execution, -O1 FAIL: gcc.c-torture/execute/941014-2.c execution, -O2 FAIL: gcc.c-torture/execute/941014-2.c execution, -Os -- Summary: gcc.c-torture/execute/941014-2.c FAILs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazu at gcc dot gnu dot org GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27539
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #10 from flash at pobox dot com 2006-05-10 20:08 --- PalmSource bug #126750. -- flash at pobox dot com changed: What|Removed |Added CC||flash at pobox dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #8 from malitzke at metronets dot com 2006-05-10 20:17 --- Well Fellas: Either have the Steering Committee revise the Invitation to participate in testing; quoted iselectively below. Or,have a member from the Steering Committe ask me to refrain from further participation. I, for one, am no longer willing to be at the receiving end of snide comments from people who can not admit that, volunteering or not, are talking through their hats. I am over 70 years of age and have come to my expertise (which is not in compilers) the hard way. I started with plugboards and worked my way up to real time assembly systems programming (telephone Central Office switches and dispatching systems). The proof of any programming effort is for the hardware to generate the right output to control other hardware or to be comprehensible by human beings. Now to the specifics: This page describes regular efforts to test GCC thoroughly, plus ideas for additional testing by volunteers who have machine cycles to spare. You might not believe it, but I have a router-firewall, a MAC (dual 800 Mhz G4's), a Pentium 3 server (four 550 Mhz Pentium 3 with 2Gbyte error correcting memory an 130 Giga byes of SCSI) assorted other machines all running with software entirely compiled with gcc-4.1 and gcc-4.2. I only report to gcc.gnu.org what I consider important problems. In this specific case I just eliminated the __FUNCTION__ part from bug.h (asm-powerpc) and I am writing this with kernel-2.6.17-rc3 as compiled by the current gcc-4.2 on the MAC. Perform regular builds and testing of current GCC sources that are not already being reported regularly. Compiling everything but Ada and running the full test suite now takes 8.5 hours on a ~800 Mhz pentium 3. There is realy no publicly available Ada source. I, personally do not care for Java, but some source packages require it and sun is apparently no coming out with new releases for the powerpc series (competition for server sales) I check the test suite output to see if that particular gcc is to be my current production compiler for either pentium3 or powerpc. If the operating system kernel you use is normally compiled with GCC, try building it with the current sources; such as a release branch, use the newly built kernel for running further GCC tests. I am a user of compilers (not only gcc) and not a compiler builder. The four or five problems I reported (and caused changes in gcc) sofar were not evidenced by the test suite. Build and test applications that are important to you; investigate and report any problems you find. Build and test packages that are normally available on your platform and for which you have access to source.a I have about 40 Gigabyte of source code (no games, no IRC, no themes or their engines, no music or downloading software, as little Java as possible, and no Pascal). This is really software for workstation use. Regarding __func__ C99 declares it a predefined identifier and Like keywords, predefined identifiers must no be defined by programmers. I am not asking that it becomes part of GCC. however it should made clear that it and certainly __FUNCTION__ are no longer supported. Regarding __LINE__, __FILE__, __DATE__, etc are required as per Standard C. Again, the GCC community can state that it is no honoring that particular requiremnt. However, the GCC comunity can not unilaterally abrogate that requirement. The trigraphs come to mind. These are probably matters for the Steering Committee. -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os. Needs ABI specification.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 20:39 --- First so what darwin aligns the stack by default to 16bytes (that is demanded by their ABI since their ABI is newer than GNU/Linux's). GNU/Linux follows the SYSV x86 ABI which is documented, maybe you cannot find it but it does exist. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-10 20:41 --- This has nothing to do with the C standard or even standard code. This is inline-asm constraint which is failing and the inline-asm in the code is wrong. This is a bug in the code so report it to Linux instead of here. -- 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=27528
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os. Needs ABI specification.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-10 20:44 --- The SYSV x86 ABI says the stack is aligned 4 byte aligned. Remember the SYSV x86 ABI was done before MMX or SSE was around or even thought about back in the 486 days (and maybe even before then). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-10 20:49 --- This is confirmed, this is an interaction between stack slots and -mpreferred-stack-boundary= which is what -Os sets. This is not a regression. Maybe the real question is why are you using -Os for code with SSE in it? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-05-10 20:49:57 date|| Summary|XMM alignment fault when|XMM alignment fault when |compiling for i386 with -Os.|compiling for i386 with -Os |Needs ABI specification.| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug ada/27536] [4.2 Regression] -fsection-anchors breaks Ada
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|-fsection-anchors breaks Ada|[4.2 Regression] -fsection- ||anchors breaks Ada Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug target/27540] New: libgomp fails to configure on IRIX 5.3
Current mainline fails to bootstrap on IRIX 5.3: configure: error: Pthreads are required to build libgomp make[1]: *** [configure-target-libgomp] Error 1 Environment: System: IRIX lyra 5.3 11091812 IP22 mips host: mips-sgi-irix5.3 build: mips-sgi-irix5.3 target: mips-sgi-irix5.3 configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --with-gnu-as --with-as=/vol/gcc/lib/gas-2.15 --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr --enable-languages=c,c++,fortran,objc,ada --disable-libmudflap How-To-Repeat: Try to bootstrap on IRIX 5.3. --- Comment #1 from ro at techfak dot uni-bielefeld dot de 2006-05-10 21:22 --- Fix: Since IRIX 5 doesn't have libpthread (and never will), libgomp should only be enable for *-*-irix6* in toplevel configure.in. I'll propose a patch shortly. Strictly speaking, libpthread was only introduced in patches to IRIX 6.2, but older IRIX 6.[012] systems are probably completely gone by now and can thus be ignored. -- Summary: libgomp fails to configure on IRIX 5.3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: mips-sgi-irix5.3 GCC host triplet: mips-sgi-irix5.3 GCC target triplet: mips-sgi-irix5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27540
[Bug libgomp/26308] [4.2 Regression] libgomp bootstrap failure on Tru64 UNIX V4.0F
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-05-10 21:28 --- Subject: Re: [4.2 Regression] libgomp bootstrap failure on Tru64 UNIX V4.0F pinskia at gcc dot gnu dot org writes: PR 26161 might had fixed this. No, the problem persists as of 20060503. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26308
[Bug c++/27315] [4.0/4.1/4.2 regression] ICE with ill-placed expression
--- Comment #6 from patchapp at dberlin dot org 2006-05-10 21:31 --- Subject: Bug number PR c++/27315 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-05/msg00361.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27315
[Bug ada/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #1 from dje at gcc dot gnu dot org 2006-05-10 21:33 --- I can disable section anchors for Ada, similar to Objective C and Objective C++, but this failure likely means that there is a bug in the Trees generated by GNU Ada. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug fortran/27320] ICE with -fdump-parse-tree after error
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-10 21:36 --- Below is a patch for this ICE. I suspect that there a lots more ICEs lurking in dump-parse-tree.c, which looks like it's not really written to be fed with incomplete structures (as might happen during error recovery). I'll try to audit the rest of the file for such problems. Index: dump-parse-tree.c === --- dump-parse-tree.c (revision 113671) +++ dump-parse-tree.c (working copy) @@ -1060,7 +1060,13 @@ break; case EXEC_CALL: - gfc_status (CALL %s , c-resolved_sym-name); + if (c-resolved_sym) + gfc_status (CALL %s , c-resolved_sym-name); + else if (c-symtree) + gfc_status (CALL %s , c-symtree-name); + else + gfc_status (CALL ?? ); + gfc_show_actual_arglist (c-ext.actual); break; -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2006-04-26 16:41:12 |2006-05-10 21:36:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27320
[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-05-10 21:43 --- Now, this is fixed at the moment (but still invalid code), but I have a fix that will break it again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25512
[Bug fortran/24549] [4.1 only] ICE with invalid pseudo-declaration statement
--- Comment #7 from anlauf at gmx dot de 2006-05-10 21:53 --- (In reply to comment #5) *** Bug 27487 has been marked as a duplicate of this bug. *** Well, first of all I have to admit that I am only a Fortran user. But PR 27487 is only a duplicate because Tobias changed the subject of my original entry, which was a request for the implementation of F2003 IMPORT. FX: Fixing gfortran's error recovery is not the answer to this PR, but to the other one. For this reason it seems more reasonable to change the status of PR 27487 back and move your patch there. Next, the subject of this PR should be reset to my original one, as IMPORT is required for F2003 support, see PR 20585. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24549
[Bug other/27541] New: Support Cluster OpenMP (distributed-memory OpenMP)
Currently, GCC only supports OpenMP on shared-memory systems. It would be nice if it could be extended to support OpenMP via the ethernet, infiniband etc. (distributed-memory systems). There exists (at least) one implementation of distributed-memory OpenMP: The Intel Compilers 9.1's Cluster OpenMP. Intel's Whitepaper: http://www.intel.com/cd/software/products/asmo-na/eng/compilers/285865.htm Intel's Cluster OpenMP User manual: http://softwareforums.intel.com/attachments/ids/11/3796/1/UsersGuide.pdf Intel's Extentions to OpenMP: the sharable directive. The sharable directive identifies variables that are referenced by more than one thread. These variables are the ones that are managed by the DSM system. (Some are automatically marked shareable, see whitepaper, p. 5) The whitepaper also describes some implemenation details to deal with global memory. Running such a Intel-Cluster-OpenMP program: ./a.out, which first reads the config file then starts the program on the remote computer via rsh or ssh. The data transfer via TCP or Direct Access Provider Library (DAPL.sf.net). * * * Besides OpenMP there exists another multi-processor extention which works at compile time: Cray's co-arrays, scheduled (in modified form) to be included into the Fortran 2008 standard (see http://www.co-array.org/). Having a look at the co-array specs shouldn't harm, when implementing this. Maybe some different or further things should be considered. -- Summary: Support Cluster OpenMP (distributed-memory OpenMP) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27541
[Bug other/27541] Support Cluster OpenMP (distributed-memory OpenMP)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 22:09 --- Is there really a standard for this or just an extension of OpenMP? Though this is useful a little bit for the Cell where you don't really have a distrubuted machine but the memory will be distributed though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-10 22:09:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27541
[Bug other/27156] SIGSEGV in operator delete() / wrong-code?
--- Comment #12 from pluto at agmk dot net 2006-05-10 22:36 ---
following reduced testcase works with libstdc++ and segv with stlport.
#include list
#include vector
struct A { };
int main()
{
std::list A* l;
std::vector A* v( l.end(), l.end() );
return 0;
}
g++ testDrv.cpp -o testDrv -pthread -O2 -fstrict-aliasing -Wall
./testDrv
g++ testDrv.cpp -o testDrv -I/usr/include/stlport -pthread \
-O2 -fstrict-aliasing -Wall -nodefaultlibs -lstlport -lc
./testDrv
*** glibc detected *** ./testDrv: free(): invalid pointer: 0x2b96b71fb1c0
it looks like a stlport bug.
--
pluto at agmk dot net changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
[Bug other/27541] Support Cluster OpenMP (distributed-memory OpenMP)
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-10 22:46 --- Is there really a standard for this or just an extension of OpenMP? I'm not sure whether I understand the question. Directive wise it is OpenMP augmented by a single directive: shareable. This seems to be a single-vendor extension by Intel. I think they simply took the OpenMP standard and looked how to implement it for distributed memory. The problem in inplementing is, as far as I understood, that plainly speaking OpenMP assumes everything is global whereas distributed programs want to minimize 'global' (better: shared) variables as they have to be synchronized and are thus expensive. Intel added sharable to denote explictly such a variable; however, some variables are automatically marked as shareable. Thus: Syntaxwise it is a rather small change quickly to be implemented in GOMP. But the library system behind is a bigger task: - wrapper main() which initializes helper library, finds settings and starts the program on m computers (incl. forking of n threads) via rsh/ssh. - provides synchronization (barrier, data exchange, collection of data etc.) via TCP or DAPL, especially for global variables Though this is useful a little bit for the Cell where you don't really have a distrubuted machine but the memory will be distributed though. Well, I'm primarily interested to run a number-crunching program (exciting.sf.net) on more nodes. As it is only parallized using OpenMP (and not e.g. via MPI), I'm currently limited to 2 CPUs (or one dualcore) on our cluster. Using Cluster OpenMP with infiniband I could use 2*120 CPUs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27541
[Bug c++/24561] no static definition at -O0
--- Comment #12 from sje at cup dot hp dot com 2006-05-10 22:54 --- I believe the patch checked in for this defect is causing g++.old-deja/g++.other/static14.C and g++.old-deja/g++.other/static20.C to fail. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24561
[Bug target/27542] New: [4.2 Regression] the ms_struct pragma is not documented
When the ms_struct pragma was implemented, Documention was not added for it. -- Summary: [4.2 Regression] the ms_struct pragma is not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: *-*-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
[Bug target/27542] [4.2 Regression] the ms_struct pragma is not documented
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
[Bug target/27543] New: [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented
According to: http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type-Attributes ms_struct is now support for also for the RS6000 back-end. -- Summary: [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc*-*-*, rs6000-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug target/27543] [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug target/27544] New: [4.0/4.1/4.2 Regression] attribute altivec is not documented
It was added by: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg0.html But it was not documented. Zem no longer works at Apple now either. -- Summary: [4.0/4.1/4.2 Regression] attribute altivec is not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc*-*-*, rs6000-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
[Bug target/27544] [4.0/4.1/4.2 Regression] attribute altivec is not documented
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
[Bug target/1078] Problems with attributes documentation
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-11 02:16 --- PR 27544 is about a missing docs for an attribute for RS6000, altivec. PR 27543 is about ms_struct attribute on rs6000/PowerPC as it just says x86 supports it which is no longer true. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27543, 27544 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1078
[Bug gcov/profile/27545] New: Cannot generate profile information for DSO
I'm working on a shared library, and would like to build it with -fprofile-generate information generated from tests that are built with the library, so I can apply it with -fprofile-use. However, when I build the library with CFLAGS='-O2 -g -fprofile-generate', it fails to link the tests with the library: gcc -pthread -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -Wall -I../flow -O2 -g -Wall -Wextra -Wno-unused-parameter -Wmissing-prototypes -Wstrict-prototypes -fprofile-generate -o .libs/benchmark-propagation benchmark-propagation.o ../flow/.libs/libflow.so -L/opt/gnome/lib /opt/gnome/lib/libgobject-2.0.so /opt/gnome/lib/libgthread-2.0.so -lpthread /opt/gnome/lib/libglib-2.0.so /usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld: .libs/benchmark-propagation: hidden symbol `__gcov_init' in /usr/lib/gcc/i586-suse-linux/4.1.0/libgcov.a(_gcov.o) is referenced by DSO /usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status I've tried this with the GCC version 4.1.0 on Fedora Core 4 with the same result. If profiling DSOs is impossible, maybe the documentation for -fprofile-generate should state that. -- Summary: Cannot generate profile information for DSO Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hpj at copyleft dot no GCC build triplet: i686-suse-linux GCC host triplet: i686-suse-linux GCC target triplet: i686-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27545
[Bug gcov/profile/27545] Cannot generate profile information for DSO
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 02:43 --- Can you make sure that the library is still building with -fPIC, if it is not, then this is not a bug. And can you make sure that the library is linking with -fprofile-generate, if it is not, then this is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27545
[Bug gcov/profile/27545] Cannot generate profile information for DSO
--- Comment #2 from hpj at copyleft dot no 2006-05-11 02:52 --- Yes, it's building with -fPIC and building/linking with -fprofile-generate. Without -fprofile-generate, it all builds fine. I'm using libtool. I'm attaching logs of builds with and without -fprofile-generate so you have all the details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27545
[Bug gcov/profile/27545] Cannot generate profile information for DSO
--- Comment #3 from hpj at copyleft dot no 2006-05-11 02:53 --- Created an attachment (id=11436) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11436action=view) Build without -fprofile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27545
