--- Comment #2 from steven at gcc dot gnu dot org 2009-12-31 09:32 ---
http://gcc.gnu.org/viewcvs?view=revisionrevision=152533
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
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)
--- 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=19429action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
--- 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 #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.
--- 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
--
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:11 ---
But the patch was backported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
--- 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 #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
--- 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 #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 #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
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 #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=19430action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42565
--- 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
--
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 #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
--- 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 #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 #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 #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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.4.3
--- 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
--- 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
--- 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
--- 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 #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
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:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- 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
--- 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 #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
--
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 #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
--- 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 #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 #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 template-parameter-1-1 ::exec2() [with
template-parameter-1-1 = int]
--- 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 #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 #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:14 ---
var-tracking I suppose.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
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 #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
--
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 #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 =
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ra
Target Milestone|--- |4.4.3
--- 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=19431action=view)
simpler test case
I'm attaching a reduced test case that triggers wrong-code for m68k-elf with
gcc-4.5-20091224,
--- 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 #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.
--
--- 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 #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
--- 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 ;)
--
--- 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 #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
--- 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 #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
/*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
--- 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
-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)
reg
--- 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=19432action=view)
slightly different example that eliminates heap dependency
to reproduce:
g++ -O3 -Wall gcc-missing-uninit.cpp
result:
--- 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
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
--- 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
--- 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 #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 #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=19433action=view)
A patch
That is what I have in mind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
--- 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=19433action=view) [edit]
A patch
That is what I have in mind.
My patch adds
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
--- 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
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 #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=19434action=view)
delta-reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42569
--- 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
--- 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
--- 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:
--- 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=gccview=revrev=155545
Log:
2009-12-31 Benjamin Kosnik b...@redhat.com
PR
--- 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
--- 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 #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
80 matches
Mail list logo
