--- Comment #6 from hjl at gcc dot gnu dot org 2010-02-28 07:56 ---
Subject: Bug 43202
Author: hjl
Date: Sun Feb 28 07:56:36 2010
New Revision: 157119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157119
Log:
Don't set the default arch for i[34567]86-*-darwin*|x86_64-*-darwin*.
--- Comment #5 from hjl dot tools at gmail dot com 2010-02-28 07:24 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|WAITING
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-28 07:23 ---
Subject: Bug 43202
Author: hjl
Date: Sun Feb 28 07:23:31 2010
New Revision: 157118
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157118
Log:
Restore i[34567]86-*-darwin* bootstrap.
2010-02-27 H.J. Lu
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-28 00:21
---
Actually, I'm thinking that *a few* times already we noticed that something was
going wrong with inlining thanks to those slightly loose patterns. Thus,
assuming nobody disagrees, I would just close this PR ex
--- Comment #11 from 4ernov at gmail dot com 2010-02-28 00:21 ---
Ok, thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-28 00:16
---
You are welcome. Don't worry, anyway, let's keep it open for now, maybe I'll
tweak the patterns for 4.5.0, cannot hurt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
--- Comment #9 from 4ernov at gmail dot com 2010-02-28 00:14 ---
Paolo, thank you very much for informing me and sorry for some off-topic, but
it's so important for me, because obviously I was really confused. Thank you.
And what about this report? Should we close it?
--
http://gcc
--
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=43206
--- Comment #16 from hjl dot tools at gmail dot com 2010-02-28 00:08
---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > It may be a different issue since the original testcase
> > > compiles with older gcc.
> >
> > It is still a regression fro
Revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
caused:
[...@gnu-34 rrs]$ cat pr43087.cc
template class NumericTraits{};
template class CovariantVector{};
template class Image{};
template
class F {
typedef H G;
typedef
typename NumericTraits::RealType
InputRealType;
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-28 00:05
---
The default is of course "-O2 -g", and I can tell you for sure that we (the
maintainers) always use it (when we are not debugging) and the same is true for
all the most important Linux distros. By the way, no w
--- Comment #15 from hjl dot tools at gmail dot com 2010-02-28 00:03
---
(In reply to comment #14)
> (In reply to comment #13)
> > It may be a different issue since the original testcase
> > compiles with older gcc.
>
> It is still a regression from gcc 4.4.1:
>
> pr43087-delta.ii:25:
--- Comment #7 from 4ernov at gmail dot com 2010-02-27 23:54 ---
Hmmm.. so it's also safe to build it with optimization, to say, -O2?
Honestly, I was seriously convinced that it's dangerous because of big warnings
in LFS etc. And I turned everything off every time..
--
http://gcc.g
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-27 23:45
---
It's harmless for sure. But certainly you don't want to build like that unless
you are debugging (and then you should add -g, of course), because you are
disabling most of the optimizations, exactly like -O0. P
--- Comment #14 from manu at gcc dot gnu dot org 2010-02-27 23:45 ---
(In reply to comment #13)
> It may be a different issue since the original testcase
> compiles with older gcc.
It is still a regression from gcc 4.4.1:
pr43087-delta.ii:25: error: no type named 'PixelType' in 'class
--- Comment #5 from 4ernov at gmail dot com 2010-02-27 23:37 ---
Thank you for the problem description.
But didn't completely understood: does it indicate any faults in my gcc build
with this flags or is it just testsuite details and it's harmless?
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #13 from hjl dot tools at gmail dot com 2010-02-27 23:31
---
(In reply to comment #10)
> Reduced testcase:
>
> template class NumericTraits{};
> template class CovariantVector{};
> template class Image{};
> template class E,
> class D>
> class F {
> type
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-27 23:29
---
Fixed for 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-27 23:29
---
Then you are not inlining *at all*. What is happening is that *many* symbols
are inadvertently exported at the baseline version instead of the right
version, or at all. That is benign, and certainly we don't wa
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-27 23:29
---
Subject: Bug 43186
Author: rguenth
Date: Sat Feb 27 23:28:46 2010
New Revision: 157114
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157114
Log:
2010-02-27 Richard Guenther
PR tree-optimizatio
--- Comment #4 from fmartinez at gmv dot com 2010-02-27 23:27 ---
Created an attachment (id=19984)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19984&action=view)
Fortran source code
File whose generated .mod file causes the compiler error
--
http://gcc.gnu.org/bugzilla/show
I am using the 4.5.0 20100225 snapshot with macports on snow leopard.
I have a large legacy fortran codebase that uses both -finit-local-zero and
-fno-automatic together. The code was not working under gcc 4.4.3. I found
that bug #41860 fixed this problem and had been checked into the trunk. So,
--- Comment #3 from 4ernov at gmail dot com 2010-02-27 23:11 ---
I'm sorry, I didn't write the title correctly, CXXFLAGS is the same value as
CFLAGS in my case, i.e. CXXFLAGS is "-march=core2", too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-27 23:05
---
In any case, I don't think it can be a *library* issue, because the library
itself is built with the *C++* compiler only.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-27
23:01 ---
Created an attachment (id=19982)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19982&action=view)
Output of GCC 4.3
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-27
23:02 -
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-27
23:01 ---
Created an attachment (id=19982)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19982&action=view)
Output of GCC 4.3
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-27
23:02 -
The testcase is taken from attachment 19965 (bug 43186).
Compile with `gcc -O3 -DBUG testcase.c'
--
Summary: GCC 4.4 / 4.5 generates larger code for a particular
testcase
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Se
--- Comment #12 from manu at gcc dot gnu dot org 2010-02-27 22:41 ---
I meant 'expanding the typedef'.
It would be nice to have a delta tool that expanded typedefs iteratively. Also,
it sometimes good to replace spaces by new lines to give delta larger search
space. I also use the follo
--- Comment #1 from 4ernov at gmail dot com 2010-02-27 22:37 ---
Created an attachment (id=19981)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19981&action=view)
Test log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
I've tried to built gcc-4.4.3 with different CFLAGS and CXXFLAGS variable and
have found that when they are "-march=core2" there's one unexpected failure in
libstdc++ tests: FAIL: abi_check. Everything else in test results is equal. I
know that I should build gcc with neither CFLAGS nor CXXFLAGS se
--- Comment #3 from hjl dot tools at gmail dot com 2010-02-27 22:34 ---
(In reply to comment #2)
> With the patch proposed in comment 1, I now get...
>
Does it fix your problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-27 22:29 ---
Interestingly deleting the typedef H G; makes us give the following error:
pr43087-delta.ii:24:18: error: no type named âPixelTypeâ in âclass
Imageâ
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-02-27
22:28 ---
With the patch proposed in comment 1, I now get...
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed: -D__DYNAMIC__ t.cc -fPIC -mmacosx-version-min=10.6.3
# -mtune
--- Comment #10 from manu at gcc dot gnu dot org 2010-02-27 22:26 ---
Reduced testcase:
template class NumericTraits{};
template class CovariantVector{};
template class Image{};
template
class F {
typedef H G;
typedef
typename NumericTraits::RealType
InputRealType;
};
template
:
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-27 22:20 ---
(In reply to comment #8)
> > Well, it really only requires much time and memory to compile,
> > it's not never ending ;)
>
> Ah, it means that machine is old.
>
> Also, the generated code is larger then what gcc 4.
--- Comment #8 from d dot g dot gorbachev at gmail dot com 2010-02-27
22:11 ---
> Well, it really only requires much time and memory to compile,
> it's not never ending ;)
Ah, it means that machine is old.
Also, the generated code is larger then what gcc 4.3 does (4.4 is affected,
too
--- Comment #1 from hjl dot tools at gmail dot com 2010-02-27 21:37 ---
Please try
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01222.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-27 21:33 ---
This is because
p = 0;
is not detected as dead store by tree DSE as in
p = 0;
r = *q;
p = (T *) t[0];
*q may load from p because with LTO TBAA rules for pointers have been
relaxed (for a reason but also i
After r157110, the wrong architecture, pentiumpro, is selected for gcc trunk
built with...
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin10/4.5.0/lto-wrapper
Target: i686-apple-darwin10
Configured with: ../gcc-4.5-20100227/configure
--- Comment #9 from dodji at gcc dot gnu dot org 2010-02-27 21:14 ---
Subject: Re: [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
> Hi, I have reduced the testcase in around half of its size and delta
> is still running. Once it is finished, I will upload it.
You mean half of the si
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2010-02-27
21:06 ---
Created an attachment (id=19980)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19980&action=view)
C source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43201
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-27
21:05 ---
Created an attachment (id=19979)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19979&action=view)
Code compiled without `-flto'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43201
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-27
21:04 ---
Created an attachment (id=19978)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19978&action=view)
Code produced by lto1
Compiled with `-O2 -flto'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--
Summary: Missed optimization with `-flto'
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g d
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-27 20:55 ---
That's because -combine refuses to compile the testcase. LTO is very
forgiving to global symbol type mismatches (maybe too forgiving). It
basically chooses one type and replaces all other uses with a
VIEW_CONVERT_E
--- Comment #7 from kai dot extern at googlemail dot com 2010-02-27 20:34
---
(In reply to comment #6)
>
> *** This bug has been marked as a duplicate of 42587 ***
>
Oh? 42587 seems to be about not recognising memory bswap, which explains why my
first attempt didn't work. But that wa
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-27 20:32 ---
This is most likely a dup of bug 42450.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43198
--- Comment #9 from chris at crupp dot de 2010-02-27 20:12 ---
I experienced the same issue. I'm not able to reproduce this in a short
snippet, but if someone needs my whole source package then i can provide it.
--
chris at crupp dot de changed:
What|Removed
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-27 20:04 ---
*** This bug has been marked as a duplicate of 42587 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-27 20:04 ---
*** Bug 43197 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-27 19:52 ---
(In reply to comment #6)
> Thanks! But it still does not work when "a < 3" is replaced by "a < 4". Also,
> the original testcase requires much time to compile.
Well, it really only requires much time and memory to c
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-27 19:37 ---
Janus, can you have a look? I was wondering whether the following patch makes
sense. If you have time, can you finish a patch for this PR and PR 43169.
Index: resolve.c
==
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-27 19:29 ---
testing a patch
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from simartin at gcc dot gnu dot org 2010-02-27 19:28
---
Fixed in 4.5
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-27 19:26 ---
I think the main problem of comment 0 was a user error - or at least it is not
reproducible with the information we have.
The second problem is solved. I therefore changed the summary and close it as
FIXED.
--
bu
--- Comment #2 from simartin at gcc dot gnu dot org 2010-02-27 19:21
---
Subject: Bug 42054
Author: simartin
Date: Sat Feb 27 19:21:39 2010
New Revision: 157112
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157112
Log:
gcc/cp/
2010-02-27 Simon Martin
PR c++/42054
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-27 18:49 ---
Patch approved http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01138.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-27 18:48 ---
Patch approved for GCC 4.6
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01188.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-27 18:47 ---
Alias 4.6
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Alias|
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-27 18:45 ---
Other PRs block this one, not the other way around.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43199
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-27 18:04 ---
Hopefully, this should be FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from davek at gcc dot gnu dot org 2010-02-27 17:50 ---
Created an attachment (id=19977)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19977&action=view)
Alternative approach
This alternative approach attempts to place a circular dependency between the
two generated
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-27 17:48 ---
Subject: Bug 24577
Author: manu
Date: Sat Feb 27 17:48:02 2010
New Revision: 157111
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157111
Log:
2010-02-27 Manuel López-Ibáñez
PR c/24577
PR
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-27 17:48 ---
Subject: Bug 43192
Author: manu
Date: Sat Feb 27 17:48:02 2010
New Revision: 157111
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157111
Log:
2010-02-27 Manuel López-Ibáñez
PR c/24577
PR
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-27 17:47 ---
Thanks for the report.
(In reply to comment #1)
> I changed the severity level to 'normal'. A Fortran issue is
> never considered to be bocker.
Especially not if it involves a new experimental feature such as polym
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-27 17:44 ---
(In reply to comment #7)
> Created an attachment (id=19963)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19963&action=view) [edit]
> Reduced test case
>
> This is a somewhat reduced test case that is still way b
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |target
Keywords||ice-on-valid-c
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-27 17:26 ---
... and fixed on the 4.5 trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-27 17:25 ---
I just think your endian swap is not recognized by the bswap pass. The main
reason is because of byte_sex function which is not optimized at the tree
level. But really there are better ways of writing endian swaps.
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-27 17:25 ---
Close as INVALID.
Patch posted was: http://gcc.gnu.org/ml/fortran/2010-02/msg00225.html
However, Jim Xia thinks it is invalid - and I think he is right - as C611 has:
R611 data-ref is part-ref [ % part-ref ] ...
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-27 17:25 ---
Subject: Bug 43185
Author: burnus
Date: Sat Feb 27 17:25:05 2010
New Revision: 157109
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157109
Log:
2010-02-27 Tobias Burnus
PR fortran/43185
*
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-27 17:15 ---
I changed the severity level to 'normal'. A Fortran issue is
never considered to be bocker.
Can you attach the files to the bug report? Copy and paste
from a web browse is fraught with problems; in particular,
white
Hey, you do know me but I won't tell you who I am in case I get banned.
There was a ragnarok dupe leaked the other day which I've been using the
last few days. Won't tell you who I am, but we're friends and I thought you
might want to have it. If you use it, don't tell anyone.
http://www.purepvpr
== 1.c ==
extern void f(void);
const char *s = "Hello, world!";
int main(void)
{
f();
return 0;
}
== 2.c ==
extern int puts(const char *);
extern const char s[];
void f(void)
{
puts(s);
}
=
When compiling with `
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:34
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:30
---
Subject: Bug 42253
Author: ebotcazou
Date: Sat Feb 27 14:30:12 2010
New Revision: 157108
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157108
Log:
PR ada/42253
* gcc-interface/utils2.c (b
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:27
---
Subject: Bug 42253
Author: ebotcazou
Date: Sat Feb 27 14:27:27 2010
New Revision: 157107
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157107
Log:
PR ada/42253
* gcc-interface/utils2.c (b
--- Comment #40 from zsojka at seznam dot cz 2010-02-27 14:06 ---
Follown file fails at all opt levels at both x86_64 and i?86:
-- testcase.cpp --
namespace {
bool bar(int i) { return i; }
}
int foo(int i) { return bar(i) ? i : 0; }
--
--- Comment #3 from zsojka at seznam dot cz 2010-02-27 14:02 ---
Testcase fails when compiled as C++ code too (without -flto):
$ /mnt/sdb1/build-157106-checking-fold/gcc/cc1plus -O bug.c
int main()
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
--- Comment #9 from p dot vanhoof at oma dot be 2010-02-27 13:53 ---
The following Lagrange interpolation routine crashes the trunk
> gcc -O1 -floop-parallelize-all -c bug.c
bug.c: In function lagrange:
bug.c:1:8: internal compiler error: Segmentation fault
... etc.
> gcc -v
Using bu
--- Comment #4 from kai dot extern at googlemail dot com 2010-02-27 13:46
---
> You are violating c++ aliasing rules. You access a uint8_t via
> different types.un
Actually, I address other types via uint8_t, but that is neither here nor
there. (Oh, I just realized you probably didn
The generated m_string.mod from m_string.f03 generated with latest version of
gcc-fortran 4.5 generates an internal error when used in any other fortran
module through a use statement.
_
module m_string
!
--- Comment #3 from pinskia at gmail dot com 2010-02-27 13:06 ---
Subject: Re: New: Endianness and Optimization
Sent from my iPhone
On Feb 27, 2010, at 2:56 AM, "kai dot extern at googlemail dot com"
wrote:
> The attached code (which tries to generically load given-endianness
>
Sent from my iPhone
On Feb 27, 2010, at 2:56 AM, "kai dot extern at googlemail dot com" > wrote:
The attached code (which tries to generically load given-endianness
values of
varying width from memory) shows some interesting optimization
quirks. It's
especially pussling why optimization q
--- Comment #12 from burnus at gcc dot gnu dot org 2010-02-27 12:24 ---
(In reply to comment #11)
> With the patch in comment #10, the tests in pr40440 (the original one and the
> one in comment #2 give an ICE:
Thanks for testing! In trans-array.c's gfc_trans_deferred_array, my current
--- Comment #1 from dcb314 at hotmail dot com 2010-02-27 11:56 ---
Created an attachment (id=19976)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19976&action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43198
I just tried to compile the package monotone-0.46
with the C++ compiler version 4.5 snapshot 20100225 and it said
cmd_diff_log.cc:1128:1: error: edge points to wrong declaration:
and
cmd_diff_log.cc:1128:1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-02-27 11:35 ---
I do not see the temporaries with
gcc-Version 4.5.0 20100214 (experimental) (GCC)
but I see this with
gcc-Version 4.5.0 20100227 (experimental) (GCC)
on x86_64-unknown-linux-gnu
This makes this a regression
--- Comment #2 from kai dot extern at googlemail dot com 2010-02-27 11:01
---
Created an attachment (id=19975)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19975&action=view)
Disassembled output
The results from compiling the source
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #1 from kai dot extern at googlemail dot com 2010-02-27 10:59
---
Created an attachment (id=19974)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19974&action=view)
C++ Source
The source file to demonstrate the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
The attached code (which tries to generically load given-endianness values of
varying width from memory) shows some interesting optimization quirks. It's
especially pussling why optimization quality varies so greatly with width, and
is actually worst for the native word width.
For example:
$ gcc
--- Comment #11 from dominiq at lps dot ens dot fr 2010-02-27 10:35 ---
With the patch in comment #10, the tests in pr40440 (the original one and the
one in comment #2 give an ICE:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address:
--- Comment #6 from d dot g dot gorbachev at gmail dot com 2010-02-27
10:17 ---
Thanks! But it still does not work when "a < 3" is replaced by "a < 4". Also,
the original testcase requires much time to compile.
--
d dot g dot gorbachev at gmail dot com changed:
What|
--- Comment #2 from jojelino at gmail dot com 2010-02-27 08:44 ---
when given without -mstackrealign, it works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43196
--- Comment #1 from jojelino at gmail dot com 2010-02-27 08:12 ---
Created an attachment (id=19973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19973&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43196
--enable-tls --disable-bootstrap --target=i686-pc-mingw32 --enable-shared
--enable-interpreter --disable-sjlj-exceptions
Thread model: win32
gcc version 4.5.0 20100227 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-g' '-include' '/tmp/baseclasses/mingw_dshow.h&#
98 matches
Mail list logo
