--- Comment #11 from pva at gentoo dot org 2008-05-07 06:54 ---
(In reply to comment #9)
> The other issue here is that people want different colors for each of their
> warnings so why hardcode it.
It should be easy to make this configurable...
Well I've googled a bit and did not found
(I assume this goes into the category 'web', I couldn't find one for
'documentation')...
The documentation for the 'nonnull' attribute (section 5.27) currently says:
"The compiler may also choose to make optimizations based on the knowledge that
certain function arguments will not be null".
This
--- Comment #9 from dino at concisoft dot com 2008-05-07 06:15 ---
Understood. Just haven't been able to reproduce on a small piece of code :-(
It seems GNU C++ compiler doesn't give strict-aliasing warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-07 05:00 ---
(In reply to comment #4)
> The default new operator is implemented within gcc. It should be
> possible to let g++ know the alignment returned by the new operator.
The default one is but the user can override it as d
--- Comment #4 from hjl dot tools at gmail dot com 2008-05-07 04:56 ---
The default new operator is implemented within gcc. It should be
possible to let g++ know the alignment returned by the new operator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-07 04:52 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRME
Since both C++ and Objective-C support foreign exceptions, they should be
tested. I don't know where the best place to put the testcase. I want to say
the Objective-C testsuite and add a check to make sure the C++ front-end was
built.
--
Summary: Foreign exceptions for Objective-C a
--- Comment #7 from ian at airs dot com 2008-05-07 04:39 ---
I'll approve the patch. I think it's correct. I'll check it in in a day or
two, or you can go ahead and do it if you are ready. Thanks for testing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
--- Comment #3 from bangerth at dealii dot org 2008-05-07 04:21 ---
How is the compiler supposed to know about what alignment malloc can
produce? How can it know that ::operator new doesn't increase the
alignment automatically?
W.
--
bangerth at dealii dot org changed:
W
--- Comment #8 from bangerth at dealii dot org 2008-05-07 04:17 ---
The point is: without the complete source code nothing definitive can
be said whether it's the compiler's or the programmer's fault. Your chances
that someone will take the time to try to understand what's going on
incre
--- Comment #4 from mrs at apple dot com 2008-05-07 02:58 ---
Thinking and supposing are bad substitutes for solid engineering.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:45
---
One of the problems here is how to do a test case for writing to stdout. We
would have to create a pipe and write to it and read back from the other side.
I don't know how to do that in the testsuite.
--
ht
--- Comment #3 from mrs at apple dot com 2008-05-07 02:40 ---
Adding:
+_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE4syncEv;
+_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE5uflowEv;
+_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE6xsgetnEPci;
+_ZN
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:33
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:32
---
I committed the XFAILed test case. Sorry for the inconvenience.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:29
---
Subject: Bug 34974
Author: jvdelisle
Date: Wed May 7 02:28:45 2008
New Revision: 135017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135017
Log:
2008-05-06 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-07 00:18 ---
# __gnu_cxx::stdio_sync_filebuf
_ZTVN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EEE;
_ZN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EE4fileEv;
_ZN9__gnu_cxx18stdio_sync_filebu
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-07 00:12 ---
Was this ever supposed to be used external from libstdc++?
It is in the __gnu_cxx namespace. I don't think they are exported at all under
GNU/Linux with elf exports.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
A few routines seem to have disappeared from 4.0.0 to 4.2.1:
mrs2 $ nm /usr/lib/libstdc++.6.0.4.dylib | grep
__ZN9__gnu_cxx18stdio_sync_filebuf | c++filt
000252d2 T __gnu_cxx::stdio_sync_filebuf >::file()
000252fc T __gnu_cxx::stdio_sync_filebuf >::sync()
000252de T __gnu_cxx::stdio_sync_filebuf
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-06 22:56 ---
Created an attachment (id=15588)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15588&action=view)
gcc44-pr36013.patch
Patch I've bootstrapped/regtested on x86_64-linux. Will you check this in, or
should I mail
--- Comment #10 from brian at dessent dot net 2008-05-06 22:06 ---
Subject: Re: colorize output of gcc
esigra at gmail dot com wrote:
> printf("%s%s%s%s", warning_format_start, _("warning: "), _("the actual
> message"), warning_format_end);
But then that is not simply "adding a colou
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-06 21:58 ---
The other issue here is that people want different colors for each of their
warnings so why hardcode it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #8 from esigra at gmail dot com 2008-05-06 21:55 ---
(In reply to comment #7)
> If you added escape sequences to the string constants in the gcc source
> then it would only work for the C locale messages.
Adding escape sequences for colours would work as well with localizati
--- Comment #2 from igodard at pacbell dot net 2008-05-06 21:39 ---
Isn't ::foo the using'd class from name? If not, how does one befriend a class
that comes from a using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
--- Comment #3 from hjl at gcc dot gnu dot org 2008-05-06 21:36 ---
Subject: Bug 36155
Author: hjl
Date: Tue May 6 21:35:33 2008
New Revision: 135008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135008
Log:
2008-05-06 H.J. Lu <[EMAIL PROTECTED]>
PR testsuite/36155
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 21:31 ---
I don't think this is a bug, the friend class here is really ::foo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
This code:
namespace name {
class foo {
public:
template
voidbaz(T& t) { int i = t.dat; }
};
}
using namespace name;
class bar {
friend class foo;
int dat;
};
int main() {
bar b;
foo f;
f.baz(b);
}
gets you:
~/ootbc/members$ g++ f
--- Comment #7 from brian at dessent dot net 2008-05-06 21:28 ---
Subject: Re: colorize output of gcc
esigra at gmail dot com wrote:
> And seriously, what is more efficcent, adding a
> colour code sequence to the string constans in GCC that says "warning:",
> "error:" etc or having a
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
We need to escape non-printable characters when we read/write module files.
Otherwise, big bad ICE:
module m
character(*), parameter :: a ='H\0z'
end module m
use m
print *, a ! ICE
print *, ichar(a(1:1)), ichar(a(2:2)), ichar(a(3:3)) ! ICE
end
--
Summary: Non-ASCII character in
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-06 21:24 ---
Created an attachment (id=15587)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15587&action=view)
Trial patch
Here's an attempt at a patch, which should do the
right thing at least for this case.
--
http:
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-06 20:53 ---
Hi Jerry,
did you commit the test case to make sure we don't
regress again?
Thomas
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-05-06 20:50
---
Fixed on 4.3.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-05-06 20:49 ---
Fixed on 4.3.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-05-06 20:47 ---
Subject: Bug 35995
Author: tkoenig
Date: Tue May 6 20:46:41 2008
New Revision: 134999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134999
Log:
2008-05-06 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-05-06 20:47
---
Subject: Bug 35990
Author: tkoenig
Date: Tue May 6 20:46:41 2008
New Revision: 134999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134999
Log:
2008-05-06 Thomas Koenig <[EMAIL PROTECTED]>
PR
The first argument of gfc_error seems to be a format string of the form tagged
with gcc-internal-format elsewhere in the po file. But it seems gfc_error
formats are instead tagged with no-c-format. This is somewhat dangerous, since
msgfmt will not discover mistakes in the translation, mistakes th
--- Comment #4 from vmakarov at gcc dot gnu dot org 2008-05-06 19:22
---
Subject: Bug 36028
Author: vmakarov
Date: Tue May 6 19:22:07 2008
New Revision: 134996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134996
Log:
2008-05-06 Vladimir Makarov <[EMAIL PROTECTED]>
--- Comment #3 from vmakarov at redhat dot com 2008-05-06 19:11 ---
Thanks for decreasing the test case. The problem was in wrong mode of
save/restore stack slot when it was reused for another hard register. It
resulted in generation of wrong save/restore insn and after that in a wrong
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-06 19:09
---
I xfailed it and forgot to commit it. I will do that tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-05-06 19:02 ---
The compiler parts of this are done, or well along in terms of progress.
For the library, I think it makes sense to start with _GLIBCXX_USE_CHAR16_T and
_GLIBCXX_USE_CHAR32_T configury and macros, and then ease into
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-05-06 18:58 ---
Subject: Bug 36130
Author: bkoz
Date: Tue May 6 18:57:46 2008
New Revision: 134995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134995
Log:
2008-05-06 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:47 ---
(In reply to comment #5)
> But seriously colorization should not be done in the compiler. Just like IDE
> should not be part of the compiler ...
Colorization of a message is part of the message. It should obviously be don
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-06 18:45
---
The mingw-w64 CRT were wrong, but have been fixed since then.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:40 ---
(In reply to comment #4)
> I rather not add too much complexity to gcc diagnostic output. Which means
> no color.
We did not demand that you do it personally. We just think that it would be a
really good idea if someone
--- Comment #2 from hjl at gcc dot gnu dot org 2008-05-06 18:37 ---
Subject: Bug 36155
Author: hjl
Date: Tue May 6 18:37:03 2008
New Revision: 134994
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134994
Log:
2008-05-06 H.J. Lu <[EMAIL PROTECTED]>
PR testsuite/36155
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 18:21 ---
But seriously colorization should not be done in the compiler. Just like IDE
should not be part of the compiler ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
print *, 'Hello World'wrong ! position is OK
1
Error: Syntax error in PRINT statement at (1)
print *, 'Hello W\xC3\xB6rld'wrong ! Position is misleading
1
Error: Syntax error in PRINT statement at (1)
(see proposition by Tobias at
http://gcc.gnu.org/ml/g
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-06 18:12 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00333.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-06 18:10 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-06 18:09 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #5 from pva at gentoo dot org 2008-05-06 18:07 ---
Andrew, it's very pity to see this bug closed as invalid so fast. Besides being
useful, people enjoy colors and people work with compilers...
I've already stated that, but I repeat. colorgcc does not work in case you have
lo
--- Comment #4 from esigra at gmail dot com 2008-05-06 18:00 ---
(In reply to comment #3)
> 2) Standards are not freely distributable, thus they are not widely available.
You say that as if it was a general fact, but it is certainly not. For example
the Ada reference manual is available
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 17:37 ---
I rather not add too much complexity to gcc diagnostic output. Which means no
color. colorgcc could be extended to get the correct coloring for the
locazation.
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-06 17:35 ---
http://schlueters.de/colorgcc.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #2 from esigra at gmail dot com 2008-05-06 17:27 ---
I would definitely like GCC to produce colourized output. It can really improve
the readability. I miss that feature. It has my vote.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-06 17:15 ---
Subject: Bug 35313
Author: tromey
Date: Tue May 6 17:15:07 2008
New Revision: 134989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134989
Log:
gcc/testsuite
PR preprocessor/35313, PR preprocessor/36
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-06 17:15 ---
Subject: Bug 36088
Author: tromey
Date: Tue May 6 17:15:07 2008
New Revision: 134989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134989
Log:
gcc/testsuite
PR preprocessor/35313, PR preprocessor/36
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-06 17:11 ---
I think this is side effect of reverting the patch of PR 34974 (which caused
several regressions) without removing its now failing test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
--- Comment #4 from burnus at gcc dot gnu dot org 2008-05-06 17:09 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-06 17:07 ---
Subject: Bug 36117
Author: burnus
Date: Tue May 6 17:06:54 2008
New Revision: 134988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134988
Log:
2008-05-06 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #7 from dino at concisoft dot com 2008-05-06 16:54 ---
-O2 -fno-strict-aliasing does work.
I think the LC and LLC functions always cast from a derived class to a base
class. That shouldn't cause aliasing problems, but I need to learn more about
that.
Thanks.
--
http://
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-06 16:28 ---
Trevor, can you scale down your original proposal just to issue an
error when there is no class-specific operator new for a type with
an alignment greater than what malloc() guarantees? It will be
programmer's respon
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 16:11 ---
Actually we (Sony) have come up with a solution but not much as come about with
it though.
If you read Trevor's proposal, you would have found we did come up with one.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #20 from hjl dot tools at gmail dot com 2008-05-06 16:10
---
It is a bug in testcase. But g++ doesn't diagnose it properly. I opened
PR 36159 for it.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
[EMAIL PROTECTED] tmp]$ cat a.cc
#include
#include
struct A {
public:
__m128i m;
void init() { m = _mm_setzero_si128(); }
};
int main()
{
A * a = new A;
printf("Address of A: %p\n", a);
a->init();
delete a;
return 0;
}
[EMAIL PROTECTED] tmp]$ g++
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-06 15:45 ---
As I mentioned it looks like you are violating aliasing rules. Basically you
are accessing one type as another. But without a full testcase I cann't be
sure. Also Does -O2 -fno-strict-aliasing work?
--
http:/
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 15:44 ---
This is correct behavior.
template void bar( T& v ) { v.foo(); }
template void bar( B& x ) { bar( *x ); }
template void bar( A& x ) { bar( *x ); }
Since A i
--- Comment #5 from dino at concisoft dot com 2008-05-06 15:42 ---
Are we missing a const, or would you care to give a bit more specific comment?
I see that:
template static const LINK* LCC(Y* X) {
return static_cast(X);
}
could be missing a const in the declaration of
--- Comment #12 from hjl at gcc dot gnu dot org 2008-05-06 15:41 ---
Subject: Bug 35657
Author: hjl
Date: Tue May 6 15:41:08 2008
New Revision: 134987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134987
Log:
2008-05-06 H.J. Lu <[EMAIL PROTECTED]>
PR target/35657
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 15:28 ---
I don't think we should do this. There is already a secondary program that
does the coloring too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-06 15:26 ---
*** This bug has been marked as a duplicate of 36144 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 15:26 ---
*** Bug 36152 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36154
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 15:23 ---
This looks like you are violating C/C++ aliasing rules from that definition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-06 15:17 ---
The problem arises because fortran/trans-intrinsics.c and
libgfortran/intrinsics/size.c were not updated to deal with
the addition of the KIND keyword. If you change the code to
use size(array, dim=1, kind=long), then
Fortran 2008 (PR 33197) supports the BESSEL_* functions. However, for BESSEL_*N
there are two versions:
A) An elemental function BESSEL_YN(N, X) and BESSEL_JN(N,X)
B) An transformational function BESSEL_YN(N1,N2,X) and BESSEL_JN(N1,N2,Y)
(B) Is currently not supported:
The result of BESSEL_JN (N1
The following subroutine produces a segfault when compiled with the 05/02/08
snapshot of gfortran 4.4.0 under FreeBSD i386. I believe it is related to Bugs
36139 and 36140. This test case is just like the first one in Bug 36139 except
that the PARAMETER statement is omitted.
SUBROUTINE mnbrak
IMPL
Revision 134973
http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00133.html
breaks gfortran.dg/fmt_t_7.f on Linux/ia32 and Linux/Intel64.
--
Summary: gfortran.dg/fmt_t_7.f failed
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-06 14:43 ---
Confirmed. Note: Using -std=f95 the kind= is properly rejected.
==16567== Invalid read of size 4
==16567==at 0x4605FD: gfc_resolve_expr (resolve.c:2310)
==16567==by 0x465625: resolve_code (resolve.c:6195)
==
This patch
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00275.html
breaks UTF tests on Linux. Does check_effective_target_4byte_wchar_t
really work? I got
bash-3.2$ cat w.c
#if 0
#include
#endif
int
main ()
{
int dummy[sizeof (wchar_t) >= 4 ? 1 : -1];
return 0;
}
bash-3.2$ gcc -c w.c
w.c: I
--- Comment #5 from ian at airs dot com 2008-05-06 14:23 ---
I introduced DECL_BASED_ON_RESTRICT_P because the conversion to SSA discarded
almost all information about restrict qualifiers. The compiler was tracking
restrict qualifiers on the original variable, but not on the GIMPLE vari
--- Comment #3 from dino at concisoft dot com 2008-05-06 14:18 ---
template static LINK* LC(Y* X) {
return static_cast(X);
}
template static const LINK* LCC(Y* X) {
return static_cast(X);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
--- Comment #3 from ubizjak at gmail dot com 2008-05-06 12:55 ---
This is due to this code snippet from i386.c, ix86_expand_binop_builtin ():
--cut here--
/* ??? Using ix86_fixup_binary_operands is problematic when
we've got mismatched modes. Fake it. */
xops[0] = target;
--- Comment #1 from patrick at motec dot com dot au 2008-05-06 12:46
---
Created an attachment (id=15586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15586&action=view)
preprocessed source
preprocessed source for the file that causes the bug, as required by bug
writing guidelin
I'm encountering an internal compiler error with the gcc 4.3.0 release. I don't
think this is a duplicate of any other bugs.
Here is the command and subsequent output:
powerpc-eabispe-gcc -I../ -I/home/patrick/src/e7/prex
-I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex/include
--- Comment #1 from dominiq at lps dot ens dot fr 2008-05-06 12:17 ---
It seems to be fixed at (or before) revision 134981.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36152
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:14
---
Subject: Re: selected_char_kind_1.f90 undefined
reference with -m32
* fxcoudert at gcc dot gnu dot org wrote on Tue, May 06, 2008 at 02:08:59PM
CEST:
> > I can only see that happening with --enable-main
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-06 12:08
---
(In reply to comment #2)
> Next time you see such an issue, can you please try to note as many details as
> possible, open a PR and Cc: me?
I will, sorry. I was really more in a hurry of getting my patch regtesti
--- Comment #4 from jv244 at cam dot ac dot uk 2008-05-06 12:08 ---
older gcc versions (tested 4.2.3 and 4.3.0) seem to work fine
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
---
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:00
---
(In reply to comment #1)
> Is that a clean build? The symbol is new and I think sometimes dependencies
> don't get updated fine. I saw that one at some point, but a clean build made
> it
> disappear.
Next time
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-06 11:12
---
Is that a clean build? The symbol is new and I think sometimes dependencies
don't get updated fine. I saw that one at some point, but a clean build made it
disappear.
--
fxcoudert at gcc dot gnu dot org change
Use of an optional kind parameter on a call to the intrinsic size was added in
Fortran 2003, and is essential to avoid overflow when dealing with arrays
bigger than huge(0). The following example provides test code and demonstrates
this.
gfortran should warn that this is non-standard fortran 90/95
The tests gcc.dg/vect/vect-reduc-1short.c and vect-reduc-9.c fail at revision
134957 with:
/var/tmp//ccTL0QBh.s:61:invalid character '<' in mnemonic
/var/tmp//ccTL0QBh.s:65:invalid character '<' in mnemonic
The assembly file vect-reduc-9.s contains at line 47:
pw %xmm2, %xmm1
--
--
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 #6 from rguenther at suse dot de 2008-05-06 10:22 ---
Subject: Re: [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
On Tue, 6 May 2008, pinskia at gcc dot gnu dot org wrote:
> --- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 04:15
> ---
> Oh we don'
Compiling the following code fails with g++ 4.2.1 (also with 4.1.3 and 4.3.0
but works with 4.0.1 and 4.0.2)
--
template class A
{
public:
T& operator*() { return *m; }
T *m;
};
template class B
{
public:
T& operator*() { return *m; }
T *m;
};
class X
{
public:
It could be useful if gcc colorizes its output. Colors allow easier to
distinguish errors and warnings from makefile commands and etc... Currently
there exist a separate script like colorgcc which colorizes output of compiler
but it does not works with localized bugs.gentoo.org/168709 output so see
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-06 09:29 ---
Created an attachment (id=15585)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15585&action=view)
files (.f .gcda .mod) needed to reproduce the ICE and a README
attached the files needed to trigger the verify_hist
1 - 100 of 105 matches
Mail list logo