--- Comment #9 from bdubbs at linuxfromscratch dot org 2010-05-16 06:38
---
I have traced the problem file for this bug to the kernel file
arch/x86/kernel/tsc.c
I have two source trees for the 2.6.33.4 kernel, one compiled with gcc-4.4.1
which works and gcc version 4.5.1 20100514
--- Comment #1 from jv244 at cam dot ac dot uk 2010-05-16 06:57 ---
reduced testcase:
module mod_tetgen
use iso_c_binding
type tetgenio
double precision, pointer :: pointlist(:,:)
integer :: numberoffacets = 0
end type tetgenio
contains
subroutine tetgenf( in, out )
--- Comment #8 from tkoenig at gcc dot gnu dot org 2010-05-16 09:00 ---
Richard, what do you think of this?
Does it make sense to do the dependency analysis in the
front end?
Does Graphite (about which I know next to nothing, I admit) have
the necessary infrastructure to detect the
--- Comment #27 from dougmencken at gmail dot com 2010-05-16 09:15 ---
This is actually not a regression. It all belongs to my setup: I'm using
busybox (without any coreutils and other shells) and uclibc. Here's the diff
made from bootstrap directories from my setup and gentoo stage 2
--- Comment #15 from iains at gcc dot gnu dot org 2010-05-16 09:32 ---
(In reply to comment #13)
(In reply to comment #12)
2/ m64 we get this :
mini-02-sno:gcc-4-6-trunk-build $ otool -rv
x86_64-apple-darwin10//libstdc++-v3/libsupc++/.libs/libsupc++.a |grep emu
002c True
--- Comment #22 from dcb314 at hotmail dot com 2010-05-16 10:21 ---
(In reply to comment #21)
Assuming this is fixed. If you have a new testcase, please file a new PR.
I am not sure that my original bug report is fixed.
I tried 4.6 snapshot 20100515 and it couldn't compile it in ten
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-16 10:30 ---
It makes sense to do this in the frontend. The worst thing is when the
frontend
creates array temporaries - those are really really hard to get rid of in the
middle-end.
There are basically two (or maybe two and a
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-05-16 10:49
---
I see
variable tracking : 734.06 (99%) usr 0.33 (35%) sys 735.29 (99%) wall
11548 kB ( 8%) ggc
...
743.18user 1.00system 12:25.12elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+10440outputs
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-16 10:53 ---
(In reply to comment #5)
A few comments:
(1) adding -flto or -fwhopr solves the linking problem for the polyhedron
tests
and the reduced one in comment #1.
(2) the test in comment #4 is different as it
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-16 10:54 ---
*** Bug 44153 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-16 10:54 ---
-fwhopr is known to be broken in 4.5.x.
*** This bug has been marked as a duplicate of 41734 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-16 10:56 ---
(In reply to comment #3)
Why is flag_exceptions not just streamed out/in with other options?
It is, but the option merging is basically broken by design (and comes too
late anyway).
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-16 10:58 ---
(In reply to comment #2)
OK, here's what's going wrong:
The LTO design is such that EH is only enabled if we encounter a function with
an EH personality.
With -fwhopr we process one translation unit at a
--- Comment #7 from dominiq at lps dot ens dot fr 2010-05-16 11:00 ---
-fwhole-program enables -fwhole-file.
Yes, but -fwhole-file does not enable -fwhole-program. All the polyhedron tests
pass with -fwhole-file (and say -O3 -ffast-math), but the test in comment #4
fails with
--- Comment #8 from rguenther at suse dot de 2010-05-16 11:04 ---
Subject: Re: -fwhole-file -fwhole-program: Wrong decls
cause too much to be optimized away
On Sun, 16 May 2010, dominiq at lps dot ens dot fr wrote:
--- Comment #7 from dominiq at lps dot ens dot fr 2010-05-16
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16 11:16 ---
You cant' compare -fwhole-file numbers to -fwhole-program numbers.
-fwhole-file is a correctness option, w/o it the Frontend generates
an invalid representation for the middle-end.
Well, from what I saw running
--- Comment #10 from rguenther at suse dot de 2010-05-16 11:21 ---
Subject: Re: -fwhole-file -fwhole-program: Wrong decls
cause too much to be optimized away
On Sun, 16 May 2010, dominiq at lps dot ens dot fr wrote:
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16
Strictly speaking, we should get -0.0 in all cases.
i...@linux-fd1f:~/Fort cat intrinsic_signed_zero.f90
program main
implicit none
real, dimension(1) :: a, b
real, dimension(1,1) :: aa, bb
a(1) = -1.0
b(1) = 0.0
print *,a(1)*b(1)
print *,dot_product(a,b)
aa(1,1) = -1.0
--- Comment #3 from pluto at agmk dot net 2010-05-16 12:22 ---
*** This bug has been marked as a duplicate of 41371 ***
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #24 from pluto at agmk dot net 2010-05-16 12:22 ---
*** Bug 43776 has been marked as a duplicate of this bug. ***
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #25 from pluto at agmk dot net 2010-05-16 12:26 ---
PR43776 constains another thestcase:
results for top of 4.5/4.6:
$ time g++45 -Wall -c 1.ii -O1 -g2
1.ii: In member function 'void es::ClockAnalyzer::initPrimitives()':
1.ii:38722:7: note: variable tracking size limit
This is well-formed, but GCC does not like it
#include initializer_list
templatetypename T
void f(T) { }
int main() {
std::initializer_listint a = { 0 };
f(a);
}
main1.cpp: In function 'int main()':
main1.cpp:8:6: warning: deducing 'T' as 'std::initializer_listint'
main1.cpp:4:6: warning:
--- Comment #16 from iains at gcc dot gnu dot org 2010-05-16 12:56 ---
leaving off the eh and debug stuff look at
.text
__ZN12_GLOBAL__N_110get_globalEv:
LFB100:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
reference a variable relative to the instruction
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 ---
(In reply to comment #16)
leaving off the eh and debug stuff look at
.text
__ZN12_GLOBAL__N_110get_globalEv:
LFB100:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
reference a
In the following code, the X's move constructor (the constructor overloaded for
rvalue reference) should be called for the copy-initialization
`X y = static_castX(x);', and two successive assertions should be passed.
However, it seems that the implicitly defined copy constructor is called, and
the
On x86_64-w64-mingw32 targets, during tests such as avx-vaddpd-1.c, the
testsuite fails. This seems to be due to the fact that the test function is
inlined into main. Due to this inlining, some of the the xmm registers are
saved and restored. However, because the -mavx flag is passed, the
--- Comment #1 from dougsemler at gmail dot com 2010-05-16 14:23 ---
Created an attachment (id=20672)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20672action=view)
Assembly that shows unsupported registry saves
This assembly is made from:
--- Comment #18 from iains at gcc dot gnu dot org 2010-05-16 14:26 ---
(In reply to comment #13)
(In reply to comment #12)
that doesn't really explain why this should be repeatably affected by the
reversion of 159371..
Yesterday (on an initially failing bootstrap) I applied the
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-16 14:40 ---
(In reply to comment #8)
This is fixed by this patchlet (which is part of patch in comment #1):
This patch breaks gfortran.dg/allocatable_scalar_9.f90 (Segmentation fault) and
some variants I have in my tests.
--
The following code causes a mysterious error.
__FUNCTION__ and __PRETTY_FUNCTION__ cause the same problem as __func__, too.
cryol...@thinblue:~/work/gcc_bug/func_in_lambda$ g++-4.5.0 -v -save-temps
-std=c++0x main.cpp
Using built-in specs.
COLLECT_GCC=g++-4.5.0
--- Comment #19 from hubicka at ucw dot cz 2010-05-16 15:00 ---
Subject: Re: r159371 breaks bootstrap on
x86_64-apple-darwin10
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51
---
(In reply to comment #16)
leaving off the eh and debug
--- Comment #20 from iains at gcc dot gnu dot org 2010-05-16 15:15 ---
(In reply to comment #19)
Subject: Re: r159371 breaks bootstrap on
x86_64-apple-darwin10
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51
---
(In reply to comment #16)
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-16 16:19 ---
The generated code is fine. The F2003 standard states on page 38.
The real type includes a zero value. Processors that distinguish between
positive and negative zeros shall treat them as equivalent
(1) in
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-16 17:07 ---
The rules say that for copy-initialization where the source type (X) is not
the same as the destination type (X) a temporary is created. That temporary is
copy-constructed from x, then y is move-constructed from the
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-16 17:08 ---
(In reply to comment #1)
Y y( static_castX(x) );
^
Oops. I meant X not Y
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44158
--- Comment #21 from hubicka at ucw dot cz 2010-05-16 17:22 ---
Subject: Re: r159371 breaks bootstrap on
x86_64-apple-darwin10
hmmm.. I don't quite understand this..
the original ld error was:
ld: codegen problem, can't use rel32 to external symbol
--- Comment #29 from rwild at gcc dot gnu dot org 2010-05-16 17:32 ---
(In reply to comment #27)
You mean the patch in Comment # 20? Because it seems an hack to me. Maybe Ralf
is willing to explain why is the only possible fix.
Oh, I don't think it's the only possible fix, it's
In some cases, __attribute__((__target__(...))) causes spurious warnings about
-fpic not being supported on the target.It seems at some point flag_pic may
be reset, even though the option is not passed via the command line.
These spurious warnings cause
--- Comment #1 from dougsemler at gmail dot com 2010-05-16 17:40 ---
Created an attachment (id=20673)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20673action=view)
Test failure example
Testsuite i386.exp=func-spec*.c
Shows test failures in -4 and -8 due to excess warnings.
--
--- Comment #2 from dougsemler at gmail dot com 2010-05-16 17:42 ---
Created an attachment (id=20674)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20674action=view)
Test success example
Runtest with the warning removed from config/i386/cygming.h
Shows that the tests will succeed
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-16 18:29
---
This is invalid then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from toon at moene dot org 2010-05-16 18:35 ---
Created an attachment (id=20675)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20675action=view)
reduced test case
A reduced test case that failes in the same way.
--
toon at moene dot org changed:
What
--- Comment #3 from toon at moene dot org 2010-05-16 18:51 ---
It might be useful to compare the two decls that invoke the mismatch that
triggers the gcc_assert:
prevailing-decl is:
function_decl 0x7fb0f574f900 convect_satmixratio
type function_type 0x7fb0f5786b28
type
--- Comment #2 from tkoenig at netcologne dot de 2010-05-16 19:03 ---
Subject: Re: dot_product / matmul and signed zeros
kargl at gcc dot gnu dot org wrote:
The generated code is fine. The F2003 standard states on page 38.
The real type includes a zero value. Processors that
--- Comment #4 from redi at gcc dot gnu dot org 2010-05-16 19:34 ---
it might be a valid enhancement request, as I think the temporary is eligible
for copy-elision (Jason?) but the compiler isn't required to elide it, so it is
wrong to assert that a temporary won't be created
--
--- Comment #3 from cestrauss at gmail dot com 2010-05-16 20:00 ---
I can confirm this mingw32 libgcj build failure exists on current trunk (4.6.0
revision 159436). The original patch attached to this report does solve the
issue for me, after updating it so it applies cleanly.
Regards,
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-16 20:01 ---
Subject: Bug 35779
Author: dfranke
Date: Sun May 16 20:01:06 2010
New Revision: 159465
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159465
Log:
gcc/fortran/:
2010-05-16 Daniel Franke
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-16 20:03
---
(In reply to comment #9)
2010-05-16 Daniel Franke franke.dan...@gmail.com
PR fortran/35779
* array.c (match_array_list): Revert functional change of 2010-05-13.
Back to square one.
--
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-16 20:05
---
Relevant ML discussion starts here:
http://gcc.gnu.org/ml/fortran/2010-05/msg00165.html
Unassigning myself.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-16 20:17 ---
The simplifiers show the same behaviour:
$ cat pr44156.f90
program main
implicit none
real, dimension(1), parameter :: a = -1.0, b = 0.0
real, dimension(1,1), parameter :: aa = -1.0, bb = 0.0
real,
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-16 20:24 ---
*** This bug has been marked as a duplicate of 40963 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-16 20:24 ---
*** Bug 44155 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from janus at gcc dot gnu dot org 2010-05-16 20:33 ---
(In reply to comment #17)
So it seems tht the bug is not gone. I have tried again with version from May
8th and I still get the problem on line 556.
Yes, the issue is not fixed yet. The commit in comment #16 was
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-05-16 21:09 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01209.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-16 21:25
---
To be safe, let's reopen the bug. For the record, this works:
#include cassert
struct X
{
X(int i) : i_(i) {}
X(X x) : i_(x.i_) { x.i_ = 0; }
int i_;
X(const X) = delete;
};
int main()
{
X x(42);
Given some function
void ff(); // any signature
This function is callable:
void rcv_f( typename std::enable_if true, decltype(ff) ::type const f ) {}
This function template does not produce a candidate:
template class F
void rcv_f( typename std::enable_if true, F ::type const f ) {}
This
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-16 22:11 ---
The ICE is fixed by removing this unneeded (and buggy) piece of code:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-16 22:17
---
Please provide a short self-contained testcase, thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2010-05-16 22:32 ---
(In reply to comment #1)
The rules say that for copy-initialization where the source type (X) is not
the same as the destination type (X) a temporary is created.
But the source type is X; there are no expressions
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #15 from rob1weld at aol dot com 2010-05-17 02:34 ---
(In reply to comment #13)
Subject: Re: Configure scripts have no 64-Bit Solaris defined (only
i386-solaris*).
--- Comment #12 from rob1weld at aol dot com 2010-05-04 07:20 ---
This is an Enhancement
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
62 matches
Mail list logo
