--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-22 07:35
---
(In reply to comment #3)
> So, on MinGW, you should --disable-werror.
I can understand the why, but I don't think it should be required (because that
means other warnings will not be spotted). And anyway, it shou
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 25069
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2005-12-22 07:06 ---
Subject: Bug 25307
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 23152
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #9 from pault at gcc dot gnu dot org 2005-12-22 07:06 ---
Subject: Bug 25068
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 25053
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:06 ---
Subject: Bug 25067
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 25064
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 25066
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 20864
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 20862
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 25063
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #14 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 20244
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #3 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 21256
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 25391
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 25029
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 20889
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2005-12-22 07:05 ---
Subject: Bug 19362
Author: pault
Date: Thu Dec 22 07:05:22 2005
New Revision: 108943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108943
Log:
2005-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25529
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25530
Testcase:
int f(unsigned t)
{
return (t/2)*2;
}
---
This is done in combine stage on the RTL level.
--
Summary: (unsigned / 2)*2 is not changed into unsigned &1
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimizatio
Testcase:
int f1(unsigned t)
{
return (t*2)/2;
}
This is done in combine on the RTL level.
--
Summary: (unsigned * 2)/2 is not changed into unsigned
&0x7FFF
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords
--- Comment #22 from ghazi at gcc dot gnu dot org 2005-12-22 04:55 ---
Subject: Bug 20772
Author: ghazi
Date: Thu Dec 22 04:55:18 2005
New Revision: 108942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108942
Log:
PR testsuite/20772
* g++.dg/abi/bitfield3.C, g++
Take the following code:
int f(void)
{
static _Complex double t;
int i, j;
for(i = 0;i<2;i++)
for(j = 0;j<2;j++)
t *= .5 * 1.0;
return t;
}
---
At -O1, we get on the tree level for the loop:
:;
CI.33 = IMAGPART_EXPR * 5.0e-1;
REALPART_EXPR = REALPART_EXPR * 5.0e-1;
IMAGP
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-22 04:43 ---
I see this with -fno-automatic in a benchmark.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from kazu at gcc dot gnu dot org 2005-12-22 04:06 ---
Oops, I forgot to change resolution to FIXED.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from kazu at gcc dot gnu dot org 2005-12-22 04:04 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Target Milesto
--- Comment #5 from kazu at gcc dot gnu dot org 2005-12-22 04:03 ---
Subject: Bug 23518
Author: kazu
Date: Thu Dec 22 04:03:32 2005
New Revision: 108940
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108940
Log:
gcc/
PR tree-optimization/23518
* fold-const.c (mak
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-12-22 03:56
---
The second testcase now crashes (4.0 branch, 4.1 branch, and mainline).
This is due to PR 25364.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-12-22 03:37
---
Confirmed. Reduced testcase:
template struct A
{
struct X;
};
template struct B : A
{
friend struct X;
struct X {};
};
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-22 03:32 ---
This also blocks building benchs_F95.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2005-12-22 02:32
---
Subject: Bug 25307
Author: jvdelisle
Date: Thu Dec 22 02:32:29 2005
New Revision: 108938
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108938
Log:
2005-12-21 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2005-12-22 02:08
---
Ran some test cases. The second example in Comment #3 fails. With or without
FX patch given in Comment #6
At line 10 of file back3.f
Fortran runtime error: Read past ENDFILE record
Dale, are you getting this?
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2005-12-22 01:18
---
This is great! I have regression tested and NIST tested on i686 and all pass.
I have not tried some of the problem cases yet, but will do later tonight.
I was just getting ready to start working on this one an
--- Comment #2 from dev at stuffit dot at 2005-12-21 23:59 ---
svn revision 108861 of gomp-20050608-branch, i should probably add!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25527
--- Comment #1 from dev at stuffit dot at 2005-12-21 23:55 ---
Created an attachment (id=10547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10547&action=view)
Sample Code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25527
code works just fine if compiled with g++-4.2.0 --openmp but dies a horrible
death if you -02
valgrind output:
[EMAIL PROTECTED] ~/tmp $ valgrind ./test
==31611== Memcheck, a memory error detector.
==31611== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==31611== Using LibVEX rev
--- Comment #2 from joseph at codesourcery dot com 2005-12-21 23:27 ---
Subject: Re: libstdc++ headers should go in multilib
directories
On Wed, 21 Dec 2005, gdr at integrable-solutions dot net wrote:
>
>
> --- Comment #1 from gdr at integrable-solutions dot net 2005-12-21 23:
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-21 23:23
---
Subject: Re: New: libstdc++ headers should go in multilib directories
"jsm28 at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Some libstdc++ headers are installed in GPLUSPLUS_TOOL_INCLUDE_DIR, i.e.
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-21 22:54 ---
GCC is correct:
const PTR mycast(const A *a) {
return (static_cast(a));
a is a pointer to a const A. While the cast you are trying to use is a
constant pointer to B. And that is invalid C++ to use static_cast t
The following code produces 'casting away constness' error on 'static_cast'
line. Should be no warning.
- code ---
struct A { };
struct B : A { };
template
const PTR mycast(const A *a) {
return (static_cast(a));
}
const B* mycast(const A *a) {
return (mycast(
Some libstdc++ headers are installed in GPLUSPLUS_TOOL_INCLUDE_DIR, i.e.
include/c++/version/target. These headers are derived from information
configured separately for each multilib, and in general may differ between
multilibs, so should go in a multilib directory (e.g.
include/c++/version/targe
hello !
first of all, this is the source code that make the compiler crash.
www.evald80.altervista.org/bug.rar
I have try this on win and linux distro and on both i get a internal compiler
error: Segmentation fault.
win so has gcc 3.3.3 and linux distro slackware has gcc 3.3.4
Regards.
--
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2005-12-21 22:14
---
(In reply to comment #16)
> When, I try the "check-gfortran" in the directory 'gcc' where I did the
> configure,make -j 4,make install, I get
Dale, you should really stop building your compiler inside the source
== Please reply above this line ==
gcc-bugs@gcc.gnu.org,
Your ticket has been submitted to our Technical Support department, one of the
staff members will review it and reply accordingly. Listed below are details of
this ticket, you will need to use the ticket key listed below to update
--- Comment #16 from dir at lanl dot gov 2005-12-21 21:43 ---
I down loaded gfortran and built it on the Macintosh with -
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
cd gcc
configure --prefix=/Users/dir/gfortran --enable-languages=c,f95
make -j 4
make install
When, I try the "c
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-12-21 20:26
---
> This might be the last one...
Victory! sparc-sun-solaris2.5.1 is alive again. :-) Thanks a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
--- Comment #15 from kargl at gcc dot gnu dot org 2005-12-21 20:21 ---
(In reply to comment #14)
> I tried to run the
> fortran testsuite with "make check-gfortran", but check-gfortran is not
> in the
> makefile. It would be nice if just fortran testsuite could be run.
>
Dale, move int
--- Comment #3 from nomis80 at nomis80 dot org 2005-12-21 20:07 ---
This is not fixed as of 4.1.0. Can someone with enough karma reopen either this
bug or #17251 ? Thanks!
--
nomis80 at nomis80 dot org changed:
What|Removed |Added
-
--- Comment #4 from jsm28 at gcc dot gnu dot org 2005-12-21 19:54 ---
In addition to the listed C failures, this is probably also responsible for the
C++ regressions
FAIL: g++.dg/opt/mmx2.C (test for excess errors)
FAIL: g++.dg/other/mmintrin.C (test for excess errors)
appearing at the
--- Comment #3 from gdr at integrable-solutions dot net 2005-12-21 19:54
---
Subject: Re: change semantics of const volatile variables
"drepper at redhat dot com" <[EMAIL PROTECTED]> writes:
| __attribute((section(".rodata.cst8"))). This will cause gcc to fail with an
| ICE.
That i
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-21 19:49 ---
Not working on this any more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from joseph at codesourcery dot com 2005-12-21 19:46 ---
Subject: Re: zero-initialized constants are place in
.bss
On Wed, 21 Dec 2005, pinskia at gcc dot gnu dot org wrote:
> Actually no, they are placed in the common section because of ANSI C rules.
There is no such
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-21 19:40 ---
I have a patch:
===
--- tree-dfa.c (revision 108920)
+++ tree-dfa.c (working copy)
@@ -216,6 +216,9 @@ tree
make_rename_temp (tree type, const char *
--- Comment #2 from drepper at redhat dot com 2005-12-21 19:38 ---
Using gcc's section attributes won't fully work either.
Using __attribute((section(".rodata"))) is OK in the compiler, although the
assembler (correctly) complaints. But what is really needed is
__attribute((section(".
--- Comment #14 from dir at lanl dot gov 2005-12-21 19:36 ---
After tracing the errors for a while, it became clean that "active" pointer
into the read/write buffer was not being correctly updated. Adding one line (
s->active=0; ) to the bottom of routine "fd_truncate" in file "unix.c" f
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-21 19:17
---
Subject: Re: New: change semantics of const volatile variables
"drepper at redhat dot com" <[EMAIL PROTECTED]> writes:
| In math code we often have to make sure the compiler does not fold operations
| at co
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-21 19:11 ---
If you really zero initialize them, you get them in the what you expect:
.section.rodata
.align 4
.type f, @object
.size f, 8
f:
.zero 8
-
Removing the cons
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-21 19:09 ---
.comm f,8,4
Actually no, they are placed in the common section because of ANSI C rules.
This is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Compile this code:
struct foo { int a, b; }
const struct foo f;
The compiler will mark the variable f in .bss instead of, as the const
indicates, into .rodata. This can be a security problem. In glibc we
deliberately use const wherever possible (as should everybody) to prevent
anybody from chan
In math code we often have to make sure the compiler does not fold operations
at compile time. In glibc we use variable declared as
static const volatile double foo = 42.0;
The problem is that gcc moves such variables into .data. But we could achieve
that easily by leaving out the 'const'. W
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-21 18:48 ---
(In reply to comment #8)
> I don't know whether GCC supports such target (if yes, you've
> potentially found a bug in GCC's implementation of total pointer
> ordering as required by the C++ standard)
My point was mo
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-21 18:40
---
Subject: Re: [4.1/4.2 Regression] Overflow not handled in ptr arithmetic
folding
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| One more thing, the comparision will fail with segmented memory
--- Comment #3 from pluto at agmk dot net 2005-12-21 18:30 ---
i suppose the lib.so and myexception's typeinfo is unavailable
after unwinding the try{} block (due to ~dll/dlclose) which is
a reason why the program crash. am i rigth?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=255
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-21 18:24 ---
One more thing, the comparision will fail with segmented memory targets like
x86 (when using the segment register).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25512
--- Comment #2 from pluto at agmk dot net 2005-12-21 18:02 ---
if I change the myexception definition to:
struct myexception : public std::exception {};
then testcase will crashe at all optimization levels on i386/amd64.
Program received signal SIGSEGV, Segmentation fault.
0xb7ef7a06
--- Comment #20 from jsm28 at gcc dot gnu dot org 2005-12-21 17:48 ---
Subject: Bug 24998
Author: jsm28
Date: Wed Dec 21 17:48:07 2005
New Revision: 108918
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108918
Log:
PR middle-end/24998
* config/arm/t-arm-elf (LIB1
--- Comment #19 from pbrook at gcc dot gnu dot org 2005-12-21 17:43 ---
Subject: Re: Patch for arm-none-linux-gnueabi build failure
> 2005-12-21 Joseph S. Myers <[EMAIL PROTECTED]>
>
> PR middle-end/24998
> * config/arm/t-arm-elf (LIB1ASMFUNCS): Add _floatundidf and
>
--- Comment #18 from joseph at codesourcery dot com 2005-12-21 17:39
---
Subject: Patch for arm-none-linux-gnueabi build failure
This patch fixes another piece of bug 24998, fallout from adding
__floatun*. Unlike the problems with missing functions, this is one
with duplicate functio
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-12-21 17:30 ---
> Finally, we don't have a policy that the opener of a PR has "more
> rights to close it", nor should we. We should be closing PRs on
> technical grounds.
I agree with that part.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from gdr at integrable-solutions dot net 2005-12-21 17:28
---
Subject: Re: [4.1/4.2 Regression] Overflow not handled in ptr arithmetic
folding
"gdr at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #4 from gdr at gcc dot gnu dot org 2005-12-21 17:2
--- Comment #10 from aph at gcc dot gnu dot org 2005-12-21 17:27 ---
I'd like to apply this patch to 4.0, but it's too different.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from gdr at gcc dot gnu dot org 2005-12-21 17:21 ---
(In reply to comment #3)
> Invalid as of 6.5.6/8
>
I don't think that paragraph explains why this is an
invalid PR.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-21 17:20 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-21 17:12 ---
Fixed on the mainline also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from gdr at integrable-solutions dot net 2005-12-21 17:05
---
Subject: Re: can't voidify __attribute__((warn_unused_result))
"mueller at kde dot org" <[EMAIL PROTECTED]> writes:
| ok, then, lets see if we can get this fixed in glibc.
good luck.
--
http://gcc.gn
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-21 16:59 ---
You should be using the Intel intrinsics by using {x,}mmintrin.h/mm3dnow.h.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-12-21 16:58 ---
lsm needs to special case handling of complex somehow, as we don't take complex
vars to ssa form (appearantly).
(gdb) call debug_generic_expr(stmt)
# t_lsm.21D.1571 = V_MUST_DEF ;
t_lsm.21D.1571 = __complex__ (5.0
In the "GCC online documentation" in the page entitled "5.45.5 X86 Built-in
Functions" the lines documenting the addsubps and addsubpd instructions are
listed as:
v2df __builtin_ia32_addsubpd (v2df, v2df)
v2df __builtin_ia32_addsubps (v2df, v2df)
The first line is correct as can be deduce
--- Comment #8 from aph at gcc dot gnu dot org 2005-12-21 16:52 ---
Subject: Bug 25121
Author: aph
Date: Wed Dec 21 16:52:13 2005
New Revision: 108914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108914
Log:
2005-12-21 Andrew Haley <[EMAIL PROTECTED]>
PR middle-end/
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-21 16:49 ---
The 4.1 branch I had meant.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Kn
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-21 16:46 ---
Should be fixed now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #14 from jakub at gcc dot gnu dot org 2005-12-21 16:45 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-21 16:44 ---
Subject: Bug 25518
Author: pinskia
Date: Wed Dec 21 16:44:09 2005
New Revision: 108912
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108912
Log:
2005-12-21 Andrew Pinski <[EMAIL PROTECTED]>
PR de
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25518
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-21 16:33 ---
Woops, mine. I think I forgot to move dwarf2out_switch_text_section out of the
#if.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
gcc -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED -D_INCLUDE__STDC_A1_SOURCE
-D_INCLUDE
_XOPEN_SOURCE_500 -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-defin
ition -Wmissing-format-attribute-DHAVE_CONFIG_H -o c
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-21 16:30 ---
Fixed on the mainline at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-21 16:27 ---
Confirmed, C testcase (compile at -O1):
int f(void)
{
static _Complex double t;
int i, j;
for(i = 0;i<2;i++)
for(j = 0;j<2;j++)
t = .5 * 1.0;
return t;
}
--
pinskia at gcc dot gnu dot org change
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-12-21 16:17
---
Fixed on trunk, 4.1 and 4.0
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from belyshev at depni dot sinp dot msu dot ru 2005-12-21
15:58 ---
Zdenek, ping!
Please apply patch for this bug to gcc-4_0-branch.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
---
--- Comment #13 from rakdver at gcc dot gnu dot org 2005-12-21 15:49
---
Subject: Bug 24793
Author: rakdver
Date: Wed Dec 21 15:49:19 2005
New Revision: 108910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108910
Log:
PR tree-optimization/24793
* tree-ssa-loop-
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-21 15:46 ---
Fixed on the trunk and on the GCC 4.1 branch.
See http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01177.html and
http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01178.html (I used the wrong bug
number in the commit >:-/)
Will ask
--- Comment #15 from steven at gcc dot gnu dot org 2005-12-21 15:45 ---
That's what you get for working on different GCSEs at the same time.
Those commits were for Bug 25196 :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-21 15:34 ---
Patch posted by Jakub.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2005-12-21 15:32 ---
Subject: Bug 25130
Author: steven
Date: Wed Dec 21 15:32:09 2005
New Revision: 108907
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108907
Log:
patch for PR rtl-optimization/25130, gcc 4.1 edition.
gcc/
--- Comment #13 from steven at gcc dot gnu dot org 2005-12-21 15:28 ---
Subject: Bug 25130
Author: steven
Date: Wed Dec 21 15:28:16 2005
New Revision: 108906
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108906
Log:
patch for PR rtl-optimization/25130
gcc/
* postreload
In cygwin platform, I got following internal compiler error.
$ gfortran --version
GNU Fortran 95 (GCC 4.1.0 20050522 (experimental))
Copyright (C) 2005 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
und
--- Comment #1 from pluto at agmk dot net 2005-12-21 14:57 ---
Created an attachment (id=10545)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10545&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25515
$ make clean all OPT=-Os
rm -rf *.ii *.o *.s lib.so main
g++ -Os lib.cpp -fPIC -shared -Wl,-soname,lib -o lib.so
g++ -Os main.cpp -o main -ldl
LD_LIBRARY_PATH=./ ./main
Memory fault
works fine with -O[0123].
$ g++ -v
Reading specs from /usr/lib64/gcc/amd64-pld-linux/3.4.5/specs
Configured with: .
1 - 100 of 121 matches
Mail list logo
