For the simple program, forward.c:
#include stdio.h
typedef struct _item_st {
int data;
struct item_st *next;
} item_t;
int
main (int argc, char *argv[])
{
item_t head = {0, NULL};
head.data = 1;
printf (head.data: %d ptr: %p\n, head.data, (void *)head.next);
return 0;
Qun-Ying zhu.quny...@gmail.com writes:
No warning at all. Should gcc warn about the *next pointer points to
an unknown structure? I know it is allow by the standard, but most of
the case, it indicates some error in the code.
Hmm? Where do you expect to warn?
You never dereference the
Hello,
I think I have found a bug in G++ . Please submit it to the bug tracker
(I do not want to open an account there) if you think it is a bug - I am
not sure about it.
While I worked with search+replace I accidently had following in my
source code:
const char* DUMMY = DUMMY;
It is
On Sun, 29 Apr 2012, Daniel Marschall wrote:
I think I have found a bug in G++ . Please submit it to the bug tracker (I do
not want to open an account there) if you think it is a bug - I am not sure
about it.
Opening an account is not that bad. The right list to ask for help is
Peter Bigot a écrit:
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode for
function pointers. If gcc supports this, it's not obvious how.
I
On 4/29/2012 8:51 AM, Georg-Johann Lay wrote:
Peter Bigot a écrit:
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode for
function pointers. If
On Sun, Apr 29, 2012 at 7:51 AM, Georg-Johann Lay a...@gjlay.de wrote:
Peter Bigot a écrit:
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode
Robert Dewar de...@adacore.com writes:
Just to be clear, there is nothing in the standard that forbids the
sizes being different AFAIK? I understand that both gcc and apps
may make unwarranted assumptions.
POSIX makes that assumption, via the dlsym interface.
Andreas.
--
Andreas Schwab,
On 4/29/2012 9:25 AM, Andreas Schwab wrote:
Robert Dewarde...@adacore.com writes:
Just to be clear, there is nothing in the standard that forbids the
sizes being different AFAIK? I understand that both gcc and apps
may make unwarranted assumptions.
POSIX makes that assumption, via the dlsym
This question is not appropriate on this mailing list, questions about
using GCC should be sent to the gcc-h...@gcc.gnu.org list, please take
any follow up there instead, thanks.
On 29 April 2012 07:14, Qun-Ying wrote:
No warning at all. Should gcc warn about the *next pointer points to
an
Peter Bigot a écrit:
Georg-Johann Lay a...@web.de wrote:
Peter Bigot a écrit:
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode for
function
On Sun, 29 Apr 2012 09:43:02 -0400
Robert Dewar de...@adacore.com wrote:
On 4/29/2012 9:25 AM, Andreas Schwab wrote:
Robert Dewarde...@adacore.com writes:
Just to be clear, there is nothing in the standard that forbids the
sizes being different AFAIK? I understand that both gcc and apps
On 4/29/2012 12:47 PM, Basile Starynkevitch wrote:
My biased point of view is that designing a processor instruction set (for
POSIX-like
systems or standard C software in mind) with function pointers of different
size than
data pointers is today a mistake: most software make the implicit
Has anyone seen better results from the testsuite for GO ?
I am getting ugly results from the testsuite and this somewhat
baffles me as the GCC 4.6.3 compiler I am using tests very well
thus :
http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02433.html
However when I bootstrap GCC 4.7.0 and
On Sun, 29 Apr 2012 12:50:44 -0400
Robert Dewar de...@adacore.com wrote:
On 4/29/2012 12:47 PM, Basile Starynkevitch wrote:
My biased point of view is that designing a processor instruction set (for
POSIX-like
systems or standard C software in mind) with function pointers of different
On 4/29/2012 1:19 PM, Basile Starynkevitch wrote:
For instance, I don't think that porting the Linux kernel (or the FreeBSD one)
to such an
architecture (having data pointers of different size that function pointers) is
easy.
Well it doesnt' surprise me too much that GNU/Linux has
Basile Starynkevitch bas...@starynkevitch.net writes:
`dlsym` is the obvious hint
Most programs don't use dlsym.
also simply that most (probably nearly all) Linux/ELF systems and Unix
systems have same
size for data and function pointers.
Those that don't use function descriptors.
Marc Feeley, the author of the Gambit Scheme compiler and interpreter, has
measured the time to make the current version of Gambit, and then to run an
application in the Gambit interpreter, for every release of gcc since gcc-2.95.
For each version of gcc, Feeley built Gambit in each of two
Snapshot gcc-4.8-20120429 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120429/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53089
--- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-29
06:07:51 UTC ---
Looks fixed to me. H.J. or Honza, close?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53156
--- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-29
06:59:14 UTC ---
Author: hp
Date: Sun Apr 29 06:59:09 2012
New Revision: 186940
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186940
Log:
PR target/53156
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53156
--- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-29
07:00:16 UTC ---
Author: hp
Date: Sun Apr 29 07:00:01 2012
New Revision: 186941
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186941
Log:
PR target/53156
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53148
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53156
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53148
--- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-04-29
07:12:10 UTC ---
Author: tkoenig
Date: Sun Apr 29 07:12:03 2012
New Revision: 186942
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186942
Log:
2012-04-29 Thomas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
08:05:59 UTC ---
(In reply to comment #0)
It would be convenient if I
could just write the whole code with __int128 and let the compiler do the
optimization by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53112
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
08:42:36 UTC ---
(In reply to comment #1)
On the other hand, tree-vrp does have the information that the
differences are in [-4294967295, 4294967295], which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Comment #42 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-04-29 09:25:24 UTC ---
Author: paolo
Date: Sun Apr 29 09:25:17 2012
New Revision: 186944
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186944
Log:
2012-04-29 Marc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53149
--- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-29
09:47:47 UTC ---
Author: manu
Date: Sun Apr 29 09:47:43 2012
New Revision: 186945
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186945
Log:
2012-04-29 Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53149
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-29
10:01:41 UTC ---
Hi Hans-Peter, could you try with the latest revision? I believe this is fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51625
Yichao Zhou broken.zhou at gmail dot com changed:
What|Removed |Added
CC||broken.zhou at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
--- Comment #6 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
13:15:40 UTC ---
I don't think it matters that much whether the return type is int or bool,
compared to the inconvenience of having 2 functions that conflict.
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53159
Bug #: 53159
Summary: Missing narrowing check
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53089
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #5 from Marc Glisse marc.glisse at normalesup dot org 2012-04-29
14:12:12 UTC ---
Created attachment 27261
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27261
build_enumerator patch
Changes the behavior on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53157
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53145
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-29 16:23:05
UTC ---
This fixes the regression. But I don't see why it should make
a difference.
diff --git a/gcc/common.opt b/gcc/common.opt
index 14c88bf..cd760fc 100644
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53145
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-04-29 16:29:27
UTC ---
/* Return a heap allocated producer string including command line options
if -grecord-gcc-switches. */
static char *
gen_producer_string (void)
{
size_t j;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41969
travnick mikolajmm at gmail dot com changed:
What|Removed |Added
CC||mikolajmm at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53160
Bug #: 53160
Summary: likely wrong code bug
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53160
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com
I just tried to compile the package luminance-hdr-2.2.1-3
on gcc-4.8 trunk dated 20120429 on an AMD x86_64 box.
The compiler said
/home/dcb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161
--- Comment #1 from dcb dcb314 at hotmail dot com 2012-04-29 20:15:53 UTC ---
Created attachment 27262
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27262
gzipped C++ source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-29
20:23:59 UTC ---
Reducing ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684
--- Comment #1 from davem at gcc dot gnu.org 2012-04-29 20:48:49 UTC ---
Created attachment 27263
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27263
Testcase distilled from glibc's math/libm-test.inc compare_float_internal()
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51625
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52684
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #30 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-04-29 23:36:15 UTC ---
Author: paolo
Date: Sun Apr 29 23:36:09 2012
New Revision: 186948
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186948
Log:
2012-04-29 Marc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
It doesn't help to attach this into a closed bugreport. LTO allows GCC to do a
lot more transformations
and sometime the transformations hurts the final performance. This is a bug and
we will try to fix it.
From information you gave it is however impossible to guess what may possibly
go wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41969
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz 2012-04-30 00:39:08 UTC
---
It doesn't help to attach this into a closed bugreport. LTO allows GCC to do a
lot more transformations
and sometime the transformations hurts the final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53162
Bug #: 53162
Summary: unexpanded parameter packs not diagnosed in alias
template used in default argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #11 from Mike Stump mikestump at comcast dot net 2012-04-30
01:08:24 UTC ---
also don't test that the warning goes away with -w. We don't test the
warning
turns into an error with -Werror.
Don't we?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53149
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38412
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53161
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186946-install
--program-prefix=r186946- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120429 (experimental) (GCC)
The regression was mostly due to a failed assumption by the
test-case (a minimal solution must match the assembly code
patterns), but also due to a different suboptimal sequence after
the reload change.
The committed patch below fixes the regresssed code, the
test-case, and tweaks the comment to
Hello world,
I have committed the attached patch as obvious as rev. 186942
after regression-testing. Will also commit to 4.7 in a few
days.
Thomas
2012-04-29 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/53148
* frontend-passes.c (create_var): If the statement has a
Bootstrapped and regression tested. Committed as obvious at revision 186943.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 186942)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-04-29 Manuel López-Ibáñez
Since Wsuggest-attribute=[pure|const|noreturn] was introduced, it
makes sense to have Wsuggest-attribute=format. This patch makes this
the canonical form of Wmissing-format-attribute (the old form is still
accepted and documented).
Bootstrapped and regression tested.
OK?
2012-04-29 Manuel
An oversight from a previous commit. Committed as obvious after testing.
Cheers,
Manuel.
Index: gcc/testsuite/gcc.dg/20011021-1.c
===
--- gcc/testsuite/gcc.dg/20011021-1.c (revision 186942)
+++ gcc/testsuite/gcc.dg/20011021-1.c
New version of the patch. Bootstrapped and regression tested.
Is this version OK?
2012-04-29 Manuel López-Ibáñez m...@gcc.gnu.org
Dodji Seketeli do...@seketeli.org
PR 5297
* libcpp/files.c (maybe_shorter_path): New.
(find_file_in_dir): Use it.
A new version using unsigned int for the flag type. It also adds
another use in the C FE.
I am not asking for approval, only whether this
approach/implementation is the way to go.
Cheers,
Manuel.
On 23 April 2012 20:09, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
So, apart from the type
On Sat, Apr 28, 2012 at 6:45 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Sat, 28 Apr 2012, Gabriel Dos Reis wrote:
On Sat, Apr 28, 2012 at 5:41 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
the attached follows the precisions on the definition of is_modulo in DR
612. I believe this
On Sun, Apr 29, 2012 at 4:28 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
Since Wsuggest-attribute=[pure|const|noreturn] was introduced, it
makes sense to have Wsuggest-attribute=format. This patch makes this
the canonical form of Wmissing-format-attribute (the old form is still
Hi,
On 04/29/2012 05:17 AM, Jason Merrill wrote:
On 04/28/2012 07:12 AM, Paolo Carlini wrote:
isn't, but clearly can be instantiation dependent. Then, I guess the way
I'm proposing to handle this is by starting some sort of embryonic
instantiation_dependent_expression_p and using it only here,
Hello,
I noticed that the file lex.c had C++ style comments, which I believe is
against the coding standards of the project.
Fixed, tested and applied to the mainline as per the obvious rule.
libcpp/
* lex.c (lex_raw_string): Change C++ style comments into C
style
Arno,
Pascal, I'd suggest you go ahead and revert this patch.
This patch has already been reverted by Eric on Apr 10 on gcc-4.7 branch.
--
Pascal Obry
--
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Jason Merrill ja...@redhat.com writes:
On 04/25/2012 05:07 AM, Dodji Seketeli wrote:
+ /* If the first token we got was a padding token, let's put
+ it back into the stream so that cpp_get_token will get it
+ first; and if we are currently expanding a macro, don't
+
Jason Merrill ja...@redhat.com writes:
On 04/25/2012 11:31 AM, Dodji Seketeli wrote:
+#define EXPANSION_POINT_LOCATION_FILE(LOC) \
+ ((expand_location_to_expansion_point (LOC)).file)
+#define EXPANSION_POINT_LOCATION_LINE(LOC) \
+ ((expand_location_to_expansion_point
On 04/29/2012 05:42 PM, Paolo Carlini wrote:
Otherwise, I'm attaching something very close to the letter of the
ABI, which passes as-is the testsuite.
Which in any case should use cp_tree_operand_length.
Paolo.
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
PR 5297
* libcpp/files.c (maybe_shorter_path): New.
(find_file_in_dir): Use it.
I can't approve or deny this patch, but for what it's worth, I find it
fine.
Thanks.
--
Dodji
Hi,
This patch adds x32 support to boehm-gc. The same patch has been
sent to the boehm-gc mailing list. Tested on Linux/x32 and Linux/x86-64.
OK for trunk?
Thanks.
H.J.
- Forwarded message from H.J. Lu hongjiu...@intel.com -
Date: Mon, 16 Apr 2012 09:39:20 -0700
From: H.J. Lu
Gabriel Dos Reis g...@integrable-solutions.net writes:
OK.
Thank you.
While bootstrapping the tree again, it appeared that an output
regression of the objc test objc.dg/foreach-7.m flew below my radar.
It's one of those typical cases where the first location pointed to by
the diagnostics
Currently we only constrain std::function's constructor to reject
integral arguments, this patch changes it to reject non-callable
arguments. This is the proposed resolution of LWG 2132, I had already
planned to do this anyway before the issue was opened so I don't see
any need to wait for a DR.
Thought I'd ping http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01225.html
since it's been about six weeks. Any initial feedback would be very
much appreciated!
Thanks,
Bill
Hi,
contributed by Marc (thanks Again!) and integrated by me. Tested
x86_64-linux, multilib. Committed to mainline.
Thanks,
Paolo.
///
2012-04-29 Marc Glisse marc.gli...@inria.fr
Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/51795
OK.
Jason
80 matches
Mail list logo
