--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-09 02:09 ---
(In reply to comment #3)
> Anyone know where in the preprocessor this should be done? I.e. which
> function
> in libcpp?
>
> If someone would let me know, I'll write a patch.
>
This is the patch I was playing with
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-09 01:25
---
The patch below should do it.
Index: expr.c
===
--- expr.c (revision 129869)
+++ expr.c (working copy)
@@ -1981,11 +1981,7 @@ check_inquir
--- Comment #3 from sergey dot gcc at comrades dot id dot au 2007-11-09
01:14 ---
// Workaround:
class a
{
public:
template
operator T &() const
throw(typename ::boost::disable_if<
::boost::is_same >::type *)
{
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #1 from dje at google dot com 2007-11-09 00:57 ---
I looked into what's going on here.
This is a problem in the i386.md lshr+zext combiner patterns (or a problem in
the combine pass, depending on one's point of view). There are patterns in
i386.md that are supposed to handl
--- Comment #2 from brian dot e dot bliss at intel dot com 2007-11-09
00:06 ---
Subject: RE: Bogus codegen for openmp atomics w/ indirects operands on IPF
The C example looks correct (but you have to use the += operator to get
a legal example, which might have affected things):
% cat
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-08 23:56
---
Hi Christian,
I've tried on i686-darwin, and it works fine with GNU Fortran (GCC) 4.3.0
20071017. I will thus close this report as fixed, and I suggest you download
more recent binaries (either from macresearch,
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-08 23:51
---
(In reply to comment #7)
> However, most run time
> libraries do the simple thing when they see io-redirection - they close the
> stream file and re-open it as a ordinary file. Is there any reason GFORTRAN
> could
Test 176.gcc from SPEC CPU2000 fails at execution time on powerpc-linux when
compiled with "-O2 -ftree-vectorize -maltivec". The stack frame is corrupted
but the last few entries are several recursive calls of reload which calls
spill_failure which calls asm_noperands. This is odd, but when _eith
With -g -O0 -dA
void bar (char *, char *, char *, int size);
void foo (int size)
{
char temp[size];
char temp3[48];
temp[size-1] = '\0';
{
char temp2[size];
bar (temp, temp2, temp3, size);
}
};
in 3.4.x we got:
...
.uleb128 0x4# (DIE (0x74) DW_TAG_variable)
.b
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Test eon from SPEC CPU2000 fails to build with "-O2 -fnon-call-exceptions
-ffast-math -fsignaling-nans" due to an ICE for control flow in the middle of a
basic block. Two minimized tests show different warnings on both powerpc-linux
and i686-linux:
elm3b145% /opt/gcc-nightly/trunk/bin/g++ -O2 -fn
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Test eon from SPEC CPU2000 fails to build on powerpc64-linux with both -m32 and
-m64 and "-fnon-call-exceptions -ffast-math -fno-gcse " with an ICE in
calc_dfs_tree at dominance.c:393
Minimized test case:
class One {
public:
One () { e[0] = e[1] = 0.0; }
double e[2];
};
template
class T
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-08 21:45 ---
Confirmed.
Also, on 64bit x86_64 we don't see that this computes the modulus, but do
foobar:
.LFB2:
movl$10, %esi
movq%rdi, %rax
xorl%edx, %edx
divq%rsi
--- Comment #9 from ralf dot guetlein at web dot de 2007-11-08 21:42
---
(In reply to comment #8)
> also fails on 4.2.1
is this bug still present in 4.2.2?
Acc. to my obervations the error only shows up when not all auto variables can
be mapped to registers, and additional variables a
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-08 20:46 ---
> I think we already emit the error you'd like (and probably have done so for
> quite some time):
>
> Error: Function 'fn' at (1) must be PURE
Ok. Seemingly it has been fixed by collateral damage of a pure patch duri
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-11-08 20:31 ---
I am going to work on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-08 20:27 ---
Slightly reduced:
static const char s[] = "ab.cd.efghijk";
int
foo (const char *x)
{
const char *a;
int b = 0;
a = __builtin_strchr (s, '.');
if (a == 0)
b = 1;
else if ((a = __builtin_strchr (a + 1, '.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-11-08
20:21 ---
Fixed on trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at gcc dot gnu dot org 2007-11-08 20:20
---
Subject: Bug 33774
Author: dannysmith
Date: Thu Nov 8 20:20:02 2007
New Revision: 130024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130024
Log:
PR target/33774
* config/i386/cygming.
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-08 20:09 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #12 from bonzini at gnu dot org 2007-11-08 19:58 ---
Who prepares the patch? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
--- Comment #7 from dir at lanl dot gov 2007-11-08 19:56 ---
When I changed it to directly open the file, it was happy. You are right, of
course, backspacing a stream file is not permitted. However, most run time
libraries do the simple thing when they see io-redirection - they close the
--- Comment #11 from bonzini at gnu dot org 2007-11-08 19:56 ---
-fforce-addr for SPECfp is neutral, with big improvements in equake (and a
little on swim+lucas, but the latter has huge fluctuations).
SPECint drops from 1156 to 1130, with clear changes for the worse as
highlighted by my
--- Comment #8 from tromey at gcc dot gnu dot org 2007-11-08 19:51 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #7 from tromey at gcc dot gnu dot org 2007-11-08 19:50 ---
Subject: Bug 30297
Author: tromey
Date: Thu Nov 8 19:50:38 2007
New Revision: 130018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130018
Log:
gcc/cp
2007-11-08 Andrew Pinski <[EMAIL PROTECTED]>
P
--- Comment #4 from andreast at gcc dot gnu dot org 2007-11-08 19:34
---
The mentioned patch does not work properly, it only handles soft-float when
no-long-double-128 is used.
Working on a better one which should support both, 'double == long double' and
long double == 128.
--
htt
--- Comment #4 from pcarlini at suse dot de 2007-11-08 19:33 ---
Ok, at least we have a work around, then. About Cygwin, probably the reason is
that those features are made available as extensions not at C99 facilities (I'm
sure that this was the case at some point for many snprintf impl
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:26
---
Interestingly, I can't reproduce your problem on x86_64-linux. I'll try tonight
with my own i686-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:20
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:20
---
Subject: Bug 33739
Author: fxcoudert
Date: Thu Nov 8 19:19:50 2007
New Revision: 130016
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130016
Log:
PR fortran/33739
* scanner.c (start_sou
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-11-08
19:18 ---
The newlib stdio.h puts [v]snprintf declarations within a #ifndef
__STRICT_ANSI__ block.
Likewise for cygwin's ctype.h and isblank
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34032
--- Comment #2 from eric dot niebler at gmail dot com 2007-11-08 19:16
---
I didn't know about -std=gnu++0x. That seems to work. -std=c++0x doesn't.
FWIW, the stock gcc that comes with cygwin is 3.4:
$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyrigh
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:16
---
I think we already emit the error you'd like (and probably have done so for
quite some time):
$ cat k.f90
function f2 (fn, i)
integer :: i, fn
character (len = fn (i)) :: f2
end function f2
$ gfortran
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|sebor at roguewave dot com |
Status|NEW |SUSPENDED
http://gcc.gnu.
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-08 18:59
---
Created an attachment (id=14512)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14512&action=view)
Patch to add this feature
This patch does the job. I'll wait until next stage 1 to submit it.
--
fxcoude
--- Comment #3 from pcarlini at suse dot de 2007-11-08 18:59 ---
Thanks Martin. Therefore, let's confirm this bug to suspend it immediately
until our DR get resolved.
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #1 from pcarlini at suse dot de 2007-11-08 18:56 ---
Note that the library has autoconf tests for those C99 functions, which,
however, are run with the default C++98 compiler. Now I'm confused by this
__STRICT_ANSI__ thing on cygwin, does it mean that with -std=gnu++0x things
--- Comment #2 from sebor at roguewave dot com 2007-11-08 18:52 ---
Yes, I can confirm that, Paolo. The Apache C++ Standard Library behaves the
same (i.e., the facet sets eofbit).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34031
--- Comment #5 from dominiq at lps dot ens dot fr 2007-11-08 18:50 ---
Subject: Re: Warning when compiling with -m64 -ffast-math
on Intel Darwin
> this should have been compiled with -m64.
Apparently it has not been with -m64:
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/.
--- Comment #2 from janis at gcc dot gnu dot org 2007-11-08 18:49 ---
Created an attachment (id=14511)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14511&action=view)
test for powerpc-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34034
--- Comment #1 from janis at gcc dot gnu dot org 2007-11-08 18:49 ---
Created an attachment (id=14510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14510&action=view)
test for x86-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34034
Test perlbmk from SPEC CPU2000 hangs on powerpc-linux and i686-linux when
compiled with "-O2 -fno-tree-dce -fno-tree-dominator-opts". I didn't manage to
get a minimized testcase that fails on both targets, but do have two slightly
different tests. Both of them hang in the loop that begins "for (t
The code in c-lex.c that handles string concatenation allows weird,
and from what I can tell invalid, ObjC string concatentations.
In particular it allows any number of "@"s, and trailing "@"s.
E.g., it treats these as valid strings:
"foo" @ "bar"
@"foo" @
--
Summary: c
--- Comment #4 from dominiq at lps dot ens dot fr 2007-11-08 18:43 ---
Subject: Re: Warning when compiling with -m64 -ffast-math
on Intel Darwin
> Hmmm, this should have been compiled with -m64. Can you attach your build log
> for building GCC?
The full log or only the part concerni
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-08 18:40 ---
>/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crtfastmath.o, file is
not of required architecture
Hmmm, this should have been compiled with -m64. Can you attach your build log
for building GCC?
--
--- Comment #2 from john dot xia at esstech dot com 2007-11-08 18:39
---
../../gcc-4.2.2/gcc/libgcc2.c: In function '__neghi2':
../../gcc-4.2.2/gcc/libgcc2.c:80: error: unrecognizable insn:
(insn 40 39 41 3 ../../gcc-4.2.2/gcc/libgcc2.c:77 (set (reg:QI 57)
(const_int 0 [0x0])) -
--- Comment #1 from john dot xia at esstech dot com 2007-11-08 18:38
---
Created an attachment (id=14509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14509&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32886
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-08 18:37 ---
This might have been already fixed in 4.2.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-11-08 18:37 ---
Hi Martin. I think this inconsistency between num_get and money_get is just a
special case of our DR 585:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585
and that setting eofbit when end of file after su
Building with -std=c++0x causes __STRICT_ANSI__ to be defined. The new C++
headers expect the system C headers (ctype.h, stdio.h, etc.,) to declare
certain functions (isblank(), snprintf(), etc.) that are part of C++0x. The
system C headers that are part of cygwin aren't privy to this. The result i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
The C++ Standard, in section 22.2.6.1.1, says that if money_get::do_get
recognizes a valid sequence then it does not modify the ios_base::iostate
variable passed to it. That variable should be set to eofbit only if do_get
has not recognized a valid sequence and no more characters are available. T
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-08 17:59
---
I'm not sure about the wording, but the following patch does what you want:
Index: interface.c
===
--- interface.c (revision 129869)
+++ interface.c
--- Comment #1 from hjl at lucon dot org 2007-11-08 17:12 ---
I verified that it isn't fixed in gcc 4.3.0.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-08 17:05 ---
Bootstrapped/regtested on x86_64-linux, ppc64-linux (-m64 default) and
ia64-linux. No regressions. Could you please send it to gcc-patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34012
When compiling this sample code
int myvar;
int foo(int mynum)
{
if void *)0) ==
(
myvar & ((1U<<0) << mynum)
)
)
&& (mynum > 0)
)
{
return 1;
}
return 0;
}
with GCC-4.1.1, 4.1.2, 4.2.2, I get:
internal compiler e
--- Comment #15 from zadeck at naturalbridge dot com 2007-11-08 16:49
---
fixed
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
Status|NEW
--- Comment #14 from zadeck at naturalbridge dot com 2007-11-08 16:48
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
Richard Guenther wrote:
> On 11/7/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>> This patch keeps recursi
--- Comment #13 from zadeck at gcc dot gnu dot org 2007-11-08 16:46 ---
Subject: Bug 33826
Author: zadeck
Date: Thu Nov 8 16:45:53 2007
New Revision: 130006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130006
Log:
2007-11-07 Kenneth Zadeck <[EMAIL PROTECTED]>
PR mid
--- Comment #10 from paolo dot bonzini at lu dot unisi dot ch 2007-11-08
16:32 ---
Subject: Re: [4.3 Regression] can't find a register
in class 'GENERAL_REGS' while reloading 'asm'
ubizjak at gmail dot com wrote:
> --- Comment #9 from ubizjak at gmail dot com 2007-11-07 18:56 --
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-11-08 16:10
---
Interesting. Something platform-specific must be going wrong here.
The original build failure shouldn't have happened even without
the attached patch because ggc-none.o should provide a definition
of ggc_free. T
--- Comment #5 from burnus at gcc dot gnu dot org 2007-11-08 15:39 ---
The check-in was the following (note the wrong bug number).
Author: burnus
Date: Thu Nov 8 15:28:30 2007
New Revision: 130002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130002
Log:
2007-11-08 Tobias Bur
--- Comment #8 from burnus at gcc dot gnu dot org 2007-11-08 15:36 ---
Sorry, the check in was for PR 33917.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-08 15:35
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from benoit dot hudson at gmail dot com 2007-11-08 15:35
---
The fact that the error appears in backward_warning.h is another annoyance,
which is probably why the overly long descriptive message is there. Better
would be that #include would only report " is
deprecated;
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 15:33
---
Subject: Bug 34028
Author: fxcoudert
Date: Thu Nov 8 15:33:23 2007
New Revision: 130003
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130003
Log:
PR fortran/34028
* trans-intrinsic.c (gf
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-08 15:29 ---
Both problems fixed on the trunk (4.3.0). Other branches are not affected as
PROCEDURE is new.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-11-08 15:28 ---
Subject: Bug 33917
Author: burnus
Date: Thu Nov 8 15:28:30 2007
New Revision: 130002
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130002
Log:
2007-11-08 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-11-08
14:46 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use
> --- Comment #19 from manu at gcc dot gnu dot org 2007-11-08 14:22 ---
> (In reply to comment #16)
> > One possible solut
--- Comment #17 from buytenh at wantstofly dot org 2007-11-08 14:26 ---
Subject: Re: gcc only understands little endian ARM systems
When I (not Bernhard) wrote the original patch, Richard Earnshaw
didn't like the approach. See:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg022
--- Comment #19 from manu at gcc dot gnu dot org 2007-11-08 14:22 ---
(In reply to comment #16)
> One possible solution would be to annotate the division by the expected value
> of the result. Division expanders then may decide whether to expand to
> machine
> instruction/libcall or to
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2007-11-08 14:08
---
(In reply to comment #29)
> gfortran.fortran-torture/execute/intrinsic_bitops.f90
This one is now PR34028, for which I have a patch. The others one aren't ICEs,
but matches my regexp because they have "internal"
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-08 14:04
---
Testcase that doesn't require -fdefault-integer-8:
$ cat a.f90
program test
integer(kind=8) nvec(10), ivec(10), nclass
integer i
nvec(:)= 1
ivec(:) = 0
call zbase(nvec,ivec,10)
write(*,'(10I3)') ivec
--- Comment #18 from manu at gcc dot gnu dot org 2007-11-08 13:47 ---
(In reply to comment #4)
> > (probably the condition check is too conservative
> > so this isn't fully cooked yet):
>
> Way too conservative because even if you don't have the opcode, sometimes code
> can be produced
--- Comment #16 from nickc at redhat dot com 2007-11-08 13:47 ---
Hi Bernhard,
I have applied your patch. I made one small change: I adjusted the new
comments in the header files to:
/* TARGET_BIG_ENDIAN_DEFAULT is set in
config.gcc for big endian configurations. */
This w
--- Comment #15 from nickc at gcc dot gnu dot org 2007-11-08 13:44 ---
Subject: Bug 16350
Author: nickc
Date: Thu Nov 8 13:44:09 2007
New Revision: 12
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=12
Log:
PR target/16350
* config.gcc: For arm*b-* define TARGET_BIG_EN
--- Comment #1 from holger dot hopp at sap dot com 2007-11-08 13:41 ---
Created an attachment (id=14508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14508&action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34029
I discovered following internal compiler error in gcc 4.3.0 (trunk).
The cause is the svn change 125925.
The title sounds to be similar to bug 34018, but the removal of change
125925 does not help for bug 34018. So this bug must be something
different.
gcc version: gcc 4.3.0 svn revision 125925
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
Happens on x86-linux, with both -m32 and -m64. Spotted by running the testsuite
with -fdefault-integer-8.
$ cat intrinsic_bitops.f90
implicit none
integer(kind=4) :: k, o
o = 0
k = 12
if (ishft (k, o+2_8) .ne. 48_8) call abort
end
$ gfortran -O2 intrinsic_bitops.f90
intrinsic_bito
enable-languages=c,c++,fortran,objc,obj-c++
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.3.0 20071108 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-08 13:13 ---
This is my proposal.
"This header is deprecated and may be removed in the future. Please, consider
using an equivalent, non-deprecated interface for the requested functionality.
To disable this warning use -Wno-depre
--- Comment #18 from jakub at gcc dot gnu dot org 2007-11-08 13:11 ---
I have also retested with the http://www.sqlite.org/gccbug32575.tar.gz
tarball and on the trunk it passes just fine with -O2.
--
jakub at gcc dot gnu dot org changed:
What|Removed
-torture/execute/20071108-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20071108-1.c
Modified:
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
--- Comment #4 from Christian dot Carli at cern dot ch 2007-11-08 13:05
---
Subject: Re: Internal compiler error: in gfc_add_modify, at
fortran/trans.c:159
Hello,
The two files needed to (re)produce the error message have been
uploaded
via the bugzilla interface.
I have
--- Comment #16 from jakub at gcc dot gnu dot org 2007-11-08 12:54 ---
Continuing after the #c11 .. #c15 unrelated PR32540 comments with the original
bug:
I've built -r127926 and -r127927 cc1 and it seems this wasn't fixed just by
a side-effect.
Although p can be either retval of foo or
--- Comment #3 from Christian dot Carli at cern dot ch 2007-11-08 12:53
---
Created an attachment (id=14507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14507&action=view)
Include File
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
--- Comment #2 from Christian dot Carli at cern dot ch 2007-11-08 12:51
---
Created an attachment (id=14506)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14506&action=view)
Fortran source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 12:49
---
Does the same thing happen with C?
void foo(float *lhs, float*rhs) {
#pragma omp atomic
*lhs = *rhs + *lhs;
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 12:45
---
(In reply to comment #0)
> Since I did not find any way to attach the input files (grfa.f and
> grpckg1.inc) to the present report
Once you write the report, there is a "Create a New Attachment" link on the
bugzi
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-11-08 12:42
---
The problem here is that code assumes that variable without DEFAULT_DEF is not
in SSA. Arguments that are unused also do have DEFAULT_DEF=NULL, this patch
should fix it. I am testing it now.
Honza
Index: tree-inl
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 12:36
---
Can you get the same warning with a C program? And can you please post the
output of running gfortran with -v, so that we know what subprocesses are
invoked and what arguments they get passed?
--
fxcoudert at
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
PR32044 makes it for months impossible to compile the Linux kernel with gcc
4.3, but I'll leave the discussions who's technically at fault (and whether gcc
4.3 will ever be able to compile the Linux kernel) to the people who know more
about such things.
But the fact that the code emitted with -Os
--- Comment #3 from gdr at cs dot tamu dot edu 2007-11-08 11:23 ---
Subject: Re: warning in backward_warning.h is illegible
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| We cannot assume that people encountering the warning will have web access.
That is true. But, the
1 - 100 of 110 matches
Mail list logo
