--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37646
The following invalid code snippet triggers an ICE since GCC 4.2.0:
===
struct A
{
void foo();
void bar(int i)
{
void (*p)() = i ? foo : foo;
}
};
===
bug.cc: In member function 'void A::bar(int)':
bug.cc:7: internal com
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37645
The following code snippet triggers an ICE since GCC 4.1.0:
==
void foo(int i __attribute__((__weakref__ ("xyz";
==
bug.c:1: internal compiler error: tree check: expected tree that
--- Comment #6 from nightstrike at gmail dot com 2008-09-25 05:00 ---
What is the output of g++ -v?
Are you using the win32 cross compiler, or the win64 native compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #5 from drangon dot mail at gmail dot com 2008-09-25 04:51
---
(From update of attachment 16071)
not for this bug
--
drangon dot mail at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from drangon dot mail at gmail dot com 2008-09-25 04:51
---
(From update of attachment 16070)
not for this bug
--
drangon dot mail at gmail dot com changed:
What|Removed |Added
---
--- Comment #5 from drangon dot mail at gmail dot com 2008-09-25 04:49
---
Created an attachment (id=16409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16409&action=view)
output of objdump, the object is build by gcc -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #4 from drangon dot mail at gmail dot com 2008-09-25 04:48
---
Created an attachment (id=16408)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16408&action=view)
output of objdump, the object is build by gcc -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #3 from drangon dot mail at gmail dot com 2008-09-25 04:48
---
Created an attachment (id=16407)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16407&action=view)
output of nm, the object is build by gcc -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #2 from drangon dot mail at gmail dot com 2008-09-25 04:47
---
Created an attachment (id=16406)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16406&action=view)
output of nm, the object is build by gcc -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #1 from drangon dot mail at gmail dot com 2008-09-25 04:45
---
Created an attachment (id=16405)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16405&action=view)
output of gcc -E
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
--- Comment #2 from gnu_andrew at member dot fsf dot org 2008-09-25 03:20
---
Interestingly:
$ /home/andrew/build/gcj/bin/gcj --version
gcj (GCC) 4.4.0 20080913 (experimental) [gcj/classpath-098-merge-branch
revision 140651]
$ /home/andrew/build/gcj/bin/gjar --version
jar (GNU Classpa
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-25 02:52
---
This happens also for x86_64.
on the trunk:
L2:
movq%rbx, %rdi
call_f0
testl %eax, %eax
jne L2
4.0.1:
L3:
leaq-4(%rbp), %rdi
call_f0
tes
--- Comment #1 from gnu_andrew at member dot fsf dot org 2008-09-25 01:47
---
I'm not sure when 4.3 branched, but David Daney's locale patch (switching from
gcj's locales to Classpath's) might have had an effect (2008-03-04). It's the
only locale change I can see from this year.
The c
Open MP directives in conjunction with LAM MPI calls is causing compiler to
fail:
(bash) niwot.pts/3% export
LAMHF77=/z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2
(bash) niwot.pts/3% mpif77 -g -fopenmp -c reorder_parent.f90
reorder_parent.f90:470: internal compiler error: Segmentation fault
P
--- Comment #3 from n dot pipenbrinck at cubic dot org 2008-09-24 22:41
---
ROL/ROR on the native integer size is not supported via intrinsics, but the
compiler will fold two shifts into a rotate.
If I want to manipulate only the lower 16 bit of an 32 bit integer (e.g. issue
a rolw) as
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-24 22:28 ---
I'll see this weekend if I can take care of this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 21:15 ---
Created an attachment (id=16404)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16404&action=view)
bzip2:ed native x64-64-linux build_log
The build_log from GeoffK's contrib/regression/btest-gcc.sh) of trunk r139963
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 21:10 ---
(In reply to comment #4)
> FWIW, this happens inside libtool configure tests,
> so I guess it is harmless inside gcc/.
>
> Do you see this in other directories' configure outputs, too,
No.
> and if yes, can you post a
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-09-24 20:42
---
(In reply to comment #2)
> Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short
> type
>
> When doing addition unsigned short is promoted to an signed int. So
> this is not a bug.
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-24 20:36 ---
What happens if you don't use profiledbootstrap but instead bootstrap?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 20:20 ---
GCC is doing the right thing here. In this constructor:
Thing2(Thing2&& o) : Thing(o) { }
the parameter "o" is treated as an lvalue, because it has a name. Using
std::move(o) to treat it as an rvalue.
Similarly,
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-24 20:16 ---
Something like this fixes the issue:
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 140638)
+++ config/rs6000/rs6000.c
--- Comment #2 from anton at samba dot org 2008-09-24 20:07 ---
After reading the gcc documentation I guess it is valid, and the 32bit
lwarx/stwcx will overlap but not change surrounding memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-24 19:55 ---
How is this broken code?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
C
When cross-compiling for vax--netbsdelf, fortran doesn't build. I have a
NetBSD/vax 4.99.72 install symlinked, and am using binutils 2.19.50.20080923.
gcc sources are subversion rev 140638. It gets to here and stops:
libtool: compile: /usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/
-B/us
--- Comment #58 from jason at redhat dot com 2008-09-24 19:21 ---
Subject: Re: exception_defines.h #defines try/catch
l dot lunak at suse dot cz wrote:
> --- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
> (In reply to comment #55)
>> It seems reasonable to
--- Comment #2 from pinskia at gmail dot com 2008-09-24 17:44 ---
Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short
type
When doing addition unsigned short is promoted to an signed int. So
this is not a bug. That is unsigned short + 1 is a signed int since
--- Comment #2 from dlenski at gmail dot com 2008-09-24 17:43 ---
Hi Andrew,
It seems to me that these modifiers are quite necessary for flexible x86
assembly. What is the point of the "q" and "Q" constraints if there's no way
to specifically refer to the 16-bit or 8-bit components of t
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-09-24 17:32 ---
FILE_WRITE_PROPERTIES is deprecated and even the documentation is removed from
msdn. So I agree that FILE_WRITE_EA should be used instead.
--
ktietz at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-09-24 17:29
---
Created an attachment (id=16403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16403&action=view)
This is the first testcase.
compile with gcc -O2 -W -Wall -Wstrict-overflow=5
--
http://gcc.gnu.org
I'll submit a testcase that apparently demonstrates that gcc is trying to apply
signed strict overflow rules to an unsigned short type, at least on 32 bit
machines when short is 16 bit.
Here is the output:
arm-elf-gcc -O2 -W -Wall -Wstrict-overflow=5 -c testcase.c
testcase.c: In function incr_cou
adaint.c uses a macro for mingw called FILE_WRITE_PROPERTIES. This has long
since been deprecated, and is instead replaced with FILE_WRITE_EA. Both macros
are defined to the same value (0x0010), but one does not exist in current
versions (such as mingw-w64, the 64-bit port). I recommend updating
--- Comment #7 from hp at gcc dot gnu dot org 2008-09-24 16:57 ---
I guess I should turn the code in the description into a testcase in gcc.dg so
target maintainers can add their xfailed scan-assembler-not and we'd see
xpasses if/when this is magically fixed...
(After the IRA adjustments
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 16:51 ---
Created an attachment (id=16402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16402&action=view)
Diff of asembly of -O2 vs -O2 -fno-if-conversion at r.140627
See previous comment.
--
http://gcc.gnu.org/bugzil
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 16:49 ---
(In reply to comment #4)
> I think this was fixed for 4.3.0:
> HP,
> can you try this again on cris?
At 140627, the problem is still there on the 4.3 branch for CRIS. I'll attach
a diff of the generated assembly of -O2
A gcc build from today (gcc version 4.4.0 20080924) gets an ICE on PowerPC when
building this (admittedly broken) code:
# gcc -m64 -O2 -c test.c
struct foo {
int a;
char lock;
};
struct foo *foo;
void testcase()
{
__sync_lock_test_and_set(&(foo->lock), 0);
}
It c
--- Comment #1 from kargl at gcc dot gnu dot org 2008-09-24 16:19 ---
(In reply to comment #0)
> For compile-time simplification, MPFR does not seem to provide a ready-to-use
> function; if one cooks up something oneself, one needs to check endian issues
> (though there might be none).
--- Comment #4 from jkolb at wsi dot com 2008-09-24 15:35 ---
I'm not sure, I don't have access to that machine right now. Kai Tietz (from
the mingw-w64 project) thought it might be the linker as well. How do I hand
the bug off to the linker folks?
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-24 15:34
---
Created an attachment (id=16401)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16401&action=view)
macro-expanded source of c-parser.c
Sorry for hitting return instead of tab in the initial report ...
Conf
--
Summary: Bootstrap fails with "may be used uninitialized" warning
in c-parser.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo:
--- Comment #3 from brian at dessent dot net 2008-09-24 15:24 ---
Subject: Re: auto-import of constant data results in a crash
at runtime
So, is the segment containing the reference to ff_log2_tab writable?
This still sounds like a linker issue not a compiler issue.
--
http://g
--- Comment #3 from sfilippone at uniroma2 dot it 2008-09-24 14:50 ---
(In reply to comment #2)
> Thanks for the report Salvatore, I'll take this one on. It seems the new
> F2003
> features are starting to getting used, from the bug-noise :D
>
Unfortunately these features are not goin
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-24 14:39 ---
Thanks for the report Salvatore, I'll take this one on. It seems the new F2003
features are starting to getting used, from the bug-noise :D
--
domob at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from jkolb at wsi dot com 2008-09-24 14:07 ---
Binutils 2.19.50
Yes I have. The linker switch does not help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-24 13:51 ---
Created an attachment (id=16400)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16400&action=view)
test case
ICE-on-invalid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 13:51 ---
We need to look at CALL_EXPR_FN's type because the decltype of a call retrieves
the return type of the the function called, which may be a REFERENCE_TYPE. The
type of the expression will have stripped away that refer
Current version of gfortran dies with an ICE on the attached invalid code.
- log ---
[EMAIL PROTECTED] F03]$ gfortran -v -c foo-ext.f03
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnutest
--with-mpfr=
--- Comment #57 from mark at codesourcery dot com 2008-09-24 13:03 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
> --- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43
> ---
> It seems reasonable to me for try { X }
The build of the Debian gcc-snapshot package, version 20080923, fails to build
with this output from some sort of constraints check. This constraints are arch
specific.
build/genpreds -h ../../src/gcc/config/s390/s390.md > tmp-preds.h
../../src/gcc/config/s390/constraints.md:122: constraint letter
seen with 20080923 from the trunk, try running any of the tools:
$ /usr/lib/gcc-snapshot/bin/gjar -help
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(natClass.cc:792)
at gnu.classpath.tools.common.Messages.getString(Messages.java:60)
a
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #84 from aldot at gcc dot gnu dot org 2008-09-24 09:51 ---
The fix doesn't seem to work for me on arm:
$ cat pr-weak.c
/* tell the compiler that the count isn't in the small data section if the arch
* has one (eg: FRV)
*/
extern const unsigned long kallsyms_num_syms
__attri
--- Comment #3 from gcc at spatium dot org 2008-09-24 09:37 ---
Subject: Re: [4.4 Regression] gcc-4.4-20080919 ada build failure
pinskia at gcc dot gnu dot org wrote 767 bytes:
> Can you try this again?
same thing with latest trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
> It seems reasonable to me for try { X } catch... to mean X when
> -fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify code's
--- Comment #8 from pault at gcc dot gnu dot org 2008-09-24 08:28 ---
Subject: Bug 36700
Author: pault
Date: Wed Sep 24 08:27:27 2008
New Revision: 140628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140628
Log:
2008-09-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/3
Requested by Richard Townsend at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1e4130b9720e4f2a
LEADZ and TRAILZ are rather common vendor extensions, e.g. supported by the
Intel compiler (it also allows for logical arguments).
LEADZ (I)
Description. Number of leading zer
--- Comment #4 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Subject: Bug 36700
Author: pault
Date: Wed Sep 24 08:12:47 2008
New Revision: 140627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140627
Log:
2008-09-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Subject: Bug 35945
Author: pault
Date: Wed Sep 24 08:12:47 2008
New Revision: 140627
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140627
Log:
2008-09-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-24 08:14 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from pault at gcc dot gnu dot org 2008-09-24 08:05 ---
Subject: Bug 37583
Author: pault
Date: Wed Sep 24 08:04:26 2008
New Revision: 140626
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140626
Log:
2008-09-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #9 from pault at gcc dot gnu dot org 2008-09-24 08:05 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-24 07:18
---
> Then perhaps either configure should reject the too-old version, or the
> testcase should detect this situation and either skip the tests in question
> and/or report that MPFR is too old. The situation as it sta
--- Comment #4 from tim dot vanholder at anubex dot com 2008-09-24 07:03
---
Then perhaps either configure should reject the too-old version, or the
testcase should detect this situation and either skip the tests in question
and/or report that MPFR is too old. The situation as it stands
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-24 07:02 ---
Subject: Bug 37626
Author: burnus
Date: Wed Sep 24 07:01:18 2008
New Revision: 140624
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140624
Log:
2008-09-24 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
67 matches
Mail list logo
