--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #1 from laurent at guerby dot net 2008-12-15 09:23 ---
4.3.2 bootstrap doesn't fail in stage1 so this is a trunk regression.
--
laurent at guerby dot net changed:
What|Removed |Added
-
--- Comment #2 from schwab at suse dot de 2008-12-15 09:33 ---
Probably related to bug 37739. Building with optimisation may be a workaround.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
after
#include
strlen(),strcat(), etc are declared in not in std namespace (like:
std::strlen()), but in global namespace (like: ::strlen() )
--
Summary: namespace, ,
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-15 14:47 ---
Subject: Bug 38113
Author: mikael
Date: Mon Dec 15 14:46:22 2008
New Revision: 142763
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142763
Log:
2008-12-15 Mikael Morin
PR fortran/38113
*
Some time ago, rth changed reload so that calls to
dse_record_singleton_alias_set and dse_invalidate_singleton_alias_set were
removed. I believe that this was an accidental side effect of fixing some
other bug. These calls identified these addresses as being "special", in the
sense that the valu
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-15 09:44 ---
Answer by Bader:
"For generics, the "R" part of the TKR rule applies, which prohibits *both*
above cases."
=> gfortran does it right. (I'm not fully convinced, but I buy this.)
Diagnostics: Bader writes:
"For han
--- Comment #13 from whaley at cs dot utsa dot edu 2008-12-15 14:52 ---
>No; "The nice thing about standards is that there are so many to choose from"
>is a well-known saying.
And also one without application here. I am aware of no other standard for
Linux ABI other than the one in th
--- Comment #3 from laurent at guerby dot net 2008-12-15 11:46 ---
>From Richard Earnshaw:
<<
GCC (to be precise binutils) has limit on the maximum program size on
ARM, which is 32MBytes (based on the span of the BL instruction).
Unfortunately, when GCC is built without optimization and
--- Comment #9 from zadeck at naturalbridge dot com 2008-12-15 15:32
---
Andrew,
What is your point here?
1) Is it your claim that anything that is arg_pointer_rtx related would
automatically qualify as being safe enough to remove dead stores to?
or
2) Is it your claim that if we c
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-15 15:51 ---
(In reply to comment #2)
> Subject: Re: WARNING: Could not compile gcc.dg/compat/struct-layout-1
> generator
>
> > This is really PR 36443.
>
> Aside from darwin specific issues with the environment, the problem l
--- Comment #4 from laurent at guerby dot net 2008-12-15 15:54 ---
More discussions here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00861.html
Also from Richard:
Recent binutils should also be able to generate binaries exceeding this limit,
though there is some runtime and additio
I tried to compile the test given for c_funloc in
http://gcc.gnu.org/onlinedocs/gfortran/C_005fFUNLOC.html#C_005fFUNLOC
and I got an ICE with trunk and 4.3.2:
funloc.f90: In function 'main':
funloc.f90:20: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6836
--
Summary
--- Comment #4 from J dot J dot vanderHeijden at gmail dot com 2008-12-15
16:41 ---
Created an attachment (id=16911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16911&action=view)
IRIX-6.2 only dummy implementation of pthread_setrunon_np()
This patch adds an empty implementatio
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-15 13:42 ---
explanation http://gcc.gnu.org/ml/fortran/2008-12/msg00137.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
--- Comment #5 from J dot J dot vanderHeijden at gmail dot com 2008-12-15
16:48 ---
Test results: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01459.html
Please approve.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38400
--- Comment #4 from brtnfld at hdfgroup dot org 2008-12-15 16:52 ---
>
> In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 - of these only
> "ifort" allows it (even with all checking enabled - thus presumably only by
> accident and not on purpose).
>
> Thus I wonder wheth
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-15 10:48 ---
I think the patch in comment 2 is about the wrong gfc_error.
Additionally, the generic resolution seems to be correct in gfortran (-> PR
38506).
* * *
In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot
|dot org
--- Comment #3 from dodji at gcc dot gnu dot org 2008-12-15 10:01 ---
Started looking at this. Got a work in progress patch at
http://www.seketeli.org/dodji/patches/gcc/PR30161-patch.txt. It's not ready for
review yet, I am just backuping it online.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from dominiq at lps dot ens dot fr 2008-12-15 12:48 ---
Compiling the test in comment #4 gives:
pr37829_2.f90:21.6:
d = c_funloc (g)
1
Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr)
at (1)
looking the gfortran sources for "c_funptr"
--- Comment #13 from jv244 at cam dot ac dot uk 2008-12-15 17:31 ---
(In reply to comment #12)
> Could you try with the addition of " -fno-strict-aliasing
> -fno-strict-overflow"? See pr38520.
The testcase in PR38492 indeed works if I use:
gfortran -O2 -ffast-math -funroll-loops -ftree
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-15 17:32 ---
As suggest in PR38431, works fine with:
gfortran -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
-fgraphite -fgraphite-identity -cpp -D__FFTSG -fno-strict-overflow test.f90
--
http://gcc.gnu.org/bugzi
--- Comment #5 from tobi at gcc dot gnu dot org 2008-12-15 17:37 ---
According to your readings, is the following valid?
DO 10 I=1,10
IF (.TRUE.) THEN
10 END IF
END
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 17:38 ---
Re. comment #14: Yes, I suppose so. Why do you want to remove gcse-las from
mainline. Not that I'm against it -- ideally RTL gcse.c would not work on
memory at all anymore -- but I wouldn't remove gcse-las until we
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-15 17:40 ---
Why is that considered a bug?
If you want strlen etc. in std:: namespace, you need to include .
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
The stack usage of the code gcc-4.x generated looks inefficient on x86 and
x86_64. A simple test case is below;
#define copy_from_asm(x, addr, err) \
asm volatile( \
"1:\tmovl %2, %1\n" \
"2:\n" \
".
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-15 18:10 ---
Subject: Bug 38487
Author: mikael
Date: Mon Dec 15 18:08:42 2008
New Revision: 142766
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142766
Log:
2008-12-15 Mikael Morin
PR fortran/38487
*
--- Comment #14 from joseph at codesourcery dot com 2008-12-15 18:17
---
Subject: Re: Gcc misaligns arrays when stack is forced
follow the x8632 ABI
On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote:
> And also one without application here. I am aware of no other standard fo
--- Comment #28 from paolo dot carlini at oracle dot com 2008-12-15 18:42
---
*** Bug 38531 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-15 18:42
---
*** This bug has been marked as a duplicate of 6257 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-15 18:50
---
By the way, in gcc4.3.x (and 4.4.x of course), is not included
anymore by as an implementation detail (it could, it's allowed by
Standard), thus this specific issue is strictly speaking moot now. But
still i
--- Comment #6 from kargl at gcc dot gnu dot org 2008-12-15 18:58 ---
(In reply to comment #5)
> According to your readings, is the following valid?
> DO 10 I=1,10
> IF (.TRUE.) THEN
> 10 END IF
>END
>
See constraint C825, page 165 in F2003 and restriction R214
on page 11.
/* When a function has been defined using the 'noreturn' attribute,
* there is no reason to save the callee-saved registers, mainly
* because the function is not going to return to the caller.
*
* This can save a few bytes of code generation for embedded-type
* applications which may use 'nore
--- Comment #14 from jv244 at cam dot ac dot uk 2008-12-15 19:06 ---
(In reply to comment #13)
>
> (i.e. no need for -fno-strict-aliasing) I'll give it a try on the full code.
OK, full code compiles & runs the test example with -fgraphite
-fgraphite-identity -fno-strict-overflow
--
--- Comment #7 from tobi at gcc dot gnu dot org 2008-12-15 19:16 ---
(In reply to comment #6)
> (In reply to comment #5)
> > According to your readings, is the following valid?
> > DO 10 I=1,10
> > IF (.TRUE.) THEN
> > 10 END IF
> >END
> >
>
> See constraint C825, page 165
--- Comment #9 from andreast at gcc dot gnu dot org 2008-12-15 19:35
---
Tested the patch on F10.
Results here:
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01223.html
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-15 19:38 ---
as this file is included in a project compiled normally with '-O3 -march=native
-funroll-loops' the timing in that case is also important. As I'm finding out,
this becomes unworkable (>6h, and still compiling).
Looking
--- Comment #15 from jv244 at cam dot ac dot uk 2008-12-15 19:44 ---
(In reply to comment #14)
> OK, full code compiles & runs the test example with -fgraphite
> -fgraphite-identity -fno-strict-overflow
compiling with
-g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -f
When I configured gcc with --enable-languages=c, I got
[...@gnu-6 gcc]$ cat x.c
unsigned int
foo ()
{
return __builtin_ia32_stmxcsr ();
}
[...@gnu-6 gcc]$ ./xgcc -B./ -O2 -S x.c
x.c:1: internal compiler error: tree check: expected class type, have
exceptional (tree_list) in type_hash_list,
There are two C_LOC issues related to not going through all expr->ref. The
second one was found by Scot Breitenfeld (in PR 36771 comment 4), the first one
I found while trying to reduce it.
* * *
use iso_c_binding
character(len=2),target :: str(2)
print *, c_loc(str(1))
end
Result:
Gives no e
--- Comment #5 from burnus at gcc dot gnu dot org 2008-12-15 20:35 ---
(In reply to comment #4)
> > In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95
> > - of these only "ifort" allows it
>
> as you said using C_LOC(X(1:1)) works fine and that is what I ended up doing.
> BTW
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-15 20:57 ---
Pilot error.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNC
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-15 21:17 ---
One of the bottlenecks seems to be find_temp_slot_from_address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-15 21:27 ---
OK, to elaborate: I'm playing with this test case on ia64-linux, and I reduced
the test case by some 8000 lines to make it compilable at all. With this 8000
lines less, it actually spends more time for me in "expand
--- Comment #15 from whaley at cs dot utsa dot edu 2008-12-15 21:32 ---
>GCC chose to change the *unwritten* standard for the ABI in use for IA32
>GNU/Linux.
This is not true. Prior to this change, gcc followed the *written* standard
provided by the LSB. You chose to violate the stan
Sent from my iPhone
On Dec 15, 2008, at 1:33 PM, "whaley at cs dot utsa dot edu" > wrote:
--- Comment #15 from whaley at cs dot utsa dot edu 2008-12-15
21:32 ---
GCC chose to change the *unwritten* standard for the ABI in use for
IA32 GNU/Linux.
This is not true. Prior to t
--- Comment #16 from pinskia at gmail dot com 2008-12-15 21:39 ---
Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI
Sent from my iPhone
On Dec 15, 2008, at 1:33 PM, "whaley at cs dot utsa dot edu"
wrote:
>
>
> --- Comment #15 from whaley at cs dot ut
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-12-15 21:40
---
I think this was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01996.html
Could you check whether it works for you?
--
rsandifo at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-15 21:53 ---
For the inline heuristics, almost all time is also spent in stack slot related
stuff. The culprit is estimate_stack_frame_size (or actually,
add_alias_set__conflicts) in cfgexpand.c.
(What are we doing in cfgexpand a
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 21:55 ---
>From cfgexpand.c:
static void
add_alias_set_conflicts (void)
{
size_t i, j, n = stack_vars_num;
for (i = 0; i < n; ++i)
{
tree type_i = TREE_TYPE (stack_vars[i].decl);
bool aggr_i = AGGREGATE_T
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-15 21:56 ---
Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #17 from whaley at cs dot utsa dot edu 2008-12-15 22:01 ---
>LSB was written years after we had already did this back in gcc 3.0.
>Please check the history before saying gcc followed a written standard
>when none existed when this change was done.
LSB was merely the umbr
On Mon, Dec 15, 2008 at 2:01 PM, whaley at cs dot utsa dot edu
wrote:
> LSB was merely the umbrella bringing together a bunch of pre-existing
> standards
> for use in Linux.
There is the problem, LSB did the incorrect thing of thinking the
written standard applied to what really was being done w
--- Comment #18 from pinskia at gmail dot com 2008-12-15 23:02 ---
Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI
On Mon, Dec 15, 2008 at 2:01 PM, whaley at cs dot utsa dot edu
wrote:
> LSB was merely the umbrella bringing together a bunch of pre-existing
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-15 23:26 ---
The reason why they are saved is so that you can have a good way of debugging
noreturn functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #19 from whaley at cs dot utsa dot edu 2008-12-15 23:39 ---
>There is the problem, LSB did the incorrect thing of thinking the written
>standard applied to what really was being done when the LSB was doing its
>work. Standards are made to be amended. Witness how many RFCs
It seems that -fstring-aliasing option doesn't work:
$ cat test.c
#include
int
main (void)
{
int a = 0x12345678;
short *b = (short *) &a;
b[1] = 0;
if (a == 0x12345678)
abort();
exit(0);
}
$ gcc -fstrict-aliasing test.c
$ ./a.out
$ gcc -O2 test.c
$ ./a.out
Aborted
There a
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-15 23:54 ---
-fstring-aliasing is only used when optimizing ..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38537
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-15 23:55 ---
On the trunk we do get a warning:
t.c: In function main:
t.c:7: warning: dereferencing pointer ({anonymous}) does break
strict-aliasing rules
t.c:7: note: initialized from here
Though it seems like the warning i
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-15 23:57 ---
Richard, seems like the variable is going to anonymous and it is defined via a
POINTER_PLUS_EXPR, we should go back one more on def-use chain.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-16 00:01 ---
-combine should go away and the code which supports should be removed really.
It is always broken and will most likely will always be broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-16 00:03 ---
int16_t* ip = (int16_t*)&m1;
printf("%hi %hi %hi %hi %hi %hi %hi %hi \n", *ip++, *ip++, *ip++,
*ip++, *ip++, *ip++, *ip++, *ip);
That is violating C/C++ aliasing rules even if __m128i is m
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 00:06 ---
These all do not produce warnings for 4.4 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-16 00:08 ---
Does -fno-strict-aliasing work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|code generation error |[4.4 Regression] code
|
--- Comment #20 from joseph at codesourcery dot com 2008-12-16 00:09
---
Subject: Re: Gcc misaligns arrays when stack is forced
follow the x8632 ABI
On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote:
> If you thought the standard adopted by LSB was the wrong
> one, you should
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 00:09 ---
This sounds like an issue with the redhat provided GCC and not in GCC you are
trying to compile.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 00:11 ---
t.c:1: error: 'i' declared as reference but not initialized
Why do you think this is valid code? Reference variables have to be
initialized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-16 00:12 ---
extern int &i;
is valid though. Note in C, int i; is a tentative definition while in C++,
there is no such thing as a tentative definition so it is normal definition and
therefor since it is a reference type variabl
--- Comment #1 from H9XLrv5oXVNvHiUI at spambox dot us 2008-12-16 01:03
---
Any news?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-16 01:08 ---
Confirmed, not a regression. If you swap around main and the template, the
link works correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from esmithmail at gmail dot com 2008-12-16 01:40 ---
Subject: Re: gcc build fails - won't link in 'gcc' on SVN obtained 20081213
ok -- except that I've been using the 4.0.0 branch for months. I
successfully built (and used) gcc-core from SVN on all these dates:
2008080
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-16 01:44 ---
That could mean this was not exposed in the redhat GCC version until that
revision of GCC. The error is coming from linking of the native program and
not from the new GCC.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-16 02:08
---
(In reply to comment #9)
> Andrew,
>
> What is your point here?
My point here is that currently we do:
gi->frame_related =
(base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx);
But if w
--- Comment #7 from rwgk at yahoo dot com 2008-12-16 02:17 ---
(In reply to comment #6)
> Does -fno-strict-aliasing work?
>
Nope. I just tried it with svn revisions 129269 and 142737.
Adding -fno-strict-aliasing does not change the (wrong) result.
Thanks for looking at this!
--
h
--- Comment #8 from hjl dot tools at gmail dot com 2008-12-16 04:01 ---
Gcc 4.3 20080428 behaves the same. -m32 returns 0.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
For the code below stored in xtemp.f90
module abc
implicit none
contains
subroutine xmain()
call foo(func("_"//bar()))
end subroutine xmain
!
function bar() result(yy)
character (len=1) :: yy(1)
yy = ""
end function bar
!
elemental function func(yy) result(xy)
character (len=*), intent(in) :: yy
c
When -O3 key is specified, gcc inlines functions with inline asm
without dismangling the labels in these asm fragments. This occurs in
all flavours of the asm pieces: CONSTRAIN, MASM and plain string:
% cat gas-label.c
f() {
#ifdef CONSTRAIN
asm volatile ("lab:mov %0, %0"::"r"(1.5F));
#elif d
--- Comment #3 from lisp2d at lisp2d dot net 2008-12-16 05:52 ---
More exact example:
.h:
extern int& i;
.cpp:
int& i; // ok
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-16 06:22 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20468#c1
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-16 07:24 ---
Confirmed on (powerpc|i686)-apple-darwin9 revision 142767.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
--- Comment #17 from jv244 at cam dot ac dot uk 2008-12-16 07:51 ---
(In reply to comment #16)
> Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me.
Thanks for the analysis. Detailed enough to have me peak in the gcc code for
once.
This would mean that the array stack_v
87 matches
Mail list logo
