There should be a way to poison a symbol only when it is used as a function or
macro call. I suggest that following a symbol with a pair of parentheses might
be a serviceable syntax for this. With this feature, the symbol rindex would
still be usable for variables.
--
Summary: #pragma
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-07-23 04:37
---
Subject: Bug 36852
Author: jvdelisle
Date: Wed Jul 23 04:36:54 2008
New Revision: 138073
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138073
Log:
2008-07-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-07-23 04:30
---
Subject: Bug 36852
Author: jvdelisle
Date: Wed Jul 23 04:29:15 2008
New Revision: 138072
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138072
Log:
2008-07-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-23 03:03 ---
I have a patch, I still have to check complex, I think it is ok because we have
expanded the division by the time we ran LIM.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-23 02:16 ---
In fact this is one case where the old loop.c gets it correct :(.
4.1.1 with IV-opts off:
.L2:
sth 3,0(9)
addi 9,9,2
bdnz .L2
Which means I can declare this as a regression from 3.4.x.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-23 02:10 ---
(In reply to comment #2)
> Also IV-opts is messing up anyways, it should have done out+1 as the base
> instead of out, blah.
Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 .
--
http://gcc.gnu.org/bu
Take:
void fred(unsigned short in, unsigned short *out1)
{
__SIZE_TYPE__ i;
for (i=0;i<100;i++)
out1[i+1] = in;
}
For PPC we currently generate:
.L2:
addi 9,9,1
slwi 0,9,1
sthx 3,4,0
bdnz .L2
But if change the code just so slightly to:
void fred(uns
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-23 02:01 ---
>for the loop on the trunk.
I think the trunk improved fold somewhere along the way, because the 4.3 I have
from January has the extra sign extension.
>We will get a zero extension in the assembly (on Powerpc-linux
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-23 01:55 ---
Hmm, I think the sign/zero extension is needed.
Even doing:
void fred(unsigned short in, unsigned short *out1)
{
int i;
for (i=0;i<100;i++)
out1[i+1] = out1[i]*in;
}
--- CUT ---
We will get a zero ext
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36904
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-07-23 01:39
---
I have reviewed our code.
First, we reject the internal unit for namelist when using -std=f95.
$ gfc -std=f95 pr36895.f90
pr36895.f90:4.8:
write(line,nml=stuff)
1
Error: Fortran 2003: Internal file at
Take the following testcase:
#include
#define xprint_vec(type) void x##type(vector type v) { }
xprint_vec(float);
This used to work in 4.3 and before but does not currently. The problem here
was introduced when the context sensitive keyword support was added.
--
Summary: [4.4 Regr
--- Comment #13 from paolo dot carlini at oracle dot com 2008-07-23 01:28
---
You see, as I feared: this class of warnings coming from the middle-end is
especially nasty, because cannot be suppressed by any normal means.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #12 from hjl dot tools at gmail dot com 2008-07-23 01:23
---
(In reply to comment #11)
> Thanks. Actually, I think the experiment would be more meaningful if you could
> put also the equivalent of your main (a calling function, that is) inside the
> header, because in your t
--- Comment #11 from paolo dot carlini at oracle dot com 2008-07-23 01:16
---
Thanks. Actually, I think the experiment would be more meaningful if you could
put also the equivalent of your main (a calling function, that is) inside the
header, because in your testcase the warning is trig
--- Comment #10 from hjl dot tools at gmail dot com 2008-07-23 01:04
---
(In reply to comment #9)
> > I said "It comes from an application." It isn't from system header file.
>
> Yes, and that doesn't answer my question. I asked if the pragma is able to
> suppress a warning triggered b
For AVR the following test fail. Probably since the day they were created.
For AVR there are no "vectypes" so they all fail message test
I don't know if these should be skipped as invalid or there is some significant
issue that warrant XFAIL.
FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-22 23:42 ---
(In reply to comment #2)
> This is most likely fixed on the trunk already.
4.3.x also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36900
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-22 23:40 ---
This is most likely fixed on the trunk already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from fmuldoo at me dot lsu dot edu 2008-07-22 22:54 ---
Subject: Re: Namelist I/O error: Bogus "Cannot match
namelist object"
Great, and thanks very much. I'm very glad you found it as it is the
only thing preventing me from using gfortran with my code. This i
--- Comment #9 from paolo dot carlini at oracle dot com 2008-07-22 22:53
---
> I said "It comes from an application." It isn't from system header file.
Yes, and that doesn't answer my question. I asked if the pragma is able to
suppress a warning triggered by your kind of snippet, IF, w
--- Comment #15 from lothar at tradescape dot biz 2008-07-22 22:01 ---
What I am worried about is that if it is not marked as a regression nobody
cares to fix it although it breaks a real application that works with gcc
4.3.2.
If you have any insights how to improve the boost intrusive
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-07-22 21:52
---
(In reply to comment #13)
> (In reply to comment #11)
> From an application perspective it is still a regression, as it works happily
> with gcc 4.2.3
Yes but it is boost's fault that boost tries to be smart about
--- Comment #13 from lothar at tradescape dot biz 2008-07-22 21:48 ---
(In reply to comment #11)
>From an application perspective it is still a regression, as it works happily
with gcc 4.2.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-07-22 21:43
---
I think someone needs to kick the hell out of boost for making crappy code. I
am going to remove the regression marker for now because it is definitely a bit
weird what boost is doing and not normal for real code.
--- Comment #8 from hjl dot tools at gmail dot com 2008-07-22 21:42 ---
(In reply to comment #7)
> (In reply to comment #6)
> > It comes from an application.
>
> This doesn't answer my question.
>
I said "It comes from an application." It isn't from system header file.
--
http:/
--- Comment #7 from paolo dot carlini at oracle dot com 2008-07-22 21:32
---
(In reply to comment #6)
> It comes from an application.
This doesn't answer my question.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #6 from hjl dot tools at gmail dot com 2008-07-22 21:30 ---
(In reply to comment #4)
> Out of curiosity: if this kind of code appears in a system header, is #pragma
> GCC system_header able to suppress the warning? Of course I'm asking because
> this is the most annoying feat
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-22 21:29 ---
It is a regression since the same correct code no longer compiles
with "-Werror -Wall" after upgrading from gcc 4.1/4.2 to 4.3.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-22 21:26
---
Out of curiosity: if this kind of code appears in a system header, is #pragma
GCC system_header able to suppress the warning? Of course I'm asking because
this is the most annoying feature of PR 36633 (which im
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-22 21:18 ---
> The warning is very fragile: if the buffer in main() is not static then
> there is no failure; is the size is passed as a constant there is no error.
Not really, if you read my comment, you will understand why th
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-22 21:13 ---
This regression is introduced by revision 120898:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00603.html
The simplified testcase:
---
typedef unsigned char __u8;
typedef unsigned short __u16;
static inline unsigned
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-22 20:50 ---
This happens because the warning happens very early in the compiler so it does
not know that the case5 is not going to be used. I think the warning is
correct and not really bogus if you take that into account.
--
On Linux/x86-64, gcc 4.3/4.4 give:
[EMAIL PROTECTED] gcc]$ cat /tmp/y.c
/*
* compile w/:
* gcc -Wall -Werror -fno-strict-aliasing -O2 -c foo.c
*/
typedef unsigned char __u8;
typedef unsigned short __u16;
static inline void * foo(
void * to, const void * from, int n)
{
switch ( n )
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-22 18:25 ---
@jakub: I confirm that doing:
if (!DECL_CONTEXT (decl))
{
DECL_CONTEXT (decl) = current_function_decl;
}
at the beginning of one_static_initialization_or_destruction() allows the
compilation to not cras
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-22 18:07 ---
(In reply to comment #2)
> Thanks a lot Manuel! Maybe I will even be able to come to this, thanks to your
> suggestions for a fix.
>
I think there is a problem with my suggestion: -pedantic-errors does not only
affect
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-22 17:47 ---
> I will check on this later tonight or this week. I have wondered about that
> comma myself.
Thanks! I believe the comma should be valid, even though it is superfluous and
"looks wrong". Thus it were nice if one co
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-22 17:29
---
Thanks a lot Manuel! Maybe I will even be able to come to this, thanks to your
suggestions for a fix.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from domob at gcc dot gnu dot org 2008-07-22 17:11 ---
The message locus for constant-string is not yet perfect, but the effort to
benefit ratio in this case is probably rather bad, so I mark this as fixed.
In my commit, I changed the "Unexpected element" error to include
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-22 17:09
---
Really, there isn't much we can do here: according to the standard
(27.6.2.5.4/4) each char is widened *individually* (via out.widen), and some of
the chars in the character-literal at issue (not belonging to t
--- Comment #2 from domob at gcc dot gnu dot org 2008-07-22 17:06 ---
Subject: Bug 29835
Author: domob
Date: Tue Jul 22 17:05:55 2008
New Revision: 138063
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138063
Log:
2008-07-22 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-07-22 16:47
---
I will check on this later tonight or this week. I have wondered about that
comma myself.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from manu at gcc dot gnu dot org 2008-07-22 16:30 ---
One testcase could use #include_next in a system header and compile with just
-pedantic-errors. This should be silent but it currently emits an error.
Another testcase could be just:
static int sc = INT_MAX + 1;
com
>From PR35637 but this is a general issue of the diagnostic machinery.
The problem is: -pedantic no warning, -pedantic-errors gives an
error.
Explanation: The pedantic warning is in a system header, so it doesn't get
emitted. When using -pedantic-errors, it is an error, and errors are always
emi
--- Comment #4 from bonzini at gnu dot org 2008-07-22 15:48 ---
i had a patch to expand pow at the tree level, but it conflicted with fold
(which consistently tried to rebuild pow function calls). the outcome might be
better now that we have PAREN_EXPR, though.
--
bonzini at gnu dot
A small c++ program causes this ICE if optimization level is 1 ore above
[my_computer]$ g++ -v -save-temps -O3 compiler_bug.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --
--- Comment #1 from oliver dot regenfelder at gmx dot at 2008-07-22 15:32
---
Created an attachment (id=15942)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15942&action=view)
preprozessor output for the file triggering the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #1 from mironov dot ivan at gmail dot com 2008-07-22 14:55
---
Created an attachment (id=15941)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15941&action=view)
Preprocessed source (utf-8)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36899
Small example:
==
#include
#include
using namespace std;
int main()
{
locale::global(locale(""));
wcout.imbue(locale());
wcout << "Hello world! ðÒÉ×ÅÔ ÍÉÒ!" << endl;
return 0;
}
===
--- Comment #3 from hjl dot tools at gmail dot com 2008-07-22 13:44 ---
*** This bug has been marked as a duplicate of 36450 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #12 from hjl dot tools at gmail dot com 2008-07-22 13:44
---
*** Bug 36896 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from schwab at suse dot de 2008-07-22 13:35 ---
Created an attachment (id=15940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15940&action=view)
Assembler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36898
--- Comment #1 from schwab at suse dot de 2008-07-22 13:34 ---
Created an attachment (id=15939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15939&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36898
The attached test case is causing a spurious dependency violation message from
the assembler. The problem seems to be that the assembler is clearing all qp
mutex relations after a call, but the compiler does not emit .pred.rel.mutex
after them.
$ gcc -O2 -c -save-temps xdisp.c
xdisp.s: Assembler
--- Comment #3 from jhuddleston at hughes dot net 2008-07-22 13:17 ---
Created an attachment (id=15938)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15938&action=view)
zip container with two files: C++ and GFORTRAN
burnus at gcc dot gnu dot org requested a small sample set demons
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-22 12:30 ---
(In reply to comment #1)
> Proposed patch passed regression test on i686-pc-linux-gnu..
Patch is approved (or obvious and simple, whatever you prefer :-)
--
tkoenig at gcc dot gnu dot org changed:
Wh
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-22 12:11 ---
Analogously for:
integer foo(size([x]))
real x
As ifort writes:
error #6279: A specification expression object must be a dummy argument, a
COMMON block object, or an object accessible through host or use asso
--- Comment #1 from ro at gcc dot gnu dot org 2008-07-22 12:05 ---
Jan, did you have a chance to take a look? Your patch breaks Tru64 UNIX
bootstrap
since almost 4 months.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-22 11:58 ---
Related to PR 32972 (optimizing cshift the way that other
array intrinsics have been done will cure this).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-22 11:48
---
Te be clear, this is ICE on invalid
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
Trying to compile the following program:
typedef void (*fptr)();
fptr zeroptr = 0;
template struct foo { };
template struct foo { };
void f() { }
foo m_foo;
I get the message:
test.cpp:6: internal compiler error: in unify, at cp/pt.c:13401
Please submit a full bug report,
with preprocessed source
--- Comment #2 from dorit at gcc dot gnu dot org 2008-07-22 10:39 ---
(In reply to comment #1)
> One problem is vectorizable_conversion. Is there a way to support
> V4DF/V4DI <-> D4SI/V4SF
> V8SI <-> V8SF
With the current framework, the only way to support
V8SI <-> V8SF
is to implemen
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-07-22 10:29 ---
Fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-22 10:27 ---
Subject: Bug 36890
Author: tkoenig
Date: Tue Jul 22 10:27:10 2008
New Revision: 138050
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138050
Log:
2008-07-22 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #22 from manu at gcc dot gnu dot org 2008-07-22 09:59 ---
Not working on this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #2 from manu at gcc dot gnu dot org 2008-07-22 09:56 ---
No reply for a long time. Old version of GCC. Closing as INVALID.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-22 09:50 ---
Better summary to find duplicates.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2008-07-22 09:48 ---
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from manu at gcc dot gnu dot org 2008-07-22 09:46 ---
Subject: Bug 28079
Author: manu
Date: Tue Jul 22 09:45:58 2008
New Revision: 138049
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138049
Log:
2008-07-22 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR 28
Component|tree-optimization |middle-end
Keywords||ice-on-valid-code
Known to work||4.3.1
Summary|ICE when gcc 4.4.0-20080722 |[4.4 Regression] ICE in
|compiles
--- Comment #1 from linuxl4 at sohu dot com 2008-07-22 09:23 ---
Created an attachment (id=15937)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15937&action=view)
printf_size.i
gcc printf_size.c -c -std=gnu99 -O2 -fgnu89-inline -Winline -Wwrite-strings
-Wstrict-prototypes
the command is :
gcc printf_size.c -c -std=gnu99 -O2 -fgnu89-inline -Winline -Wwrite-strings
-Wstrict-prototypes -mpreferred-stack-boundary=2 -I..
if change -O2 to -O1 , ICE will dispear .
what's wrong ?
--
Summary: ICE when gcc 4.4.0-20080722 compiles glibc 2.6.1/
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-22 09:01 ---
"10.10.2 Namelist output"
"The form of the output produced is the same as that required for input, except
for the forms of real, character, and logical values. The name in the output is
in upper case. With the except
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-22 08:30 ---
This is caused by
static const unsigned int READ_CHUNK = 4096;
and, further down,
n = (base < READ_CHUNK) ? base : READ_CHUNK;
where base is a gfc_offset (a signed quantity).
The "unsigned" is unnecessary.
--- Comment #6 from r dot emrich at de dot tecosim dot com 2008-07-22
07:53 ---
(In reply to comment #5)
> For me it is working today
>
I don't Know if it's related but today (rev. 138048) I get the following on
x86_64-unknown-linux-gnu:
/SCRATCH/tmp.haKcfD9964/Linux/x86_64-unknown-l
--- Comment #4 from manu at gcc dot gnu dot org 2008-07-22 07:20 ---
Closing as invalid then.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Stat
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/543dbbd5a3cb5fce
Jerry, could you check whether Richard Maine's concerns are correct or not? NAG
f95 and g95 write everything in one line; g95 has also a trailing comma, NAG
does not. (ifort 11beta and sunf95 don't supp
77 matches
Mail list logo
