[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #16 from dominiq at lps dot ens dot fr 2007-02-08 08:45 --- Subject: Re: recursive I/O hangs under OSX Try : ... Or increase the size of string. I have increased the length to 20 and in both cases the executable (for an invalid code!-) works on OSX. I have also tried: external fun character(20) :: fun i=2 print trim(fun(i)), 99 end function fun(i) character(20) :: fun integer :: i write(fun,'(A2,I0,A)') (I, I, ) end which works. Is this last code valid for f95 (-std=f95 does give any diagnostic) and/or f2003? Anyway the hanging seems due to the recursive access to external I/O. If I want to corner the problem, where should I look? With directions I can try to locate the problem and test possible fixes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug target/30518] error from system header file
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-02-08 08:54 --- (In reply to comment #7) Yes, this is a bug, a fixincludes should be able to fix it, yes, that should be done. At Apple, we use the fixincludes mechanism to build the SDK bits, so that is eactly the right fix for us as well. But still, the radar was closed. I'm not very familiar with Apple bug handling, will it be fixed nonetheless? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-01-21 11:43:09 |2007-02-08 08:54:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #16 from pcarlini at suse dot de 2007-02-08 09:17 --- Many thanks Howard and Chris: I had a quick look to the tentatively ready issues and didn't notice this one. Anyway, in my understanding, DR 580 (thus the consistent use of allocator::address and the new issues ;) is largely orthogonal to this one and we can make good progress by simply applying Howard' first fix. I'm going to set it up as a full patch, and send it to the list, to close soon this PR. -- pcarlini at suse dot de changed: What|Removed |Added Status|SUSPENDED |ASSIGNED Last reconfirmed|2004-08-12 20:11:36 |2007-02-08 09:17:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug tree-optimization/30730] -Wunsafe-loop-optimizations gives too many warnings
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-08 09:34 ---
Confirmed. The duplicate warnings are annoying. Note that the warning is
emitted because we change n -= 2 to n += 4294967294 (oops).
From the .original tree dump:
{
goto D1972;
D1971:;
n = n + 4294967294;
D1972:;
if (n 10) goto D1971; else goto D1973;
D1973:;
}
this is because 2 is easily negatable and the canonical form in this case
is an addition. While we can fix that, the loop optimizer should be fixed
as well to note that this unsigned addition is just a subtraction of two.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org, rakdver at gcc dot gnu
||dot org
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
GCC build triplet|any |
GCC host triplet|any |
GCC target triplet|any |
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2007-02-08 09:34:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30730
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #17 from jakub at gcc dot gnu dot org 2007-02-08 09:36 --- When writing the unit locking code, I relied on Fortran95 requiring that the same unit isn't used recursively, you can use different units, but not the same. gfortran.dg/intrinsic_actual_2.f90 fails on Linux too when linked with -fopenmp (or -lpthread, -fopenmp implies that), but that is fine, the testcase is IMHO not valid Fortran95 source. Now, if Fortran2003 allows some recursive access to the same unit (under which conditions?), then the gfc_unit's lock could very well be changed into __gthread_recursive_mutex_t as well as the initializer, perhaps together with adding a recursion count (as the recursion count in __gthread_recursive_mutex_t isn't portably accessible) to gfc_unit as well. The question is how much is libgfortran prepared for changes happening to gfc_unit happening between say st_write and st_write_done calls (st_write normally calls get_unit and thus acquires gfc_unit's lock, which is held until st_write_done calls unlock_unit). For Fortran95, if a hang is in your opinion not a good implementation of undefined behavior when running a buggy program, if recursive mutex is used for gfc_unit's lock and a recursion counter is present, then anyone calling gfc_unit could then check the recursion count and if it is bigger than 1, unlock_unit it again and report an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug tree-optimization/30730] -Wunsafe-loop-optimizations gives too many warnings
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-02-08 09:38 --- Note that the warning is emitted because we change n -= 2 to n += 4294967294 (oops). this is because 2 is easily negatable and the canonical form in this case is an addition. While we can fix that, No, you cannot -- loop optimizer would represent n-=2 this way in any case. the loop optimizer should be fixed as well to note that this unsigned addition is just a subtraction of two. Loop optimizers are aware of this on most places. -- 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|NEW |ASSIGNED Last reconfirmed|2007-02-08 09:34:14 |2007-02-08 09:38:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30730
[Bug fortran/30733] New: VOLATILE: Missed optimization - attribute not restricted to scope
+++ This bug was initially created as a clone of Bug #30522 +++
Setting the VOLATILE attribute to a host- or use-associated variable currently
marks the variable everywhere as VOLATILE. The attribute should be, however,
restricted to the scope. (This is a missed optimization only.)
Possible implementation:
decl.c: gfc_match_volatile
case MATCH_YES:
/* If the use- or host-associated symbol is not volatile, we
clone it. */
if (!sym-attr.volatile_ sym-ns != gfc_current_ns)
{
/* note somewhere that in this namespace VOLATILE is needed, e.g. by cloning
the variable here and setting below the attribute only to the cloned variable.
And then put a check in trans-decl.c in e.g. gfc_generate_function_code near
generate_local_vars to actually mark this variable as volatile; be careful that
the variable should be external volatile not a new local variable.
*/
}
if (gfc_add_volatile (sym-attr, sym-name, gfc_current_locus)
Test case: See PR30522's volatile10.f90 (search for TODO).
Maybe the fact that -fdump-tree-original does not show the VOLATILE attribute
for module variables could be solved as collateral damage.
--
Summary: VOLATILE: Missed optimization - attribute not restricted
to scope
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 30522
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
[Bug fortran/30522] Host-/use-associated VOLATILE variable: volatile scope, redundent attributes
--- Comment #1 from patchapp at dberlin dot org 2007-02-08 09:45 --- Subject: Bug number PR30522 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/2007-02/msg00682.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30522
[Bug c++/30734] New: name conflict between class and namespace name is not recognized
1 namespace Foo {
2 };
3
4 class Foo {
5 };
6
7 int main() {
8class Foo1 : public Foo {
9};
10Foo1 my_Foo1;
11Foo my_foo;
12return 0;
13 }
14
15
Foo.C: In function 'int main()':
Foo.C:11: error: expected primary-expression before 'my_foo'
Foo.C:11: error: expected `;' before 'my_foo'
on line 8 and 10, Foo is understod asa class name, on line 11 as a namespace
Without line 11, no error message at all
--
Summary: name conflict between class and namespace name is not
recognized
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ulrich dot lauther at siemens dot com
GCC build triplet: 686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: 686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30734
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #18 from dominiq at lps dot ens dot fr 2007-02-08 10:03 --- Subject: Re: recursive I/O hangs under OSX gfortran.dg/intrinsic_actual_2.f90 fails on Linux too when linked with -fopenmp (or -lpthread, -fopenmp implies that), but that is fine, the testcase is IMHO not valid Fortran95 source. When you say fails what kind of failure do you get? Is this a timeout or not? If this is a runtime error, a seg fault, or whatever but hanging, this is fine with me. Now, if Fortran2003 allows some recursive access to the same unit (under which conditions?) I think the question is settled: recursive access to external units is invalid. then anyone calling gfc_unit could then check the recursion count and if it is bigger than 1, unlock_unit it again and report an error. This seems the path to follow to implement a runtime error, isn't it? To be frank, I have a very limited understanding of what you are saying, but I could look again to the code to figure out what it looks like: I understand more or less the technical concepts, but not the actual implementation. Thanks for your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Re: [Bug c++/30734] New: name conflict between class and namespace name is not recognized
ulrich dot lauther at siemens dot com [EMAIL PROTECTED] writes:
| 1 namespace Foo {
|2 };
|3
|4 class Foo {
|5 };
|6
|7 int main() {
|8class Foo1 : public Foo {
|9};
| 10Foo1 my_Foo1;
| 11Foo my_foo;
| 12return 0;
| 13 }
| 14
| 15
| Foo.C: In function 'int main()':
| Foo.C:11: error: expected primary-expression before 'my_foo'
| Foo.C:11: error: expected `;' before 'my_foo'
|
| on line 8 and 10, Foo is understod asa class name, on line 11 as a namespace
| Without line 11, no error message at all
Line 4 is invalid; the front-end should have issued a diagnostic there.
-- Gaby
[Bug c++/30734] name conflict between class and namespace name is not recognized
--- Comment #1 from gdr at cs dot tamu dot edu 2007-02-08 10:16 ---
Subject: Re: New: name conflict between class and namespace name is not
recognized
ulrich dot lauther at siemens dot com [EMAIL PROTECTED] writes:
| 1 namespace Foo {
|2 };
|3
|4 class Foo {
|5 };
|6
|7 int main() {
|8class Foo1 : public Foo {
|9};
| 10Foo1 my_Foo1;
| 11Foo my_foo;
| 12return 0;
| 13 }
| 14
| 15
| Foo.C: In function 'int main()':
| Foo.C:11: error: expected primary-expression before 'my_foo'
| Foo.C:11: error: expected `;' before 'my_foo'
|
| on line 8 and 10, Foo is understod asa class name, on line 11 as a
namespace
| Without line 11, no error message at all
Line 4 is invalid; the front-end should have issued a diagnostic there.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30734
[Bug c++/30734] name conflict between class and namespace name is not recognized
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|686-pc-linux-gnu| GCC host triplet|i686-pc-linux-gnu | GCC target triplet|686-pc-linux-gnu| Keywords||accepts-invalid Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-02-08 10:46:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30734
Bytes alignement problem with arm-linux-gcc
Hi all
I'm actually working with arm-linux-gcc 3.4.4 and i've noticed a bug
when using union. Indeed i've written the following union but sizes
doesn't match the reallity:
typedef union _t_paquet{
unsigned char msg[14];
struct _NAMEDFIELD{
unsigned char error ;
unsigned long entete ;
unsigned char len ;
unsigned char data[8] ;
} NAMEDFIELD;
}t_paquet ;
Normally we will have the following sizes:
sizeof(a.msg) = 14
sizeof(a.NAMEDFIELD.error) = 1
sizeof(a.NAMEDFIELD.entete) = 4
sizeof(a.lNAMEDFIELD.en) = 1
sizeof(a.NAMEDFIELD.data) = 8.
So we can think that sizeof(a.msg)=sizeof(a.NAMEDFIELD) but
sizeof(a.NAMEDFIELD)=20 ...
How can this problem can be resolved? Is there a specific compilation
option for alignement problems?
With regards
Frederic
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #19 from dominiq at lps dot ens dot fr 2007-02-08 12:06 --- The following invalid code: external fun real fun real a a = fun() ! print *, a write(10,*) fun(), a, 'try it', ' 1.23' end real function fun() print *, 'test' fun = 1.0 end gives a working executable when compiled with gfortran on OSX. However, if I replace print *, by write(10,*) the executable hangs again. So the problem seems limited to use of the same external unit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
GCC has problems with 64-bit multiplication
Test program:
#include stdio.h
#include sys/types.h
int main() {
int32_t a = 0x4000;
int16_t b = 0x4000;
int64_t c = a * b;
printf(0x%016llx\n, c);
return 0;
}
%cc test.c
%./a.out
0x
%gcc --version
gcc (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Generated assembly code:
8048514: c7 45 fc 00 00 00 40movl $0x4000,0xfffc(%ebp)
804851b: 66 c7 45 fa 00 40 movw $0x4000,0xfffa(%ebp)
8048521: 0f bf 45 fa movswl 0xfffa(%ebp),%eax
8048525: 0f af 45 fc imul 0xfffc(%ebp),%eax
XXX this instruction is probably the bug:
8048529: 99 cltd
804852a: 89 45 f0mov%eax,0xfff0(%ebp)
804852d: 89 55 f4mov%edx,0xfff4(%ebp)
8048530: 83 ec 04sub$0x4,%esp
8048533: ff 75 f4pushl 0xfff4(%ebp)
8048536: ff 75 f0pushl 0xfff0(%ebp)
8048539: 68 cb 85 04 08 push $0x80485cb
804853e: e8 49 fe ff ff call 804838c _init+0x24
8048543: 83 c4 10add$0x10,%esp
--HPS
[Bug tree-optimization/23361] Can't eliminate empty loops with power of two step and variable bounds
--- Comment #11 from rakdver at gcc dot gnu dot org 2007-02-08 14:38 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00704.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||02/msg00704.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23361
Re: GCC has problems with 64-bit multiplication
All,
Not a bug in GCC the result is correct as you've only asked for a 32-bit
multiply.
--- Hans Petter Selasky [EMAIL PROTECTED] wrote:
Test program:
#include stdio.h
#include sys/types.h
int main() {
int32_t a = 0x4000;
int16_t b = 0x4000;
int64_t c = a * b;
^ this is a 32-bit multiply with the result widened
to 64-bit,
printf(0x%016llx\n, c);
return 0;
}
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #20 from kargl at gcc dot gnu dot org 2007-02-08 16:18 --- (In reply to comment #17) Now, if Fortran2003 allows some recursive access to the same unit (under which conditions?), Recursive IO to external units is simply not allowed by the Fortran 95 and Fortran 2003 standards. You could wade through Brooks posts in fortran@ to see where recursion is allowed. __gthread_recursive_mutex_t as well as the initializer, perhaps together with adding a recursion count (as the recursion count in __gthread_recursive_mutex_t isn't portably accessible) to gfc_unit as well. The question is how much is libgfortran prepared for changes happening to gfc_unit happening between say st_write and st_write_done calls (st_write normally calls get_unit and thus acquires gfc_unit's lock, which is held until st_write_done calls unlock_unit). This sound like a performance penalty imposed on anyone writing standard conforming code to permit nonconforming code to run. The fact remains that a fortran processor can do anything it wants with nonconforming code. It might work on some architecture and it may fail another for some definition of work and fail. So be it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
Re: GCC has problems with 64-bit multiplication
On Thursday 08 February 2007 16:02, Graham Stott wrote:
All,
Not a bug in GCC the result is correct as you've only asked for a 32-bit
multiply.
Ok, thanks. But really I don't want to do ((int64_t)a) * b, which I know
works, hence that is very much slower than a * b on intel processors, hence
the mull instruction will be used instead of imul.
I found the following option by googling:
-mwide-multiply multiplies of 32 bits are 64
Is there an __attribute__() that I can use that will enable this for one
multiplication, and not all ? Or something similar ?
--- Hans Petter Selasky [EMAIL PROTECTED] wrote:
Test program:
#include stdio.h
#include sys/types.h
int main() {
int32_t a = 0x4000;
int16_t b = 0x4000;
int64_t c = a * b;
^ this is a 32-bit multiply with the result
widened to 64-bit,
printf(0x%016llx\n, c);
return 0;
}
--HPS
[Bug tree-optimization/30562] [4.3 Regression] remove unused variable is removing a referenced variable (in STORED_SYMS or LOADED_SYMS)
--- Comment #6 from dnovillo at gcc dot gnu dot org 2007-02-08 16:56 --- Subject: Bug 30562 Author: dnovillo Date: Thu Feb 8 16:55:43 2007 New Revision: 121715 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121715 Log: PR 30562 * tree-flow.h (struct var_ann_d): Remove field 'is_used'. Update all users. * tree-ssa-alias.c (compute_is_aliased): Remove. Update all users. (init_alias_info): * tree-ssa-live.c (remove_unused_locals): Do not remove TREE_ADDRESSABLE variables. * tree-ssa-structalias.c (compute_points_to_sets): Tidy. * tree-ssa-operands.c (add_virtual_operand): Remove argument FOR_CLOBBER. Update all users. If VAR has an associated alias set, add a virtual operand for it if no alias is found to conflict with the memory reference. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-live.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug tree-optimization/30735] New: 50% slow down due to mem-ssa merge
There is a huge regression of gcc 4.3 performance detected on cpu2006/454.calculix benchmark at -O2 optimization level on x86_64-redhat-linux. Regression is caused by mem-ssa merge 12/12/2006 (revision 119760). http://gcc.gnu.org/viewcvs?view=revrevision=119760 mem-ssa merge may introduce unnecessary memory - register moves. -- Summary: 50% slow down due to mem-ssa merge Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug tree-optimization/30735] 50% slow down due to mem-ssa merge
--- Comment #1 from hjl at lucon dot org 2007-02-08 17:01 --- Created an attachment (id=13021) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13021action=view) A testcase # /usr/gcc-good/bin/gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.3 --with-local-prefix=/usr/local Thread model: posix gcc version 4.3.0 20061211 (experimental) [trunk revision 119728] # /usr/gcc-4.3/bin/gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --enable-decimal-float=yes --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.3 --with-local-prefix=/usr/local Thread model: posix gcc version 4.3.0 20070206 (experimental) [trunk revision 121636] # make /usr/gcc-good/bin/gfortran -c -O2 -ffast-math -static -o old.o e_c3d.f /usr/gcc-4.3/bin/gfortran -O2 -ffast-math -static -c -o tr535.o tr535.f /usr/gcc-4.3/bin/gfortran -O2 -ffast-math -static -o old old.o tr535.o /usr/gcc-4.3/bin/gfortran -c -O2 -ffast-math -static -o new.o e_c3d.f /usr/gcc-4.3/bin/gfortran -O2 -ffast-math -static -o new new.o tr535.o time ./old 0.03user 0.00system 0:00.03elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+82minor)pagefaults 0swaps time ./new 0.10user 0.00system 0:00.10elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+83minor)pagefaults 0swaps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug tree-optimization/30735] 50% slow down due to mem-ssa merge
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-08 17:07 --- Try one of the partitioning patches I proposed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug tree-optimization/30562] [4.3 Regression] remove unused variable is removing a referenced variable (in STORED_SYMS or LOADED_SYMS)
--- Comment #7 from dnovillo at gcc dot gnu dot org 2007-02-08 17:10 --- Fix http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00727.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug tree-optimization/30735] 50% slow down due to mem-ssa merge
--- Comment #3 from hjl at lucon dot org 2007-02-08 17:13 --- (In reply to comment #2) Try one of the partitioning patches I proposed. Which one? Please provide a link or attach it here. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug target/30736] New: stack references scheduled below stack pointer adjustment
This was initially seen internally with a 4.1.2 gcc plus power6 patches,
but with some adjustments to haifa-sched.c (only touching the order in the
ready list) can be reproduced with trunk. The underlying issue is, that
the stack pointer restore instruction in the rs6000 backend does not conflict
with all insns accessing stack memory, but only with those created by
gen_frame_mem(). Attached is a C++ testcase (from khtml). Bear with me while
explaining the error, it's hard to construct a small runtime testcase.
Suppose this patch is applied to trunk:
-
Index: haifa-sched.c
===
--- haifa-sched.c (revision 121710)
+++ haifa-sched.c (working copy)
@@ -798,6 +798,8 @@ priority (rtx insn)
}
while (twin != prev_first);
}
+if (INSN_UID(insn) == 235 || INSN_UID(insn)==230)
+ this_priority += 10;
INSN_PRIORITY (insn) = this_priority;
INSN_PRIORITY_KNOWN (insn) = 1;
}
@@ -930,7 +932,7 @@ rank_for_schedule (const void *x, const
/* If insns are equally good, sort by INSN_LUID (original insn order),
so that we make the sort stable. This minimizes instruction movement,
thus minimizing sched's effect on debugging and cross-jumping. */
- return INSN_LUID (tmp) - INSN_LUID (tmp2);
+ return INSN_LUID (tmp2) - INSN_LUID (tmp);
}
/* Resort the array A in which only element at index N may be out of order.
*/
@@ -2402,7 +2404,7 @@ schedule_block (basic_block *target_bb,
if (ready.n_ready 0)
ready_sort (ready);
- if (targetm.sched.reorder2
+ if (0 targetm.sched.reorder2
(ready.n_ready == 0
|| !SCHED_GROUP_P (ready_element (ready, 0
{
-
I.e. switch off target specific reorder2, reorder insns by _inverse_ uid
and special case two instructions by priority in order to force them to be
output earlier. The compile the attached testcase with:
% ./gcc/cc1plus -O2 -quiet -fsched-verbose=6 -da bug.ii
Examine the assembler output for the docWidth method (not the thunk):
_ZNK5khtml12RenderCanvas8docWidthEv:
addi 9,1,12 r9 = r1+12
.L22:
lwz 0,52(1)
lwz 31,44(1)
lwz 30,40(1)
lwz 29,36(1)
lwz 28,32(1)
mtlr 0
addi 1,1,48 r1 = r1+48
lwz 3,0(9) access [r9] == [r1-36]
blr
Note that the access to [r9] is below the adjustment to r1 (stack pointer).
When a signal occurs at exactly that place this will most probably have been
overwritten. I'm aware of the red zone on ppc64 (and in fact also on ppc
linux) but with a more complicated function the invalidly accessed offset
could be made larger.
The reason why this happens can be seen in the dumps. The relevant insns are
(before sched2):
(insn:HI 153 152 154 18 (set (reg/v/f:SI 9 9 [orig:123 a ] [123])
(plus:SI (reg/f:SI 1 1)
(const_int 12 [0xc]))) 79 {*addsi3_internal1} (nil)
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 1 1)
(const_int 12 [0xc]))
(nil)))
...
(insn:HI 157 155 228 19 (set (reg:SI 3 3 [orig:135 D.62311 ] [135])
(mem:SI (reg/v/f:SI 9 9 [orig:123 a ] [123]) [4 S4 A32])) 310
{*movsi_internal1} (nil)
(expr_list:REG_DEAD (reg/v/f:SI 9 9 [orig:123 a ] [123])
(nil)))
(insn 228 157 229 19 (use (reg/i:SI 3 3 [ result ])) -1 (nil)
(nil))
...
(insn 231 230 232 19 (set (reg:SI 28 28)
(mem/c:SI (plus:SI (reg/f:SI 1 1)
(const_int 32 [0x20])) [69 S4 A8])) 310 {*movsi_internal1}
(nil)(nil))
[a couple more loads from callee saved reg from [r1+offset]
(insn 235 234 236 19 (set (reg/f:SI 1 1)
(plus:SI (reg/f:SI 1 1)
(const_int 48 [0x30]))) 79 {*addsi3_internal1} (nil)
(nil))
(jump_insn 236 235 239 19 (parallel [
(return)
(use (reg:SI 65 lr))
]) 544 {*return_internal_si} (nil)
(nil))
Note how the second last insn, the stack pointer adjustment can't cause any
dependency of any sort with insn 157, as the latter uses register 9 to access
the stack. Note further that all accesses to the saved registers are using
alias set 69, while the read from [r9] (for the to be returned value) is using
alias set 4. From inside the compiler it can be checked that both alias sets
do not conflict.
That is important to know, because the rs6000 backend has provisions to
generate a sort of schedule barrier instruction supposed to clobber stack
memory in order to not resort the saved register instructions with the stack
adjustment. That's the 'stack_tie' instruction. That one uses
gen_frame_mem() to create a MEM rtx which it can clobber, but that will have
(in this case) alias set 4 (get_frame_alias_set() ). So, even if it would
have been emitted it wouldn't stop this particular reordering (because not
[Bug tree-optimization/30562] [4.3 Regression] remove unused variable is removing a referenced variable (in STORED_SYMS or LOADED_SYMS)
--- Comment #8 from aldot at gcc dot gnu dot org 2007-02-08 17:30 --- I was seeing this bug when building with BOOT_CFLAGS=-march=nocona\ -mtune=nocona\ -O2 that later ICE'd for ../gcc/libgcc2.c:557 I don't have access to that x86_64 with ubuntu anymore so cannot check if the patch does fix it, unfortunately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug target/30736] stack references scheduled below stack pointer adjustment
--- Comment #1 from matz at gcc dot gnu dot org 2007-02-08 17:35 ---
I can't currently attach anything, somehow bugzilla is broken.
Anyway, perhaps the description of what happens is clear enough to see the
error. Btw: this patch will solve the problem on trunk per my proposal:
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 121710)
+++ config/rs6000/rs6000.c (working copy)
@@ -14112,6 +14112,7 @@ rs6000_emit_stack_tie (void)
rtx mem = gen_frame_mem (BLKmode,
gen_rtx_REG (Pmode, STACK_POINTER_REGNUM));
+ set_mem_alias_set (mem, 0);
emit_insn (gen_stack_tie (mem));
}
@@ -14561,9 +14562,8 @@ rs6000_emit_prologue (void)
|| info-first_fp_reg_save 64
|| info-first_gp_reg_save 32
)));
- if (frame_reg_rtx != sp_reg_rtx)
- rs6000_emit_stack_tie ();
}
+ rs6000_emit_stack_tie ();
/* Handle world saves specially here. */
if (WORLD_SAVE_P (info))
@@ -15501,11 +15501,11 @@ rs6000_emit_epilogue (int sibcall)
/* If this is V.4, unwind the stack pointer after all of the loads
have been done. */
+ rs6000_emit_stack_tie ();
if (frame_reg_rtx != sp_reg_rtx)
{
/* This blockage is needed so that sched doesn't decide to move
the sp change before the register restores. */
- rs6000_emit_stack_tie ();
emit_move_insn (sp_reg_rtx, frame_reg_rtx);
}
else if (sp_offset != 0)
---
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30736
[Bug c/30737] New: C99 initializer can't see anon struct/union members
bug 1 $ cat bug.c
// Build as follows:
// gcc -W -Wall -O2 -std=gnu99 -c bug.c
#include string.h
typedef signed char s8;
typedef signed short s16;
typedef signed int s32;
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
struct ron{
short ann;
union{
u16 ben;
struct {
u8 bob;
u8 jon;
};
};
u32 abe;
u32 ada;
char sue[];
};
int sid(char *buf){
char *orig = buf;
struct ron don = {
.ann = 84,
.ben = 76,
.abe = 7,
.ada = 8,
};
memcpy(buf,don,sizeof don);
buf += sizeof don;
return buf - orig;
}
bug 0 $ gcc -W -Wall -O2 -std=gnu99 -c bug.c
bug.c: In function sid:
bug.c:31: error: unknown field ben specified in initializer
bug.c:31: warning: missing braces around initializer
bug.c:31: warning: (near initialization for don.anonymous)
bug 1 $ gcc -v
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 --enable-plugin
--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.1 20070123 (Red Hat 4.1.1-54)
bug 0 $
--
Summary: C99 initializer can't see anon struct/union members
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acahalan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30737
[Bug tree-optimization/30735] 50% slow down due to mem-ssa merge
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-08 18:42:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug c/30737] C99 initializer can't see anon struct/union members
--- Comment #1 from joseph at codesourcery dot com 2007-02-08 18:42 --- Subject: Re: New: C99 initializer can't see anon struct/union members Looks like bug 10676 to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30737
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #10 from tobi at gcc dot gnu dot org 2007-02-08 19:00 --- I forgot that OS X is not supported by gcc 4.1, and got my memory refreshed only after it was 3/4 of the build. I've now started a build on a Linux machine, but I will probably not have time to attend this bug before tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug target/30518] error from system header file
--- Comment #10 from mrs at apple dot com 2007-02-08 19:02 --- Ignore me, I'm going crazy. This is really just a simple problem of the software isn't portable to 10.3.9. The right fix is to modify it so that it compiles. The OS has been fixed to not have this bug in more recent versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
[Bug c/30737] C99 initializer can't see anon struct/union members
--- Comment #2 from acahalan at gmail dot com 2007-02-08 19:05 --- (In reply to comment #1) Subject: Re: New: C99 initializer can't see anon struct/union members Looks like bug 10676 to me. Perhaps, but that bug has an incorrect keyword. It is marked diagnostic, which is far less serious than the correct rejects-valid keyword. It's also marked minor, which seems like a poor choice for a bug that rejects valid code. (and, BTW, the dupes are building up) I'd rather you didn't dupe this out against a bug marked as a minor diagnostic problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30737
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-08 19:17 --- *** Bug 30736 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/30736] stack references scheduled below stack pointer adjustment
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-08 19:17 --- *** This bug has been marked as a duplicate of 30282 *** -- 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=30736
ICAS 2007 ICNS 2007, Athens, June 19-25, 2007 DEADLINE EXTENDED FEBRUARY 10
Invitation Please consider contributing to ICAS 2007, ICNS 2007 and the associated workshops listed below. Conference: June 19-25, 2007, Athens, Greece Important deadline for full paper submission: February 10, 2007 Please forward the Call for Submissions to the appropriate groups. === CALL FOR PAPERS ICAS 2007: The Third International Conference on Autonomic and Autonomous Systems: http://www.iaria.org/conferences2007/ICAS07.html ICNS 2007: The Third International Conference on Networking and Services http://www.iaria.org/conferences2007/ICNS07.html Featuring also the workshops: - SELF 2007: The Second International Workshop on Self-adaptability and Self-management of Context-aware Systems http://www.iaria.org/conferences2007/SELF.html - KUI 2007: The First International Workshop on Knowledge-based User Interface http://www.iaria.org/conferences2007/KUI.html - IPv6DFI 2007: The Second International Workshop on Deploying the Future Infrastructure http://www.iaria.org/conferences2007/IPV6DFI.html - IPDy 2007: The Second International Workshop on Internet Packet Dynamics http://www.iaria.org/conferences2007/IPDY.html - GOBS 2007: The First International Workshop on GRID over Optical Burst Switching Networks http://www.iaria.org/conferences2007/GOBS.html === Published by IEEE Computer Society Press Published in the IEEE Xplore Digital Library Indexing: http://www.computer.org/portal/pages/cscps/cps/cps_indexing.html === ICAS 2007 Main Tracks: SYSAT: Advances in system automation AUTSY: Theory and practice of autonomous systems AWARE: Design and deployment of context-awareness networks, services and applications AUTONOMIC: Autonomic computing: design and management of self-behavioural networks and services MCMAC: Monitoring, control, and management of autonomous self-aware and context-aware systems CASES: Automation in specialized mobile environments ALCOC: Algorithms and theory for control and computation MODEL: Modelling, virtualization, any-on-demand, MDA, SOA = ICNS 2007 Main Tracks: ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications -- View this message in context: http://www.nabble.com/ICAS-2007---ICNS-2007%2C-Athens%2C-June-19-25%2C-2007-DEADLINE-EXTENDED-FEBRUARY-10-tf3195435.html#a8872497 Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #12 from tromey at gcc dot gnu dot org 2007-02-08 19:49 --- Subject: Bug 30513 Author: tromey Date: Thu Feb 8 19:49:32 2007 New Revision: 121721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121721 Log: 2007-01-27 Andreas Tobler [EMAIL PROTECTED] PR libgcj/30513 * configure.host: Add forgottten sysdep_dir to sparc. Add a flag to libgcj_flags to undefine 'sun' at compile time. * sysdep/sparc/locks.h (read_barrier): New functions for 32 and 64 bit Sparc. (write_barrier): Likewise. Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/ChangeLog branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/configure.host branches/redhat/gcc-4_1-branch-java-merge-20070117/libjava/sysdep/sparc/locks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug libgcj/30647] build of gcc midi-dssi fails
--- Comment #3 from tromey at gcc dot gnu dot org 2007-02-08 20:21 --- Created an attachment (id=13022) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13022action=view) proposed patch Please try this patch. If it works for you I will check it in. Thanks. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30647
[Bug bootstrap/30678] [4.3 regression] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-02-08 20:26 --- (In reply to comment #13) The problem was supposed to have been fixed: http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00194.html http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00172.html Ah, I see. As I don't regularly read gcc-cvs :-), and the commits didn't mention this PR, I didn't catch that. This WORKSFORME now. Is anybody else seeing problems? If not, we can close this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #4 from patchapp at dberlin dot org 2007-02-08 20:30 --- Subject: Bug number PR30498 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/2007-02/msg00747.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #13 from andreast at gcc dot gnu dot org 2007-02-08 20:46 --- I'll close it. Doko confirmed it is working on sparc-linux. Thanks. -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug bootstrap/30678] [4.3 regression] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #15 from bkorb at gnu dot org 2007-02-08 20:53 --- The commit notice went out to gcc-patches, too. I'd have updated this, but apparently I need more than gcc-CVS commit permissions to do so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug libgcj/30570] Word DEBUG used as a variable in VMAccessController.java breaks build
--- Comment #3 from rob1weld at aol dot com 2007-02-08 20:56 --- I found out exactly what the trouble is - it _likely_ affects ALL platforms. I use a very long set of configure options (to enable as much as possible) but the one that is causing the trouble is: --enable-libgcj-debug . I proved this by altering the file: gcc-4_2-branch/libjava/java/security/natVMAccessController.cc I added this around the #include config.h statement: static const jint DEBUG = 1L; #include config.h static const jint DEBUG = 1L; I then compiled the file using the exact same command that make shows on screen plus I added -E to show the error and examined the resulting file: # 11 /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/java/security/natVMAccessController.cc static const jint DEBUG = 1L; # 1 ./include/config.h 1 # 14 /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/java/security/natVMAccessController.cc 2 static const jint 1 = 1L; The second 'jint' statement is wrong so that means that the included config.h wrecked things. Looking at file: /gcc-4_2-branch-build/i686-pc-cygwin/libjava/include/config.h we have this: /* include/config.h. Generated by configure. */ /* include/config.h.in. Generated from configure.ac by autoheader. */ /* Define this if you want runtime debugging enabled. */ #define DEBUG 1 Note: We have the same definition (without causing the error, since _this_ config.h is not included) here in /gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/include/config.h. /* include/config.h. Generated by configure. */ /* include/config.h.in. Generated from configure.ac by autoheader. */ /* Define to 1 if you want native library runtime debugging code enabled */ #define DEBUG 1 That second one does not cause any trouble but _IF_ you are going to change the word DEBUG be sure to change them both if they should both be the same word. This problem comes from the file: /gcc-4_2-branch/libjava/include/config.h.in so this _IS_ a 'gcc problem' and not a problem with either classpath's source or Cygwin's headers. Here is the part of config.h.in at fault: /* include/config.h.in. Generated from configure.ac by autoheader. */ /* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP systems. This function is required for `alloca.c' support on those systems. */ #undef CRAY_STACKSEG_END /* Define to 1 if using `alloca.c'. */ #undef C_ALLOCA /* Define this if you want runtime debugging enabled. */ #undef DEBUG /* Define if system properties shouldn't be read from getenv(GCJ_PROPERTIES). */ #undef DISABLE_GETENV_PROPERTIES Now that _MAY_ seem inocent enough but what happens when you run /gcc-4_2-branch/configure --enable-libgcj-debug is that /gcc-4_2-branch/libjava/configure gets passed the --enable-libgcj-debug and creates a confdefs.h file (that gets deleted - thus hiding the problem from searching). When the /gcc-4_2-branch/libjava/configure script gets near the end it does the sed script routine (to substitute variables in the *.in files) it uses the confdefs.h file as well. Here is the part of the configure script that says it does this: # Transform confdefs.h into two sed scripts, `conftest.defines' and # `conftest.undefs', that substitutes the proper values into # config.h.in to produce config.h. The first handles `#define' # templates, and the second `#undef' templates. That tells me that configure is replacing the #undef DEBUG in config.h.in with #define DEBUG 1 if configure uses the parameter --enable-libgcj-debug. This creates the problem in the java/security/VMAccessController.h file that is made by gcjh (I hope I explained that correctly). I just got through re-running /gcc-4_2-branch/configure (with all my long list of parameters) without using --enable-libgcj-debug and make runs without causing the error (while compiling gcc-4_2-branch/libjava/java/security/natVMAccessController.cc) it still breaks _elsewhere_ ;( . I am not an expert on Java and I will leave it to the experts as how best to fix this. My 2 cents is that the file /gcc-4_2-branch/libjava/configure is wrong since it sets #define DEBUG 1 ; and in doing so it breaks the file java/security/VMAccessController.h (created by gcjh). I suggest that this is _equally_ applicable to _all_ platforms and would halt the build for anyone who uses --enable-libgcj-debug (_AND_ also uses other parameters that cause /gcc-4_2-branch/libjava/java/security/natVMAccessController.cc to be compiled). Since this should happen on any platform can someone else confirm it? (As a point of interest I am using this /gcc-4_2-branch/configure command: /cygdrive/C/makecygwin/gcc-4_2-branch/configure --disable-werror --verbose --target=i686-pc-cygwin --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-static --enable-nls
[Bug c++/30738] New: suboptimal code for min, max, et al
For T being an arithmetic type, gcc 4.1 generates what looks like suboptimal
assembly code for inline C++ functions that take their argument(s) by const
reference (const T) vs the same functions that take their argument(s) by value
(T).
Ideally, the code generated for test_min_ref() and test_min_ptr() below would
be the same as for test_min_val(). The code generated for SPARC at the bottom
shows that the code for both functions is worse.
template class T inline const T min_ref (const T x, const T y) { return x
y ? x : y; }
template class T inline const T* min_ptr (const T *x, const T *y) { return *x
*y ? x : y; }
template class T inline T min_val (T x, T y) { return x y ? x : y; }
int test_min_ref (int x, int y) { return min_ref (x, y); }
int test_min_ptr (int x, int y) { return *min_ptr (x, y); }
int test_min_val (int x, int y) { return min_val (x, y); }
.file t.cpp
.section.text
.align 4
.global _Z12test_min_refii
.type _Z12test_min_refii, #function
.proc 04
_Z12test_min_refii:
.LLFB5:
cmp %o0, %o1
st %o0, [%sp+68]
st %o1, [%sp+72]
bge .LL7
add%sp, 68, %o0
jmp %o7+8
ld [%o0], %o0
.LL7:
add %sp, 72, %o0
jmp %o7+8
ld [%o0], %o0
.LLFE5:
.size _Z12test_min_refii, .-_Z12test_min_refii
.global __gxx_personality_v0
.align 4
.global _Z12test_min_ptrii
.type _Z12test_min_ptrii, #function
.proc 04
_Z12test_min_ptrii:
.LLFB6:
cmp %o0, %o1
st %o0, [%sp+68]
st %o1, [%sp+72]
bge .LL13
add%sp, 68, %o0
jmp %o7+8
ld [%o0], %o0
.LL13:
add %sp, 72, %o0
jmp %o7+8
ld [%o0], %o0
.LLFE6:
.size _Z12test_min_ptrii, .-_Z12test_min_ptrii
.align 4
.global _Z12test_min_valii
.type _Z12test_min_valii, #function
.proc 04
_Z12test_min_valii:
.LLFB7:
cmp %o0, %o1
bg,a.LL17
mov%o1, %o0
.LL17:
jmp %o7+8
nop
.LLFE7:
.size _Z12test_min_valii, .-_Z12test_min_valii
.ident GCC: (GNU) 4.1.0
--
Summary: suboptimal code for min, max, et al
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris
GCC host triplet: sparc-sun-solaris
GCC target triplet: sparc-sun-solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30738
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 21:25 --- I forgot that OS X is not supported by gcc 4.1 What do you mean? I have built gcc 4.1 on both OSX 10.3 an 10.4 several time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug bootstrap/30678] [4.3 regression] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-02-08 21:38 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-08 21:49 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: --- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 21:25 --- I forgot that OS X is not supported by gcc 4.1 What do you mean? I have built gcc 4.1 on both OSX 10.3 an 10.4 several time. The build fails with errors of the following kind: /var/tmp//ccFScp77.s:3049:indirect jmp without `*' This is with $ as -version Apple Computer, Inc. version cctools-622.3.obj~2, GNU assembler version 1.38 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #13 from dominiq at lps dot ens dot fr 2007-02-08 22:06 --- The build fails with errors of the following kind: /var/tmp//ccFScp77.s:3049:indirect jmp without `*' Sound familiar, aren't you speaking of MacIntel? I have done some testing on MacIntel with a prebuild gfortran and I remember having some problems with as. I did not build gcc 4.1 recently on PPC 10.4.8, but I have build 4.2 without problem with as Apple Computer, Inc. version cctools-622.5.obj~13, GNU assembler version 1.38 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug bootstrap/30739] New: awk Prerequisite is not documented
After getting a private email about what caused PR 29049 for real, I noticed that the prerequisite for awk was not documented in http://gcc.gnu.org/install/prerequisites.html Yes it is a standard UNIX tool but there are some versions of GNU awk which are broken. -- Summary: awk Prerequisite is not documented Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30739
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-08 22:10 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: --- Comment #13 from dominiq at lps dot ens dot fr 2007-02-08 22:06 --- The build fails with errors of the following kind: /var/tmp//ccFScp77.s:3049:indirect jmp without `*' Sound familiar, aren't you speaking of MacIntel? I have done some testing on MacIntel with a prebuild gfortran and I remember having some problems with as. I did not build gcc 4.1 recently on PPC 10.4.8, but I have build 4.2 without problem with as Apple Computer, Inc. version cctools-622.5.obj~13, GNU assembler version 1.38 Yes MacIntel, sorry, I should have said that. 4.2 is indeed fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #15 from dominiq at lps dot ens dot fr 2007-02-08 22:25 --- I think there is definitively a problem with the as provided on MacIntel. If you are interested I can dig my archives, I think I have some trace of the problem. Unfortunately I have only a limited access to a MacIntel machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug target/30518] error from system header file
--- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 22:30 --- Subject: Re: error from system header file I cannot remember if I have given the appropriate feedback. I thought this bug was closed since I have probably done at least two builds since the bug appeared. If I have not given any feedback, I apologize. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
[Bug c++/30703] ICE Segmentation fault on using OpenMP
--- Comment #5 from jakub at gcc dot gnu dot org 2007-02-08 23:31 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30703
[Bug middle-end/30696] [4.3 regression] Linker failure with OpenMP and inline function
--- Comment #4 from jakub at gcc dot gnu dot org 2007-02-08 23:35 --- Fixed on the trunk, thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30696
[Bug rtl-optimization/29599] [4.1/4.2/4.3 Regression] ICE when building the kernel on SH4
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-02-08 23:54 --- Alex suggested that it's a problem in the generic part of the compiler. I'm preparing another patch according to his suggestion. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29599
[Bug libgcj/30570] Word DEBUG used as a variable in VMAccessController.java breaks build
--- Comment #4 from tromey at gcc dot gnu dot org 2007-02-09 00:03 --- Thanks for analyzing this. I think we ought to rename libgcj's DEBUG to something else. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-09 00:03:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug libgcj/30647] build of gcc midi-dssi fails
--- Comment #4 from grgoffe at yahoo dot com 2007-02-09 00:19 --- Subject: Re: build of gcc midi-dssi fails Tom, I'm in my gcc directory and entered patch ../configure.patch but got some error messages. Is this not the right way to put on the patch? Wrong directory? Hints gladly accepted. Regards, George... --- tromey at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from tromey at gcc dot gnu dot org 2007-02-08 20:21 --- Created an attachment (id=13022) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13022action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13022action=view) proposed patch Please try this patch. If it works for you I will check it in. Thanks. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30647 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. = _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/ _/_/_/_/ _/_/_/_/ - _/ _/ _/_/ _/_/ _/ _/ _/ _/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ - _/_/ _/ _/_/ _/ _/ _/_/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/ - It's not what you know that hurts you, It's what you know that ain't so. Will Rogers Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30647
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-02-09 00:32 --- Comment #3 is not quite correct: The ICE for the first testcase in comment #1 is in instantiate_decl, at cp/pt.c:12204 The ICE for the second testcase in comment #1 is in import_export_decl, at cp/decl2.c:1956 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug c++/30722] ICE on invalid template code #2
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-02-09 00:33 --- See second testcase in comment #1 of PR24791. *** This bug has been marked as a duplicate of 24791 *** -- 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=30722
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #7 from reichelt at gcc dot gnu dot org 2007-02-09 00:33 --- *** Bug 30722 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||v dot haisman at sh dot cvut ||dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug c++/30721] ICE on invalid template code
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-02-09 00:34 --- See first testcase in comment #1 of PR24791. *** This bug has been marked as a duplicate of 24791 *** -- 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=30721
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-02-09 00:34 --- *** Bug 30721 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug c++/30659] [4.0/4.1/4.2/4.3 Regression] ICE in undefined template
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-02-09 00:48 --- Even shorter testcase: extern C template Achar foo(); I don't get the segfault in GCC 4.0.4 and current 4.1 branch (although I see it in 4.0.3 and 4.1.1). Can somebody reproduce the bug on these branches? -- reichelt 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=30659
[Bug libgcj/30647] build of gcc midi-dssi fails
--- Comment #5 from tromey at gcc dot gnu dot org 2007-02-09 00:51 --- Sorry, I didn't make that patch at the top level. cd top/libjava/classpath, then apply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30647
[Bug ada/30740] New: Improper semantics in gnat's compilation of certain expressions involving modular arithmetic
The problem appears in the evaluation of certain expressions with modular variables. Without the use of the -gnato option during compilation, the executable produced by gnat 3.15p on Solaris for the source code shown below produces incorrect results. Here's a sample output line from this program: __ When J=2, Test_Pattern*2**J =124 or 2#100# but Test_Pattern*2**2 = 60 or 2#00# __ 60 is correct, 124 is incorrect. So the default behavior of the compiler does not appear to match the semantics of the Ada language standard for modular values and the workaround requires use of an option (-gnato) that should not be influencing the behavior of this program. (Overflow is not possible for modular values; they must always wrap around.) See http://groups.google.com/group/comp.lang.ada/browse_thread/thread/4eca860272d4832b/3bca35e8bb0bdb52?hl=en#3bca35e8bb0bdb52 for a complete discussion of this problem. Here's the source code of a program that demonstrates this problem in my environment and, according to others on comp.lang.ada, other environments as well: with Ada.Text_IO; use Ada.Text_IO; procedure Strange_Typing is type Six_Bits is mod 2**6; package Six_Bit_IO is new Ada.Text_IO.Modular_IO(Six_Bits); use Six_Bit_IO; Test_Pattern : Six_Bits := 31; -- 5 bits of ones begin Put(The test pattern is a modulo 2**6 integer = ); Put(Test_Pattern, 0); Put( or ); Put(Test_Pattern, 0, 2); New_Line(2); for J in 0 .. 5 loop Put(When J=); Put(Six_Bits(J), 0); Put(, ); Put(Test_Pattern*2**J =); Six_Bit_IO.Put( Test_Pattern*2**J); Put( or ); Six_Bit_IO.Put( Test_Pattern*2**J, 0, 2); Put(Ascii.Ht but ); case J is when 0 = Put(Test_Pattern*2**0 = ); Put( Test_Pattern*2**0, 0);Put( or ); Put( Test_Pattern*2**0, 0, 2); when 1 = Put(Test_Pattern*2**1 = ); Put( Test_Pattern*2**1, 0);Put( or ); Put( Test_Pattern*2**1, 0, 2); when 2 = Put(Test_Pattern*2**2 = ); Put( Test_Pattern*2**2, 0);Put( or ); Put( Test_Pattern*2**2, 0, 2); when 3 = Put(Test_Pattern*2**3 = ); Put( Test_Pattern*2**3, 0);Put( or ); Put( Test_Pattern*2**3, 0, 2); when 4 = Put(Test_Pattern*2**4 = ); Put( Test_Pattern*2**4, 0);Put( or ); Put( Test_Pattern*2**4, 0, 2); when 5 = Put(Test_Pattern*2**5 = ); Put( Test_Pattern*2**5, 0);Put( or ); Put( Test_Pattern*2**5, 0, 2); end case; New_Line; end loop; New_Line; end Strange_Typing; -- Summary: Improper semantics in gnat's compilation of certain expressions involving modular arithmetic Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaffem at erau dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30740
[Bug preprocessor/14934] the assumed dependency target isn't always right
--- Comment #3 from tromey at gcc dot gnu dot org 2007-02-09 00:57 --- I've thought about this more and I think that closing it is best. Please reopen (with a reason :-) if you disagree. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14934
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #17 from paolo at gcc dot gnu dot org 2007-02-09 01:00 --- Subject: Bug 17012 Author: paolo Date: Fri Feb 9 01:00:25 2007 New Revision: 121735 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121735 Log: 2007-02-08 Howard Hinnant [EMAIL PROTECTED] PR libstdc++/17012 * include/bits/list.tcc (list::remove): Take care of *__first == __value. * docs/html/ext/howto.html: Add an entry for DR 526. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/docs/html/ext/howto.html trunk/libstdc++-v3/include/bits/list.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug c++/30637] The options -fno-unit-at-a-time and -finline-functions generates erroneous code
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-02-09 01:16
---
The bug has nothing to do with -fno-unit-at-a-time.
(It is ignored for C++ anyways.)
The bug is fixed since GCC 4.0.0.
Btw, here's a shorter self-contained program that hangs when compiled with
g++ -O -finline-functions by GCC 3.4.x:
struct A
{
virtual void FOO() {}
};
struct B
{
A* p;
B() : p(new A) {}
A* foo();
void bar();
};
A* B::foo()
{
return p;
}
void B::bar()
{
foo()-FOO();
}
int main()
{
B().bar();
return 0;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30637
[Bug c++/28705] [4.1Regression] ICE: in type_dependent_expression_p, at cp/pt.c:12837
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-02-09 01:30 --- This problem is a regression that is not fixed on the 4.1 branch yet. Or is there a reason not to backport the fix? -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.0/4.1/4.2 Regression]|[4.1Regression] ICE: in |ICE: in |type_dependent_expression_p, |type_dependent_expression_p,|at cp/pt.c:12837 |at cp/pt.c:12837| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28705
[Bug c++/30425] [4.0/4.1 Regression] ICE in type_dependent_expression_p, at cp/pt.c:12739
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-02-09 01:31 --- *** This bug has been marked as a duplicate of 28705 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30425
[Bug c++/28705] [4.1Regression] ICE: in type_dependent_expression_p, at cp/pt.c:12837
--- Comment #7 from reichelt at gcc dot gnu dot org 2007-02-09 01:31 --- *** Bug 30425 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28705
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #41 from mmitchel at gcc dot gnu dot org 2007-02-09 02:53 --- Subject: Bug 29487 Author: mmitchel Date: Fri Feb 9 02:52:53 2007 New Revision: 121738 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121738 Log: PR target/29487 * tree.h (DECL_REPLACEABLE_P): New macro. * except.c (set_nothrow_function_flags): Likewise. PR target/29487 * decl.c (finish_function): Use DECL_REPLACEABLE. * tree.c (cp_cannot_inline_tree_fn): Likewise. PR c++/29487 * g++.dg/eh/weak1-C: New test. * g++.dg/eh/weak1-a.cc: Likewise. * g++.dg/eh/comdat1.C: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/comdat1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/weak1-a.cc branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/weak1.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/tree.c branches/gcc-4_1-branch/gcc/except.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug c/30741] New: Error when trying to compile under DOS on a Vista machine
I installed DJGPP on my new laptop running Vista. When I type gcc filename.c I get the following error: C:\DJGPP\gcc410b\binGCC PROG1.C gcc.exe: Internal error: (null) (program cc1plus) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. I'm a hardware engineer taking my first C class andI have no idea what this means. This program compiles and runs fine on my XP machine as well as on my WIN2000 machine. Is this related to Vista or is it possible I didn't install DJGPP correctly? -- Summary: Error when trying to compile under DOS on a Vista machine Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ggiordano at verizon dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30741
[Bug c/30741] Error when trying to compile under DOS on a Vista machine
--- Comment #1 from dj at redhat dot com 2007-02-09 03:10 --- For starters, gcc is case sensitive. When you passed it PROG1.C instead of prog1.c, you're telling it to compile a C++ program. Did you install the C++ compiler? Do you get the same error if you use prog1.c instead of PROG1.C ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30741
[Bug libgcj/30647] build of gcc midi-dssi fails
--- Comment #6 from grgoffe at yahoo dot com 2007-02-09 03:34 --- Subject: Re: build of gcc midi-dssi fails Tom, I figured it out and have been running the build -j 5 since after the email. I'll let you know when I get in tomorrow. I'm on the West coast, fyi. Thanks, George... --- tromey at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from tromey at gcc dot gnu dot org 2007-02-09 00:51 --- Sorry, I didn't make that patch at the top level. cd top/libjava/classpath, then apply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30647 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. = _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/ _/_/_/_/ _/_/_/_/ - _/ _/ _/_/ _/_/ _/ _/ _/ _/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ - _/_/ _/ _/_/ _/ _/ _/_/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/ - It's not what you know that hurts you, It's what you know that ain't so. Will Rogers 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30647
[Bug c/30741] Error when trying to compile under DOS on a Vista machine
--- Comment #2 from ggiordano at verizon dot net 2007-02-09 03:42 --- Subject: Re: Error when trying to compile under DOS on a Vista machine That was it. I thought I'd been mixing case all along and that it didn't matter under DOS but apparantly I'm mistaken. Now, it won't recognize stdio.h. I think this is an install problem. I wish there was a simpler install of gcc instead of this DJGPP. Thanks. From: dj at redhat dot com [EMAIL PROTECTED] Date: 2007/02/08 Thu PM 09:10:36 CST To: [EMAIL PROTECTED] Subject: [Bug c/30741] Error when trying to compile under DOS on a Vista machine --- Comment #1 from dj at redhat dot com 2007-02-09 03:10 --- For starters, gcc is case sensitive. When you passed it PROG1.C instead of prog1.c, you're telling it to compile a C++ program. Did you install the C++ compiler? Do you get the same error if you use prog1.c instead of PROG1.C ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30741
[Bug libgcj/30742] New: ResourceBundle regression
ResourceBundle on svn head has a regression. It doesn't find the correct class loader from the stack. I'll attach a test case. To see the bug: cd Fail gij -cp main.jar F -- Summary: ResourceBundle regression Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30742
[Bug libgcj/30742] ResourceBundle regression
--- Comment #1 from tromey at gcc dot gnu dot org 2007-02-09 03:58 --- Created an attachment (id=13024) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13024action=view) bug tar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30742
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-09 04:10 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: --- Comment #15 from dominiq at lps dot ens dot fr 2007-02-08 22:25 --- I think there is definitively a problem with the as provided on MacIntel. If you are interested I can dig my archives, I think I have some trace of the problem. Unfortunately I have only a limited access to a MacIntel machine. Thank you, but I think MacIntel is officially unsupported with 4.1. Tant pis. I'll use the Linux box to further investigate the problem there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #5 from P dot Schaffnit at access dot rwth-aachen dot de 2007-02-09 07:44 --- Hi! This is great! I cannot judge how much work this would be, but would it be possible to extend this patch a little further so that these backtraces can be requested by the user? (i.e. like the service routines 'ERRTRA' from Lahey, 'TRACEBACKQQ' from Digital|Compaq|HP|Intel or 'Trace_Back_Stack_and_Print' from SGI). This way it can also be used for user error handling... Thanks! Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
