--- 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 dep
--- 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 uc
--- 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 (0ma
--- 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
--- 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).
--
http://gcc.gnu.org/bugz
--- 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
--- 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 -whole-f
--- 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 1
--- 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
bb(1
--- 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 exce
This is well-formed, but GCC does not like it
#include
template
void f(T) { }
int main() {
std::initializer_list a = { 0 };
f(a);
}
main1.cpp: In function 'int main()':
main1.cpp:8:6: warning: deducing 'T' as 'std::initializer_list'
main1.cpp:4:6: warning: in call to 'void f(T) [with T =
--- 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
--- 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:
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_cast(x);', and two successive assertions should be passed.
However, it seems that the implicitly defined copy constructor is called, and
the s
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 regist
--- 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=20672&action=view)
Assembly that shows unsupported registry saves
This assembly is made from:
/opt/build/x86_64-pc-linux/x86_64-w64-
--- 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
COLLECT_LTO_WRAPPER=/home/cryolite/
--- 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 commen
--- 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 t
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-16 17:08 ---
(In reply to comment #1)
> Y y( static_cast(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
> ___emutls_v._ZZN1
--- 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 mere
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 testsuite/gcc.target/i386/funcspec-4.c
--- 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=20673&action=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=20674&action=view)
Test success example
Runtest with the warning removed from config/i386/cygming.h
Shows that the tests will succee
--- 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=20675&action=view)
reduced test case
A reduced test case that failes in the same way.
--
toon at moene dot org changed:
Wha
--- 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:
>
QI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0x7
--- 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
--
htt
--- 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=gcc&view=rev&rev=159465
Log:
gcc/fortran/:
2010-05-16 Daniel Franke
PR fortran
--- 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
>
> PR fortran/35779
> * array.c (match_array_list): Revert functional change of 2010-05-13.
Back to square one.
--
dfranke at gcc dot gn
--- 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 |Adde
--- 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, dimensi
--- 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
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);
X
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 ) {}
--- 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 15944
--- 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 expression
--
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 "Enhanc
--
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 #14 from jakub at gcc dot gnu dot org 2010-05-17 06:04 ---
The #c6 patch is now in, but #c3 not yet. Unfortunately that one needs more
work, see comment #c8.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from potswa at mac dot com 2010-05-17 06:06 ---
Sorry, that was completely wrong. I thought I'd isolated a testcase with the
above code plus int main() { return rcv_f(f); }, but that actually
does work.
It seems the problem is completely different. The testcase below sugg
62 matches
Mail list logo
