--- Comment #11 from dorit at il dot ibm dot com 2007-02-06 08:18 ---
(In reply to comment #10)
One thing I can think of that this description misses is that the two
pointers must be based-on *different* restrict-qualified pointers, unless
that case is already handled elsewhere.
--- Comment #29 from paolo dot bonzini at lu dot unisi dot ch 2007-02-06
08:26 ---
Subject: Re: Shared libstdc++ fails to link
Paolo, would you be able to undo the change to make foo not marked
TREE_NOTHROW? IIUC, that would be different than the patch you posted
in Comment #22,
--- Comment #30 from bonzini at gnu dot org 2007-02-06 08:37 ---
Created an attachment (id=13011)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view)
proposed, untested patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-02-06 08:39
---
Confirmed, although I'm not exactly sure how we could detect that. Maybe we
would need to add front-end optimization passes, between resolution and
translation...
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-02-06 09:26
---
The patch proposed makes sense, Dave can you verify it fixes this PR for you?
I'll spin some testing on the trunk in a moment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
When an ifstream object is used in several open()-close() cycles, it seems to
remember past cycles in the Red Hat gcc version.
STEPS TO REPRODUCE:
1) Compile the attached code using gcc version 4.1.0 20060515 (Red Hat
4.1.0-18)
2) Compile the attached code using gcc version 4.0.2
3) Create a file
--- Comment #1 from steigers at phys dot ethz dot ch 2007-02-06 10:05
---
Created an attachment (id=13012)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13012action=view)
Code for testing the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30711
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-06 10:08 ---
Created an attachment (id=13013)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13013action=view)
alternate patch
This patch tackes the issue by allowing
a_2 = ASSERT_EXRP a_1, (unsigned)a_1 + 5 = 10
(and
--- Comment #2 from jakub at gcc dot gnu dot org 2007-02-06 10:11 ---
Simplified testcase:
struct A
{
A() {}
~A() {}
int i;
};
void
foo (A a)
{
#pragma omp parallel firstprivate (a)
a.i++;
}
The problem is that while OpenMP 2.5 prohibits firstprivate etc. vars having
reference
--- Comment #32 from amylaar at gcc dot gnu dot org 2007-02-06 10:18
---
(In reply to comment #30)
Created an attachment (id=13011)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view) [edit]
proposed, untested patch
As far as I can tell, this patch takes care of
--- Comment #2 from steigers at phys dot ethz dot ch 2007-02-06 10:33
---
Apparently if the close() statement is followed by a clear() statement it
works. I t also works if close() is omitted and only clear() is called.
I therefore suspect that someone forgot to change the status of
--- Comment #33 from rguenth at gcc dot gnu dot org 2007-02-06 10:39
---
It does not work either:
/abuild/rguenther/obj-29487/./gcc/xgcc -shared-libgcc
-B/abuild/rguenther/obj-29487/./gcc -nostdinc++
-L/abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/src
--- Comment #34 from bonzini at gnu dot org 2007-02-06 10:41 ---
The two bits were actually the same, since passes.c was doing this exactly
after calling set_nothrow_function_flags
if (current_function_nothrow)
/* Now we know that this can't throw; set the flag for the benefit
--- Comment #35 from amylaar at gcc dot gnu dot org 2007-02-06 11:10
---
(In reply to comment #25)
I think the analysis should be deeper than just binds_local_p, though;
I think it should be based on whether attribute ((weak)) (or
equivalent) explicitly appears, so that we don't
--- Comment #36 from amylaar at gcc dot gnu dot org 2007-02-06 11:17
---
(In reply to comment #34)
I'll prepare a patch to revert my 2004 change too.
I suspect that a 100% literal reversion will run into problems where the
use of a global variable will result in the the analysis of
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-06 12:12
---
(In reply to comment #5)
Min/maxval should return (for REAL):
+INF if there is an INF in the maxval argument array
-INF if there is a -INF in the minval argument array
NAN if the argument array only
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-06 12:25
---
$ cat pr29400-3.f90
integer,parameter :: i(1,1) = 0
logical :: l
l = any(i==1)
end
$ gfortran pr29400-3.f90 ./a.out
pr29400-3.f90: In function MAIN__:
pr29400-3.f90:1: internal compiler error:
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-06 12:30 ---
I don't know what the status is of the other patch for MAXVAL/MINVAL, but we
should probably combine them into a single patch (in particular to ease the
backporting).
The status of the other patch is: Waiting for
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-02-06 12:38 ---
Subject: Bug 27302
Author: rguenth
Date: Tue Feb 6 12:38:32 2007
New Revision: 121644
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121644
Log:
2007-02-06 Richard Guenther [EMAIL PROTECTED]
PR
I started to get failures bootstrapping trunk early this morning. For example:
Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/xgcc
-B/u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/
/u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/pr13366.c -O
-msse -fno-show-column -S
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-06 13:41
---
I was wrong: the bug basically happens for all intrinsics which gfc_walk_expr
one of their arguments and then simply assert that the ss != gfc_ss_terminator.
This is a wrong thing to do for constant arguments. I
--- Comment #21 from manu at gcc dot gnu dot org 2007-02-06 13:48 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01933.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
--- Comment #22 from manu at gcc dot gnu dot org 2007-02-06 13:49 ---
Not a definitive fix but at least the warning can be disabled:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01933.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
--- Comment #2 from s_j_newbury at yahoo dot co dot uk 2007-02-06 13:58
---
Sounds like you're trying to build a hard-float compiler for a soft-float
(binutils) target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29120
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-06 14:05
---
We're passing a pointer to a logical instead of an array descriptor:
$ cat a.f90
integer :: k(3), l(1)
integer, parameter :: j(3) = 2
l = maxloc (k, j1)
end
$ cat a.f90.003t.original
--- Comment #37 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-06
14:13 ---
Subject: Re: Shared libstdc++ fails to link
The patch proposed makes sense, Dave can you verify it fixes this PR for you?
I'll spin some testing on the trunk in a moment.
Yes. I'll try when an
Attached code generates on Internal Complier Error when using -O3 on
an Intel Mac
--
Summary: Internal Complier Error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
at least seen on the redhat/gcc-4_1-branch-java-merge-20070117 branch; not yet
validated on the trunk:
$ touch IIFoo.java
$ gcj -C IIFoo.java
gcj: no input files
--
Summary: [regression] gcj driver doesn't recognize files starting
with II
Product: gcc
--- Comment #3 from joaquinduran at adtelecom dot es 2007-02-06 14:26
---
Forget the bug.
I submmited it because I wa not able to build it from Open Embedded meta-data.
The fix was update the meda-data used to generate the images (which specifies
the ./configure options; very similar
20070206 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E
-lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v
coord_v_convert.F90 -mtune=generic -O -o /tmp/ccjN9yGi.f95
ignoring nonexistent directory
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #8 from sayle at gcc dot gnu dot org 2007-02-06 15:09 ---
Subject: Bug 28296
Author: sayle
Date: Tue Feb 6 15:09:17 2007
New Revision: 121649
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121649
Log:
PR libgomp/28296
Backport from mainline.
--- Comment #9 from sayle at gcc dot gnu dot org 2007-02-06 15:15 ---
Subject: Bug 28296
Author: sayle
Date: Tue Feb 6 15:15:33 2007
New Revision: 121650
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121650
Log:
PR libgomp/28296
Backport from mainline.
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-06 15:36 ---
There is no attached code. Ray can you try adding the code, again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
--- Comment #2 from ray at ultramarine dot com 2007-02-06 15:39 ---
Subject: Re: Internal Complier Error
On Tue, 6 Feb 2007, kargl at gcc dot gnu dot org wrote:
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-06 15:36 ---
There is no attached code. Ray can
After the line gcc-Version 4.3.0 20070206 (experimental) is the actual
compilation command. On my computer it looks like:
/projects/tob/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
env_grid.f -ffixed-form ...
Run now (replace the argument with yours of above)
gdb /projects/tob/gcc-trunk
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-06 16:52 ---
Confirmed. It crashes with -O but not without optimization.
Reduced test case:
Subroutine xcc_V_CONVERT(iepoch)
implicit none
logical :: IEPOCH
real:: XVECTOR(1:3)
real:: YVECTOR(1:3)
, but with today's gcc under x86_64-unknown-linux-gnu it
does not crash.
Maybe someone with Intel Mac can reproduce it.
Oherwise:
Compile with the -v option, e.g. gfortran -v -O3 env_grid.f
After the line gcc-Version 4.3.0 20070206 (experimental) is the actual
compilation command. On my computer
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-06 17:45 ---
Reduced test case:
The line xvector = 0.0 can also be removed. The dump-tree-original looks then
as follows:
xcc_v_convert (iepoch)
{
real4 xvector[3];
real4 yvector[3];
if (*iepoch)
{
(void)
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-06 17:50 ---
This is most likely a dup of bug 29922.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-06 17:52 ---
*** Bug 30715 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-06 17:52 ---
*** This bug has been marked as a duplicate of 30391 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from sje at cup dot hp dot com 2007-02-06 18:01 ---
This is fixed on mainline and the 4.2 branch now. Should it be closed? I
don't think %VAL is in GCC 4.1 and the failing test is certainly not in the 4.1
branch. The underlying bug is in 4.1 but it may not be possible
--- Comment #1 from doko at ubuntu dot com 2007-02-06 18:02 ---
confirmed with trunk 20070206
--
doko at ubuntu dot com changed:
What|Removed |Added
Known to fail
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-02-06 18:11 ---
Subject: Bug 30540
Author: dfranke
Date: Tue Feb 6 18:11:30 2007
New Revision: 121657
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121657
Log:
2007-02-07 Daniel Franke [EMAIL PROTECTED]
Backport
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-02-06 18:12 ---
Subject: Bug 30272
Author: dfranke
Date: Tue Feb 6 18:12:22 2007
New Revision: 121658
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121658
Log:
2007-02-07 Daniel Franke [EMAIL PROTECTED]
Backport
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-02-06 18:14 ---
Fixed in mainline and 4.2. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-02-06 18:15 ---
Fixed in mainline and 4.2. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30272
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-02-06 18:32 ---
Solving for C++0x.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #15 from dfranke at gcc dot gnu dot org 2007-02-06 18:48
---
Subject: Bug 30546
Author: dfranke
Date: Tue Feb 6 18:48:11 2007
New Revision: 121661
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121661
Log:
2007-02-07 Daniel Franke [EMAIL PROTECTED]
--- Comment #16 from dfranke at gcc dot gnu dot org 2007-02-06 18:50
---
Subject: Bug 30546
Author: dfranke
Date: Tue Feb 6 18:49:55 2007
New Revision: 121662
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121662
Log:
2007-02-07 Daniel Franke [EMAIL PROTECTED]
--- Comment #17 from dfranke at gcc dot gnu dot org 2007-02-06 18:54
---
Fixed in mainline and 4.2. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
I had tried to compile code like
templateint dim class cls {
clsdim-1 c[16];
};
template class cls0 {
};
int main() {
cls200 c;
return 0;
}
and had error:
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See
glibc 2.3.6 fails to compile with gcc 4.1.2 dated 11/24/06 or later, or
matching gcc version 4.2.x, if gcc is compiled for e500 or e500v2 CPUs.
The following code is a shortened test case.
#define testmacro(mem) \
({ \
--- Comment #1 from guenter at roeck-us dot net 2007-02-06 19:28 ---
Turns out that compilation is fine if I compile with -mno-strict-align.
Maybe this is not a bug after all but simply changed semantics ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-06 19:30 ---
You cannot really take the address of an elemenent of a packed struct on non
strict alignment targets as if you deference them, it will try to do an aligned
load which then fail as the alignment is wrong.
--
--- Comment #3 from pcarlini at suse dot de 2007-02-06 19:32 ---
I cannot reproduce the issue on official FSF compiler more recent than gcc4.0.0
(note that vendor releases are not supported here, sorry). In fact, since that
release we are implementing the resolution of DR 409:
Compiling without -O causes severe consequences that can easily
be avoided, i.e. see the wontfix bug 25575.
people expect to have warnings for use of uninitialized variables,
I dont know if this behaviour has always been the same across gcc
versions but regardless, the user cant be expected to
--- Comment #3 from guenter at roeck-us dot net 2007-02-06 19:41 ---
Does that mean this is really a glibc problem ?
In glibc, the problem occurs with an atomic_increment() on an element of a
packet structure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
--- Comment #7 from spark at gcc dot gnu dot org 2007-02-06 19:43 ---
Subject: Bug 28686
Author: spark
Date: Tue Feb 6 19:43:41 2007
New Revision: 121663
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121663
Log:
2007-02-06 Seongbae Park [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-06 19:48 ---
If there is no reason to ever compile without -O,
There are reasons, like getting much, much better debug info.
-O1 enables lots of optimization that changes the code so much that debugging
optimizated code is
The program below terminates with a runtime error due to an attempt to allocate
a negative amount of memory. The error occurs while allocating memory for a
temporary, empty, array slice.
$ cat pr.f90
program runtime_error
REAL:: a(5), b
INTEGER :: l, u
l = 4
u = 2
a = (/ 1.0, 2.0,
--- Comment #2 from tvb at gnome dot org 2007-02-06 20:09 ---
(In reply to comment #1)
If there is no reason to ever compile without -O,
There are reasons, like getting much, much better debug info.
-O1 enables lots of optimization that changes the code so much that debugging
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-02-06 20:34
---
Confirming this bug (both of them, actually).
For the missed-optimization, I think there's no reason to keep a library
function _gfortran_internal_free(x) that is equivalent to if(x) free(x);, we
should generate
--- Comment #2 from tromey at gcc dot gnu dot org 2007-02-06 20:44 ---
Subject: Bug 30714
Author: tromey
Date: Tue Feb 6 20:43:55 2007
New Revision: 121666
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121666
Log:
PR java/30714:
* jvspec.c
--- Comment #3 from tromey at gcc dot gnu dot org 2007-02-06 20:45 ---
Subject: Bug 30714
Author: tromey
Date: Tue Feb 6 20:45:25 2007
New Revision: 121667
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121667
Log:
PR java/30714:
* jvspec.c
--- Comment #4 from tromey at gcc dot gnu dot org 2007-02-06 20:46 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from mmitchel at gcc dot gnu dot org 2007-02-06 20:50
---
Subject: Bug 30370
Author: mmitchel
Date: Tue Feb 6 20:50:37 2007
New Revision: 121668
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121668
Log:
PR 30370
* config/rs6000/t-ppccomm:
--- Comment #16 from mmitchel at gcc dot gnu dot org 2007-02-06 20:58
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-06 21:00
---
The wrong-code bug happens in gfc_trans_create_temp_array. For some reason, the
function argument to that function is false, and the code present to take care
of negative extent is not triggered. Thomas, you're
--- Comment #17 from mmitchel at gcc dot gnu dot org 2007-02-06 21:06
---
Subject: Bug 30370
Author: mmitchel
Date: Tue Feb 6 21:06:36 2007
New Revision: 121669
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121669
Log:
PR 30370
* config/rs6000/t-ppccomm:
--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-06
21:18 ---
Subject: Re: Shared libstdc++ fails to link
Created an attachment (id=13011)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view)
--
Attached test case ICEs. The code is AFAIK invalid:
---8---
#include stdio.h
template typename Numeric
class Table
{
typedef struct
{
const char * const name;
Numeric index;
} Tableitem;
static const Tableitem entries[];
public:
const char * const
operator[]
--- Comment #1 from v dot haisman at sh dot cvut dot cz 2007-02-06 21:36
---
(In reply to comment #0)
[...]
logout::wilx:~/tmp g++42 -o ice ice.cxx
ice.cxx:14: internal compiler error: in import_export_decl, at cp/decl2.c:1956
Please submit a full bug report,
with preprocessed
This has been derived from test case in PR 30721 but because it ICEs at
different place I report it as different bug.
-8--
template typename Numeric
struct Table
{
typedef struct
{
const char * const name;
} Tableitem;
static const Tableitem entries[];
};
enum
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-06 22:03 ---
What is there to warn about?
If you do -Winitialize without -O, you get a warning so ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #60 from hubicka at gcc dot gnu dot org 2007-02-06 22:05
---
Hi,
small update on status. At -O3 -fno-tree-fre -fno-tree-pre we are now doing
1.1GB footprint, 800MB of this out of gimple. We still explode in FRE/PRE but
majority of other problems was fixed:
Execution times
--- Comment #61 from hubicka at gcc dot gnu dot org 2007-02-06 22:14
---
Also forgot to mention, integration is slow because of the split_block
quadraticness.
For -O2:
We need 531MB of ram, GGC memory is peaking at 100MB, large portion of the
non-GGC memory are definitly the scheduler
Currently, allocated memory is freed by calling the library function
_gfortran_internal_free, which does nothing but:
/* Free internally allocated memory. Pointer is NULLified. Also used to
free user allocated memory. */
void
internal_free (void *mem)
{
if (mem != NULL)
free (mem);
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #18 from kkojima at gcc dot gnu dot org 2007-02-06 23:12
---
Subject: Bug 29746
Author: kkojima
Date: Tue Feb 6 23:12:35 2007
New Revision: 121671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121671
Log:
PR target/29746
* config/sh/sh.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-06 23:13
---
To keep things separate, I filed PR30723 for the missed optimization.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-06 23:16
---
Created an attachment (id=13018)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13018action=view)
Patch for this bug
Here's the patch I propose. It makes the code simpler by using a cond_expr
instead of
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-02-06 23:17
---
(In reply to comment #10)
This is fixed on mainline and the 4.2 branch now. Should it be closed? I
don't think %VAL is in GCC 4.1 and the failing test is certainly not in the
4.1
branch. The underlying
--- Comment #19 from kkojima at gcc dot gnu dot org 2007-02-06 23:29
---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-07 00:21
---
Here's another patch for concat, to have the front-end generate the code itself
instead of calling a library function. It still generates the extra temporary,
but can optimize other things.
Index: trans-expr.c
--- Comment #1 from fang at csl dot cornell dot edu 2007-02-07 00:32
---
Ahh, exploding recursive templates...
For future reference, you could limit the recursion depth explicitly, using
-ftemplate-depth-n
from a gcc-3.4.0 man page:
Set the maximum instantiation depth for template
--- Comment #18 from schlie at comcast dot net 2007-02-07 00:56 ---
Subject: Re: C++ FE emitting assignments to read-only
global symbols
for 4.3?
From: rguenth at gcc dot gnu dot org [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 5 Feb 2007 22:51:25 -
To: [EMAIL
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-02-07 02:10
---
From the dictionary: obsolescent - Going out of use; becoming obsolete;
So this means its not obsolete yet, and thus still supported.
I will fix this. Splitting hairs really, but what the heck.
--
gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,java,ada
following example file can't compiled
$ cat bug.cpp
class A{
public:
bool operator()() const {
return true;
}
};
int main() {
if ((A()())) {}
}
$ g++-4.1 -c bug.cpp
bug.cpp: In function int main():
bug.cpp:9: error: type name declared as function returning a function
bug.cpp:9:
--- Comment #4 from patchapp at dberlin dot org 2007-02-07 04:30 ---
Subject: Bug number PR30681
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/msg00597.html
--
--- Comment #1 from fang at csl dot cornell dot edu 2007-02-07 05:04
---
Workaround:
if (A().operator()()) { }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30725
--- Comment #2 from fang at csl dot cornell dot edu 2007-02-07 05:05
---
looks familiar: PR 29234
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30725
--- Comment #3 from lidaobing at gmail dot com 2007-02-07 05:13 ---
*** This bug has been marked as a duplicate of 29234 ***
*** This bug has been marked as a duplicate of 29234 ***
--
lidaobing at gmail dot com changed:
What|Removed |Added
--- Comment #2 from lidaobing at gmail dot com 2007-02-07 05:13 ---
*** Bug 30725 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29234
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-07 06:51 ---
If you use -fno-strict-aliasing and it works, that should tell you something
right there really.
Anyways you are violating C/C++ aliasing rules, see PR 21920.
*** This bug has been marked as a duplicate of 21920
1 - 100 of 104 matches
Mail list logo
