--- Comment #14 from razya at il dot ibm dot com 2007-10-30 09:14 ---
Subject: Re: [4.3 Regression] inlining miscompilation
"rguenther at suse dot de" <[EMAIL PROTECTED]> wrote on 29/10/2007
15:12:36:
>
>
> --- Comment #13 from rguenther at suse dot de 2007-10-29 13:12
--
On ARM I get a lot of gfortran testsuite failures because of "test for
excess errors". They are due to these warnings:
(sid)1109:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gfortran -c Wall.f90
Wall.f90:0: warning: 'const' attribute directive ignored
Wall.f90:0: warning: 'nothrow' attribute d
--- Comment #1 from tbm at cyrius dot com 2007-10-30 09:21 ---
See http://gcc.gnu.org/ml/gcc/2007-10/msg00748.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33947
--- Comment #12 from rguenther at suse dot de 2007-10-30 09:27 ---
Subject: Re: [4.3 Regression] ICE verify_ssa
failed (missing definition for SSA_NAME)
On Tue, 30 Oct 2007, dorit at il dot ibm dot com wrote:
> --- Comment #11 from dorit at il dot ibm dot com 2007-10-30 05:48 --
--- Comment #10 from irar at il dot ibm dot com 2007-10-30 10:09 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from irar at il dot ibm dot com 2007-10-30 10:10 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-30 10:36
---
(In reply to comment #2)
> At which point, one could have added the required tgammaf wrapper to
> c99_functions.c.
This issue (adding configure tests and float-variant wrappers) is PR33583. To
Michael: you can ei
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-30 10:36
---
*** Bug 33942 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33941
--- Comment #3 from tow21 at cam dot ac dot uk 2007-10-30 10:48 ---
Created an attachment (id=14439)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14439&action=view)
dependency of problem file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33941
--- Comment #4 from tow21 at cam dot ac dot uk 2007-10-30 10:55 ---
Created an attachment (id=14440)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14440&action=view)
test case for failure
Rather than uploading all the dependencies, here is a tarball. Unpack it, cd
into common/ and
I'm sorry to report yet another bootstrap breakage on mips-sgi-irix6.5. The
following testcase is reduced from lambda-code.c, which fails to compile at
stage 2:
$ cat foo.i
typedef struct {
int i, j;
} tree_stmt_iterator;
typedef struct {
tree_stmt_iterator tsi;
int bb;
} block_stmt_iterato
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-10-30 11:40
---
Created an attachment (id=14441)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14441&action=view)
Dumps from -fdump-tree-all
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33948
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-30 11:41
---
And I should have said this is revision 129739.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33948
--- Comment #3 from jakub at gcc dot gnu dot org 2007-10-30 11:56 ---
Testing:
--- gcc/cp/decl2.c.jj 2007-10-28 19:34:13.0 +0100
+++ gcc/cp/decl2.c 2007-10-30 12:52:35.0 +0100
@@ -3499,9 +3499,9 @@ build_offset_ref_call_from_tree (tree fn
parameter. That mus
--- 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
--- 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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Ke
--- 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
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
--
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
--- 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
--- 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 #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 #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 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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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.
--
--- 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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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 #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)
--
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
1 - 100 of 115 matches
Mail list logo
