To trySince you set up your.
Hi,
I'm developing a gcc based compiler and in a certain scenario I get the
following reload crash:
error: unable to find a register to spill in class 'AB_REGS'
I looked into it and it looks like it happens when all the AB_REGS registers
are taken as function arguments, and the prefered class
Hi,
J. Finch wrote on 10.01.2008 15:23:56:
on the issue as stated in the subject regarding x86_64-pc-mingw64, I
have downloaded MS debugger as suggested by FX, and I attach the
logs where command p is stepping.
fortran Program, c.f90, for test, one statement only
[program begin]
end
This looks fine. What is the call stack looks like? And how does the
function calling ntdll looks like?
I think, you should step on an int 3. Because you simply debug the
exception handling routine itself.
Hi, Kai:
I attach the stack in the following:
C:\temp\fortrancdb gfortran
Hi,
J. Finch wrote on 10.01.2008 16:31:38:
Thank you very much for your dumps, but you should use on runtime the
option '-dH' option to enforce that you reach the point, where the
exception is caused.
stack before and after segmentation fault is as:
..
..
Hi all,
I'm going on brutalizing GIMPLE code to make it more suitable for CIL emition in
the CLI be/fe branch and I've stumbled across something which looks really weird.
When working with types I always assumed that if 't' is a RECORD_TYPE,
UNION_TYPE or QUAL_UNION_TYPE then calling
On 10 January 2008 16:12, Gabriele SVELTO wrote:
int
main()
{
struct try
{
FLOAT x, y;
unsigned unord : 1;
unsigned lt : 1;
unsigned le : 1;
unsigned gt : 1;
unsigned ge : 1;
unsigned lg : 1;
};
static struct try const data[] =
{
Yes, I can remember that constraints in a mov-insn can not be
resolved by other/additional mov-insns.
I think you're doing this the wrong way. You don't have a i-m mov
instruction, so why are you pretending you do?
Why aren't you doing this the same way as pretty much every other target?
On 10 January 2008 16:40, Gabriele SVELTO wrote:
Dave Korn wrote:
On 10 January 2008 16:12, Gabriele SVELTO wrote:
[snip]
A new type still named 'struct try' is used in the COMPONENT_REFs of
this function but this type has a different TYPE_UID from the 'struct try'
used in main.
Dave Korn wrote:
On 10 January 2008 16:40, Gabriele SVELTO wrote:
Yes, you're completely correct about the artificial initialiser function; I
thought the compiler might output it as a nested function, but I don't know
without checking. (But I've been working on gcc for only ~7 years so I
Gabriele == Gabriele SVELTO [EMAIL PROTECTED] writes:
Gabriele Good to know, TYPE_MAIN_VARIANT () is exactly what I was
Gabriele looking for, unfortunately it's description in tree.def
Gabriele isn't exactly crystal clear :P Thank you very much
This would be a great opportunity to improve the
Hi, Kai,
This is what you want, with -dH. If you need further information, please let me
know. Finch.
.
.
(8b8.8bc): Break instruction exception - code 8003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntdll.dll -
The main reason it is not hosted on the gcc servers is that it would
require installation of ruby and ruby on rails.
This has not been brought up on overseers before, and i do not know
how people would feel about it.
On Jan 10, 2008 2:01 AM, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
Hi,
The
On Tue, 8 Jan 2008, Benjamin Kosnik wrote:
As such, I'd like to get a general indication from the greater GCC community
as to this plan. Does this document seem like a good idea?
(Previously, we've left this kind of document to the user community.
Often the passage of time has not been
On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:
In addition, improvements to the GCC infrastructure allows several
existing warning flags new ability to spot problematic code.
Is this sentence okay? I'm not a native speaker, so I might miss a
nuance here.
No, it's
On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote:
On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:
In addition, improvements to the GCC infrastructure allows several
existing warning flags new ability to spot problematic code.
Is this sentence okay? I'm not
On 10 January 2008 22:47, Joe Buck wrote:
On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote:
On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:
In addition, improvements to the GCC infrastructure allows several
existing warning flags new ability to spot problematic
On Thu, Jan 10, 2008 at 11:10:02PM -, Dave Korn wrote:
On 10 January 2008 22:47, Joe Buck wrote:
On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote:
On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:
In addition, improvements to the GCC infrastructure allows
On Wed, 2008-01-09 at 15:38 -0500, DJ Delorie wrote:
[EMAIL PROTECTED] This macro must never return zero, even if a register
+cannot hold the requested mode - indicate that with HARD_REGNO_MODE_OK
+and/or CANNOT_CHANGE_MODE_CLASS instead.
I think that HARD_REGNO_NREGS should not be returning
IIRC, the bug happened building either libgcc or newlib. If you want
to revert my latest patch in a local source tree and just try a build,
it's likely to show you an example ;-)
The GCC Steering Committee has appointed Jakub Jelinek, Joseph Myers,
and Richard Guenther to help with GCC Release Management.
It's a big job, and I haven't had as much time for it recently as I had
in the past. Jakub, Joseph, and Richard all have tremendous GCC
experience, and I think that
Yes, I know beginners get confused by and/or precedence. But
*every* language that I know of that has operator precedence places
'and' before 'or'.
FWIW, Bourne shell doesn't, and || have equal precedence there.
That's a bit off-topic though, as it's not an argument against your
actual
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
1 - 100 of 106 matches
Mail list logo
