Hi Richard,
I found the following in my build logs, and thought it was worth
reporting to you. Although I don't speak texinfo, the lines in
questions are the ones introduced by your ColdFire 9/63 patch
(commited as rev. 120713):
perl
On Tue, 6 Feb 2007, Dorit Nuzman wrote:
Hi Richard,
...
However...,
I have seen cases in which complete unrolling before vectorization
enabled
constant propagation, which in turn enabled significant simplification of
the code, thereby, in fact making a previously unvectorizable
Richard Guenther [EMAIL PROTECTED] wrote on 06.02.2007 11:19:15:
On Tue, 6 Feb 2007, Dorit Nuzman wrote:
After sleeping on it, it actually makes a lot of sense to me to
schedule
complete loop unrolling before vectorization - I think it would either
simplify loops (sometimes creating more
Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
Richard Guenther [EMAIL PROTECTED] wrote on 05/02/2007 17:59:00:
On Mon, 5 Feb 2007, Paolo Bonzini wrote:
As we also only vectorize innermost loops I believe doing a
complete unrolling pass early will help in general (I
Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
Richard Guenther [EMAIL PROTECTED] wrote on 05/02/2007 17:59:00:
...
That's going to change once this project goes in: (3.2) Straight-
line code vectorization from http://gcc.gnu.
On Tue, 6 Feb 2007, Dorit Nuzman wrote:
Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
Richard Guenther [EMAIL PROTECTED] wrote on 05/02/2007 17:59:00:
...
That's going to change once this project goes in: (3.2) Straight-
François-Xavier Coudert [EMAIL PROTECTED] writes:
I found the following in my build logs, and thought it was worth
reporting to you. Although I don't speak texinfo, the lines in
questions are the ones introduced by your ColdFire 9/63 patch
(commited as rev. 120713):
perl
Hi list!
First, I am not subscribed to this list, so please CC me on answers, thanks!
I try to build gcc trunk (r121622) on x86_64/core2duo but I get an ICE.
Thanks for any help in advance!
Regards,
Hanno
___
Build config:
# ./xgcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
On Tue, 6 Feb 2007, Richard Sandiford wrote:
Ugh, thanks for the heads-up. This patch adds some rudimentary
support for @multitable. As far as I know, perldoc doesn't have
anything equivalent to multi-column tables, so I just treated them
as itemized lists and used : as a column separator.
In an OS kernel functions that do not return are commonly used and
practically always their code is beyond gcc's ability to recognize
noreturn functions. A typical example would for example be the BUG()
function in Linux which is implemented as something like:
static inline void
Richard Guenther [EMAIL PROTECTED] wrote on 05/02/2007 18:16:05:
On Mon, 5 Feb 2007, Jan Hubicka wrote:
...
Did you run some benchmarks?
Not yet - I'm looking at the C++ SPEC 2006 benchmarks at the moment
and using vectorization there seems to do a lot of collateral damage
(maybe
Hi,
I tried to compile glibc 2.3.6 and 2.4 for an e500 target using
gcc-4.1.2-20070128.
I applied the proposed patch for PR30370 go get gcc compiled.
Unfortunately, glibc compilation fails. After some testing, I was able
to create a small test program - see below. It turns out that the
problem
Hello Paolo, all,
* Paolo Bonzini wrote on Mon, Feb 05, 2007 at 10:30:41AM CET:
The macro $(SYSTEM_HEADER_DIR) is used in a double-quoted context,
leading to nonportable ...`.`..., [...]
Proposed untested patch. (I also haven't checked whether there are
other instances of this
On Jan 29, 2007, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
* You can add a return 0 or an exit(1) at the end of the function or
in a default label. Since in your case the code is unreachable, the
optimiser may remove it or it will never be executed.
But this would generate additional code
On 1/31/07, Diego Novillo [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote on 01/31/07 11:26:
So, ideally, I would like just the gcc part until the first part of
the middleend where you have a 'no optimizations', language
independent AST of the source file.
OK, so you probably want to inject
Hello,
Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
Richard Guenther [EMAIL PROTECTED] wrote on 05/02/2007 17:59:00:
...
That's going to change once this project goes in: (3.2) Straight-
line code vectorization from
On Tue, Feb 06, 2007 at 04:44:50PM -0200, Alexandre Oliva wrote:
* You can add a return 0 or an exit(1) at the end of the function or
in a default label. Since in your case the code is unreachable, the
optimiser may remove it or it will never be executed.
But this would generate
On 06/02/07, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Jan 29, 2007, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
* You can add a return 0 or an exit(1) at the end of the function or
in a default label. Since in your case the code is unreachable, the
optimiser may remove it or it will
On Tue, Feb 06, 2007 at 08:00:29PM +, Ralf Baechle wrote:
On Tue, Feb 06, 2007 at 04:44:50PM -0200, Alexandre Oliva wrote:
Meanwhile, there's __builtin_trap() already, and Ralf might use that
even to remove the asm volatile, and Paweł could use it in a default:
label. It's still worse
In an OS kernel functions that do not return are commonly used and
practically always their code is beyond gcc's ability to recognize
noreturn functions. A typical example would for example be the BUG()
function in Linux which is implemented as something like:
static inline void
Paulo J. Matos wrote on 02/06/07 14:19:
Why before pass_build_ssa? (version 4.1.1)
It depends on the properties your pass requires. If you ask for
PROP_cfg and PROP_gimple_any then you should schedule it after the CFG
has been built, but if you need PROP_ssa, then you must be after
I am implementing -Wstrict-aliasing by catching simple cases in the
frontend and more complex ones in the backend. The frontend mechanism
is tree pattern matching. The backend one uses flow-sensitive points-to
information.
I want to avoid duplicate warnings. I thought of a few ways, but
On Tue, Feb 06, 2007 at 01:53:44PM -0800, Silvius Rus wrote:
I am implementing -Wstrict-aliasing by catching simple cases in the
frontend and more complex ones in the backend. The frontend mechanism
is tree pattern matching. The backend one uses flow-sensitive points-to
information.
I
Silvius Rus [EMAIL PROTECTED] writes:
I want to avoid duplicate warnings. I thought of a few ways, but none
seems perfect. Can you please advise which of the following I should
choose, suggest alternatives, or let me know if a solution exists.
It may work to set and check TREE_NO_WARNING on
Back in 2000 I wrote a really simple patch that caused gcc to treat an
ASM_OPERANDS that clobbered pc as a control flow barrier, exactly
for this problem.
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
I still think it was a good idea, but at the time it was received
Zack Weinberg wrote:
Back in 2000 I wrote a really simple patch that caused gcc to treat an
ASM_OPERANDS that clobbered pc as a control flow barrier, exactly
for this problem.
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
I still think it was a good idea, but at the time it was
Zack Weinberg [EMAIL PROTECTED] writes:
Back in 2000 I wrote a really simple patch that caused gcc to treat an
ASM_OPERANDS that clobbered pc as a control flow barrier, exactly
for this problem.
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
I still think it was a good idea, but
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
I also think it would be good to have one option affecting it: turn
__builtin_unreachable() into an abort(), or turn it into a cannot be
reached marker. I think the former should be the default at -O0, the
latter at -O1 and
Joe Buck [EMAIL PROTECTED] writes:
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
I also think it would be good to have one option affecting it: turn
__builtin_unreachable() into an abort(), or turn it into a cannot be
reached marker. I think the former should be the
On Feb 6, 2007, at 5:06 PM, Joe Buck wrote:
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
I also think it would be good to have one option affecting it: turn
__builtin_unreachable() into an abort(), or turn it into a cannot be
reached marker. I think the former should be
--- 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
1 - 100 of 134 matches
Mail list logo
