--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-01-01 06:35
---
I forgot to mention I am using Cygwin 1.7, so this is beginning to look like
some sort of installation issue. The gfortran version 4.5 I downloaded and
installed per the gfortran wiki.
The other possibility to c
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-01-01 06:22
---
I tried the test case with Cygwin running on WinNT-4.0 and it works fine with
both 4.3.4 and 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
--- Comment #18 from bkoz at gcc dot gnu dot org 2010-01-01 03:54 ---
> multiset error
... was bogus. I adjusted the traits to fix this.
> The std::array error seems indeed bogus: if I'm not wrong, it happens when
> swapping arrays, and there are no guarantees that the operation does
--- Comment #17 from bkoz at gcc dot gnu dot org 2010-01-01 03:39 ---
Subject: Bug 21772
Author: bkoz
Date: Fri Jan 1 03:38:58 2010
New Revision: 155545
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155545
Log:
2009-12-31 Benjamin Kosnik
PR libstdc++/21772 part 3
--- Comment #3 from kargl at gcc dot gnu dot org 2010-01-01 02:49 ---
(In reply to comment #2)
> Subject: Re: BLOCKDATA referenced in EXTERNAL not loading from library
>
> I just got it from the gfortran Wiki because of problems with the previous
> version I had:
> http://gcc.gnu.org/
--- Comment #2 from urbanjost at comcast dot net 2010-01-01 01:57 ---
Subject: Re: BLOCKDATA referenced in EXTERNAL not loading from library
I just got it from the gfortran Wiki because of problems with the previous
version I had:
http://gcc.gnu.org/wiki/GFortranBinaries
then the "Cy
--- Comment #1 from kargl at gcc dot gnu dot org 2010-01-01 00:46 ---
Can you please read how to submit a bug report? I can't
find anywhere were it states that a Bourne shell script
should be submitted. It simply makes it almost impossible
to read the actual bug report. In fact, all t
--- Comment #1 from dirtyepic at gentoo dot org 2010-01-01 00:38 ---
Created an attachment (id=19434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19434&action=view)
delta-reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42569
while building gst-plugins-taglib-0.10.17:
gstapev2mux.cc: In function 'void add_one_tag(const GstTagList*, const gchar*,
void*)':
gstapev2mux.cc:118:62: error: cannot call constructor 'TagLib::String::String'
directly
gstapev2mux.cc:118:62: note: for a function-style cast, remove the redundant
':
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-31 23:19 ---
It is caused by revision 150695:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00375.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
Even though the BLOCKDATA is referenced with an EXTERNAL statement, it is
not initializing the COMMON; this worked in previous versions of gfortran,
and g95, g77, ifort, and vendor compilers (Cray, HP-UX, IRIX64, SunOS, Solaris,
...) as long as the EXTERNAL statement was present.
#!/bin/sh
echo t
--- Comment #13 from hjl dot tools at gmail dot com 2009-12-31 21:57
---
(In reply to comment #12)
> Created an attachment (id=19433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19433&action=view) [edit]
> A patch
>
> That is what I have in mind.
>
My patch adds -fdump-lto-tr
--- Comment #12 from hjl dot tools at gmail dot com 2009-12-31 21:55
---
Created an attachment (id=19433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19433&action=view)
A patch
That is what I have in mind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-31 21:25 ---
And most likely a dup of the other bug ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-31 20:43 ---
I couldn't reproduce this either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-31 20:42 ---
dg-do run gomp testcases don't belong into gcc/testsuite/*.dg/gomp/, but to
libgomp/testsuite/libgomp.*/
Please move recursion1.f90 there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #4 from matt at use dot net 2009-12-31 19:53 ---
It seems like this analysis would succeed if the intrinsic memcpy for copying
the [2] and [4] were inlined before this analysis. Is there a reason that the
intrinsic version of memcpy isn't substituted in before this analysis i
--- Comment #3 from matt at use dot net 2009-12-31 19:49 ---
Created an attachment (id=19432)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19432&action=view)
slightly different example that eliminates heap dependency
to reproduce:
g++ -O3 -Wall gcc-missing-uninit.cpp
result:
giv
ec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r155538-install --program-prefix=r155538-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20091231 (experimental) (GCC)
--- Comment #1 from smm2rc at Virginia dot EDU 2009-12-31 19:22 ---
Oh, and replacing the 'auto&& key = *b' line with 'auto&& key =
b.member_function()' results in a no-error compilation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42567
/*To start off, I apologize if this bug already was reported (I didn't find it
mentioned anywhere...). Also, what exactly is meant by 'host triplet', 'target
triplet', and 'build triplet'? (I just sort of guessed at them - I'm assuming
they're the host system and the target system and the system on
--- Comment #12 from nospamname at web dot de 2009-12-31 18:04 ---
>3.4.6 (didn't check older releases).
I test now 3.4.0 for m68k-amigaos.The Problem is here too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-31 17:56 ---
A different patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01253.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #15 from simon at pushface dot org 2009-12-31 17:41 ---
This bug affects Ada as well.
It happens with gcc-4_4-branch HEAD as of 31 Dec 2009, and with earlier
releases too (specifically, 4.3.4+AdaCore modifications; this compiler is
AdaCore's Leopard release with one added RTS
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-12-31 17:36
---
I cannot reproduce with a cross, neither on mainline nor 4.4 branch. Could you
post the command line passed to cc1? Do you have relevant local patches?
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 17:21 ---
It's indeed at fault. But instead of trying to fix it I'd ditch it completely
as premature optimization.
I consider c-common.c C frontend specific anyway ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42544
--- Comment #10 from developer at sandoe-acoustics dot co dot uk
2009-12-31 17:07 ---
(In reply to comment #9)
> FAIL: gfortran.dg/gomp/recursion1.f90 -Os execution test
There are two problems:
1) there is a problem with specifying -fopenmp twice on the CL
gfortran.dg/gomp/gomp.
--- Comment #11 from jsm28 at gcc dot gnu dot org 2009-12-31 17:06 ---
Reopening for now. Please leave the Component as "target"; that is
a much more likely place for the bug than the C front end.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from joseph at codesourcery dot com 2009-12-31 17:03 ---
Subject: Re: Bad codegen with signed short cast to unsigned
int, then promoted to unsigned long long
The first place to look for a problem would be shorten_compare.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 17:02 ---
Works on i?68-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42534
--- Comment #10 from mikpe at it dot uu dot se 2009-12-31 17:01 ---
Created an attachment (id=19431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19431&action=view)
simpler test case
I'm attaching a reduced test case that triggers wrong-code for m68k-elf with
gcc-4.5-20091224, ev
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ra
Target Milestone|--- |4.4.3
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyw
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 16:50 ---
Hum. Looks like the C FE somehow munges the uLL constant.
c_parser_cast_expression (parser=0xb77b0b44, after=0x0)
at /home/richard/src/trunk/gcc/c-parser.c:5000
(gdb) call c_parser_peek_token (parser)
$8 = (c_t
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
--- Comment #12 from simon at pushface dot org 2009-12-31 16:25 ---
I have tried gcc-4_4-branch and indeed it correctly identifies the triplet
without any help (I have been having some trouble with exactly what compiler I
am configuring with).
The problem turns out to be in gcc/ada/gcc-i
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42562
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 16:14 ---
var-tracking I suppose.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 16:07 ---
GDC is not part of the FSF GCC compiler, please report to GDC upstream.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 16:04 ---
Hm, yeah - there's also PR41584 - another empty TU bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42453
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 16:01 ---
It isn't particularly easy to DCE predicates in a general fashion.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 15:57 ---
-O1 -fipa-sra shows the problem as well. We can see wrong (or rather missing)
cloning of static initializers:
;; Function void Foo< >::exec2() [with
= int] (_ZN3FooIiE5exec2Ev)
void Foo< >::exec2() [with =
int
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-31 15:48 ---
Looks like this was fixed for 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:45 ---
Try a snapshot from the 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42474
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:44 ---
-Wunreachable-code is broken and has been removed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42482
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-31 15:41 ---
I'm fine with deprecating -V - anyone care to send a patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42485
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-31 15:37 ---
It was.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-31 15:36 ---
Btw, in 4.4 there is one DOM pass removed for compile-time.
We won't fix this for 4.4, the particular testcase is fixed in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
The bootstrap fails building the libstdc++ PCH file.
The system compiler is used to attempt the build and fails because it doesn't
undetstand -std=gnu++0x because it's an old compiler.
MacOSX:~/obj ed$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: p
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:33 ---
What do you expect with -fno-optimize-sibling-calls ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42497
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 15:30 ---
This is because widening multiplication is not detected if there are
more-than-once used sub-expressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42498
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:29 ---
Please try with trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Ke
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:28 ---
Fixed in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NE
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:28 ---
Please try with trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Ke
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.4.3
http://gcc
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 15:25 ---
I fixed sth like this a while ago, please try with current trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:21 ---
Primary target fails to bootstrap.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-31 15:19 ---
Works on i?86-linux. I guess stage2 is miscompiled?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:14 ---
It works with GCC built w/o --with-arch/--with-tune.
Can you paste the complete output of -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42520
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-31 15:12 ---
Revision 155528 caused:
FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link
FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20081222_1.o link
FAIL: gcc.dg/lto/20081222 c_lto_20081222_0.o-c_lto_20
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42521
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-31 15:08 ---
Confirmed on i?86-linux with -funsigned-char instead.
I'll have a looksee.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from aanisimov at inbox dot ru 2009-12-31 13:40 ---
Created an attachment (id=19430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19430&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42565
I tried to compile KDE 4.3.4 with gcc-r155523. The compilation stalled at file
globalsettings_base.cpp, which took more than 40 minutes to compile (actually,
it could have taken more, because I've simply aborted it).
In the attachement you will find the preprocessed version of this file. Sorry
to
--- Comment #9 from nospamname at web dot de 2009-12-31 13:35 ---
I compile now with a m68k-elf Compiler and do the small testcode i post
above.The Problem is same on m68k-elf Compiler too.
other CPU as -m68000 fail with -O3 or -O2
So can this Report Reopen and maybe another can check
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-31 11:57
---
A very old issue. In general, before filing in Bugzilla, do a search, and in
any case never file issues vs old unmaintained release branches, thanks.
*** This bug has been marked as a duplicate of 27102 ***
--- Comment #20 from paolo dot carlini at oracle dot com 2009-12-31 11:57
---
*** Bug 42563 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-31
11:39 ---
I am now seeing...
FAIL: gfortran.dg/gomp/recursion1.f90 -Os execution test
at r155534 that wasn't present at r155526 so the proposed
fix appears to have caused a gfortran regression on x86_64-apple-dar
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2009-12-31 11:21
---
Confirmed as fixed on x86_64-apple-darwin10 at rev. 155523.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 11:11 ---
But the patch was backported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42559
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-31 11:05 ---
Needs similar fix for LABEL_DECL. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from zweije at xs4all dot nl 2009-12-31 11:01 ---
I beg to differ. I cannot find where the standard says that
unsigned short *always* promotes to int in rvalue contexts.
My reading in more detail is:
1. The value of y is an lvalue of type unsigned short (5.1/7).
2. 1
--- Comment #39 from krebbel at gcc dot gnu dot org 2009-12-31 10:31
---
Ok. That looks good. I think the S/390 problem from comment #33 got fixed with
that patch:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01392.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-31
10:20 ---
Created an attachment (id=19429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19429&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
seen with current branches and trunk when building libcap-ng on sparc/sparc64.
the file builds without -fPIC or with -O0.
Matthias
$ gcc-4.4 -c -O2 -fPIC cap-ng.i
cap-ng.c: In function 'init':
cap-ng.c:154: error: unrecognizable insn:
(insn 18 17 19 4 cap-ng.c:139 (set (reg:SI 117)
(lo
--- Comment #2 from steven at gcc dot gnu dot org 2009-12-31 09:32 ---
http://gcc.gnu.org/viewcvs?view=revision&revision=152533
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
80 matches
Mail list logo
