Hello list,
Yestoday I encounter this problem during a test:
1int x = 11;
2std::cout x x-- ++x;
I think it should be :
11 11 11
I wrote the fellowing code :
#include iostream
int main() {
int x = 11;
std::cout x x-- ++x std::endl;
}
compile the code above with
On 06/07/2010 09:38 AM, pem wrote:
I am not familar with both c++ and compiler implementation, donot konw
why the results are differnt for gcc and clang. Anyone could help and
explain this difference for me?
First of all, this would be a question for gcc-h...@gcc.gnu.org. This
mailing list
Sorry for missing version info of my compiler:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-
wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-
On 2010-06-06 22:34:50 +0200, Vincent Lefevre wrote:
Here's a second release candidate. As there should not be new
platform-specific problems, the final release is delayed by a
few days only.
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.xz
Hi all,
Just a reminder, as discussed on thread starting at
http://gcc.gnu.org/ml/gcc/2010-06/msg00092.html
--
Laurynas
I am not familar with both c++ and compiler implementation, donot konw
why the results are differnt for gcc and clang. Anyone could help and
explain this difference for me?
The ISO C standard says that the evaluation order of function arguments is
unspecified [ISO C99, 6.5.2.2-11], though the
On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Jun 2, 2010 at 14:09, NightStrike nightstr...@gmail.com wrote:
threads that haven't been addressed. I offered to Ian to do the same
thing for the whole mailing list if we can make it a policy that
people who
On 6/7/10, NightStrike nightstr...@gmail.com wrote:
On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Jun 2, 2010 at 14:09, NightStrike nightstr...@gmail.com wrote:
threads that haven't been addressed. I offered to Ian to do the same
thing for the whole
powerpc-ibm-aix5.3.0.0
gcc-4.4.3
gmp-4.3.1
configured using --with-gmp-build=
configure failed with missing longlong.h and gmp-impl.h. Manually
copying those header files to the build directory allowed configure
and build to succeed.
All 156 tests passed
Hi,
The libtool-2.2.8 testsuite fails some tests on darwin10 with gfortran
because it makes use of Apple ld's -force_load flag to load all members
of convenience archives. One of the tests creates link lines like:
gfortran -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
NightStrike nightstr...@gmail.com writes:
On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo dnovi...@google.com wrote:
On Wed, Jun 2, 2010 at 14:09, NightStrike nightstr...@gmail.com wrote:
threads that haven't been addressed. I offered to Ian to do the same
thing for the whole mailing list if
From http://gcc.gnu.org/ml/gcc/2009-09/msg00501.html:
we looked at the current list of primary and
secondary targets and suggested (again) to demote i686-apple-darwin to
a secondary platform on the base that it is unmaintained. We
recognize that it is used and gets many bugs filed against.
It
On 2010-06-07 10:17:18 -0400, David Edelsohn wrote:
powerpc-ibm-aix5.3.0.0
gcc-4.4.3
gmp-4.3.1
configured using --with-gmp-build=
configure failed with missing longlong.h and gmp-impl.h. Manually
copying those header files to the build directory allowed configure
and build to succeed.
Recently on #gcc, I have been conversing with several others on the
topic of patches lost in the tides of the gcc-patches mailing list. I
flagged Jeff Downs' recent message as an example of a patch that has
been waiting since November
Gerald Pfeifer wrote:
It has been reported via the FSF that 'gfortran.info' is copyrighted by
the FSF '1999-2008', although it should be under the form '1999, 2000,
[other years], 2008'.
Would you mind changing this accordingly?
Fixed in Rev. 160390 using the attached patch.
Thanks
On Mon, Jun 7, 2010 at 1:01 PM, Eric Botcazou ebotca...@adacore.com wrote:
Recently on #gcc, I have been conversing with several others on the
topic of patches lost in the tides of the gcc-patches mailing list. I
flagged Jeff Downs' recent message as an example of a patch that has
been
Annoying or not, I wasn't offering to sift through svn commit logs.
It's very trivial for me to read through a mailing list that I already
read, and scan for messages that say committed to branch B at
revision R. It's a lot more complicated to find out if something has
been committed myself,
On 06/07/2010 09:23 PM, NightStrike wrote:
Annoying or not, I wasn't offering to sift through svn commit logs.
It's very trivial for me to read through a mailing list that I already
read, and scan for messages that say committed to branch B at
revision R. It's a lot more complicated to find
On Mon, Jun 7, 2010 at 9:23 PM, NightStrike nightstr...@gmail.com wrote:
Ideally, after a day of this, people will start
sending such messages to effectively close threads, and then you'll
see very few messages from me.
That's a one way trip to my bozo bin...
Ciao!
Steven
On Mon, Jun 7, 2010 at 4:23 PM, Joern Rennecke
joern.renne...@embecosm.com wrote:
Quoting NightStrike nightstr...@gmail.com:
Annoying or not, I wasn't offering to sift through svn commit logs.
How about requiring that a patch should have an associated open PR with the
patch keyword to be
Paolo Carlini paolo.carl...@oracle.com writes:
On 06/07/2010 09:23 PM, NightStrike wrote:
Annoying or not, I wasn't offering to sift through svn commit logs.
It's very trivial for me to read through a mailing list that I already
read, and scan for messages that say committed to branch B at
On 06/07/2010 10:31 PM, Ian Lance Taylor wrote:
The question we face now is: are we willing to change our process in
order to improve it?
Maybe. Currently, I have zero problems with it.
And, if we are willing, is this specific change
a reasonable one to make?
No.
Paolo.
On Mon, 7 Jun 2010, NightStrike wrote:
I suggested that a long time ago on irc, but was brutally shot down
for it. Apparently, most people hate bugzilla :( To be clear, what I
suggested was that every patch should have a PR. There is way too
much duplication of purpose between bugzilla,
On 06/07/10 14:31, Ian Lance Taylor wrote:
The gcc project currently has a problem: when people who are not
regular gcc developers send in a patch, those patches often get
dropped. They get dropped because they do not get reviewed, and they
get dropped because after review they do not get
On 06/07/2010 11:05 PM, Jeff Law wrote:
On 06/07/10 14:31, Ian Lance Taylor wrote:
The gcc project currently has a problem: when people who are not
regular gcc developers send in a patch, those patches often get
dropped. They get dropped because they do not get reviewed, and they
get dropped
Paolo Carlini paolo.carl...@oracle.com writes:
On 06/07/2010 10:31 PM, Ian Lance Taylor wrote:
The question we face now is: are we willing to change our process in
order to improve it?
Maybe. Currently, I have zero problems with it.
I understand that you have no problems with the current
On 06/07/2010 11:16 PM, Ian Lance Taylor wrote:
Can you expand? What kinds of process changes would be reasonable to
make?
Following the terminology irregular contributor, per Jeff message, I
would not consider unreasonable for irregular contributions to use more
extensively and consistently
Paolo Carlini paolo.carl...@oracle.com writes:
This makes sense. Thinking out loud myself, even for irregular
contributors, the idea of a ping-man doesn't really sound right, it's a
boring and error-prone task. Can anybody think of a way to automate the
job? For patches corresponding to
On Mon, Jun 7, 2010 at 2:21 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 06/07/2010 11:16 PM, Ian Lance Taylor wrote:
Can you expand? What kinds of process changes would be reasonable to
make?
Following the terminology irregular contributor, per Jeff message, I
would not consider
Paolo Carlini paolo.carl...@oracle.com writes:
On 06/07/2010 11:16 PM, Ian Lance Taylor wrote:
Can you expand? What kinds of process changes would be reasonable to
make?
Following the terminology irregular contributor, per Jeff message, I
would not consider unreasonable for irregular
Jay K jay.kr...@cornell.edu writes:
I haven't tried 4.5.0 yet.
You should, all those bugs should be fixed in 4.5.0, but not all of the
fixes have been backported to the 4.4 branch yet.
-bash-4.1$ /opt/csw/gcc4/bin/g++ -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with:
On 06/07/2010 11:40 PM, Andrew Pinski wrote:
I think a big way of solving this is through a non technical solution
of having a person who just go through patches and mentors the non
regular developers.
The only point I want to stress again, or maybe clarify, is that if a
*person* is going
On 8 June 2010 00:21, Paolo Carlini paolo.carl...@oracle.com wrote:
On 06/07/2010 11:40 PM, Andrew Pinski wrote:
I think a big way of solving this is through a non technical solution
of having a person who just go through patches and mentors the non
regular developers.
The only point I want
On 7 June 2010 23:23, Ian Lance Taylor i...@google.com wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
This makes sense. Thinking out loud myself, even for irregular
contributors, the idea of a ping-man doesn't really sound right, it's a
boring and error-prone task. Can anybody think of
On 06/08/2010 02:20 AM, Manuel López-Ibáñez wrote:
Perhaps NightStrike can fine-tune his approach.
By the way, I wonder how many contributors can even think taking
seriously a message coming from NightStrike. Not me, for sure...
Paolo.
Ian Lance Taylor wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
This makes sense. Thinking out loud myself, even for irregular
contributors, the idea of a ping-man doesn't really sound right, it's a
boring and error-prone task. Can anybody think of a way to automate the
job? For
On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
On 06/07/10 14:31, Ian Lance Taylor wrote:
The gcc project currently has a problem: when people who are not
regular gcc developers send in a patch, those patches often get
dropped. They get dropped because they do not get reviewed, and
On Tue, Jun 8, 2010 at 9:14 AM, Ben White ja_wal...@sbcglobal.net wrote:
Would a modestly modified copy of Bugzilla be workable for that something?
I.E. Patchzilla?
Think about mercurial or git. Every one can commit on his/her own
local repository, and publish his/her repository. Every one
--- Comment #4 from amodra at gmail dot com 2010-06-07 06:57 ---
Actually, that's the wrong patch. The correct one stops
rs6000_split_multireg_move being called in this case, by modifying
define_mode_iterator DIFD in rs6000.md.
--
amodra at gmail dot com changed:
What
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-07 07:16 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Section 6.7.4 paragraph 3 of the ISO C99 standard states that:
An inline definition of a function with external
linkage ... shall not contain a reference to an identifier with
internal linkage.
GCC has code to check for this condition, but it does not work in C99 mode.
Reproduce by:
--- Comment #14 from sfilippone at uniroma2 dot it 2010-06-07 08:26 ---
(In reply to comment #13)
The remaining issue (comment #4/#11/#12) is being tracked by PR 44434, so this
one can be closed.
The attached variation of generic_23 still does not work.
[sfili...@donald bug15]$
--- Comment #15 from sfilippone at uniroma2 dot it 2010-06-07 08:27 ---
Created an attachment (id=20853)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20853action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #38 from rguenth at gcc dot gnu dot org 2010-06-07 08:39
---
*** Bug 44437 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-07 08:39 ---
Use STAGE1_CFLAGS=-O -g.
*** This bug has been marked as a duplicate of 37739 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
In case of wrong prerequisite versions, configure says
Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+
but the prerequisites page http://gcc.gnu.org/install/prerequisites.html says
GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
MPFR Library version 2.4.2 (or later)
MPC
Hi,
oprofiling compilation of empty file I get:
4831959.8126 no-vmlinux /no-vmlinux
3057 3.7842 ld-2.11.1.so do_lookup_x
2935 3.6331 libc-2.11.1.so memset
2921 3.6158 ld-2.11.1.so _dl_relocate_object
1589 1.9670 as
--- Comment #11 from singler at kit dot edu 2010-06-07 09:35 ---
Obviously, I'm not the only one having this problem, Jason has patched
libstdc++-v3/testsuite/util/testsuite_abi.h in the meantime.
r160313 | jason
--- Comment #16 from burnus at gcc dot gnu dot org 2010-06-07 09:41 ---
(In reply to comment #14)
The attached variation of generic_23 still does not work.
[sfili...@donald bug15]$ ./generic_23_1
FOO%DOIT base version
Aborted (core dumped)
(In reply to comment #15)
Created an
--- Comment #25 from amodra at gmail dot com 2010-06-07 09:53 ---
Yes it seems the patch is not sufficient on 4.4. On mainline the code looks
good by inspection. (I don't have e500 hardware to run tests on.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-06-07 09:54 ---
That's not an inline definition, so that constraint does not apply.
If all of the file scope declarations for a function in a translation
unit include the inline function specifier without extern, then the
--- Comment #12 from paolo dot carlini at oracle dot com 2010-06-07 10:09
---
Yes, it's a glibc bug (I don't have available any machine using that old
glibc), and if you look at the mailing list, I already commented that could be
related to your issue. I think we should use the same
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-07 10:13 ---
Prerequesites states the recommended versions, configure only tests the
minimal required versions. The inconsistency is ok.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from paolo dot carlini at oracle dot com 2010-06-07 10:18
---
As a matter of fact, in testsuite_allocator.h the problem can be solved much
more cleanly by simply qualifying with std:: the size_t and ptrdiff_t in tge
second half of the file, I can do that later today.
--- Comment #26 from amodra at gmail dot com 2010-06-07 10:29 ---
Doh! No, it's still broken on mainline too. I wasn't testing what I thought I
was...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #14 from iains at gcc dot gnu dot org 2010-06-07 10:45 ---
closing after back-porting to 4.5;
if anyone feels passionately about a merge to 4.4 ... they can re-open.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-06-07 10:57 ---
Subject: Bug 44159
Author: ktietz
Date: Mon Jun 7 10:56:44 2010
New Revision: 160363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160363
Log:
2010-06-07 Kai Tietz kai.ti...@onevision.com
PR
In this code s failbit is set if last line in s is empty (stream ends with
\n\n):
std::istream s;
//s is some kind of input stream like std::istringstream s(\n\n);
while (s.good()) {
std::string line;
std::getline(s, line);
}
--
Summary: std::getline set failbit in situation when
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-06-07 11:09 ---
Subject: Bug 44159
Author: ktietz
Date: Mon Jun 7 11:08:46 2010
New Revision: 160365
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160365
Log:
2010-06-07 Kai Tietz kai.ti...@onevision.com
Backport
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-06-07 11:09 ---
Fixed an 4.5 branch and on mainline.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from schwab at linux-m68k dot org 2010-06-07 11:19 ---
You are getting eof.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #4 from kazu at gcc dot gnu dot org 2010-06-07 11:35 ---
Posted a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #2 from qwak82 at gmail dot com 2010-06-07 11:36 ---
But also fail bit, this program prints:
line: a //this is OK, first line
line://this is also OK, second (empty) line
fail bit //eof is set - OK; but fail bit should be set here?
#include
While playing with -Warray-temporaries, I noticed that the warning is emitted
twice for RESHAPE as illustrated by the following example:
[macbook] f90/bug% cat pr36928_red.f90
! { dg-do compile }
! { dg-options -Warray-temporaries }
! PR 36928 - optimize array interleaving array temporaries
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-07 11:56 ---
[lib.string.io] paragraph 8
If the function extracts no characters, it calls is.setstate(ios_base::failbit)
which may throw ios_base::failure (27.4.4.3).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #9 from gccbug at oxyware dot com 2010-06-07 12:12 ---
The patch doesn't seem to handle != as a terminating condition:
#pragma omp parallel for
for (int i = 0; i != 1000; i++) {}
doesn't compile on 4.4.1, whereas i1000 does.
--
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-07 12:17 ---
That's correct, it shouldn't compile.
The OpenMP standard doesn't allow != comparisons in omp for condition, only ,
=, , =.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
--
fabien at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fabien at gcc dot gnu dot
|dot org
int i;
void
f1 ()
{
const int * __attribute__((unused)) a = i;
const int *b __attribute__((unused)) = i;
}
warns for a (incorrectly) and not for b in C++, in C it correctly doesn't warn
at all.
--
Summary: [4.6 Regression] -Wunused-but-set-variable problem with
struct S
{
const int u;
const int v;
S (const int a, const int b) : u(a), v(b) { }
};
bool
f1 ()
{
bool t = false;
S z = S (1, 2);
t |= z.u == 1;
t |= z.v == 2;
return t;
}
void
f2 ()
{
S z = S (1, 2);
z.u;
}
int i;
void
f3 ()
{
S z = S (1, 2);
i++, z.u;
}
warns with
--- Comment #27 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
12:49 ---
(In reply to comment #25)
Yes it seems the patch is not sufficient on 4.4. On mainline the code looks
good by inspection. (I don't have e500 hardware to run tests on.)
If you'd like login access to
--- Comment #5 from kazu at gcc dot gnu dot org 2010-06-07 13:12 ---
Subject: Bug 44404
Author: kazu
Date: Mon Jun 7 13:12:42 2010
New Revision: 160372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160372
Log:
gcc/
PR rtl-optimization/44404
* auto-inc-dec.c
--- Comment #6 from kazu at gcc dot gnu dot org 2010-06-07 13:15 ---
Fixed.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
fabien at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fabien at gcc dot gnu dot
|dot org
--- Comment #7 from kazu at gcc dot gnu dot org 2010-06-07 13:17 ---
Subject: Bug 44404
Author: kazu
Date: Mon Jun 7 13:17:32 2010
New Revision: 160374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160374
Log:
gcc/
PR rtl-optimization/44404
* auto-inc-dec.c
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-07 13:36 ---
Created an attachment (id=20854)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20854action=view)
callgrind.startup.bz2
Callgrind dump for --enable-checking=release trunk cc1 from today on an empty
file.
--
I'm trying to build a gcc cross-compiler.
The configure script was passed the following arguments: --prefix=${tools}/usr
--build=${host} --host=${host} --target=${target} --with-sysroot=${sysroot}
--with-newlib --enable-languages=c --with-gmp=${tools}/usr
--with-mpfr=${tools}/usr
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-07 13:49 ---
Useless temporaries are also emitted for PAD and ORDER optional arguments:
program main
integer :: i, k, l, m, n
real :: e1, e2
real, dimension(4,5) :: b
real, dimension(5,4) :: c
b = reshape([(i,
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-07 14:03
---
Yes, we lack *tons* of other C++0x things.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-07
14:03 ---
Subject: Re: [4.6 regression] gmp multilib support broke bootstrap with static
libgmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-04 17:48
---
First off this is not a
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-07 14:24 ---
You need to adjust LD_LIBRARY_PATH.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from zero at boolean-domain dot net 2010-06-07 14:35 ---
I obtain a similar error message when building a gcc-4.5.0 cross compiler:
/media/data/linux/sources/gcc-4.4.4-build/./gcc/xgcc
-B/media/data/linux/sources/gcc-4.4.4-build/./gcc/
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-07 14:52
---
I think Jon is right on both accounts: the request is reasonable, but, even
before that last changes, thus since the very beginning of v3:
if (!__r)
__r = __size - __osize;
thus, I think
--- Comment #14 from paolo dot carlini at oracle dot com 2010-06-07 15:17
---
Created an attachment (id=20855)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20855action=view)
Tentative patch (only sanity checked on a system not affected by the glibc
issue)
--
--- Comment #15 from paolo dot carlini at oracle dot com 2010-06-07 15:23
---
Johannes, can you try the patch and in case, give me some details about the
remaining issues? The idea is simply that if a glibc header has been included
by cwctype before wctype.h, then __GLIBC__ is defined
--- Comment #4 from meklund at cisco dot com 2010-06-07 15:26 ---
I see your point that some legacy code might use a larger size as a flexible
array.
What is you opinion on the possibility of adding a bit-flag to
__builtin_object_size() (like 0x04) that tightens the allowed flexible
--- Comment #16 from paolo dot carlini at oracle dot com 2010-06-07 15:27
---
Errata: ... by cwctype before wctype.h... should read ... before
cwctype wants to include wctype.h...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
When compiling the attached code with gfortran I get:
procedure(i_f), pointer, protected :: p_f = null()
1
Error: PROTECTED attribute conflicts with EXTERNAL attribute at (1)
I think that the code is legal, according to the standard
C535 (R501) The
--- Comment #12 from jason at gcc dot gnu dot org 2010-06-07 15:51 ---
Suspending.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-07 15:58 ---
Untested:
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -567,8 +567,9 @@ check_conflict (symbol_attribute *attr, const char *name,
locus *where)
}
conf (is_protected, intrinsic)
- conf
--- Comment #2 from mikael at gcc dot gnu dot org 2010-06-07 15:59 ---
(In reply to comment #1)
Useless temporaries are also emitted for PAD and ORDER optional arguments:
This is a known limitation of array constructors handling by gfortran.
For passing to the library function, a
Occurred on Windows Vista, with GCC 4.5.0 and 4.4.0 and -masm=intel and -Ox
x0,
the code generation produces a faulty output with -O1 and a faulty control frow
leading to SIGSEGV when -O2 or -O3.
When -masm=intel or -Ox deleted, no SIGSEGV occurs and output is right.
This phenomena doesn't occur
--- Comment #1 from dg dot recrutement31 at gmail dot com 2010-06-07 16:20
---
Created an attachment (id=20856)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20856action=view)
source file in which a faulty control flow occurs.
Compiled with gcc 4.5 with the following potions:
--- Comment #11 from manu at gcc dot gnu dot org 2010-06-07 16:21 ---
(In reply to comment #10)
That's correct, it shouldn't compile.
The OpenMP standard doesn't allow != comparisons in omp for condition, only ,
=, , =.
Is it so difficult to write that in the error message? Would
--- Comment #2 from dg dot recrutement31 at gmail dot com 2010-06-07 16:24
---
(From update of attachment 20856)
The program in which this bug occurs have been tested with valgrind that does
not reveal memory leak and other bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-07
16:32 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
I've now analysed this further: the test only fails at -O3. The failure
is an abort in
The last remaining gfortran testsuite failure on Solaris 10/11 x86 is
FAIL: gfortran.dg/atan2_1.f90 -O0 execution test
(only for 32-bit). The test aborts at l.12:
do i = 1, 10
if(atan(1.0, i/10.0) -atan2(1.0, i/10.)/= 0.0) call abort()
--- Comment #18 from ro at gcc dot gnu dot org 2010-06-07 16:48 ---
Created an attachment (id=20857)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20857action=view)
assembler output at -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #19 from ro at gcc dot gnu dot org 2010-06-07 16:49 ---
Created an attachment (id=20858)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20858action=view)
assembler output at -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
1 - 100 of 192 matches
Mail list logo
