Hello,
I have binutils 2.18
$ ld --version
GNU ld (GNU Binutils) 2.18
...
But during compilation I get following:
configure: WARNING: === Linker version 1800 is too old for
configure: WARNING: === full symbol versioning support in this release of GCC.
configure: WARNING: === You would
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-01-10 14:03
---
Created an attachment (id=14907)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14907action=view)
Lightly tested fix.
I'll give it a whirl on IA-64 but it would be nice to test it on ARM too.
--
--- Comment #1 from manu at gcc dot gnu dot org 2008-01-10 14:07 ---
This is an example that shows that small differences in code lead to quite
different SSA representations. Without print we have a PHI node, where one of
the operands is the uninitialized value, so we warn. However,
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-10 14:28 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-10 14:29 ---
Subject: Bug 34651
Author: rguenth
Date: Thu Jan 10 14:28:40 2008
New Revision: 131442
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131442
Log:
2008-01-10 Richard Guenther [EMAIL PROTECTED]
PR
I saw that gfortran writes (at least sometimes) a localized run-time error
message:
_gfortran_runtime_error (Attempt to allocate a negative amount of
memory.[1]{lb: 1 sz: 1});
_gfortran_os_error (Memory allocation failed[1]{lb: 1 sz: 1});
becomes then (LANG=de_DE.UTF-8):
_gfortran_runtime_error
--- Comment #9 from jakub at gcc dot gnu dot org 2008-01-10 14:50 ---
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00404.html
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00408.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
--- Comment #38 from rguenth at gcc dot gnu dot org 2008-01-10 14:36
---
Created an attachment (id=14908)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14908action=view)
hack to disable rewriting of VOPs
I tried to change the unroller doing only SSA_NAME replacement update after
--- Comment #39 from rguenth at gcc dot gnu dot org 2008-01-10 15:01
---
Hmm, looks I was compeltely wrong about the cause of the slowdown. We actually
run cfg_cleanup after cunroll and merge blocks like
BB1
...
BB2
# SFT.1_2 = PHI SFT.1_1 (BB1)
...
# SFT.1000_2 = PHI
--- Comment #14 from eres at il dot ibm dot com 2008-01-10 15:05 ---
-fassociative-math and -fsigned-zeros flags can not co-exist.
I guess this testcase should be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-10 15:08 ---
Related to PR 31094, PR 31279, and PR 23169.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34721
The attached C++ source is AFAICS legal C++.
However it doesn't compile with the debug libstdc++, as the debug code assumes
that each given set can be compared with the passed compare operator.
--
Summary: Legal program doesn't compile with -D_GLIBCXX_DEBUG
Product: gcc
--- Comment #1 from dominik dot strasser at onespin-solutions dot com
2008-01-10 15:28 ---
Created an attachment (id=14909)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14909action=view)
Source code showing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
--- Comment #40 from rguenth at gcc dot gnu dot org 2008-01-10 15:32
---
After you fix this, we're back to SCCVN is slow with lots of virtual operands.
For -O2 (which appearantly is the worst case) we now have the following
profile:
Each sample counts as 0.01 seconds.
% cumulative
--- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-10 15:56
---
Some bugs appear to re-appear. :-(
While I get
__attribute__((naked))
int main(void)
{
// ...
return 42;
}
to compile with the current compiler, the following piece of code:
__attribute__((signal,
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-10 15:38 ---
Isn't this similar to
include stdio.h
main()
{
char foo[10];
printf(%s, foo);
}
and other functions that we know for sure don't modify their arguments. It
seems a missed optimisation not only for Fortran.
--
--- Comment #3 from manu at gcc dot gnu dot org 2008-01-10 15:40 ---
Actually, that is for Wuninitialized. For a missed optimisation:
#include stdio.h
char foo()
{
char str[] = Hola;
char c;
printf(%s, str);
c = str[0];
return c;
}
--
--- Comment #2 from pcarlini at suse dot de 2008-01-10 15:59 ---
Interesting. I agree the code is legal, on the other hand, we want to check the
required ordering... Would it be ok to you to have the check moved to
_GLIBCXX_DEBUG_PEDANTIC??
--
pcarlini at suse dot de changed:
--- Comment #3 from pcarlini at suse dot de 2008-01-10 16:10 ---
Hi Doug. As the main author of our debug-mode, I'd like to know your opinion
about this issue... On one hand, in the actual algorithm we are not comparing
values from the same range, on the other hand, clearly the
--- Comment #6 from krebbel at gcc dot gnu dot org 2008-01-10 16:47 ---
Subject: Bug 34641
Author: krebbel
Date: Thu Jan 10 16:46:26 2008
New Revision: 131445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131445
Log:
2008-01-10 Andreas Krebbel [EMAIL PROTECTED]
PR
--- Comment #41 from rguenth at gcc dot gnu dot org 2008-01-10 16:59
---
Subject: Bug 34683
Author: rguenth
Date: Thu Jan 10 16:59:06 2008
New Revision: 131446
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131446
Log:
2008-01-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #43 from rguenth at gcc dot gnu dot org 2008-01-10 17:05
---
Actually this is not a regression against a released compiler, as both the
4.1 and the 4.2 branches ICE for this testcase:
gfortran-4.2 -S -o /dev/null t.f90 -O -fstrict-aliasing
t.f90: In function 'ampli':
--- Comment #42 from rguenth at gcc dot gnu dot org 2008-01-10 17:02
---
This is probably all we can get for now - maybe another few % with minor
tweaks,
but nothing earth-shattering. After all, we _do_ have a much larger IL due
to the number of VOPs not partitioned.
--
--- Comment #44 from steven at gcc dot gnu dot org 2008-01-10 17:39 ---
Yes, fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from eric dot weddington at atmel dot com 2008-01-10 17:56
---
(In reply to comment #3)
__attribute__((signal, naked))
void __vector_42(void)
{
static unsigned char x;
x++;
}
still triggers the ICE:
However, if there is a function prototype, and the
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from baldrick at gcc dot gnu dot org 2008-01-10 18:25
---
Your solution seems to be somewhat complex though. Can't we get away with
an iterative propagation algorithm for the DECL_NO_STATIC_CHAIN flag?
Yes, but it is less efficient: in the worst case the number of
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-10 18:05 ---
If there is an ICE, there is a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
--- Comment #15 from ubizjak at gmail dot com 2008-01-10 18:23 ---
(In reply to comment #13)
This testcase has an execution failure on i686-pc-linux-gnu when using
-fpic/-fPIC.
They also fail for non-pic compilations when the testcase _really_ executes the
test:
Index:
--- Comment #16 from eres at il dot ibm dot com 2008-01-10 18:32 ---
This is because the test requires -fassociative-math for enabling the
variable-expansion as well as -fsigned-zeros for honor the sign of zero; but
they can not co-exist; also under -funsafe-math-optimizations.
--
--- Comment #48 from zadeck at naturalbridge dot com 2008-01-10 18:44
---
Subject: Re:
I do not want to commit this patch until after seongbae gets the new
node visiting sorted out.
This patch does for the rd problem what
http://gcc.gnu.org/bugzilla/attachment.cgi?id=14729
does for
--- Comment #9 from pault at gcc dot gnu dot org 2008-01-10 19:11 ---
Subject: Bug 34396
Author: pault
Date: Thu Jan 10 19:10:48 2008
New Revision: 131448
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131448
Log:
2008-01-10 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #10 from pault at gcc dot gnu dot org 2008-01-10 19:13 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2008-01-10 19:18 ---
We start with a CFG that looks like this (all edges directed down):
ENTRY
|
2
|\
| \
3 5
|\ \
| \ \
7 4--6
\ /
\ /
8
|
EXIT
where basic block 4 is a forwarder block. Insns in blocks 6 and 7 match
This is the core of the problem (at comp_0.c):
...
for(j = 0;j 3;j++) {
comp_0_fptr[j][1]();
}
...
comp_0_fptr holds pointers to void functions. When compiling with -g,
everything works ok. Compiling with -O2, or any other, the effect that I get
is:
comp_0_fptr[0][1]();
--- Comment #1 from ijeukens at yahoo dot com dot br 2008-01-10 19:24
---
Created an attachment (id=14910)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14910action=view)
execution output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |middle-end
--- Comment #2 from ijeukens at yahoo dot com dot br 2008-01-10 19:26
---
Created an attachment (id=14911)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14911action=view)
source 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
--- Comment #3 from ijeukens at yahoo dot com dot br 2008-01-10 19:27
---
Created an attachment (id=14912)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14912action=view)
source 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
--- Comment #4 from ijeukens at yahoo dot com dot br 2008-01-10 19:27
---
Created an attachment (id=14913)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14913action=view)
source 3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
--- Comment #5 from ijeukens at yahoo dot com dot br 2008-01-10 19:28
---
Created an attachment (id=14914)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14914action=view)
source 4 .. and last one
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
--- Comment #4 from wvangulik at xs4all dot nl 2008-01-10 19:00 ---
In 4.2.2 there is still no warning when compiling without -O.
void main(void)
{
volatile struct
{
int a, b, c, d, e, f;
} x;
x.d = 5;
asm volatile(in r28, 0x2F : : : r28);
x.d = 6;
}
--- Comment #4 from pcarlini at suse dot de 2008-01-10 20:04 ---
Thinking more about this issue, probably a more sophisticated solution would be
running the checks only when the value_types are equal. I'll try to prepare
something.
--
--- Comment #45 from jaydub66 at gmail dot com 2008-01-10 20:14 ---
(In reply to comment #42)
This is probably all we can get for now - maybe another few % with minor
tweaks,
but nothing earth-shattering. After all, we _do_ have a much larger IL due
to the number of VOPs not
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-10 20:16 ---
Created an attachment (id=14915)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14915action=view)
Fix using run_fast_dce
I see no way around running run_fast_DCE. But at least let's try to run it
only when
--- Comment #46 from steven at gcc dot gnu dot org 2008-01-10 20:21 ---
See e.g. bug 27004 and bug 33974.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #22 from janis at gcc dot gnu dot org 2008-01-10 21:24 ---
Steven asked for a regression hunt, but will not be pleased by the results. A
hunt using a hppa64-linux cross cc1 on powerpc-linux identified
http://gcc.gnu.org/viewcvs?view=revrev=81764
r81764 | dnovillo |
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-10 22:18 ---
Created an attachment (id=14916)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14916action=view)
new test case that fails before the tree-ssa merge
I made a new test case out of the .final_cleanup dump, and
--- Comment #24 from janis at gcc dot gnu dot org 2008-01-10 23:17 ---
A regression test using the test added in comment #23 identified:
http://gcc.gnu.org/viewcvs?view=revrev=74332
r74332 | sayle | 2003-12-05 14:06:46 + (Fri, 05 Dec 2003)
--
--- Comment #25 from steven at gcc dot gnu dot org 2008-01-10 23:44 ---
So this has been failing since at least GCC 3.4. And I see nothing in the
identified patch that is related to how CSE handles its values, so I suspect
this bug exists in older compilers as well (just needs another
--- Comment #26 from steven at gcc dot gnu dot org 2008-01-10 23:58 ---
Mark, wrt. the release, I recommend this PR shouldn't be a blocker. The
problem is old and is currently latent on the trunk, where it is only exposed
with non-default options (-fno-inline-small-functions).
--- Comment #1 from danglin at gcc dot gnu dot org 2008-01-11 01:01 ---
Subject: Bug 34466
Author: danglin
Date: Fri Jan 11 01:00:48 2008
New Revision: 131457
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131457
Log:
PR ada/34466
* s-osinte-linux-hppa.ads
I came across this while investigating (most likely) a related problem in
Apache stdcxx. Btw., I suspect the bg_BG locale is incorrect in defining
thousands_sep to NUL and filed
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5599
$ cat t.cpp g++ -dumpversion g++ t.cpp LC_NUMERIC=bg_BG
--- Comment #2 from danglin at gcc dot gnu dot org 2008-01-11 01:07 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Using the progmem attribute in C++ sources produce warning messages about
uninitialized variables. The following preprocessor output works correctly
under 4.1 but produces said warnings (in every warning level):
# 1 is.cpp
# 1 built-in
# 1 command-line
# 1 is.cpp
int i1
--- Comment #1 from pcarlini at suse dot de 2008-01-11 01:54 ---
Yes, I think we want to suspend this, waiting for the resolution of the glibc
issue. Because, I clearly remember adjusting the code basing on feedback from
people working on glibc: I learned that an empty thousand
--- Comment #2 from sebor at roguewave dot com 2008-01-11 02:09 ---
Right, in C it does mean that (because thousands_sep is a multibyte string, and
so the value is really ). The problem is that in C++ a NUL thousands_sep is a
perfectly valid single-byte character, i.e., '\0'. IMO, the
--- Comment #3 from pcarlini at suse dot de 2008-01-11 02:18 ---
(In reply to comment #2)
Right, in C it does mean that (because thousands_sep is a multibyte string,
and
so the value is really ). The problem is that in C++ a NUL thousands_sep is
a
perfectly valid single-byte
--- Comment #4 from pcarlini at suse dot de 2008-01-11 02:27 ---
In other terms, on the v3 side, we are not grouping anything in such cases,
therefore grouping() can only be the empty string, consistently with
22.2.3.1.2. As for the thousands separator, a '\0' seems a good character as
--- Comment #7 from ismail at pardus dot org dot tr 2008-01-11 02:31
---
Added testcase doesn't compile on i686-linux :
gcc/testsuite/g++.dg/torture/pr34641.C:16: error: 'operator new' takes type
'size_t' ('unsigned int') as first parameter
--
ismail at pardus dot org dot tr
--- Comment #5 from sebor at roguewave dot com 2008-01-11 03:09 ---
It's irrelevant to the implementation but it could be relevant to user-defined
formatting (or parsing) code that bypasses num_put (or num_get) but uses
numpunct to get the expected formats.
IMO, the improvement in any
--- Comment #6 from pcarlini at suse dot de 2008-01-11 03:17 ---
(In reply to comment #5)
It's irrelevant to the implementation but it could be relevant to user-defined
formatting (or parsing) code that bypasses num_put (or num_get) but uses
numpunct to get the expected formats.
I'm
--- Comment #7 from sebor at roguewave dot com 2008-01-11 03:37 ---
But that's just the libstdc++ interpretation of grouping and thousands_sep (no
offense). The C library paints a different picture.
If I want to write my own formatter/parser for numbers in the Bulgarian locale
that
--- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-11 03:57 ---
Thanks Kenny, patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00445.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826
--- Comment #8 from ghazi at gcc dot gnu dot org 2008-01-11 03:58 ---
Thanks Uros, patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00445.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33187
--- Comment #8 from pcarlini at suse dot de 2008-01-11 03:59 ---
(In reply to comment #7)
What I'm saying is that if the C library says localeconv()-grouping is \3\3
the C++ numpunct::grouping() shouldn't say it's something else.
Why not? If we agree that when the thousand separator
--- Comment #5 from raksit at gcc dot gnu dot org 2008-01-11 04:21 ---
Subject: Bug 27971
Author: raksit
Date: Fri Jan 11 04:20:32 2008
New Revision: 131460
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131460
Log:
gcc/ChangeLog
PR rtl-optimization/27971
*
--- Comment #20 from ghazi at gcc dot gnu dot org 2008-01-11 04:21 ---
Is the testcase gcc.dg/tree-ssa/loop-19.c supposed to work with -fpic/-fPIC?
I'm getting failures on mainline and 4.2 with x86_64, and only on 4.2 with
i686. Mainline i686 seems to work though.
Fails:
This is not rejected:
static int a()
{
return 0;
}
extern int f(void);
inline int f(void)
{
return a();
}
CUT ---
This violates C99 6.7.4/2 which says:
An inline definition of a function with external linkage shall not contain a
definition of a
modifiable object with static storage
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2008-01-11
04:44 ---
Subject: Re: [4.2/4.3 regression] loop performance regression
Is the testcase gcc.dg/tree-ssa/loop-19.c supposed to work with -fpic/-fPIC?
not necessarily; with -fpic, both memory accesses are fully
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-01-11 04:50
---
2 -- What does constraint #3 of section 6.7.4 mean?
It is not fully as 6.7.4/3 is not diagnosed, I filed this as PR 34735.
I guess Geoff forgot about this constraint.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-11 05:15 ---
We do reject this though:
static int a()
{
return 0;
}
inline int f(void)
{
return a();
}
extern int f(void);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34735
--- Comment #9 from sebor at roguewave dot com 2008-01-11 05:44 ---
I don't agree that localeconv()-grouping is garbage just because thousands_sep
is NUL. I'm not aware of anything in C or POSIX that says that. In the case of
bg_BG, the grouping is clearly correct. What's questionable
I am compiling for an avr target and sharing variables with interrupts. To
safely update the variables I am disabling interrupts but I want the interrupts
to be disabled for the shortest possible period of time.
The compiler shifts the instructions around slightly when optimizing, this has
the
--- Comment #1 from gcc-david at tulloh dot id dot au 2008-01-11 06:04
---
Created an attachment (id=14917)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14917action=view)
Trivial example source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
--- Comment #2 from gcc-david at tulloh dot id dot au 2008-01-11 06:05
---
Created an attachment (id=14918)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14918action=view)
Trivial example intermediate file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
--- Comment #3 from gcc-david at tulloh dot id dot au 2008-01-11 06:05
---
Created an attachment (id=14919)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14919action=view)
Trivial example assembler output file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
--- Comment #18 from aoliva at gcc dot gnu dot org 2008-01-11 06:46 ---
I don't see anything in expand_expr_real_1 that, given something like
(wider)narrower_typed_value, would reduce the value in a way that takes the
narrower_type into account. NOP_EXPR and CONVERT_EXPR will just
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-11 07:02
---
Reply to comment #2: I will update and see if that fixes it. Thanks Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34692
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
84 matches
Mail list logo
