I've been looking at -ftrapv and some simple cases it doesn't work
right in. (I've got a patch coming soon to address one case where
__addvsi3 libcalls and the like get optimized away in RTL.)
I see a few reports in Bugzilla, many marked as duplicates of PR
19020 though they cover a few
I've recently noticed that every time I build GCC, the source files in
the libstdc++-v3/include/precompiled directory have their modification
timestamps updated. Anyone know what's going on here?
Ollie
Mark,
Kai Tietz wrote:
Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all
calling-convention predicates ought to be looking at the type to
support
calling through function pointers?
This macro is
Hello!
I have tripped over a problem, where #defines from libc
(bits/mathinline.h) interfere badly with gcc's intrinsics.
The problem (note the #include):
--cut here--
#include math.h
double test (double x)
{
return ceil(x);
}
--cut here--
when compiled with -O2 -ffast-math -msse2
On 9/17/07, Uros Bizjak [EMAIL PROTECTED] wrote:
Hello!
I have tripped over a problem, where #defines from libc
(bits/mathinline.h) interfere badly with gcc's intrinsics.
The problem (note the #include):
--cut here--
#include math.h
double test (double x)
{
return ceil(x);
}
--cut
On 9/17/07, Uros Bizjak [EMAIL PROTECTED] wrote:
Hello!
I have tripped over a problem, where #defines from libc
(bits/mathinline.h) interfere badly with gcc's intrinsics.
The problem (note the #include):
--cut here--
#include math.h
double test (double x)
{
return
Dear Employee,
We needs a representative in United Kingdom to act as our Online Staff
through which our customers can pay outstanding bills owed by them to us in
your Region
We are looking only for the Honest and Open Hearted Individual whosatisfies
our requirements and glad to offer
Dear Employee,
We needs a representative in United Kingdom to act as our Online Staff
through which our customers can pay outstanding bills owed by them to us in
your Region
We are looking only for the Honest and Open Hearted Individual whosatisfies
our requirements and glad to offer
On trunk I get
/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem
/usr/powerpc64-suse-linux/include -isystem
-suse-linux-gnu
On trunk I get
/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem
/usr/powerpc64-suse-linux
On Mon, 17 Sep 2007, Gerald Pfeifer wrote:
And now to the most important issue of all to address before we can
release GCC 4.3.0. ;-)
In our current documentation we have both command-line option and
command line option. Like other such cases, we should make a choice
and document this in
On Mon, 17 Sep 2007, Ken Raeburn wrote:
I see a few reports in Bugzilla, many marked as duplicates of PR 19020 though
they cover a few different cases, which have me wondering about what the scope
of -ftrapv ought to be.
See my message http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02026.html
Dear Employee,
We needs a representative in United Kingdom to act as our Online
Staff through which our customers can pay outstanding bills owed by them to
us in your Region
We are looking only for the Honest and Open Hearted Individual
whosatisfies our requirements and glad to offer
Dear Employee,
We needs a representative in United Kingdom to act as our Online
Staff through which our customers can pay outstanding bills owed by them to
us in your Region
We are looking only for the Honest and Open Hearted Individual
whosatisfies our requirements and glad to offer
Joseph S. Myers wrote:
On Mon, 17 Sep 2007, Gerald Pfeifer wrote:
And now to the most important issue of all to address before we can
release GCC 4.3.0. ;-)
In our current documentation we have both command-line option and
command line option. Like other such cases, we should make a choice
It's actually powerpc configured like
../configure --with-cpu=default32 --build=powerpc64-suse-linux
checking build system type... powerpc64-suse-linux-gnu
checking host system type... powerpc64-suse-linux-gnu
checking target system type... powerpc64-suse-linux-gnu
Looks like
2007-08-31
On Fri, Aug 17, 2007 at 06:02:06PM +0200, Rask Ingemann Lambertsen wrote:
What happened to the experiments you described at
URL:http://gcc.gnu.org/ml/gcc/2004-06/msg01178.html? Emitting a no-op move
of the (set (reg) (reg)) form won't work, but maybe something like
(insn (use (reg)
Richard Guenther [EMAIL PROTECTED] writes:
On trunk I get
/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem
Bootstrap of powerpc64-linux fails building libgfortran with:
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function
'set_integer':
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal compiler
error: in set_variable_part, at var-tracking.c:2381
Please submit a
On Mon, 2007-09-17 at 17:55 +0200, Andreas Schwab wrote:
Richard Guenther [EMAIL PROTECTED] writes:
On trunk I get
/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/
-B/usr
On Mon, Sep 17, 2007 at 10:50:17AM -0700, Janis Johnson wrote:
Bootstrap of powerpc64-linux fails building libgfortran with:
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function
'set_integer':
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal compiler
On 9/17/07, Jakub Jelinek [EMAIL PROTECTED] wrote:
My guess is that this is a long standing latent bug with var-tracking
on big endian machines, we saw it a few times with gcc-4.1.x-RH as well.
The problem is that after optimizing some subregs we can have negative
offsets in MEM_OFFSET of some
Laurent GUERBY wrote:
On Mon, 2007-09-17 at 17:55 +0200, Andreas Schwab wrote:
Richard Guenther [EMAIL PROTECTED] writes:
On trunk I get
/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse
This is for Joel :).
I know nothing about autoconf, near to nothing about Makefile
and I don't even know what multilib are for (I never found any
documentation about them :).
Laurent
On Mon, 2007-09-17 at 16:20 -0400, Jack Howarth wrote:
Laurent,
I would suggest you start over using the
Janis Johnson [EMAIL PROTECTED] writes:
Bootstrap of powerpc64-linux fails building libgfortran with:
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function
'set_integer':
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal compiler
error: in
Kai Tietz wrote:
I'm sorry -- that doesn't really answer the question I was trying to
ask. To be clear, if we're calling through a function pointer, we still
need to be able to do the right thing, and in that case we don't have a
FUNCTION_DECL. So, I don't understand how you can have a
Laurent,
I would suggest you start over using the libgfortran as your
example. Geoffrey Keating created the config/multi.m4 file which
dramatically simplified how the multilib could be implemented.
If I recall correctly from when I helped clean up some of
the residual multilib problems (so
On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
Janis Johnson [EMAIL PROTECTED] writes:
Bootstrap of powerpc64-linux fails building libgfortran with:
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function
'set_integer':
Snapshot gcc-4.1-20070917 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070917/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Janis Johnson [EMAIL PROTECTED] writes:
On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
Janis Johnson [EMAIL PROTECTED] writes:
Bootstrap of powerpc64-linux fails building libgfortran with:
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function
'set_integer':
Richard Sandiford wrote:
Janis Johnson [EMAIL PROTECTED] writes:
On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
Janis Johnson [EMAIL PROTECTED] writes:
Bootstrap of powerpc64-linux fails building libgfortran with:
Kenneth Zadeck wrote:
Richard Sandiford wrote:
Janis Johnson [EMAIL PROTECTED] writes:
On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
Janis Johnson [EMAIL PROTECTED] writes:
Bootstrap of powerpc64-linux fails building libgfortran with:
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-17 06:40 ---
*** Bug 33444 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33445
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-17 06:40 ---
*** This bug has been marked as a duplicate of 33445 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-09-17 06:46
---
It doesn't appear in x86 Mac Os X 10.4 with version 4.0.1 (Apple Computer,
Inc. build 5250)
Because the GCC released by Apple defaults to -fno-strict-aliasing.
Gcc forget code's dependancy.
No, your code
Following (delta reduced) testcase ICEs with 'gcc -O2 -msse2
-ftree-parallelize-loops=4 -ftree-vectorize' on i686 and x86_64:
gcc -O2 -msse2 -ftree-parallelize-loops=4 -ftree-vectorize 048.c
048.c: In function 'Create_BCyl':
048.c:15: internal compiler error: in build2_stat, at tree.c:3110
Please
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-17 06:55 ---
Looking at the dump (GCC 4.3), one sees for the fixed-format code:
#pragma omp parallel default(shared) reduction(+:kin) reduction(+:pot)
private(d) private(rij) private(k) private(j) private(i)
{
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-17 07:16 ---
Why do you think that is a bug?
Please read OpenMP 2.5, 2.1.1 (Fixed Source Form Directives) and 2.1.2
(Free Source Form Directives). Continuation is done very differently between
fixed and free form. So, what are
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-17 07:40 ---
How about giving a diagnostic as ifort does:
fortcom: Error: test2.f90, line 93: Syntax error, found '' when expecting one
of: LABEL END-OF-STATEMENT ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE
CHARACTER ...
!$omp
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-17 08:05 ---
Jakub, do you agree that this is a bug or is this no bug?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-09-17 08:18 ---
Pedantically this is not a bug. If an omp sentinel doesn't have the desired
form, it should be handled as a normal comment. As the preceeding line
doesn't end with , then !$omp is not a valid omp sentinel (as !$omp
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-17 08:21 ---
Pedantically this is not a bug. If an omp sentinel doesn't have the desired
form, it should be handled as a normal comment.
I think your comment is with regards to PR 33445 and not regarding this PR
(PR33439).
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-17 08:33 ---
I guess so. All the testcases rely on either availability of cexp() or
sincos().
For the former via TARGET_C99_FUNCTIONS, for the latter via TARGET_HAS_SINCOS.
But it is interesting that -59 fails, as the
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-17 08:39
---
I can reproduce that on x86_64-linux with trunk rev. 128442. Severity set to
critical, as this is LAPACK.
Program received signal SIGSEGV, Segmentation fault.
vect_get_vec_defs_for_stmt_copy (dt=0x7fff713d44c0,
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-17 08:40
---
Yep, this was fixed. Sorry.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-17 08:53 ---
Jakub Jelinek wrote (in PR 33439, but seemingly regarding this PR):
Pedantically this is not a bug. If an omp sentinel doesn't have the desired
form, it should be handled as a normal comment. As the preceeding
--- Comment #4 from irar at il dot ibm dot com 2007-09-17 08:59 ---
(In reply to comment #3)
I can reproduce that on x86_64-linux with trunk rev. 128442.
Dorit's fix is revision 128514, so it is not supposed to work on 128442...
Anyway, I am trying to reproduce this ICE on
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-17 09:05 ---
Please provide a complete testcase that shows the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33451
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-17 09:14 ---
This is related to pointer plus.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-17 09:33
---
On x86_64-linux, when f951 (both with -m32 and -m64) is run under valgrind, I
get a short series of invalid read beginning with:
==1628== Invalid read of size 1
==1628==at 0xAEA1F0: htab_hash_string
--- Comment #2 from victork at gcc dot gnu dot org 2007-09-17 09:37 ---
Subject: Bug 33319
Author: victork
Date: Mon Sep 17 09:37:31 2007
New Revision: 128539
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128539
Log:
PR tree-optimization/33319
*
/tmp/cvs/gcc-20070916/Build/./gcc/xgcc -B/tmp/cvs/gcc-20070916/Build/./gcc/
-B/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/bin/
-B/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/lib/ -isystem
/tmp/cvs/gcc-20070916/Build/root/powerpc64-suse-linux/include -isystem
--- Comment #5 from irar at il dot ibm dot com 2007-09-17 09:54 ---
(In reply to comment #4)
Anyway, I am trying to reproduce this ICE on x86_64-linux now, with the
current
trunk (128538).
It doesn't ICE for me. (The loop gets vectorized).
Ira
--
--- Comment #7 from kari-matti dot pulkkinen at comptel dot com 2007-09-17
10:01 ---
Got the same error with 4.2.1:
/temp/cpt2k4p/gcc/HP-UXita/./gcc/xgcc -B/temp/cpt2k4p/gcc/HP-UXita/./gcc/
-B/vobs/prod/tools/gnu/gcc/HP-UXita/ia64-hp-hpux11.23/bin/
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:16
---
I'm making this a meta-bug to monitor our improvement on newlib targets.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
nbkolchin at gmail dot com wrote:
Our target hardware has SH7750 processor running in little endian mode under
RTEMS. Unfortunetaly there is no way to boot linux there.
After lurking inside backend sources, I found that m4 has several variants in
GCC 4.x: m4-100, m4-200, etc. I've tried to
--- Comment #5 from andrew dot stubbs at st dot com 2007-09-17 10:30
---
Subject: Re: New: [SH4] performance regression between
3.4.6 and 4.x
nbkolchin at gmail dot com wrote:
Our target hardware has SH7750 processor running in little endian mode under
RTEMS. Unfortunetaly there
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:42
---
Subject: Bug 33449
Author: fxcoudert
Date: Mon Sep 17 10:42:29 2007
New Revision: 128543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128543
Log:
PR middle-end/33449
*
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-17 10:42
---
Closing the bug, after adding a reduced testcase to the testsuite.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-17 11:03 ---
Confirmed. Looks like we try to build a multiplication with ptr * int:
(gdb) bt
#0 fancy_abort (
file=0xf27848 /space/rguenther/src/svn/pointer_plus/gcc/tree.c,
line=3110, function=0xf291bf build2_stat)
--- Comment #21 from rask at gcc dot gnu dot org 2007-09-17 11:13 ---
It's probably someting simple, see config.log. Like I said, the patch is a
quick and dirty one and the AVR back end can use more work than that, most of
which means deleting patterns. Examples: All and, ior, xor,
--- Comment #5 from opichals at seznam dot cz 2007-09-17 11:35 ---
Yes, I have checked the ODR definition and it is really the fact that the code
violates that. Thank you for your explanations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32549
--- Comment #4 from nickc at redhat dot com 2007-09-17 12:08 ---
Subject: Re: collect2: ld terminated with signal 11 [Segmentation
fault]
Hi Don,
Thank you both for your replies. I have now built binutils 2.18.
However I'm not root on this machine and so cannot install it in the
--- Comment #42 from rguenth at gcc dot gnu dot org 2007-09-17 13:11
---
Still slow.
cfg cleanup : 7.10 (10%) usr 0.16 (10%) sys 7.26 (10%) wall
625 kB ( 1%) ggc
tree VRP : 27.40 (39%) usr 0.39 (23%) sys 27.91 (38%) wall
7602 kB (11%) ggc
--- Comment #11 from dominiq at lps dot ens dot fr 2007-09-17 13:59 ---
Subject: Re: [4.3 Regression] At revision 128385
Bootstraping PPC Darwin still fail in Java
Did you try to bootstrap with Java with the one line patch in:
http://gcc.gnu.org/ml/gcc-bugs/2007-09/msg01311.html
It
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-09-17
14:52 ---
On powerpc-apple-darwin9, the patch Zdenek is checking in...
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01380.html
suppresses the build problems in Java...
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2007-09-17
14:57 ---
To clarify, what I meant to say in the above comment was that I am concerned if
Zdenek's patch may convert this PR into a latent bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
--- Comment #7 from hubicka at gcc dot gnu dot org 2007-09-17 15:12 ---
Subject: Bug 33348
Author: hubicka
Date: Mon Sep 17 15:12:10 2007
New Revision: 128547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128547
Log:
PR middle-end/33348
PR target/33406
*
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-09-17 15:12
---
Subject: Bug 33406
Author: hubicka
Date: Mon Sep 17 15:12:10 2007
New Revision: 128547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128547
Log:
PR middle-end/33348
PR target/33406
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-17 15:26 ---
On x86_64-linux, when f951 (both with -m32 and -m64) is run under valgrind, I
get a short series of invalid read beginning with:
FX, which version of gfortran are you using? I cannot reproduce it (with
valgrind)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-17 15:43
---
Closing, please reopen when you get time to rebuild and post the error.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from burnus at gcc dot gnu dot org 2007-09-17 15:55 ---
Subject: Bug 33106
Author: burnus
Date: Mon Sep 17 15:55:22 2007
New Revision: 128550
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128550
Log:
2007-09-17 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2007-09-17 15:56 ---
FIXED on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rakdver at gcc dot gnu dot org 2007-09-17 15:39
---
Subject: Bug 26449
Author: rakdver
Date: Mon Sep 17 15:38:48 2007
New Revision: 128549
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128549
Log:
PR rtl-optimization/26449
* loop-invariant.c
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-17 16:29 ---
Simple patch; catches if result size source size (cf. example in bug 31610
comment 0). However, it does not catch if result size LHS variable. (Example
in this PR.)
Index: simplify.c
--- Comment #22 from ubizjak at gmail dot com 2007-09-17 16:43 ---
Fixed in mainline, still (latent) present on 4.2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from don-gcc at isis dot cs3-inc dot com 2007-09-17 16:31
---
Subject: Re: collect2: ld terminated with signal 11 [Segmentation fault]
Nick Clifton writes:
There are several possibilities:
...
I ended up following the recommendation below - worked fine.
I installed
--- Comment #2 from pcarlini at suse dot de 2007-09-17 17:22 ---
I can't reproduce the problem with current (128551) mainline. Likely a
transient issue, otherwise, please reopen.
--
pcarlini at suse dot de changed:
What|Removed |Added
See 31610 for another example.
13.7.75 MERGE (TSOURCE, FSOURCE, MASK)
FSOURCE shall be of the same type and type parameters as TSOURCE.
NAG f95:
Error: merge_char_3.f90, line 4: Unequal character lengths (2 and 3) in MERGE
intrinsic
Error: merge_char_3.f90, line 5: Unequal character lengths (2
--- Comment #6 from gcc at abeckmann dot de 2007-09-17 17:35 ---
Created an attachment (id=14216)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14216action=view)
minimal testcase
The ICE only occurs with -O3 and above.
$ /suse/NOBACKUP/gcc/gcc-4.2-branch/bin/g++ -v -O3 -fopenmp
--- Comment #2 from manu at gcc dot gnu dot org 2007-09-17 17:32 ---
I think Andrew is right. If you think that this is still an issue, please
reopen.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from burnus at gcc dot gnu dot org 2007-09-17 17:39 ---
For the warning that TRANSFER contains partially undefined values, see also PR
33037. For MERGE, see PR 33455
Independent of those, the following valid program still gives an ICE (if one
removes the 20 in transfer,
--- Comment #4 from manu at gcc dot gnu dot org 2007-09-17 17:56 ---
I think this is confirmed as a feature that would be nice to have. So the
install instructions should behave like the OpenMP manual here
http://gcc.gnu.org/onlinedocs/ and we will end up with:
The object renaming does not behave properly as demonstrated with the test
codes below. Note that line 11 of message_services.adb contains the problem. In
addition, if line 11 is commented out and line 12 in uncommented, the codes
behave properly.
package Message_Services is
type Message_Code
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-17 19:05 ---
Confirmed. Reverting r127960 helps.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Summary|Wrong system.ads for --with-|[4.3
--- Comment #10 from pcarlini at suse dot de 2007-09-17 19:18 ---
Not actively working on it (for now)
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-17 19:22 ---
I would strongly discourage adding this feature. A long time ago,
either Paul Brook or Steven Bosscher and I exchanged email about
the use of environmental variables to control various aspects of
gfortran. In the
Some vendors seemingly offer to set the filename of a pre-connected unit via an
environment variable.
I'm not sure we need this, but some other compilers seem to have it and it is
seemingly used:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/16d2c1d82a05edb4
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-17 20:07 ---
They're still there, but obviously no longer 4.3 material.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from rguenth at gcc dot gnu dot org 2007-09-17 20:06
---
No 4.3 pending patch anymore.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-17 20:09 ---
Queued for 4.4!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
The following valid testcase triggers an ICE on mainline
when compiled with -O:
===
inline void foo(int* p, int n)
{
for (; n 0; --n, ++p)
*p = 0;
}
struct A
{
int x[2];
A() { foo(x, 2); }
};
inline A getA() { return A(); }
struct B
{
A a;
B();
};
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33459
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-17 21:56 ---
Confirmed, inlining and RVO and RSO are interacting together interestingly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid testcase triggers an ICE since GCC 3.0:
===
struct A
{
struct
{
struct { static int i; };
void foo() { i; }
};
};
===
bug.cc:5: error: 'int A::anonymous struct::anonymous struct::i' invalid; an
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33460
1 - 100 of 125 matches
Mail list logo
