--- Comment #2 from jv244 at cam dot ac dot uk 2010-02-21 09:12 ---
seemingly being discussed, since useful for tonto
http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #31 from paolo dot carlini at oracle dot com 2010-02-21 09:51
---
(In reply to comment #30)
Wouldn't it be a violation of the one definition rule (ODR),
when one translation unit is compiled with -fwrapv and another without?
In that case this would be a regression.
I
--- Comment #23 from paul dot richard dot thomas at gmail dot com
2010-02-21 10:43 ---
Subject: Re: spurious _gfortran_internal_pack
I was going to check out the situation for 4.4. However, my
inclination is to close it. I'll be working on it tonight.
Cheers
Paul
On Sat, Feb 20,
--- Comment #6 from paul dot richard dot thomas at gmail dot com
2010-02-21 10:43 ---
Subject: Re: unneeded temporary (s=s+f(a))
Same as 41113 - I'll decide what to do tonight - see you on #gfortran?
Paul
On Sat, Feb 20, 2010 at 10:48 PM, burnus at gcc dot gnu dot org
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-21 11:06 ---
(In reply to comment #2)
seemingly being discussed, since useful for tonto
http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html
But there: it's unfortunately not possible to avoid the temporary creation
without
Seen with gcc 4.4.0:
$ gcc temp.cpp -I../..
In file included from temp.cpp:2:
../../gptm/thread_scope_new.h:128: internal compiler error: tree check:
expected class type, have exceptional (identifier_node) in
constructor_name_full, at cp/name-lookup.c:1777
Please submit a full bug report,
--- Comment #1 from kian dot karas dot dev at gmail dot com 2010-02-21
12:02 ---
Created an attachment (id=19931)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19931action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43131
--- Comment #4 from jv244 at cam dot ac dot uk 2010-02-21 12:11 ---
(In reply to comment #3)
(In reply to comment #2)
seemingly being discussed, since useful for tonto
http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html
But there: it's unfortunately not possible to avoid
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-21 12:19
---
I can't reproduce this with the *released* gcc4.4.0 or current gcc-4_4-branch,
I get instead:
../../gptm/thread_scope_new.h:128: error: declaration of ~ThreadScopeNew as
member of
--- Comment #32 from veksler at il dot ibm dot com 2010-02-21 12:44 ---
(In reply to comment #31)
(In reply to comment #30)
Wouldn't it be a violation of the one definition rule (ODR),
when one translation unit is compiled with -fwrapv and another without?
In that case this
--- Comment #41 from dominiq at lps dot ens dot fr 2010-02-21 12:46 ---
AFAICT this pr and the side effects have been fixed, hence closing. If someone
disagree, please reopen.
Thanks all for the work.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #14 from dominiq at lps dot ens dot fr 2010-02-21 12:47 ---
Closing as fixed. Thanks for the patch.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #11 from dominiq at lps dot ens dot fr 2010-02-21 12:49 ---
Any plan to backport the fix to 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
--- Comment #12 from rguenther at suse dot de 2010-02-21 12:50 ---
Subject: Re: [4.4 Regression] virtual memory exhausted:
Cannot allocate memory
On Sun, 21 Feb 2010, dominiq at lps dot ens dot fr wrote:
--- Comment #11 from dominiq at lps dot ens dot fr 2010-02-21 12:49
--- Comment #33 from paolo dot carlini at oracle dot com 2010-02-21 12:53
---
(In reply to comment #32)
If this hazard is so prevalent shouldn't it deserve a separate PR?
If a method or function depend on a flag or macro then it can be handled
by overloading and specialization
--- Comment #34 from rguenth at gcc dot gnu dot org 2010-02-21 13:04
---
(In reply to comment #33)
(In reply to comment #32)
If this hazard is so prevalent shouldn't it deserve a separate PR?
If a method or function depend on a flag or macro then it can be handled
by overloading
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-21 13:06 ---
Subject: Bug 35259
Author: burnus
Date: Sun Feb 21 13:06:07 2010
New Revision: 156937
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156937
Log:
2010-02-21 Tobias Burnus bur...@net-b.de
PR
--- Comment #7 from burnus at gcc dot gnu dot org 2010-02-21 13:06 ---
FIXED on the (4.5) trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from veksler at il dot ibm dot com 2010-02-21 13:33 ---
(In reply to comment #34)
(In reply to comment #33)
(In reply to comment #32)
If this hazard is so prevalent shouldn't it deserve a separate PR?
If a method or function depend on a flag or macro then it can
--- Comment #36 from rguenther at suse dot de 2010-02-21 13:37 ---
Subject: Re: numeric_limitssigned::is_modulo is
inconsistent with gcc
On Sun, 21 Feb 2010, veksler at il dot ibm dot com wrote:
Or suspend it. I think this warrants a defect report anyway since I think
is_modulo
--- Comment #9 from jv244 at cam dot ac dot uk 2010-02-21 14:11 ---
(In reply to comment #7)
(In reply to comment #3)
This could be somewhat similar, I really wonder if this needs a temp:
TYPE T1
INTEGER :: a(3)
END TYPE T1
TYPE(T1), POINTER :: x,y
ALLOCATE(x,y)
--- Comment #14 from jv244 at cam dot ac dot uk 2010-02-21 14:12 ---
all fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|NEW
--- Comment #24 from jv244 at cam dot ac dot uk 2010-02-21 14:16 ---
(In reply to comment #23)
Subject: Re: spurious _gfortran_internal_pack
I was going to check out the situation for 4.4. However, my
inclination is to close it. I'll be working on it tonight.
this is not stuff
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-21 14:32 ---
I have played with CSiBE with this patch:
-- 8 -
--- ../../gcc/gcc/config/arm/arm.c 2010-02-12 21:45:29.0 +0100
+++
--- Comment #7 from hjl dot tools at gmail dot com 2010-02-21 15:39 ---
It also failed on Linux/x86-64 with -m32:
FAIL: c-c++-common/pr41779.c -Wc++-compat (test for warnings, line 30)
--
hjl dot tools at gmail dot com changed:
What|Removed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |c
Ever
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-02-21 15:59
---
An update. I have a patch developing. Conceptually, it requires handling of
separators in list_read.c to be moved to the beginning of each invocation of
list_formatted_read_scalar. This avoids trying to
--- Comment #5 from rwild at gcc dot gnu dot org 2010-02-21 16:13 ---
Thanks for the logs. I don't understand the libiberty installation failure
yet. Can you please run the following, and provide the log file and the number
of runs needed, in case it provokes a failure?
while make
--- Comment #8 from hjl dot tools at gmail dot com 2010-02-21 16:15 ---
It is C99 and ILP32:
[...@gnu-6 gcc]$ ./xgcc -B./ -S
/export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/pr41779.c -Wconversion
-m32 -std=c99
[...@gnu-6 gcc]$ ./xgcc -B./ -S
--- Comment #13 from agner at agner dot org 2010-02-21 16:21 ---
What is the status of this issue?
Is option 3 implemented?
Which versions of Linux and binutils support IFUNC?
Any plans for BSD and Mac?
--
agner at agner dot org changed:
What|Removed
Since the update to Autoconf = 2.60, the installation directory defaults
do not match the GNU Coding Standards, nor do they match the semantics
documented in the manual. The problems are described in more detail in
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00696.html.
Opening this bug so that
The autotools upgrade (specifically, the move to Autoconf = 2.60) changed
installation directory variable defaults. This patch
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01598.html
would do that, but it is not correct as of now, because of the issues
mentioned in PR 43132 and in
Since the update to Autoconf = 2.60, the installation directory defaults
do not match the GNU Coding Standards, nor do they match the semantics
documented in the manual. The problems are described in more detail in
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00696.html.
Opening this bug so that
--- Comment #1 from rwild at gcc dot gnu dot org 2010-02-21 16:28 ---
sorry for the dupe
*** This bug has been marked as a duplicate of 43132 ***
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rwild at gcc dot gnu dot org 2010-02-21 16:28 ---
*** Bug 43134 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #14 from hjl dot tools at gmail dot com 2010-02-21 16:34
---
(In reply to comment #13)
What is the status of this issue?
It is implemented on ifunc branch.
Is option 3 implemented?
Yes, on ifunc branch.
Which versions of Linux and binutils support IFUNC?
You need at
--- Comment #9 from hjl dot tools at gmail dot com 2010-02-21 16:46 ---
On Linux/ia32, -std=c99 changes silently float to long double
and we don't get a warning. It is a regression from gcc 4.4.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #3 from dodji at gcc dot gnu dot org 2010-02-21 16:47 ---
Okay Daniel, your POV makes sense to me. Thank you.
I am preparing a patch.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2010-02-21 16:47
---
[...@gnu-6 gcc]$ cat /tmp/x.i
float f5(float x, int y)
{
return x * y;
}
[...@gnu-6 gcc]$ gcc -S /tmp/x.i -Wconversion -m32 -std=c99
/tmp/x.i: In function f5:
/tmp/x.i:3: warning: conversion to float from
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-21 17:25 ---
I may have miscompared the bootstrap results to miss this because I do test
-m32.
Yes, the excess precision stuff changes the common type to long double in
build_binary_op in C and -m32 (but not in C++!).
Joseph, is
--- Comment #2 from rwild at gcc dot gnu dot org 2010-02-21 17:27 ---
I think one way to start addressing this would be to transport an unexpanded
docdir='${datarootdir}/doc/${PACKAGE}'
through to the sub makes (it's fairly irrelevant whether datarootdir is
expanded
in the toplevel
--- Comment #12 from joseph at codesourcery dot com 2010-02-21 17:43
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
There is a technical bug here, in that the semantics I intended to
implement and said I was implementing were that implicit conversions from
--- Comment #13 from manu at gcc dot gnu dot org 2010-02-21 17:57 ---
(In reply to comment #12)
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
Sorry I do not understand completely your answer. Shouldn't we warn at all? If
the semantics were implemented as
--- Comment #14 from hjl dot tools at gmail dot com 2010-02-21 18:00
---
That is true that the previous release didn't have proper excess
precision semantics. But from the user perspective, the previous
release handles
--
float f5(float x, int y)
{
return x * y;
}
--
correctly with
--- Comment #37 from gdr at integrable-solutions dot net 2010-02-21 18:04
---
Subject: Re: numeric_limitssigned::is_modulo is
inconsistent with gcc
On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
Or suspend it. I think this
--- Comment #14 from dodji at gcc dot gnu dot org 2010-02-21 18:07 ---
Subject: Bug 42824
Author: dodji
Date: Sun Feb 21 18:06:39 2010
New Revision: 156939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156939
Log:
Fix PR c++/42824
gcc/cp/ChangeLog:
PR c++/42824
--- Comment #15 from joseph at codesourcery dot com 2010-02-21 18:15
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote:
Sorry I do not understand completely your answer. Shouldn't we warn at all? If
the
--- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 ---
(In reply to comment #37)
is_modulo is intended to describe the implementation's choice, not necessarily
the CPU behaviour (which the implementation may choose to mask or not.)
The issue here is that GCC does
--- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 ---
(In reply to comment #15)
With the intended semantics, we should warn; there would be an actual
conversion from integer to float there, that could change the value.
Great. Any hints where could be the problem or
--- Comment #17 from joseph at codesourcery dot com 2010-02-21 18:32
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote:
--- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 ---
(In
--- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50
---
Subject: Re: numeric_limitssigned::is_modulo is
inconsistent with gcc
On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #38 from
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-21 19:07 ---
More weirdeness.
// PR c++/17459: Spurious message when forgetting parentheses on call of member
// { dg-do compile }
struct S {
void foo();
void bar() { foo; } // { dg-error statement cannot resolve address of
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-21 19:17 ---
(In reply to comment #5)
Is there any chance of activity on this bug?
It would be wonderful to have a warning for this
case, since these bugs can be extremely annoying to find.
-Winit-self is generally broken for
--- Comment #6 from dodji at gcc dot gnu dot org 2010-02-21 20:19 ---
The resolution of PR c++/43036 seems related to array types only. So I don't
understand why it fixes this PR. I'd like to investigate a bit further.
The test case is too big for me to understand it so I am
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-21 21:20 ---
Subject: Bug 23510
Author: manu
Date: Sun Feb 21 21:20:04 2010
New Revision: 156942
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156942
Log:
2010-02-21 Manuel López-Ibáñez m...@gcc.gnu.org
PR
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-21 21:21 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from galtgendo at o2 dot pl 2010-02-21 21:22 ---
There's new input in a different Gentoo bug:
http://bugs.gentoo.org/show_bug.cgi?id=305333
Apparently in certain conditions on ppc,
bool is both defined and undefined.
Unless you'll see that as bad code on openjpeg side.
--- Comment #1 from davek at gcc dot gnu dot org 2010-02-21 22:27 ---
just ran into this myself!
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-21 23:21 ---
So this is confirmed, yes? no? Joseph?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from grosser at gcc dot gnu dot org 2010-02-22 00:42 ---
I believe this commit introduced the bug:
Remove COMPONENT_REF limitation in SCoP detection.
2010-01-08 Sebastian Pop sebastian@amd.com
* graphite-scop-detection.c (exclude_component_ref):
--- Comment #17 from hp at gcc dot gnu dot org 2010-02-22 01:31 ---
(In reply to comment #13)
Is this still an issue? To be honest I have no idea if this target is still in
good shape or not...
Not that this PR is dependent on the shape of the port, but at r156927 it was
in
I'm reporting this against my system compiler (4.1.2 on NetBSD/macppc), but I
can reproduce it using all versions from 3.4 (when two-stage name lookup was
introduced) to 4.4 - which I was able to test on a linux/amd64 machine with a
large collection of compilers installed.
The following code
--- Comment #1 from uwe at netbsd dot org 2010-02-22 02:51 ---
Created an attachment (id=19932)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19932action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
--- Comment #2 from bangerth at gmail dot com 2010-02-22 03:56 ---
This is not a bug. Because the base class of Node::OpNode does not
depend on template arguments, the members of the base class are
visible in Node::OpNode::f(). On the other hand, since the base
class of Node::FooOpNode
--- Comment #3 from uwe at netbsd dot org 2010-02-22 04:08 ---
(In reply to comment #2)
This is not a bug. Because the base class of Node::OpNode does not
depend on template arguments, the members of the base class are
visible in Node::OpNode::f(). On the other hand, since the base
--- Comment #4 from bangerth at gmail dot com 2010-02-22 04:29 ---
(In reply to comment #3)
But doesn't this error happens during instantiation as the error message
indicates? If definition of Node::FooNode is commented out, the templates
themselves are accepted.
What I meant to
--- Comment #5 from uwe at netbsd dot org 2010-02-22 04:45 ---
(In reply to comment #4)
What I meant to say is this: during parsing ...
So do I get this right (knowing nothing about g++ internals) that in the first
phase (during parsing) the call to test is resolved to sibling
--- Comment #6 from uwe at netbsd dot org 2010-02-22 04:47 ---
(In reply to comment #5)
What confuses me is that explictly qualifying the offending call as
Node::test(op.i)
makes it compile correctly.
I mean as far as I understand Node::test should resolve to the same sibling,
--- Comment #7 from pault at gcc dot gnu dot org 2010-02-22 05:44 ---
Subject: Bug 43072
Author: pault
Date: Mon Feb 22 05:43:57 2010
New Revision: 156949
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156949
Log:
2010-02-22 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #25 from pault at gcc dot gnu dot org 2010-02-22 05:45 ---
Fixed on trunk. Thanks for reportimg the problems and all the help, Tobias and
Joost.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2010-02-22 05:45 ---
Fixed on trunk. Thanks for reportimg the problems and all the help, Tobias and
Joost.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-22 05:48 ---
Fixed on trunk. Thanks for reportimg the problem, Joost.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
After fixing, 43072 and friends, one excess copy-in and copy-out remains, where
a substring describes the declared string length. The testcase is in
internal_pack_9.f90:
subroutine foo2
implicit none
external foo
character(len=20) :: str(2) = '1234567890'
call foo(str(:)(1:20)) ! This is
--- Comment #39 from amylaar at gcc dot gnu dot org 2010-02-22 06:04
---
(In reply to comment #38)
Maybe this issue migrated into PR31849?
Not entirely, PR31849 is tree-optimization, and a lot of auto-increment
opportunities are only visible at the rtl level.
--
--- Comment #18 from hp at gcc dot gnu dot org 2010-02-22 07:05 ---
Results at http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02083.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
78 matches
Mail list logo
