--- Comment #9 from matz at gcc dot gnu dot org 2010-03-17 17:03 ---
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00774.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
If one specifies any visibility attribute on an enum class emits the type
attributes ignored after type is already defined warning.
Easy to reproduce! Just add the following lines anywhere and compile them
(without -Wno-attributes):
enum class __attribute__((visibility(default))) Number
{
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-17 17:21
---
*** Bug 43408 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-17 17:21
---
*** This bug has been marked as a duplicate of 43407 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from pluto at agmk dot net 2010-03-17 17:28 ---
this is a bug in glibc-2.11.1/sysdeps/x86_64/fpu/s_sinl.S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43405
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/110fb27c70e1a193
Reported by: Philippe Bourdin
The following program always prints -42 independent whether the file exists
or not. It at least should initialize the variable by -1.
!---
integer :: i
i
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-17 17:34
---
Glibc is a separate project, see http://sources.redhat.com/bugzilla/
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2010-03-17 17:34 ---
If one checks libgfortran/io/*, one sees that (dtp-common.flags
IOPARM_DT_HAS_SIZE) is only used for read.c and transfer.c and is not touched
at all for inquire.c.
Work-around: gfortran offers the STAT, FSTAT, and
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-17 17:43 ---
I was wondering about connected files. (I think it only applies to
inquire_via_unit.) What does one return here if the file has not been flushed?
The *STAT result or does one calls flush on the unit and uses then
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-17 17:47 ---
Fixed in 4.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pluto at agmk dot net 2010-03-17 17:51 ---
more details...
intel (24319101.pdf) manual describe requirements for fsin opcode:
Calculates the sine of the source operand in register ST(0) and stores
the result in ST(0). The source operand must be given in radians
--- Comment #7 from burnus at gcc dot gnu dot org 2010-03-17 17:58 ---
Patch by Changpeng, which has been approved for 4.6 Stage 1 and moves the
pass_lim up;
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00775.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
--- Comment #5 from eli dot osherovich at gmail dot com 2010-03-17 18:05
---
The very same code compiled by the Intel C compiler runs as expected.
Moreover, the prototype of sinl is as follows
long double sinl(long double x);
and 1e22 definitely withing the bounds of long double.
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-17
18:19 ---
Subject: Re: [4.5 Regression] ICE in stage1 compiling __bswapdi2
var-tracking expects that if frame_pointer_rtx (resp. arg_pointer_rtx,
depending on whether FRAME_POINTER_CFA_OFFSET or
--- Comment #3 from vsoni at tilera dot com 2010-03-17 19:33 ---
(In reply to comment #2)
I read that t.f promotes to int. And that is exactly what the C++ frontend
does:
That's plausible, but the standard, especially it's intent, is unclear I think.
I see three plausible
On Linux/x86-64, gcc 3.4 failed to bootstrap gcc 4.5.0 at
revision 157518. I got:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-Wold-style-definition -DHAVE_CONFIG_H -I. -I.
--- Comment #8 from vz-gcc at zeitlins dot org 2010-03-17 20:05 ---
Sorry for a late follow up but I've just discovered that this change broke
compilation of code using wxWidgets library with -pedantic-errors -std=c++98
switches because wxWidgets uses constructions such as (simplified):
--- Comment #10 from burnus at gcc dot gnu dot org 2010-03-17 20:16 ---
(In reply to comment #9)
(In reply to comment #8)
Maybe we just need to document that -pedantic changes the range of integers
to
be what the Fortran standard requires (a symmetric range).
The Fortran
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-17 20:27 ---
False alarm. I did run out of memory.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-17 21:01 ---
Created an attachment (id=20132)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20132action=view)
gcc45-pr43403.patch
Let's go with this patch then. Can you please regtest it?
--
jakub at gcc dot gnu dot org
--- Comment #2 from pault at gcc dot gnu dot org 2010-03-17 21:07 ---
As Daniel has indicated, this has nothing to do with gfortran.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-17
21:09 ---
Subject: Re: [4.5 Regression] ICE in stage1 compiling __bswapdi2
Let's go with this patch then. Can you please regtest it?
Yes. I'll try it when I get home this evening.
Dave
--
--- Comment #21 from mikpe at it dot uu dot se 2010-03-17 21:13 ---
(In reply to comment #20)
no change in the libjava testsuite when built with these binutils
But that's still thumb not arm like in comment #16? All my results are from
plain arm (armv5tel) builds.
--
--- Comment #9 from dodji at gcc dot gnu dot org 2010-03-17 21:15 ---
The situation has change quite a lot since gcc 4.3.0.
Now a DW_TAG_member is emitted for the static member variable, and only one
DW_TAG_variable is emitted to represent the variable definition.
So I guess the bug
--- Comment #8 from changpeng dot fang at amd dot com 2010-03-17 21:22
---
Created an attachment (id=20133)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20133action=view)
patch with the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
--- Comment #22 from mikpe at it dot uu dot se 2010-03-17 21:23 ---
I did another binutils experiment. I reverted my patch to disable general
merging of table entries, and instead disabled generating new and merging
cantunwind entries. With that binutils libjava regressed just like with
--- Comment #11 from dominiq at lps dot ens dot fr 2010-03-17 21:31 ---
Well, the number model is symmetric. See Fortran 2003 ...
I agree, but it is a very pedantic view that should at least be mentioned in
the manual.
Now I think the implementation is not consistent:
[macbook]
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-17 21:44 ---
Argh, seems ARM is very badly abusing PRE_DEC:
(insn/f 72 41 73 2 /opt/trunk/libgcc/../gcc/libgcc2.c:553 (parallel [
(set (mem/c:BLK (pre_dec:BLK (reg/f:SI 13 sp)) [6 A8])
(unspec:BLK [
--- Comment #1 from tromey at gcc dot gnu dot org 2010-03-17 21:46 ---
I tried it and it works fine with svn head.
Make sure to rm a.h before trying with different flags.
Or, use -force.
--
tromey at gcc dot gnu dot org changed:
What|Removed
C++ inlining of virtual calls does not occur in many instances when it should
be easy to determine that it is safe.
The problem occurs when there is an object that is referred to via a pointer or
reference. Normally a virtual call through a pointer cannot be inlined because
it is not known what
--- Comment #8 from sje at cup dot hp dot com 2010-03-17 22:09 ---
I tried the patch and didn't have any problem bootstrapping and I didn't see
any regressions. It also fixed my small test case, but when I went back and
tried some of the other tests from PR 28490 I still saw some of
symbol.c's gfc_build_class_symbol has:
(*as) = NULL; /* XXX */
Thus the following invalid program is accepted as the check for
Assumed size array at %L must be a dummy argument fails as sym-as == NULL.
module m
type t
end type t
end module m
subroutine foo()
use m
class(t), pointer
--- Comment #12 from kargl at gcc dot gnu dot org 2010-03-17 22:20 ---
(In reply to comment #10)
(In reply to comment #9)
(In reply to comment #8)
Maybe we just need to document that -pedantic changes the range of
integers to
be what the Fortran standard requires (a
--- Comment #13 from kargl at gcc dot gnu dot org 2010-03-17 22:26 ---
(In reply to comment #11)
Well, the number model is symmetric. See Fortran 2003 ...
I agree, but it is a very pedantic view that should at least be mentioned in
the manual.
You forgot to attach your patch.
The powerpc64-unknown-linux-gnu compiler generates much worse code on the
inl1130 function in the gromacs benchmark from spec 2006 when compiling for the
VSX instruction set with -mcpu=power7 (or -mvsx). The code in question in not
vectorizable, and in fact only uses integer and single precision
--- Comment #1 from meissner at gcc dot gnu dot org 2010-03-17 22:35
---
Created an attachment (id=20134)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20134action=view)
Test case from the gromacs benchmark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
--- Comment #2 from meissner at gcc dot gnu dot org 2010-03-17 22:37
---
Created an attachment (id=20135)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20135action=view)
Bzip2 tar file of the assembly output for altivec, vsx, scalar, and no-spill
--
--- Comment #3 from meissner at gcc dot gnu dot org 2010-03-17 22:38
---
Created an attachment (id=20136)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20136action=view)
Bzip2 tar file of the ira dump output for altivec, vsx, scalar, and no-spill
--
--- Comment #6 from ramana at gcc dot gnu dot org 2010-03-17 22:43 ---
As per Comment #4 and based on conversations on IRC, this is certainly a target
bug . I have verified that this very testcase attached also has the same effect
on the arm-eabi target ( a simple -g -O2 is enough to
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
DWARF4 draft: http://dwarfstd.org/doc/DWARF4-public-review.pdf
gfortran uses
main()
to initialize the program and
MAIN__
as actual Fortran program.
DWARF4 offers:
DW_AT_main_subprogram Main or starting subprogram
Unit containing main or starting subprogram
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-17 23:14 ---
I had filed PR 23280 for that really but it turned out I used the incorrect
dwarf and it pushed to alternative entry points.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from wilson at codesourcery dot com 2010-03-17 23:25 ---
Subject: Re: [ia64] Inappropriate address spills
On Wed, 2010-03-17 at 22:09 +, sje at cup dot hp dot com wrote:
I tried the patch and didn't have any problem bootstrapping and I didn't see
any regressions.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
|
--- Comment #10 from sje at cup dot hp dot com 2010-03-17 23:47 ---
Reading Richard's initial comment I thought the problem was that the code was
(or could be) illegal because the relocation may be out of range and we
shouldn't
use the gprel relocation for any of these constant pool
I came across some source code that failed to compile in gcc 4.4.3 with -O3
because the kernel shot gcc for using too much memory. After I minimized the
code (and converted it from C++ to C for simplicity) into the below example,
gcc 4.4.3 still took over a minute of CPU and a gigabyte of RAM for
--- Comment #11 from wilson at codesourcery dot com 2010-03-18 00:12
---
Subject: Re: [ia64] Inappropriate address spills
On Wed, 2010-03-17 at 23:47 +, sje at cup dot hp dot com wrote:
Reading Richard's initial comment I thought the problem was that the code was
(or could be)
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Priority|P3 |P1
--- Comment #8 from doko at ubuntu dot com 2010-03-18 00:52 ---
checked that this patch fixes the testcase, and doesn't show any regressions on
ia64-linux-gnu for the testsuite (4.4 branch 20100311).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43348
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:14
---
I have a few other bugs ahead of this, but I will fix it if no one else does so
before I get to it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43409
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:38
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 02:38:17 2010
New Revision: 157527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157527
Log:
2010-03-17 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:43
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 02:43:10 2010
New Revision: 157528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157528
Log:
2010-03-17 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:52
---
The above patches take care of several other corner cases with end file
conditions. Thanks Terry for report and Tobias for helping with test cases.
I am not proceeding to back port to 4.4.
--
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2010-03-18 02:54
---
Correction s/not/now
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43265
--- Comment #9 from bergner at gcc dot gnu dot org 2010-03-18 03:10 ---
Subject: Bug 42427
Author: bergner
Date: Thu Mar 18 03:10:04 2010
New Revision: 157530
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157530
Log:
gcc/
PR target/42427
* config/rs6000/rs6000.c
I came across some code that previously compiled at -O3 without complaint on
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) and gcc version 4.4.1 (Ubuntu
4.4.1-4ubuntu9), but triggered a segmentation fault on gcc 4.4.3. After
minimization, here is the segmentation fault:
$
--- Comment #1 from wlam at kosmix dot com 2010-03-18 03:11 ---
Created an attachment (id=20137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20137action=view)
Minimized C++ source causing segmentation fault in gcc 4.4.3 at -O3
--
--- Comment #10 from bergner at gcc dot gnu dot org 2010-03-18 03:14
---
Fixed.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from wlam at kosmix dot com 2010-03-18 03:14 ---
Oops, the description is truncated:
(built from the GNU source distribution, though the Fedora version of 4.4.3
shows similar behavior--
$ g++ -Wfatal-errors -c -O3 -Wall foo.ccfoo.cc: In member function void
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2010-03-18 03:52
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 03:51:43 2010
New Revision: 157532
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157532
Log:
2010-03-17 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #5 from carrot at google dot com 2010-03-18 03:52 ---
In this case arm_arm_address_cost does the right thing. The problem is in
function should_replace_address.
When two addresses have same address cost, we choose the one with higher rtx
cost. The reason is That has the
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2010-03-18 03:56
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 18 03:55:52 2010
New Revision: 157533
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157533
Log:
2010-03-17 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2010-03-18 03:58
---
IO library is significantly changed from 4.3 to 4.4/4.5 No Backport to 4.3
Closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
101 - 163 of 163 matches
Mail list logo
