--- Comment #7 from chrbr at gcc dot gnu dot org 2007-10-31 07:56 ---
Subject: Bug 19531
Author: chrbr
Date: Wed Oct 31 07:55:46 2007
New Revision: 129792
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129792
Log:
fix PR c++/19531: NRV is performed on volatile temporary
Added:
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-10-31 07:24
---
Fixed on mainline.
Probably by the patch for PR31993 and PR32252.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hailijuan at gmail dot com 2007-10-31 07:20 ---
invalid testcase.
--
hailijuan at gmail dot com changed:
What|Removed |Added
Status|UNCONF
--- Comment #8 from hailijuan at gmail dot com 2007-10-31 07:18 ---
Subject: Re: gfortran: incorrect output for array of dynamic bounds
running a.out compiled with -fbounds-check and then get following message:
micro# ./a.out
Fortran runtime error: Array reference out of bounds for arr
--- Comment #7 from kargl at gcc dot gnu dot org 2007-10-31 06:50 ---
(In reply to comment #6)
> Subject: Re: gfortran: incorrect output for array of dynamic bounds
>
> not like that. it's right to use a(j,i) which has j as lower dimension.
> memory layout of array(0:2, 0:1) is like:
>
--- Comment #6 from hailijuan at gmail dot com 2007-10-31 06:17 ---
Subject: Re: gfortran: incorrect output for array of dynamic bounds
not like that. it's right to use a(j,i) which has j as lower dimension.
memory layout of array(0:2, 0:1) is like:
a(0,0), a(1,0), a(2,0), a(0,1), a(1,
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-10-31 06:07
---
You have the array indexes reversed:
a(j,i)= i+j should be a(i,j) = i+j
To keep your references within the bounds of the array you defined. Use
-fbounds-check as Steve pointed out and you will get an
--- Comment #1 from eric dot niebler at gmail dot com 2007-10-31 05:56
---
Created an attachment (id=14446)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14446&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33955
--- Comment #4 from kargl at gcc dot gnu dot org 2007-10-31 05:56 ---
(In reply to comment #3)
>
> exactly! but why gfortran does that? is that permitted by fortran
> standards? thanks a lot.
See my previous comment. Your program is invalid Fortran. A Fortran
compiler can do anything
Compile the attached preprocessed file with "g++ -std=c++0x -c -x c++ bug.i".
The compiler ICEs. Seems to be a problem with template varargs.
This is with the latest g++, built from svn on 10/30/2007, with some patches
from Doug Gregor for various problems.
--
Summary: internal compi
--- Comment #3 from hailijuan at gmail dot com 2007-10-31 05:46 ---
Subject: Re: gfortran: incorrect output for array of dynamic bounds
exactly! but why gfortran does that? is that permitted by fortran
standards? thanks a lot.
31 Oct 2007 04:01:08 -, jvdelisle at gcc dot gnu dot o
--- Comment #2 from kargl at gcc dot gnu dot org 2007-10-31 04:08 ---
First, your program is not a valid Fortran program, so gfortran can do whatever
it wants with the code. Second, add -fbounds-check to your compiler options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954
--- Comment #26 from amodra at bigpond dot net dot au 2007-10-31 04:03
---
I believe the linker is correct to reject relocations against local symbols in
discarded sections. The reason being that the linker allows linkonce (and
comdat group) section contents to differ between two files
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-10-31 04:01
---
gfortran does not initialize bigarray for you, so you get what is in memory
there at the moment.
If I set bigarray = 0. I get:
0.000 0.000 0.000 0.000 0.000
0.00
--- Comment #13 from patchapp at dberlin dot org 2007-10-31 04:00 ---
Subject: Bug number PR33162
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-10/msg01855.html
--
http://gcc.gnu.org/bugzilla/s
the testcase is minimized as file d.f90:
SUBROUTINE sub(a, n)
REAL a(2:, 3:)
DO i=2, n+1
DO j=3, n+2
a(j,i)= i+j
ENDDO
ENDDO
RETURN
END
PROGRAM test
INTERFACE
--- Comment #16 from sebpop at gmail dot com 2007-10-31 01:13 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
Testing a fix.
--- Comment #17 from sebpop at gmail dot com 2007-10-31 01:13 ---
Created an attachment (id=14445)
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2007-10-31
00:44 ---
Then perhaps I ought to explain what I'm using -Wfatal-errors for.
I wrote an IRC bot called geordi ( http://www.eelis.net/geordi ) that accepts
lines of C++ code, compiles them with g++, and either rep
--- Comment #1 from bero at arklinux dot org 2007-10-31 00:42 ---
Created an attachment (id=1)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=view)
bzip2-ed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33953
$ gcc -O3 -c drawgfx.i
src/emu/drawgfx.c: In function 'blockmove_NtoN_blend_noremap32':
src/emu/drawgfx.c:4760: internal compiler error: vector VEC(tree,base) index
domain error, in vectorizable_operation at tree-vect-transform.c:4017
Please submit a full bug report,
with preprocessed source if app
--- Comment #7 from pcarlini at suse dot de 2007-10-31 00:07 ---
For concreteness would be something like the below (you can try it out, but
consider that the underlying sequence container "emplace" push_back are not
implemented yet, therefore expect only backward compatibility with C++0
--- Comment #6 from pcarlini at suse dot de 2007-10-30 23:56 ---
You are right. I'm investigating the issue with the help of knowledgeable
people in this area, we should be able to resolve it rather quickly. A possible
"solution", which would essentially render the issue moot, is replaci
--- Comment #5 from a dot chavasse at gmail dot com 2007-10-30 23:51
---
Well, I did notice that the library was conforming to n2369, but I have really
no idea otherwise about this - except that it did break the compilation of some
really straightforward and innocent looking code of min
--- Comment #4 from pcarlini at suse dot de 2007-10-30 23:28 ---
Actually, I don't know. Definitely the library is conforming to n2369, but
maybe something is wrong in the specifications of the two push. I'm going to
investigate that, let's tentatively consider this as a library issue, b
--- Comment #18 from dominiq at lps dot ens dot fr 2007-10-30 23:25 ---
> (SIGN_* is a bit of a lousy naming, but I don't have any better idea)
what about GFC_* ? However I wonder about possible conflicts with user defined
operator. Is that so difficult to parse ==, /=, <=, and =>?
--
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-10-30 23:20
---
For other operators, ie .eqv., we output them as the simple EQV string (without
the dots). What about outputting the troublesome operators into simple
alphanumeric strings, like SIGN_EQ for ==, SIGN_NE for /=, SI
--- Comment #16 from dominiq at lps dot ens dot fr 2007-10-30 23:10 ---
If I replace <= by == or /=, the error becomes:
Fatal Error: Reading module foo at line 21 column 16: find_enum(): Enum not
found
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33941
--- Comment #15 from dominiq at lps dot ens dot fr 2007-10-30 23:07 ---
Sorry, but the Tobias' patch is not enough. With the full test I get now:
Fatal Error: Reading module m_common_attrs at line 120 column 55: Expected left
parenthesis
line 120 reads:
INTEGER ()) 0 '0')) (OP (LOGICA
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-30 22:42 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2007-10-30 22:41 ---
Fixed so far on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #5 from jakub at gcc dot gnu dot org 2007-10-30 22:40 ---
Subject: Bug 33709
Author: jakub
Date: Tue Oct 30 22:40:13 2007
New Revision: 129785
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129785
Log:
PR c++/33709
* fold-const.c (fold_binary): If one
--- Comment #4 from jakub at gcc dot gnu dot org 2007-10-30 22:38 ---
Subject: Bug 33616
Author: jakub
Date: Tue Oct 30 22:37:53 2007
New Revision: 129784
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129784
Log:
PR c++/33616
* decl2.c (build_offset_ref_call_fro
--- Comment #8 from dhowells at redhat dot com 2007-10-30 22:28 ---
Seems to work for me. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28583
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-30 22:21 ---
Well the second error: really should be notes. But really this is doing what
-Wfatal-errors is designed to do. -Wfatal-errors is really was only designed
to help out reducing testcases and nothing else.
--
htt
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-30 22:20
---
(In reply to comment #8)
> Subject: Bug number PR33749
>
> 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-10/msg01237.ht
Consider:
int main () { goto foo; { int i = 0; foo:; } }
Compiling this snippet /without/ -Wfatal-errors produces:
t.cpp: In function âint main()â:
t.cpp:1: error: jump to label âfooâ
t.cpp:1: error: from here
t.cpp:1: error: crosses initialization of âint iâ
Compiling
--- Comment #14 from patchapp at dberlin dot org 2007-10-30 22:15 ---
Subject: Bug number PR33897
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-10/msg01694.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #8 from patchapp at dberlin dot org 2007-10-30 22:15 ---
Subject: Bug number PR33749
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-10/msg01237.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-10-30 21:48
---
Subject: Bug 33596
Author: fxcoudert
Date: Tue Oct 30 21:48:23 2007
New Revision: 129782
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129782
Log:
PR fortran/33596
* trans-intrinsic.c (g
--- Comment #20 from reichelt at gcc dot gnu dot org 2007-10-30 20:30
---
Subject: Bug 32500
Author: reichelt
Date: Tue Oct 30 20:30:47 2007
New Revision: 129781
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129781
Log:
PR tree-optimization/32500
* gcc.c-tortur
--- Comment #19 from reichelt at gcc dot gnu dot org 2007-10-30 20:29
---
Subject: Bug 32500
Author: reichelt
Date: Tue Oct 30 20:29:22 2007
New Revision: 129780
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129780
Log:
PR tree-optimization/32500
* gcc.c-tortur
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-30 20:07 ---
You are missing the part about argument dependent lookup.
With the namespace, only the first display is looked at since the "bad" class
is not in the global namespace.
The late works because all of the display's a
--- Comment #1 from mpeuser at sandel dot com 2007-10-30 19:47 ---
Created an attachment (id=14443)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14443&action=view)
The preprocessor output of the code that generates the compiler error.
Here is the preprocessor output file.
--
I have run into a compiler error with gcc 4.x that I am trying to understand
whether my code is wrong or the compiler has a bug.
FYI: 4.1.2 is shown in the compiler output below, but I have had the same
results with 4.2.1. The problem does not occur with gcc 3.4.1, 3.4.4, Borland
5.5, and Visual S
--- Comment #14 from patchapp at dberlin dot org 2007-10-30 19:40 ---
Subject: Bug number PR33941
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-10/msg01832.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #25 from hjl at lucon dot org 2007-10-30 19:37 ---
Basically, you can't have a non-comdat section references a local symbol
in a comdat section.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #24 from hjl at lucon dot org 2007-10-30 19:36 ---
(In reply to comment #23)
> Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
> discarded section
>
> On 30/10/2007, at 12:12 PM, hjl at lucon dot org wrote:
>
> > The problem is "typeinfo for (anony
--- Comment #23 from geoffk at geoffk dot org 2007-10-30 19:32 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 12:12 PM, hjl at lucon dot org wrote:
> The problem is "typeinfo for (anonymous namespace)::t" in .rodata
>
--- Comment #3 from pcarlini at suse dot de 2007-10-30 19:31 ---
If something (I doubt so, could only be a defect in n2369), this is a C++
issue, because the implementation in the library is totally trivial, identical
to the specifications.
--
pcarlini at suse dot de changed:
--- Comment #22 from hjl at lucon dot org 2007-10-30 19:12 ---
The problem is "typeinfo for (anonymous namespace)::t" in .rodata section
references "typeinfo name for (anonymous namespace)::t" in a comdat section.
When the comdat section is discarded, we got a problem. Can we put
"typein
--- Comment #21 from geoffk at geoffk dot org 2007-10-30 19:04 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 11:44 AM, rguenther at suse dot de wrote:
> I see. So where is the bug here? We obviously see application
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-10-30 18:50
---
I guess re-evaluating if this is a binutils bug then is required? Do we also
need
to bump the minimal binutils version requirement for 4.3 if so?
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #19 from rguenther at suse dot de 2007-10-30 18:44 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in
... defined in discarded section
On Tue, 30 Oct 2007, geoffk at geoffk dot org wrote:
> On 30/10/2007, at 11:07 AM, rguenth at gcc dot gnu dot org wrote:
>
>
--- Comment #13 from dominiq at lps dot ens dot fr 2007-10-30 18:43 ---
> Well, the patch which exactly does in code what you said in words
> is the following:
Obviously, I would have forgotten "/"! Is not it a good candidate for the
"obvious" rule?
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from dean at arctic dot org 2007-10-30 18:43 ---
apparently the approved intrinsics for the "movq xmm,m64" / "movq m64,xmm"
instructions are _mm_loadl_epi64 and _mm_storel_epi64. i've asked intel to add
these to the ISA documentation because they're missing at the moment.
--- Comment #18 from geoffk at geoffk dot org 2007-10-30 18:35 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 11:07 AM, rguenth at gcc dot gnu dot org wrote:
> --- Comment #16 from rguenth at gcc dot gnu dot org 2
--- Comment #17 from geoffk at geoffk dot org 2007-10-30 18:31 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 30/10/2007, at 9:53 AM, gcc at magfr dot user dot lysator dot liu
dot se wrote:
>>> If that is the case, what should type
--- Comment #6 from aldot at gcc dot gnu dot org 2007-10-30 18:26 ---
Fixed for 4.3.0
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #1 from ralgith at gmail dot com 2007-10-30 18:23 ---
Or be considered non-local, but NOT generate the warning. This is a fairly
common coding convention, and this warning keeps jumping up and down at me in
several programs I've compiled.
--
ralgith at gmail dot com chang
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-30 18:07
---
Geoff, your patch changed the typeinfo symbols for anonymous namespaces from
having weak linkage to non-weak linkage. This caused the regression. Do you
argue this change was deliberate and is the right thing? W
--- Comment #6 from sebpop at gmail dot com 2007-10-30 17:59 ---
Subject: Re: not vectorized: can't determine dependence (array sections)
I would like to keep the two bugs, PR32375 and PR32378, open as we can
vectorize them without having to version the code.
--
http://gcc.gnu.org
--- Comment #5 from janis at gcc dot gnu dot org 2007-10-30 17:54 ---
Fixed.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-30
17:47 ---
Subject: Re: INIT_PRIORITY is broken
> Would you please try this patch?
I'll give it a try when I get home tonight.
Thanks,
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33579
--- Comment #5 from spop at gcc dot gnu dot org 2007-10-30 17:36 ---
Subject: Re: not vectorized: can't determine dependence (array sections)
> The testcase gets vectorized even with the failed dependence test.
>
This is okay. The test for non-dependence is added to the run-time
cond
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-30 17:29 ---
There is no reason why the back-end is adding atrributes instead of modifying
the FUNCTION_DECL itself.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from burnus at gcc dot gnu dot org 2007-10-30 17:27 ---
(In reply to comment #11)
> The use of '<', '>', and '=' has been introduced in revision 126468. However
> looking at proc parse_atom in gcc/fortran/module.c, they do not seem to be in
> the recognized character set.
--- Comment #4 from spop at gcc dot gnu dot org 2007-10-30 17:01 ---
Subject: Re: not vectorized: can't determine dependence (array sections)
On 1 Jul 2007 12:46:31 -, dorit at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> (dependence classified: scev_not_known)
>
I still see t
--- Comment #15 from gcc at magfr dot user dot lysator dot liu dot se
2007-10-30 16:53 ---
I agree that the linker should not drop the typeinfo when it is needed.
I could just tell that I see the problem on Linux so it isn't Darwin-specific.
> > Should the typeinfo for an anonymous na
--- Comment #4 from zero at colonel-panic dot org 2007-10-30 16:45 ---
Subject: Re: gcc-4.2.2 generates bad code on ARM
rguenth at gcc dot gnu dot org wrote:
> --- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-30 15:54
> ---
> It doesn't matter that you store the add
--- Comment #11 from dominiq at lps dot ens dot fr 2007-10-30 16:45 ---
The use of '<', '>', and '=' has been introduced in revision 126468. However
looking at proc parse_atom in gcc/fortran/module.c, they do not seem to be in
the recognized character set.
--
http://gcc.gnu.org/bugz
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-10-30 16:34
---
Created an attachment (id=14442)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14442&action=view)
patch
David --
Would you please try this patch? I have lightly tested this on a hacked-up x86
configuration
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
In the first case below, a warning should be emitted just the same as the
second case... Types other than character are not affected, because for them
the middle-end will do the job anyway.
$ cat s.f90
function pop() result(item)
character(len=0) :: item
end function pop
$ gfortran s.f90 -c
$ ca
--- Comment #1 from pcarlini at suse dot de 2007-10-30 16:24 ---
Seems just matter of calling pp_cxx_statement...
--
pcarlini at suse dot de changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Ke
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-10-30 16:23
---
Further reduced:
module foo
contains
function pop(n) result(item)
integer :: n
character(len=merge(0, 0, n > 0)) :: item
end function pop
end module foo
program test
use foo
end program
--
fxc
--- Comment #7 from pcarlini at suse dot de 2007-10-30 16:10 ---
Really, not a bug.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-30 15:54 ---
It doesn't matter that you store the address of param to a volatile variable
(this store is not removed), but that
DMA_ADDR_REG = (unsigned long) data;
does not make the stack local live longer than t
--- Comment #2 from zero at colonel-panic dot org 2007-10-30 15:31 ---
Subject: Re: gcc-4.2.2 generates bad code on ARM
rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-30 14:31
> ---
> huh? you initialize DMA_ADDR_REG to the
--- Comment #9 from dominiq at lps dot ens dot fr 2007-10-30 14:50 ---
Reduced test case:
module m_common_elstack
implicit none
private
! Simple stack to keep track of which elements have appeared so far
! Initial stack size:
integer, parameter :: STACK_SIZE_INIT = 10
! M
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-30 14:31 ---
huh? you initialize DMA_ADDR_REG to the address of param (which is on the
stack).
The initialization of the contents of param is unused and as such dropped
(but due to -fno-strict-aliasing the compiler assumes it es
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-30 14:28 ---
I have tried what icedtea javac does on such *.java files and it apparently
exits with 0 exit status, but doesn't create any *.class file. So I guess
silently creating empty *.s (i.e. just ignore not being able to fin
--- Comment #8 from dominiq at lps dot ens dot fr 2007-10-30 14:15 ---
Comparing the working mod file to the non working one, I have found that "GT"
was replaced by ">" and "LE" by "<=". I ignored the warning "If you edit this,
you'll get what you deserve." and did the changes in the non
GCC generates incorrect code for the following C code in both ARM and Thumb
modes. The initialisation of param[0] is performed in the wrong leg of the if()
statement, consequently the assignemnt to DMA_ADDR_REG uses an uninitialised
value. Command line, compiler specs and object dump are included b
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-30 14:03 ---
Actually, that would need to be for f in $$objects; do echo $$f; done | xargs
$(AR_FOR_TARGET) $@
Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-30 14:01 ---
Untested patch that could help:
--- libgcc/Makefile.in 2007-09-28 08:29:29.0 +0200
+++ libgcc/Makefile.in 2007-10-30 14:55:38.0 +0100
@@ -1,6 +1,6 @@
# Makefile.in
-# Copyright (C) 2005, 2006 Free S
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-10-30 13:45 ---
Fixed.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-10-30 13:44 ---
Fixed.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-10-30 13:37 ---
Subject: Bug 32252
Author: dgregor
Date: Tue Oct 30 13:36:34 2007
New Revision: 129773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129773
Log:
2007-10-30 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-10-30 13:37 ---
Subject: Bug 31993
Author: dgregor
Date: Tue Oct 30 13:36:34 2007
New Revision: 129773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129773
Log:
2007-10-30 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #4 from jakub at gcc dot gnu dot org 2007-10-30 13:30 ---
Subject: Bug 33723
Author: jakub
Date: Tue Oct 30 13:29:57 2007
New Revision: 129772
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129772
Log:
PR tree-optimization/33723
* gcc.dg/tree-ssa/pr33
--- Comment #4 from rguenther at suse dot de 2007-10-30 13:24 ---
Subject: Re: [4.3 Regression] Type verification failure with
new expression
On Tue, 30 Oct 2007, jakub at gcc dot gnu dot org wrote:
> --- Comment #3 from jakub at gcc dot gnu dot org 2007-10-30 13:12 ---
> Te
--- Comment #3 from jakub at gcc dot gnu dot org 2007-10-30 13:12 ---
Testing a fix:
--- gcc/fold-const.c.jj2007-10-19 14:39:55.0 +0200
+++ gcc/fold-const.c2007-10-30 14:09:39.0 +0100
@@ -9504,12 +9504,15 @@ fold_binary (enum tree_code code, tree t
if (
--- Comment #7 from dominiq at lps dot ens dot fr 2007-10-30 13:06 ---
I see the failure for the FOX-3.0 tarball with both revisions 129038 and
129734.
Note that the make succeeds with gfortran 4.2.2. So this seems to be a 4.3
regression, but not a really recent one.
--
http://gcc.g
--- Comment #15 from paolo at gcc dot gnu dot org 2007-10-30 13:05 ---
Subject: Bug 33815
Author: paolo
Date: Tue Oct 30 13:05:26 2007
New Revision: 129769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129769
Log:
2007-10-19 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #5 from dir at lanl dot gov 2007-10-30 12:58 ---
Hi Jerry,
Thanks for looking at the problem. I am actually having several failures
with GFORTRAN on CYGWIN and MSYS (All, I/O problems perhaps). This was the
first that I was able to isolate. I am hoping that the o
--- Comment #6 from tow21 at cam dot ac dot uk 2007-10-30 12:23 ---
So much for trying to cut down the testcase.
To replicate the bug
wget http://source.uszla.me.uk/FoX/FoX-3.0.tgz && \
tar xzf FoX-3.0.tgz && cd FoX-3.0 && \
./configure && make
(or if you have gfortran installed somew
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-30 12:07 ---
The make in the tar file fails with:
m_common_error.f90:4.35:
use pxf, only: pxfabort, pxfflush
1
Fatal Error: Can't open module file 'pxf.mod' for reading at (1): No such file
or
1 - 100 of 115 matches
Mail list logo
