--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
--
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 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
--
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 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
--- 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
--- 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 expan
--- 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=14919&action=view)
Trivial example assembler output 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=14918&action=view)
Trivial example intermediate file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
--- 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=14917&action=view)
Trivial example source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
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 ef
--- 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
--- 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 #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 change
--- 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
st
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 dur
--- 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:
http://gcc.gnu
--- 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=gcc&view=rev&rev=131460
Log:
gcc/ChangeLog
PR rtl-optimization/27971
* combine
--- 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 separa
--- 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 #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 #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 inse
--- 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
--- 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 L
--- 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 change
--- 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
a
--- 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-byt
--- 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 #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 separator
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 ""
# 1 ""
# 1 "is.cpp"
int i1 __attribute__((__progmem__)) = 1;
int _
--- 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
Status|UNCONFIRM
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 #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=gcc&view=rev&rev=131457
Log:
PR ada/34466
* s-osinte-linux-hppa.ads (SC_NP
--- 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).
Obviousl
--- 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 t
--- 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=rev&rev=74332
r74332 | sayle | 2003-12-05 14:06:46 + (Fri, 05 Dec 2003)
--
http://gcc.gnu.org/bugzil
--- 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=14916&action=view)
new test case that fails before the tree-ssa merge
I made a new test case out of the .final_cleanup dump, and J
--- 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=rev&rev=81764
r81764 | dnovillo |
--- 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 #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=14915&action=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 rea
--- 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 par
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3473
--- 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=14914&action=view)
source 4 .. and last one
--
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=14913&action=view)
source 3
--
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=14912&action=view)
source 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
--- 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=14911&action=view)
source 1
--
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
h
--- 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=14910&action=view)
execution output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
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]();
comp_0_fp
--- 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 a
--- 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
Statu
--- 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=gcc&view=rev&rev=131448
Log:
2008-01-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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 #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 t
--- 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.
--
h
--- 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 n
--- 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: testsuite/gc
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last r
--- 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 #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, a
--- 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 #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':
t.f90:
--- 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.
--
http://gcc
--- 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=gcc&view=rev&rev=131446
Log:
2008-01-10 Richard Guenther <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=131445
Log:
2008-01-10 Andreas Krebbel <[EMAIL PROTECTED]>
PR
--- 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 specifica
--- 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 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, naked
--- 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
char foo()
{
char str[] = "Hola";
char c;
printf("%s", str);
c = str[0];
return c;
}
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-10 15:38 ---
Isn't this similar to
include
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.
--
manu at
--- 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 #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=14909&action=view)
Source code showing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
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 #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
--- 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 #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
...
# SFT.1_2 = PHI
...
# SFT.1000_2 = PHI
# SFT.1_3 = VDE
--- 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
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_
--- 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=14908&action=view)
hack to disable rewriting of VOPs
I tried to change the unroller doing only SSA_NAME replacement update after
--- 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=gcc&view=rev&rev=131442
Log:
2008-01-10 Richard Guenther <[EMAIL PROTECTED]>
PR
--- 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 #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, with
--- 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=14907&action=view)
Lightly tested fix.
I'll give it a whirl on IA-64 but it would be nice to test it on ARM too.
--
http:
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 n
84 matches
Mail list logo
