--- Comment #7 from ache at nagual dot pp dot ru 2007-06-25 16:08 ---
Still not works with
gcc version 4.2.1 20070614 prerelease [FreeBSD]
try
cc -O2 foo.c; ./a.out
and
cc -O foo.c; ./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
I recognize that because of limits.h and float.h the C compiler has to
implement
functions or in-line code to make available ways to offer something to provide
operations for types referenced via freestanding headers. However, the C
specification says nothing about ___ramming down my throat___
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-25 16:31 ---
There is no builtin udivdi3. This is a runtime library function that get's
called
if the processor does not support this instruction (Unsigned DIVide for DImode
with 3 arguments) natively.
--
rguenth at gcc dot
--- Comment #2 from malitzke at metronets dot com 2007-06-25 16:38 ---
I want to reiterate that I am as little a linux-kernel maintainer as I am a GCC
maintainer. The linux-kernel is in excellent hands and does not need me. Out of
sheer laziness and/or intellectual poverty the example
--- Comment #3 from malitzke at metronets dot com 2007-06-25 16:39 ---
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
--- Comment #4 from malitzke at metronets dot com 2007-06-25 16:39 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-25 16:41 ---
Pong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|rguenth
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-25 16:44 ---
This is related to or really a dup of bug 4417.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-25 16:45 ---
*** Bug 32501 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-25 16:45 ---
This was reported a long time ago as PR 16470, if you think otherwise you need
to go back and talk to the C standards committee. What the issue here is you
are using long long and there is no hardware support for
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Known to work||4.1.2 4.2.0
--- Comment #8 from ed at fxq dot nl 2007-06-25 16:52 ---
(In reply to comment #0)
When the size of the loop is increased (in the attached example, to 6 or
higher) the problem disappears.
This should read:
When the size of the array is increased (in the attached example, to 6 or
--- Comment #7 from malitzke at metronets dot com 2007-06-25 16:52 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-25 16:54 ---
*** Bug 32501 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16470
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-25 16:54 ---
Who are you pinging? Because if you read the bug report I pointed to, you will
see that this was already decided this is not a bug a long long time ago.
Please read all of my comments instead of just reopening the
--- Comment #10 from malitzke at metronets dot com 2007-06-25 17:01 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
CC|rguenth at
--- Comment #9 from malitzke at metronets dot com 2007-06-25 17:02 ---
Read the standard
--
malitzke at metronets dot com changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-25 17:08
---
You missed:
Any library facilities available to a freestanding
program, other than the minimal set required by clause 4, are
implementation- defined.
This is from C99/5.1.2.1.
And C99/4/6 says:
The two forms
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-25 17:12
---
The standard is clear that long long is fully supported by freestanding
programs which means that the implementation needs to support it. GCC supports
it by providing libgcc.a support library.
4/6:
The two forms
--- Comment #2 from nemet at gcc dot gnu dot org 2007-06-25 17:21 ---
Subject: Bug 32495
Author: nemet
Date: Mon Jun 25 17:21:46 2007
New Revision: 125998
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125998
Log:
PR libfortran/32495
* runtime/backtrace.c
--- Comment #3 from nemet at gcc dot gnu dot org 2007-06-25 17:22 ---
Fixed.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from simon_baldwin at yahoo dot com 2007-06-25 17:24 ---
Indeed it can -- thanks for the reminder. Marking as FIXED.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #8 from simon_baldwin at yahoo dot com 2007-06-25 17:26 ---
Resolved by revision 122434.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2007-06-25
17:38 ---
Subject: Re: Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code
despite -fPIC
hjl at lucon dot org writes:
--- Comment #2 from hjl at lucon dot org 2007-06-22 18:26 ---
On Linux, I
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|spark at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |zadeck at gcc dot gnu dot
|dot org
--- Comment #30 from spark at gcc dot gnu dot org 2007-06-25 18:13 ---
The following patch will essentially disable the warning
for template instantiations in the anonymous namespace.
Index: gcc/cp/decl2.c
===
---
--- Comment #1 from ro at gcc dot gnu dot org 2007-06-25 18:16 ---
I forgot to mention: this is a regression from the 4.2 branch.
Besides, the same error happens with gas 2.17 and the native assembler.
With both gas and gld 2.17, the problem does not occur, but all java programs
tail
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Subject: Bug 31494
Author: pault
Date: Mon Jun 25 18:27:59 2007
New Revision: 126000
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126000
Log:
2007-06-25 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #10 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Subject: Bug 32464
Author: pault
Date: Mon Jun 25 18:27:59 2007
New Revision: 126000
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126000
Log:
2007-06-25 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Fixed on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pault at gcc dot gnu dot org 2007-06-25 18:30 ---
Fixed on trunk.
Thanks for the report, Harald.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from patchapp at dberlin dot org 2007-06-25 18:50 ---
Subject: Bug number PR 32130
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01856.html
--
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-06-25 18:51 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01858.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
--- Comment #4 from patchapp at dberlin dot org 2007-06-25 19:03 ---
Subject: Bug number PR32359
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01222.html
--
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-25 19:29
---
I cannot recreate this bug.
I have tried building both 32 and 64 bit compilers with both revision 125972
and the current 126001.
All of my machines are suse, so if this requires someone elses abi, I am out
The following subroutine has an orphaned OpenMP do directive (i.e. no
enclosing parallel region in the program unit) containing a reduction clause.
gfortran reports an error involving the scope of the reduction variable and
fails to compile the code. I believe this code is valid. For reference,
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01172.html (PR 32239):
At the moment the vectorizer only vectorizes builtin_pow if the exponent is
either 2 or 0.5. whereas if we expand constant exponents in the gfortran
frontend (gfc_conv_cst_int_power) it vectorizes for other constant integer
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-25 19:52 ---
At the moment the vectorizer only vectorizes builtin_pow if the exponent is
either 2 or 0.5. whereas if we expand constant exponents in the gfortran
frontend (gfc_conv_cst_int_power) it vectorizes for other constant
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-25 19:56 ---
Additionally: It would be great if there would be a variant for long integers
(8 byte integers) and long long (16 byte integers) as PR32239 could only use
__builtin_powi for int4 and not for int8 or int16.
--- Comment #4 from marcus at jet dot franken dot de 2007-06-25 19:57
---
I am using 10.2-x86_64 with the compiler built with
./configure --enable-languages=c
and at r126002
gdb
(gdb) bt
#0 fancy_abort (file=0xab29a0 /home/marcus/projects/gcc/gcc/df-scan.c,
line=4058,
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-25 20:04
---
sorry, pilot error on my part, i am too embarrassed to actually tell you what i
did.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-25 20:09 ---
I think gfortran is correct ...
$ ifort -warn all -openmp pr32502.f
fortcom: Error: pr32502.f, line 6: Variables that appear on the FIRSTPRIVATE,
LASTPRIVATE, and REDUCTION clauses on a work-sharing directive must
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-25 20:13 ---
Besides with gfortran, it is also rejected by three further compilers. It still
might be an oversight, but one has to check the OpenMP 2.5 standard; by
compiler voting gfortran wins ;-)
Intel's ifort rejects it
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-25 20:26
---
(In reply to comment #2)
there probably is a case for allowing certain such typedefs to be treated
like keywords with regard to adding _Complex, signed or unsigned.
I second that. Can a decision be reached on
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-25 20:35 ---
Currently, there is no means to warn about the usage of (un-)allocated
allocatables. See also: PR20520.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-06-25 20:37 ---
Cross-reference: the other way round, warn if allocatable is already allocated:
PR30676.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
i used to think this is duplicate bug of 32372 because it is invoked by similar
source.
but that testcase works fine.
--
Summary: [4.3 Regression] internal compiler error: in
df_refs_verify, at df-scan.c:4058
Product: gcc
Version: 4.3.0
--- Comment #1 from jojelino at gmail dot com 2007-06-25 20:42 ---
Created an attachment (id=13786)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13786action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32504
--- Comment #2 from jojelino at gmail dot com 2007-06-25 20:44 ---
craches if -Olevel given level1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32504
--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-25 20:49 ---
Besides local allocated variables, one can think of local pointers as well:
integer, pointer :: a
a = 4 ! wrong
if(associated(a)) ! wrong
nullify(a)
if(associated(a)) ! ok
a = 4 ! wrong
For allocation, one could
The following code produces predictable but odd output. The compiler should
either generate a warning for this case or throw away the instantiation of the
type upon encountering the better-matching partial specialization, somehow
keeping it for code above the given line.
template typename T
--- Comment #1 from dascandy at gmail dot com 2007-06-25 20:51 ---
The problem doesn't produce a warning when compiled with -Wall -Wextra
-pedantic. One of these (I expect -Wall is the best fit) should produce a
warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32505
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-25 21:30 ---
OpenMP v2.5, section 2.5.1, Loop contruct:
Summary
The loop construct specifies that the iterations of the associated loop will be
executed in parallel. The iterations of the loop are distributed across threads
Related to #21220?
Still happens with 4.0.4, Host 4.1.2,
$ /usr/cc/sh64/bin/sh64-superh-linux-gnu-ld -v
GNU ld version 2.15.94.0.2.2 20041220
$ /usr/src/cc/gcc-4.0.4/gcc-4.0.4/sh64/gcc/xgcc
-B/usr/src/cc/gcc-4.0.4/gcc-4.0.4/sh64/gcc/
-B/usr/cc/sh64/sh64-superh-linux-gnu/bin/
--- Comment #1 from jdi at l4x dot org 2007-06-25 21:35 ---
Created an attachment (id=13787)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13787action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32506
g++ -g source_c++_iostream_test01.cpp
--
source_c++_iostream_test01.cpp:80 internal compiler error: in dwarf2out_finish,
at dwarf2out.c:14292
source_c++_iostream_test01.cpp :
#include cassert
#include iostream
#include sstream
#include limits
using namespace std;
static
void
PerformTest01 ()
--- Comment #1 from magnetudinbuda at yahoo dot com 2007-06-25 21:41
---
Created an attachment (id=13788)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13788action=view)
the file that caused 'internal compiler error'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32507
according to documentation of libstdc++:
--enable-concept-checks
This turns on additional compile-time checks for instantiated library
templates, in the form of specialized templates, described here.
They can help users discover when they break the rules of the STL,
before their programs run.
[forwarded from http://bugs.debian.org/428926]
current 4.1 branch fails to link when the following code (extracted from the
gmp source) is built with -O1 (the libstdc++.so.6 on the system is the one
built by the current 4.2 branch).
$ g++ -O1 t-locale.cc
/tmp/ccXHCSZ6.o: In function `main':
--- Comment #4 from spam dot brian dot taylor at gmail dot com 2007-06-25
22:20 ---
Looks like you are correct. I believe the relevant section of the OpenMP API
standard is 2.8.1.2 (Sharing Attribute Rules for Variables Referenced in a
Region, but not in a Construct), lines 25-35 on
--- Comment #1 from pluto at agmk dot net 2007-06-25 22:23 ---
4.2-20070609 works, but 4.2-20070625 fails similar to 4.1.
$ readelf -sW concepts-42.so|c++filt|grep Concept
10: 1010 5 FUNCWEAK DEFAULT 10
__gnu_cxx::_BidirectionalIteratorConceptX
--- Comment #5 from pluto at agmk dot net 2007-06-25 22:32 ---
fixed by patch for PR32190.
--
pluto at agmk dot net changed:
What|Removed |Added
Status|NEW
--- Comment #6 from pluto at agmk dot net 2007-06-25 22:33 ---
this is a duplicate of PR23399.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32109
--- Comment #2 from simartin at gcc dot gnu dot org 2007-06-25 22:51
---
Subject: Bug 32111
Author: simartin
Date: Mon Jun 25 22:51:12 2007
New Revision: 126006
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126006
Log:
gcc/cp/
2007-06-26 Simon Martin [EMAIL PROTECTED]
--- Comment #3 from simartin at gcc dot gnu dot org 2007-06-25 22:54
---
This should be fixed in 4.3.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pluto at agmk dot net 2007-06-25 22:56 ---
(In reply to comment #2)
This is caused by two things, jump threading and inlining. If we jump thread
more, we no longer get the warning which is what you are seeing in 4.2.1.
the latest gcc 4.2 also produces this
--- Comment #5 from pluto at agmk dot net 2007-06-25 22:57 ---
Created an attachment (id=13789)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789action=view)
preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
--- Comment #1 from pcarlini at suse dot de 2007-06-25 23:03 ---
Whatever it is, it isn't a libstdc++ proper issue: the 4_1-branch is in deep
regressions-only mode, only very few commits to the breanch during the last 6+
months, nothing related to that issue (just have a look to the
--- Comment #2 from pcarlini at suse dot de 2007-06-25 23:13 ---
And of course a normally installed and configured recent 4_1-branch gcc
(20070619) compiles the provided snippet just fine. The symbol is exported as
expected:
000ad570 T
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-25 23:13 ---
This patch:
diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:10:32 2007 +
@@ -2849,6 +2849,7 @@ try_combine (rtx i3, rtx i2, rtx i1,
--- Comment #7 from spark at gcc dot gnu dot org 2007-06-25 23:25 ---
As David suggested, this might be a slightly better fix:
diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:23:23 2007 +
@@ -2057,6
--- Comment #3 from pcarlini at suse dot de 2007-06-25 23:27 ---
Sorry, disregard my remark between parentheses about 4.1 headers vs 4.2
library, I didn't follow your way of explaining your setup: yes, actaully, a
4.1 object *can* be linked to a 4.2 *.so. In any case, certainly the
--- Comment #8 from zadeck at naturalbridge dot com 2007-06-25 23:27
---
Subject: Re: ICE in df_refs_verify, at df-scan.c:4058
spark at gcc dot gnu dot org wrote:
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-25 23:13 ---
This patch:
diff -r 36792eca786a
--- Comment #2 from gd at spherenet dot de 2007-06-25 23:38 ---
Here is the reduced testcase which shows the bug:
=
namespace std __attribute__((__visibility__(default))) {
templatetypename _CharT
class basic_streambuf
{
friend void getline();
};
extern
--- Comment #9 from appfault at hotmail dot com 2007-06-25 23:41 ---
So does this being marked dupe of bug 21334 mean that as long as string (not
ext/vstring.h) is in use, that std::string is subject to other possible race
conditions, even if the original test case succeeds in gcc
--- Comment #10 from pcarlini at suse dot de 2007-06-25 23:50 ---
Probably, the answer is yes. In this area, when writing portable code, always
remember that C++03 says *nothing* about threads, and concurrent programming,
and so on. Different implementations, historically, made
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-26 00:19 ---
Subject: Bug 32421
Author: pinskia
Date: Tue Jun 26 00:19:44 2007
New Revision: 126012
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126012
Log:
2007-06-25 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-26 00:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-06-26 01:18 ---
Subject: Bug 20216
Author: geoffk
Date: Tue Jun 26 01:18:08 2007
New Revision: 126014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126014
Log:
PR 20216
* gcc.dg/pr20216.c: New.
Added:
--- Comment #4 from zadeck at naturalbridge dot com 2007-06-26 02:19
---
so kazu,
is there anything that i need to do with this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32423
The masseges below are the errors when i compile with command recodif, it never
happen before. Could you help me to fix this problem ?
recodif -cv -D CC=gcc -g testfee.des testfee.rec
Tri des variables...
Ecriture de testfee.c...
Ecriture du dessin...
Compilation :
gcc -I/app/std/include -o
--- Comment #4 from acahalan at gmail dot com 2007-06-26 03:10 ---
(In reply to comment #3)
Subject: Re: Missed optimizations with -fwhole-program -combine
I would not expect this to be fixed anytime soon. I have yet to find
any real people who use either combine or
--- Comment #6 from acahalan at gmail dot com 2007-06-26 03:37 ---
(In reply to comment #5)
This is related to or really a dup of bug 4417.
It's only related, not a dup, though bug 4417 is sort of a subset.
There appears to be no possible set of gcc options that will allow compiling
--- Comment #9 from davids at webmaster dot com 2007-06-26 03:42 ---
This should be marked as a 4.2.0 regression.
--
davids at webmaster dot com changed:
What|Removed |Added
GCC generally doesn't inline weak functions, because their body may be
redefined by the linker: if the compiler inlined the call, the linker changing
the behavior of the function wouldn't change the inlined copy. For example,
GCC does not inline this:
void bar () __attribute__((weak));
void bar
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-26 05:47 ---
The exact wording that forbids this is in 2.8.3.6:
A list item that appears in a reduction clause of a work-sharing construct
must be shared in the parallel regions to which any of the work-sharing regions
arising
101 - 187 of 187 matches
Mail list logo
